502 Bad Gateway

The short version: A 502 means a gateway or proxy (like Nginx or a CDN) reached the backend server but got back an invalid or empty response. Visiting? Reload and try again in a minute. Running the website? Restart the upstream service, such as PHP-FPM, and check the proxy and error logs.

Key takeaways

• A 502 means a gateway or proxy did reach the upstream server, but what came back was invalid or empty. Per RFC 9110 the server received an invalid response from an inbound server while acting on your behalf.
• Hold it next to 504: a 502 is a broken answer, a 504 is no answer in time. A 503 is the server refusing on purpose. A 500 is the application's own code crashing.
• This is server-side almost every time. As a visitor, give it a minute and reload; the rare local culprit is a misbehaving VPN, a proxy, or a stale DNS cache.
• For owners, one cause dwarfs the rest: a crashed or stopped upstream (PHP-FPM, a Node or Python app, a container). Restart that service and most 502s vanish.
• The nginx error log names the cause outright. connect() failed means the backend is down, Permission denied means a socket issue, upstream prematurely closed means the backend died mid-response.

Error type

HTTP 5xx server error

Whose side

Almost always the website

Fix difficulty

Moderate (website owner)

Common cause

Upstream returned an invalid response

What does 502 Bad Gateway mean?

A 502 Bad Gateway comes from a server acting as a gateway or proxy: Nginx, a load balancer, or a CDN like Cloudflare. It forwarded your request to the upstream (or origin) server behind it just fine, but the reply it got back was no good. Malformed, empty, or simply something it could not parse. Since the proxy cannot hand that broken reply on to you, it answers with a generic 502 instead.

Picture the request chain and it clicks: your browser talks to the proxy, and the proxy talks to the backend that actually builds the page. A 502 points squarely at that second hop. That is the line between it and a 504 Gateway Timeout, where the backend gives no answer at all and the proxy stops waiting. With a 502, an answer did arrive. It was just garbage. And because the failure lives server-side, fixing it almost always falls to the website owner or host, not the visitor.

502

HTTP status code

5xx

Server-side error class

RFC 9110

Spec that defines it

How the 502 Bad Gateway error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com

502

Bad Gateway

The server received an invalid response from the upstream server.

• 502 Bad Gateway
• HTTP Error 502 - Bad Gateway
• nginx: 502 Bad Gateway
• Cloudflare: Bad gateway Error code 502
• 502 Server Error: The server encountered a temporary error
• 502 Proxy Error
• Temporary Error (502)

502 vs 500, 503 and 504

All four are 5xx server errors, but they fail at different points in the request chain.

What the nginx error log message tells you

A 502 page is generic, but the matching line in <code>/var/log/nginx/error.log</code> usually names the exact failure.

What causes 502 Bad Gateway?

• The upstream service crashed or got stopped (PHP-FPM, a Node or Python app, an application container) and never came back, often right after a deploy or an out-of-memory kill.
• The proxy is aiming at the wrong place: a proxy_pass or fastcgi_pass pointed at a port or socket the backend is not listening on.
• Socket or permission trouble. The FPM socket is there, but the proxy cannot read it, and Nginx logs Permission denied or No such file or directory.
• Overload. Every backend worker is busy, requests pile up in the queue, and eventually the proxy abandons them and returns 502.
• Something in between is quietly blocking the connection: a firewall, a security rule, or mod_security sitting between the proxy and the origin.
• A CDN cannot reach a healthy origin. The origin is down, an origin firewall is dropping the CDN IPs, or DNS for the origin is misconfigured.
• A compression bug at the origin, like gzip content served with a wrong content-length header or broken gzip, which leads the proxy to reject the response.

How to find the cause fast

1. Open the proxy error log first (/var/log/nginx/error.log). The wording does the diagnosis for you: connect() failed means the backend is down, Permission denied means a socket issue, upstream prematurely closed means the backend died mid-response.
2. From the server itself, curl the origin directly with curl -I http://127.0.0.1:PORT/, skipping the proxy and CDN. If that fails too, the backend is the problem. If it works, the proxy or CDN config is.
3. Make sure the upstream service is genuinely running and listening. Use systemctl is-active, ps aux | grep, and check the socket or port with ss -lntp.
4. If a CDN sits out front, take it out of the loop for a moment (pause Cloudflare or query the origin IP). That tells you whether the 502 is coming from the edge or from your origin.

Terminal

curl -sI https://example.comHTTP/1.1 502 Bad GatewayServer: nginx# the upstream app server returned nothing valid

