After CDN is introduced, failure no longer belongs only to the origin server. A user-facing 502, 504, certificate error, or slow page may come from the edge, origin network, firewall, TLS configuration, cache rules, or the application process. Changing many settings at once destroys the evidence needed for diagnosis.
Confirm the request actually reaches CDN
Check DNS, response headers, certificate coverage, and hostnames before logging into the server. Some regions may still resolve legacy records and some subdomains may bypass CDN. If entry points differ, later observations cannot be compared reliably.
Confirm the edge can reach the origin
Common causes include missing source IP allowlists, closed ports, HTTPS origin validation failure, strict Host requirements, and protocol mismatch. Origin protection is useful only when it matches the CDN's actual fetch behavior.
Cache rules can amplify small problems
If HTML never caches, every request pressures the origin. If error responses are cached, a brief incident can last longer. If random query strings bypass cache, peak origin traffic grows unexpectedly. Separate rules for pages, static assets, downloads, APIs, and error pages.
| Signal | Check first | Typical action |
|---|---|---|
| 502 | Origin port, process, protocol | Restore process or fix Host/protocol |
| 504 | Origin latency, database, dependencies | Reduce origin pressure and slow requests |
| TLS error | Certificate scope, SNI, validation | Correct certificate or origin policy |
| Traffic spike | Cache key, random parameters, hot assets | Normalize cache and purge flow |
Records are more valuable than a lucky repair
Each incident should leave a timeline: first signal, affected regions, error type, recent change, actions, and recovery evidence. Over time, those records reveal whether the recurring issue is configuration, capacity, release process, or provider boundary.