A script fails with a dropped connection once every hundred requests over a datacenter IP, and once every ten over a residential or mobile channel. That's not a faulty proxy — it's a property of the environment, and the client has to ride drops out on its own. Here's where the frequency gap comes from, what timeouts and retry delays to set, which errors are worth retrying, and how retries affect traffic spend.
Why residential and mobile channels drop more often than server ones
A datacenter IP sits on a provider's dedicated, redundant link with near-zero jitter — a drop there is rare and usually a systemic outage. A residential address is a real home connection: the router reboots, the provider switches the subscriber between nodes, the DHCP lease renews, the device sleeps. A mobile channel adds handovers between base stations, network switching and momentary signal loss — all on a live subscriber's live device, not a port dedicated to you. Carrier-side NAT, letting hundreds of subscribers share one address, is the same reason such an IP is nearly unbannable: see why mobile proxies are hard to ban. The flip side is a channel that's physically less stable than a server one.
Sensible connect and read timeout values
Connect timeout and read timeout differ and shouldn't be confused. Connect timeout caps how long establishing a session may take: 3-5 seconds for a datacenter channel, 8-15 for residential and mobile, since a packet passes through more hops on real hardware. Read timeout caps the wait for a response once the connection is up — the benchmark is the target server's expected response time with a 2-3x margin, typically 15-30 seconds for ordinary requests, more for heavy operations. Too short a timeout on a residential channel turns normal latency into a false failure; too long burns traffic for no benefit.
Exponential backoff between retries
Retrying right after a drop is a bad idea: if the cause is node overload or a momentary signal loss, an instant retry lands in the same state. Exponential backoff increases the delay with each attempt — say, 1, 2, 4, 8 seconds — giving the channel time to recover. Add random jitter of 20-30%: without it, parallel threads of the same script retry in sync after a shared failure and create their own load spike. Cap attempts at three or four — beyond that, success odds barely rise while time and traffic spent grow linearly.
Which errors to retry, and which not to
Worth retrying: anything resembling a temporary channel fault — a dropped connection, a timeout, 502/503/504 errors, network exceptions with no response. Not worth retrying: anything a repeat won't change — a 400 with a malformed body, 401/403 as an authorization problem, 404 as a missing resource. Handle 429 separately: it's an instruction to slow down, not a fault, so wait out the delay stated in the response header rather than the general backoff schedule. Blindly retrying every error without sorting is why scripts hammer a wall for hours instead of stopping and reporting the problem.
Telling a dropped channel from a platform block
A dropped channel means no response at all: a timeout, a connection reset, a TCP or TLS-level error. A block is a response — just unwelcome: a 403 code, a captcha instead of content, a redirect to a verification page, normal-sized HTML instead of the expected data. The first is cured by retrying; the second isn't — a repeat request to a block almost always gets the same answer, while switching addresses through rotation is a separate matter, covered in setting up IP rotation via API. Every retry is its own session on a residential or mobile channel, billed by traffic: an aggressive retry against a blocked address just spends gigabytes on the same rejection again. A retry cap and response-code triage is a matter of budget as much as reliability.
Frequently Asked Questions
How many times should a request be retried before giving up?
Three or four attempts with growing delays are enough for most tasks. If all fail, a fifth attempt on the same address is unlikely to succeed while traffic spend keeps climbing — switch the address via rotation or return the error to the calling code.
Do datacenter and residential channels need different timeout settings?
Yes. A datacenter channel holds stable, low latency, so a short timeout is justified. Residential and mobile channels pass through a live subscriber's real hardware, so their timeouts should be set noticeably wider — otherwise normal latency keeps getting mistaken for a failure.
Can the same retry logic be used for every kind of error?
No. Network faults and 5xx responses are candidates for a delayed retry. Authorization and malformed-request errors are pointless to retry. A 429 calls for the delay the server specifies, and signs of a block — a captcha, a redirect, a 403 — call for switching the address rather than retrying the same IP.
Residential and mobile channels for retry-heavy tasks are in the proxy section, where you can estimate traffic spend for a scenario and pick a channel balancing stability and price, after checking the difference between mobile and residential proxies.