How to Use Proxies with Playwright: A Practical Guide

Playwright can automate Chromium, Firefox, and WebKit, but launching a real browser does not automatically give each job a suitable network identity.

Without a proxy, browser sessions normally exit through the IP address of the machine running Playwright. That may be acceptable for local testing, but it becomes limiting when you need to:

• test a website from another country or region
• run independent browser jobs without routing all traffic through one IP
• preserve one network identity during a multi-step workflow
• validate localized prices, search results, ads, or availability
• separate browser workers by customer, market, or task
• reproduce proxy-related errors before deploying at scale

This guide shows how to configure authenticated proxies in Playwright, verify that traffic is actually using the expected route, choose between rotating and sticky sessions, and debug the failures that occur in real browser automation systems.

Use these techniques only for authorized testing, public-data collection, quality assurance, monitoring, and other workflows that comply with applicable laws and target-site policies.

How Playwright proxy configuration works

Playwright supports proxy configuration at two useful levels:

1. Browser launch level — all contexts and pages created in that browser use the same proxy.
2. Browser context level — each context can use its own proxy configuration.

The proxy object accepts a server and optional authentication credentials. Playwright supports HTTP and SOCKS proxy servers, as well as an optional bypass list. Although a host-and-port value may be interpreted as HTTP, using an explicit scheme such as http:// or socks5:// makes configuration errors easier to detect.

A typical authenticated proxy configuration looks like this:

proxy: {
  server: 'http://proxy.example.com:9000',
  username: 'customer-123-country-US',
  password: process.env.PROXY_PASSWORD,
}

Keep the proxy address, username, and password separate. Do not embed credentials directly in source code or commit them to Git.

Before you start

Create a new Node.js project and install Playwright:

mkdir playwright-proxy-example
cd playwright-proxy-example

npm init -y
npm install playwright typescript tsx
npx playwright install chromium

Create environment variables through a .env file, shell, secret manager, or deployment platform:

PROXY_SERVER=http://proxy.example.com:9000
PROXY_USERNAME=customer-123-country-US
PROXY_PASSWORD=replace-with-your-password
IP_CHECK_URL=https://iprobe.io/json
TARGET_URL=https://example.com

Add local secrets and diagnostic files to .gitignore:

.env
.env.*
trace.zip
playwright-report/
test-results/

Quick start: launch Playwright through a proxy

Create proxy-check.ts:

import { chromium } from 'playwright';

function requiredEnv(name: string): string {
  const value = process.env[name]?.trim();

  if (!value) {
    throw new Error(`Missing required environment variable: ${name}`);
  }

  return value;
}

function getProxyConfig() {
  const server = requiredEnv('PROXY_SERVER');
  const username = process.env.PROXY_USERNAME?.trim();
  const password = process.env.PROXY_PASSWORD?.trim();

  if (!/^(https?|socks5):\/\//i.test(server)) {
    throw new Error(
      'PROXY_SERVER must include a protocol, such as http:// or socks5://',
    );
  }

  if ((username && !password) || (!username && password)) {
    throw new Error(
      'PROXY_USERNAME and PROXY_PASSWORD must both be set or both be omitted',
    );
  }

  return {
    server,
    ...(username ? { username } : {}),
    ...(password ? { password } : {}),
  };
}

async function main(): Promise<void> {
  const proxy = getProxyConfig();
  const checkUrl =
    process.env.IP_CHECK_URL?.trim() || 'https://iprobe.io/json';

  const browser = await chromium.launch({
    headless: true,
    proxy,
  });

  try {
    const context = await browser.newContext();
    const page = await context.newPage();

    page.on('requestfailed', request => {
      console.error('request_failed', {
        url: request.url(),
        method: request.method(),
        error: request.failure()?.errorText || 'unknown error',
      });
    });

    const response = await page.goto(checkUrl, {
      waitUntil: 'domcontentloaded',
      timeout: 45_000,
    });

    if (!response) {
      throw new Error('The IP-check navigation returned no response');
    }

    if (!response.ok()) {
      throw new Error(`IP-check endpoint returned HTTP ${response.status()}`);
    }

    console.log('IP-check response:');
    console.log(await page.locator('body').innerText());

    await context.close();
  } finally {
    await browser.close();
  }
}

main().catch(error => {
  console.error(error instanceof Error ? error.message : error);
  process.exitCode = 1;
});

Run it:

