WordPress 502 Bad Gateway and 504 Gateway Timeout: What They Mean and How to Fix Them

On this page

1. Proxy, PHP and upstream in plain words
2. 502 bad gateway vs 504 gateway timeout on WordPress
3. Read the error page first
4. PHP workers: the most common bottleneck
5. Heavy plugins, slow queries and outside services
6. Cloudflare and CDN problems
7. Server limits on shared hosting
8. What to send your host
9. "The gateway did not receive a timely response": what it means
10. Quick check: time the server and see who answered
11. When to get help
12. FAQs

A WordPress 502 Bad Gateway means the server that answered your browser, such as Nginx, LiteSpeed or Cloudflare, got an invalid reply from the server behind it, usually PHP. A 504 Gateway Timeout on WordPress means it waited for that reply and gave up. Both are server-side problems: PHP is overloaded, a plugin or database query is too slow, an outside service is hanging, or the host or CDN is having trouble. Visitors can't fix them by refreshing; you or your host need to find the slow or failing part.

Proxy, PHP and upstream in plain words

When someone opens your site, the request usually passes through several layers before WordPress runs:

1. CDN or proxy (often Cloudflare) receives the visit.
2. Web server (Nginx, Apache or LiteSpeed) on your hosting account receives it next.
3. PHP (PHP-FPM or LSAPI) runs WordPress, your theme and plugins.
4. Database (MySQL or MariaDB) returns posts, settings and orders.
5. Outside services such as payment gateways, shipping APIs or licence servers may be called during the page load.

Each layer is the "upstream" of the one before it. A gateway error is one layer saying the next one let it down. That is why the first job is working out which layer produced the error page.

502 bad gateway vs 504 gateway timeout on WordPress

Error	What it means	Typical WordPress causes
502 Bad Gateway	The upstream replied with something invalid, or the connection was refused or dropped	PHP process crashed or was killed, PHP-FPM not running, all PHP workers busy, origin server down behind Cloudflare
504 Gateway Timeout	The upstream accepted the request but did not answer in time	Slow plugin, heavy database query, outside API that hangs, import or backup running, cron jobs piling up
503 Service Unavailable	The server is refusing work for now	Resource limits hit on shared hosting, maintenance mode, server overloaded
500 Internal Server Error	PHP or the web server failed while running the request	Fatal PHP error, broken .htaccess, memory limit

If you are seeing a 500 instead, the cause is usually a code error rather than capacity; see how to fix a 500 internal server error in WordPress.

Read the error page first

The error page itself tells you which layer failed. Screenshot it first.

• Cloudflare-branded page with "Browser, Cloudflare, Host" boxes: Cloudflare is working and is reporting that your host failed. Cloudflare error codes in the 520 to 524 range point to the origin server too; a 524 means the origin took too long.
• Plain "502 Bad Gateway nginx" or LiteSpeed page: the web server on your hosting account could not get a good reply from PHP.
• Hosting company branded page: often a resource limit or a server-level outage.
• Error only on some URLs such as checkout, search, wp-admin or a report page: that page is doing something slow, not the whole server.

Also note the time, the exact URL and whether you were logged in. Logged-in and wp-admin pages skip the page cache, so they hit PHP every time and fail first when PHP is struggling.

PHP workers: the most common bottleneck

A PHP worker handles one uncached request at a time. If your plan allows a small number of workers and each request is slow, a handful of visitors, a bot crawl or an admin running a report can occupy all of them. New requests queue, and the web server returns a 502 or 504 when they wait too long.

Signs this is your problem:

• Errors come in bursts during busy periods, sales or after you send a newsletter.
• The site recovers by itself after a few minutes.
• wp-admin, cart and checkout fail more often than cached blog pages.
• Your hosting panel shows "entry processes" or "processes" at the limit.

The fix is usually two-sided: make each request faster so workers free up quickly, and make sure most visits are served from cache so they never reach PHP. WordPress caching explained covers which pages can be cached and which cannot. Moving to a recent PHP version also helps, as newer versions run WordPress faster; see how to update PHP safely.

Heavy plugins, slow queries and outside services

A 504 often traces back to one slow thing that happens on every request or on one particular page:

• Plugins that call outside APIs during page load: shipping rate lookups, currency converters, social feeds, licence checks. If that API is slow or down, your page waits for it.
• Heavy database queries: related-product widgets, filters on large WooCommerce catalogues, a bloated wp_options table with large autoloaded data, or years of post revisions.
• Background jobs that run on visitor requests: WP-Cron tasks, Action Scheduler queues in WooCommerce, backup plugins and imports.
• Security or analytics plugins that log every visit to the database.

To find the culprit, use Query Monitor on a staging copy, or deactivate plugins one at a time and test the failing URL. Troubleshooting plugin conflicts walks through a safe way to do this without taking the live site down. If backups or imports cause the errors, schedule them for night hours and move WP-Cron to a real server cron job.

Raising timeouts: a short-term patch

Raising max_execution_time or the proxy timeout can stop a 504 on a long admin task, such as an import. It does not fix a slow site; it just lets requests hold a worker for longer.

Cloudflare and CDN problems

If the error page is Cloudflare's, check these in order:

1. Is the origin up? Ask your host, or check if the site loads directly through the server's address with Cloudflare paused.
2. Is the host blocking Cloudflare? A firewall or security plugin that rate-limits by IP can block Cloudflare's addresses, because all your visitors appear to come from them.
3. SSL mode: "Full (strict)" needs a valid certificate on the origin. A mismatch tends to give 525 or 526 errors rather than 502, but it is worth checking after any SSL change.
4. Long requests: Cloudflare has its own time limit for an origin response. A slow export or report through Cloudflare can hit it even when the host would have waited.

Our Cloudflare setup guide for WordPress covers the settings that avoid most of these.

Server limits on shared hosting

Shared hosting plans cap CPU, memory, processes and sometimes I/O per account. When a site hits a cap, the host may throttle or kill PHP processes, which shows up as 502, 503 or 504 errors. Check your hosting panel's resource usage graphs for the time of the errors.

If the limits are hit by real visitors after caching and plugin clean-up, the site has outgrown the plan. Shared vs VPS vs managed WordPress hosting explains the differences, and if your host is Hostinger, fixing a slow Hostinger website covers the plan-specific checks. If the limits are hit by bots, blocking bad bots at Cloudflare or the firewall is cheaper than upgrading.

What to send your host

A message like "my site is down" gets a generic reply. A message with details gets a useful one:

• The exact error code and a screenshot of the error page.
• Date, time and timezone of each occurrence.
• The URLs affected and whether you were logged in.
• Whether Cloudflare or another CDN is in front of the site.
• A request to check PHP-FPM or LSAPI logs, slow logs and resource limit hits for that time.

Ask specifically whether PHP processes were killed, whether a worker limit was reached, or whether a firewall blocked requests.

"The gateway did not receive a timely response": what it means

Some servers show a longer message instead of a short 504 page: "The gateway did not receive a timely response from the upstream server or application." It is the same problem as a 504 gateway timeout, described in more words. The front server forwarded the request, the application behind it (WordPress running on PHP) took longer than the allowed time, and the front server stopped waiting.

Because it is a timeout, the useful question is "what was slow?" rather than "what is broken?". Check these in order:

1. Does it happen on every page, or only on one action such as saving a long post, running an import, generating a report or checking out?
2. Did it start after a plugin update, a new plugin, a theme change or a PHP version change?
3. Is a backup, security scan or cron task running at the same time each day?
4. Does the hosting panel show CPU, memory or process limits being hit?
5. Is an outside API, such as a payment gateway, shipping rate service or social feed, slow or down?

If it only happens on one heavy action, the fix is usually to make that task lighter, split it into batches or run it outside busy hours. If it happens everywhere, the site has outgrown its PHP workers or hosting plan, or something is flooding it with requests.

Quick check: time the server and see who answered

Two terminal commands tell you how slow PHP is and which layer is sending the error:

curl -s -o /dev/null -w "status %{http_code}  first byte %{time_starttransfer}s  total %{time_total}s" https://yourdomain.com/
curl -sI https://yourdomain.com/ | grep -iE "^(server|cf-ray|cf-cache-status|x-litespeed-cache)"

Run the first one a few times, then again on a page that is not cached, such as the cart or a search URL. A first-byte time that climbs towards your host's timeout points to slow PHP. In the headers, a cf-ray line means Cloudflare is in front, so check whether the error page is Cloudflare's or your server's. Include these numbers in your message to the host.

If the page shows a critical error message rather than a gateway error, the cause is a PHP fatal error; see how to fix the WordPress critical error.

When to get help

Get help when the errors happen during checkout or busy hours, when the host says the problem is your code, or when you have already tried lighter tasks and caching. WordPress speed optimization covers slow plugins, queries, PHP workers and caching, and WordPress maintenance adds uptime monitoring so you hear about timeouts before customers do.

FAQs

How do I fix a 502 bad gateway or 504 gateway timeout on WordPress?

Find which layer is failing from the error page, check your host's error logs and resource limits, make sure page caching works, and look for a slow plugin, query or outside API. Most fixes are on the server or plugin side, not in your browser.

Is a 502 error my fault or my host's?

It can be either. A crashed PHP service or server outage is the host's to fix. Too few workers for the traffic, or a slow plugin tying them up, is about how the site is built and which plan it runs on.

Why do I only get 504 errors in wp-admin?

Admin pages are never served from the page cache, so every click runs PHP. A slow dashboard widget, a heavy plugin settings page or a big WooCommerce report can exceed the timeout while the public site still looks fine.

Will increasing max_execution_time fix a 504?

Sometimes, for a single long admin task. It will not fix a slow front end, because the proxy timeout is often separate and longer requests hold PHP workers for longer.

Can Cloudflare cause a 502 bad gateway?

Cloudflare usually reports a problem at your origin rather than causing it. It can be involved if your host's firewall blocks Cloudflare addresses or if a long request goes past Cloudflare's own time limit.

If gateway errors keep coming back, a speed and server audit usually finds the slow plugin or the missing cache behind them; see WordPress speed optimisation. For ongoing updates, uptime monitoring and speed checks, look at WordPress maintenance plans, or hire a WordPress developer in India to look into it.

What does "the gateway did not receive a timely response" mean on WordPress?

It is a 504 gateway timeout written out in full. The front server passed your request to PHP and WordPress, which took too long to reply, so the server stopped waiting. Look for slow plugins, heavy imports or backups, slow outside services or exhausted PHP workers, and send your host the time and URL of the error.