How to Troubleshoot and Fix the WordPress 502 Bad Gateway Error

Last Updated: July 2026

TL;DR: The WordPress 502 Bad Gateway error means a gateway server (often Cloudflare or Nginx) received an invalid or no response from your upstream server, typically because PHP-FPM crashed, the server is overloaded, or a proxy is misconfigured. Restarting PHP-FPM and checking server resource usage resolves the majority of 502 errors in under ten minutes.

You click to your WordPress site and instead of your homepage, you get a stark “502 Bad Gateway” message. No content loads, your admin dashboard is inaccessible, and visitors are bouncing. The wordpress 502 bad gateway error troubleshoot fix process is not as complex as it looks, but you do need to work through the causes in the right order. This guide walks you through every root cause and the exact steps to resolve each one on WordPress 6.7 running PHP 8.3.

What the 502 Bad Gateway Error Actually Means in 2026

Try GigaPress AI Free →

The HTTP 502 status code is defined in RFC 7231 as a response a gateway or proxy server sends when the server it was acting as a proxy for returned an invalid response. In plain terms, there is a middleman (a proxy, load balancer, or CDN such as Cloudflare) sitting between the visitor’s browser and your origin server. That middleman asked your origin server for a response, and either got nothing back or got a garbled reply.

This is meaningfully different from a WordPress 503 Service Unavailable error, which indicates the server itself is up but temporarily unable to handle the request (usually scheduled maintenance or deliberate throttling). A 502 means the communication between layers has broken down. The origin server may have crashed, timed out before replying, or replied with an unparseable response.

The Four Root Causes of a WordPress 502 Bad Gateway Error

Before running any commands, identify which category your 502 falls into. The fix is entirely different depending on the cause.

Cause	What Happens	Most Likely Scenario	Typical Fix Time
PHP-FPM crash or exhausted workers	Nginx/Apache gets no response from PHP	Sudden traffic spike or runaway plugin process	2-5 minutes
Overloaded or unresponsive server	Origin server hits CPU or RAM ceiling	Shared hosting under heavy load, no caching	5-15 minutes
Cloudflare or CDN timeout	Cloudflare’s 100-second proxy read timeout exceeded	Long-running WP-Cron, slow database queries	5-20 minutes
Proxy or reverse-proxy misconfiguration	Nginx upstream block points to wrong port or socket	Recent server migration or Nginx config change	5-30 minutes

Step 1: Check Your Server Error Logs First

Before touching any configuration, read the error logs. They will point you directly at the cause and prevent wasted effort. SSH into your server and run:

sudo tail -n 100 /var/log/nginx/error.log

For Apache-based hosts, check:

sudo tail -n 100 /var/log/apache2/error.log

And for PHP-FPM specifically:

sudo tail -n 100 /var/log/php8.3-fpm.log

Look for messages containing “upstream,” “connect() failed,” “no live upstreams,” “Connection refused,” or “resource temporarily unavailable.” Each of those phrases points to a specific fix below. If you see “worker_processes” or “max_children” in the logs, you have hit a PHP-FPM pool exhaustion issue.

Step 2: Restart PHP-FPM to Fix a Crashed Worker Pool

PHP-FPM (FastCGI Process Manager) manages the pool of PHP worker processes that execute your WordPress code. When all workers are occupied or the PHP-FPM service itself crashes, Nginx has no process to hand the request to and returns a 502. This is the single most common cause of a WordPress 502 bad gateway error, especially after a traffic surge or a plugin that enters an infinite loop.

Restart PHP-FPM with the command appropriate to your server:

# For PHP 8.3 on Ubuntu/Debian:
sudo systemctl restart php8.3-fpm

# For PHP 8.2:
sudo systemctl restart php8.2-fpm

# Check the service status after restarting:
sudo systemctl status php8.3-fpm

After restarting, reload your WordPress site. If the 502 clears immediately, PHP-FPM was the culprit. To prevent recurrence, increase the number of available worker processes in your PHP-FPM pool configuration file (typically at /etc/php/8.3/fpm/pool.d/www.conf):

pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20

The exact values depend on your server’s available RAM. As a rule of thumb, each PHP-FPM worker on a WordPress site uses roughly 30-60 MB of RAM. On a server with 2 GB RAM, setting pm.max_children to 30 is a safe starting point. After editing the file, run sudo systemctl reload php8.3-fpm to apply changes without dropping existing connections.

Step 3: Check Server Resources for an Overloaded Origin

If the PHP-FPM service is running normally but the 502 persists, your server may be hitting a CPU or memory ceiling. Run these commands to check real-time resource usage:

# CPU and memory at a glance:
top -bn1 | head -20

# Memory usage summary:
free -m

# Disk I/O (high I/O wait contributes to 502s):
iostat -x 1 5

