Per-context proxy: route ownership for separate browser work

What a per-context proxy changes

A per-context proxy assigns a network route to one browser context instead of applying one route to every page in a browser process. It is useful when an organization has authorized work that must remain separate: for example, a support team may test a regional service journey while a separate quality-assurance task uses another approved route. The practical question is not how to make activity appear to come from somewhere else. It is which workload is allowed to use which route, and how that choice can be checked later.

Browser contexts are a familiar application boundary. Playwright documents a context as an isolated browser profile, and its proxy option applies the selected proxy to requests from that context. BotBrowser's public per-context proxy documentation describes assigning different proxies to different browser contexts. Those two facts make a context a reasonable unit for a route assignment when the browser automation library and the approved deployment support it.

The route is only one part of the boundary. A proxy is an intermediary between a client and a destination, as MDN describes. It does not itself establish a destination permission, a correct regional result, or where an application stores and processes data. The application owner must define those conditions separately. Treat the route as an operational dependency with a named purpose, not as a claim about identity, entitlement, data residency, or direct connectivity.

Isolation is useful, but bounded

Context isolation is valuable because it reduces accidental sharing inside a test or automation job. Separate contexts can keep their own browser data, such as cookies and local storage, according to the browser automation model. Assigning a route at the same boundary gives operators a clear way to say which route belongs to which task. It also makes cleanup straightforward: close the context when its task is complete and create a new one for a later assignment.

That boundary is not a guarantee of anonymity, non-attribution, or independence from every shared resource. Contexts can still run on the same host, use the same organization, depend on the same proxy provider, reach the same services, and be governed by the same access policies. Destination services may record activity under their own terms. A privacy review should therefore consider the complete system, including accounts, retention, employee access, vendor agreements, and destination rules.

It is equally important not to infer a user's physical location from a route. Network location can be approximate, can change, and can reflect provider infrastructure rather than the operator. A product team that needs a particular interface language, time zone, consent state, or test account should set those requirements deliberately in its authorized test plan. Do not convert a route selection into an automatic assertion that all regional settings, records, or legal obligations now match.

Choose routes by workload, not by convenience

Start with a small route register. For each assignment, record a human-readable route label, the allowed application or test, the owner, the intended region when relevant, the approval period, and the secret reference used by the deployment. Keep credentials out of tickets, source files, screenshots, and browser logs. A secret manager or the deployment platform should supply credentials through its normal protected mechanism.

The label should describe a purpose rather than expose an endpoint. For example, "support-portal-eu-test" is more durable than copying a hostname into many jobs. The proxy provider can rotate an endpoint without forcing every template to change, while reviewers can still see that the task requests an approved route family. A new purpose deserves a new assignment; silently reusing an old route label makes later review unreliable.

Use one assignment per context and keep the association visible at job creation. A task may use an independent route, or it may intentionally inherit the launch profile's proxy route and geographic identity when no independent route is configured. Inheritance is still a route choice, not a direct connection. The smallest documented arrangement is easier to operate and audit. Avoid placing a route in a global default merely because one workload needs it: a global setting can unintentionally affect unrelated pages or services in the same process.

Before using a regional route, confirm that the task is authorized by the destination service and by the organization that owns the route. A regional checkout test, a customer-support review, and a data-processing job have different permissions and retention needs. If the purpose changes, pause and obtain the appropriate approval instead of treating a working proxy configuration as transferable permission.

Build a safe context lifecycle

BotBrowser's public per-context proxy documentation lists an ENT Tier3 license and a profile-loaded browser as prerequisites. For an independent route, apply the approved context route and geographic metadata configuration before its first dependent request. The timing matters: settings applied after a page exists may not affect that context as intended. Keep the approved configuration in the deployment layer or reviewed application configuration, not in ad hoc console steps. A reviewer can then identify the context purpose, route label, and secret reference without reading credentials.

Use a fresh context when the assignment changes. A context that has already accumulated cookies, storage, downloads, or application state is a poor baseline for a different route or business purpose. Closing the old context clears the operational boundary: one context has one declared task and one route assignment. This practice also reduces accidental carryover of session state into an unrelated validation.

Plan for normal failure. A route can be unavailable, credentials can expire, or a destination can return an expected access error. Define the allowed request and protocol scope, plus any approved route exclusions, before the run. A required route must fail closed when unavailable: do not silently continue through a direct connection or an unapproved fallback. Record a concise operational result such as "route unavailable," "authentication rejected," or "authorized workflow completed," along with the route label and time window. Do not collect full browsing histories, page contents, or customer data merely to prove that a proxy was configured. Escalate access or policy failures through the service owner instead of repeatedly retrying a workflow.

