Proxies for AI Agents: When You Need Them and How to Connect

When a browser agent or an AI tool that reads pages needs a proxy, how to connect it and how not to waste traffic.

Prokso editorial team 8 min read Guides
Proxies for AI Agents: When You Need Them and How to Connect
Key takeaways
  • An agent needs a proxy for content from the right country, spreading the load and stable sessions
  • For one-off requests to open pages from your own country, you usually do not need a proxy
  • Multi-step tasks with a login run on a sticky port, independent requests run on rotation
  • Traffic is counted in both directions; turning off images in the agent's browser saves a lot of it
  • An agent must follow a website's rules just like a person or an ordinary scraper

AI agents go online by themselves more and more often. One opens a browser and moves through a website like a person. Another gets a page address from the model and downloads it with an HTTP request. A third crawls hundreds of documents so it can answer questions based on them later.

To a website, they all look like an ordinary visitor or like a robot, depending on how they are set up. Below: when an agent needs a proxy, when it does not, how to connect it and how to keep track of traffic usage.

What kinds of agents read pages

Browser agents control a real browser through Playwright or Puppeteer. They click, fill in fields and go through several steps in a row. Such an agent loads the whole page, along with scripts and images.

Page reading tools are a function the model calls when it needs the text at a link. Usually this is an HTTP client: requests, httpx or similar. It downloads only the HTML, without images, so it uses little traffic.

RAG collectors crawl websites and put documents into a database the model then answers from. Essentially this is a scraper, except the result goes into search for the model. If your task is specifically collecting data for training and testing models, there is a separate use case for it: data collection for AI.

When an agent really needs a proxy

A proxy is not a required part of an agent. It is needed in a few clear situations:

  • The content depends on the country. The agent checks prices, availability or search results the way a shopper in Poland or Germany sees them, not where the server is.
  • The load needs to be spread out. The agent reads many pages, and all requests from one server address hit websites' limits.
  • A stable session is needed. The agent logs into an account and goes through several steps, and the website must see the same visitor.
  • The agent's server is in a datacenter, and some websites do not serve pages to datacenter addresses.
  • Tasks need to be separated. Different clients or projects work through different plans, and the usage of each is visible separately.

When you can do without one

If the agent occasionally opens open pages from your own country and websites respond normally, a proxy adds nothing. The same goes for a website with an official API: it is simpler and more reliable for the agent to get data through it.

A proxy is also not needed for requests to the language model itself. It connects to the part of the agent that goes to websites, while requests to the model's API go directly.

If you are not sure, run the agent without a proxy on a dozen typical tasks. See where websites respond with errors, a captcha or content from the wrong country. Those are the tasks to connect a proxy for, and the rest can stay as they are.

How to connect a proxy to an agent

The proxy connects not to the model but to the agent's network part: to the HTTP client or to the browser it controls. The connection line is the same everywhere: protocol, username, password, the gw.prokso.com host and a port. You can get it from the dashboard generator in the format you need.

How the agent goes onlineWhere to set the proxyGuide
Headless browser on PlaywrightThe proxy parameter when launching the browser or contextPlaywright
Headless browser on PuppeteerA browser launch argument and authorization on the pagePuppeteer
HTTP tool on requestsThe proxies dictionary in the sessionPython requests
Async tool on httpxThe client's proxy parameterhttpx

It is convenient to create one client or browser context per task and pass it to all of the agent's tools. Then all steps of the task are guaranteed to go through the same proxy, not through a random set of connections.

After connecting, check the address: have the agent open the my IP page and return the country and address it saw. If the country is wrong, the error is in the connection line or in the chosen country.

Rotation or a sticky address for agent tasks

