502 Bad Gateway Nginx: How to Fix It (Step-by-Step)

Your site loaded fine an hour ago. Now every URL throws a 502 Bad Gateway Nginx error, and your inbox is filling up. Take a breath — this one is almost always fixable in minutes once you know the order to check things.

A 502 means Nginx reached out to an upstream process (usually PHP-FPM) and got a broken or empty reply. The web server itself is running. Something sitting behind it is not.

Below is the exact sequence we walk on a live server when this hits: PHP-FPM first, then the upstream socket, then the logs. Action first — theory can wait until your site is back.

Quick Answer: A 502 Bad Gateway on Nginx means the upstream service Nginx proxies to — normally PHP-FPM or a Node/app backend — returned an invalid or empty response. Fix it by restarting PHP-FPM (sudo systemctl restart php8.3-fpm), confirming the fastcgi_pass socket matches the pool's listen value, and reading /var/log/nginx/error.log for the precise upstream failure.

Most 502s trace back to four culprits, and a managed host like Hostaccent will often catch and restart a dead PHP-FPM pool before you even notice. On an unmanaged box, that job is yours — so let's make it quick.

What a 502 Bad Gateway Nginx Error Actually Means

Nginx rarely generates its own errors. When it serves a PHP site, it acts as a reverse proxy: it takes the request, hands it to PHP-FPM over a socket, waits for the response, and passes it back to the browser.

A 502 status code is Nginx saying: "I asked my upstream, and what came back made no sense." Empty reply, closed connection, malformed headers — any of these trigger it.

That's actually good news. Your DNS resolves, Nginx is listening, and your SSL is valid. The Nginx PHP-FPM 502 is, at heart, a communication breakdown between two processes — which narrows the search dramatically.

Contrast this with a 504 (gateway timeout), where the upstream is alive but too slow to answer. A 502 usually means the upstream is dead, misconfigured, or unreachable — not merely lagging.

Here's a fast way to tell the three apart, because they send you down different paths. A 500 is the application itself erroring (a PHP fatal, a broken plugin) — Nginx got a valid response, it just carried an error. A 502 is Nginx getting garbage or nothing back from the upstream. A 504 is Nginx waiting past its timeout with no answer at all. Read the wrong one and you'll spend 30 minutes tuning timeouts when your real problem is a stopped service.

As of 2026, most stacks run PHP 8.1–8.3, so adjust the version numbers in the commands below to match your install before you paste anything.

Insider Insight: If you see 502s on some page loads but not others, the upstream isn't fully down — it's usually PHP-FPM worker exhaustion under load. Random 502s that vanish when traffic drops point at pool sizing, not a crashed service.

The Causes, Ranked by How Often We See Them

In the support tickets our team handles, 502s cluster around a short list. Here's the honest frequency order, not a textbook one:

1. PHP-FPM is down or crashed — the single most common cause on PHP and WordPress servers.
2. PHP-FPM worker exhaustion — pm.max_children set too low, so every worker is busy and Nginx can't get a slot.
3. Socket or port mismatch — fastcgi_pass in the Nginx vhost points somewhere PHP-FPM isn't listening.
4. Upstream timeout or memory kill — a heavy request or the OOM killer takes the PHP process down mid-request.
5. Bad response headers — the upstream sends a header block too big for Nginx's buffers.

The fixes below follow this order. Start at the top and stop the moment your site returns.

Step-by-Step: How to Fix a 502 Bad Gateway on Nginx

Work these in sequence. After each fix, reload the page in a private window (to skip cache) before moving on. This is the 502 Bad Gateway fix flow we use on real incidents.

Step 1 — Check whether PHP-FPM is running

Nine times out of ten, this is it. Check the service:

bashCopy
sudo systemctl status php8.3-fpm

If it shows inactive (dead) or failed, start it:

bashCopy
sudo systemctl restart php8.3-fpm

Adjust the version (php8.3-fpm, php8.2-fpm, etc.) to match your install. If the service refuses to start, that's a config error — jump to Step 4 and read the logs.

