Proxies for Puppeteer, Playwright and Selenium

Start by finding out what your target refuses

The one thing that genuinely differs between targets is whether datacenter ranges are accepted at all, and with a browser automation job you are unusually well placed to find out, because the script already exists. Every verified account gets a free allocation of shared datacenter proxies with no card, so run your existing Puppeteer, Playwright or Selenium job against the real target through those addresses and read what comes back. A rendered page means datacenter is the right product and the cheapest thing that works. A challenge, an interstitial, or a shell where the content should be means that target classifies hosting ranges as a class, and no larger datacenter plan changes the answer; residential is what you need. Buying more datacenter at that point is spending money to relearn the same fact.

The same decision, walked from the product end rather than the tool end, is in choosing the right proxy type.

One page load, many requests, and why a browser wants a session

Per-request rotation is the right default for a crawler, where each request stands alone and a fresh address per request is the point. A browser is the case where it is usually wrong. Every subresource is its own request through the same proxy configuration, so under per-request rotation the document and its scripts can leave from different networks within the same second, and the next navigation may reuse any connection that is still open. Most targets never notice. Targets that tie a session to an address do, and the symptom is a login that succeeds followed by a page that treats you as a stranger. Adding a session segment to the username pins one exit for the whole flow. On the rotating tiers that pin holds for up to 30 minutes, measured from when it is first assigned rather than from your last request, so a job that runs longer should mint a fresh session id and carry on. Residential accepts session ids too, but its stickiness is delegated to the upstream partner network rather than to our own session lease, so treat the hold as best effort there and build the flow to survive the address changing under it.

What actually breaks when the exit changes mid-flow is covered in sticky versus rotating sessions.

Wiring it in Puppeteer and Playwright

Both set the proxy at the browser level and neither needs a plugin. In Puppeteer the address is a Chromium launch argument passed in args, and the credentials are a separate step, because Chromium discards a username and password embedded in that flag: page.authenticate carries them instead, once per page. Playwright has a first-class proxy option taking server, username and password, accepted both at launch and on browser.newContext, which is what lets one browser process hold several contexts on different exits. Because targeting and session ids ride in the username on our gateways, choosing a country or pinning a session is a string you build rather than an endpoint you switch, so the wiring below is the whole integration and none of it changes when the pool does.

The 407s, the per-context caveat and the DNS and WebRTC side channels are in proxy authentication in Puppeteer and Playwright.

• Puppeteer: args: ["--proxy-server=http://HOST:PORT"], then page.authenticate({ username, password })
• Playwright: proxy: { server, username, password }, on launch or on browser.newContext()
• Country and session ride in the username: USER-country-de-session-482913

Selenium is the awkward one, and the reason is not your code

Selenium speaks WebDriver, and the WebDriver proxy capability has fields for the proxy host, the scheme and a username and password for SOCKS, and no username or password for an HTTP proxy at all. Chromium then ignores credentials embedded in the proxy-server flag, so the browser connects unauthenticated, is refused, and raises a dialog drawn outside the page where no element lookup can reach it. Two arrangements avoid the problem rather than working around it. The first is to register the public address of the machine running Selenium and connect with no credentials at all: IP whitelisting is available on every product, and on the rotating gateways a whitelisted machine can still send the username with an empty password to keep country and session targeting, while a whitelisted residential connection sends no username, which makes its exit untargeted. The second is Selenium 4's own authentication handler, which answers the challenge over DevTools with no extension and no local forwarder.

Four authentication routes with working code for each, and the three ways to rotate, are in rotating a Selenium proxy, and the auth traps on the way.

A browser moves far more per page than a crawler does

This is the part that decides the invoice, and it is the one argument on this page that a Scrapy buyer never has to make. A crawler fetches the document and parses it. A headless browser fetches the document and then everything the document asks for: the framework bundle, the fonts, the images, the analytics beacons. On a per-gigabyte product that multiple lands directly on the bill, so the cheapest rate per gigabyte is not automatically the cheapest way to run a browser. Rotating Unmetered has no byte meter at all and is priced by how many connections you hold open at once, which for this workload is a number you already know: it is how many browser workers you run. Blocking images, fonts and media in the browser cuts the same bill on a metered product, and is worth doing before you size anything.

Where each billing unit wins, with the arithmetic rather than the adjective, is in unmetered billing versus per GB.

What a proxy fixes here, and what it leaves standing

Rotation and residential exits solve one problem: per-address accounting. Rate limits, per-IP request caps and single-address bans stop deciding your outcome when requests arrive from different networks. They do nothing about the rest of what a browser announces about itself. An automated Chromium is identifiable from its own runtime properties, its TLS handshake, its font and codec list and its timing, and a target correlating on those will connect your sessions whatever the exit is. A cookie set behind one exit and replayed behind another is a stronger signal than either exit was on its own. Buy proxies for the address problem, treat the browser's own footprint as separate work, and change one variable at a time when something starts failing, because otherwise you never learn which of the two it was.

What you are buying, by product

Residential exits are real consumer connections in an upstream partner network, billed by the gigabyte, and are what a target refusing datacenter ranges will accept. Rotating datacenter hands you a fresh address per request from blocks node4 owns in the United States, Italy and Spain, also billed by the gigabyte, and is the cheaper answer where a target tolerates hosting traffic but limits each address. Rotating Unmetered is the same pool and the same gateway with the byte meter removed, priced by concurrent connections instead. Dedicated datacenter is priced per address with nothing metering the traffic, which suits a long-running browser job against a tolerant target where the bytes would otherwise dominate the cost.

The same four products compared against competitors rather than against each other, for this workload specifically: how the proxy types rank for a browser job.