Proxy Error 502 Bad Gateway and 504 Gateway Timeout

Both codes are sent by a server acting as a gateway or proxy (RFC 9110, sections 15.6.3 and 15.6.5):

MDN's 502 page and 504 page give the same definitions. Neither code says your request was wrong: a 5xx is a server-side failure.

When you scrape through a proxy, there can be several gateways in a row: your proxy, then a CDN in front of the website, then the website's own load balancer. Any of them can send a 502 or 504.

For Cloudflare, its 502/504 page says the error means Cloudflare could not establish contact with the website's server, and that most come from that server. On ProxyField, the gateway's own answer when no exit could be connected for the location in your username is 502 Bad Gateway, with the text ProxyField: temporary error. Try again in a few seconds.

1. Retry once, from a new IP. On per-request rotation, the retry already leaves through another exit node; a one-off 502 from a dropped node is gone on the second try. ProxyField: "If a node slows down, traffic automatically moves to the next one."
2. Load the target without the proxy. If it fails there too, the website is down; wait.
3. Check a different target through the same proxy, for example https://api.ipify.org. If that works, the proxy is fine and the target is failing.
4. Check the protocol and scheme. An https:// proxy URL for a plain HTTP proxy, or HTTP sent to a SOCKS5 port, can come back as a 502 or a broken connection. ProxyField's gateway is gate.proxyfield.io:7000 for HTTP, HTTPS and SOCKS5 alike.
5. Slow down if 502s rise with your volume. A site that is struggling under load answers bursts with 502s; fewer parallel requests help it and you.

1. Raise your timeouts to fit the target. Slow pages, search pages and large files need more time. Set separate connect and read timeouts so a dead proxy fails fast and a slow page still loads.
2. Retry with back-off, on a new IP for rotating sessions.
3. Choose an exit location near the target. A US site served through an exit on another continent adds round-trip time to every request. ProxyField targets country, region and city.
4. Lower concurrency on one site. A 504 that appears only at high volume means the target, or your machine, is saturated.
5. Check the target without the proxy. If it is slow everywhere, the timeout is on the site's side.

This Python requests example sets a short connect timeout and a longer read timeout, and retries 502, 503 and 504 with back-off through the ProxyField gateway:

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

PROXY = "http://<login>-country-us-city-new_york:<password>@gate.proxyfield.io:7000"

retry = Retry(
    total=4,
    backoff_factor=1.5,                  # waits grow 1.5 s, 3 s, 6 s ...
    status_forcelist=[502, 503, 504],
    allowed_methods=["GET", "HEAD"],
    respect_retry_after_header=True,
    raise_on_status=False,               # return the last response instead of raising
)
s = requests.Session()
s.mount("http://", HTTPAdapter(max_retries=retry))
s.mount("https://", HTTPAdapter(max_retries=retry))
s.proxies.update({"http": PROXY, "https": PROXY})

r = s.get("https://example.com/", timeout=(10, 60))  # (connect, read) in seconds
print(r.status_code)

The Retry options are documented in urllib3. Retry only idempotent requests such as GET; a retried POST can submit twice.

The 503 case has its own page: Proxy Error 503 Service Unavailable. A connection that fails before any status code is a different problem: see why is my proxy not working.

• Set explicit connect and read timeouts in every client; library defaults can be "wait forever".
• Retry with exponential back-off and a cap, on idempotent requests only.
• Rotate exit IPs between retries, and keep sticky sessions only as long as a task needs them (30 s to 36 h on ProxyField).
• Target exit locations close to the website.
• Watch error rates per target; a rising share of 502/504 on one site means slow down, not push harder.