How to Resolve the “502 Bad Gateway” Error in WordPress

A 502 Bad Gateway error in WordPress almost always means one thing: your web server (usually Nginx) asked PHP for a page and got back nothing it could use. The site itself is not deleted, blocked or hacked in most cases, and roughly 80% of the incidents we see clear within ten minutes once you identify which layer broke. The trick is working through the request chain in order instead of guessing.

Below is the order we actually use when a customer opens a ticket about a 502, starting with the checks that take seconds and ending with the server-level settings that cause repeat offenders.

What a 502 Response Is Really Telling You

In the HTTP spec, a 502 is a server-side status code returned by a machine acting as a gateway or proxy when the upstream server sends an invalid response. The MDN reference for status 502 describes it exactly that way, and the phrasing matters for troubleshooting. Something answered the request; it just could not get a usable reply from the thing behind it.

On a typical WordPress stack, the request passes through four or five hops: browser, CDN or Cloudflare, Nginx, PHP-FPM, then MySQL. A 502 is generated by whichever hop lost contact with the next one down the line. Your job is to find the first broken link, not to restart everything at once.

It helps to know the neighbours. A 504 means the upstream replied too slowly rather than badly, which we cover in the walkthrough on what causes the 504 Gateway Timeout in WordPress. A database failure usually shows the familiar “Error Establishing a Database Connection” message instead.

The Two-Minute Checks That Clear Most 502 Errors

Before touching any config file, rule out the cheap causes. A surprising share of 502 reports on Reddit and in support queues turn out to be a stale cached copy of the error page rather than a live fault.

• Hard-reload the page with Ctrl+F5, then try it in a private window and on mobile data.
• Purge the CDN cache, since Cloudflare and similar proxies will happily serve a cached 502 for several minutes after the origin recovers.
• Check your host’s status page for node maintenance or a network event in your region.
• Test a non-WordPress file, such as a plain HTML file in your web root. If that loads fine, Nginx is healthy and PHP is the suspect.
• Restart PHP-FPM (sudo systemctl restart php8.3-fpm) if you have root or a control-panel button for it.

That last step fixes a genuine majority of one-off 502 Bad Gateway incidents, because a crashed or hung PHP worker pool leaves Nginx with nobody to talk to. If the error returns within the hour, treat the restart as a bandage and keep reading.

PHP-FPM Is the Usual Culprit

When PHP-FPM runs out of worker processes, new requests queue, then get refused, and Nginx reports a bad gateway. The relevant setting is pm.max_children in your pool config, and the right number depends on RAM: divide usable memory by the average process size (commonly 40-80 MB on a plugin-heavy site).

Look for the giveaway line in the PHP-FPM log, usually server reached pm.max_children setting, consider raising it. Our notes on monitoring WordPress PHP error logs on the server cover where those files live on common stacks. Fatal errors, segmentation faults and exhausted memory limits all show up in the same place with a timestamp you can match to the failed request.

Two other PHP-side settings cause repeat 502s on busy sites:

For a closer look at this topic, see our guide: Why Are My WordPress Emails Going to Spam? (And How SMTP Fixes It).

• memory_limit set too low for the job, often fine at 256M for blogs but tight at 512M for WooCommerce imports.
• max_execution_time shorter than a long-running task, which kills the worker mid-response.
• OPcache misconfiguration, where a too-small opcache.memory_consumption triggers repeated cache resets under load.

If you are on a managed plan, these values are usually adjustable from the dashboard rather than by editing files, and our WordPress hosting PHP controls expose the versions and limits directly.

Nginx Settings That Produce a 502 Under Load

Nginx returns 502 when the FastCGI socket refuses the connection or when the response header exceeds the buffers allocated to it. Large WordPress pages with many cookies or a long Set-Cookie header are classic triggers on default buffer sizes.

Three values are worth reviewing in your server block, with reference to the official ngx_http_fastcgi_module documentation:

1. fastcgi_buffers and fastcgi_buffer_size, often raised to 16 16k and 32k on membership or ecommerce sites.
2. fastcgi_pass, which must point at the exact socket path or TCP port your PHP pool is listening on. A PHP version upgrade frequently changes that path and breaks it silently.
3. fastcgi_read_timeout, typically 60-300 seconds depending on how long your heaviest admin tasks run.

Run nginx -t before reloading. A failed config test that still gets reloaded is how a brief fix turns into an afternoon of downtime.

Ruling Out Plugins, Themes and Recent Deploys

If the 502 started right after an update, the code is the likely cause. Rename the plugins folder to plugins_off over SFTP or SSH, load the site, then rename it back and reactivate plugins one at a time. WP-CLI makes this faster: wp plugin deactivate --all followed by selective reactivation.

Teams that deploy regularly should be able to roll back in seconds rather than debug live. That is the practical case for version-controlled deployments on WordPress hosting with Git, where a bad commit gets reverted before most visitors notice the gateway error.

When Cloudflare Shows the 502 Instead

Cloudflare-branded 502 pages include a Ray ID and a diagram showing which side failed. If the “host” block is marked as the problem, your origin is down and the fixes above apply. If Cloudflare itself is flagged, check their status page and wait, because nothing on your server will help.

Workers scripts returning malformed responses also surface as 502s. Bypass the proxy temporarily by editing your local hosts file to point the domain at the origin IP, which tells you within a minute whether the break sits at the edge or at home.

Traffic Spikes Are the Cause Nobody Logs

The 502s that competitors rarely explain are capacity-driven. A news piece gets picked up, concurrent requests jump from 5 to 300, PHP workers saturate, and every visitor after that sees a bad gateway page while your logs show nothing more dramatic than max_children warnings.

Caching absorbs most of that: a full-page cache serving logged-out traffic from memory can cut PHP requests by 90% or more. Publishers running high-variance traffic benefit from platforms sized for bursts, which is the thinking behind WordPress magazine hosting and the resource headroom on business WordPress hosting plans. Set an uptime monitor at one-minute intervals so you learn about a 502 before a reader emails you.

Frequently Asked Questions

How Do You Get Rid of a 502 Bad Gateway Error?

Restart PHP-FPM and purge your CDN cache first, which resolves the majority of 502 incidents in under five minutes. If the error returns, check the PHP-FPM log for max_children or fatal error entries, then verify the fastcgi_pass socket path in Nginx matches your running PHP version.

Does a 502 Bad Gateway Mean the Website Is Blocked?

No. A 502 is a server-side failure between two machines, not a block, ban or firewall rejection, which would normally return a 403 or a connection timeout instead. Your DNS, SSL certificate and domain registration are all unaffected by a bad gateway response.

Will a 502 Error Fix Itself?

Often yes, within 30 seconds to a few minutes, because PHP-FPM respawns crashed workers automatically and traffic spikes subside. A 502 that persists beyond roughly ten minutes points at a configuration fault or a saturated server and needs manual work.

What Is the Root Cause of a 502 Bad Gateway?

The root cause is an invalid or empty response from an upstream process, most commonly PHP-FPM hitting its worker, memory or execution-time limit. Undersized Nginx FastCGI buffers, a wrong socket path after a PHP upgrade and faulty plugin code round out the list.

Get Server-Level Help With Recurring 502s

If the same 502 Bad Gateway keeps returning after restarts, the sizing or stack configuration is wrong and a second set of eyes on the logs will find it faster. Our team reads PHP-FPM and Nginx logs daily, so send over the timestamps and we will tell you which layer gave up.