A 502 Bad Gateway error means one server in your hosting chain received an invalid response from the layer behind it, most often because PHP-FPM crashed, lost its socket, or ran out of workers. It differs from a 504, where the backend never answered in time. We find the failing layer and fix it for $49-$99, typically in about 45 minutes.
Modern hosting is a chain of servers, not one machine. A visitor's request typically passes through a CDN like Cloudflare, then a web server like nginx or Apache acting as a reverse proxy, and finally reaches the backend that actually runs your site, usually PHP-FPM for WordPress. A 502 Bad Gateway means one link in that chain asked the next link for your page and got an invalid response back: the connection was refused, it was cut off mid-reply, or what came back was not valid HTTP. That is the crucial difference from a 504, where the backend simply never answered in time. A 502 usually means the process that should be running your code is crashed, restarting, or unreachable, rather than merely slow. The whole site goes down with it, every URL returns a server error to visitors and to Googlebot, and because the failing layer is invisible from the browser, guessing instead of reading the server logs wastes hours.
Fix This Error Now →502 Bad Gateway Error can be caused by several issues. Here are the most common.
The most common cause on nginx and PHP stacks. The web server is up, but the PHP process manager behind it is dead, so every connection to it is refused. The proxy error log shows connection refused entries for the upstream, and the fix starts with finding out why the service died rather than just restarting it.
PHP-FPM serves at most pm.max_children simultaneous requests, per the PHP documentation. When slow requests occupy every worker, new connections back up and fail. This produces the classic intermittent 502: fine at 8am, down at lunch, fine again at night. Raising the cap without fixing the slow requests just moves the cliff.
A worker that dies while writing its response makes the proxy report an upstream that closed the connection prematurely. The killers are usually the kernel's out-of-memory reaper on an undersized server, or PHP-FPM's own request_terminate_timeout cutting off a request that ran too long.
The web server forwards PHP requests to a specific socket or port. A PHP version upgrade typically changes that socket path, and if the proxy config still references the old one, the site throws 502 on every request. This is the classic morning-after error following a host PHP upgrade or a server migration.
nginx allocates a fixed buffer for the first part of the backend response. Oversized cookies or headers, often from plugins that stuff data into Set-Cookie, overflow it and nginx logs that the upstream sent too big a header while reading the response, then serves a 502. The fix is raising the buffer and trimming whatever bloated the headers.
PHP-FPM can restart itself when child processes keep dying: its emergency_restart_threshold watches for repeated segmentation faults, per the PHP documentation. A buggy PHP extension or a bad opcode cache can put the service in a die-restart loop, which looks like a 502 that clears for a minute and returns.
When Cloudflare or another CDN sits in front, it shows its own 502 if your origin returns something invalid. Cloudflare's documentation notes that most 502s it displays are passed through from the origin, and that Cloudflare-generated ones often trace to the origin serving broken gzip content or a wrong content-length header.
A box with exhausted RAM or a saturated CPU cannot keep its backend processes alive. The database drags, PHP workers pile up waiting on queries, memory runs out, and the out-of-memory killer starts shooting processes. The 502 is the visible symptom; the resource exhaustion underneath is the disease.
A server firewall rule, a WAF, or an overzealous security module can block or reset the internal connection between the proxy and the backend, or between the CDN and the origin. Everything looks healthy from inside the server, yet requests through the front door fail.
70-80% of our customers have WordPress sites. Here are WordPress-specific causes for this error.
A plugin that calls an external API during page load, or runs heavy queries on every request, makes each request hold a PHP-FPM worker for seconds instead of milliseconds. At even moderate traffic the pool of workers runs dry and the proxy starts returning 502 to everyone.
Hosts routinely upgrade PHP versions, and each version usually runs its own PHP-FPM pool on its own socket. If the web server config was not updated in the same step, WordPress goes down with a sitewide 502 immediately after the upgrade even though nothing in WordPress changed.
WordPress runs scheduled tasks on visitor traffic. A backup plugin, a broken import, or a mis-scheduled task that fires on every page load can occupy multiple workers at once. The site 502s during exactly the window the heavy task runs, then recovers, which is a strong diagnostic fingerprint.
With a working page cache most visits never touch PHP at all. When caching breaks or gets disabled, every request suddenly needs a PHP worker, and a traffic level the site handled easily yesterday exhausts the pool today. The 502 appears without any code change at all.
Certain plugin, PHP extension, and opcode cache combinations crash the PHP process outright rather than throwing a catchable error. PHP-FPM logs the dead children and may auto-restart. Finding the trigger requires correlating crash timestamps in the FPM log with the requests in the access log.
Page builders, dashboards with live widgets, and some themes poll admin-ajax.php or the REST API every few seconds per open browser tab. A handful of open wp-admin tabs can quietly consume workers all day and tip a small server into 502s under otherwise normal traffic.
Identify which layer generated the 502 first. A Cloudflare-branded error page versus a plain server page tells us whether the CDN or your origin produced it, which halves the search space immediately
Read the web server error log for the exact upstream failure: connection refused means the backend is down, a prematurely closed connection means workers are dying, a too-big header means buffer overflow. Each one has a different fix
Check whether PHP-FPM is running, restart it if it is down, and then watch it: a service that dies again within minutes is in a crash loop that restarting alone will never fix
Verify the socket or port the proxy forwards to actually matches the running PHP-FPM pool, especially if PHP was recently upgraded or the site was migrated
Measure active PHP workers against the pm.max_children limit to confirm or rule out pool exhaustion, and right-size the pool to the server's actual memory
Find what is making requests slow enough to pile up: slow database queries, external API calls inside page loads, or heavy cron tasks, and fix the source instead of only raising limits
Check the kernel log for out-of-memory kills and the FPM log for segfault patterns, then isolate the plugin or extension responsible
Raise proxy buffer sizes if oversized response headers are the trigger, and trim the cookie or header bloat that caused them
Test the site direct-to-origin with the CDN bypassed to isolate Cloudflare or CDN configuration issues, and purge the CDN cache after the origin is healthy
Confirm stability under load, restore or repair the page cache so normal traffic stops hitting PHP, and set up uptime monitoring so the next incident alerts you within a minute
Fixed in 2 hours or your money back. We do not waste time.
No hourly billing. You know the price before we start.
Cannot fix it? You do not pay. Zero risk to you.
Our Broken Pages & Error Repair team has fixed thousands of sites with this exact issue. 2-hour turnaround, guaranteed.
One server in your hosting chain acted as a gateway, asked the server behind it for your page, and received an invalid response: a refused connection, a connection that died mid-reply, or data that was not valid HTTP. On a typical WordPress stack that means nginx or Apache could not get a usable answer from PHP-FPM. It is a communication failure between layers of your own hosting, not something the visitor's browser or computer caused.
A 502 means the gateway received an invalid response from the backend. A 504 means it received no response at all before its timeout expired. In practice, a 502 usually points at a backend that is crashed, unreachable, or misconfigured, while a 504 points at a backend that is alive but too slow. The distinction matters because the diagnostic paths are different, which is why we check the exact error and the logs before touching anything.
Sometimes, and it is always worth reporting, but the majority of 502s we fix are application-level: a slow plugin exhausting the PHP worker pool, a mis-pointed proxy config after a PHP upgrade, or a crash loop triggered by a specific plugin. The host's infrastructure can be perfectly healthy while your site's own processes fail. That is why hosts often close 502 tickets with everything looks fine on our end.
Hosts check whether the physical server and their services are up, and they usually are. What they rarely check is whether your PHP pool is exhausted, whether your proxy config points at the right socket, whether a plugin is holding workers hostage on external API calls, or whether response headers are overflowing proxy buffers. Those live in your site's territory, and they are the most common 502 causes we find after a host has said everything is fine.
Intermittent 502s are a capacity signature. PHP-FPM caps simultaneous requests at its pm.max_children limit, so the site works until traffic or slow requests fill every worker, fails while the pool is saturated, and recovers when load drops. A crash-restart loop produces the same rhythm: PHP-FPM dies, its manager restarts it, and the site flaps between up and down. The timing pattern of the failures is itself diagnostic evidence, so note when they happen.
Usually not. Cloudflare's own documentation explains that most 502s it displays are passed through from your origin server, shown with Cloudflare branding. A 502 actually generated by Cloudflare is rarer and often traces to the origin serving broken gzip content or a mismatched content-length header. The reliable test is requesting the site directly from the origin with the CDN bypassed: if the 502 persists, the origin is the problem.
Yes. A 502 is a communication failure between your web server and its backend. Your files, database, orders, and content are untouched; the machinery that serves them is what stopped. The only data caveat is for actions that were mid-flight when a worker died, such as an order submitted at the exact moment of a crash, which is another reason to fix crash loops promptly rather than living with occasional 502s.
Most 502 fixes cost $49-$99. Restarting a dead service and fixing the reason it died, correcting a proxy socket mismatch, or resizing a worker pool sit at the low end. Diagnosing a crash loop, tracing a plugin that exhausts the pool under load, or untangling a CDN-origin issue sits at the high end. You get a firm quote before we start, and if we cannot fix it, you pay nothing.
Our average 502 fix takes about 43 minutes. Getting the site back up usually happens in the first 15 minutes, because reading the proxy error log points directly at the failing layer. The rest of the time goes into fixing the underlying cause so the error does not return at the next traffic peak, and verifying stability under load.
Keep a working page cache in front of PHP so normal traffic rarely touches the backend, size the PHP-FPM pool to the server's real memory, avoid plugins that call external services during page loads, and put uptime monitoring on the site so you hear about failures in minutes. If 502s recur at traffic peaks despite that, the server is genuinely undersized and moving up a tier is cheaper than the lost sales.
Every technical claim on this page traces back to primary documentation and the named vendor references below.
Plugin, theme, critical error, PHP, and update fixes in one place.
Visit the WordPress Repair hub →Get 502 bad gateway error fixed today. Expert engineers. 2-hour guarantee.
Fix My Error Now →