If CPU usage is above 90% or available RAM is under 100 MB, the server is overwhelmed. Short-term remedies include:

• Kill runaway processes: identify the offending PID in top and run sudo kill -9 [PID]
• Enable a page caching plugin such as W3 Total Cache or WP Super Cache so WordPress does not execute PHP for every request
• Check for WP-Cron runaway jobs with wp cron event list via WP-CLI and deregister stuck events
• Upgrade your hosting plan if the site has genuinely outgrown its resources

For a detailed look at your hosting options and what resource allocations to expect, see our guide on WordPress hosting.

Step 4: Adjust Cloudflare Timeout Settings to Fix a Proxy Timeout 502

If your WordPress site sits behind Cloudflare (which is extremely common in 2026), Cloudflare acts as the proxy layer. Cloudflare has a hard proxy read timeout of 100 seconds on its free and Pro plans. If your origin server takes longer than 100 seconds to respond to a single request, Cloudflare closes the connection and returns a 502 (or sometimes a 524, which is a Cloudflare-specific timeout variant).

Common WordPress scenarios that exceed 100 seconds include importing a large WooCommerce product CSV, running a database migration plugin, or WP-Cron executing a bulk email send. To diagnose whether Cloudflare is the layer where the 502 originates, add a temporary A record that bypasses Cloudflare (set the DNS record to DNS-only, removing the orange cloud proxy) and try loading the site directly. If the site loads without a 502, Cloudflare is the point of failure.

Your options for resolving a Cloudflare-originated 502 include:

• Speed up your origin server so it responds within 100 seconds (fix slow database queries, enable object caching with Redis or Memcached)
• Move long-running tasks out of the web request cycle entirely, using background processing via Action Scheduler (built into WooCommerce) or WP Background Processing
• Upgrade to a Cloudflare Business plan, which allows you to increase the proxy read timeout to 6,000 seconds for specific URLs via a Cloudflare configuration rule
• Exclude specific admin URLs from Cloudflare proxying using a Page Rule that sets “Bypass Cache” or using a configuration rule to disable the proxy for /wp-admin/admin-ajax.php during maintenance operations

To disable Cloudflare proxying for a single DNS record temporarily, log into your Cloudflare dashboard, navigate to DNS, and click the orange cloud icon next to your A record to turn it grey (DNS-only). Remember to re-enable it after diagnosis. This does not affect your DNS TTL for existing visitors but it removes Cloudflare as a variable.

Step 5: Fix a Proxy Misconfiguration in Your Nginx or Apache Setup

If you recently migrated your server, changed your hosting environment, or updated your Nginx or Apache configuration, the reverse-proxy settings may point to the wrong socket or port. This is a common cause of 502 errors after a server rebuild or after switching from Apache to Nginx.

In an Nginx setup, the fastcgi_pass or proxy_pass directive must point to where PHP-FPM is actually listening. PHP-FPM can listen on a Unix socket (faster) or a TCP port (more flexible). Check where your PHP-FPM pool is listening:

grep -r "listen" /etc/php/8.3/fpm/pool.d/www.conf

A typical output will show either:

listen = /run/php/php8.3-fpm.sock
# or
listen = 127.0.0.1:9000

Now check your Nginx site configuration to confirm the fastcgi_pass matches:

grep -r "fastcgi_pass" /etc/nginx/sites-enabled/

If the pool listens on a Unix socket but Nginx is pointed to 127.0.0.1:9000, you will get a 502 every time. Correct the mismatch in your Nginx server block:

