WordPress 502 bad gateway error: how to fix it

A 502 Bad Gateway error means the web server received an invalid response from an upstream server. In a WordPress context, the web server is Nginx (or Apache acting as a reverse proxy), and the upstream server is PHP-FPM – the process that actually runs your WordPress PHP code. Nginx asked PHP-FPM to process the request, and PHP-FPM either crashed, returned garbage, or terminated the connection unexpectedly.

This error sits between a 503 (PHP-FPM is too busy to accept the request) and a 504 (PHP-FPM accepted the request but took too long to respond). A 502 means PHP-FPM accepted the request and then something went wrong during processing – the connection was lost, the process was killed, or the response was malformed.

Understanding the relationship between the web server and PHP-FPM makes diagnosing a 502 straightforward.

How Nginx talks to PHP-FPM#

When a request for a PHP page arrives, Nginx does not execute PHP itself. It forwards the request to PHP-FPM (FastCGI Process Manager) via a Unix socket or TCP connection. PHP-FPM runs the PHP code, generates the HTML output, and sends it back to Nginx. Nginx then sends that output to the visitor’s browser.

A 502 occurs when this communication breaks down. Nginx successfully connected to PHP-FPM (otherwise you would see a 503), but the response it received was not valid. The specific failure modes are:

• PHP-FPM process crashed during execution (segfault, out-of-memory kill)
• PHP-FPM process was killed by the operating system (OOM killer, resource limits)
• PHP-FPM closed the connection before sending a complete response
• PHP-FPM sent a malformed FastCGI response that Nginx could not parse

The Nginx error log tells you exactly which failure occurred. This is always the first place to look.

Step 1: Check the Nginx error log#

The Nginx error log contains the specific reason for the 502. Common entries:

upstream prematurely closed connection while reading response header from upstream

PHP-FPM closed the connection before sending the response headers. The PHP process was killed or crashed mid-execution.

recv() failed (104: Connection reset by peer) while reading response header from upstream

PHP-FPM actively reset the connection. Usually a crash or a forced process termination.

upstream sent too big header while reading response header from upstream

The PHP response headers exceeded Nginx’s buffer size. This is a configuration issue, not a crash.

connect() to unix:/var/run/php-fpm.sock failed (11: Resource temporarily unavailable)

This is technically a 503, not a 502, but sometimes appears alongside 502 errors when PHP-FPM is overloaded.

On Hostney, per-site error logs are at ~/.logs/{your-domain}-nginx.error.log . On self-managed servers, check /var/log/nginx/error.log .

Step 2: Check the PHP error log#

If the Nginx log shows that PHP-FPM closed the connection prematurely, the PHP error log tells you why. Common entries:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted

The PHP process ran out of memory and was killed. See WordPress PHP memory exhausted error: how to fix it for the complete walkthrough.

PHP Fatal error: Maximum execution time of 30 seconds exceeded

The script ran longer than allowed and PHP killed it. The connection was closed before a response was sent.

PHP Fatal error: Uncaught Error: Call to undefined function ...

A PHP fatal error crashed the process. The error message tells you which plugin or theme file caused it.

On Hostney, per-site PHP error logs are at ~/.logs/{your-domain}-php.error.log .

Cause 1: PHP-FPM process crashed (memory)#

The most common cause of 502 errors. A PHP script consumed more memory than the configured limit, PHP killed the process, and Nginx received an incomplete response.

This is subtly different from a white screen caused by memory exhaustion. A white screen happens when PHP catches the memory error and outputs nothing. A 502 happens when the memory error kills the process so abruptly that it cannot even send an error response to Nginx.

How to confirm

The PHP error log shows Allowed memory size exhausted . The Nginx error log shows upstream prematurely closed connection .

How to fix

The immediate fix is to increase the PHP memory limit. In wp-config.php :

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

This only works if PHP’s own memory_limit is equal to or higher. On Hostney, the platform sets a generous PHP memory limit by default. If your site needs more, contact support.

The long-term fix is to identify what is consuming the memory. The file path in the PHP error log tells you which plugin or operation hit the limit. Common offenders:

• WooCommerce with large product catalogs loading hundreds of variations
• Page builders rendering complex layouts
• Import operations loading entire datasets into memory
• Image processing on high-resolution uploads

