How to give an AI browser agent a proxy

An AI browser agent is a language model that controls a real browser: it reads the page (as a screenshot, an accessibility snapshot or both), decides what to click or type, and repeats until the task is done. Open-source frameworks such as browser-use, Playwright MCP and Stagehand let you run that browser on your own computer or server and plug in any model you like.

People add a proxy for the same reasons they would with a scraper: to spread an agent’s traffic over more IPs than their own, to see a site from a USA or EU address, and to keep a busy agent from getting their office or home IP rate-limited. The catch is that an agent is a heavy user. It loads full pages, often several times per task, over many parallel connections.

Most proxy problems with agents come from three places: the proxy is “requested” in the task prompt instead of configured on the browser, the agent runs on a vendor’s cloud where your IP authorization can’t follow it, or too many tabs share a small thread plan. This guide shows the exact setting in each framework, where an agent can and can’t use Storm proxies, and how to size the plan.

Be clear about where the browser actually lives. ChatGPT’s agent mode, Browser Use Cloud, Browserbase sessions and similar services run the browser on the vendor’s servers. Their outgoing IPs belong to the vendor, they’re shared with other customers, and they can change from one session to the next. You can’t put those IPs in your Authorized IPs list and expect them to stay valid, and Storm rotating and residential proxies have no username and password to hand over instead.

That leaves three honest options:

• Run the agent yourself. browser-use, Playwright MCP and Stagehand in LOCAL mode all launch the browser on your machine. Your MCP client or chat app can still be anywhere; what matters is the machine that starts Chromium.
• Use a VPS with a fixed IP. Put the agent on a small Linux server, authorize its IP once, and run it headless. This is also the fix when your home IP changes (or authorize a free No-IP hostname).
• Use private dedicated proxies with user:pass when a hosted tool has a custom-proxy field that takes host, port, username and password. Each one is a static USA IP only you use, with up to 100 threads.

If a hosted product has no custom-proxy field, no proxy provider can change its IP.

A browser doesn’t fetch a page over one connection. It opens several in parallel for HTML, scripts, styles, fonts, images and tracking calls, so one tab uses around 10 threads on our gateways. An agent that opens a second tab to compare prices doubles that for as long as both are open.

• 10 threads: one agent, one tab, for testing the setup only.
• 40 threads: about 3 agents at once with some headroom, or 4 if each keeps strictly to one tab.
• 80 threads: about 7 parallel agents.
• 150 threads: about 14 parallel agents; 200 threads, about 19.

Leave one tab’s worth spare. Going over the limit shows up as random connection failures mid-task, which the model then tries to “solve” by clicking around.

Search engines are the exception. Keep Google and other search engines to the Main gateway and at most a quarter of your threads: on a 40-thread plan that’s 10 threads, which is a single agent tab. Better: give the agent its start URLs directly.

• Reading public pages (research, price checks, summarising articles): the Main rotating gateway. Each new connection may leave from a different IP, which is fine when nothing depends on a session.
• Logged-in or multi-step work (forms, checkouts, dashboards): the 15-minute gateway, or a dedicated proxy if the task can take longer than that. A site that sees one session jump between IPs mid-checkout often signs it out.
• Sign-ups and social sites: the 3-minute gateway is meant for account registration, social sites and browsing (USA only). It isn’t for search-engine scraping.
• Residential ports: one residential IP for 5 minutes, changing at fixed times (minute 1, 6, 11 and so on). Open connections can drop at that moment, so short tasks fit better than a 20-minute workflow.
• One fixed identity per agent: give each agent its own dedicated proxy. Rotating pools are the wrong tool when an account should always see the same IP.

A scraper fetches the HTML and moves on. An agent needs the page fully rendered so it can take a screenshot or an accessibility snapshot after almost every action. That means every script, image, font and ad loads through the proxy, and the agent often revisits the same page several times while it plans, checks its work or recovers from a misclick.

On a plan billed per gigabyte, that traffic is hard to predict: one agent stuck in a loop on an image-heavy site can burn through a month’s allowance overnight. Storm plans are priced per thread, port or proxy with unlimited bandwidth, so the cost stays the same whether the agent loads 50 pages or 50,000.

The screenshots themselves go from your machine to the model’s API, not through the proxy, as long as you set the proxy on the browser only.

Set the proxy in the browser config, not as a global HTTP_PROXY/HTTPS_PROXY environment variable. Many Python and Node SDKs honour those variables, so a global setting would also send your OpenAI, Anthropic or Gemini API calls through the gateway. That adds latency and uses threads you need for pages, for traffic that gains nothing from a proxy. The PLAYWRIGHT_MCP_PROXY_SERVER variable is safe because only the Playwright MCP server reads it.

If you connect Playwright MCP to a browser that’s already open (its extension mode or --cdp-endpoint), the proxy flags don’t change that browser. Set the proxy where that browser was launched, for example with the steps in our Chrome proxy guide. For scripted, non-agent automation the same gateways work in plain Playwright and Puppeteer.