Server Errors

502 Bad Gateway

Intermediate Risk: medium

Last reviewed July 18, 2026

Hosting access often needed Database access usually not needed

Direct answer

502

A 502 Bad Gateway means a reverse proxy or load balancer could not get a valid response from the upstream (often PHP-FPM, Apache, or your origin) — restart or repair the backend worker, then check timeouts and overload rather than chasing a WordPress PHP fatal alone.

HTTP 502 is a gateway failure: something in front of your app reached the edge, but the next hop returned nothing useful or crashed mid-response. On WordPress hosts that usually means nginx or a CDN talking to a dead, overloaded, or timed-out PHP-FPM or Apache process. Confirm the status code, check upstream health, then isolate resource and config causes before you start renaming plugins at random.

Intermediate

What the error means

A reverse proxy (nginx, Apache as a front, Cloudflare, or a host load balancer) sits between visitors and your application. When that proxy cannot obtain a complete, valid response from the upstream — PHP-FPM down, worker crash, connection refused, or a timeout while waiting — it returns 502 Bad Gateway. That is different from a 500 (the app or server config errored while handling a connected request), a 503 (the server is intentionally unavailable or overloaded and saying “try later”), and Cloudflare 522 (Cloudflare could not complete a TCP handshake to the origin in time). On WordPress, 502 often looks like a host-branded error page with no PHP fatal in the application log until you check PHP-FPM or proxy error logs.

Common symptoms

Visitors see “502 Bad Gateway,” “Bad Gateway,” or a host/CDN-branded 502 page
DevTools Network shows status 502 (not 500, 503, or Cloudflare 522)
Site may load intermittently — some requests succeed, others 502 under load
wp-admin and the front end both fail, or only heavy pages (checkout, builders) 502
Proxy or PHP-FPM logs show upstream timed out, connection reset, or no live upstreams
Error started after a PHP restart, deploy, traffic spike, or host maintenance
Direct origin IP or “DNS only” tests behave differently than traffic through Cloudflare

Most likely causes

01 PHP-FPM (or the PHP handler) stopped, crashed, or ran out of workers
02 Upstream process crash or segfault while generating the response
03 Proxy or load-balancer timeout shorter than a slow WordPress/PHP request
04 Origin overload — CPU, memory, or entry processes exhausted so workers die
05 Misconfigured upstream socket/port after a PHP or nginx config change
06 CDN or WAF in front returning 502 when the origin closes the connection early
07 Database hang causing PHP workers to pile up until the gateway gives up

What changed before the problem started

PHP version change, PHP-FPM restart, or host “PHP handler” switch
Traffic spike, bot wave, or marketing campaign hitting the origin
Plugin or theme update that made requests much slower or fatal under load
nginx/Apache proxy timeout or upstream block edited by host or you
Cloudflare proxy (orange cloud) enabled or firewall rule tightened
Server reboot, migration, or resource plan downgrade

Troubleshooting steps

01
Confirm 502 in DevTools and note whether Cloudflare is involved
Open the failing URL → DevTools → Network. Confirm the HTML document status is 502. If you see a Cloudflare-branded page with Ray ID, note whether the code is 502 vs 522 — 522 is origin connection timeout and follows a different playbook. Success signal: you know the exact status and whether the edge or origin is labeling the failure.
02
Check host status and PHP / error logs at the failure timestamp
In cPanel, Plesk, Cloudways, or your host dashboard, open today’s error, nginx, or PHP-FPM log. Search for “upstream,” “connect() failed,” “Connection refused,” “timed out,” or “Primary script unknown.” Also check the host status page for outages. Success signal: you can tell whether PHP-FPM was down, timed out, or the whole machine was degraded.
03
Restart PHP-FPM or the host “PHP” / app service if the panel allows it
Many managed hosts expose “Restart PHP,” “Reload PHP-FPM,” or a one-click app restart. Use that once after noting the time. Reload the site in a private window. Success signal: 502 clears immediately after restart points to a dead or stuck worker pool — then investigate why it died so it does not return.
04
Reduce load: pause heavy cron, disable caching rebuilds, and lower concurrency
If the site flaps between 200 and 502 under traffic, temporarily disable nonessential cron/heartbeat plugins, pause large import jobs, and avoid hammering Refresh. Ask the host whether entry processes or PHP workers are at the plan limit. Success signal: 502 rate drops when concurrency falls, confirming overload rather than a permanent config break.
05
Isolate a crashing plugin only after upstream is answering again
Once you get intermittent 200s, rename `wp-content/plugins` to `plugins.disabled` via SFTP or File Manager if logs show PHP crashes tied to a plugin path. Bring plugins back one at a time. Do not start plugin isolation while PHP-FPM itself is completely down — that will not help a dead socket. Success signal: stable 200s with plugins off, then a named plugin that recreates 502 or fatals.
06
Test origin vs CDN path
If Cloudflare (or another CDN) is proxied, briefly set the record to DNS-only or test the origin hostname/IP the host provides. If origin is fine but the proxied hostname 502s, open a ticket with the CDN and host about upstream health and timeouts. Success signal: you know whether the gateway failure is at the edge or on the origin stack.

