HTTP 502 usually means a proxy or web server could not obtain a valid response from its upstream, often PHP-FPM. WordPress may be the workload that triggers the failure, but the 502 itself is generated one layer earlier.
Record the response headers and timestamp before restarting services. A restart can restore availability while erasing evidence of a crashed worker or exhausted pool.
Identify who generated the 502
Inspect response headers and body branding for Cloudflare, a hosting proxy, Nginx, Apache or load balancer. Test the origin through an authorised host method if a CDN is involved.
Record:
public/origin status
request URL and duration
proxy request/ray ID
server/PHP logs at same time
whether static assets workDo not expose the origin IP or weaken firewall controls during testing.
Compare static and PHP requests
Request a known image or CSS file, then wp-login.php and the affected page. Static success with all PHP requests returning 502 points to PHP-FPM/socket/upstream service.
If only one WordPress route fails, inspect that request’s PHP workload and timeout. If every site on the account fails, the problem is more likely shared hosting capacity or service configuration.
Check neighbouring domains only when authorised.
Inspect proxy and PHP-FPM logs
Look for “connection refused,” “upstream prematurely closed connection,” “no live upstreams,” worker exit, segmentation fault or timeout.
Match PID and request time across logs. PHP fatal errors normally produce an application response, while a crashed process may leave the proxy with no valid headers.
Protect logs because paths and request parameters can be sensitive.
Check PHP worker saturation
All workers may be busy on slow requests, causing new connections to queue or fail. Review active/max children, queue length, CPU and RAM.
Increasing worker count consumes more memory. Calculate per-worker peak and total server capacity before changing pool settings.
Find the slow route, query or external API that occupies workers. Capacity alone should not conceal unbounded work.
Verify socket and port configuration
Nginx/Apache must connect to the same Unix socket or TCP port where PHP-FPM listens. After a PHP version change, the old socket path may disappear.
Check socket ownership and permissions against the web server user. Do not use world-writable permissions as a fix.
On cPanel/Plesk, use supported PHP handler controls so panel-managed configuration is not overwritten later.
Look for process crashes
Inspect system/PHP logs for out-of-memory kills, segfaults and extension failures. An operating-system OOM event may kill PHP without a WordPress log entry.
Disable or update the implicated PHP extension through hosting controls after reproducing in staging. Do not remove required extensions from production without checking dependent sites.
Confirm disk and inode availability because services also fail when they cannot write sockets or logs.
Separate CDN 502 from origin 502
Cloudflare can return 502 when it cannot connect to the origin or when the origin sends an invalid response. Compare the Cloudflare event/request ID with origin access logs.
No origin request indicates DNS, routing, firewall or TLS between edge and origin. An origin 502 logged locally moves the issue to the server stack.
Avoid creating a broad firewall allow rule without verifying the provider’s current network requirements.
Repair and verify under load
Correct the socket, PHP service, pool capacity, crashing extension or slow WordPress path demonstrated by evidence. Restart only the necessary service and document its pre-restart state.
Test repeated PHP requests, administrator actions and the original route while monitoring workers. Recurring care should alert on PHP queue length, worker crashes and 502 rate so the server can be repaired before intermittent failures become a full outage.