Should you put your site behind a reverse proxy or CDN?

A reverse proxy sits in front of your origin server and forwards requests to it — adding filtering, routing or TLS termination on the way. A CDN distributes cacheable content across many locations so it's served near each visitor. Many commercial services combine both, which is why the terms travel together — but they're two functions, and knowing which problem you're solving matters. Either way, the provider's network becomes your front door, and that changes how TLS, caching, visitor IPs and even your site's availability behave — so a few things are worth deciding deliberately rather than discovering later.

Cloudflare is one well-known example of this kind of service; Fastly, Bunny, Akamai and Amazon CloudFront are others, and many hosting plans and site platforms (for example Netlify or Vercel) include a CDN of their own. The principles below apply to any of them; for the exact dashboard steps, plan limits and defaults, check your chosen provider's current documentation — those change often and aren't worth memorizing.

What it actually does

You point the relevant web hostname at the provider — some services also require moving your authoritative DNS to them, which is a separate architectural decision — and it becomes your front door:

• A global cache (CDN) — static files (images, CSS, JS) are served from a location near each visitor, a real speed win for anyone far from your host.
• Attack absorption — DDoS floods and abusive bots can be filtered before they reach your server, often with a configurable firewall (WAF).
• HTTPS at the edge — the provider can terminate TLS and serve a certificate. Useful — but it complements, not replaces, HTTPS at the origin, and it's not by itself a reason to add a proxy.
• A layer you configure — caching, redirects and rules in a dashboard, without touching the server.

Note the scope: only the web hostnames the service supports are proxied. MX, verification and other service records remain ordinary DNS records — putting a domain "behind" a proxy does not route your email through it.

That's real value. The trade-off is a second system to understand and a third party your traffic now passes through.

The decisions to get right

• Encrypt the origin hop too. Edge HTTPS only secures visitor-to-proxy. The proxy-to-your-server hop is separate: install a certificate on your origin and set the proxy's TLS mode to its strictest ("full/strict"-style) setting so that hop is encrypted and verified, not left in the clear.
• Cache by explicit inclusion, not broad exclusion. Begin with static assets. Public HTML can cache well — article, landing and product pages — but only once you've verified the page is identical for every visitor and that login, cart, form and preview states are excluded; the real line isn't static-versus-HTML but public-and-identical versus personalized or fast-changing. Drive lifetimes from your origin's own Cache-Control header where you can, and beware cache-everything rules that can freeze an error response when your server hiccups — prefer status-aware caching and "serve stale". And know how content is invalidated: check whether deployments and content updates purge the affected URLs automatically, and prefer a targeted purge to clearing the whole cache.
• Recover the real visitor IP. Every request now arrives from the proxy, so logs, rate limits and analytics see the proxy's address unless you configure the server or application to use the provider's documented client-IP header or trusted-proxy mechanism — and only trust it on connections that genuinely came from the proxy, or an attacker can spoof it.
• Lock down the origin — where your hosting permits it. A proxy only helps if visitors can't bypass it. Restrict the origin to the provider's published networks or use an authenticated tunnel; keep those ranges updated, and account for legitimate direct access (health checks, administration, third-party callbacks). And know that hiding the origin IP is not the same as securing it — historical DNS records and outbound email headers may already reveal the address.
• Know where your traffic — and your visitors' data — now flows. All traffic passes through the provider, which may terminate TLS and see request contents, form submissions included. Treat that as a deliberate data-processing decision: check the provider's data-processing agreement, processing locations, subprocessors, log-retention settings and transfer safeguards where applicable.
• Document a tested recovery route. The proxy becomes a single point in front of your whole site: an outage or misconfiguration there makes the site unreachable even with a healthy origin. "Bypass it in an emergency" is harder than it sounds — know which DNS record you'd change, whether the origin serves a browser-trusted certificate on its own, how long cached answers would take to drain, and how the firewall restrictions would be adjusted without leaving the origin exposed. Test the route once before you need it.
• Use scoped credentials. If you automate anything (like cache purges), create an API token limited to just that permission — never a global, account-wide key — so a leak can't take over everything.

What it will not fix

A CDN can't make slow database queries fast, rescue an overloaded application, update vulnerable software, or compensate for a badly configured origin — it can only hide some of that some of the time, for cacheable pages. Before assuming the CDN is the answer, measure where the delay actually occurs: at the edge, on the network, or inside the application.

A reverse proxy or CDN can be a genuine win for a small site — as long as you cache deliberately, secure both hops, and remember it now owns your front door. For the specific setup steps, follow your provider's current docs.

What to do

1. Decide what problem you're solving: a CDN mainly reduces latency and origin load for distant visitors; a proxy adds filtering, origin shielding and centrally managed rules. Neither is required merely for HTTPS.
2. Turn on edge HTTPS and secure the origin hop with an origin certificate and strict TLS mode.
3. Cache by explicit inclusion — static assets first, verified-public HTML deliberately — and know how purges happen on deploy.
4. Configure the provider's trusted client-IP mechanism, and restrict the origin to proxied traffic where your hosting allows.
5. Check the privacy and data-transfer implications, and proxy only web hostnames — mail and verification records stay ordinary DNS.
6. Write down and test the emergency bypass route, and use scoped API tokens for any automation.