Errors & retries

Residential exits are real devices on real networks. A single attempt can fail because the device went offline mid-request. Build retries in from the start.

SOCKS5 reply codes

Code	Meaning	What to do
0x00	Success	—
0x04	The chosen exit could not serve	Retry. A new exit is picked.
0x05	No exit matched your request	Do not retry blindly. Check your targeting.
0x07	Command not supported	Retry once. If it repeats, contact support.

The two failures that look alike

0x04, the exit failed. Your targeting was fine and an exit was chosen; it just did not deliver. Retrying gets you a different device and usually works.

0x05, nothing matched. No exit in the pool fits what you asked for. Retrying sends the identical impossible request again. Loosen the targeting instead.

Getting these two confused produces the classic symptom: a retry loop that burns its whole budget on a request that could never have succeeded. If 0x05 repeats, drop the narrowest option and try again. That is usually ZIP, ASN or device OS.

How much to retry

Two retries makes each request effectively reliable. In our own six-protocol testing, two full passes scored 6/6 and 5/6, and the single miss was a transient exit refusal that succeeded immediately afterwards.

Back off between attempts. Retrying instantly three times mostly means failing three times in the same second.

Failures that are not ours

Timeouts on IPv6. Many targets do not answer over IPv6 at all. If requests started timing out when you added -v6, test the target over IPv6 directly.

An HTTP/3 request that “hangs” after the body arrived. Some servers never send a FIN on the QUIC stream. See Protocols.

Auth failures after an IP change. If you use IP whitelisting and your egress address moved, every request fails as unauthorized. Check your current public IP against the whitelist.

Blocks from the target. A 403 or a CAPTCHA page is a successful proxy request that the destination refused. Rotating harder may not help. See Choosing a product, and consider the Scraping API, which handles blocking for you.

Still stuck

Contact support with the timestamp, the entry point, and the exact targeting options you sent. Those three make a request traceable on our side; the destination URL alone does not.