Configuration de proxy pour utilisation de navigateur : IP de sortie par session

Recherchez un proxy pour utilisation de navigateur et Google vous propose la boîte de dialogue des paramètres de Chrome. Voici l'autre chose : acheminer la bibliothèque d'agents AI pour utilisation de navigateur via des IP résidentielles authentifiées, une par agent.

Recherchez proxy pour utilisation de navigateur et Google vous propose la boîte de dialogue des paramètres de Chrome, l'API d'extension chrome.proxy et un tutoriel sur les fichiers PAC d'entreprise. Rien de tout cela n'est ce que vous cherchiez. Vous voulez acheminer browser-use - la bibliothèque Python avec 108k étoiles sur GitHub qui permet à un LLM de piloter un vrai navigateur - via un proxy authentifié, pour que votre agent ne martèle pas une cible depuis l'IP de votre bureau. Voici ce guide : où le paramètre se trouve réellement, pourquoi il cesse de fonctionner silencieusement après une mise à jour, comment donner à chaque agent parallèle sa propre IP de sortie, et ce qui se passe pour une tâche longue lorsque l'IP change sous elle.

Où se trouve réellement le paramètre de proxy pour utilisation de navigateur

Le proxy est une propriété de la session du navigateur, pas de l'agent. Dans la bibliothèque actuelle, Browser est un alias pour BrowserSession - la documentation est explicite sur le fait qu'il s'agit exactement de la même classe - donc tout tutoriel que vous trouvez utilisant un nom s'applique à l'autre. Le paramètre est proxy, et la documentation le type comme ProxySettings avec quatre champs : server, bypass, username et password. Un dictionnaire équivalent fonctionne, ce que la plupart des gens passent :

import asyncio
from browser_use import Agent, Browser
# llm = ...  your model of choice; see the browser-use docs for the import

PROXY = {
    "server": "http://gate.quantumproxies.io:8000",  # scheme is mandatory
    "username": "USER",
    "password": "PASS",
    "bypass": "localhost,127.0.0.1",                  # keep local calls off the proxy
}

browser = Browser(proxy=PROXY, headless=False)

async def main():
    agent = Agent(
        task="Open https://api.ipify.org?format=json and report the IP you see",
        llm=llm,
        browser_session=browser,
    )
    await agent.run()

asyncio.run(main())

Deux détails que les gens se trompent. Premièrement, les identifiants appartiennent aux champs username et password, pas entassés dans server - Chromium ne répondra pas à un défi d'authentification proxy à partir d'un mot de passe intégré dans l'URL, et browser-use n'a pas de boîte de dialogue pour le saisir. Deuxièmement, server a besoin d'un schéma. gate.quantumproxies.io:8000 n'est pas une URL de proxy ; http://gate.quantumproxies.io:8000 l'est. Si les identifiants vous posent problème, mettre sur liste blanche l'IP de votre serveur supprime complètement l'utilisateur:mot de passe de l'équation - la passerelle reconnaît l'appelant et le navigateur ne voit jamais de 407.

Pourquoi votre configuration de proxy pour utilisation de navigateur ne fait rien

La page la plus visitée sur ce sujet après la documentation est le problème GitHub #2445, déposé en juillet 2025 : un proxy qui fonctionnait en 0.1.45 a cessé de prendre effet en 0.5.4, et le seul indice était l'agent rapportant joyeusement DNS_PROBE_FINISHED_NXDOMAIN dans son propre résumé. Ce mode d'échec - l'agent racontant une erreur réseau comme s'il s'agissait d'un fait sur le site web - est la signature d'un proxy à moitié configuré. Travaillez à travers cette liste avant de brûler plus de jetons :

Vous avez passé proxy= à une session que l'agent n'a jamais reçue. Créez un Browser, passez cet objet exact, et ne laissez pas une session par défaut se créer dans votre dos.
Vous avez défini cdp_url. Se connecter à un Chrome déjà en cours d'exécution signifie que le proxy appartient aux indicateurs de lancement de ce navigateur (--proxy-server=...), pas à votre configuration de session - browser-use ne peut pas le rétrofiter.
Une variable d'environnement globale HTTP_PROXY ou HTTPS_PROXY combat le paramètre de session, ou pire, achemine silencieusement vos appels d'API LLM via une bande passante mesurée.
Le proxy lui-même est mort. Testez-le en dehors de l'agent d'abord - cela ne coûte rien et élimine la moitié de l'espace de recherche.

import requests

PROXY_URL = "http://USER:PASS@gate.quantumproxies.io:8000"
r = requests.get(
    "https://api.ipify.org?format=json",
    proxies={"http": PROXY_URL, "https": PROXY_URL},
    timeout=20,
)
print(r.status_code, r.text)   # must NOT be your own IP