location ~ .php$ {
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

After editing, test the configuration before reloading:

sudo nginx -t && sudo systemctl reload nginx

Step 6: Deactivate Plugins and Switch Themes via WP-CLI or FTP

A poorly coded plugin can cause PHP-FPM workers to hang indefinitely, draining the entire pool and producing a 502. If the error began right after installing or updating a plugin, that plugin is the prime suspect. Because your dashboard may be inaccessible during a 502, use WP-CLI to deactivate all plugins from the command line:

wp plugin deactivate --all

Then reload the site. If the 502 clears, reactivate plugins one at a time with wp plugin activate plugin-slug until the error returns. That last-activated plugin is the culprit. If you do not have WP-CLI or SSH access, you can rename the plugins directory via FTP or your host’s file manager from wp-content/plugins to wp-content/plugins-disabled. WordPress will deactivate all plugins automatically when it cannot find the directory.

Similarly, a theme that makes external HTTP calls on every page load can trigger timeouts. Switch to the default Twenty Twenty-Five theme via WP-CLI:

wp theme activate twentytwentyfive

For a broader look at other common HTTP error codes on WordPress, the guide to what the 503 Service Unavailable error means and how to fix it is a helpful companion read, since 502 and 503 are often confused. You may also find our complete list of common WordPress errors useful for diagnosing other concurrent issues.

Step 7: Contact Your Hosting Provider with Diagnostic Data

If you have worked through all the steps above and the 502 persists, the problem may be infrastructure-level: a failing network switch, a corrupted upstream load balancer configuration, or a temporary node failure on a shared or cloud host. At this point, contact your hosting support team and provide the following information to speed up resolution:

• The exact time the 502 started (with timezone)
• The relevant lines from your Nginx or Apache error log
• The output of systemctl status php8.3-fpm
• Whether the error is 100% reproducible or intermittent
• Whether you are behind Cloudflare and the result of a DNS-only bypass test

Quality WordPress hosts respond to server-level issues within minutes. If your host cannot explain the root cause of a 502 within a reasonable time frame, it may be worth reviewing your hosting options. You can also check the WordPress.org recommended hosting page for vetted providers, or consult the WordPress Developer Resources for deeper server configuration references.

Quick-Reference: WordPress 502 Bad Gateway Error Fix Checklist for 2026

1. Read Nginx, Apache, and PHP-FPM error logs for specific upstream error messages
2. Restart PHP-FPM (sudo systemctl restart php8.3-fpm)
3. Check server CPU and RAM with top and free -m; kill runaway processes
4. Test bypassing Cloudflare by switching DNS record to DNS-only temporarily
5. Increase Cloudflare proxy timeout via configuration rule (Business plan) or reduce origin response time
6. Verify fastcgi_pass in Nginx matches the actual PHP-FPM listen socket or port
7. Deactivate all plugins via WP-CLI or FTP rename; reactivate one by one
8. Switch to default Twenty Twenty-Five theme and test
9. Contact hosting support with log data and timestamps

For errors closely related to the 502, see our guides on the 504 Gateway Timeout error in WordPress and the 500 Internal Server Error in WordPress. If your site is experiencing connection issues beyond gateway errors, the WordPress Connection Timed Out error guide covers additional diagnostic steps.

Want a Pro WordPress Site in Minutes?

GigaPress AI builds you a full WordPress site in about 15 minutes — AI handles layout, styling, content, and images. Free to design, only pay when you’re ready to go live. If you’re tired of debugging server-layer errors on a DIY WordPress setup, GigaPress AI’s managed hosting environment is pre-optimized for PHP-FPM performance and Cloudflare compatibility, so you spend time growing your site, not chasing 502 errors.

Frequently Asked Questions

What is the fastest way to fix a WordPress 502 Bad Gateway error?

The fastest fix is to restart PHP-FPM with sudo systemctl restart php8.3-fpm. This resolves the majority of 502 errors caused by a crashed or exhausted worker pool, and takes under thirty seconds. If the error returns, increase the pm.max_children value in your PHP-FPM pool config to prevent the pool from running out of workers under load.

Why does my WordPress site show 502 only sometimes and not always?

Intermittent 502 errors almost always indicate a resource limit being hit under traffic spikes, not a static misconfiguration. The PHP-FPM worker pool runs out during bursts of traffic, some requests get through before the pool is exhausted, and others receive a 502. The fix is to increase PHP-FPM pm.max_children, add page caching so fewer PHP workers are needed per request, or upgrade to a server with more RAM that can support a larger worker pool.

Does Cloudflare cause 502 errors on WordPress sites?

Yes. Cloudflare returns a 502 when your origin server fails to respond within its proxy read timeout (100 seconds on Free and Pro plans). Cloudflare also returns a 502 if your origin server’s IP is unreachable or returns a non-HTTP response. You can confirm Cloudflare is the source by temporarily switching your DNS record to DNS-only (grey cloud) and accessing the site directly. If the site loads, the fix is to speed up your origin or increase the Cloudflare timeout via a configuration rule on a Business plan.

Can a WordPress plugin cause a 502 Bad Gateway error?

Yes, and this is more common than most site owners expect. A plugin that enters an infinite loop, makes slow external API calls on every page request, or triggers extremely long database queries can cause PHP-FPM workers to hang. Once all workers are occupied with stuck processes, subsequent requests receive a 502. Deactivate all plugins via WP-CLI or by renaming the plugins directory, then reactivate them one at a time to isolate the problematic plugin.

How do I fix a 502 error after moving WordPress to a new server?

After a server migration, a 502 is almost always caused by a mismatch between where PHP-FPM is listening (Unix socket or TCP port) and what your Nginx fastcgi_pass directive specifies. Run grep listen /etc/php/8.3/fpm/pool.d/www.conf to find the PHP-FPM listen target, then run grep fastcgi_pass /etc/nginx/sites-enabled/ to confirm the Nginx configuration matches. Correct the mismatch, run sudo nginx -t to validate, and reload Nginx.