Fixing 502 and 504 errors on WordPress

A 502 means the proxy in front of your site asked PHP for a page and got a broken answer back. A 504 means it asked, waited, and gave up. Your first move is the same for both: if you changed anything in the past hour, a plugin update, a theme edit, a new snippet, revert it, because these errors usually follow a change. If nothing changed, work down the list: memory exhaustion first, then a PHP process that keeps dying, then a request hung on something external, then the proxy or CDN layer. The error log tells you which one you have, usually within minutes.

What the codes actually mean

WordPress pages are served by a chain. The visitor hits a web server, the web server hands the request to PHP, PHP talks to the database, and the finished HTML travels back out. In front of all this sits a proxy, Nginx on most stacks, sometimes a CDN as well, and its job is to wait for PHP and relay the response.

A 502 Bad Gateway is the proxy reporting that the answer it received was broken: the PHP process crashed, was killed for exceeding its memory allowance, or dropped the connection mid-reply. A 504 Gateway Timeout is the proxy reporting that PHP never finished inside the time it was allowed. Both point behind the proxy, which is the messenger; restarting things at random rarely helps.

Four questions that halve the search

All pages, or one? Errors on every URL point at PHP, the database, or the host itself. Errors on a single page or a single action point at a plugin or one slow query.

After a change, or out of nowhere? A plugin update, a core update, a deploy, or a new piece of code in the hour before the errors started is the prime suspect until proven otherwise.

Just you, or everyone? Ask someone on another network, or check from your phone with wifi off. If the site loads for other people, they may be seeing a cached copy while you see the live error, a clue in itself.

Constant, or bursts? A few seconds of 502s during a deploy is the proxy watching PHP restart, and it fixes itself. Errors that persist, or that grow as traffic grows, need the full diagnosis.

The diagnosis order

Memory exhaustion comes first, because it is the most common and the fastest to confirm. When a PHP request tries to use more memory than its limit allows, the process is killed, the proxy gets a broken answer, and the visitor gets a 502. The evidence is a log line naming "allowed memory size" and "exhausted". Find it in your host's PHP error log, or switch on debugging in wp-config.php and read wp-content/debug.log. Your current limit is visible in the admin under Tools, Site Health, Info. Raising it, in the hosting panel or the PHP configuration, buys immediate room. It does not fix the cause: something is eating the memory, and the log line usually names the plugin or theme responsible. A site that keeps needing its limit raised is asking you to find the eater.

A crashing PHP process comes second. The pattern is intermittent 502s, the site fine between them, and no memory errors in the log. Restarting PHP from the hosting panel usually clears it; if it returns, the PHP-FPM error log is where the crash reason lives, and that log is worth pasting into a support ticket whole.

A hung external call comes third. Plugins phone home: licence checks, currency rates, feed fetches, mail sent while the visitor waits. If the remote service hangs, PHP waits with it, and the proxy eventually returns a 504 for that page while the rest of the site behaves. Deactivate the suspect and reload the page; if the problem follows the plugin, you have it. Query Monitor, a free plugin, shows every outbound HTTP call and how long each took, turning guesswork into reading.

The proxy and CDN layer comes last, because it is the least likely. If you can fetch the site directly from the origin while visitors still see errors, the problem sits in the middle: a host-side configuration change, or the CDN edge. Cloudflare and similar services use their own error codes for "the origin misbehaved" and give each event a trace ID their support can look up. Thirty seconds on your host's status page is time well spent.

The classic culprits

A plugin stuck in a loop, retrying an external call or redirecting to itself, until something upstream gives up. An update that finished halfway and left two file versions mixed; the fix is to run the update again or reinstall WordPress core from the Updates screen. A server that is too small for the traffic now hitting it, where every PHP worker is busy, the queue grows, and the proxy starts returning 504s; the access log's request count at the minute of the incident, next to your usual rate, settles that question. A database lock, where one long query or a stuck write holds a table and everything else queues behind it; the database process list shows the query running while the others wait.

The recovery path

Revert the recent change first. Plugin updates can be rolled back from the plugin's page where a rollback is offered, and theme or code changes undo through SFTP or your host's file manager, which you can reach even when WordPress is down. If you are locked out of the admin entirely, rename the plugins folder over SFTP, which stops all plugins loading, then restore the name and reactivate plugins one at a time to find the offender.

Then read the error log before changing anything else. Every step above is a guess until the log converts it into a fact, and most incidents of this kind are one log line away from a named cause. Fix what the log names: raise the memory limit or evict the plugin eating it, complete the broken update, kill or wait out the locked query, and note what the log said.

If the cause turns out to be traffic instead of a fault, the server was telling you it is full. The same pressure that produces 504s under load shows up earlier as a sluggish admin and slow uncached pages, so our guide to a slow WordPress admin covers the shared causes, and the server size calculator turns your traffic numbers into a sizing decision before the next spike arrives.