Proxies for AI agents: Playwright MCP and browser-use 2026

An AI agent that navigates websites on its own — Claude with Playwright MCP, browser-use, cloud Browserbase — runs into the same wall as a regular parser: a couple of dozen requests from a single address, and instead of a page, a Cloudflare challenge appears. The difference is that the agent doesn't get upset and simply loops, burning tokens on attempts to "press a button that doesn't exist."

This can be resolved with a proxy. However, connecting a proxy to the agent turns out to be unexpectedly non-obvious: half of the instructions online suggest a syntax that Chromium silently ignores. Below are working configurations for the three most common stacks of 2026 and an analysis of the pitfalls that everyone stumbles upon.

Who Needs This

This guide is for those who have already launched an agent and encountered one of the following symptoms:

The agent performs 10–20 steps, and then each subsequent step returns a captcha or a "Verify you are human" page;
The agent sees different content than you do: prices, search results, and product availability are shown based on your server's IP, not the desired country;
The agent is running in the cloud (VPS, GitHub Actions, container), and the data center's address is already marked as bot-like;
You have specified a proxy with a username and password, but the browser starts as if there is no proxy at all.

If you are still at the stage of "why are agents blocked at all" — first read the breakdown of how anti-bot systems distinguish agent browsers from humans: it discusses detection signals, while this section focuses on the practicalities of connection.

Trap #1: Chromium Does Not Accept Username and Password in the Proxy String

The most common mistake, which costs people hours of debugging. The classic format from the provider is user:pass@host:port. You plug it into the browser's launch flag:

--proxy-server="http://user:[email protected]:8080"

And nothing works. Chromium does not support passing credentials within the --proxy-server flag: an error about unsupported proxy appears in the console, and traffic goes through without it. If you remove the credentials and leave only host:port, the browser in normal mode will show a system window requesting a username and password — and that’s where it stops, because in headless mode there is no window and no one to click in it.

This leads to three workable paths, and you need to choose wisely:

IP Authorization (whitelist). The cleanest option for agents. You add the address of the machine running the agent to the whitelist in the provider's dashboard — and then connect without a username and password, using just host:port. The --proxy-server flag starts working as intended, and headless mode does not ask for anything else. ProxyCove supports both methods — username:password and IP-whitelist, even simultaneously, so you can set up a whitelist for the agent while keeping a password for manual tasks.
Pass credentials at the API level, not the flag. Playwright, Puppeteer, and browser-use can accept username and password as separate fields — this is not the same mechanism as the command-line flag, and it works. This is suitable when you are writing the agent's code yourself.
Local relay. Set up a proxy without a password that forwards requests upstream with a password, and specify the local address to the agent. This option is for cases where the whitelist is unavailable: for example, if the machine's IP is dynamic.

Playwright MCP: A Configuration That Actually Works

Playwright MCP from Microsoft is the de facto standard today for agents that need a real browser. The proxy is set with server arguments directly in the MCP client configuration:

{"mcpServers":{"playwright":{"command":"npx","args":["@playwright/mcp@latest","--browser","chromium","--headless","--proxy-server","http://gate.example.com:8080","--proxy-bypass",".local,.internal","--isolated","--viewport-size","1920x1080"]}}}

What’s important here, point by point:

--proxy-server accepts both HTTP and SOCKS5 addresses in the form of socks5://host:port. Without credentials — see the trap above.
--proxy-bypass is a comma-separated list of domains that bypass the proxy. This is not a decorative option: if the agent has internal services or a local API, routing them through a residential channel incurs unnecessary traffic costs.
--isolated keeps the profile in memory and does not write it to disk. This is useful when each task needs to start from a clean slate. The downside is that cookies do not survive a restart, and each session for the website appears as a new visitor.
--user-data-dir — on the contrary, a persistent profile. For scenarios involving authentication, use this instead of isolation, and make sure to bind the IP (see the sticky section below).
--storage-state allows you to inject saved cookies and localStorage into an isolated session — a compromise between the two previous options.
--allowed-origins and --blocked-origins restrict where the agent can go at all. An underrated saving: an agent engrossed in analytics and advertising domains can easily triple traffic consumption.
--device (for example, "iPhone 15") and --user-agent change how the agent presents itself as a browser. Set them consistently with the type of proxy: a mobile User-Agent over a data center IP is a contradiction that anti-bot systems detect instantly.

Specifically about --cdp-endpoint: it connects MCP to an already running browser. In this case, the proxy is configured not by MCP flags but when starting that browser — a typical reason why "the proxy is set, but the IP remains the same."

browser-use: Proxy Through ProxySettings

If the agent is built on browser-use, the configuration goes into a settings object, and here you can pass the username and password — they go through the API, not the command line:

