How to Use Cloudflare DNS with a VPS and Nginx
Point domains to a VPS cleanly, keep Nginx in control of the origin, and avoid the most common confusion around Cloudflare proxying, DNS records, and HTTPS setup.
How Cloudflare DNS, your VPS IP, and Nginx fit together on a real self-hosted site.
Small websites, reverse-proxied apps, private admin entrypoints, and first VPS deployments.
People often mix up DNS, proxy mode, and origin HTTPS, then debug the wrong layer for hours.
Before you begin
- Know the public IP of your VPS.
- Know which hostname should point to which service.
- Have SSH access and working Nginx config validation before changing live DNS.
Cloudflare can make a VPS setup cleaner, but only if you keep the layers straight. DNS points names at your server. Cloudflare proxy mode may sit in front of that traffic. Nginx still handles the origin web serving or reverse proxying on your VPS. Most frustration comes from confusing those jobs and changing the wrong thing first.
Understand what each layer is doing
Cloudflare DNS tells the world where your hostname should resolve. If the record is proxied, Cloudflare stands between the visitor and your server. Nginx lives on the VPS and serves the site or proxies to apps behind it. TLS may exist both between the visitor and Cloudflare and between Cloudflare and your origin, depending on how you configure it.
Create DNS records deliberately
Most small VPS setups use an A record for the root domain and either another A record or a CNAME for subdomains. Point the record at the VPS you actually intend to serve traffic from. Keep names organized so it is obvious which subdomains are public websites, app endpoints, or admin-only entrypoints.
If you are moving a live hostname, lower TTL only if that actually helps your migration. The more important thing is making sure the origin is ready before traffic reaches it.
Configure Nginx at the origin clearly
Your Nginx server block should match the hostname you are publishing and either serve the site directly or reverse proxy to the correct internal service. Test with nginx -t before reloads, and confirm the app works at the origin even before Cloudflare is involved. If the origin is broken, Cloudflare will not make it healthy.
For reverse-proxied apps, be explicit about upstream targets, headers, and whether the backend should stay private on localhost or an internal Docker network.
Handle HTTPS correctly at the origin
Do not assume Cloudflare removes the need for correct origin HTTPS. For most production sites, use a mode where Cloudflare talks to an HTTPS origin, not plain HTTP. That means your Nginx side should still have a valid certificate path, often via Let’s Encrypt or a Cloudflare origin certificate depending on your model.
What matters operationally is consistency. If Cloudflare expects HTTPS to your origin, your origin must actually serve HTTPS correctly for that hostname.
Use proxy mode intentionally and keep private services private
Public websites are a natural fit for proxied records. Private admin tools are different. Some services should stay DNS-dark or reachable only through VPN, localhost tunnels, or tightly scoped entrypoints. Do not treat Cloudflare as a reason to expose everything. A safer pattern is to proxy the public website and keep control planes, dashboards, and internal tools on separate private paths.
This is where many operators get into trouble. They solve the public site, then casually expose admin surfaces because the DNS layer made publishing feel easy.
Common mistakes to avoid
The biggest mistakes are proxying a record before the origin is ready, using the wrong SSL mode, forgetting that Nginx still needs correct hostname config, exposing private tools just because DNS is convenient, and debugging DNS when the actual problem is an origin app or reverse proxy target.
What to do next
Once DNS and edge routing are clear, the next step is making the host itself easier to recover and maintain. Continue with How to Keep a Self-Hosted Service Running with systemd.