Si cela imprime une IP étrangère, les identifiants et la passerelle sont corrects et le problème est dans le câblage de la session. Si cela imprime votre propre adresse, ou un 407, corrigez cela d'abord. Notre vérificateur d'IP gratuit vous indique à quoi ressemble la sortie de l'autre côté - ASN, type et réputation - ce qui est la deuxième chose à vérifier lorsque les pages se chargent mais que chacune d'elles est un CAPTCHA.

Liste de contrôle associant les symptômes de proxy pour utilisation de navigateur (erreurs DNS, fuite d'IP réelle, configuration qui fonctionnait sur une version antérieure) avec les correctifs à vérifier — La configuration semble généralement correcte. L'échec est presque toujours la session que l'agent a réellement reçue, le schéma manquant, ou une variable d'environnement globale.

Un proxy par session, pour que les agents parallèles ne partagent pas une IP de sortie

C'est toute la raison pour laquelle le paramètre se trouve sur la session plutôt que sur une configuration globale. Exécutez dix agents via un Browser partagé et la cible voit dix fois le trafic depuis une adresse, ce qui est le moyen le plus rapide de brûler une IP résidentielle. Construisez la session à l'intérieur de la coroutine à la place, et donnez à chacune son propre identifiant de session persistant pour que la passerelle la fixe à une seule sortie pour la durée de la tâche :

import asyncio, secrets
from browser_use import Agent, Browser

def session_proxy(sid: str, country: str = "us"):
    return {
        "server": "http://gate.quantumproxies.io:8000",
        "username": f"USER-country-{country}-session-{sid}",
        "password": "PASS",
    }

async def run_task(task: str, country: str):
    sid = secrets.token_hex(3)                  # e.g. a1b2c3
    browser = Browser(
        proxy=session_proxy(sid, country),
        user_data_dir=None,                     # incognito: no shared cookies
        allowed_domains=["*.example.com"],      # keep the agent on target
    )
    agent = Agent(task=task, llm=llm, browser_session=browser)
    return await agent.run()

async def main():
    await asyncio.gather(
        run_task("Find the price of SKU-1", "us"),
        run_task("Find the price of SKU-1", "de"),
        run_task("Find the price of SKU-1", "gb"),
    )

asyncio.run(main())

Trois indicateurs font vraiment le travail ici. user_data_dir=None fonctionne en mode incognito, donc les agents ne peuvent pas hériter des cookies des uns des autres et fusionner discrètement deux identités sur un profil. allowed_domains restreint la navigation à une liste de modèles - notez que les jokers dans la position TLD, comme example.*, sont rejetés intentionnellement, et les listes dépassant cent entrées sont optimisées en ensembles avec la correspondance de modèles désactivée. Et l'identifiant de session dans le nom d'utilisateur est ce qui rend l'IP de sortie stable ; les noms exacts des indicateurs pour le pays et la session se trouvent dans votre tableau de bord, mais la forme est la même partout.

Choisir le pays de sortie par tâche

Les agents qui achètent, comparent les prix ou vérifient la disponibilité se trompent par défaut s'ils naviguent depuis le mauvais pays. Parce que le proxy est par session, le pays est un argument par tâche - échangez country-us pour country-de et la même tâche renvoie les prix allemands. Choisissez parmi les 200+ pays du pool, et gardez le reste du navigateur cohérent avec cela : passez une langue correspondante via args (Chromium accepte --lang=de-DE) plutôt que de laisser une IP de sortie allemande demander des pages en anglais américain. Pour les surfaces uniquement mobiles et les sorties de la plus haute confiance, les IPs mobiles se comportent différemment à nouveau, car le NAT des opérateurs met des milliers de vrais utilisateurs derrière la même adresse.

Donnez à chaque agent sa propre IP de sortie résidentielle

Flux montrant une file d'attente de tâches se déployant vers une session browser-use par agent, chacune avec sa propre session de proxy persistante, pour que le site cible voie des IP résidentielles distinctes — Construisez la session à l'intérieur de la tâche, pas à l'extérieur. Un Browser par agent, une session persistante par Browser, une IP par identité.

Que se passe-t-il lorsque l'IP tourne en milieu de tâche

Les agents sont lents d'une manière que les scrapers ne le sont pas. Entre la pause par défaut de 0,5 s après chaque action, un temps d'attente minimum de 0,25 s pour l'état de la page et un temps d'attente de 0,5 s pour l'inactivité réseau, browser-use passe plus d'une seconde par étape avant que le modèle ait dit quoi que ce soit - et le temps de trajet aller-retour du modèle est généralement de plusieurs secondes de plus. Une tâche de quinze étapes s'exécute donc pendant une à deux minutes de temps réel. Si votre IP de sortie tourne à chaque requête, le site verra une adresse différente à chacune de ces étapes : la connexion tombe, le panier se vide, et l'agent rapporte que le bouton de paiement a disparu.

La solution est une session persistante dont la fenêtre dépasse confortablement la durée de votre tâche dans le pire des cas, pas votre moyenne. Chronométrez quelques exécutions réelles, prenez la plus lente, et ajoutez une marge - les agents réessaient, et un réessai double le temps. Lorsqu'une tâche doit vraiment dépasser toute fenêtre persistante, divisez-la : connectez-vous et exportez l'état, puis reprenez dans une nouvelle session avec les cookies que vous avez enregistrés via storage_state. Et si vous choisissez entre rotation par requête et persistance, notre liste de contrôle de l'infrastructure pour agents AI couvre le reste de la couche autour de cette décision.

Gardez le proxy hors de vos appels LLM

Celui-ci coûte vraiment de l'argent et presque personne ne le remarque. Définir HTTPS_PROXY comme une variable d'environnement pour que le proxy "s'applique partout" achemine également chaque appel d'API de modèle via votre passerelle résidentielle - invites et réponses, à chaque étape, facturées par gigaoctet pour le privilège de faire le détour. Configurez le proxy uniquement sur le Browser et laissez l'environnement de processus tranquille. Pendant que vous comptez les octets, notez que browser-use charge uBlock Origin par défaut via enable_default_extensions : laissez-le activé, car chaque requête publicitaire qu'il tue est une que vous ne payez pas. L'arithmétique complète est dans notre analyse de ce que coûte un agent AI en bande passante, et la version classique du compromis en scraping est dans navigateur sans tête vs requêtes HTTP.

Questions fréquemment posées

Comment puis-je configurer un proxy dans browser-use ?

Passez proxy= lorsque vous construisez le Browser (également exporté comme BrowserSession), puis remettez cet objet à l'Agent. La valeur contient server avec un schéma http:// explicite, plus username, password et une liste bypass optionnelle. Il n'y a pas de paramètre de proxy au niveau de l'agent - il appartient à la session.

Pourquoi ma configuration de proxy pour utilisation de navigateur ne fonctionne-t-elle pas ?

Par ordre de probabilité : l'agent fonctionne sur une session différente de celle que vous avez configurée, server manque de son schéma, vous avez défini cdp_url donc le navigateur a été lancé ailleurs sans indicateurs de proxy, ou une variable d'environnement de proxy globale vous remplace. Vérifiez le proxy avec un client HTTP simple d'abord - une erreur DNS dans le journal de l'agent signifie généralement qu'aucun proxy n'est attaché du tout.

Chaque agent browser-use peut-il utiliser une IP différente ?

Oui, et vous devriez. Créez le Browser à l'intérieur de chaque coroutine de tâche avec ses propres identifiants de proxy plutôt que de partager une instance. Ajouter un identifiant de session unique au nom d'utilisateur de la passerelle fixe chaque agent à une sortie distincte pour la durée de son exécution, donc dix agents parallèles ressemblent à dix utilisateurs au lieu d'un très occupé.

Quel type de proxy convient le mieux aux agents browser-use ?

Résidentiel rotatif pour la recherche et les vérifications de prix où chaque tâche est indépendante, résidentiel persistant pour tout ce qui a une connexion ou un panier, et mobile lorsque la cible est hostile ou uniquement mobile. Les IP de centre de données sont bien pour les cibles internes et les pages non protégées, et elles sont bien moins chères par gigaoctet - ce qui compte, car un agent de navigateur déplace beaucoup de gigaoctets.

Un proxy empêche-t-il browser-use d'être détecté ?

Non. Un proxy corrige uniquement la couche IP ; l'empreinte d'un Chromium automatisé est un problème distinct, tout comme le comportement d'un agent qui clique avec une précision millimétrique. Les sorties résidentielles de confiance éliminent le signal le plus facile, mais associez-les à une version de navigateur orientée furtivité si la cible utilise une gestion sérieuse des bots.

Rien ici n'est exotique : le proxy est une propriété de session, et les deux choses qui le cassent sont un schéma manquant et une session que vous n'avez jamais remise. Faites cela correctement, donnez à chaque agent parallèle sa propre sortie persistante, et gardez la passerelle à l'écart de vos appels d'API de modèle. Pour une vue d'ensemble, consultez notre carte des frameworks anti-détection et des proxies authentifiés.

Exécutez browser-use sur plus de 90 millions d'IP résidentielles dans plus de 200 pays