CDN vs reverse proxy: what each layer is for

Same verbs, different geography

Both can cache GET, strip headers and proxy to an upstream. The proxy usually sits next to the app. The CDN sits next to the user.

If all of your users are in one metro, a local proxy may be enough. The moment they are not, the proxy becomes the origin as far as the world is concerned.

The delivery model

What you should keep on the proxy

Application routing, WebSocket upgrades to a specific worker, internal auth, and caching that depends on application internals can stay on nginx or the framework.

Cloud CDN does not replace your app router. It reduces how often that router runs for public GETs.

What you should move to the CDN

Public TLS, global cache, image transformation, large-file delivery, DDoS absorption and hiding the origin IP belong at the edge.

You can still run nginx behind Cloud CDN. Many teams do. The proxy then sees Shield-consolidated misses instead of the whole internet.

Do not double-cache blindly

A stale proxy cache behind a stale CDN cache is two clocks to debug. Pick TTLs per layer. Purge both on deploy if both store HTML.

Hashed assets can be cached in both places. HTML should have a single operator who is allowed to invalidate it.

Validate before production

Document which layer owns TLS, cache lifetime, forwarded headers, and invalidation. Test a request through both layers and confirm that the application uses trusted proxy information rather than arbitrary client-supplied headers.

• Record the configuration and expected result before changing traffic.
• Keep evidence of the test and a working rollback for the previous behavior.