PROXY_SERVER="http://proxy.example.com:9000" \
PROXY_USERNAME="customer-123-country-US" \
PROXY_PASSWORD="your-password" \
npx tsx proxy-check.ts

Do not proceed to the real target until this script confirms all three of the following:

• Playwright can reach the proxy endpoint.
• The proxy accepts the supplied credentials.
• The visible exit IP and location match what you requested.

A browser successfully launching does not prove that the target traffic is using the expected proxy route. Always verify the observed exit identity.

Browser-level proxy configuration

A launch-level proxy is the simplest option:

const browser = await chromium.launch({
  proxy: {
    server: process.env.PROXY_SERVER!,
    username: process.env.PROXY_USERNAME,
    password: process.env.PROXY_PASSWORD,
  },
});

const context = await browser.newContext();
const page = await context.newPage();

Use a browser-level proxy when:

• every job in the browser should use the same route
• one worker represents one country or market
• the browser handles one sticky session
• operational simplicity is more important than sharing a browser process

The main advantage is predictability. Every context created inside that browser inherits the browser's network route.

The main limitation is flexibility. Changing the proxy generally means closing the browser and launching another one with a different configuration.

Context-level proxy configuration

Playwright also supports supplying a proxy when creating a browser context:

import { chromium } from 'playwright';

const browser = await chromium.launch();

const usContext = await browser.newContext({
  proxy: {
    server: process.env.PROXY_SERVER!,
    username: 'customer-123-country-US',
    password: process.env.PROXY_PASSWORD,
  },
  locale: 'en-US',
  timezoneId: 'America/New_York',
});

const deContext = await browser.newContext({
  proxy: {
    server: process.env.PROXY_SERVER!,
    username: 'customer-123-country-DE',
    password: process.env.PROXY_PASSWORD,
  },
  locale: 'de-DE',
  timezoneId: 'Europe/Berlin',
});

const usPage = await usContext.newPage();
const dePage = await deContext.newPage();

await Promise.all([
  usPage.goto('https://iprobe.io/json'),
  dePage.goto('https://iprobe.io/json'),
]);

await usContext.close();
await deContext.close();
await browser.close();

A browser context is a practical unit for separating cookies, storage, permissions, locale, timezone, and proxy identity.

Use context-level proxies when:

• one browser process needs to serve multiple independent jobs
• each job needs isolated cookies and storage
• different jobs need different countries
• you want one context per account, task, or session
• browser startup cost is significant and context isolation is sufficient

Do not treat the proxy as a page-level setting that can be safely changed halfway through a workflow. Create a new context when a task needs a different proxy identity.

Authenticated HTTP proxies

For an authenticated HTTP proxy, pass credentials through the proxy object:

const context = await browser.newContext({
  proxy: {
    server: 'http://proxy.example.com:9000',
    username: process.env.PROXY_USERNAME,
    password: process.env.PROXY_PASSWORD,
  },
});

This is different from website authentication.

Proxy credentials authenticate the connection between Playwright and the proxy. Website credentials authenticate the user to the destination website. Passing proxy credentials through form fields, httpCredentials, cookies, or a target-site Authorization header does not replace the proxy configuration.

A 407 Proxy Authentication Required response means the browser reached the proxy, but credentials were missing, malformed, expired, or rejected.

When debugging a 407 error, check:

1. The username is complete and has not been truncated.
2. The password does not contain unintended whitespace.
3. The proxy host and port belong to the same product and protocol.
4. Environment variables are available inside the actual runtime.
5. The same credentials work with a direct proxy test.
6. Provider-specific country or session parameters are formatted correctly.

Test the exact credentials with curl:

curl \
  --proxy "http://proxy.example.com:9000" \
  --proxy-user "customer-123-country-US:your-password" \
  --connect-timeout 15 \
  --max-time 30 \
  "https://iprobe.io/json"

If curl also receives a 407, fix the credentials or account configuration before changing Playwright code.

If curl succeeds but Playwright fails, compare the exact host, port, protocol, username, password, and runtime environment used by both clients.

Using SOCKS5 proxies

Set a SOCKS5 server with an explicit scheme:

const browser = await chromium.launch({
  proxy: {
    server: 'socks5://proxy.example.com:1080',
  },
});

Authentication capabilities can depend on the browser engine, proxy implementation, and provider endpoint. Test the precise endpoint and authentication mode you plan to deploy rather than assuming that HTTP and SOCKS endpoints behave identically.