Pro Tip: A PHP-FPM pool that dies right after boot is usually a fatal syntax error in a .conf file. Run sudo php-fpm8.3 -t to test the pool config before restarting — it names the exact file and line that broke.

Step 2 — Confirm the socket path matches

Nginx and PHP-FPM have to agree on where they talk. Open your vhost:

bashCopy
sudo nano /etc/nginx/sites-available/yourdomain.conf

Find the fastcgi_pass line. It looks like this:

nginxCopy
fastcgi_pass unix:/run/php/php8.3-fpm.sock;

Now check what PHP-FPM is actually listening on:

bashCopy
grep listen /etc/php/8.3/fpm/pool.d/www.conf

If the two don't match — say Nginx points at php8.2 but you upgraded to php8.3 — that mismatch alone throws a 502 on every request. Fix the path, test with sudo nginx -t, then run sudo systemctl reload nginx. The official Nginx FastCGI documentation covers the directive in full.

Step 3 — Raise PHP-FPM workers if 502s appear under load

If the site works at 2am but throws 502s during your busy hours, you're out of workers. Edit the pool:

bashCopy
sudo nano /etc/php/8.3/fpm/pool.d/www.conf

The defaults are conservative — often pm.max_children = 5, which chokes fast. On a box with 4GB RAM and typical WordPress usage, 20–30 children is a saner starting point:

iniCopy
pm = dynamic
pm.max_children = 25
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10

Restart PHP-FPM. Read the PHP-FPM configuration docs for how each value interacts — set max_children too high and you'll trade 502s for out-of-memory kills. Our Nginx + PHP-FPM Performance Tuning on Linux VPS guide has the full sizing math.

Step 4 — Read the Nginx error log (the step people skip)

The log tells you exactly what broke. Watch it live, then reload the failing page:

bashCopy
sudo tail -f /var/log/nginx/error.log

Match what you see against these upstream connect error patterns:

• connect() failed (111: Connection refused) while connecting to upstream → PHP-FPM is down (back to Step 1).
• no live upstreams while connecting to upstream → your upstream {} block has no reachable backend.
• upstream sent too big header → a buffer problem (Step 5).
• recv() failed (104) mid-request → the PHP worker was killed, often by the OOM killer.

For that last one, confirm memory pressure:

bashCopy
sudo dmesg | grep -i 'killed process'

If PHP-FPM is being OOM-killed, you either need more RAM or a lower pm.max_children. At Hostaccent, on our Nginx → Apache + NVMe stack, the typical bottleneck here is a plugin leaking memory on a 512MB container — not the web server at all.

Don't stop at the Nginx log, either. PHP-FPM keeps its own record, and it often names the failing script or the exact reason a worker exited:

bashCopy
sudo tail -f /var/log/php8.3-fpm.log

A line reading server reached pm.max_children setting is a dead giveaway that you're out of workers (Step 3). A WARNING: child exited on signal 9 means the OOM killer struck. Between these two logs, roughly 90% of 502s explain themselves within a minute — no guesswork needed.

Step 5 — Fix "upstream sent too big header"

Some apps (heavy WordPress setups, certain redirect and security plugins) send oversized headers that overflow Nginx's default buffers. Add these inside the location block that runs PHP:

nginxCopy
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;

For proxied apps (Node, etc.), the equivalents are proxy_buffers and proxy_buffer_size. Test and reload Nginx after editing. In our experience, this clears the intermittent 502-on-login pattern that otherwise looks completely random.

How to Confirm the Fix and Stop It Coming Back

Once the site loads, don't just walk away. Confirm the fix held and harden against a repeat.

Verify the response code from the command line so a cached page doesn't fool you:

bashCopy
curl -I https://yourdomain.com

A clean HTTP/2 200 means you're genuinely back. If Cloudflare sits in front, purge its cache too — Cloudflare's explanation of the 502 error covers how the edge can cache a bad response and keep serving it after your origin recovers.

One trap to avoid: testing from your own browser, which may be holding a cached error page or a stale DNS record. Run the curl -I check from a second machine, or add -H "Cache-Control: no-cache" to be certain you're hitting live origin. A "fixed" site that still 502s for real visitors is worse than a site you know is down — at least the latter tells you the truth.