from browser_use import Browser, ProxySettings proxy = ProxySettings(server='http://gate.example.com:8080', username='user', password='pass', bypass='localhost,127.0.0.1') browser = Browser(proxy=proxy)

The server field is mandatory, while the others are optional. The same principle applies in pure Playwright: the proxy is set either globally when starting the browser or separately for each context through browser.newContext({ proxy: { server: ... } }). The latter is key for parallel agents: each context gets its own outgoing address, and ten tasks do not share a single IP.

Cloud Browsers: Proxy at the Session Level

With Browserbase and similar services, the browser lives in someone else's cloud, so launch flags are not available to you — the proxy is specified in the session parameters, usually in a string like http://username:password@gateway:port in the MCP server's environment variable. Chromium's limitation does not interfere here: the cloud provider itself parses the string and configures the browser from within.

A practical nuance: cloud browsers have their own pool of proxies, and it is shared among all clients. If the task is sensitive to the reputation of the address — logging into an account, working with a platform where you are already recognized — having your own channel is more predictable than a shared one.

Rotation or Sticky: Choose Based on Task Type

A rookie mistake is to enable rotation for every request and wonder why the agent gets logged out. Agent scenarios have two modes, and they are not interchangeable:

Rotation for every request (at ProxyCove this is port 824) — for reconnaissance: to bypass a hundred product cards, gather search results, check prices in different regions. Each request goes out from a new address, making it difficult to link them together.
Sticky session (ports 10000+, change interval from 1 to 120 minutes) — for anything that consists of steps: login, cart, multi-page form, long dialogue with the interface. If the IP changes in the middle of a sequence, the site will at best ask for reauthorization, and at worst mark the session as suspicious.

The agent almost always operates in the second mode: by definition, it performs a sequence of steps rather than a single shot. Details on choosing the interval and common mistakes are discussed in the guide on when sticky sessions are needed and how to configure them.

Five Pitfalls

SOCKS5 with authentication in Chromium. The syntax socks5:// exists in Playwright, but the combination of "SOCKS5 plus username and password" in Chromium-based browsers has historically been problematic — the corresponding request in the Playwright tracker has been open since November 2021. If you have a choice, for agents, use the HTTP(S) channel; it is more predictable.
DNS and WebRTC leaks. Traffic goes through the proxy, but names are resolved directly, or WebRTC reveals the real address — and all masking loses its meaning. This should be checked before, not after, launching the agent: how to hide WebRTC when working through a proxy.
Desynchronization of geo and locale. IP in Germany, machine's timezone in Moscow, interface language in English — a combination that appears to be automation by itself. In Playwright, locale and timezone are set through context parameters; align them with the proxy's country.
Traffic you didn't order. The agent opens the page entirely, including images, fonts, and advertising scripts. On a residential channel with payment per gigabyte, this is a noticeable expense — block unnecessary domains and, where possible, disable media loading.
The proxy is not set where the browser starts. When working through --cdp-endpoint, through a Docker wrapper, or through a cloud service, MCP flags do not affect the actual connection. The first thing to do after setup is to make the agent open any IP check service and ensure that the address and country are correct.

What Type of Proxy to Use for the Agent

The rule is simple: the closer the task is to a live user, the more "human-like" the address should be.

Residential proxies — the foundation for agents. These are addresses from home providers, and to the website, the agent appears as a regular visitor. They are needed wherever there is Cloudflare, regional pricing, and any hint of anti-bot measures.
Mobile proxies — heavy artillery for social networks and platforms where accounts are treated particularly nervously. One mobile address is shared by thousands of real subscribers, so banning it entirely is costly for the platform.
Data center proxies — for internal APIs, test environments, and open sources without protection. Fast and cheap, but on secured sites, the agent will run into a challenge almost immediately.

A useful detail for agent scenarios: changing the protocol at ProxyCove is done by replacing the prefix in the connection string — HTTP, HTTPS, and SOCKS5 are available on the same proxy, and the proxy itself does not need to be reconfigured. There are over 195 countries in the pool, so "show the agent local results" can be resolved by choosing the country when purchasing.

Conclusion

Connecting a proxy to an AI agent is not a single line but three consecutive solutions: how to authenticate (for headless agents, it is almost always an IP whitelist, not a password), where to set the proxy (MCP flags, settings object, or cloud session parameters — but definitely where the browser actually starts), and in what mode to operate (for multi-step scenarios — a sticky address, not rotation for every request). Plus, mandatory checks for DNS and WebRTC leaks before going live.

Do this carefully once — and the agent will stop wasting tokens on conversations with captchas. Residential proxies from ProxyCove can be connected to Playwright MCP and browser-use in just a few minutes, with payment based on traffic, and IP-whitelist for headless mode can be enabled in the dashboard.