Proxies for Puppeteer and Playwright: Choosing a Type

Which proxy type to run headless browsers through: residential for guarded sites, datacenter for volume, one session per browser context, with code.

A headless browser shows a site everything a real browser does: the fingerprint, the TLS handshake and the IP address together. If the target blocks hosting networks, a clean fingerprint will not save a datacenter exit, so use residential proxies. If the target does not, datacenter proxies are usually faster, cheaper and steadier. Then pick the billing model by what drives your cost: browser pages are heavy, so per-gigabyte plans get expensive quickly, and a cluster with many parallel contexts is often cheaper billed by concurrent connections. Node4 sells each type compared here, so this is a guide to choosing a type, not a ranking of providers.

One exit per browser context

The most useful habit with either library is to tie one proxy session to one browser context. A context keeps its own cookies, so if its exit also stays fixed, a site sees one consistent visitor per context instead of a visitor whose address changes between the login page and the dashboard.

Playwright lets you set the proxy per context, which makes this a few lines. Both examples are ES modules (a .mjs file), so await works at the top level:

import { chromium } from 'playwright';

// The placeholder launch proxy is deliberate: some Chromium builds ignore
// context proxies unless the browser itself was launched with one, and then
// every context silently leaves from your own address.
const browser = await chromium.launch({ proxy: { server: 'http://per-context' } });
async function contextFor(job) {
  return browser.newContext({
    proxy: {
      server: 'http://gw-rotating_datacenter.node4.io:8083',
      username: `USERNAME-session-${job}`,
      password: 'PASSWORD',
    },
  });
}

const ctxA = await contextFor('cat01');   // one exit for every page in this context
const ctxB = await contextFor('cat02');   // a different exit

Puppeteer sets the proxy when the browser launches, and Chromium reuses proxy credentials it has already accepted, so the dependable pattern is one browser per session:

import puppeteer from 'puppeteer';

const browser = await puppeteer.launch({
  args: ['--proxy-server=http://gw-residential.node4.io:8082'],
});
const page = await browser.newPage();
await page.authenticate({ username: 'USERNAME-country-de-session-cat01', password: 'PASSWORD' });
await page.goto('https://ipinfo.io/json');   // confirm the exit before the real work

Use the HTTP port for browsers. Chromium does not send a username and password to a SOCKS5 proxy, and it resolves hostnames locally before using one unless you configure otherwise; the Puppeteer and Playwright setup guide covers both cases.

Proxy types for headless browsers, compared

What browser traffic does to the bill

A browser loads everything: images, fonts, scripts, analytics beacons. For example, suppose a product page that an HTTP client fetches as 150 KB of HTML costs 3 MB through a browser. At 20,000 pages a day that is 60 GB a day instead of 3 GB. Measure one of your own pages before you size a plan.

Two ways to deal with it:

• Block what you do not need. Route interception (page.route() in Playwright, page.setRequestInterception() in Puppeteer) can abort image, font and media requests. On many retail and listing pages this removes most of the bytes without changing the data you extract.
• Change the billing unit. On Rotating Unmetered you pay for how many connections are open at once, and page weight stops mattering. A browser opens several connections per page, so size it by peak open connections across the cluster, not by the number of contexts: 30 contexts that each hold around 6 connections need about 180, plus headroom. See connection-based pricing and the proxy calculator.

How sessions behave on each product

On Rotating Datacenter and Rotating Unmetered, a session ID holds one exit for up to 30 minutes, counted from when the exit is first assigned. Using it does not extend it. A crawl that logs in at minute 0, idles, and resumes at minute 28 can lose its exit two minutes later, so give long jobs a new session ID per stage and log in again when the exit changes. Without a session ID, each new HTTPS tunnel gets a new exit and every request sent through an open tunnel keeps it; a plain-HTTP request gets its own exit each time.

On residential, a session is best effort, with a 30-minute ceiling, and can end sooner if the device behind the exit goes offline. Check the exit at the start of each stage and restart the stage if it changed. Sticky vs rotating sessions has the details for both.

Which type to buy

If the target blocks hosting networks or you need countries outside the US, Italy and Spain, buy residential and cut page weight with request interception before choosing a plan size on residential pricing. If the target accepts datacenter traffic, use Rotating Datacenter for modest crawls and Rotating Unmetered when a cluster keeps many connections open all day. Keep dedicated addresses for a few long-lived browsers, and shared ones for getting the launch flags right. For the wider trade-off see datacenter vs residential proxies, and for providers rather than types, residential proxy providers compared.