What the target actually sees
Your client connects to proxynade.net:2555 and that address never changes. The gateway picks a residential exit and the target sees that exit's IP, not the gateway address.
The exit IP carries an ASN: the network owner label that identifies the underlying ISP. A Comcast or Orange residential connection shows a consumer ISP ASN. A datacenter route shows a hosting ASN. Targets that classify traffic by ASN treat those two differently; ASN assignments are governed by BGP routing (RFC 4271), which is why the same physical location can report a different network owner depending on how routes are announced. Residential context matters when the target dislikes hosting networks; it does not paper over bad request patterns, stale cookies, or timing that looks scripted.
Rotation means the gateway assigns a different residential exit per request or per connection window. Ten requests through the same connection string can land on ten different IPs because the gateway's exit selection changed, not your code.
Result quality is not the same as exit count
When sampling a rotating pool, unique IP count is a weak proxy for usefulness. The numbers that matter are body size, row count, retries per kept result, and which exits returned thin or challenge-page bodies.
Ten different residential exits that collectively return seven challenge pages and three usable results is a bad run. The rotation spread the requests but did not improve the results. Logs tell that story; exit count does not.
The dashboard network logs record host, outcome, latency, and byte totals per request. Export the CSV, sort by byte total, and look at the rows where bytes are low but status is 200. Those are often challenge pages or soft-blocks that the client accepted without realizing the body was empty.
When plain rotation fits and when it does not
Rotation is the right shape for jobs where each request is independent: price checks on public pages, directory sampling, broad monitoring across many URLs. One bad exit does not stall the whole job, and the next request picks a fresh assignment automatically.
Logins, cart flows, and cookie-dependent sequences are a different problem. Those expect one visitor identity across multiple clicks. A new ISP on every request can look like account takeover noise to the target's session layer. For those flows, sticky sessions are the correct tool, where the exit is pinned for a duration set by the lifetime-<minutes> token in the username. The session mode lives in the username, not in the protocol or port.
| Request pattern | Session type | Why |
|---|---|---|
| Independent price or directory checks | Plain rotation | Each request is self-contained; new exits spread load. |
| Login + form + short browsing sequence | Sticky (lifetime-<minutes>) | Target expects one visitor IP across the flow. |
| Long account workflow requiring a fixed IP | Hard session | Exit stays pinned until it dies, regardless of time. |
Volume vs Premium: the cost-per-kept-result question
Volume Residential is $0.89/GB. Premium Residential is $5.00/GB, billed per transferred byte. The plan choice comes down to what each tier returns on your specific target, not pool-size slogans.
If Volume writes clean rows with low retries, it is the cheaper option and there is no reason to change. If Volume burns bandwidth on retries, challenge pages, and thin bodies, the effective cost per kept result climbs. Premium can end up cheaper in practice even at five times the headline rate, because the byte total for the same number of usable results is lower.
Provider-metered bytes include redirects, retries, failed responses, and challenge-page bodies the client downloaded then discarded. App-level counters that track rows or accepted bodies will always look cleaner than the bandwidth bill. The gap between those two numbers is worth measuring before committing to a plan at scale.