Separate application secrets from route secrets. The proxy credential authorizes access to a network service; it should not be reused as a destination login, and a destination login should not be embedded in a proxy configuration. Rotate each credential through its own owner and process. This reduces the impact of a change and makes it possible to revoke a route without changing an application's own access controls.

Validate the authorized outcome

Validation should test the result required by the authorized workload, not attempt to characterize the browser or a destination's defenses. For a regional help-center check, confirm that the approved test account can reach the intended public or authorized page and that the expected locale or content policy is presented. For a service integration, confirm the documented request succeeds or fails in the expected way. Record only the minimum evidence needed for support and compliance.

Compare a changed assignment with a known, approved baseline. Keep the browser release, application version, test account, and route purpose stable where possible. If several variables change at once, an outcome cannot reliably show which change mattered. A staged rollout by deployment group is usually easier to reverse and investigate than changing every worker at once.

Route health and application health are different observations. Infrastructure monitoring may show that an approved route accepts a connection, while an application workflow may still fail because of permissions, maintenance, account state, or destination availability. A configuration value or completed page load does not prove actual egress. For the authorized request and protocol scope, compare the route label with the proxy provider's own authorized endpoint record or the organization's approved network record. Report that egress observation separately from the application outcome. Treat an unexpected direct path, an unapproved exclusion, or an unavailable required route as a failed validation, not as a successful fallback.

Write the acceptance result as two separate fields: route evidence and application outcome. Mark the check failed when either required route evidence is missing or the authorized workflow has the wrong result. This prevents a successful page response from hiding an unverified route and gives the owner a clear recovery decision.

When a failure could duplicate a customer action or create repeated records, stop new work for the affected group. Preserve the minimal job evidence, restore the previously approved assignment if that is safe, and ask the route or application owner to investigate. Retrying with a different route is not a neutral troubleshooting action when the destination rules or business impact are unclear.

Regional settings need explicit decisions

BotBrowser documents independent geographic resolution for each context: when timezone, locale, and language remain on auto, they derive from that context's proxy. Explicit settings are also resolved independently per context and per setting. A context without an independent proxy inherits the launch profile's route and geographic identity. Wait for its proxy and geographic updates before creating dependent pages or navigating. A route may still be selected for availability or network-path reasons while an application deliberately fixes language or time zone. Each override needs an explicit source: a user choice, an approved application requirement, or a documented automatic policy.

Maintain a short exception record for values that intentionally do not follow the route. State what is fixed, who approved it, and why it is required. Review the record whenever the route, application, or deployment platform changes. An old locale or time-zone override can be syntactically valid and still be wrong for the current task.

Do not promise that proxy placement produces a particular geographic interpretation. Geolocation data is not a substitute for a business rule, and a route can change without notice from a provider. Where location has legal, contractual, or user-consent implications, use the organization's compliance process and the destination's documented controls. A browser context cannot decide those requirements on its own.

Operating checklist and limits

An effective operating checklist is short. Confirm the workload is authorized; select its approved route label; create a fresh context; obtain credentials from protected deployment configuration; run the minimal documented workflow; and retain a narrow result record. Close the context after completion. This sequence creates a useful audit trail without turning a routine check into broad collection.

Review capacity with the real, authorized workload. Open pages, media, extensions, downloads, and application behavior all affect browser resources. A result from an empty page is not a capacity promise for a production job. Set conservative limits, observe normal failure handling, and leave room for short-lived peaks rather than assuming one browser process can safely absorb every task.

Per-context routing also has limits at the network edge. Proxy support, authentication, request and protocol scope, approved exclusions, and protocol availability depend on the automation library, browser release, proxy service, and deployment environment. Geographic metadata can inform regional resolution, but it is not proof of routing and does not replace an approved route assignment. Consult the maintained BotBrowser proxy documentation and the browser library documentation before changing an approved configuration. Do not rely on copied command snippets from an old article or ticket.

Two-context routing check

Synthetic acceptance matrix (application test design)

This matrix defines observable application assertions for a synthetic fixture; it is a test design, not a report of runtime execution. Keep route evidence and application results as separate fields so a successful response cannot create false attribution.

