502 Bad Gateway on WordPress: What It Means and How to Fix It Fast

The error that means your server is fighting itself

A 502 Bad Gateway is different from most WordPress errors. It does not come from WordPress at all. It comes from the web server — Nginx, Apache, or a reverse proxy like Cloudflare — telling you that it tried to reach the backend process that runs WordPress, and that process did not respond.

Think of it like calling a phone number and hearing a disconnected tone. The phone network works. Your phone works. But the person you are trying to reach is not picking up. In this case, the "person" is PHP-FPM — the process that executes your WordPress code — and it has either crashed, timed out, or run out of capacity.

The 502 error is especially dangerous because it affects your entire site. Not one page. Not one feature. Everything. Every URL returns the same error. Your homepage, your blog, your contact form, your checkout — all gone. And unlike some WordPress errors that only appear intermittently, a 502 often persists until the underlying cause is resolved.

The good news is that a 502 returns a clear HTTP status code, which means monitoring can detect it instantly. The bad news is that the causes range from simple (a PHP restart) to complex (server resource exhaustion under load). Here is every major cause and how to fix each one.

1. PHP-FPM crashed or stopped running

PHP-FPM (FastCGI Process Manager) is the service that processes PHP code on most modern WordPress hosting setups. It runs as a separate service from your web server. When a visitor requests a page, Nginx or Apache passes the request to PHP-FPM, which executes the WordPress code and returns the HTML. If PHP-FPM crashes or stops running, the web server has nothing to pass requests to. Every request fails with a 502.

PHP-FPM can crash because of a segmentation fault in a PHP extension, a corrupted OPcache, a fatal error in a PHP file that runs on every request (like wp-config.phpor a must-use plugin), or an out-of-memory condition that kills the process. On managed hosting, the provider's process monitor usually restarts PHP-FPM automatically within a few seconds. On self-managed servers, it may stay down until you restart it manually.

How to fix it: Check if PHP-FPM is running. On the command line: systemctl status php-fpm (or php8.2-fpm depending on your setup). If it is stopped, restart it: systemctl restart php-fpm. Check the PHP-FPM error log for the crash reason — usually at /var/log/php-fpm/error.log or /var/log/php8.2-fpm.log. If you are on shared hosting and cannot access these commands, contact your hosting provider. They can restart PHP-FPM for you and check the logs.

2. Upstream server overload — all PHP workers are busy

PHP-FPM uses a pool of worker processes. Each worker handles one request at a time. The number of workers is configured in your PHP-FPM pool configuration (usually pm.max_children). When every worker is busy and a new request arrives, one of two things happens: the request waits in a queue until a worker becomes available, or — if the queue is full or the wait exceeds the timeout — the web server gives up and returns a 502.

This is the most common cause of intermittent 502 errors. Your site works most of the time. But during traffic spikes, when a bot crawls your site aggressively, or when a slow database query ties up workers for several seconds each, the pool runs out of available workers. Some requests get through. Others get a 502. It looks random to your visitors.

How to fix it: Check your PHP-FPM status page or run ps aux | grep php-fpm to see how many workers are running versus your pm.max_children setting. If all workers are consistently busy, increase pm.max_children. But be careful — each worker consumes memory (typically 20-50MB for WordPress). If you increase workers beyond what your server's RAM can support, you will trade 502 errors for out-of-memory crashes. The real fix is often to optimise slow queries, add page caching, and reduce the amount of work each PHP request has to do. Refer to the Nginx upstream module documentation for tuning proxy settings.

3. Reverse proxy timeout

When Nginx acts as a reverse proxy in front of PHP-FPM, it has a timeout setting — proxy_read_timeout — that defines how long it will wait for PHP-FPM to respond. The default is often 60 seconds. If a WordPress request takes longer than this timeout — a large WooCommerce order, a heavy report generation, a slow database migration — Nginx stops waiting and returns a 502.

You might also hit this if you use Cloudflare or another CDN as a reverse proxy. Cloudflare has its own timeout (100 seconds on the free plan) and returns a 502 if your origin server does not respond within that window. The Cloudflare 502 page looks different — it shows Cloudflare branding and says "Bad gateway" with a "Cloudflare" identifier.

How to fix it: For Nginx, increase the timeout values in your site configuration:

proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_send_timeout 300;

If you use fastcgi_pass instead of proxy_pass, the equivalent settings are fastcgi_read_timeout, fastcgi_connect_timeout, and fastcgi_send_timeout. For Cloudflare, you cannot increase the timeout beyond 100 seconds on the free plan (Enterprise plans allow longer). Optimise the slow request instead — add caching, optimise the database query, or move the heavy operation to a background process.

4. Hosting resource limits

Shared hosting and even some managed WordPress hosts impose hard limits on CPU time, memory, number of processes, and number of simultaneous connections. When your site exceeds any of these limits, the hosting provider's resource manager kills the offending process. If it kills PHP-FPM workers, the web server returns 502 errors until the resource usage drops below the limit.

This often happens during traffic spikes, heavy cron jobs, or when a plugin runs a resource-intensive operation like importing products, generating reports, or sending bulk emails. The hosting provider's control panel may show a "Resource Limit Reached" message, but this message is not always displayed — sometimes you just get a generic 502.

How to fix it: Check your hosting control panel for resource usage metrics. If you are consistently hitting limits, you need either a better hosting plan or a more efficient site. Optimise your site: add page caching (WP Super Cache or W3 Total Cache), optimise images, reduce the number of plugins, and ensure your database is indexed properly. If traffic spikes are the trigger, consider a CDN to serve static assets and reduce the load on your server. If you are on shared hosting and hitting limits regularly, it is time to upgrade to a VPS or managed WordPress host. Refer to the WordPress optimization documentation for performance tuning guidance.

5. Corrupted OPcache

OPcache is a PHP extension that caches compiled PHP bytecode in memory so PHP does not have to parse and compile the same files on every request. It dramatically improves performance. But if the cache becomes corrupted — due to a failed deployment, a disk error, or a PHP version upgrade — PHP-FPM can crash or return garbage data. The web server receives an invalid response and returns a 502.

How to fix it: Restart PHP-FPM, which clears the OPcache. If the problem recurs, add opcache.validate_timestamps=1 to your php.ini so OPcache checks for file changes. On deployments, use opcache_reset() or restart PHP-FPM as part of your deployment script to ensure the cache is fresh.

6. Database connection exhaustion

Every WordPress page load requires multiple database queries. If your database server runs out of available connections — because too many PHP workers are holding connections simultaneously, because a slow query is blocking other queries, or because the database server itself is overloaded — PHP-FPM workers hang waiting for a database response. They hit the timeout. Nginx gets no response. 502 Bad Gateway.

This looks similar to a PHP-FPM overload but the root cause is the database. You might also see the "Error Establishing a Database Connection" message on some requests while others get 502 — depending on which error surfaces first.

How to fix it: Check your database server's connection count and slow query log. Increase max_connections in your MySQL or MariaDB configuration if you are running out. Identify and optimise slow queries — a single query that takes 10 seconds blocks a PHP worker and a database connection for that entire duration. Add object caching (Redis or Memcached) to reduce the number of database queries per page load.

Why the 502 is actually the easiest WordPress error to monitor

Unlike the critical error or the White Screen of Death, which can return a 200 OK status while showing an error, the 502 Bad Gateway returns a clear 502 HTTP status code. Any HTTP monitor that checks for a 200 response will catch it immediately. This makes the 502 the one WordPress error where standard uptime monitoring actually works as expected.

But there is a caveat. If you use Cloudflare, a CDN, or a caching reverse proxy, the caching layer might serve a cached version of the page even when the origin returns a 502. Your monitor checks the cached page, gets a 200, and reports everything as fine. Your cache eventually expires, and then the 502 is exposed to visitors. Adding keyword monitoring alongside HTTP monitoring catches this edge case.

How to detect 502 errors with Uptrue

Uptrue's HTTP monitoring checks your site every 60 seconds and alerts you the moment it receives a non-200 response. Combined with keyword monitoring, you catch 502 errors whether they come from the origin server or are hidden behind a caching layer.

Step 1: Set up an HTTP monitor to catch 502 status codes

1. Sign up at uptrue.io/signup (free plan available)
2. Click Add Monitor from your dashboard
3. Select HTTP/HTTPS as the monitor type
4. Enter your homepage URL
5. Set expected status to 200
6. Set the check interval to 1 minute
7. Configure alerts — Slack, email, or Microsoft Teams

