502 Bad Gateway: What It Means & How to Fix It

What Is a 502 Bad Gateway Error?

502 Bad Gateway is an HTTP status code that means the server answering you is acting as a gateway or proxy, and it got an invalid response from the server behind it. The HTTP standard (RFC 9110, section 15.6.3) defines it exactly that way: the server, "while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request."

Most modern websites have at least two layers. A front server, such as nginx, Apache, Cloudflare or a cloud load balancer, accepts your connection, then passes the request to an upstream application such as PHP-FPM, a Node.js app, Python's Gunicorn or a container. When that upstream is down, crashes, or answers with something the proxy can't use, the proxy has nothing to give you, so it returns 502.

The important point is that the gateway itself is working. It received your request and responded. The fault is one step further back.

The Many Faces of a 502 Error

The status code is the same everywhere, but the page you see depends on which proxy produced it:

Whichever version you see, the name of the proxy in the footer is a useful clue: it tells the site owner which layer to investigate.

502 vs 500 vs 503 vs 504: What's the Difference?

The 5xx codes all mean "server problem", but each one points at a different layer:

A quick rule: 502 = the upstream refused the connection, hung up, or sent a bad answer, 504 = the upstream gave no answer in time. Our guides to the neighbours cover them in depth: 500 Internal Server Error, 503 Service Unavailable and 504 Gateway Timeout.

What Causes a 502 Bad Gateway?

• The upstream app isn't running. PHP-FPM, Node, Gunicorn or the container crashed, failed to start after a deploy, or is restarting.
• The proxy points to the wrong place. proxy_pass or fastcgi_pass uses the wrong port, an old PHP socket path after an upgrade, or localhost inside a Docker container.
• The app crashes on some requests. One page triggers an out-of-memory kill or an unhandled exception, and the connection closes before a response.
• All workers are busy. PHP-FPM hit pm.max_children, so new requests wait in the socket's queue. Most then time out as 504; once the queue is full, nginx logs (11: Resource temporarily unavailable) and returns 502.
• The response headers are too big. Large cookies or big security headers overflow nginx's proxy_buffer_size.
• Keep-alive mismatch behind a load balancer. The app closes idle connections sooner than the load balancer expects, so the balancer sends a request into a connection that is closing.
• The proxy can't reach the upstream after a network change. A firewall that rejects the proxy, or an upstream that moved to a new IP, gives 502 (Connection refused, No route to host). A firewall that silently drops packets gives 504 instead, and behind Cloudflare these show as 521 or 522.

How to Fix a 502 Error as a Visitor

You can't repair someone else's server, but these steps confirm the problem is really on their side and clear the rare local causes:

• Wait 30 to 60 seconds and reload (Ctrl + R, or Cmd + R on a Mac). Many 502s last only as long as a deploy or a restart.
• Check whether it's down for everyone. DNS Robot's Website Down Checker opens the page from 11 places, and the HTTP Header Checker shows the exact status code our server gets. If they see a 502 too, it's the site, not you.
• Hard-reload with Ctrl + Shift + R (Mac: Cmd + Shift + R), in the rare case a cached error page is being shown to you.
• Flush your DNS if the site recently moved hosts, so you reach the new server. Here's how to flush DNS on every system.
• Turn off VPNs and proxies. Your own proxy can be the "gateway" that fails, especially on work networks.
• Try another browser or your phone on mobile data. If it works there, clear cookies for that site.

How to Fix a 502 Bad Gateway on Your Server

Server-side, a 502 is one of the easier errors to fix, because the proxy usually logs what went wrong (a load balancer's keep-alive race and Cloudflare's own 502s are the exceptions). Work through these three checks in order; the fourth part is a real example.

1. Read the Proxy's Error Log

Reproduce the 502, then read the last 50 lines of the proxy's error log (commands below the table). Each of these nginx messages points to its own fix:

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

# Apache
sudo tail -n 50 /var/log/apache2/error.log    # Debian/Ubuntu
sudo tail -n 50 /var/log/httpd/error_log      # RHEL/Alma/Rocky

2. Check the Upstream App Is Running

# PHP-FPM (adjust the version)
sudo systemctl status php8.3-fpm
sudo journalctl -u php8.3-fpm -n 50

# Node.js under PM2
pm2 status
pm2 logs --lines 50

# Docker
docker ps -a          # look for containers that keep restarting
docker logs --tail 50 <container>

# Was it killed for using too much memory?
sudo dmesg -T | grep -i "killed process"

