How to Fix 504 Gateway Timeout Error

By ErrorFix · Updated October 26, 2026 · 8 min read

What 504 Gateway Timeout means

HTTP status 504 means "gateway timeout." It happens when a server acts as a gateway — a reverse proxy like Nginx, a load balancer, or a CDN like Cloudflare — and the server behind it, your origin server, PHP-FPM, or an application server, does not answer within the time the gateway is willing to wait. The default Nginx wait is 60 seconds; Cloudflare's is about 100 seconds. When that clock runs out, the gateway stops waiting and shows the visitor a 504 page instead of the site.

That waiting game is also the key difference from its close cousin, the 502 Bad Gateway error. A 502 means the gateway got a bad or empty answer back. A 504 means it got no answer at all in time. So a 504 is almost always a speed problem, not a broken-connection problem: the backend is alive, but it is too slow, too busy, or stuck on a single heavy job. Visitors can usually just wait it out; owners need to find what is eating the time.

It also helps to know who can fix what. If you are just visiting a site, nothing on your computer caused the timeout, and no browser setting will make the remote server answer faster. The useful visitor moves are refresh, cache, and patience. If you run the site, the fix lives in your logs, your database, and your server settings — and raising a timeout without fixing the slowdown only hides the problem until the next traffic spike.

Common causes

• Slow database queries or heavy scripts: an unindexed query, a huge import, or a report that scans thousands of rows can easily run past the gateway timeout.
• PHP-FPM or application workers exhausted: when every worker is busy, new requests queue up and time out one by one, even though the server itself is still running.
• Server overload or traffic spikes: a viral post, a sale, or a denial-of-service attack can swamp CPU, memory, or bandwidth so nothing answers in time.
• Proxy, CDN, or firewall misconfiguration: a timeout set too low, a firewall rule slowing the path to the origin, or a CDN pointed at the wrong server can all turn a slow reply into a 504.
• DNS or network problems between servers: if the gateway cannot reliably reach the origin, whether through a bad DNS record or packet loss on the route, the wait stretches until it times out.

How to fix the 504 Gateway Timeout error — step by step

Steps 1 and 2 are for visitors. Steps 3 through 6 are for site owners.

1. Refresh and wait a few minutes. Press Ctrl + R (or Cmd + R on a Mac) to reload the page, then wait two or three minutes before trying again. Many 504 errors are brief: a server process restarts, a traffic spike passes, or a slow database query finishes, and the next request succeeds. Do not hammer the refresh button, because rapid retries add load to a server that is already struggling to answer. Open the page in an incognito window (Ctrl + Shift + N) to rule out a stale cached copy of the error on your side.
2. Clear your browser cache and try another network. A cached 504 page can keep appearing after the site has recovered. Press Ctrl + Shift + Delete, set the time range to All time, check Cached images and files, and click Clear data, then close and reopen the tab. Also try your phone's mobile data or a different network: if the site loads there, the problem is local to your connection, not the site itself. If it fails everywhere, the fault is on the server side and only the site owner can fix it.
3. Site owner: find which request times out. Before changing any setting, find the slow request. On Nginx, check the error log with grep 504 /var/log/nginx/error.log and the access log for the slowest URLs. On a WordPress site, enable the PHP-FPM slow log and look for the script or plugin that keeps appearing. If one URL always times out, the problem is that page or its query. If every URL times out, the whole backend is overloaded or down.
4. Site owner: restart PHP-FPM and check server resources. On a VPS or dedicated server, connect via SSH and restart the backend with sudo systemctl restart php8.2-fpm (match your PHP version, which you can check with php -v), then confirm it is running with sudo systemctl status php8.2-fpm. Check load with top or htop, memory with free -h, and disk space with df -h. If PHP-FPM workers are all busy, the pool is exhausted: raise pm.max_children cautiously, or the next traffic spike will time out again. A full disk can also stop PHP-FPM from starting at all.
5. Site owner: raise timeouts only as a temporary measure. If a script legitimately runs for a long time, such as a large import or report, raise the gateway timeouts so it can finish. On Nginx, set proxy_read_timeout 300 and fastcgi_read_timeout 300 in the site configuration, then test with sudo nginx -t and reload with sudo systemctl reload nginx. On Apache, set ProxyTimeout 300. Treat this as a pause button, not a fix: a slow query will still be slow, and a higher timeout only gives it more time to finish. Behind Cloudflare, note that Cloudflare itself caps the wait at about 100 seconds, so a longer origin timeout alone will not help there.
6. Site owner: fix the slow upstream and check DNS and the CDN. Fix what is actually slow: add an index to the slow database query, cache the heavy page, or disable the plugin that runs on every request. Move long jobs, such as imports and bulk emails, to a background queue so the visitor is not left waiting. Then check the path into the server: confirm the DNS A record points at the correct origin IP, and try pausing Cloudflare (Overview, then Advanced Actions, then Pause Cloudflare) to test whether the origin works directly. Check your hosting provider's status page for incidents. If everything looks right on your end, open a support ticket with the exact times the 504s started, the affected URLs, and a log excerpt.

Did this fix it? Quick checklist

• The site loads without the 504 error
• It works in an incognito window and on another network
• PHP-FPM and the web server are running and responsive
• No single slow URL still times out, and the error log shows no new 504s

If 504s come and go at the same time every day, suspect a scheduled task: backups, cron jobs, or a daily import locking the database while visitors are active. Stagger heavy jobs away from peak hours. If 504s started right after a deploy, suspect the new code: a plugin update or a new query can be the slowdown, so roll back and compare the logs before and after. And if only logged-in pages time out while the homepage is fast, look at session handling and per-user queries first — a query that is fine for one visitor can collapse under many at once.