Common CDN issues

Start with the symptom

Common CDN issues are often misdiagnosed because the CDN sits in the middle of several systems at once. A slow page might be an origin problem, a cache-key problem, a regional routing problem, a TLS problem, or a security rule. A missing image might be a bad deploy, an old cached object, a purge delay, a MIME-type issue, or a blocked request. The fastest path is to start with the user-visible symptom, then trace the request path step by step.

A CDN can improve performance, availability, and security, but it also adds another decision layer. It may answer from cache, forward to one of several origins, transform a response, redirect a request, block traffic, or serve stale content during an outage. Each of those behaviors can be correct. They only become issues when the behavior is unexpected, unobservable, or owned by the wrong team.

Cache symptoms

Cache problems are the most familiar CDN issues. Stale content appears when the CDN still has an older response after the origin has changed. This can be normal if the TTL has not expired, but it becomes a problem when publishing workflows assume immediate freshness. The fix may be a shorter TTL, a better purge process, versioned asset URLs, or clearer expectations for content teams.

The opposite problem is poor cache reuse. Low hit rates can come from very short TTLs, unnecessary cookies, query strings that create duplicate entries, broad Vary headers, or CDN rules that bypass cache too often. A page can look cacheable to a human while every request produces a different cache key.

Cache poisoning is a security-sensitive version of the same theme. If untrusted request headers, hostnames, or query parameters influence a cached response without being safely represented in the cache key, an attacker may be able to store a response that later visitors receive. Strict host validation, careful cache-key design, and avoiding cache storage for ambiguous responses reduce this risk.

Origin and routing symptoms

Origin problems often appear as CDN errors even when the edge is healthy. Timeouts, connection resets, overloaded application servers, invalid upstream certificates, and origin firewall changes can all produce user-visible failures. If the CDN reports a high number of origin errors, compare edge logs with origin logs before changing CDN policy.

Routing issues can be more subtle. A request may go to the wrong origin pool, a backup origin may not have the same content, or a health check may fail open or fail closed in a way the application was not designed for. Multi-region systems need special attention because a region can be reachable while its database, cache, payment provider, or object storage dependency is not.

Direct-to-origin bypass is both an operations issue and a security issue. If users or attackers can reach the origin without passing through the CDN, they can avoid cache, WAF, rate-limit, bot, and TLS policies. During an incident, bypass traffic can make dashboards disagree because the CDN sees only part of production traffic.

DNS and TLS symptoms

DNS issues include stale records, split traffic during migrations, incorrect CNAME targets, missing IPv6 coverage, and low TTLs that do not behave as expected across resolvers. CDN migrations should be treated as staged production changes, not just DNS edits. Keep old records, certificate coverage, origin readiness, and rollback paths visible until traffic is stable.

TLS issues include expired certificates, hostname mismatches, missing intermediate certificates, unsupported protocol settings, and redirect loops between HTTP and HTTPS. Remember that there are usually two TLS legs: browser to CDN, and CDN to origin. The browser may be fine while the origin leg is failing, or the origin may be fine while the edge certificate is wrong.

Mixed content is another common failure. A page delivered over HTTPS may still reference scripts, images, or APIs over HTTP. Modern browsers may block those resources, creating problems that look like frontend bugs but are really delivery hygiene issues.

Security policy surprises

CDNs often host WAF, bot, DDoS, rate-limit, geo, and header policies. False positives can block real users, payment callbacks, crawlers, uptime monitors, or mobile app traffic. False negatives can leave expensive endpoints exposed during scraping, credential stuffing, or application-layer denial-of-service attacks.

The hard part is context. A rule that is safe for a public image path may be too aggressive for checkout. A bot rule that works for browsers may break API clients. A rate limit that protects login may harm a legitimate bulk action in an admin tool. Security policy should be route-aware, logged, and testable.

Header manipulation can also surprise teams. Adding, removing, or normalizing headers at the edge can affect cache behavior, CORS, authentication, redirects, analytics, and application logic. These changes should be tracked like application changes because they change the request the origin sees.

A practical troubleshooting routine

For a single failed request, capture the URL, method, timestamp, client network, response code, response headers, cache status, edge location, request ID, and user impact. Then check the same request from another region and from the origin path if that is allowed. A regional difference points toward routing, POP, ISP, or local cache behavior. A global difference points toward policy, origin, DNS, or deployment state.

For broader incidents, separate the problem by layer: DNS resolution, TLS handshake, edge policy, cache lookup, origin connection, application response, and browser rendering. Avoid changing several layers at once. If the team disables security rules, bypasses cache, and changes DNS together, it may restore service but destroy the evidence needed to prevent a repeat.

Preventing repeat issues

Good CDN operations depend on ownership and observability. Define who can change DNS, certificates, cache keys, TTLs, origin pools, purge rules, and security policies. Keep an audit trail. Require a rollback plan for high-risk routes such as login, checkout, APIs, uploads, and admin paths.

Monitor cache hit ratio, origin error rate, edge error rate, TLS errors, rule actions, purge volume, direct-origin traffic, route-level latency, and regional availability. Global averages are useful, but route and region breakdowns are what make CDN issues diagnosable.

The most useful habit is to document intended behavior before incidents: which routes may be cached, which may be served stale, which origins are active, which security controls are expected, and what evidence proves a request followed the intended path. Common CDN issues become easier to fix when the normal state is explicit.