Proxy AI: What It Means and How to Set One Up

"Proxy AI" is used for two unrelated things. One is an AI proxy: a gateway that sits between your code and model providers (OpenAI, Anthropic, Mistral, OpenRouter) to handle keys, routing, caching and spend limits. The other is a network proxy for AI: an IP your agent's outbound HTTP traffic exits from, so the sites and APIs it touches see a real consumer connection instead of a cloud server. This page separates them and shows how to configure the second one, which is the part that breaks in production.

The two meanings, side by side

They are not alternatives. A production agent often runs both: an LLM gateway on the model side, and a mobile or residential exit on the browsing side.

Why AI agents get blocked without a network proxy

An agent running on a VPS or in a serverless function exits from a datacenter ASN. Anti-bot systems treat that ASN as a strong negative signal before they look at anything else, which is why the same script that works on your laptop returns 403 or an endless challenge page in the cloud. Two more signals stack on top: request volume from one IP, and headless browser fingerprints.

The IP layer is the cheapest one to fix. A mobile exit puts the agent behind carrier NAT, where thousands of real subscribers share the address, so per-IP reputation scoring is far less aggressive. Datacenter vs residential vs mobile proxies covers how the three IP types are actually classified. For the full agent architecture (MCP tools, credential handling, SMS for verification steps), the long version is AI agents on mobile infrastructure.

How to route an AI agent through a proxy

1. Pick the session model first

Decide this before you write config, because it changes the credential you use:

• Per-request rotation: every outbound request exits from a different device. Right for independent fetches: search results, product pages, public profiles.
• Sticky session: one device for a fixed window. Required for anything with a login, a cart, a cookie or a multi-step tool chain, because a mid-flow IP change reads as session hijacking.

Agents mostly need sticky, because a task is a sequence of dependent calls. See sticky sessions on mobile proxies for how long to hold one.

2. Build the connection string

On a shared pay-per-GB pool, geo and session are chained onto the proxy username as underscore parameters:

username_c_US_s_agent7_ttl_30m:password@gateway:port

_c_US targets a country, _s_agent7 pins every request carrying that session ID to the same device, _ttl_30m sets the window. Drop _s_ and you get per-request rotation. City, subdivision, ISP and ASN parameters exist too, which matters when you are checking localized results rather than just leaving the datacenter. If you prefer static config over per-request control, create a named proxy list with its own credentials and rotation setting and point the agent at that.

On a dedicated device, one real 4G/5G phone is yours; rotation happens only when you call for it, so every session is sticky by default.

3. Wire it into the client the agent actually uses

The common failure here is assuming HTTP_PROXY is enough. It is not, for several stacks:

• Node.js global fetch ignores proxy environment variables. Pass an undici ProxyAgent as the dispatcher.
• Playwright and Puppeteer need the proxy in the launch options, not the environment, and credentials passed separately.
• Python requests and httpx do read environment variables, but per-session proxies config is safer when one process runs several agent identities.
• LangChain, LlamaIndex and MCP tool servers inherit whatever HTTP client they were built on, so verify the tool, not the framework.

If your agent drives a browser, Playwright proxy setup has the working launch configuration.

4. Verify the exit before you run volume

Make the agent's first tool call an IP check and log the result. If it returns your server's address, the proxy is not applied and every later request is burning reputation.

Then check for leaks around the proxy: a headless browser can expose the host IP over WebRTC, and DNS resolution can still go to your cloud provider's resolver. The WebRTC leak test and proxy validator cover both.

One rule that saves most debugging: one identity, one session ID

Give every agent identity its own session ID, and never reuse a session ID across identities. Concretely: _s_acct_a for one account, _s_acct_b for another, generated from the identity record, not from a random value per run. Two consequences follow.

First, two logins inside one sticky window from one IP look like one operator running two accounts, which is the exact pattern platform-side clustering looks for. Second, when a run fails you can trace it: the session ID in the log tells you which exit was used and whether the flow held one device end to end.

The corollary is retry behavior. If your agent retries a failed request on a new IP inside the same logical session, you have just changed devices mid-flow. Retry on the same session ID; only rotate when you are starting a new task.

What it costs

Two pricing models, and the workload decides:

• Pay-per-GB shared pool: from $3.99 for 1 GB, down to $250 for 100 GB ($2.50/GB) at the top tier. Text-heavy scraping and API calls consume little data, so most agents that do not render pages live here.
• Dedicated device: from $49/month, one phone you control rotation on. Worth it when you need a stable identity, a specific carrier, or predictable cost regardless of throughput.

An agent that renders full pages in a headless browser can pull tens of megabytes per hundred pages because of images and scripts; block media requests in the browser context and the same crawl costs a fraction. If the agent also has to pass a phone verification step, getting a phone number for your AI agent covers the SMS side, and note that one-time OTP and multi-day rental numbers are US numbers, while a dedicated monthly line is available per country.