Proxy Errors and Status Codes: What Each Means

Four checks tell you which side failed.

1. Test the proxy alone. Use the proxy checker, or send one request with the credentials from your account:

   ShellCopy Shell code

   curl -x gate.proxyfield.io:7000 -U "<login>-country-us-city-new_york:<password>" https://api.ipify.org

   An IP address back means the proxy works.

2. Read the status code and who sent it (next section): 407 and most 502/504 pages come from the proxy side; a 403, 404 or 429 with the site's branding, or a Cloudflare page, comes from the target.

3. Try the URL without the proxy, then from another location. Failing everywhere means the site is down or refuses everyone; one location failing means a regional block.

4. Check your account: username and password, the allowlist, and remaining traffic (the dashboard shows real-time usage stats and remaining gigabytes).

HTTP's standard, RFC 9110 §3.7, names two kinds of intermediary: a proxy, which the client chooses (your scraper sends requests to gate.proxyfield.io:7000), and a gateway (reverse proxy), which acts as the origin server for the site, such as Cloudflare in front of a website. Both can answer with their own status codes, which is why the same 502 can come from either side.

Three rules settle most cases:

• The site's own answer passes through. A 403, 404 or 429 from the website reaches you unchanged; the proxy did its job.
• The proxy answers itself only when it cannot complete the request: 407 (no valid login), 502 (no valid answer from the server behind it), 504 (no answer in time), or a provider's own code.
• A connection failure has no code at all: the client never reached the proxy, or got no reply. Python and cURL report it as an exception or an exit code.

To see which side spoke, print the headers with curl -i:

curl -i -x gate.proxyfield.io:7000 -U "<login>-country-us-city-new_york:<password>" https://example.com/

For an https:// URL the client first asks the proxy to open a tunnel (CONNECT), so the output can hold two header blocks:

For http:// URLs there is no tunnel: a 407 arrives as an ordinary response with a Proxy-Authenticate header.

A 4xx code means a request was refused; a 5xx code means a server failed, the proxy or the site. Each code links its MDN definition, and the single-code docs go deeper.

The standards behind the table: RFC 9110 (401 §15.5.2, 403 §15.5.4, 404 §15.5.5, 407 §15.5.8, 502 §15.6.3, 503 §15.6.4, 504 §15.6.5), RFC 6585 (429) and RFC 7725 (451).

Which codes to retry

Retry what is temporary, with growing pauses; never loop on a refusal.

In Python, requests with urllib3's Retry does this for you:

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

retry = Retry(total=3, backoff_factor=1, status_forcelist=[429, 502, 503, 504],
              allowed_methods=["GET", "HEAD"], respect_retry_after_header=True)
session = requests.Session()
session.mount("http://", HTTPAdapter(max_retries=retry))
session.mount("https://", HTTPAdapter(max_retries=retry))

When the retries run out, requests raises RetryError with a message such as Max retries exceeded with url: / (Caused by ResponseError('too many 429 error responses')).

Requests wraps urllib3, so a traceback names a requests exception and, inside it, the urllib3 cause. The urllib3 docs define them in one line each: ProxyError is "Raised when the connection to a proxy fails", ConnectTimeoutError "when a socket timeout occurs while connecting to a server", ReadTimeoutError "while receiving data from a server" (urllib3 exceptions; Requests API: exceptions).

One script that shows which side each failure points to:

import requests

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

try:
    r = requests.get("https://api.ipify.org", proxies=proxies, timeout=(5, 30))
    r.raise_for_status()
    print("exit IP:", r.text)
except requests.exceptions.ProxyError as e:
    print("proxy side: host, port, login or tunnel ->", e)
except requests.exceptions.ConnectTimeout as e:
    print("no connection within 5 s: firewall or port ->", e)
except requests.exceptions.ReadTimeout as e:
    print("connected, no data within 30 s: slow target ->", e)
except requests.exceptions.SSLError as e:
    print("TLS failed: check the proxy scheme ->", e)
except requests.exceptions.HTTPError as e:
    print("the site or proxy answered", e.response.status_code)

Then run the same credentials through cURL: if curl -x gate.proxyfield.io:7000 -U "<login>-country-us-city-new_york:<password>" https://api.ipify.org works and Python fails, the problem is in the script (scheme, encoding, environment variables such as HTTPS_PROXY).

A connection failure happens before any status code: the client never reaches the proxy, or the proxy never reaches the site.

A Cloudflare error page means your request went through the proxy and reached Cloudflare, the site's gateway: the site's rules or its origin server answered, not your proxy. The page and the headers say so (Server: cloudflare, CF-RAY). If Cloudflare gets a normal 404 from the site, it passes the 404 on; it writes its own 52x page only when the origin fails. For scrapers, start with Cloudflare 403 Forbidden; all codes are in Cloudflare error codes.

"Proxy detected" means the site, or an IP database it checks, classifies your IP as a proxy, VPN or datacenter address. IP databases label addresses by who holds them: datacenter ranges are usually listed as hosting; residential, mobile and static residential (ISP) IPs under the internet provider or carrier. An IP lookup tool shows how your exit IP is listed; more in anonymous proxy detected.

If a site rejects datacenter ranges, move to residential proxies or static residential (ISP) proxies; where datacenter ranges are accepted, datacenter proxies are usually enough. No IP type is a guarantee: sites also check headers, fingerprints and request rates.

• Slow responses. A distant exit location or a slow target adds time; target a location closer to the site and compare response times in the checker. On ProxyField, "If a node slows down, traffic automatically moves to the next one." More in slow proxies and changing IPs.
• A sticky IP that changes. Sticky sessions last from 30 s to 36 h (presets 1, 5, 10, 30 min, 1, 3, 6 h). Set a session longer than the task; when it ends, expect a new IP. The IP is not guaranteed if the exit node drops; on a connection error the gateway retries once with a new session, so the IP may change, and a connection that breaks is not restored, so your client reconnects.
• Works on your laptop, fails on a server. Add the server's IP to the allowlist, or switch to username and password, and check that its firewall allows outbound connections to port 7000, or the port you set up in the dashboard for the allowlist.
• A Playwright or Puppeteer timeout. Run the cURL check first, then block images, fonts and media and raise the navigation timeout; see the Playwright proxy setup.

What the ProxyField gateway returns when the problem is on your side:

For anything else, our 24/7 live chat helps, including with setup and integration.

1. Run the proxy through the proxy checker again.
2. Request https://api.ipify.org through the proxy and confirm the IP you get back is the proxy's exit IP, not your own.
3. Re-check the gateway, port and credentials against your account.
4. Contact our 24/7 live chat with the time, target URL, full error and exit IP.

A proxy that won't work at all has its own checklist: why is my proxy not working.