If the service is stopped, start it and find out why it stopped: a failed deploy, a syntax error in the new release, or the out-of-memory killer. In PHP-FPM's log, server reached pm.max_children setting means every worker was busy. Raise pm.max_children only if the server has the RAM for it, otherwise find the slow requests that tie workers up.

3. Make Sure proxy_pass Points to the Right Port or Socket

Compare what nginx is told to talk to with what is actually listening:

# What is nginx proxying to?
sudo nginx -T 2>/dev/null | grep -n "proxy_pass\|fastcgi_pass"

# What is actually listening?
sudo ss -tlnp            # TCP ports and their processes
ls -l /run/php/          # PHP-FPM socket files

Two classic mismatches: after upgrading PHP, the socket becomes php8.3-fpm.sock while nginx still points to php8.1-fpm.sock; and inside Docker, proxy_pass http://localhost:3000 points at the nginx container itself rather than the app, so use the Compose service name (http://app:3000).

4. A Real Example: How dnsrobot.net Served a 502

This happened to us on 30 September 2026. After we published a batch of new blog posts, exactly one of them returned 502 Bad Gateway through nginx 1.24, while every other page worked. The Next.js app behind nginx returned that same page with 200 OK when we requested it directly on port 3000. So the app was fine and the gateway was failing.

The nginx error log had the answer in one line: upstream sent too big header while reading response header from upstream. That page's response headers came to 4,087 bytes, mostly a long Content-Security-Policy header plus preload Link headers. nginx reads the first part of the response, including all headers, into a buffer set by proxy_buffer_size, which by default is one memory page: 4 KB on our server. That left only 9 bytes of room, and the full header block, status line included, overflowed it.

The fix was three lines in the location block that proxies to the app; after nginx -t and a reload, the page returned 200:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_buffer_size 16k;        # room for large headers (was the 4k default)
    proxy_buffers 4 32k;
    proxy_busy_buffers_size 64k;
}

The lesson: if only some pages return 502 while the rest of the site works, look for a size limit, such as large headers or Set-Cookie values on those pages, before you suspect the app.

Node.js Behind a Load Balancer: Random 502s

If you run Node.js behind AWS Application Load Balancer or a similar balancer and see occasional 502s with no errors in your app logs, check keep-alive timeouts. Node's HTTP server closes idle keep-alive connections after 5 seconds by default in Node 26 and earlier (server.keepAliveTimeout; Node 24.6 and 22.19 added a 1-second keepAliveTimeoutBuffer on top, and the next major release raises the default to 65 seconds), while an AWS ALB keeps idle connections open for 60 seconds. Sometimes the balancer reuses a connection just as Node closes it, and that request comes back as a 502.

The fix is to keep the app's timeout longer than the balancer's:

const server = app.listen(3000)
// Must be longer than the load balancer's idle timeout (ALB default: 60s)
server.keepAliveTimeout = 65_000
server.headersTimeout = 66_000 // only needed before Node 18; harmless later

502 Bad Gateway on Cloudflare

Behind Cloudflare, first look at who made the error page (Cloudflare's 502/504 guide):

• Cloudflare-branded page (Browser ✓ / Cloudflare ✓ / Host ✗): your origin server itself returned a 502 or 504 to Cloudflare. Fix it on the origin with the server-side steps above. If Cloudflare can't connect to the origin at all, you get 521 or 522, not 502.
• A plain page saying "502 Bad Gateway" with "cloudflare" underneath: this one comes from Cloudflare itself. Cloudflare's docs name two causes: your origin sending broken gzip content, or gzip content without an updated Content-Length (turn compression off at the origin to test), and a sudden traffic spike at one Cloudflare data centre, which passes on its own.
• A page naming nginx or Apache: usually the request reached your server without going through Cloudflare, so the DNS record isn't proxied (grey cloud) or you're looking at the origin directly (unless a Cache Rule turns on Origin error page pass-through).
• Moved hosts? Update the origin's A record in Cloudflare's DNS (a wrong origin IP usually shows as 521, 522 or 523). A DNS Lookup only shows the origin for grey-cloud (DNS only) records; proxied records answer with Cloudflare's own IPs.

Does a 502 Error Hurt SEO?

A short outage doesn't. Google's documentation says 5xx server errors make its crawlers temporarily slow down crawling. Pages that are already indexed stay in the index at first, but if the errors persist, Google eventually drops those URLs.

So a 502 lasting a few minutes during a deploy is harmless. A 502 on important pages that lasts days, or one that appears intermittently for weeks, can reduce crawling and cost rankings. Monitor your key URLs, and check the Crawl stats report in Search Console after any outage.