Case	Synthetic setup	Observable route evidence	Observable application result	Acceptance
Positive independent route	Fresh Context A has an approved independent route and a no-side-effect fixture request.	The authorized egress reference matches Context A's route label, request, and protocol.	The fixture returns the expected result for Context A.	Pass only when both fields match; otherwise fail closed.
Negative inherited or missing route	Context B has no independent route, or the required route is absent.	The record shows the documented inherited route, or explicitly records missing route evidence; it must not be reported as Context A's egress.	The fixture is blocked or reports the documented inherited-route outcome; no direct fallback is accepted.	Pass only for the declared negative outcome.
Failure-closed and recovery	Make Context A's required route unavailable, then restore the previously approved assignment in a fresh context.	Failure records no approved egress; recovery records the restored route reference for the same allowed request.	Failure leaves the synthetic work uncompleted; recovery completes the fixture once.	No direct or unapproved fallback; recovery is a separate accepted attempt.
Retry reconciliation and no false attribution	Use a synthetic draft whose first attempt has an uncertain server result, then reconcile before retrying.	Each attempt has its own route reference; an uncertain attempt is never attributed to a later route.	The draft remains editable until reconciliation; retry creates at most one confirmed result.	Pass only when reconciliation precedes retry and route/app fields remain paired.

Use two fresh contexts for two approved workloads. Context A receives its independent approved route and related configuration before its first page. Context B deliberately has no independent route, so its recorded expectation is the launch profile's inherited route and geographic identity. Give each context a distinct route label, allowed request and protocol scope, owner, and expected application result. A proxy route affects the network path only. It is not evidence of the destination's storage location, processing location, retention practice, or legal basis for handling data.

Before either context opens a dependent page, wait for the documented context proxy and geographic updates. Leave Context A's locale, language, and time zone on auto only when proxy-derived values are intended. Record explicit overrides separately, including their approval. Then run the smallest authorized workflow for each context. The expected result can be a public test page, a synthetic fixture, or another application-owned check that cannot create a customer transaction.

For Context A, verify actual egress for its approved request and protocol scope against the provider's own authorized endpoint record or the organization's approved network record. For Context B, verify the inherited route against the launch profile's recorded assignment. A page title, browser setting, or successful response is not that verification. Record route evidence and application evidence as separate results. A route that is unavailable, an unexpected direct path, or a request that follows an unapproved exclusion must fail the check. Do not continue the required workflow through another route.

Make the egress record specific enough to answer an operational question without exposing a credential or endpoint in the job output. It can identify the provider record or organization network record, the route label, the allowed protocol, the observation time, and the context label. The provider or network owner retains the underlying connection data under its own controls. The application job need only retain the reference and the pass or fail result. That separation keeps a browser run from becoming an uncontrolled network log while still allowing an owner to investigate a mismatch.

The check must match the request that the approved workload actually makes. A result for a simple HTTP health request cannot establish the route used by an HTTPS application workflow, and a record for one allowed protocol does not cover another protocol automatically. When the task permits route exclusions, state their exact business purpose and request scope in the assignment. Treat the exclusion as a separate expected path, not as evidence that the proxy was used. When a new application version changes the request pattern or protocol needs, review the assignment before expanding the run rather than assuming the old route evidence still applies.

Run negative cases before treating the change as accepted. Make Context A's approved route unavailable and confirm that no direct fallback succeeds. Exercise an approved exclusion only within its documented scope and confirm that a request outside that scope does not use it. If the application has a retry or submission action, use a synthetic draft and confirm that a failed route leaves it editable, a cancellation is not shown as completed, and an uncertain server result is reconciled before another submission. These are application acceptance requirements, not guarantees of a proxy setting.

Keep product prerequisites separate from application outcomes in the acceptance record. Prerequisites are the documented ENT Tier3 entitlement, loaded profile, approved route assignment, allowed request and protocol scope, and completed context proxy and geographic updates before a dependent page. Outcomes are both the application's expected result and an egress attribution reference for the exact request and protocol. Mark the run passed only when every prerequisite and both outcomes are present; otherwise fail closed, stop the affected context, retain minimal evidence, restore the last approved assignment when safe, and reconcile any uncertain application result before retrying.

The handoff record needs the two context labels, launch-profile revision, independent route label where present, allowed scope and exclusions, geo mode or explicit overrides, start and end time, egress result, application result, and owner. It should exclude route credentials, browsing content, and full request traces. This gives the next operator enough information to pause the affected context or restore its prior approved assignment without turning operational logging into uncontrolled data collection.

For related reader guidance, see proxy configuration, dynamic proxy switching, and multi-account browser isolation. These pages describe adjacent operational questions; they do not replace destination authorization, privacy review, or change control.

Sources

• BotBrowser: Per-Context Proxy
• Playwright Browser.newContext proxy option
• MDN: Proxy servers and tunneling