A 502 Bad Gateway error means one server, acting as a gateway or proxy, received an invalid response from the server behind it. The proxy (Nginx, a load balancer or a CDN such as Cloudflare) is working fine. The application server behind it isn't.
For visitors there's little to do except refresh. For site owners, a 502 is a useful clue: it tells you exactly which layer of your stack to look at.
How a 502 happens
Most modern sites have at least two hops:
Browser → CDN / load balancer / Nginx → App server (PHP-FPM, Node, Gunicorn, Puma...)
(the "gateway") (the "upstream")
The gateway forwards the request upstream and waits. If the upstream refuses the connection, closes it halfway, or sends back something that isn't valid HTTP, the gateway can't pass anything useful on. It returns a 502 instead.
Different layers word it differently: 502 Bad Gateway (Nginx), 502 Proxy Error (Apache), Error 502 with a Cloudflare page, or an HTTP 502 from AWS ALB and Google Cloud load balancers.
The 8 most common causes
- The app process is down. PHP-FPM, Node or Gunicorn crashed or never started after a reboot. Nginx logs
connect() failed (111: Connection refused). - Wrong upstream address. A deploy changed the socket path or port, and Nginx still points at the old one. You'll see
No such file or directoryfor a socket. - Worker pool exhausted. All PHP-FPM children or Node workers are busy with slow requests, so new connections get dropped. This appears under traffic spikes or when a database gets slow.
- The app crashes mid-request. A fatal error, segfault or out-of-memory kill closes the connection before the response is complete:
upstream prematurely closed connection. - Response headers too large. Big cookies or many
Set-Cookieheaders overflow the proxy buffer:upstream sent too big header. - CDN can't reach the origin. Firewall rules block the CDN's IP ranges, or the origin's IP changed and DNS at the CDN wasn't updated.
- TLS mismatch between proxy and origin. The CDN connects over HTTPS but the origin's certificate is invalid, or the other way round.
- Deploy in progress. Old workers are stopped before the new ones are ready, leaving a gap of a few seconds with no upstream.
How to find which one it is
Step 1: read the proxy's error log
This is the fastest route to an answer. On Nginx:
sudo tail -n 50 /var/log/nginx/error.log
Match the message against the causes above: connection refused means the process is down (1) or the address is wrong (2). Prematurely closed means a crash (4). Too big header is (5). Resource temporarily unavailable on a socket usually means the pool is full (3).
Step 2: check the app process
sudo systemctl status php8.3-fpm # or your app's service sudo journalctl -u php8.3-fpm -n 100 --no-pager
Step 3: bypass the proxy
Call the upstream directly from the server. If this fails, the problem is the app; if it works, the problem is the proxy config or the network between them.
curl -sv http://127.0.0.1:3000/health # Node/Go/Python on a port # PHP-FPM behind a socket: check the socket exists and is owned correctly ls -l /run/php/php8.3-fpm.sock
Step 4: look at resources
Run free -m and df -h, and check dmesg | grep -i kill for the OOM killer. A full disk or an out-of-memory kill causes a surprising share of 502s.
Fixes for each cause
| Cause | Fix |
|---|---|
| Process down | Restart it and enable automatic restart (Restart=always in systemd, or a process manager like Supervisor or PM2). |
| Wrong upstream | Make fastcgi_pass / proxy_pass match the actual socket or port, then nginx -t && systemctl reload nginx. |
| Pool exhausted | Raise pm.max_children only if you have the RAM. Better: find the slow requests (slow query log, APM) and fix them. |
| Crashes mid-request | Read the app log for the fatal error. Raise memory_limit only after you understand why memory spiked. |
| Headers too large | Increase fastcgi_buffer_size / proxy_buffer_size (e.g. 32k) and trim oversized cookies. |
| CDN can't reach origin | Allow-list the CDN's IP ranges, check the origin IP in the CDN's DNS, and test the origin directly. |
| TLS mismatch | Put a valid certificate on the origin and use "Full (strict)" mode on the CDN. |
| Deploy gaps | Use graceful reloads (systemctl reload php8.3-fpm) or zero-downtime deploys so new workers start before old ones stop. |
If you're a visitor
Refresh after 30 seconds. Then try another browser or network. If the site loads for others but not for you, clear the site's cookies (cause 5 can be cookie-specific). Use the free website checker to see whether it's down for everyone - our guide to checking if a site is down covers the rest.
Catch 502s before your users do
Intermittent 502s are the hardest kind: a pool that fills up for 90 seconds at 2 a.m. never shows up when you test by hand. An external website monitor checks every 30-60 seconds, records the exact status code and error for every failure, and alerts you when failures persist.
Upmonora's AI insights also flag recurring error patterns, such as "5xx errors cluster between 02:00 and 02:15", which usually points straight at a cron job or backup. Start with the free plan.
Frequently asked questions
Is a 502 Bad Gateway my fault or the website's?
Almost always the website's. A 502 is generated by a server (a proxy, load balancer or CDN) that could not get a valid response from the server behind it. Refreshing or trying later is all a visitor can do.
How long does a 502 error last?
It depends on the cause. A restarting app server clears in seconds; a crashed PHP-FPM pool or a failed deploy lasts until someone fixes it. If a 502 lasts more than a minute or two, treat it as an outage.
What is the difference between 502 and 504?
A 502 means the upstream server returned something invalid or closed the connection. A 504 means it did not answer before the proxy gave up waiting. Both mean the proxy is up and the application behind it is not healthy.
Can a 502 error hurt SEO?
A short 502 does not. If Googlebot sees 5xx errors for hours or days, it slows down crawling and can eventually drop affected URLs from the index, so fix long outages quickly.