WordPress 502 Bad Gateway Error: Causes and Step-by-Step Fixes

A 502 Bad Gateway means a gateway — usually Nginx, a load balancer, proxy, or CDN — couldn't get a valid response from the upstream server. WordPress may be involved, but the error itself is almost always infrastructure in front of PHP.

Don't clear your browser cache. Don't reinstall WordPress. The problem is on the server side.

First Five Minutes: Triage the 502

1. Test several pages, /wp-admin/, and a private browser window.
2. Check from another network or an uptime service. If everyone sees the 502, it's the server.
3. Check the host's status page. A PHP, database, proxy, or CDN incident may already be reported.
4. Purge caches once. If that doesn't fix it, stop.
5. Open the server logs. The log tells you the actual cause.

Confirm the Scope

If only your browser shows the 502, it's a local issue. If every visitor sees it, it's the server.

Check whether the whole site is down or just some pages. /wp-admin/ failing while the front end works points to PHP-FPM or admin-specific plugins. The whole site failing points to Nginx, PHP-FPM, or the database.

Purge Caches Once

Purge the WordPress cache, server cache, and CDN cache. If the CDN has a development mode or origin preview, use it to bypass the CDN temporarily.

Don't change DNS. DNS changes take time to propagate and can extend the outage if the problem isn't DNS-related.

Check PHP and Server Logs

Match the failure time across Nginx or Apache, PHP-FPM, and application logs. Look for lines like:

upstream timed out (110: Connection timed out) while reading response header from upstream
connect() to unix:/var/run/php/php8.1-fpm.sock failed (111: Connection refused)
PHP-FPM pool www seems busy (you may need to increase pm.start_servers)
AH01071: Got error 'PHP message: PHP Fatal error: Allowed memory size exhausted'

These tell you exactly what broke:

• Upstream timeout: PHP is too slow. Likely a slow plugin, slow query, or an external API call that never returns.
• Connection refused: PHP-FPM crashed or isn't running. The host needs to restart it.
• Pool busy: Not enough PHP workers. Traffic outpaces capacity.
• Memory exhausted: A plugin or theme is using too much memory.

Send the exact log line to your host. "My site is down" gets a slower response than "PHP-FPM pool exhausted at 14:32 UTC, log attached."

Rule Out WordPress Code

If the server is healthy but the 502 returns under load, a plugin or theme is holding PHP workers.

Disable plugins from the dashboard or rename the plugins folder:

wp-content/plugins → wp-content/plugins-disabled

If the site returns, rename the folder back and activate plugins one at a time. Watch for the 502 to return.

Also test a default theme on staging. A slow external API call or a runaway PHP task can hold workers until the gateway gives up.

Check Recent Infrastructure Changes

Review changes to:

• PHP version
• PHP-FPM socket or port
• Proxy addresses
• Container or origin IP
• SSL certificates
• Firewall allowlists

In an Nginx/PHP-FPM setup, the upstream address in the Nginx config must match the service that's actually listening. A mismatch produces an instant 502.

Verify the Recovery

Load uncached and cached pages. Log in. Save a post. Watch the logs for renewed upstream errors.

If traffic caused worker exhaustion, restarting PHP only buys time. The slow request or capacity limit still needs a real fix. Otherwise the 502 comes back during the next traffic spike.

Before You Close the Ticket

Most 502 errors come down to one of these: PHP-FPM crashed, PHP workers exhausted, a slow plugin holding requests, or a config mismatch between Nginx and PHP-FPM. Read the log first. Fix the cause, not the symptom.