Also confirm that the port is intended for SOCKS5. A common source of tunnel errors is using:

• an HTTP scheme with a SOCKS-only port
• a SOCKS scheme with an HTTP-only port
• the correct hostname with the wrong product port

Verify the proxy before visiting the target

A reliable automation workflow separates proxy verification from target testing.

Use this order:

1. Test the proxy with curl.
2. Test it through Playwright against a neutral IP endpoint.
3. Confirm the requested country or city.
4. Visit the real target.
5. Validate the business output, not only the HTTP status.

A useful verification helper:

import type { Page } from 'playwright';

type ExitCheck = {
  raw: string;
  finalUrl: string;
  status: number;
};

export async function verifyExit(
  page: Page,
  checkUrl = 'https://iprobe.io/json',
): Promise<ExitCheck> {
  const response = await page.goto(checkUrl, {
    waitUntil: 'domcontentloaded',
    timeout: 45_000,
  });

  if (!response) {
    throw new Error('Exit verification returned no HTTP response');
  }

  return {
    raw: await page.locator('body').innerText(),
    finalUrl: page.url(),
    status: response.status(),
  };
}

Store the result alongside the job record:

const exit = await verifyExit(page);

console.log({
  jobId: 'price-check-2026-08-06-001',
  requestedCountry: 'US',
  proxyMode: 'sticky',
  exitStatus: exit.status,
  exitBody: exit.raw,
});

This makes wrong-country output visible before it contaminates downstream data.

Rotating proxies versus sticky sessions

“Rotating” and “sticky” describe provider routing behavior, not Playwright features.

Playwright supplies the proxy credentials. The proxy service decides which exit route those credentials receive.

Use rotating sessions for independent tasks

Rotating routes are appropriate when each task can stand alone:

• product-detail collection
• public search-result snapshots
• category discovery
• availability checks
• one-page monitoring jobs
• large URL queues where jobs do not share state

A safe worker pattern is one isolated context per independent job:

import { chromium } from 'playwright';

type ProxyConfig = {
  server: string;
  username?: string;
  password?: string;
};

async function runIndependentJob(
  targetUrl: string,
  proxy: ProxyConfig,
): Promise<string> {
  const browser = await chromium.launch();

  try {
    const context = await browser.newContext({ proxy });

    try {
      const page = await context.newPage();
      const response = await page.goto(targetUrl, {
        waitUntil: 'domcontentloaded',
        timeout: 45_000,
      });

      if (!response) {
        throw new Error('Navigation returned no response');
      }

      return await page.title();
    } finally {
      await context.close();
    }
  } finally {
    await browser.close();
  }
}

For higher throughput, reuse a browser and create a new context per job, subject to measured CPU, memory, connection, and proxy limits.

Use sticky sessions for stateful workflows

Sticky sessions are appropriate when the workflow needs network continuity:

• login and account navigation
• shopping carts
• multi-step forms
• paginated sessions with stored state
• browser agents completing several related actions
• workflows where cookies and IP should remain consistent

Keep the same proxy session credential and browser context for the entire logical workflow:

const context = await browser.newContext({
  proxy: {
    server: process.env.PROXY_SERVER!,
    username: 'customer-123-country-US-time-10-sid-checkout-001',
    password: process.env.PROXY_PASSWORD,
  },
  locale: 'en-US',
  timezoneId: 'America/New_York',
});

const page = await context.newPage();

await page.goto('https://example.com/login', {
  waitUntil: 'domcontentloaded',
});

await page.getByLabel('Email').fill(process.env.ACCOUNT_EMAIL!);
await page.getByLabel('Password').fill(process.env.ACCOUNT_PASSWORD!);
await page.getByRole('button', { name: 'Sign in' }).click();

// Continue the same workflow in the same context and proxy session.

The username format is provider-specific. Use the credential generator or documentation supplied with your proxy account rather than copying session syntax from another provider.

Do not rotate the route in the middle of a stateful task unless the workflow is explicitly designed to recover from that identity change.

Match browser settings to proxy geography

A proxy changes the network route. It does not automatically update every browser signal or stored preference.

For location-sensitive tasks, consider aligning:

• proxy country and city
• browser locale
• timezone
• target URL or market parameter
• previously stored cookies
• account region
• accepted language
• expected currency

Example:

const context = await browser.newContext({
  proxy: {
    server: process.env.PROXY_SERVER!,
    username: 'customer-123-country-GB',
    password: process.env.PROXY_PASSWORD,
  },
  locale: 'en-GB',
  timezoneId: 'Europe/London',
});

Do not assume that correct IP geography guarantees correct page output. Websites may also use account settings, cookies, URL parameters, language, inventory region, or prior user choices.

For every geo-sensitive result, log both the requested route and the observed output:

console.log({
  requestedCountry: 'GB',
  locale: 'en-GB',
  timezone: 'Europe/London',
  visibleExit: exit.raw,
  finalUrl: page.url(),
  displayedCurrency: 'GBP',
});

The useful result is not merely HTTP 200. The useful result is the correct country, currency, language, inventory, search market, or business data.

Wait for the page correctly

Proxy traffic can make navigation slower, but increasing every timeout is rarely a complete fix.

Use domcontentloaded for initial navigation, then wait for a locator that proves the required data is ready:

await page.goto(targetUrl, {
  waitUntil: 'domcontentloaded',
  timeout: 45_000,
});

await page
  .locator('[data-testid="product-price"]')
  .first()
  .waitFor({
    state: 'visible',
    timeout: 15_000,
  });

Modern pages may keep analytics, streaming, polling, or other background connections active. Waiting for an application-specific locator is usually more meaningful than waiting for all network activity to stop.

A navigation timeout may come from:

• an unreachable proxy endpoint
• slow proxy tunnel establishment
• a dead or overloaded route
• target response latency
• heavy JavaScript execution
• an unsuitable wait condition
• a missing selector
• a target page that returned different content

Measure which phase failed before changing the timeout.

Retry without repeating the same failure

Retries should change something meaningful.

Do not blindly retry:

• a 407 with the same rejected credentials
• an invalid proxy hostname
• an unsupported protocol
• a permanent account restriction
• a malformed target URL
• the same unhealthy sticky route indefinitely

A simple retry helper:

function sleep(milliseconds: number): Promise<void> {
  return new Promise(resolve => setTimeout(resolve, milliseconds));
}

async function withRetry<T>(
  operation: (attempt: number) => Promise<T>,
  maxAttempts = 3,
): Promise<T> {
  let lastError: unknown;

  for (let attempt = 1; attempt <= maxAttempts; attempt += 1) {
    try {
      return await operation(attempt);
    } catch (error) {
      lastError = error;

      if (attempt === maxAttempts) {
        break;
      }

      const delay = Math.min(1_000 * 2 ** (attempt - 1), 8_000);
      await sleep(delay);
    }
  }

  throw lastError;
}

Use it around a complete job boundary:

const result = await withRetry(async attempt => {
  const context = await browser.newContext({
    proxy: getProxyForAttempt(attempt),
  });

  try {
    const page = await context.newPage();
    const response = await page.goto(targetUrl, {
      waitUntil: 'domcontentloaded',
      timeout: 45_000,
    });

    if (!response) {
      throw new Error('No navigation response');
    }

    if (response.status() === 429) {
      throw new Error('Target returned HTTP 429');
    }

    return await page.title();
  } finally {
    await context.close();
  }
});

getProxyForAttempt() should implement your actual policy. Depending on the workflow, a retry might:

• use a fresh rotating identity
• request a new sticky session ID
• move the job to another route
• reduce concurrency
• wait longer before retrying
• stop immediately for non-retryable errors

Debug Playwright proxy failures

Use a small diagnostic script before debugging your full crawler:

page.on('console', message => {
  console.log('browser_console', {
    type: message.type(),
    text: message.text(),
  });
});

page.on('requestfailed', request => {
  console.error('request_failed', {
    url: request.url(),
    resourceType: request.resourceType(),
    error: request.failure()?.errorText,
  });
});

page.on('response', response => {
  if (response.status() >= 400) {
    console.warn('http_error', {
      status: response.status(),
      url: response.url(),
    });
  }
});

Playwright distinguishes a network failure from an HTTP error response. A response such as HTTP 403, 404, 429, or 503 does not normally trigger requestfailed; monitor both failed requests and response status codes.

Change one variable at a time. If you simultaneously change the proxy, browser, headers, timeout, locale, and concurrency, you may produce a successful run without learning which change fixed the problem.

Capture a Playwright trace

Tracing is useful for intermittent proxy failures:

const context = await browser.newContext({
  proxy: getProxyConfig(),
});

await context.tracing.start({
  screenshots: true,
  snapshots: true,
  sources: true,
});

try {
  const page = await context.newPage();

  await page.goto(process.env.TARGET_URL!, {
    waitUntil: 'domcontentloaded',
    timeout: 45_000,
  });

  await page.locator('body').waitFor();
} finally {
  await context.tracing.stop({ path: 'trace.zip' });
  await context.close();
}

Open the trace:

npx playwright show-trace trace.zip

Traces can contain action timing, DOM snapshots, screenshots, source locations, and network activity. Do not upload traces containing customer data, authentication state, sensitive URLs, or secrets to public systems without reviewing them first.

Browser installation proxy versus browsing proxy

These are separate configurations.

This command configures the network used to download Playwright's browser binaries:

HTTPS_PROXY="http://corporate-proxy.example.com:8080" \
npx playwright install chromium

It does not replace the runtime proxy configuration used by browser pages.

Runtime browser traffic still needs:

await chromium.launch({
  proxy: {
    server: 'http://proxy.example.com:9000',
  },
});

Treating installation and runtime routing as separate settings prevents a common situation where browser installation succeeds but automated page traffic still exits directly.

A production-ready worker shape

A reliable worker should record enough context to explain each result:

type JobLog = {
  jobId: string;
  targetUrl: string;
  attempt: number;
  proxyProtocol: string;
  proxyMode: 'rotating' | 'sticky';
  requestedCountry?: string;
  requestedCity?: string;
  sessionId?: string;
  exitIdentity?: string;
  finalUrl?: string;
  status?: number;
  durationMs: number;
  errorType?: string;
  errorMessage?: string;
};

Do not log the proxy password. Avoid logging the complete username when it contains account identifiers or reusable session information.

A worker lifecycle can follow this sequence:

This makes resource cleanup, session ownership, retry boundaries, and route attribution clear.

Scale Playwright with proxies carefully

Scale only after one-context and low-concurrency tests are reliable.

Track at least:

• successful business outputs
• HTTP status distribution
• proxy connection failures
• 407 frequency
• tunnel failure frequency
• navigation latency
• wrong-country frequency
• bytes consumed per successful output
• retries per completed job
• browser memory and CPU usage

Do not optimize only for requests per second. A faster crawler that returns challenge pages, wrong-country results, duplicate output, or partial content is not more productive.

Use bounded concurrency:

async function runPool<T>(
  items: T[],
  concurrency: number,
  worker: (item: T) => Promise<void>,
): Promise<void> {
  const queue = [...items];

  async function consume(): Promise<void> {
    while (queue.length > 0) {
      const item = queue.shift();

      if (item !== undefined) {
        await worker(item);
      }
    }
  }

  await Promise.all(
    Array.from(
      { length: Math.min(concurrency, items.length) },
      () => consume(),
    ),
  );
}

Start with a small concurrency value. Increase it while observing success rate, target responses, browser resources, and proxy health.

Provider account limits, route availability, target behavior, and browser resource consumption may become bottlenecks at different points.

Python example

Install Playwright for Python:

pip install playwright
playwright install chromium

Create proxy_check.py:

import os
from playwright.sync_api import sync_playwright


def required_env(name: str) -> str:
    value = os.getenv(name, "").strip()

    if not value:
        raise RuntimeError(f"Missing environment variable: {name}")

    return value


proxy = {
    "server": required_env("PROXY_SERVER"),
    "username": required_env("PROXY_USERNAME"),
    "password": required_env("PROXY_PASSWORD"),
}

check_url = os.getenv("IP_CHECK_URL", "https://iprobe.io/json")

with sync_playwright() as playwright:
    browser = playwright.chromium.launch(
        headless=True,
        proxy=proxy,
    )

    try:
        context = browser.new_context()
        page = context.new_page()

        page.on(
            "requestfailed",
            lambda request: print(
                "request_failed",
                request.url,
                request.failure,
            ),
        )

        response = page.goto(
            check_url,
            wait_until="domcontentloaded",
            timeout=45_000,
        )

        if response is None:
            raise RuntimeError("IP check returned no response")

        if not response.ok:
            raise RuntimeError(
                f"IP check returned HTTP {response.status}"
            )

        print(page.locator("body").inner_text())
        context.close()
    finally:
        browser.close()