Cause 2: PHP script timeout#

If a PHP script exceeds max_execution_time , PHP terminates it. If the termination happens after PHP-FPM has started sending the response, you get a partial response. If it happens before any output, you get a 502 because Nginx received nothing.

How to confirm

The PHP error log shows Maximum execution time exceeded . The error appears on specific pages or operations, not site-wide.

How to fix

Increase the execution time for the specific operation. On Hostney, change max_execution_time in Hosting > PHP Manager > Variables. For command-line operations (imports, exports, bulk operations), use WP-CLI instead of the browser – WP-CLI does not have a web request timeout:

wp import large-file.xml --authors=create

If the timeout happens on normal page loads (not imports or admin operations), a plugin is running a slow operation on every request. Enable Query Monitor to identify slow database queries, or check the PHP slow log for functions that take too long.

Cause 3: PHP-FPM killed by OOM killer#

The Linux Out-of-Memory (OOM) killer terminates processes when the system runs critically low on memory. If PHP-FPM is killed, all active requests on that worker receive a 502.

This is different from PHP’s memory_limit – that is a per-script limit within PHP. The OOM killer operates at the operating system level and kills entire processes when the server as a whole runs out of RAM.

How to confirm

Check the system log for OOM kill events:

grep -i "oom" /var/log/messages

or:

dmesg | grep -i "oom"

If you see entries like Out of memory: Killed process [pid] (php-fpm) , the OOM killer terminated PHP-FPM.

How to fix

This is a server resource issue, not a WordPress configuration issue. The server does not have enough RAM for the workload. Solutions:

• Reduce PHP-FPM worker count. Each worker reserves memory. If the server has 2 GB of RAM and 20 PHP-FPM workers each using 100 MB, that is 2 GB just for PHP. Reduce  pm.max_children  in the PHP-FPM pool configuration.
• Enable swap. If the server has no swap space, the OOM killer triggers as soon as RAM is exhausted. Adding swap provides a buffer (at the cost of performance when swap is used).
• Upgrade server resources. If the workload legitimately needs more RAM, the server needs more RAM.

On Hostney, each site runs in its own isolated container with resource limits. One site’s memory usage cannot trigger the OOM killer for another site’s PHP processes. If your container is hitting its limits, support can adjust the allocation.

Cause 4: Upstream buffer too small#

When PHP-FPM sends a response with large headers (many cookies, large session data, complex redirect chains), the response headers may exceed Nginx’s default buffer size. Nginx cannot parse the oversized headers and returns a 502.

How to confirm

The Nginx error log shows upstream sent too big header while reading response header from upstream . This typically happens on specific pages, not site-wide – usually pages that set many cookies or have large session data.

How to fix

Increase Nginx’s FastCGI buffer sizes. On self-managed servers, add these to the Nginx configuration:

fastcgi_buffer_size 32k;
fastcgi_buffers 16 16k;
fastcgi_busy_buffers_size 32k;

On managed hosting, contact support to adjust these values. On Hostney, the default buffer sizes are configured for WordPress compatibility and this issue is rare.

WooCommerce sites with many payment gateways, analytics scripts, and marketing plugins are most likely to hit this limit because each adds cookies and headers to the response.

Cause 5: Plugin or theme fatal error#

A PHP fatal error that occurs after PHP-FPM has accepted the connection but before it sends any output produces a 502. This is the same root cause as the WordPress white screen of death, but manifests as a 502 when the error kills the process rather than just preventing output.

How to confirm

The PHP error log shows a fatal error with a file path in wp-content/plugins/ or wp-content/themes/ . The 502 appeared after a plugin or theme update.

How to fix

Deactivate the offending plugin via SFTP:

cd wp-content/plugins/
mv problematic-plugin problematic-plugin-disabled

If you cannot identify which plugin from the error log, deactivate all plugins:

mv plugins plugins-disabled

If the site loads, rename the directory back and reactivate plugins one at a time to find the culprit.

Cause 6: PHP-FPM not running or restarting#

If PHP-FPM is completely down, you get a 503 (connection refused). But if PHP-FPM is in the process of restarting – accepting connections on the socket but not yet ready to process them – you can get a 502 for requests that arrive during the restart window.

How to confirm

The 502 is intermittent and lasts only a few seconds. It may correlate with PHP-FPM restarts triggered by configuration changes, log rotation, or graceful reloads.

