Proxy Rotation for Web Scraping: Session Boundaries

Proxy rotation for web scraping can change the network route while an open browser context retains its cookies and pages. The useful question is which requests used which route, not whether the browser now has a new identity. BotBrowser documents context-level proxy updates and geographic settings; it does not supply proxy addresses, confer a reputation on them or guarantee a site's acceptance. For authorized collection, assign each route change a request boundary and check the observations separately.

TL;DR

• A rotated exit address does not reset cookies, authenticate an account or replace a fingerprint profile.
• BotBrowser documents an overlap: requests already in flight finish on the previous proxy, while new requests use the updated route.
• An HTTP endpoint, a DNS observer and a WebRTC peer observe different network paths.
• Serialize updates within the same context and await completion before dependent navigation.
• Keep credentials outside diagnostics and stop on an authorization refusal instead of rotating to retry it.

Contents

• A route change inside a retained context
• Five observations with different meanings
• Requests that cross the handover
• An owned-endpoint preflight record
• Choose a rotation boundary for the job
• BotBrowser controls and their limits
• Practical conclusion

A route change inside a retained context

A proxy setting selects a network path. Cookies and localStorage belong to the browser's application-state lifecycle. Keeping the same BrowserContext across a route update therefore creates a different situation from starting a fresh context. Record both operations; a scheduler label such as run-B says nothing about whether client state was reused.

The per-context proxy guide covers assigning separate routes to separate contexts. A rotation inside one of those contexts needs an additional time boundary: the route before the update, the completed update and the first dependent request. A loaded document is not evidence of the route that a later navigation will use.

Retaining application state may be necessary for an owned integration, but the server decides whether that state remains valid. Cookie continuity across scraping runs distinguishes client retention from server acceptance. Replacing an exit address neither grants permission nor makes a continued session unobservable to its service.

Distinguish browser-controlled switching from a provider's rotating gateway. In the first case, the job submits a context update and can retain its completion result. In the second, the browser may keep one proxy URL while an external gateway chooses upstream exits. The documented BotBrowser update boundary cannot prove when that external decision occurred. Put the gateway's session policy beside the context policy so a request traced to an unexpected exit has a specific configuration to compare.

An application session also has a longer history than the latest HTTP request. Its own server can retain account events even when a fresh context contains no cookies. A clean client state is therefore a statement about that browser storage boundary, not a claim that a service has forgotten earlier activity. Use separate approved test accounts when the application test requires account isolation; rotating routes is not an account-lifecycle mechanism.

Five observations with different meanings

An owned HTTP endpoint can record the peer address reaching its network boundary. If a load balancer or reverse proxy sits in front, the application may see that intermediary instead. MDN's X-Forwarded-For reference requires a known trust configuration before forwarded addresses are used for security decisions. An arbitrary X-Forwarded-For value is not independent proof of egress.

Observation	Evidence to retain for an owned fixture	What it cannot establish
HTTP egress	Request identifier, time and trusted edge observation	DNS or media transport used the same path
DNS resolution	Resolver-path evidence for the declared hostname	The HTTP response came through the intended proxy
Regional settings	Declared overrides and the fixture's displayed timezone/language	The physical location or identity of a user
WebRTC	Declared media policy and an authorized peer's transport observation	Every candidate address proves a packet route
Application state	Required store markers and a separate server outcome	A changed address created a clean or accepted session

The BotBrowser proxy configuration reference distinguishes socks5:// local DNS from socks5h:// remote DNS. This is documented product behavior, not a promise that every framework gives those schemes the same meaning. Retain the actual scheme and resolver evidence rather than inferring DNS routing from a successful page load.

MDN's WebRTC overview describes peer communication beyond ordinary document retrieval. Candidate presentation and actual transport need separate interpretation. The DNS and WebRTC consistency discussion connects those surfaces without treating one HTTP response as a complete network audit.

Give each row its own expected condition. For HTTP, an owned fixture might require the approved route label. For DNS, it might require the organization's remote-resolution policy. For a regional display test, it can deliberately require a fixed interface language rather than the language estimated from egress. Those conditions serve different purposes. Marking every difference as a leak would misclassify legitimate preferences, while marking every matching label as a pass would omit the actual transport question.