Confirm 502 in DevTools and note whether Cloudflare is involved

Open the failing URL → DevTools → Network. Confirm the HTML document status is 502. If you see a Cloudflare-branded page with Ray ID, note whether the code is 502 vs 522 — 522 is origin connection timeout and follows a different playbook. Success signal: you know the exact status and whether the edge or origin is labeling the failure.

Check host status and PHP / error logs at the failure timestamp

In cPanel, Plesk, Cloudways, or your host dashboard, open today’s error, nginx, or PHP-FPM log. Search for “upstream,” “connect() failed,” “Connection refused,” “timed out,” or “Primary script unknown.” Also check the host status page for outages. Success signal: you can tell whether PHP-FPM was down, timed out, or the whole machine was degraded.

Restart PHP-FPM or the host “PHP” / app service if the panel allows it

Many managed hosts expose “Restart PHP,” “Reload PHP-FPM,” or a one-click app restart. Use that once after noting the time. Reload the site in a private window. Success signal: 502 clears immediately after restart points to a dead or stuck worker pool — then investigate why it died so it does not return.

Reduce load: pause heavy cron, disable caching rebuilds, and lower concurrency

If the site flaps between 200 and 502 under traffic, temporarily disable nonessential cron/heartbeat plugins, pause large import jobs, and avoid hammering Refresh. Ask the host whether entry processes or PHP workers are at the plan limit. Success signal: 502 rate drops when concurrency falls, confirming overload rather than a permanent config break.

Isolate a crashing plugin only after upstream is answering again

Once you get intermittent 200s, rename `wp-content/plugins` to `plugins.disabled` via SFTP or File Manager if logs show PHP crashes tied to a plugin path. Bring plugins back one at a time. Do not start plugin isolation while PHP-FPM itself is completely down — that will not help a dead socket. Success signal: stable 200s with plugins off, then a named plugin that recreates 502 or fatals.

Test origin vs CDN path

If Cloudflare (or another CDN) is proxied, briefly set the record to DNS-only or test the origin hostname/IP the host provides. If origin is fine but the proxied hostname 502s, open a ticket with the CDN and host about upstream health and timeouts. Success signal: you know whether the gateway failure is at the edge or on the origin stack.

When to stop troubleshooting

Hand off if you cannot access the host panel or logs, PHP restart is unavailable and the socket stays down, 502 persists after CDN bypass and plugin isolation, the host reports hardware or network failure, or revenue pages stay dark past your maintenance window. Gateway failures during peak sales are a dispatch priority — do not keep restarting blindly without a root cause.

Information to collect before requesting help

01 Exact URL and DevTools status code (confirm 502 vs 500/503/522)
02 Whether a Cloudflare or other CDN Ray ID / branded page appears
03 Timestamps of outages and whether they correlate with traffic spikes
04 PHP-FPM, nginx, or host error log excerpts mentioning upstream failures
05 Whether “Restart PHP” temporarily cleared the 502
06 Hosting provider, plan type (shared/VPS), and PHP version
07 Recent deploys, PHP changes, or CDN/proxy toggles

How a professional repairs the problem

A technician confirms the true status code and whether the failure is origin PHP-FPM, proxy timeout, or edge mislabeling. They restart or repair the upstream pool, read FPM/proxy logs to the crashing or saturated worker, isolate plugin/query load that kills workers, align timeouts with capacity, and verify stable 200s through both origin and CDN paths before closing the incident.

Frequently asked questions

Is 502 the same as a WordPress critical error? +

No. A critical error is WordPress catching a PHP fatal and showing its recovery screen. A 502 means the gateway never got a valid upstream response — PHP may be down entirely, so WordPress never renders that message.

How is 502 different from Cloudflare 522? +

522 means Cloudflare could not complete a TCP connection to your origin in time. 502 usually means a proxy did talk to an upstream (or expected to) but received an invalid or empty response — often a dead PHP-FPM pool behind nginx on the same machine.

Will renaming plugins fix a 502? +

Only if PHP is running and a plugin is crashing or exhausting workers. If PHP-FPM itself is stopped, rename nothing until the upstream process is healthy again.

Can a database problem cause 502? +

Yes. Hung MySQL connections can pin every PHP worker until the gateway times out and returns 502. Check DB connectivity and slow queries when FPM looks “busy” but pages never finish.

Should I raise every timeout to the maximum? +

No. Longer timeouts without more workers or a faster page just hold connections open and can worsen overload. Fix the crash or bottleneck first; adjust timeouts only for known-slow legitimate endpoints.

Why did 502 start after a traffic spike? +

Shared and small VPS plans have finite PHP workers. When all workers are busy or killed by resource limits, new requests get 502 from the proxy. Caching, bot filtering, and a higher plan reduce recurrence.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

You will receive a clear explanation of the likely cause.
We will tell you if the issue falls outside our repair scope.
No additional work will be performed without approval.
A backup should be created whenever access and website condition allow it.

Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form.