Playwright through a proxy: reproducible tests for authorized workflows
Playwright can configure an HTTP(S) or SOCKS5 proxy globally or per browser context. Per-context setup is useful for isolating a customer and credential set.
Key points in one minute
- One test context should represent one isolated session.
- A trace helps diagnose failures but may contain sensitive data.
- A minimal proxy bypass list prevents unnoticed direct traffic.
- Validate secret-bearing responses in memory rather than attaching them to reports.
Test boundaries
Before execution, define approved domains, users, actions, and request limits. Block third-party navigation in the test routing layer.
Implement an allowlist in route handling before page navigation: permit exact hosts and required static domains, and abort everything else with a recorded reason. Decide explicitly how analytics and advertising are handled; functional QA can usually block them safely. Store test scope with the scenario version and owner approval.
Context configuration
Pass server, username, password, and bypass through protected configuration. Never embed secrets in source code or test names.
Create a new browser context for each test user or lease and close it in finally. Never reuse storageState across customers. Keep proxy bypass minimal or some requests may go direct and create a false pass. Confirm the outbound address through an authorized diagnostic endpoint at scenario start.
Network events
Request and response events can confirm method, approved host, and status. Exclude payloads and authorization headers from reports.
Collect aggregate counts by host, method, status, and duration. Wait for expected responses using an exact predicate rather than arbitrary sleeps. Redact URL queries and headers before logging. Assert secret-bearing responses in process and retain only a boolean result plus a safe identifier.
Tracing a failure
Record a trace on the first retry or a dedicated diagnostic run. Restrict archive access and retention.
Trace policy should reflect sensitivity: on-first-retry in ordinary CI, a dedicated short diagnostic run in production-like environments, and no public archive uploads. Before retention, inspect snapshots, network, and console data for tokens. Assign deletion timing and audit support access to traces.
Practical checklist
- 1Isolate customers by browser context.
- 2Block out-of-scope targets.
- 3Remove secrets from traces and reports.
- 4Confirm the outbound address at scenario start.
- 5Set a deletion period for trace archives.
Sources and documentation
This material is based on primary, official, and technical sources. The article is an original summary written for this knowledge base.