AI agents and automated browsers: giving them a French connection

An AI agent filling in a form, a Playwright script testing your checkout flow, a bot fetching your orders from a supplier's portal: most of the time, they all run on a cloud server. And cloud server addresses are the first ones sites filter.

The problem

A hosting address tells the site: "this is not a regular user". Many sites respond with a captcha, a verification page, or a flat refusal. Some protection services even offer sites the option to block AI bots by default.

A French mobile line gives the agent a carrier subscriber's address. The crudest filter, the one that judges on the address alone, no longer refuses it.

What this page does not tell you to do

A site that refuses bots through its terms, its robots.txt or its anti-bot protection has given its answer. A mobile address does not change it.

This page is for uses where the agent acts on your behalf, where you have the right to act: your accounts, your tools, your own sites, your partners' portals, or quality tests on your service. For collecting public data, the framework is in Price monitoring and data collection.

Plugging in the proxy

The addresses and credentials are on the proxy's page, in My proxies.

Playwright (Python)

browser = playwright.chromium.launch(proxy={
    "server": "http://HOST:PORT",
    "username": "USERNAME",
    "password": "PASSWORD",
})
context = browser.new_context(locale="fr-FR", timezone_id="Europe/Paris")

locale and timezone_id make pages, dates and prices display as they would for a French visitor.

Puppeteer (Node.js)

const browser = await puppeteer.launch({ args: ["--proxy-server=http://HOST:PORT"] });
const page = await browser.newPage();
await page.authenticate({ username: "USERNAME", password: "PASSWORD" });

Simple HTTP requests (Python, requests)

proxies = {"https": "socks5h://USERNAME:PASSWORD@HOST:PORT"}
requests.get("https://exemple.fr", proxies=proxies, timeout=30)

The h in socks5h makes the proxy resolve hostnames: without it, your DNS requests go out through the server. You need the requests[socks] package.

The traps

The address is only one signal among others. A browser without an interface (headless) can be recognized by other clues than its IP. If your agent gets refused with a good address, the problem is elsewhere.

WebRTC. An automated browser can reveal the server's address through WebRTC, outside the proxy. See WebRTC and DNS leaks, or send the whole server through the WireGuard tunnel.

One agent, one proxy. Several agents acting on different accounts through the same address end up linked. Give a line to each context that must stay separate; see Compartmentalizing what you do.

Changing IP at the right moment. Never in the middle of a logged-in session: the site would see the same account jump from one address to another. Rotation is driven through the API, between two tasks; see Changing your IP.

Which plan

A browser loads whole pages, images and scripts included: data goes fast. A plan with unlimited data saves you from watching a quota. Take rotation if your tasks benefit from starting again from a fresh address, a fixed address otherwise.

FAQ

HTTP or SOCKS5 for an automated browser?

Both work. Chromium does not accept credentials in a SOCKS5 proxy address, hence the use of HTTP in the examples above. See HTTP or SOCKS5?.

My agent runs at home, not on a server. Do I need this?

Probably not: it already goes out through your home router, a subscriber address. The proxy is only useful to separate its activities from yours, or to give it a French origin if you are abroad.

---

See also: Common errors · Testing your proxy