502 Bad Gateway
The web server reached PHP and PHP did not answer. Nginx or Apache is reporting a conversation that ended before it started.
502 Bad Gateway
PHP-FPM is either down or its workers are all busy. Check whether the process is running before anything else - a stopped pool and a saturated pool produce the same page and need different fixes.
What causes it, most likely first.
Work down the list. Each check is written to rule its row in or out before you change anything, because the fixes below it are different and a guess costs more than a command.
| Cause | How to check | Fix |
|---|---|---|
| PHP-FPM is not running | The service status says inactive or failed. The web server log says "connect() failed" or "no live upstreams". | Start it, then read why it stopped. A pool that exited on its own usually did so because the machine ran out of memory. |
| Every worker is busy | The pool is running, the 502s come in bursts under traffic, and the log says the upstream timed out rather than refused. | Find the slow request occupying the workers. Adding workers to a pool starved by one slow endpoint buys minutes, not a fix. |
| The socket path or port is wrong | Every request 502s, consistently, including static-looking URLs that route through PHP. The log names a socket that does not exist. | Point the web server at the socket the pool actually listens on. This appears right after a PHP version change. |
| A worker crashed mid-request | The PHP-FPM log records a segfault or a child exiting on a signal, timed to the request. | Identify the extension involved. A segfault is rarely WordPress code - it is usually a native extension meeting input it did not expect. |
| A proxy in front is timing out | The origin serves the page fine when requested directly, and only the public URL 502s. | Raise the proxy's read timeout, or make the slow response faster. The origin is not the thing to change here. |
Fixing it, step by step.
Commands assume WP-CLI and shell access. Where you have neither, each step says what it is doing so it can be done from the dashboard or over SFTP instead.
Ask whether PHP is running at all
This one answer removes half of the possibilities.
systemctl status php8.3-fpm --no-pager | head -n 12
Read the web server log for the exact upstream complaint
"Connection refused" and "upstream timed out" mean different things and point at different sections above.
grep -E 'upstream|502' /var/log/nginx/error.log | tail -n 20
Look at the PHP-FPM log for crashes
Exits on a signal, and warnings that all children are busy, both live here.
tail -n 40 /var/log/php8.3-fpm.log
See what the workers are actually doing
If they are all occupied by the same URL, you have found the slow endpoint.
wp cron event list --fields=hook,next_run_relative --status=due
Restart the pool once you know why
A restart clears the symptom. Doing it without reading the log means doing it again tomorrow.
systemctl restart php8.3-fpm
What the platform takes off the list.
Each site has its own PHP-FPM pool in its own container with its own memory limit, so one site exhausting its workers cannot 502 anybody else's - the failure stays where it started. Restarting services is a button rather than an SSH session, and because the pool is sized with the plan rather than shared across a whole machine, a busy neighbour is not one of the causes on this list.
Questions, answered.
Is a 502 my fault or the host's?
Why does restarting PHP fix it for a while?
Can a single plugin cause a 502 across the whole site?
How is this different from a 504?
If that was not it.
These fail in ways that look similar from the browser.