A 504 Gateway Timeout while using a proxy is one of the most misdiagnosed errors in scraping, because people treat it as one problem when it is really four or five, each with a different fix. The good news: once you know what a 504 actually says, you can find your specific cause in about two minutes. Here is the whole map.
What does a 504 Gateway Timeout mean with a proxy?
A 504 Gateway Timeout means a server acting as a gateway (here, your proxy) did not get a response from the upstream server (the target site) within its time limit, so it gave up.
The key word is upstream. The failure is on the proxy-to-target leg, not the you-to-proxy leg. Your request reached the proxy fine. The proxy then tried to reach the target and did not hear back in time. That single fact rules out half the things people waste time checking (your own network, your auth) and points you straight at the real causes.
The five causes, and the fix for each
| Cause | How to spot it | Fix |
|---|---|---|
| Dead or overloaded proxy | Same request works through a different proxy | Switch to a fresh, verified proxy |
| Timeout set too low | Fast targets work, slow ones 504 | Raise connect and read timeouts |
| Slow or blocking target | Fails through several proxies, works with none | Rotate IPs, slow down, retry |
| Wrong protocol or port | Every request 504s or refuses | Match HTTP vs SOCKS and the right port |
| Free proxy died mid-use | Worked a minute ago, 504 now | Re-verify before use, or use a paid pool |
Almost every 504 through a proxy is the first row. Let us go through them properly.
1. The proxy is dead or overloaded (most common)
Proxies, especially free ones, go down or get swamped constantly. An overloaded proxy accepts your connection but cannot service the outbound request in time, so you get a 504.
Fix: try the request through a different proxy. If it works, the first proxy was the problem, full stop. In a script, this means never trusting a single proxy: pull from a pool and rotate.
2. Your timeout is too low
If your client gives the proxy less time than the target needs to respond, you manufacture your own 504. Heavy pages, slow APIs and distant targets all need headroom.
Fix: set an explicit, generous timeout, split into connect and read so a slow handshake fails fast but a slow page still completes:
curl -x http://PROXY_IP:PORT \
--connect-timeout 10 \
--max-time 60 \
-s https://example.com/
In Python requests, pass a tuple: timeout=(10, 60) (connect, read).
3. The target itself is slow or blocking proxy traffic
Sometimes the proxy is fine and the target is the problem: it is genuinely slow, or it is stalling requests that arrive from proxy IP ranges as a soft block.
Fix: isolate it. Make the same request with no proxy at all. If that also hangs, the site is the issue and no proxy will fix it. If it works without a proxy but 504s through several, the target is throttling proxy traffic, so rotate to cleaner IPs (residential beats datacenter here), slow your request rate, and add retries. A target that stalls proxy traffic often also answers with 403 Forbidden or 429 Too Many Requests, and those guides cover the block side.
4. Wrong protocol or port
Pointing an HTTP client at a SOCKS port (or the reverse) produces timeouts and refusals that look like 504s. A proxy listening on 1080 is almost certainly SOCKS; 8080, 3128 and 80 are usually HTTP.
Fix: match the scheme to the proxy. Our cURL guide covers the exact http://, socks5:// and socks5h:// syntax and the gotchas around each.
5. A free proxy died between checks
Free proxies have lifetimes measured in minutes. A 504 right after a proxy worked is usually just that proxy dying, not a bug in your code.
Fix: verify each proxy immediately before you use it, not when you found it. Our proxy checker confirms a proxy is alive, fast and anonymous in one shot, and every entry on the free proxy list shows when it was last checked. If the job needs to stay up, this is the point where a dead-cheap free pool stops being worth the retries.
A two-minute diagnostic
When a 504 hits, run these three checks in order and you will know the cause:
- Same request, different proxy. Works? The first proxy was dead. Done.
- Same request, no proxy. Works without a proxy but not with several? The target is throttling proxy IPs. Rotate and slow down.
- Same proxy, a boring target (an IP-echo endpoint). Works on the simple target but not your real one? Your timeout is too low or the real target is slow. Raise the timeout.
Two or three commands, and the mystery is gone. This beats guessing every time.
Preventing 504s in a pipeline
If you are running this at scale, build the fixes in so 504s become a non-event instead of an incident:
- Rotate from a verified pool so a dead proxy is instantly replaced, never fatal.
- Set connect and read timeouts on every request, sized to the target.
- Retry with backoff on 504 (and 502, 408), switching proxy on each retry.
- Match IP quality to the target: datacenter for lenient sites, residential for ones that throttle proxies.
Do that and the occasional 504 is just the pool doing its job. If you are setting a scraper up from scratch, the complete guide to proxies for web scraping has the full retry-and-rotation pattern these fixes plug into.
Frequently asked questions
What does a 504 Gateway Timeout mean when using a proxy?
It means the proxy accepted your request but did not get a response from the target site in time, so it gave up and returned a 504. The failure is between the proxy and the target, not between you and the proxy. The usual causes are a dead or overloaded proxy, a slow or blocking target, or a timeout set too low.
How do I fix a 504 error through a proxy?
Work through it in order: switch to a fresh, verified proxy; raise your connect and read timeouts; confirm the protocol and port are correct; test the target without the proxy to see if the site itself is down; and add retries with rotation so a single dead proxy does not fail the job. Most 504s through proxies are a dead or overloaded proxy and clear on the next working IP.
Is a 504 the proxy's fault or the website's fault?
Either can cause it, which is why you isolate. If the same request succeeds through a different proxy, the first proxy was the problem. If it fails through several proxies but works with no proxy at all, the target is slow or is blocking proxy traffic. Testing one variable at a time tells you which.
Why do I get 504 errors only with free proxies?
Free proxies die and get overloaded constantly, so a proxy that worked a minute ago can time out on the next request. That is the normal behavior of shared free pools. Verify each proxy right before use, or move to a dedicated pool if the job needs to stay up.
504 vs 502 vs 408, what's the difference through a proxy?
504 means the upstream (the target) did not respond in time. 502 Bad Gateway means the proxy got an invalid response from the target. 408 Request Timeout means the server gave up waiting for your request to arrive. All three point at a stalled hop, but 504 specifically means the proxy-to-target leg timed out.