How to Fix a 502 Bad Gateway Error
A 502 Bad Gateway means the proxy — Nginx, Apache or a CDN — got an invalid or empty reply from the upstream app. Reload once, then restart PHP-FPM, check disk and RAM, and read the gateway error log: connection refused, timeout or a bad socket each point to a different fix.
For anyone staring at a 502 in India: what the code means, the checks in order, and the exact log line that names the fix.
knowledge
- Read time
- 5 min
- Sections
- 6
- Updated
- 14 Nov 2026
- Written by
- WebJi® team
Last editorial update: 15 November 2026.
What does a 502 Bad Gateway actually mean?
A 502 Bad Gateway means the proxy — Nginx, Apache with mod_proxy, a load balancer or a CDN — was itself running but received an invalid response, or no HTTP message at all, from the upstream application it called. The visitor's click did not fail; the app behind the gateway did. When the middle box gets no valid reply to relay, it answers with 502 on the app's behalf.
The chain matters because the fix is always at one specific link. Browser → proxy → PHP-FPM, Node or Python app is the typical shape: the proxy holds the door, the upstream builds the page. Dead upstream, wrong socket, or a reply the proxy cannot parse — each is a 502 with a different cure. Use the status code, not the branded error page, to pick your next step:
| Code | What the gateway is saying | Where to look |
|---|---|---|
| 502 Bad Gateway | Proxy got an invalid or empty reply from upstream | App process, socket or port, FastCGI buffers |
| 504 Gateway Timeout | Proxy waited; the upstream did not finish | Slow PHP, a hung query, the read timer |
| 503 Service Unavailable | Server is up but will not take the request now | Entry processes, maintenance mode, overload |
| 500 Internal Server Error | The app threw while building the page | .htaccess, a plugin, a PHP fatal |
| 403 Forbidden | A rule refused this visitor or file | Permissions, ModSecurity, a deny rule |
- The proxy usually survives. It is the upstream reply that failed, so restarting the web server is rarely the fix.
- Connection refused, a bad socket and an oversized header are 502 work.
- A pure wait is a 504 — follow the timeout guide instead of enlarging buffers.
What should you check first when a 502 appears?
Work the checks in order and stop when the URL returns 200: reload once, rule out your own browser and network, then look at the origin — the gateway error log decides the rest. A second failure means read the log, not reload again.
- Reload the URL. A single blip clears on its own; if the 502 returns instantly, continue.
- Try a private window or mobile data. If that works, the fault is a cached copy, an extension or a VPN on your device, not the server.
- If every network fails, the origin is sick. On a VPS, open the gateway error log, then restart the app service it points to.
- On WebJi® shared or cPanel hosting there is no panel button that restarts the host PHP-FPM. Email support@webji.services with the exact URL and the time — support answers 24/7 in Hindi and English, average first reply under 60 minutes. The office phone is not a support line.
- Check disk and memory with
df -handfree -m. A full disk or an out-of-memory kill produces 502s even when no config changed.
The log line you find picks the next section: "connection refused" is the PHP-FPM case, a timeout belongs to the 504 guide, and "too big header" is the buffer case below.
Why does PHP-FPM cause a 502 exactly when the site gets busy?
A 502 that appears only under load usually means every PHP-FPM child is occupied — each request holds one child until PHP finishes, so when the pool is full, the proxy fails the new request on the spot. The cure is an honest pool size, not an optimistic one.
On a VPS running PHP 8.3 the pool file is /etc/php/8.3/fpm/pool.d/www.conf; the settings that matter are pm (dynamic, static or ondemand) and pm.max_children. The ceiling is the RAM you can genuinely give PHP divided by the average process size:
ps --no-headers -o rss -C php-fpm8.3 # average child RSS, in KB
A typical WordPress child runs 50–100 MB. On a 2 GB server with about 600 MB spare for PHP and a 75 MB average, pm.max_children = 8 is the honest ceiling — roughly 600 ÷ 75. Set it higher than memory allows and the kernel's OOM killer starts removing workers, which looks like random 502s. Apply the change with systemctl restart php8.3-fpm (substitute the installed version, such as php8.2-fpm).
On a WebJi® shared account this file is not yours to edit; the same symptom there is an entry-process limit, and support can read that graph with you.
Which Nginx log line matches which 502 fix?
Open /var/log/nginx/error.log, read the phrase on the line, change the single directive it names, run nginx -t, reload Nginx, and retest the URL in a private window. One log line, one change — stacking guesses is how a 502 becomes an outage.
| Log phrase | What failed | What to change |
|---|---|---|
connect() failed (111: Connection refused) | Nothing is listening on the proxy target | Start PHP-FPM or the app; confirm the port or socket |
Permission denied | The socket exists but the proxy user cannot use it | Match the pool's listen owner to the Nginx user |
upstream timed out | The app accepted the connection and never finished | Treat it as a 504: shorten the work, or nudge fastcgi_read_timeout (default 60s) |
upstream sent too big header | Response headers exceeded the FastCGI header buffer (default 4k/8k) | Raise fastcgi_buffer_size, then fastcgi_buffers if needed |
no live upstreams | Every backend in the group failed its checks | Restore one healthy app process before tuning anything |
A refused connection is not fixed by a longer timer, and a timeout is not fixed by a bigger buffer. Raise proxy_read_timeout or fastcgi_read_timeout only when the log actually says the upstream timed out, and only in small steps — an app that needs minutes should have that work moved off the web request. Apache with mod_proxy fails the same two ways: ProxyPass aimed at the wrong port, or ProxyTimeout shorter than the app. Match the port, then reload.
What does a 502 from Cloudflare tell you?
A Cloudflare-branded 502 means Cloudflare reached your origin and did not get a valid response — so you test the origin directly and let the result split the problem in two.
curl -I --resolve yourdomain.com:443:ORIGIN_IP https://yourdomain.com
A 200 straight from the origin alongside a 502 through Cloudflare points at the connection between edge and origin; a 502 from the origin itself means the app behind your web server is still the fault. The neighbouring Cloudflare codes narrow it further: 521 means the origin refused the connection or is offline, 522 means the connection timed out — an overloaded origin or a firewall dropping edge traffic — and 525 means the TCP connection succeeded but the TLS handshake failed, cured by a valid origin certificate with Full (strict) mode. Fix the origin and the Cloudflare 502 leaves with it; a cached page at the edge can meanwhile look fine while uncached URLs fail.
How do you stop the next 502 from surprising you?
Leave real RAM headroom so pm.max_children fits without swap, and watch the gateway error log instead of only the homepage. A pool sized to the last byte of memory fails the moment a backup job or a search crawl starts alongside normal traffic.
- Size the pool from measured RSS, not from a tutorial's default number.
- Alert on log patterns: a rising count of
connect() failedorno live upstreamsis the 502 starting, before visitors see it. - Run a health URL on your VPS that returns 200 only when PHP and the database both answer — it shows the upstream dying before Nginx does.
- Note what changed last. A plugin, a PHP version bump or a deploy is the usual trigger; tell support that when you write in.
WebJi® states a 99.9% uptime target, and a 502 on your own account is still diagnosed from your log line. On shared hosting, where you have no SSH, email support@webji.services the moment the same URL returns 502 twice.
Frequently asked questions
Is a 502 error my fault or my host's?
If a private window and a second network still fail, the origin is at fault — your app, the proxy config, or the host's PHP pool. If only your browser fails, clear the cache or pause the VPN. Registering a new domain name fixes neither.
How do I restart PHP-FPM?
On a VPS, run systemctl restart php8.3-fpm, substituting the version your pool actually runs (php8.2-fpm, and so on). On WebJi® shared or cPanel hosting the pool is managed for you and there is no customer-side restart button — email support@webji.services with the URL and time instead.
Why does the 502 appear only during high traffic?
Every busy PHP request holds one child. When pm.max_children is exhausted, new requests fail at the proxy. Size the ceiling as usable RAM divided by the average process size, measured with ps -o rss -C php-fpm. Setting it higher than memory allows just moves the failure to the OOM killer.
Is a 502 Bad Gateway permanent?
No. It lasts only while the upstream is down, pointed at the wrong socket, or out of workers. A single reload often clears a blip; a 502 on every URL stays until the log line behind it is fixed.
Does a 502 mean the site was hacked?
Not by itself — it means the proxy and the app stopped talking. Read the error log and your recent plugin or deploy changes first. Treat it as a possible compromise only when the log or file changes support that.
Last editorial update: 15 November 2026.
Ready to get started with WebJi®?
Join 12,000+ businesses across India and overseas. INR pricing, 18% GST shown before payment and 24/7 email support in Hindi and English — average first reply under 60 minutes.