When an observation is absent, retain that absence without substituting a nearby value. A proxy control response can establish that a command completed, but it is not an observation at the destination. A remote resolver's response does not establish the media route. This separation also limits data collection: retain only the evidence needed for the declared condition, rather than collecting a permanent cross-surface fingerprint to explain an ordinary routing incident. A geo-alignment capture record applies the same rule to advertising observations: the exit region, reported timezone and declared language list are stored per capture, because a route change without a matching language change produces a capture that describes two places. A regulated-data collection profile extends that rule to a single-purpose job: the session is bound to one profile for its whole life, and a step-up challenge voids in-flight work rather than being retried under a new route.

Requests that cross the handover

BotBrowser's dynamic-switching documentation states that in-flight requests complete on the previous proxy and new requests use the updated proxy. Consequently, a late response from route A can arrive after a route-B update completes. Grouping responses only by arrival time can attribute that older request to the wrong route.

For a controlled job, stop admitting new work before its declared switch point and account for outstanding requests. Keep request start times and opaque request identifiers with the route assignment. Await the update before starting navigation that depends on it. The dynamic proxy switching guide covers the runtime control; the operational addition is a record that preserves the overlap instead of assuming an instantaneous cutover.

Serialize proxy, context-flag and proxy-clearing updates for the same context as the public documentation requires. This does not require serializing every independent browser context. A failed update leaves the dependent job without its required precondition; stop that job and inspect its redacted control result rather than asserting that the new route is active.

The job's timestamps need an explicit clock meaning. Keep the local ordering of request admission and control completion; record a clock source when correlating those events with a separate edge log. If two clocks are not synchronized well enough to establish order, use the fixture's request identifier and acknowledge the ordering gap. A later wall-clock timestamp alone must not convert an unknown request assignment into proof of a completed handover.

Long-lived background activity needs a separate decision before switching. A page can initiate work beyond the navigation the scheduler awaited. Declare whether the fixture's polling or media activity is paused, ended or outside the measured workload. Do not label an entire tab as route B merely because its latest navigation was route B. The unit supported by the observation is the identified request or connection, not every activity associated with the page.

An owned-endpoint preflight record

Use a fixture and network edge that the organization controls. Give one harmless request a unique identifier before the handover, then another after the update completes. Keep the request start, completion and observed route together, for example as requestId, startedAt and routeLabel fields. These are proposed acceptance conditions, not reported measurements, and no third-party account or challenge page is needed.

For the HTTP row, compare the fixture's trusted edge observation with the approved route assignment. Keep an opaque route label in ordinary logs; any needed address-level evidence belongs in the restricted network record. Do not log proxy URLs containing credentials, authorization headers or account cookies. A response from an unrelated public IP-check service is not evidence about the application's reverse-proxy trust chain.

Check the declared DNS path and WebRTC policy only through authorized infrastructure that can observe them. If the job does not use media, record WebRTC as outside the workload rather than inventing a successful transport check. A displayed timezone or language is a separate fixture observation; multilingual users and explicit overrides can legitimately differ from an IP's geographic estimate.

Continue only when the required rows have evidence and the owned application accepts its harmless operation. Missing DNS evidence is an unknown for DNS, even if HTTP passed. An HTTP 403 or an account authorization refusal is a stop condition for the collection workflow, not a signal to cycle addresses until the same operation succeeds.

Three outcomes require different follow-up. If the switch command fails, inspect the control prerequisite before any dependent navigation. If it succeeds but the owned endpoint sees an unexpected exit, compare the context assignment, declared direct-routing exceptions and provider gateway policy. If the expected exit is observed but the application declines the operation, inspect the application's authorized server record. These outcomes do not share one inferred cause, and none independently identifies browser fingerprint detection.

Keep the fixture response distinguishable from cached display data. A request identifier should be newly assigned by the fixture and checked in its edge or application log, rather than copied from an older page's visible text. The organization controls the fixture's caching policy and harmless operation. A page that displays an earlier address without a corresponding fresh request is insufficient evidence for the current route, regardless of how convincingly it renders.

