How to Fix the 502 Bad Gateway Error in WordPress.

A 502 Bad Gateway error means one server asked another server for your page and got back a broken response, or none at all. On a WordPress site, the server that failed is almost always PHP: the part that actually runs WordPress.

Most WordPress hosts put a web server such as Nginx in front of PHP, and many sites also sit behind Cloudflare. When PHP crashes, runs out of time, or isn’t running, the server in front of it has nothing valid to send you, so it shows a 502. This guide shows how to work out which link in that chain broke and how to fix it.

Step 1: Rule Out a Temporary Glitch

A 502 is often brief. The PHP process restarts, or a server under heavy load recovers within seconds. Before changing anything:

• Wait a minute and reload the page.
• Open the site in a private window. If it works there but not in your normal browser, see “The 502 only happens for you” below.
• Check your host’s status page, or ask support whether there’s a known issue on your server.

If the error keeps coming back or won’t go away, it has a real cause. Keep going.

Step 2: Find Out Which Server Sent the 502

The error page tells you who generated it:

• A plain white page with “502 Bad Gateway” and “nginx” underneath comes from your host’s Nginx server. PHP behind it failed.
• A Cloudflare-branded page shows three boxes (Browser, Cloudflare, Host) and marks the failing one. If “Host” shows an error, Cloudflare reached your server and your server returned the 502, so the problem is on your hosting. If Cloudflare itself is marked, it’s usually temporary on Cloudflare’s side.
• A page styled by your host (many managed hosts have their own) means their proxy couldn’t get a response from PHP.

If your site is behind Cloudflare and you can’t tell, temporarily pause Cloudflare for the site (Overview → Pause Cloudflare on Site) and reload. If the 502 persists, the problem is on your server.

Step 3: Check the Error Logs

In your hosting panel, open the error logs (sometimes split into “Nginx error log” and “PHP error log”). The line logged at the moment of the 502 usually names the cause directly:

• connect() to unix:/run/php/php-fpm.sock failed (111: Connection refused) while connecting to upstream: PHP isn’t running at all. See Fix 1.
• upstream prematurely closed connection while reading response header from upstream: PHP started the request but died before finishing. That points to a crash, a memory problem, or a time limit. See Fixes 2 and 3.
• upstream timed out (110: Connection timed out): PHP took too long. This usually shows as a 504, but some setups return a 502. See Fix 3.
• upstream sent too big header while reading response header from upstream: the response headers, often cookies, were bigger than Nginx allows. See Fix 5.

Also turn on the WordPress debug log (the three lines in our critical error guide) and check wp-content/debug.log for a PHP Fatal error at the same time.

Fix 1: Restart PHP

If PHP has stopped or hung, restarting it clears the 502 immediately. Most hosting panels have a way to do this:

• Look for a Restart PHP or Restart services button in the PHP or advanced settings.
• If there isn’t one, switching the site to a different PHP version and then back again restarts PHP on most hosts.
• On a VPS with SSH access, restart the PHP-FPM service, for example sudo systemctl restart php8.3-fpm (match the version you run).

If the 502 comes back soon after, PHP is being crashed or overwhelmed by something. Find out what with the fixes below rather than restarting over and over.

Fix 2: Find the Plugin or Theme Crashing PHP

A plugin or theme that crashes PHP, or uses far more memory than allowed, kills the PHP process mid-request, and the server in front returns a 502. This is especially likely if the error started right after an update.

• Check debug.log for a fatal error naming a plugin or theme folder.
• If nothing is logged, rename wp-content/plugins to plugins-off over SFTP and reload. If the 502 goes away, rename it back and reactivate plugins one at a time. See deactivating plugins when you’re locked out.
• If plugins aren’t the cause, rename your active theme’s folder so WordPress falls back to a default theme.

Also try switching to the previous PHP version in your hosting panel. Some extensions and older plugins crash on newer PHP releases.

Fix 3: The 502 Only Happens on Heavy Tasks

If the site loads normally but you get a 502 during specific actions, such as running an import, generating a backup, bulk-editing products, or loading a large report, that request is running longer or using more memory than PHP allows. PHP stops it, and the server in front returns a 502.

• Raise PHP’s max_execution_time and memory_limit in your hosting panel’s PHP settings. 300 seconds and 256M or 512M are common for heavy tasks.
• Raise WordPress’s own memory limit with define( 'WP_MEMORY_LIMIT', '256M' ); in wp-config.php. Our memory exhausted guide explains the difference.
• Break the job into smaller batches if the plugin supports it, or run it at a quiet time.
• On shared hosting, the proxy timeout may be fixed. Ask your host, or run long jobs with WP-CLI if they provide SSH access.

Fix 4: Too Much Traffic for Your PHP Workers

Each PHP request needs a free PHP worker. If all of them are busy, new requests queue up and eventually fail, sometimes as 502s and more often as 503 or 504 errors. That happens during a traffic spike, a bot attack hammering wp-login.php or xmlrpc.php, or when slow plugins keep workers busy for too long.

• Check your host’s resource or traffic stats for spikes at the time of the errors.
• Make sure page caching is working (for example LiteSpeed Cache or your host’s cache), so most visitors never need PHP at all.
• Block abusive traffic with Cloudflare or your security plugin, and block xmlrpc.php if you don’t use it.
• If normal traffic is simply too much for your plan, you need more PHP workers or a bigger plan.

Fix 5: The 502 Only Happens for You

If the site works in a private window or on another device, the problem is in your browser. The usual cause is cookies: very large or numerous cookies make the request headers too big, and Nginx rejects the response with a 502 (the “too big header” log line above).

• Clear cookies for your site and reload.
• If it keeps happening, a plugin is setting too many cookies. Check DevTools → Application → Cookies to see which ones are large.
• On a VPS, raising fastcgi_buffer_size and fastcgi_buffers in the Nginx config fixes it for good. On managed hosting, ask your host.

Still Getting a 502?

If the logs show nothing useful, plugins and theme are ruled out, and PHP restarts don’t help, the problem is on the server itself. Send your host the exact time of the errors, the URLs, and any log lines you found. Those details let them check the PHP-FPM and proxy logs on their side instead of asking you to clear your cache.

Summary

A 502 means the server in front of PHP got no valid response. Reload first, then check who sent the error page and what the error log says at that moment. Restart PHP if it’s stopped, find any plugin or theme that crashes it, raise limits for heavy tasks, make sure caching protects your PHP workers, and clear cookies if only you see the error.