Short answer: a 502 Bad Gateway means your web server (often Nginx) asked the PHP process for a page and got back something invalid, or nothing. The failure is in the connection between the two layers, not usually in your posts or database.
Why this differs from a 500
A 500 often means the application or server failed while handling the request. A 502 typically means a gateway did not receive a valid upstream response — the worker crashed, timed out, or was killed for exceeding a memory limit. That distinction matters because the fix lives in resources and process configuration, not in your theme code.
Constant or intermittent?
This is the first thing to establish. A constant 502 often follows a PHP restart, a bad deployment, or a CDN/proxy misconfiguration. An intermittent 502 that appears under load almost always means capacity — the PHP-FPM process pool is exhausted, or requests are exceeding the gateway timeout. Correlate the timing with traffic; a 502 only at peak hours is a sizing problem, not a bug.
Read both logs
Look at the web-server error log for the gateway message, and the PHP-FPM log for “server reached max_children” or workers being killed. Together they tell you whether you ran out of workers, hit a timeout, or crashed on a specific request. Check /wp-content/debug.log too for a fatal error inside a long-running request.
Find the slow or failing operation
Identify whether one action triggers it — saving a large post, running an import, opening a report, or a page that calls a slow external API. A single hanging third-party request can tie up a worker until the gateway gives up. Move genuinely long tasks (backups, imports) to the command line or a scheduled process instead of a web request.
What not to do, and how to verify
Repeatedly reloading a 502 adds more stalled requests to a saturated pool and extends the outage. Raising every timeout without finding the slow operation just turns a fast failure into a slow one. To verify, reproduce the specific action that failed under realistic concurrency, and confirm the site now degrades gracefully instead of holding requests open.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
A 502 describes a failed gateway-to-upstream exchange, not one universal PHP failure. Correlating proxy, web-server and PHP-FPM logs is what distinguishes a crashed worker, timeout, socket issue or bad upstream configuration.
- 1
Determine whether the 502 is constant, route-specific or load-dependent.
- 2
Match the gateway timestamp with PHP-FPM worker and operating-system events.
- 3
Check upstream socket or host configuration after deployments and restarts.
- 4
Identify long external calls or requests that occupy workers until the gateway gives up.
What must be verified
- The original route works repeatedly and under realistic concurrency.
- Gateway and PHP-FPM logs show no new upstream failures.
- External dependencies fail fast or degrade gracefully.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →