HTTP 504 Gateway Timeout: What It Means & How to Fix

An HTTP 504 Gateway Timeout means a server acting as a gateway or proxy waited for a response from an upstream server and never got one in time. The gateway did its job — it forwarded your request — but the machine behind it was too slow or unreachable, so the gateway gave up and returned 504. It is fundamentally a waiting error, not a refusal error.

This guide breaks down what a 504 really means, how it differs from 502 and 503, the most common causes on both sides of the connection, and the concrete fixes whether you are scraping a slow site, browsing, or running the server that throws it.

What Is an HTTP 504 Error?

HTTP 504, defined in RFC 9110, is returned by an intermediary — a reverse proxy, load balancer, CDN, or API gateway — when it does not receive a timely response from the upstream server it is trying to reach. The intermediary accepted your request and tried to fulfill it, but the backend (an application server, database, or another service) took longer than the configured timeout allowed.

The request chain usually looks like: client to gateway (Nginx, Cloudflare, AWS ALB) to upstream (your app server). A 504 is the gateway saying: "I asked the upstream and waited, but it never answered, so here is a timeout."

504 vs 502 vs 503 vs 408

These timeout and gateway codes are constantly confused. Here is the clean distinction:

The simplest mental model: 408 means you (the client) were too slow to ask. 504 means the upstream was too slow to answer. 502 means the upstream answered with something broken. 503 means the server is up but deliberately not serving right now.

Common Causes of a 504

Server-side causes

• Slow backend application — the app server is taking longer than the gateway timeout to generate a response, often due to a slow database query, an external API call, or a heavy computation.
• Overloaded upstream — too many concurrent requests mean new ones queue behind a backlog and exceed the timeout.
• Upstream is down or restarting — the gateway cannot reach the backend at all and times out waiting for a connection.
• Gateway timeout set too low — a legitimately long operation (report generation, large export) exceeds an aggressive proxy_read_timeout.
• Network or DNS problems — packet loss, a slow upstream DNS resolution, or a firewall silently dropping packets between gateway and upstream.

Client-side and scraping causes

• The target site is slow under load — when you scrape aggressively, the target itself slows down and its own gateway starts returning 504.
• Your client timeout is too short — if you set a 5-second timeout against a page that takes 8 seconds, your stack reports a timeout that looks like a 504 from the chain.
• A slow or overloaded proxy — a cheap, congested proxy adds latency; combined with a slow target, the total exceeds your timeout.
• Heavy pages and large responses — pages that return megabytes of HTML or trigger slow server-side rendering can blow past timeouts.
• Anti-bot stalling — some defenses deliberately delay responses to suspected bots, pushing you into timeouts.

How to Fix a 504 as a Visitor

• Refresh and wait — 504s are often transient. Reload after a few seconds; the upstream may have recovered.
• Try again later — if the site is overloaded, the issue is on their end and will clear when traffic drops.
• Check your network — a flaky connection or an interfering VPN can contribute. Try a different network to confirm it is the site, not you.
• Flush DNS — stale DNS can route you to a dead endpoint. Clearing your resolver cache occasionally helps.

How to Fix a 504 When Scraping

1. Increase your client timeout

Give slow targets room to respond. A 20 to 30 second read timeout is reasonable for heavy pages:

import requests

proxy = "http://USERNAME:[email protected]:12321"
r = requests.get(
    "https://slow-target.com/page",
    proxies={"http": proxy, "https": proxy},
    timeout=(10, 30),   # 10s connect, 30s read
)

2. Retry with exponential backoff

Treat 504 as retryable. Back off so you do not pile onto an already-slow server:

import time, requests

def fetch(url, proxies, attempts=4):
    delay = 2
    for i in range(attempts):
        try:
            r = requests.get(url, proxies=proxies, timeout=(10, 30))
            if r.status_code != 504:
                return r
        except requests.exceptions.Timeout:
            pass
        time.sleep(delay)
        delay = delay * 2   # 2s, 4s, 8s
    return None

3. Reduce concurrency

If your own load is making the target slow, dial back. Fewer concurrent requests per target domain often eliminates 504s entirely. Two to five concurrent requests per domain is a safe starting point.

4. Rotate to a faster, cleaner IP

A congested datacenter IP shared by many abusers can be throttled or deprioritized by the target, adding latency. Switching to a fresh residential IP or a low-latency static datacenter proxy reduces both throttling and round-trip time.

5. Request less per call

Where the site supports it, use pagination, filters, or an API endpoint that returns smaller payloads instead of scraping a giant page that strains the server.

How to Fix a 504 on Your Own Server

If you operate the gateway, a 504 means your upstream is too slow or unreachable. Common fixes on Nginx:

# nginx: give a slow but legitimate upstream more time
location /api/ {
    proxy_pass http://app_backend;
    proxy_connect_timeout 10s;
    proxy_read_timeout 120s;
    proxy_send_timeout 120s;
}

• Profile and fix slow queries — the most common real cause is a database query that got slow as data grew. Add indexes or cache results.
• Scale the backend — add workers or instances so requests do not queue behind a backlog.
• Add health checks — so the load balancer stops routing to a dead or stuck instance instead of waiting for it to time out.
• Cache expensive responses — serve heavy reports from cache rather than regenerating them on every request.
• Raise timeouts only as a last resort — a longer timeout hides the symptom; fixing the slow upstream is the real cure.

The Role of Proxies in 504s

When scraping, the proxy is part of the gateway chain, so its speed matters. A slow, oversubscribed proxy pool adds latency to every request, and that extra time can be the difference between a 200 and a 504 against an already-slow target. High-quality proxies reduce 504s in two ways: lower latency per request, and cleaner IPs that targets are less likely to throttle. SpyderProxy offers low-latency static datacenter proxies with 99.9% uptime at $1.50/proxy/month, and rotating residential from $1.75/GB for high-trust access.

Frequently Asked Questions

What does HTTP 504 Gateway Timeout mean?

It means an intermediary server such as a reverse proxy, load balancer, or CDN forwarded your request to an upstream server and did not receive a response within its timeout window. The gateway is fine; the upstream was too slow or unreachable.

What is the difference between 502 and 504?

A 502 Bad Gateway means the upstream returned an invalid or broken response. A 504 Gateway Timeout means the upstream returned nothing at all in time. Both involve the gateway, but 502 is a bad answer and 504 is no answer.

Is a 504 my fault or the website's fault?

Usually the website's, since the upstream behind its gateway was too slow. But it can be partly yours if your client timeout is too short, your connection is unstable, or your scraping load is what is slowing the target down in the first place.

How do I fix a 504 when scraping?

Increase your read timeout to 20 to 30 seconds, retry with exponential backoff, reduce concurrency per domain, and rotate to a faster, cleaner IP. If your own load is causing it, slowing down is the most effective fix.

Can a proxy cause a 504?

Yes. A slow or overloaded proxy adds latency to every request, and combined with a slow target the total can exceed your timeout. A low-latency proxy with clean IPs reduces both the delay and the throttling that lead to 504s.

How do I fix a 504 on my own Nginx server?

Increase proxy_read_timeout and proxy_send_timeout for the slow location, but more importantly fix the slow upstream: optimize database queries, scale workers, add health checks, and cache expensive responses. Raising the timeout alone only hides the problem.

Conclusion

HTTP 504 is the chain telling you that something upstream took too long to answer. As a visitor, refresh and wait. As a scraper, lengthen your timeouts, retry with backoff, ease off the throttle, and run through fast, clean proxies. As a server owner, treat the timeout as a symptom and fix the slow backend behind it. In every case, the fix follows from identifying which link in the gateway chain ran out of patience.

For low-latency proxies that keep timeouts rare, start with SpyderProxy static datacenter at $1.50/proxy/month or residential from $1.75/GB.