CDN and proxy 7 min read Updated August 2026

CDNs and reverse proxies: verify the response users actually receive

A CDN or reverse proxy can improve latency, absorb traffic, terminate TLS, compress content, and protect the origin. It can also rewrite redirects, cache the wrong variant, inject headers, or serve stale HTML, so the public edge response must be audited separately from the origin.

At a glance

The edge is part of the application

Treat caching, redirects, headers, TLS, and invalidation rules at the proxy as production code. A correct origin does not help if users and crawlers receive a different response from the edge.

  • Identify every layer that can change the public response.
  • Cache only responses whose variants and privacy rules are understood.
  • Use diagnostic headers carefully without exposing sensitive infrastructure.
  • Purge and retest edge nodes after configuration changes.
01

What detection can and cannot prove

The report infers CDN or proxy use from DNS and response characteristics such as Via, Age, cache-status, and provider-specific headers. Missing markers do not prove there is no proxy, and a detected provider does not prove the cache is configured well.

The useful question is whether the public response is correct: final URL, status, content type, encoding, cache directives, canonical signals, and body must match the intended variant.

02

Typical edge failures

  • Wrong cache key Language, device, authentication, or compression variants are mixed because relevant inputs are ignored.
  • Stale metadata Old canonical tags, robots directives, or content persist after a deployment.
  • Redirect conflict Edge and origin normalization rules create chains, loops, or a different hostname.
  • Cached errors A temporary 404 or 5xx is stored and continues after the origin recovers.
03

Debug edge and origin independently

Record the public response, then compare it with an authorized direct-origin request that preserves the production Host header. Inspect Age, cache-status, Vary, Cache-Control, and request IDs while avoiding any change that exposes the origin publicly.

Correct the owning layer, invalidate only the affected cache scope, and test several geographic points. Confirm both anonymous and personalized paths so a cache improvement does not leak user-specific content.

Action checklist

Keep edge delivery observable and safe

  1. 01Document the CDN, load balancer, proxy, and origin order.
  2. 02Validate cache keys for language, encoding, device, and authentication.
  3. 03Compare public and authorized origin responses.
  4. 04Set deliberate TTL and error-caching policies.
  5. 05Purge affected URLs and retest multiple edge locations.

Official references

The technical recommendations in this guide are aligned with these primary sources.