The logic here is the same as for people and scrapers, except the agent goes through steps faster. If the address changes in the middle of logging into an account, the website will see one user visiting different places within a minute and will ask for verification.

  • A multi-step task on one website: a sticky port from 10000 to 20000. It holds a single address for 1 to 120 minutes, 30 by default. Set the time with a margin for the whole task.
  • Many independent pages on different websites: rotation, port 823 for HTTP or 824 for SOCKS5, a new address for every request.
  • Several agents in parallel: each one gets its own sticky port so their sessions do not overlap.
  • Long tasks with residential or mobile addresses: keep in mind that the address may change earlier if the device goes offline. The port will get a new address in the same country, and it helps if the agent can continue the step instead of failing with an error.

More about the modes in the glossary: sticky session and rotating proxy.

Budget: where an agent spends traffic

Traffic in Prokso is counted in both directions: both what the agent sent and what it received. For an HTTP tool that takes only HTML, this is not much. A browser agent loads the whole page, and most of the traffic goes to images, video, fonts and ad scripts.

  • Turn off loading of images, video and fonts if the agent only needs text. In Playwright and Puppeteer this is done by intercepting requests.
  • Do not send third-party counters and ads through the proxy if the task does not need them.
  • Cache pages the agent has already read, and do not let it open the same link several times per task.
  • Limit the depth: how many links the agent can open in one task.
  • Keep different plans for different projects and turn on a daily or weekly traffic limit so that an agent stuck in a loop does not use up the whole balance.

The traffic calculator will help you estimate usage in advance: enter the average page size and the number of pages per day. Prices per gigabyte for each type are on the pricing page.

How an agent should react to errors

A model tends to repeat an action until it gets a result. For the network this is a bad habit: ten retries in a row in response to an error waste traffic and annoy the website. It is more reliable to write the error handling rules into the tool's code rather than leave them to the model.

  • Error 407: a problem with the proxy username and password, or the plan has run out of traffic. Retrying is pointless; check the connection line and the balance.
  • Errors 429 and 403: a signal to stop on this website and come back later at a slower pace.
  • Timeout: one or two retries with a growing pause, then skip the page.
  • An empty page: check whether it needs to be loaded through a browser rather than an HTTP client.

An agent can get proxies through the API

If the agent works on its own, it is convenient for it to get proxies without a person. Prokso has an API for clients: through it you can check the balance and prices, get the list of plans and proxy lines in the format you need, and pause or resume a plan.

Buying a new plan and adding gigabytes through the API are paid only from the balance; top-ups are done in the dashboard. The limit is 60 requests per minute per key, and the key is created in the dashboard settings. For an agent, this means a simple setup: a person tops up the balance, and the agent takes the lines it needs and keeps an eye on the balance by itself.

Website rules apply to agents too

An agent is a visitor just like a person or a scraper, and the website's rules for it are the same. Follow robots.txt and the terms of use, keep a reasonable pace and do not let the agent open dozens of pages per second. If a website returns 429 or 403, the agent must stop, not repeat the request.

Proxies do not cancel these rules and do not make an agent invisible. Some websites are closed to all of the service's addresses: the list is on the blocked websites page. More about working calmly with limits in the article how to avoid IP bans.

FAQ

What is an AI agent in the context of proxies?

It is a program based on a language model that opens pages by itself: through a built-in browser, through HTTP requests or as part of a system that collects documents for answers. The proxy connects to its network part, not to the model itself.

Do I need a proxy for a language model's API?

Usually not. A proxy is needed for the agent's requests to the websites it reads. Requests to the model's API can go directly.

Which mode should I choose for an agent: rotation or a sticky address?

If the task has several steps on one website, especially with a login, use a sticky port 10000-20000. If the agent makes many independent requests to different pages, rotation through port 823 or 824 will do.

Can an agent get proxies by itself?

Yes, through the Prokso API: it can return the balance, prices, the list of plans and proxy lines. Buying a new plan or adding gigabytes through the API is paid only from the balance; top-ups are done in the dashboard.

How can I reduce an agent's traffic usage?

Turn off images, video and fonts in the agent's browser if the task does not need them. Cache pages the agent has already read, and do not let it open the same page several times.

Read next