Where your 5xx class error comes from

The 5xx family in one line

Every 5xx code says "the server could not or would not complete the request". The family tells you which layer gave up: the code itself (500), the reverse proxy's origin (502), a deliberate or transient outage (503), the timeout between the proxy and origin (504), and the uncommon 599 Network Connect Timeout used by some proxies.

The stack that produces them

visitor -> CDN/proxy -> web server -> application (PHP/node) -> database

A 5xx is the network path pointing back at the last healthy layer:

That is why a single 502 points at the origin or the connection between the edge and origin, not at your PHP: an edge that receives a bad origin response converts the origin fault into a 502 by design. The 502 article covers the mapping in detail.

Code by code, with the structural cause

• 500 Internal Server Error: a genuine uncaught exception in the code or a server misconfiguration. The 500 article lists the top causes: a parsing error, a memory limit, a database connection failure, a bad config directive.
• 502 Bad Gateway: the gateway (nginx, Apache reverse proxy, the CDN's origin connection) received an invalid response from the upstream. Common origins: the origin timed out, the origin process restarted in the middle, DNS inside the origin failed, or the origin returned a response the gateway rejected. If a CDN is in front, the edge is the gateway and its view of the origin is where to look.
• 503 Service Unavailable: the server is up but deliberately refusing work: maintenance, under a load that tripped a limit, or a load-balancer node draining. Because it is deliberate, it is the one 5xx where Retry-After and 503 semantics actually matter.
• 504 Gateway Timeout: the upstream did not answer inside the gateway's timeout. For a same-host database this is a query-work timeout; with a proxy it is the proxy's own timeout. The fix lives in the timeout config or the slow upstream, not in the browser's retry.
• 599 Network Connect Timeout: non-standard, used by some CDNs and monitoring agents for "the proxy could not reach the server in time". If your visitors see it, there is no origin response at all: firewall, route, or DNS.

The one metric to add on a 5xx

Instrument at the layer that owns the failure, not at the page. An edge log that records $status per request and a breakdown of upstream_status for 502/504 (the origin's own HTTP status when the edge gives up) tells you within minutes whether the origin returned a real 500 (application fault) or no response (connection or timeout). Most CDNs and proxies expose the upstream status in their logs. That one field is the difference between "the PHP crashed" and "the full server is down", and it points you to the right article below.

When a 5xx is not a server fault

• A single 502 for https://example.com/api while / is fine. That is often an origin scope (an API pool) and not the whole site.
• A 503 that came with Retry-After: 120 during a deploy. That is the deploy path in action, not a bug.
• A 504 only on POST while GET is fast. The origin's write path (database, queue) is the lagging layer.

Where each goes next

The family maps to its own drill: the 500 article for application breaks, the 502 for proxy-origin, and the 503 + retry header for scheduling. If you are staring at a repeatable 5xx and do not yet know which of these it is, the troubleshooting order walks the first 15 minutes in the right sequence.