502 Bad Gateway Error: What It Means and How to Fix It, Step by Step

A 502 Bad Gateway appears when Nginx (or Apache in reverse proxy mode) acts as an intermediary to another process—usually PHP-FPM—and that process doesn't respond validly. It's not a problem with the browser of whoever visits the site: it's the web server throwing up its hands because the backend hasn't given it anything usable.

What's actually happening behind the scenes

When a visitor requests a PHP page, Nginx doesn't generate it itself: it passes it to PHP-FPM via a socket or port, waits for the response and returns it to the browser. The 502 fires when this handoff breaks: PHP-FPM has crashed, it's restarting, a plugin has entered an infinite loop and saturated the available processes, or the socket is no longer reachable. The typical causes, according to the technical guides consulted, are the backend not running, a process crashing mid-response or a socket with incorrect permissions.

First check: do it yourself, before raising a ticket

Before contacting your hosting provider, three checks require zero technical expertise:

1. Reload the page once, waiting a few seconds. If the issue was a momentary PHP-FPM restart, it disappears on its own.
2. Check if it's global or local: try the homepage and at least one other page on the site. If only one specific page gives 502 (typically one with lots of data or a heavy plugin), suspicion shifts to that single script, not the server.
3. Note the exact time you saw it, including minutes. Without this information, anyone looking at the server logs is searching blind.

What to write to your hosting provider to get help faster

A ticket saying "the site is down" wastes everyone's time. Instead, provide:

• the exact URL (not just the domain: if it's a specific page, that one);
• the precise time, with timezone, of the first and last error you saw;
• a screenshot of the 502 page (helps distinguish a 502 generated by Nginx from one generated by a CDN or WAF in front of the server, which are different problems);
• if possible, whether the error appeared after a specific action (plugin update, deployment, configuration change).

If you have SSH access: commands in order

Reference environment: Ubuntu 24.04 with Nginx and PHP-FPM (php8.3-fpm package, the default version in Ubuntu 24.04 repositories; if the site uses another version substitute the number).

1. PHP-FPM service status:

sudo systemctl status php8.3-fpm

You should see a green "active (running)" status. If instead it shows failed or inactive, the issue is confirmed: PHP-FPM isn't responding to anyone, not just your browser.

2. If the service is in failed state, the details are in the system log:

sudo journalctl -xeu php8.3-fpm.service

Among the most common causes of failed startup are process master startup timeouts, as shown in various real cases: Active: failed (Result: timeout) since Fri 2025-08-01, with the final line php8.3-fpm.service: Failed with result 'timeout'.

3. Verify that the socket exists and has correct permissions:

ls -la /run/php/
ls -la /run/php/php8.3-fpm.sock

The socket must belong to the user running Nginx (typically www-data). If PHP-FPM appears active but the site still gives 502, check whether the socket exists, its permissions, and whether the socket's owner matches the web server user (Nginx: usually www-data).

4. Read Nginx's error log, which reports the exact cause in the "upstream" line:

sudo tail -n 50 /var/log/nginx/error.log

The lines to look for and their meaning:

Log message	Most likely cause
connect() failed (111: Connection refused)	the backend is not running on that port/socket
connect() failed (110: Connection timed out)	the backend is unreachable or blocked by a firewall
upstream prematurely closed connection	the backend crashed mid-response
recv() failed (104: Connection reset by peer)	the backend interrupted the connection
no live upstreams	all configured backends failed health checks

This mapping corresponds to what the technical guides consulted report: connect() failed (111: Connection refused) → backend not running on that port; connect() failed (110: Connection timed out) → backend unreachable/firewalled; upstream prematurely closed connection → backend crashed mid-response; recv() failed (104: Connection reset by peer) → backend reset the connection; no live upstreams while connecting to upstream → all backends failed health check.

5. If you just need to restart the service after working out the cause:

sudo systemctl restart php8.3-fpm
sudo systemctl restart nginx

502 or 504? They're not the same error

Confusing them leads to applying the wrong fix. A 502 means nginx received a response from the upstream, but the response was invalid, incomplete or came from a crashed process, whereas a 504 means nginx gave up waiting because the upstream was taking too long to respond. In practice: if the log says "upstream timed out" you're looking at a 504 (slow backend, need to raise timeouts), not a 502 (absent or crashed backend, need to restart it or understand why it crashed). Increasing proxy_read_timeout doesn't fix a 502 caused by a dead process: a 502 isn't a 504. If the log says upstream timed out (110: Connection timed out) while reading response header, nginx connected successfully and the backend is simply too slow, in which case the right fix is to increase proxy_read_timeout, not the one above.

Minimum path for those with SSH access

1. systemctl status php8.3-fpm → if it's not active (running), go to journalctl.
2. journalctl -xeu php8.3-fpm.service → understand why it crashed (memory, timeout, config).
3. ls -la /run/php/ → does the socket exist with correct permissions?
4. tail -n 50 /var/log/nginx/error.log → the "upstream" line tells you the exact cause, use the table above.
5. Only then, systemctl restart php8.3-fpm—restarting before reading the log hides the cause and the problem returns.