The moment your site returns a 502 instead of 200, Uptrue triggers an alert. Uptrue uses a two-confirmation check — if the first check fails, it retries from a different location before alerting. This eliminates false positives from momentary network issues while still catching real 502 errors within two minutes.

Step 2: Add a keyword monitor for CDN-cached sites

1. Click Add Monitor again
2. Select Keyword as the monitor type
3. Enter your homepage URL
4. Set the keyword to "Bad Gateway"
5. Set the check type to "Page must NOT contain"
6. Set the interval to 1 minute

Some CDN and caching configurations intercept the 502 and serve a custom error page with a 200 status code. The page often contains the text "Bad Gateway" or "502." This keyword monitor catches those cases.

Step 3: Add a positive keyword monitor for content verification

1. Add another Keyword monitor for your homepage
2. Set the keyword to your site title, tagline, or a navigation item that always appears
3. Set the check type to "Page must contain"
4. Set the interval to 1 minute

This is your safety net. If your normal content disappears for any reason — a 502, a white screen, a critical error, a hacked page, or anything else — you know something is wrong. It does not matter what specific error replaced your content. If your expected content is gone, Uptrue alerts you.

Step 4: Monitor critical inner pages

502 errors usually affect the entire site, but not always. A specific PHP-FPM pool configured for a subdomain, or a plugin that only loads on certain pages, could cause 502 errors on specific URLs while the rest of the site works. Monitor:

• Homepage
• Checkout or cart page (if you run WooCommerce)
• Contact page
• API endpoints that serve your mobile app or integrations
• Any page receiving paid traffic

Step 5: Configure alerts that reach you immediately

A 502 means your entire site is down. This is not a degraded feature or a broken form — every visitor sees an error. Configure alerts for maximum speed:

• Slack — instant notification in a dedicated channel
• Microsoft Teams — same idea, different platform
• Email — fine as a backup, but not fast enough for full outages
• Webhook — pipe alerts into PagerDuty, Opsgenie, or your own incident management system

Preventing 502 errors before they happen

Monitoring catches the problem fast. But these measures reduce the chances of a 502 hitting your site in the first place.

Right-size your PHP-FPM pool

Calculate the right pm.max_children value for your server. A common formula: divide your available RAM (minus what the OS, database, and web server need) by the average memory per PHP worker. If you have 2GB available for PHP and each worker uses 40MB, set pm.max_children to 50. Monitor actual usage and adjust. Too few workers and you get 502 errors under load. Too many and you get out-of-memory crashes.

Add page caching

Page caching serves static HTML files for most requests, bypassing PHP entirely. A cached page does not need a PHP worker. This dramatically reduces the load on PHP-FPM and makes 502 errors under traffic spikes far less likely. Use a caching plugin like WP Super Cache, W3 Total Cache, or your hosting provider's built-in caching.

Add object caching with Redis or Memcached

Object caching stores database query results in memory so WordPress does not have to query the database on every page load. This reduces both PHP execution time and database load, freeing up PHP workers faster and preventing connection exhaustion. Most managed WordPress hosts include Redis or Memcached.

Optimise slow database queries

A single slow query that takes 5 seconds ties up a PHP worker and a database connection for that entire duration. Install the Query Monitor plugin in development to identify slow queries. Add database indexes where needed. Avoid plugins that run expensive queries on every page load — especially when they query the wp_options table with autoload enabled for large datasets.

Use a CDN for static assets

Images, CSS, JavaScript, and fonts served through a CDN never touch your server. This reduces the total number of requests your server has to handle, leaving more capacity for the dynamic PHP requests that need PHP-FPM workers.

Stop finding out about 502 errors from your visitors

A 502 Bad Gateway takes your entire WordPress site offline. Your homepage, your blog, your checkout, your login — everything returns an error. Unlike some WordPress problems that hide behind a 200 status code, the 502 is honest about what happened. It returns a clear error code that monitoring can detect instantly.

Uptrue checks your site every 60 seconds. The moment a 502 is returned, you know. On Slack, Teams, email, or webhook. Before your visitors complain. Before Google crawls an error page. Before your client calls to ask why their site is down. Under a minute. Every time.

Frequently asked questions