Run it:

PROXY_SERVER="http://proxy.example.com:9000" \
PROXY_USERNAME="customer-123-country-US" \
PROXY_PASSWORD="your-password" \
python proxy_check.py

The same operational rules apply to Python:

• verify the exit route first
• keep credentials outside source code
• use a context as the session boundary
• preserve one context for sticky workflows
• create isolated contexts for independent jobs
• monitor both network failures and HTTP error responses

Security and responsible-use checklist

Before production deployment:

• Store proxy passwords in a secret manager or protected environment variable.
• Never print complete authenticated proxy URLs.
• Redact passwords from exceptions and traces.
• Restrict access to logs containing account or session identifiers.
• Rotate exposed credentials immediately.
• Apply explicit concurrency and timeout limits.
• Respect site terms, access controls, privacy requirements, and applicable laws.
• Do not use proxies to access private data or bypass authentication.
• Stop jobs that repeatedly receive explicit access-denial responses.
• Retain only the data and diagnostic artifacts you actually need.

A proxy changes the network route. It does not grant permission to access content.

Final pre-deployment checklist

Your Playwright proxy integration is ready for controlled production testing when:

1. The proxy succeeds through curl.
2. The same credentials succeed through Playwright.
3. The visible exit IP matches the requested geography.
4. The real target loads through a minimal script.
5. The required business data is present.
6. Rotating and sticky behavior has been measured rather than assumed.
7. Retries have explicit limits and change something meaningful.
8. Proxy passwords are absent from source code and logs.
9. Browser contexts are always closed.
10. Traces and diagnostic logs are available for failed jobs.
11. Concurrency is bounded.
12. Success is measured by usable output, not only HTTP status.

Frequently asked questions

Can I set a different proxy for each Playwright page?

Use a separate browser context for each proxy identity. Proxy settings belong at the browser or context level, so pages that need different routes should normally live in different contexts.

Can one browser use several proxies?

Yes. Launch a browser and create separate contexts with separate proxy configurations. Verify this architecture against the browser engines and proxy endpoints you intend to use before scaling it.

Why does curl work while Playwright fails?

The two clients may be using different protocols, ports, credentials, DNS behavior, environment variables, or connection patterns. Compare the exact configuration and start with a one-page Playwright script.

Does a 403 mean the proxy is broken?

Not necessarily. An HTTP 403 means an HTTP response was received from the target or an intermediary. First verify the proxy against a neutral IP endpoint. If that succeeds, investigate the target response and whether your workflow is authorized.

Should I use rotating or sticky proxies?

Use rotating routes for independent tasks. Use sticky routes for multi-step workflows that need cookies, account state, and network identity to remain consistent.

Should I always use residential proxies with Playwright?

No. Choose the route type based on the target, geography, required reliability, authorization, cost, and test results. Datacenter routes may be sufficient for many APIs, test environments, and low-sensitivity websites. Residential routes are useful when the workflow legitimately requires consumer-network geography or when datacenter-origin traffic produces unreliable localized output.

Why does the page show the wrong country after the IP check succeeds?

The target may use cookies, account settings, locale, timezone, language, URL parameters, or previous region choices in addition to the exit IP. Record all of these signals together.

Should I use networkidle for proxy pages?

Usually not as the primary readiness condition. Navigate with domcontentloaded, then wait for a locator or assertion that represents the data your job needs.

Conclusion

Using a proxy with Playwright is easy at the syntax level:

proxy: {
  server,
  username,
  password,
}

Building a reliable proxy-based browser workflow requires more discipline.

Verify the exit identity before trusting the route. Use a browser context as the boundary for cookies, geography, and proxy sessions. Match rotating routes to independent jobs and sticky sessions to stateful workflows. Monitor HTTP responses separately from network failures. Capture traces for intermittent problems. Scale according to successful, correct outputs rather than raw browser volume.

When these boundaries are explicit, Playwright proxies become easier to test, debug, operate, and improve.

Related BytesFlows guides

• Playwright proxy troubleshooting
• Sticky contexts and cost control
• Python proxy scraping
• Browser automation proxies
• Residential proxy plans
• Proxy pricing

Technical references

• Playwright BrowserType proxy options↗
• Playwright network configuration↗
• Playwright tracing↗
• Playwright browser installation behind a proxy↗
• HTTP 407 Proxy Authentication Required↗