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

A 502 Bad Gateway error means a server acting as a gateway or proxy, usually Nginx, Apache, a load balancer, or Cloudflare, passed your request to an upstream server and got back an invalid or empty response. The proxy is working. The application behind it is not. Almost every 502 comes down to one of six causes: the app process crashed, it is overloaded, it timed out, the proxy is pointed at the wrong address or socket, a firewall is blocking the connection, or a deploy restarted the backend mid-request. Unlike a 404, a 502 is a server-side fault, and it is yours to fix, not the visitor's.

What the error actually tells you

HTTP splits errors into 4xx, which means the request was wrong, and 5xx, which means the server failed. A 502 sits in the 5xx family and is specific: the machine that answered the browser was not the machine meant to generate the page. It handed the request onward and the answer it got back was garbage, empty, or never arrived in a usable form. That is useful information, because it narrows the problem to the link between your proxy and your application, and rules out DNS, TLS, and the visitor's browser.

You will see it phrased differently depending on who is reporting it: 502 Bad Gateway nginx, 502 Bad Gateway Cloudflare, HTTP Error 502, or a hosting provider's branded error page. The cause is the same in each case, only the identity of the gateway changes.

What causes a 502 Bad Gateway error?

Six causes account for nearly all of them.

How do you fix a 502 Bad Gateway error on Nginx?

Start with the error log, because Nginx tells you exactly which upstream failed and why. Run tail -50 /var/log/nginx/error.log and read the most recent entry. Connection refused means the application process is not running or not listening where you told Nginx to look. No such file or directory pointing at a .sock path means the socket name in your config does not match the one PHP-FPM created. Upstream timed out means the app is alive but too slow. Fix in that order: confirm the backend is running with systemctl status php8.3-fpm or the equivalent for your stack, verify the address in the Nginx upstream or fastcgi_pass line matches what the app actually binds to, then run nginx -t and reload. If the log says timeout, raising proxy_read_timeout or fastcgi_read_timeout masks the symptom, so use it to buy time while you fix the slow query underneath.

How to fix a 502 on Apache

Apache's version usually comes from mod_proxy and the fix follows the same path with different filenames. Check /var/log/apache2/error.log for proxy: error reading status line from remote server or AH01102, which both point at a backend that closed the connection early. Confirm the process behind the ProxyPass directive is up and listening on the port you referenced, make sure mod_proxy and the matching handler module are enabled, then adjust ProxyTimeout only if the log shows a genuine timeout rather than a refused connection.

What does a 502 from Cloudflare mean?

Cloudflare shows two different 502 pages and the distinction matters. If the error page says the problem is with your host's server, Cloudflare reached your origin and got an invalid response back, so the fault is on your infrastructure and you troubleshoot it exactly as above. If the page indicates the issue is on Cloudflare's side, the proxy layer itself failed and you should check Cloudflare's own status page before touching your server. The fastest way to tell them apart is to bypass the proxy: request your origin IP directly with a Host header and see whether it serves the page. If the origin answers cleanly, the problem is between Cloudflare and you, often a firewall rule that stopped allowing Cloudflare's IP ranges.

Is a 502 error the visitor's fault?

No. A 502 is generated on the server side and there is nothing a visitor can do to fix it. Refreshing sometimes appears to work, but only because the underlying problem was intermittent, such as a backend restarting or a worker pool briefly exhausted. Clearing the browser cache, changing DNS, or trying a different browser will not resolve a genuine 502. If you are the visitor and the error persists, the site is broken and the owner has to fix it.

Why intermittent 502s are the dangerous ones

A total outage gets noticed within minutes because everything breaks at once. The 502 that appears on 2 percent of requests during peak hours is far more expensive, because it fails silently on real customers while every manual check you run returns a healthy 200. This is the classic pattern of a worker pool that is one process short of the traffic it gets, or a database connection limit reached only under load. Nobody reports it, your dashboards look fine, and the checkouts that failed just never come back.

Catching that pattern needs continuous checking rather than spot checks. A monitor hitting the endpoint every minute from several regions builds a failure rate you can see, and a run of 502s across regions confirms the problem is your application rather than one network path. It is worth setting the check to treat any 5xx as an incident and routing the confirmed alerts to a channel someone watches, since a single 502 during a deploy is noise but five in ten minutes is a real problem. Our guide to which HTTP status codes should trigger alerts covers where to draw that line for each code.

How to prevent 502 errors

Most 502s are capacity or lifecycle problems, so prevention is mostly about headroom and graceful restarts.

1. Size your worker pool for peak, not average. PHP-FPM's pm.max_children, Gunicorn workers, and Node cluster sizes should have room above your busiest hour.
2. Use graceful reloads on deploy. Reload rather than restart so in-flight requests finish, which removes the burst of 502s that follows every release.
3. Fix the slow queries. Timeouts that show as 502 or 504 Gateway Timeout almost always trace back to one unindexed query or one slow third-party call.
4. Set sensible timeouts on outbound calls. An external API that hangs for 60 seconds will exhaust your workers and take the whole site down with it.
5. Keep memory limits honest. An out-of-memory kill on the app process presents as a 502 with nothing obviously wrong in the application log.
6. Monitor the endpoint continuously so you learn about the intermittent 2 percent before it becomes the total outage.

If your 502s cluster around automated traffic rather than real users, the cause is often a scraper or integration hammering an expensive endpoint faster than your workers can clear it. Rate limit that client, or move the job onto an extraction service that handles retries and backoff so your origin is not absorbing the retry storm.

The short version

A 502 Bad Gateway means your proxy is fine and your application is not. Read the proxy error log first, because it names the failing upstream and the reason: refused, missing socket, or timed out. Confirm the backend process is running, confirm the proxy points at the right address, then fix the slow path if it is a timeout. Restarting the app clears most 502s but does not stop the next one, so treat the restart as triage and the capacity work as the fix. And put continuous checks with keyword and status code assertions in front of it, because the 502 that matters most is the one only some of your customers see. Setting that up takes a few minutes with our guide to monitoring a website.