Choose a rotation boundary for the job

For a regional collection job that needs one route, assign the proxy at BrowserContext creation and keep that assignment through the job. A provider-controlled gateway can still change its upstream exit behind the same endpoint. Confirm the provider's documented session policy and compare owned-endpoint observations; an unchanged proxy hostname alone does not establish a stable exit.

For an authorized recovery from an unavailable route, decide whether the application state should continue before updating the context. If the next task must start clean, create an appropriately isolated context with its own state policy. Retain the distinction between replacing a transport and resetting cookies; silently doing both prevents a later incident from identifying which condition changed.

Rotation is not a substitute for a workload budget. Keep the service's permitted rate and concurrency across the whole collection job, including different routes. A received rate-limit or challenge response needs application-level diagnosis and the applicable service policy, not a new identity claim based on the next exit address.

Define the recovery route before a fault. If direct networking is forbidden by the job's privacy policy, an unavailable proxy should leave the job stopped. Do not turn a temporary transport issue into an undocumented direct fallback. If an approved replacement is available, apply the same completed-update and owned-endpoint conditions to it. A recovery action needs evidence of its own; the word fallback is not a weaker acceptance standard.

Context retirement is a storage decision too. Record whether a completed job's authorized state must be retained in the protected application workflow or intentionally discarded through its supported lifecycle. Keep unrelated jobs' secrets and account state separate. A route label may be reusable infrastructure, while application storage belongs to a particular permitted purpose. Reusing the label does not authorize reusing the previous job's stored account data.

BotBrowser controls and their limits

The public dynamic-switching guide lists ENT Tier3 and a valid loaded profile as prerequisites. It describes a context update that applies geographic state before completion. Launch configuration also matters: the proxy reference says the BotBrowser --proxy-server path triggers geographic detection, while framework-only proxy options do not trigger that product pipeline. Keep the configured path with the run record.

BotBrowser's WebRTC documentation distinguishes candidate information from transport. Its default policy blocks unproxied datagrams when the proxy cannot carry them; the documented real mode deliberately permits direct host networking. Selecting that mode changes the privacy boundary. Candidate appearance alone cannot certify the route a media packet took.

Clearing a context proxy reverts to the browser-level proxy or, if none exists, a direct connection. Clearing is therefore not a network stop operation. BotBrowser's routing controls do not supply proxy capacity, repair an IP reputation or establish third-party authorization. The relevant job decision is whether its declared routes, required observations and application permissions are satisfied.

Pin the public documentation revision or retrieval date in the internal operational record alongside the deployed browser version. A product's current guide is not proof that an older installed executable supports every listed option. Resolve a missing capability as a version or entitlement prerequisite before interpreting a failed configuration as a destination-side refusal. No browser runtime comparison or proxy-provider performance measurement is claimed by these source-based acceptance conditions.

FAQ

Does proxy rotation require a different fingerprint profile?

An exit change and a profile choice are separate inputs. A changed IP does not establish a new device identity; choose the profile for the authorized workload rather than inferring identity from network location.

Can the same proxy endpoint produce different exits?

Yes, if its provider's routing policy allows that behavior. Confirm that policy and observe the owned endpoint; a stable hostname is not sufficient evidence of a stable upstream exit.

Does a new route empty the cookie jar?

A route update is not a storage-reset operation. Declare whether the context and its application state are retained, and check server acceptance independently.

Is an IP check enough when the job uses WebRTC?

No. An HTTP request establishes only that request's observed path. Media transport and its privacy policy need evidence appropriate to the authorized peer connection.

Sources

• BotBrowser: Dynamic proxy switching
• BotBrowser: Proxy configuration
• BotBrowser: WebRTC leak prevention
• MDN: WebRTC API
• MDN: X-Forwarded-For

Practical conclusion

Make the next authorized request depend on a completed route update and a verified job preflight. Keep old in-flight work distinguishable from later work, and treat required network observations and retained application state as separate conditions. If authorization or an essential route check fails, stop that job and resolve the named condition before collection continues.