How to fix

On self-managed servers, check if PHP-FPM is configured for graceful restarts:

systemctl status php-fpm

If PHP-FPM is restarting repeatedly (crash loop), the PHP error log will show the reason. Common causes: a syntax error in the PHP-FPM pool configuration, a corrupted OPcache, or a PHP extension that crashes on load.

On Hostney, each site’s PHP container restarts independently and automatically. A restart takes only a few seconds, and only that specific site is affected. Other sites on the same server continue serving normally.

Cause 7: Cloudflare or CDN timeout#

If your site is behind Cloudflare or another CDN, the CDN acts as an intermediary. The CDN connects to your origin server, waits for a response, and forwards it to the visitor. If the origin server responds too slowly or the connection drops, the CDN generates its own 502 page.

How to confirm

The 502 page is branded by the CDN (Cloudflare’s 502 page shows “Cloudflare” and “Error 502”). The response headers include CDN identifiers like cf-ray .

How to fix

This means your origin server is having an issue that the CDN detected. The fix is on the origin server, not the CDN:

• Check if the origin server is reachable by bypassing the CDN (use the server’s direct IP)
• Check PHP-FPM status on the origin
• Check if the origin is under heavy load

If the origin is healthy but slow, the CDN may be timing out before the response arrives. Increase the CDN’s origin timeout settings, or optimize the slow page on the origin.

502 vs 503 vs 504: which is which#

These three errors are related but indicate different failure points:

A 502 means something broke. A 503 means something is overloaded. A 504 means something is slow. The diagnostic approach is different for each. For 503 and 504, see 503 service temporarily unavailable in Nginx and 504 gateway timeout in Nginx.

Intermittent 502 errors#

If the 502 happens occasionally rather than consistently, the cause is usually a resource limit being hit under specific conditions:

• High-traffic spikes. Multiple concurrent requests consuming memory simultaneously can push total usage past the limit. Each request alone would be fine, but together they exhaust resources.
• Specific pages or operations. A WooCommerce checkout, a large admin page, or a search query with many results may consume more memory or time than typical pages.
• Bot traffic. Automated bots hitting PHP endpoints (wp-cron.php, admin-ajax.php, xmlrpc.php) consume PHP workers and memory. If the bot traffic is heavy enough, legitimate requests fail. See What happens when bots find your WordPress login for how bot traffic affects WordPress.
• Database contention. Slow database queries hold PHP workers longer, increasing memory usage across all active workers.

For intermittent 502 errors, enable server-level caching to reduce PHP-FPM load. On Hostney, the Nginx FastCGI cache serves cached pages without involving PHP at all, which dramatically reduces the number of requests that PHP-FPM needs to handle. See How Hostney handles WordPress cache purging automatically for the mechanics.

How Hostney handles 502 errors#

Container isolation. Each site runs in its own PHP-FPM container. A PHP process crashing on one site cannot produce 502 errors on another site. On traditional shared hosting, a PHP-FPM crash can affect every site on the server.

Automatic container restart. If a site’s PHP container crashes, it restarts automatically within seconds via systemd. The 502 is temporary and self-healing without any manual intervention.

Generous resource defaults. PHP memory limits and execution times are set generously by default. The most common causes of 502 errors on other platforms (tight memory limits, aggressive execution timeouts) are less likely to occur.

Per-site error logs. Both Nginx and PHP error logs are isolated per site, so diagnosing the cause of a 502 does not require searching through a shared log file. The error log path is always ~/.logs/{your-domain}-php.error.log for PHP errors and ~/.logs/{your-domain}-nginx.error.log for Nginx errors.

Summary#

A 502 Bad Gateway error means PHP-FPM crashed or sent an invalid response while processing your request. The Nginx error log tells you what went wrong (connection reset, premature close, oversized headers), and the PHP error log tells you why (memory exhaustion, fatal error, execution timeout).

Start with the Nginx error log to identify the failure mode, then check the PHP error log for the root cause. The most common fix is increasing the PHP memory limit or deactivating a plugin that crashed. For persistent 502 errors, look at server resource usage – PHP-FPM may need more memory or fewer workers. For a complete reference of WordPress errors and their quick fixes, see How to fix the most common WordPress errors.