Your site was fine an hour ago. Now every page says 502 Bad Gateway.
Short answer: the server in front of your site, usually Nginx or Cloudflare, got a broken reply from the app behind it. On WordPress that app is PHP-FPM. Restart it, or fix what crashed it, and the error clears.
We broke a test server six ways to see what each 502 error leaves behind.
The log line tells you the fix. Most guides never show it to you.
What does 502 Bad Gateway mean?
A 502 Bad Gateway means a gateway or proxy got an invalid response from the server behind it. That’s how RFC 9110, the HTTP standard, defines it.
So the error has two parties, and neither of them is your browser.
- The gateway takes your request first: Nginx, Apache acting as a proxy, a load balancer or a CDN.
- The upstream builds the page: PHP-FPM for WordPress, a Node or Python app, or your origin server when a CDN sits in front.
- The 502 is the gateway saying the upstream refused the connection, hung up halfway or sent something that wasn’t valid HTTP.
That’s why a 502 is almost never fixed on the visitor’s side. The page you see comes from a working server that is reporting a broken one behind it. If you run a hosted site, our guide to how web hosting works shows where each of these layers lives.
Seeing a 502 on someone else’s site? Try these three things
If it isn’t your site, you have very little to fix. Do these in order and stop when the page loads.
- Wait 60 seconds and reload. Many 502s last only while a server restarts or a deploy finishes.
- Open it on mobile data or another network. If it loads there, a proxy, VPN or office firewall between you and the site is the gateway that’s failing.
- Turn off your VPN or proxy. A proxy is a gateway too, and a dead exit server returns its own 502. Our common proxy errors guide covers that case.
Clearing your cache or cookies rarely helps with a 502, with one exception we’ll get to: oversized cookies.
We broke an Nginx server six ways on purpose
In November 2026 we set up Nginx 1.26 as a reverse proxy on our Linux test box, with small test apps behind it. Then we broke the apps one at a time and read what Nginx wrote to its error log.
It’s a lab, not a production WordPress site. But the log lines are the same ones you’ll find on a real server, and they’re the fastest route to the fix.
| What we broke | What the visitor got | What Nginx logged |
|---|---|---|
| App not running | 502 in under 1 ms | connect() failed (111: Connection refused) |
| App hung up mid-request | 502 | upstream prematurely closed connection |
| App sent a 6,000-character cookie | 502 | upstream sent too big header |
| PHP socket path wrong | 502 | connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory) |
| App took 10 seconds to answer | 504 after exactly 3 s | upstream timed out (110: Connection timed out) |
| One of two app servers down | 200 on 10 of 10 requests | upstream server temporarily disabled |
Two patterns jump out. A 502 usually arrives instantly, because the gateway knew right away the reply was bad. A slow app gives you a 504 instead, timed to the gateway’s limit.
And look at the last row. With a second app server in the pool, Nginx quietly retried and every visitor got the page.
Here’s what Nginx sends back. The whole error page is 157 bytes:
HTTP/1.1 502 Bad Gateway
Server: nginx/1.26.3
Content-Type: text/html
Content-Length: 157How to fix a 502 Bad Gateway on your own site
Start with the error log, not with guesses. On most Nginx servers it lives at /var/log/nginx/error.log, and the newest lines sit at the bottom.
sudo tail -n 20 /var/log/nginx/error.log
# then check the app behind it, for WordPress usually:
systemctl status php8.3-fpmMatch the log line to our table. Then apply its fix:
Fix a 502 from the log line up
Each step matches one error Nginx writes when the upstream fails.
-
Step 1 of 5
Connection refused: start the app
PHP-FPM or your app isn’t running. Restart it with systemctl restart php8.3-fpm (use your version), then check its own log for why it stopped. Out-of-memory kills are the usual culprit.
-
Step 2 of 5
No such file or directory: fix the socket path
Nginx is pointing at a PHP socket that doesn’t exist, often right after a PHP version upgrade. Make fastcgi_pass match the listen line in your PHP-FPM pool config, then reload Nginx.
-
Step 3 of 5
Prematurely closed: find what crashed the worker
The PHP worker died mid-request. Check the PHP error log and the WordPress debug log for a fatal error, then disable the plugin named in it.
-
Step 4 of 5
Too big header: raise the buffer
The app sent headers bigger than Nginx’s 4 KB default buffer. Set proxy_buffer_size 16k and proxy_buffers 8 16k (fastcgi_buffer_size for PHP), reload, and test again.
-
Step 5 of 5
Behind Cloudflare: check whose error page it is
A Cloudflare-branded 502 page means your origin server sent the error, so fix the server. A plain, unbranded page means it came from Cloudflare itself.
That buffer fix is the one we proved on the box. The same 6,000-character cookie that broke the page loaded with a 200 OK once we raised proxy_buffer_size to 16k.
Real-world tip: if a 502 appears only after you log in, or only in wp-admin, suspect the header size first. Logged-in sessions carry bigger cookies, and a page builder or security plugin can push them past 4 KB.
Why WordPress sites throw 502s more than most
A WordPress page isn’t a file Nginx can hand over. Every uncached request goes to PHP-FPM, a pool of PHP workers, and that’s the link that breaks.
Three things stress it. A plugin with a fatal error kills its worker mid-page. A traffic spike or a heavy WooCommerce job uses up every worker. And a cheap plan’s memory limit lets the server kill PHP outright when it runs short.
Caching cuts the load hard, because a cached page never reaches PHP at all. That’s one reason a caching plugin like WP Rocket pays off on busy shared plans.
Security plugins and firewalls can also block the connection between the CDN and your server, which looks like a 502 to everyone outside. Our list of WordPress security plugins covers which ones add their own firewall layer.
502, 503 or 504: which one are you looking at?
All three come from a gateway or a struggling server, but each one points to a different problem.
| Code | What happened | Where to look first |
|---|---|---|
| 502 Bad Gateway | The upstream refused, crashed or sent a broken reply | Error log, then the app or PHP-FPM status |
| 503 Service Unavailable | The server says it can’t take requests right now | Maintenance mode, rate limits, overloaded workers |
| 504 Gateway Timeout | The upstream was too slow to answer | Slow queries, long imports, timeout settings |
Our lab showed the difference in seconds. The broken apps failed with a 502 in under 2 milliseconds, while the slow one hit our 3-second limit and came back as a 504.
When the 502s keep coming back, look at your hosting
One 502 is a bug. A 502 every week is a capacity problem.
If your log keeps showing refused connections or killed workers at busy times, your plan doesn’t have enough PHP workers or memory for your traffic. You can tune the pool on a VPS, but on shared hosting you’re stuck with the host’s limits.
Ask your host how many PHP workers your plan allows before you blame WordPress. Our checklist for choosing a web hosting service puts that question near the top.
That’s the point where an upgrade beats another week of restarts. A managed host like Pressable or a bigger Hostinger plan gives you more workers and someone who reads the logs for you. Our managed vs shared WordPress hosting comparison runs the numbers on when that’s worth it.
Prefer to stay in control? Our roundup of VPS hosting services covers plans where you set the worker count yourself.
Disclosure: some links above are affiliate links. We earn a commission if you buy through them, at no extra cost to you.
Frequently Asked Questions
Does a 502 Bad Gateway hurt my SEO?
A short one doesn’t. Google treats 5xx errors as temporary and slows its crawling while they last. If pages keep returning server errors for days, Google starts dropping them from its index, so fix repeat 502s quickly.
Can a WordPress plugin cause a 502 error?
Yes. A plugin with a fatal PHP error can crash the worker building the page. Nginx then reports a 502. Rename the plugin’s folder over SFTP to switch it off and test again.
Why do I get a 502 only when saving a post or uploading?
Saving and uploading are the heaviest requests WordPress makes. A large upload or a slow plugin hook can crash or exhaust a PHP worker. Check the PHP error log at the exact time you saved.
Is a 502 Bad Gateway caused by my internet?
Rarely. The error is sent by a server that’s working. The exception is a proxy, VPN or company firewall you route through, because that’s a gateway too. If the site loads on mobile data, the problem is on your network.
How long does a 502 Bad Gateway usually last?
A 502 caused by a restart or a deploy usually clears within a minute or two. One caused by a crashed service, a wrong socket path or full workers lasts until someone fixes the server, so don’t wait it out.
Why does my site work with Cloudflare paused but show 502 with it on?
Cloudflare connects to your server differently than your browser does. Your firewall may block Cloudflare’s IP ranges, or the server may send broken compressed responses. Cloudflare’s docs name broken gzip as one cause of unbranded 502 pages.
Should I contact my host about a 502?
Yes, if you’re on shared or managed hosting and can’t see the server logs. Send the exact time, the URL and whether it happens on every page. That’s enough for support to find the matching error log line.
The bottom line
A 502 Bad Gateway means the gateway worked and the app behind it didn’t. Visitors can only reload, switch networks or drop their VPN.
Site owners should open the Nginx error log first. Then match the line to its fix: start PHP-FPM, correct the socket, find the crashing plugin or raise the header buffer. If the 502 error returns every busy week, your plan has run out of room, and that’s a hosting decision.
Next step: run tail -n 20 on your error log the next time it happens, before you restart anything. The restart clears the evidence.
