You open your website and see a blank page. In the middle sits one short line: 502 Bad Gateway<\/strong>. There is no menu, no logo, no content. Your dashboard will not open either. For a store, every minute of this costs you orders.<\/p>\n The message is short, so it feels like a dead end. It is not. A 502 is one of the most fixable WordPress errors, once you know what it is telling you.<\/p>\n A 502 error is a message from one server about another server. Your web server received a request for a page. It passed that request to a second program. That program was supposed to build the page and hand it back. Instead it sent back something broken, or nothing at all. Your web server could not use the reply, so it gave up and showed a 502.<\/p>\n In WordPress, that second program is almost always PHP. PHP is the language WordPress is written in. Every page on your site is built by PHP before a visitor sees it. If PHP crashes, stalls, or runs out of memory, the web server is left holding an empty reply. That is a 502.<\/p>\n Most 502 errors start with an ordinary change. A plugin updates itself overnight. Your host moves you to a newer PHP version. A traffic spike fills every worker process. A caching plugin or a CDN sits in front of the site and forwards a broken reply. A backup job eats all the memory at 3am. None of these are exotic. They happen on healthy sites every week.<\/p>\n This guide walks you through the whole problem. You will learn the signs that confirm you really have a 502. You will see the ten real reasons it happens. Each one gets a matching fix. At the end you get the habits that stop it coming back. Work through the steps in order. The early steps are safe and take a minute. The later ones go deeper into your server.<\/p>\n Several WordPress errors look alike from the outside. Before you change anything, make sure you are chasing the right one. Here is what a 502 actually looks like.<\/p>\n The page is nearly empty.<\/strong> You get white space and a single line of text. It may say “502 Bad Gateway”, “502 Server Error”, or “HTTP Error 502”. Sometimes there is a second line naming the web server, such as nginx. Your theme does not load at all. That is the giveaway: WordPress never ran, so it could not draw your design.<\/p>\n The error page is not styled like your site.<\/strong> A WordPress error usually still carries some of your fonts or colours. A 502 does not. It comes from the web server, one level above WordPress. So it is plain and ugly.<\/p>\n The dashboard is down too.<\/strong> Try loading your login page. If that also shows 502, the problem is server wide. If the front of the site fails but the dashboard opens, the fault is narrower, and you have somewhere to work from.<\/p>\n It comes and goes.<\/strong> This is very common with 502. You reload and the page appears. You reload again and it breaks. That flicker points at load, memory, or worker limits rather than broken code. Steady, permanent 502 on every page points at a crashed service or a fatal error.<\/p>\n Only some pages fail.<\/strong> Heavy pages break first. A shop page with many products, a search result, or an admin screen may fail while your simple contact page is fine. That pattern points at resources, not at the whole server being down.<\/p>\n Logged-out visitors see it but you do not.<\/strong> Your page cache may be serving you a saved copy while real visitors hit PHP and fail. Open your site in a private browsing window to check what strangers really see.<\/p>\n It is not one of these.<\/strong> A 503 Service Unavailable error<\/a> means the server is up but deliberately refusing work, often during an update. A 500 Internal Server Error<\/a> means PHP ran and then failed inside your site. A 504 Gateway Timeout error<\/a> means PHP was still working and simply took too long. A 502 means the reply arrived broken.<\/p>\n A 502 is a symptom, not a cause. Ten things commonly break the link between your web server and PHP. Read them all before you start fixing. Knowing which one fits your site saves a lot of guesswork later.<\/p>\n Caches save a copy of what your server sent and reuse it. Your browser does this. So does a page cache plugin. So does a CDN like Cloudflare. If any of them saved the 502 page, they will keep handing it out after the real fault is gone. The site is healthy, but nobody can tell. This is why the very first step is a proper reload, not a server change.<\/p>\n On most modern hosts, PHP runs as a separate background service called PHP-FPM. Your web server talks to it through a socket file or a network port. If that service has stopped, crashed, or been restarted onto a different socket, the web server knocks and nobody answers. It cannot report “PHP is down” to your visitor, so it reports 502. This often follows a server reboot or a PHP version change.<\/p>\n Every PHP request gets a memory allowance. WordPress, your theme, and every active plugin share it. Image work, imports, and page builders are hungry. When the allowance runs out, PHP stops mid-job. The reply is cut off halfway, so the web server sees a broken response. On small servers the operating system may also kill the whole PHP process to protect itself, which produces the same result.<\/p>\n PHP-FPM keeps a pool of worker processes. Each worker handles one request at a time. The pool has a maximum size, set by a value called Your web server will not wait forever for PHP. On nginx the wait is controlled by Before the page content, PHP sends a block of headers. These carry cookies, redirects, and security settings. Your web server reserves a small, fixed amount of memory to read that block. Sites with many cookies, long session data, or big security headers can produce a header block that does not fit. The web server cannot read the reply properly, so it calls it invalid and returns 502. This one is easy to miss because the site works fine for logged-out visitors and breaks only for logged-in users.<\/p>\n A fatal error stops PHP dead. Bad code in a plugin, a half-finished update, a missing file, or two plugins fighting over the same function will all do it. When PHP dies partway through writing a page, the web server receives a truncated reply. That is invalid, so you get a 502. A fatal error more often causes a 500 error. It produces a 502 instead when the process dies before any usable output is sent.<\/p>\n Hosts upgrade PHP regularly, sometimes automatically. Newer PHP versions remove old functions. An older theme or an abandoned plugin may still call one of them. That call fails instantly and takes the worker down with it. The site was fine yesterday and broken today, with no change made by you. This is one of the most common causes of a sudden 502 on an older site.<\/p>\n A web application firewall sits between the visitor and your site and inspects traffic. A server firewall does something similar at network level. If either one decides a request is dangerous, it can cut the connection while PHP is mid-reply. The web server then sees a half-finished response. False positives are common after a security plugin update or a new rule set.<\/p>\n If you use Cloudflare or a similar service, there are two servers in the chain, not one. Cloudflare’s own documentation explains the difference. A Cloudflare-branded 502 page means your own server returned a 502. A plain, unbranded 502 page means the problem sits with Cloudflare. Cloudflare also notes that a compression mismatch at your origin can cause this, such as sending gzip-compressed content with the wrong content length. Knowing which server produced the error tells you where to look.<\/p>\n Work through these steps in order. Each one matches a cause above. Each one tells you how to check whether that cause is yours before you change anything, and how to confirm the fix worked. Stop as soon as the site comes back.<\/p>\n A warning before you begin. Several of these steps touch server settings, the This step addresses the first cause: a saved copy of the error page outliving the real fault. Caches do not know the difference between a good page and a broken one. Once a 502 is stored, it keeps being served.<\/p>\n Confirm this is your cause first. Open your site in a private or incognito browser window. If it loads there but still fails in your normal window, your browser is the culprit. If it fails in both, try adding a meaningless question mark string to the address, such as Now clear things in order. Do a hard reload in your browser first, which is Ctrl and F5 on Windows or Command, Shift and R on a Mac. Then open your WordPress dashboard, if you can reach it, and find your caching plugin’s settings. Every major caching plugin has a single button to empty all caches. Use that. If you use Cloudflare, log in to your Cloudflare dashboard, open the caching section for your domain, and run a full cache purge. Some hosts also run their own server cache, which you clear from your hosting control panel.<\/p>\n To verify, close the private window, open a fresh one, and load your home page. If the site appears, you are done, and the real fault has already passed. If the 502 comes straight back, the fault is live and you should move on to the next step.<\/p>\n This step addresses the second cause: PHP-FPM being stopped or listening in the wrong place. If the service is not there, nothing else you change will help.<\/p>\n Confirm it first. Log in to your hosting control panel and look for a PHP section, often called PHP Manager, PHP Settings, or Select PHP Version. Many panels show whether the PHP service is running and which handler is in use. A healthy site shows PHP-FPM running on your current PHP version. If you have server access, your web server’s error log is even clearer. Look for the phrase “connect() failed” or “Connection refused” next to a socket path. That is your web server knocking on a door with nobody behind it.<\/p>\n The fix is usually a restart. In most control panels there is a restart option next to the PHP service. Use it. On a managed host, open a support ticket and ask them to restart PHP-FPM for your account. This is a routine request and they will not mind. If you manage your own server, restart the PHP-FPM service and then reload the web server so it picks up a fresh connection. If the service refuses to start, the log will say why. The reason is normally a bad line added to a config file recently.<\/p>\n Verify by loading your home page and your login page. Both should respond. If PHP starts and then crashes again within minutes, you have an underlying fault, and Steps 3, 4 and 7 will find it.<\/p>\n This step addresses the third cause: PHP running out of memory and dying mid-reply. A cut-off reply is exactly what triggers a 502.<\/p>\n Confirm this is your cause before changing anything. If you can reach your dashboard, open the Tools menu and go to Site Health, then the Info tab. Expand the Server section and read the PHP memory limit. Anything at or below 128 megabytes is tight for a modern site with a page builder or a shop. Next, turn on error logging so you can see memory failures in writing. Edit your WordPress will then write problems to a file at One typo in The first sets the limit for the public side of your site. The second sets it for the dashboard and background jobs. One important catch: WordPress cannot go above the limit your host sets for PHP itself. If your host caps PHP at 128 megabytes, these lines will do nothing. Raise the PHP limit in your control panel too, or ask your host to raise it.<\/p>\n Verify by reloading Site Health and checking the new memory figure has taken effect. Then load the page that was failing. If the 502 is gone, remove the debug lines from This step addresses the fourth cause: every PHP worker being busy, so new requests have nowhere to go. It is the usual explanation for a 502 that appears at busy times and clears when traffic drops.<\/p>\n Confirm it first. The evidence lives in your PHP-FPM log. Ask your host for it, or find it in your control panel’s log viewer. You are looking for a warning that says the server reached The fix depends on your hosting. On shared hosting you usually cannot change this yourself. Send your host the log line instead. Ask them to raise the worker limit for your account. On a VPS or a managed plan with a control panel, look for a PHP-FPM pool settings screen and raise the maximum children value. Do not simply set a huge number. Each worker uses memory, often 60 to 100 megabytes on a plugin-heavy WordPress site. Setting too many workers causes the server to run out of memory, which brings back the 502 for a different reason. Raise it in modest steps and watch memory use after each change.<\/p>\n There is a second half to this fix that costs nothing. Fewer, faster requests need fewer workers. Turn on full page caching so most visitors never reach PHP at all. Our guide to fixing page speed issues in WordPress<\/a> covers how to set this up properly.<\/p>\n Verify by watching the site through your next busy period. The max_children warning should stop appearing in the log, and the intermittent 502 should stop with it.<\/p>\n This step addresses the fifth cause: PHP taking longer than the web server is willing to wait. The connection is cut, and the half-formed reply becomes a 502.<\/p>\n Confirm this is your cause by timing the failure. Load the page that breaks and count. If the 502 appears at almost exactly 30 or 60 seconds every single time, a timeout is cutting it off. A random delay points elsewhere. Also note what you were doing. Timeouts almost always hit during a big import, a backup, a bulk product update, or a plugin installation, not on your home page.<\/p>\n The fix has two halves that must agree with each other. On the web server side, the read timeout needs raising. On nginx that is On shared hosting you can usually change Verify by repeating the exact action that failed. If it now completes, the timeout was the problem. Treat this as a temporary fix, though. A page that needs five minutes has something wrong with it. Our guide to the maximum execution time exceeded error<\/a> goes deeper into why scripts run long.<\/p>\n This step addresses the sixth cause: response headers too large for the buffer your web server set aside. It is worth checking whenever the 502 only affects logged-in users or one specific page.<\/p>\n Confirm it first. The symptom is very distinctive. Log out and browse the site: it works. Log back in and the same page returns 502. Sites with many cookies, a membership plugin, or a long redirect chain fit this pattern. Your web server’s error log confirms it outright. Look for a line saying “upstream sent too big header” next to the failing address. That message is the whole diagnosis.<\/p>\n The fix is to give the web server more room to read those headers. This is a server configuration change, so take a backup of the configuration file first and, if possible, test on staging. On nginx you add buffer settings inside the server block that handles PHP:<\/p>\n Then test the configuration and reload nginx. On shared hosting you cannot edit this, so send your host the “too big header” log line and ask them to raise the buffers. They will recognise it immediately.<\/p>\n Verify by logging in and loading the page that failed. If it now works while logged in, the buffers were the cause. If it still fails, look at how many cookies your site sets. Some plugins add far more than they need.<\/p>\n This step addresses the seventh cause: a fatal error in plugin or theme code killing the worker before it can finish the page. It is the single most common reason a healthy site breaks overnight.<\/p>\nSigns That Show a 502 Bad Gateway Error in WordPress<\/h2>\n
Reasons Why the 502 Bad Gateway Error in WordPress Happens<\/h2>\n
1. A Cached Copy of the Error Page Is Still Being Served<\/h3>\n
2. PHP Is Not Running, or Is Listening in the Wrong Place<\/h3>\n
3. PHP Has Run Out of Memory<\/h3>\n
4. Every PHP Worker Is Busy<\/h3>\n
pm.max_children<\/code>. When all workers are busy, new requests queue up. If the queue also fills, the web server cannot hand the request over at all, and it returns 502. This is the classic cause of a 502 that flickers on and off during busy periods.<\/p>\n5. PHP Takes Longer Than the Gateway Will Wait<\/h3>\n
fastcgi_read_timeout<\/code>, which defaults to 60 seconds. On Apache it is the Timeout<\/code> or ProxyTimeout<\/code> setting, also 60 seconds by default. When the wait runs out, the connection is torn down. Depending on the stack, that shows as either a 504 or a 502. Long imports, backups, and slow queries are the usual triggers.<\/p>\n6. The Response Headers Are Too Big for the Buffers<\/h3>\n
7. A Plugin or Theme Is Throwing a Fatal Error<\/h3>\n
8. Your PHP Version No Longer Suits Your Site<\/h3>\n
9. A Security Plugin, Firewall, or WAF Is Killing the Request<\/h3>\n
10. A CDN or Proxy Cannot Get a Clean Reply From Your Server<\/h3>\n
How to Fix the 502 Bad Gateway Error in WordPress (Step by Step)<\/h2>\n
wp-config.php<\/code> file, or plugin files. A mistake there can take a working site down. Take a full backup first, or make your changes on a staging copy. Our guide to backing up WordPress with UpdraftPlus<\/a> shows how to get one in a few minutes. Each risky step below repeats this warning where it applies.<\/p>\nStep 1: Force a Real Reload and Clear Every Cache<\/h3>\n
?test=1<\/code> on the end. A cache usually treats that as a new page. If that version loads, a cache is holding the old error.<\/p>\nStep 2: Check That PHP Is Actually Running, Then Restart It<\/h3>\n
Step 3: Raise the PHP Memory Limit<\/h3>\n
wp-config.php<\/code> file and add these lines above the comment that says to stop editing:<\/p>\ndefine( 'WP_DEBUG', true );\r\ndefine( 'WP_DEBUG_LOG', true );\r\ndefine( 'WP_DEBUG_DISPLAY', false );<\/code><\/pre>\nwp-content\/debug.log<\/code>. Reload the broken page, then open that file. A line containing “Allowed memory size” and “exhausted” confirms memory is your problem.<\/p>\nwp-config.php<\/code> can break your site. Download a copy of the original file before you save the new one. To raise the limit, add these two lines in the same place:<\/p>\ndefine( 'WP_MEMORY_LIMIT', '256M' );\r\ndefine( 'WP_MAX_MEMORY_LIMIT', '512M' );<\/code><\/pre>\nwp-config.php<\/code>, because leaving debugging on a live site is not safe. If the error remains, keep the debug log on and continue.<\/p>\nStep 4: Check the PHP Worker Pool and Raise It<\/h3>\n
pm.max_children<\/code>, often with advice to raise it. That line is proof. A softer clue is timing: note whether the 502 appears during your busiest hour, or right after you send a newsletter, and disappears overnight.<\/p>\nStep 5: Raise the Gateway Timeout and the PHP Execution Time<\/h3>\n
fastcgi_read_timeout<\/code>, which defaults to 60 seconds. On Apache it is Timeout<\/code> or ProxyTimeout<\/code>, also 60 by default. On the PHP side, max_execution_time<\/code> controls how long a script may run. The golden rule is that the web server timeout must be equal to or greater than the PHP execution time. If PHP is allowed 300 seconds but the web server only waits 60, you will still get an error at 60 seconds.<\/p>\nmax_execution_time<\/code> yourself in your control panel’s PHP settings, but not the web server timeout. Ask your host to raise the read timeout to match. On your own server, edit the values in your nginx or Apache configuration and restart the service. A syntax mistake in a web server config file can take the whole server offline. Keep a copy of the original file. Test the configuration before you reload it.<\/p>\nStep 6: Increase the FastCGI Buffer Sizes<\/h3>\n
fastcgi_buffer_size 32k;\r\nfastcgi_buffers 16 16k;\r\nfastcgi_busy_buffers_size 32k;<\/code><\/pre>\nStep 7: Find the Plugin or Theme That Is Crashing PHP<\/h3>\n