Read 5xx as a layer clue
A 5xx response means a server-side layer could not complete the request, but the status alone is not a root-cause report. First record the exact code, URL, response time, headers, timestamp and whether the result came from a CDN, reverse proxy or origin. A fast 502 and a slow 504 usually point to different failure paths.
What 502 usually means
A 502 Bad Gateway commonly means a gateway or reverse proxy could not obtain a valid response from its upstream. Check the upstream address, port, protocol, socket, service state and response format. Connection refused, connection reset and an invalid header are different clues; correlate them with proxy and application logs instead of repeatedly refreshing the page.
What 503 usually means
A 503 Service Unavailable often indicates that the service is stopped, overloaded, in maintenance or refusing traffic through a health check or rate limit. Check application workers, deployment state, health-check rules, connection pools, CPU, memory and disk pressure. A 503 generated by a CDN may not mean the origin itself returned 503.
What 504 usually means
A 504 Gateway Timeout means a gateway waited too long for an upstream response. Find which hop timed out: CDN to proxy, proxy to web server, web server to PHP-FPM, application to database or application to an external API. Increasing a timeout can hide symptoms while making worker exhaustion worse, so measure the slow dependency first.
Trace the request path in order
Check DNS and the intended IP, then inspect the edge or CDN, reverse proxy, virtual host, upstream socket, application process, database and external services. Confirm that each layer points to the next layer you expect and that firewall rules allow the connection. Test the origin directly only when you are authorized to do so.
Use timestamps and logs together
Keep the diagnostic timestamp and request path. Compare CDN, load balancer, proxy, web-server, PHP-FPM, application and database logs for the same window. Look for connection refused, upstream timeout, broken pipe, worker restart, out-of-memory kill, database pool exhaustion and deployment errors. Log correlation is more reliable than guessing from the status code.
Check resource and process limits
Review CPU, memory, disk space, file descriptors, process limits, worker counts, queue length, database connections and restart history. A service may be technically running but unable to accept more work. Fix the bottleneck or failing dependency before raising concurrency or proxy timeouts.
Verify one change at a time
After correcting the upstream address, restoring a process or fixing a dependency, test the affected layer first and then the public HTTPS URL. Compare response code, latency, headers and logs. Keep a rollback configuration and avoid simultaneous DNS, proxy, application and database changes that make the result impossible to attribute.
Common mistakes and limits
Do not treat every 5xx as a DNS problem, assume a 200 response from one path proves the whole application is healthy, or expose stack traces and credentials in public diagnostics. IIPP can show public response evidence, but origin logs, private health checks and application metrics remain the operator’s source of truth.
Check real data now
Use the live IIPP tool to inspect the domain or IP address you are working with.
Website Diagnostics →