To keep the 502 error off your website for good:

• Set PHP-FPM to auto-restart. Add Restart=on-failure to the systemd unit so a crash self-heals in seconds instead of staying down for hours.
• Right-size your workers so peak traffic never starves the pool. If you're regularly maxing out, it's a capacity signal — see How to Fix High TTFB in WordPress (2026 Guide) for the wider performance picture.
• Monitor uptime with an external check that alerts on the first 502, not the fiftieth. Aim for 99.9% uptime and you'll catch pool crashes within seconds.
• Keep backups current so rolling back a bad config takes seconds — our Linux VPS Backup Automation with Rsync + Cron walkthrough automates it.

Pro Tip: Add a tiny location = /healthz endpoint that returns 200 straight from PHP, and point your monitor at it. If that path 502s, PHP-FPM is the problem; if only your app URLs 502, it's application-level. That one split saves 20 minutes of guessing per incident.

A frequent misconfiguration we see when migrating customer sites is a stale fastcgi_pass left over from an old PHP version after an upgrade — everything looks fine until the first request hits a socket that no longer exists. Locking down your Linux VPS Security Baseline (Ubuntu 24.04) in 30 Min is worth doing while you're in the config, and adding Nginx Rate Limiting: Basic DDoS & Bot Protection helps too, since a chunk of "random" 502s are actually bots hammering a login endpoint until the pool tips over.

Struggling With Recurring 502s? Let the Stack Handle It

If you've worked through every step and the 502 Bad Gateway Nginx error keeps coming back — or you'd simply rather not babysit PHP-FPM at 2am — a managed VPS moves that burden off your plate. Hostaccent's VPS Hosting runs the same Cloudflare → Nginx → Apache + NVMe stack described above, tuned so worker pools and auto-restart are handled for you. The Basic plan starts at $7.99/mo (renews at $7.99/mo) with UK-based human support that actually reads your error logs.

Honest limitation: if your 502s come from one plugin leaking memory, no host — Hostaccent included — magically "fixes" that for you; you'll still need to find the culprit. But a right-sized, monitored server means a crashed pool restarts itself in seconds instead of taking your site down for an afternoon. As a UK-registered company operating since 2012, we've handled this exact incident thousands of times.

Frequently Asked Questions

What does a 502 Bad Gateway Nginx error mean?

It means Nginx, acting as a reverse proxy, sent a request to an upstream service (usually PHP-FPM) and received an invalid or empty response. Nginx itself is running fine — the failure is in the backend it depends on, which is why the fix almost always starts with PHP-FPM.

How do I fix a 502 error without server access?

Without SSH, your options are limited but real. Clear your CDN or Cloudflare cache, wait 2–3 minutes in case the upstream is restarting, and check your host's status page. If you're on shared or managed hosting, open a ticket immediately — a dead PHP pool is a server-side fix only your provider can apply.

Can a 502 Bad Gateway be caused by Cloudflare?

Yes, indirectly. Cloudflare returns a 502 when your origin server gives it a bad response, and it can keep serving that cached 502 even after the origin recovers. Fix the origin first, then purge the Cloudflare cache and confirm with a direct curl to your server.

Why does my site show a 502 only under heavy traffic?

That's the classic PHP-FPM worker-exhaustion pattern. Your pm.max_children is too low, so during traffic spikes every worker is busy and Nginx can't get a response. Raise the worker count (within your RAM budget) and the load-triggered 502s disappear.

Does restarting the whole server fix a 502?

Sometimes — but it's a blunt instrument. A reboot restarts PHP-FPM, which resolves the most common cause, so the site returns. The problem is you learn nothing about why it crashed, so it recurs. Restarting only php8.3-fpm is faster and tells you far more.

Is a 502 error bad for SEO?

A brief 502 won't hurt rankings — Googlebot simply retries later. Sustained 502s over hours or days are the real risk: repeated failed crawls can drop pages from the index. Fast recovery matters more than any single blip, which is one reason we build auto-restart into every Hostaccent server.