How 502 Bad Gateway looks from the outside

Pulsetic checks your website from 15 or more locations every 30 seconds over HTTP and HTTPS, so a 502 trips an alert the second your backend stops returning a valid response, not when a customer emails you. The checks run from outside your network, which means they see exactly what real visitors see at the CDN or proxy edge. Alerts reach you by email, SMS, voice call, Slack, Discord, Telegram, or webhook within seconds, and the response logs mark when the 502 started and when it cleared. What Pulsetic watches is availability from the outside; it does not read your server CPU or memory. So it tells you the website is down and when, and you read the server logs to learn exactly why.

To confirm the exact code a URL returns, or to re-test several at once after a fix, run them through the free bulk URL status checker.

How to fix 502 Bad Gateway

If you are a visitor

1. Wait a minute, then reload. A 502 is often a brief server-side blip that clears on its own.
2. Hard refresh to skip your local cache (Ctrl+F5, or Cmd+Shift+R on Mac).
3. Open the page in a private or incognito window, or a different browser, to rule out a cached page or an extension.
4. See whether the website is down for everyone using a service like Pulsetic or a down-detector. If it is down for all, only the owner can fix it.
5. On the off chance the fault is yours, flush your DNS cache (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS) and switch off any VPN or proxy.

If you run the website

1. Restart the upstream service that builds pages (sudo systemctl restart php8.2-fpm, or your Node, Python, or app container). A crashed or stopped backend is by far the most common cause.
2. Read the proxy and backend error logs side by side (/var/log/nginx/error.log and the FPM or app log) to catch the exact failure wording.
3. Check the proxy target. Confirm proxy_pass or fastcgi_pass points at the host, port, or socket the backend actually listens on, then run nginx -t and reload.
4. Seeing Permission denied in the Nginx log? Check socket ownership and permissions: the FPM listen.owner and listen.group should match the web server user.
5. Bump proxy and FastCGI timeouts (proxy_read_timeout, fastcgi_read_timeout) when long requests are getting cut off, and raise FPM worker counts when the pool is saturated under load.
6. Running a CDN such as Cloudflare? Make sure it can reach a healthy origin: allowlist the CDN IP ranges in your origin firewall and verify the origin DNS record.
7. When the 502 page carries no CDN branding, suspect compression at the origin and disable gzip compression to confirm.
8. If your host manages the stack and none of the above fits, contact your hosting provider with the timestamp and the affected URL so they can check the server side.

Still not fixed? Next steps

• From the server itself, curl the origin directly: curl -I http://127.0.0.1:PORT/. If that fails too, blame the backend. If it works, the proxy or CDN config is what is broken.
• Got a CDN out front? Bypass it. Pause Cloudflare or query the origin IP, and you will know whether the 502 is born at the edge or at your origin.
• A backend that keeps dying under load is usually a saturated worker pool or an OOM kill. Raise the worker counts and memory limits, and track down the slow request that pins workers.
• When your host manages the stack and the logs point at the server, hand them the affected URL and the exact timestamp. That lets them inspect the upstream from their side.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

Nginx upstream and proxy config

upstream backend {
    server 127.0.0.1:8080;
}

server {
    location / {
        proxy_pass http://backend;
        proxy_connect_timeout 90s;
        proxy_read_timeout 90s;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_read_timeout 90s;
    }
}

Check that the PHP-FPM backend is up

# Is the FPM process running?
ps aux | grep php-fpm
systemctl is-active php8.2-fpm.service

# Does the socket the proxy points at exist?
ls -l /run/php/php8.2-fpm.sock

# Hit the origin directly, bypassing the proxy and CDN
curl -I http://127.0.0.1:8080/

Restart services and read the logs

sudo systemctl restart php8.2-fpm.service
sudo nginx -t && sudo systemctl reload nginx

# Look for connect() / upstream / socket errors
sudo tail -n 50 /var/log/nginx/error.log
sudo tail -n 50 /var/log/php8.2-fpm.log

How to prevent 502 Bad Gateway

A 502 can come and go in seconds, which is exactly why it slides past you until a customer reports it. Pulsetic checks your website and key endpoints from multiple locations every 30 seconds and alerts you by email, SMS, voice call, Slack, Discord, and more the moment they start returning 502s or stop responding. It will not tell you which upstream crashed, but it tells you fast that something is wrong, and when it recovers, so you can move before your visitors do.

Learn how Pulsetic's uptime monitoring detects this from the outside, across 15+ locations.