skip to content

Your Playwright suite must reach a staging hotel-booking site only through an authenticated HTTP proxy. How do you configure that?

level: seniorimportance: should knowfreq 31%

answer

  1. Four fields, one object
  2. Set once, inherited by every context
  3. Some hosts should skip the hop
  4. Credentials belong in the environment
  5. A proxy hop is not a site login

basics

~20 s

Pass a proxy object to browserType.launch(): server, plus optional username, password and a comma-separated bypass list. Set at launch it covers every context that browser creates, and the credentials should come from environment variables, not source.

solid answer

~40 s

`browserType.launch()` takes a `proxy` option shaped `{ server, bypass, username, password }`. `server` accepts `http://host:port` or `socks5://host:port`, and a bare `host:port` is treated as HTTP. `username` and `password` cover proxy authentication, and `bypass` is a comma-separated list of domains that should be reached directly - useful when the staging booking API is inside the network but assets are not. Setting it at launch makes it browser-wide: every context created from that browser inherits it, which is the right granularity when the whole suite sits behind one corporate proxy. If different tests need different proxies, set it per context instead. Keep the credentials in environment variables and read them at the launch call, so no secret is committed. If the proxy terminates TLS with its own certificate, that is a separate context-level concern.

code

typescript · 13 lines
typescript
import { chromium } from '@playwright/test';

const browser = await chromium.launch({
  proxy: {
    server: process.env.PROXY_SERVER ?? 'http://proxy.internal:3128',
    bypass: '.internal, localhost',
    username: process.env.PROXY_USER,
    password: process.env.PROXY_PASS,
  },
});
const page = await browser.newPage();
await page.goto('https://staging.example.com/hotels/search');
await browser.close();

go deeper

for a junior

Know that the proxy option is an object on the launch call with a server field, and that a username and password can be supplied when the proxy asks for them.

for a middle

Explain that a proxy set at launch applies to every context from that browser, that bypass is a comma-separated domain list, and that both HTTP and SOCKS servers are accepted.

for a senior

Show the operational side: credentials from the environment, artifacts treated as sensitive, and a diagnosis path that separates a proxy failure from an application failure.

for a principal

Own where egress configuration lives for the whole suite and how secrets reach it, so no team ends up pasting a proxy password into a config to unblock itself.

Playwright's `proxy` launch option is how you tell the browser process to send its traffic somewhere other than straight out. It appears on `browserType.launch()` and `browserType.launchPersistentContext()`, and the same shape exists at the context level. ## The shape of the option ```ts const browser = await chromium.launch({ proxy: { server: process.env.PROXY_SERVER!, // 'http://proxy.internal:3128' bypass: '.internal, localhost', username: process.env.PROXY_USER, password: process.env.PROXY_PASS, }, }); ``` - **`server`** - the proxy to use for all requests. HTTP and SOCKS are supported: `http://myproxy.com:3128` or `socks5://myproxy.com:3128`. A short `myproxy.com:3128` is read as an HTTP proxy. - **`bypass`** - an optional comma-separated list of domains reached directly, for example `'.com, chromium.org, .domain.com'`. - **`username` / `password`** - optional credentials for a proxy that requires authentication. ## Choosing the scope | Where you set it | Who it affects | Fits when | |---|---|---| | `launch()` options | every context from that browser | one proxy for the whole suite | | context options | that context only | different tests need different egress | For the corporate-proxy case the launch level is the right choice: one setting, no test that can accidentally opt out. Per-context proxies earn their place when a test deliberately exercises a different network path - a regional egress for the booking search, say - and you want the difference visible in that test rather than in global setup. ## Handling the credentials 1. Read them from the environment at the launch call. Never inline a proxy password in a config or a test file, and never in an example pasted into a ticket. 2. Provide them through the CI secret store, so the values exist only in the job that needs them. 3. Keep them out of logs. Traces, HAR files and verbose logs can capture request metadata, so treat any artifact from a proxied run as sensitive until you have checked it. 4. Fail loudly on a missing variable rather than silently launching without a proxy - a suite that quietly bypasses the proxy will fail later with a confusing DNS or timeout error. ## What the option does and does not cover - It configures the **browser's** egress. Every page and request the browser makes goes through it, subject to `bypass`. - It does not authenticate you to the *site*. Proxy credentials are for the proxy hop only; site login stays a separate concern. - If the proxy intercepts TLS with its own certificate authority, the browser will reject the certificate. Trusting it is a context-level TLS concern, not something the `proxy` option solves. - Requests your test code makes outside the browser are configured separately - the launch option cannot reach them. ## Diagnosing a proxied run When the staging booking site is unreachable, work from the outside in: - Does a plain command-line request through the same proxy and credentials succeed from the same machine? If not, the problem is not Playwright's. - Is the failure a connection error or an authentication challenge? A challenge means the server value is reaching the browser but the credentials are missing or wrong. - Does a host that should be direct appear to be going through the proxy? Check the `bypass` list - it matches domains, so a missing leading dot on a subdomain pattern is a classic mistake. - Does the failure only occur on CI? Compare the environment variables the job actually sees against the ones the local run uses. ## The judgment part Interviewers ask this because it is a small API wrapped around a real operational decision: whether the whole browser goes through one route, whether secrets are handled properly, and whether you can tell a proxy failure from an application failure. The answer that lands names the four fields, puts the option at the launch level for a suite-wide proxy, sources the credentials from the environment, and separates the proxy hop from site authentication and from TLS trust.

  • When would you set the proxy on a context instead of at launch?
    When tests need different egress from each other - one exercising a regional route to the booking API while the rest use the default. Setting it per context keeps the difference visible in the test that depends on it, instead of hiding it in shared launch options.
  • The proxy intercepts TLS with a corporate certificate authority and pages fail to load. What is the fix?
    That is a certificate-trust problem, not a proxy-option one. Either install the corporate authority into the trust store the browser uses, or relax certificate checking with the context-level TLS option - preferably only for the staging environment where the interception happens.

saying these in an interview costs you the question

  • Hardcodes proxy credentials in the committed config
  • Thinks proxy username and password log into the site
  • Expects bypass to accept a regular expression
  • Assumes a launch proxy also covers non-browser requests
  • Believes each context needs its own proxy setting