Configurazione Proxy per Uso Browser: IP di Uscita per Sessione

Cerca un proxy per uso browser e Google ti mostra la finestra di dialogo delle impostazioni di Chrome. Questa è l'altra cosa: instradare la libreria AI per uso browser attraverso IP residenziali autenticati, uno per agente.

Cerca proxy per uso browser e Google ti mostra la finestra di dialogo delle impostazioni di Chrome, l'API dell'estensione chrome.proxy e un tutorial su file PAC aziendali. Niente di tutto ciò è quello che cercavi. Vuoi instradare browser-use - la libreria Python con 108k stelle su GitHub che permette a un LLM di guidare un vero browser - attraverso un proxy autenticato, così il tuo agente non martella un target dal tuo IP aziendale. Questa è quella guida: dove vive effettivamente il parametro, perché smette silenziosamente di funzionare dopo un aggiornamento, come dare a ogni agente parallelo il proprio IP di uscita, e cosa succede a un compito lungo quando l'IP si sposta sotto di esso.

Dove vive effettivamente il parametro proxy per uso browser

Il proxy è una proprietà della sessione del browser, non dell'agente. Nella libreria attuale, Browser è un alias per BrowserSession - i documenti sono espliciti che sono esattamente la stessa classe - quindi qualsiasi tutorial che trovi usando un nome si applica all'altro. Il parametro è proxy, e i documenti lo tipizzano come ProxySettings con quattro campi: server, bypass, username e password. Funziona un dict equivalente, che è ciò che la maggior parte delle persone passa:

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())

Due dettagli che le persone sbagliano. Primo, le credenziali appartengono ai campi username e password, non infilate nel server - Chromium non risponderà a una sfida di autenticazione proxy da una password incorporata nell'URL, e browser-use non ha una finestra di dialogo per digitarla. Secondo, server necessita di uno schema. gate.quantumproxies.io:8000 non è un URL proxy; http://gate.quantumproxies.io:8000 lo è. Se le credenziali ti danno problemi, whitelistare l'IP del tuo server rimuove user:pass dall'equazione completamente - il gateway riconosce il chiamante e il browser non vede mai un 407.

Perché la tua configurazione proxy per uso browser non fa nulla

La pagina più visitata su questo argomento dopo i documenti è il problema GitHub #2445, presentato a luglio 2025: un proxy che funzionava nella versione 0.1.45 ha smesso di avere effetto nella 0.5.4, e l'unico indizio era l'agente che riportava allegramente DNS_PROBE_FINISHED_NXDOMAIN nel suo riepilogo. Questa modalità di fallimento - l'agente che narra un errore di rete come se fosse un fatto sul sito web - è la firma di un proxy che è mezzo configurato. Lavora attraverso questa lista prima di bruciare più token:

Hai passato proxy= a una sessione che l'agente non ha mai ricevuto. Crea un Browser, passa esattamente quell'oggetto, e non lasciare che una sessione predefinita venga creata alle tue spalle.
Hai impostato cdp_url. Connettersi a un Chrome già in esecuzione significa che il proxy appartiene ai flag di avvio di quel browser (--proxy-server=...), non alla tua configurazione di sessione - browser-use non può adattarlo.
Una variabile d'ambiente globale HTTP_PROXY o HTTPS_PROXY sta combattendo con l'impostazione della sessione, o peggio, instradando silenziosamente le tue chiamate API LLM attraverso una larghezza di banda misurata.
Il proxy stesso è morto. Testalo fuori dall'agente prima - non costa nulla e esclude metà dello spazio di ricerca.

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

Se stampa un IP straniero, le credenziali e il gateway sono a posto e il problema è nel cablaggio della sessione. Se stampa il tuo indirizzo o un 407, risolvi prima quello. Il nostro controllo IP gratuito ti dice come appare l'uscita dall'altro lato - ASN, tipo e reputazione - che è la seconda cosa da controllare quando le pagine si caricano ma ognuna di esse è un CAPTCHA.

Lista di controllo che abbina i sintomi del proxy per uso browser (errori DNS, perdita di IP reale, configurazione che funzionava su una versione precedente) con le correzioni da verificare — La configurazione di solito sembra corretta. Il fallimento è quasi sempre la sessione che l'agente ha effettivamente ricevuto, lo schema mancante o una variabile d'ambiente globale.

Un proxy per sessione, così gli agenti paralleli non condividono un IP di uscita

Questo è il motivo per cui il parametro si trova sulla sessione piuttosto che su una configurazione globale. Esegui dieci agenti attraverso un Browser condiviso e il target vede dieci volte il traffico da un indirizzo, che è il modo più veloce per bruciare un IP residenziale. Costruisci la sessione all'interno della coroutine invece, e dai a ciascuno il proprio identificatore di sessione sticky in modo che il gateway lo fissi a un'unica uscita per tutta la durata del compito:

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())

Tre flag stanno facendo un vero lavoro lì. user_data_dir=None esegue in incognito, quindi gli agenti non possono ereditare i cookie l'uno dell'altro e fondere silenziosamente due identità su un profilo. allowed_domains limita la navigazione a una lista di pattern - nota che i caratteri jolly nella posizione del TLD, come example.*, sono rifiutati di proposito, e le liste oltre cento voci sono ottimizzate in set con il pattern matching disattivato. E l'identificatore di sessione nel nome utente è ciò che rende stabile l'IP di uscita; i nomi esatti dei flag per paese e sessione vivono nella tua dashboard, ma la forma è la stessa ovunque.

Scegliere il paese di uscita per compito

Gli agenti che fanno acquisti, confrontano prezzi o controllano disponibilità sono sbagliati per impostazione predefinita se navigano dal paese sbagliato. Poiché il proxy è per sessione, il paese è un argomento per compito - sostituisci country-us con country-de e lo stesso compito restituisce prezzi tedeschi. Scegli tra i 200+ paesi nel pool e mantieni il resto del browser coerente con esso: passa una lingua corrispondente attraverso args (Chromium accetta --lang=de-DE) piuttosto che lasciare che un IP di uscita tedesco richieda pagine in inglese americano. Per superfici solo mobili e le uscite di massima fiducia, gli IP mobili si comportano diversamente ancora, perché il NAT del carrier mette migliaia di utenti reali dietro lo stesso indirizzo.

Dai a ogni agente il proprio IP di uscita residenziale

Flusso che mostra una coda di compiti che si espande in una sessione per uso browser per agente, ciascuna con la propria sessione proxy sticky, così il sito target vede IP residenziali distinti — Costruisci la sessione all'interno del compito, non al di fuori di esso. Un Browser per agente, una sessione sticky per Browser, un IP per identità.

Cosa succede quando l'IP ruota a metà compito

Gli agenti sono lenti in un modo in cui i scraper non lo sono. Tra la pausa predefinita di 0,5s dopo ogni azione, un'attesa minima dello stato della pagina di 0,25s e un'attesa di inattività di rete di 0,5s, browser-use impiega oltre un secondo per passo prima che il modello abbia detto qualcosa - e il round-trip del modello è di solito diversi secondi in più. Un compito di quindici passi quindi dura da uno a due minuti di orologio. Se il tuo IP di uscita ruota per richiesta, il sito vedrà un indirizzo diverso su ognuno di quei passi: il login si interrompe, il carrello si svuota, e l'agente riporta che il pulsante di checkout è scomparso.

La soluzione è una sessione sticky la cui finestra supera comodamente la durata del tuo compito nel peggiore dei casi, non la tua media. Cronometra alcune esecuzioni reali, prendi la più lenta e aggiungi margine - gli agenti riprovano, e un tentativo raddoppia l'orologio. Quando un compito ha veramente bisogno di sopravvivere a qualsiasi finestra sticky, dividilo: accedi ed esporta lo stato, quindi riprendi in una nuova sessione con i cookie che hai salvato tramite storage_state. E se stai scegliendo tra rotazione per richiesta e sticky, la nostra lista di controllo dell'infrastruttura per agenti AI copre il resto del livello attorno a questa decisione.

Tieni il proxy fuori dalle tue chiamate LLM

Questo costa soldi veri e quasi nessuno se ne accorge. Impostare HTTPS_PROXY come variabile d'ambiente per far sì che il proxy "si applichi ovunque" instrada anche ogni chiamata API del modello attraverso il tuo gateway residenziale - prompt e risposte, a ogni passo, fatturati per gigabyte per il privilegio di fare il giro lungo. Configura il proxy solo sul Browser e lascia in pace l'ambiente del processo. Mentre conti i byte, nota che browser-use carica uBlock Origin per impostazione predefinita tramite enable_default_extensions: lascialo attivo, perché ogni richiesta pubblicitaria che uccide è una che non paghi. L'aritmetica completa è nella nostra analisi di quanto costa un agente AI in termini di larghezza di banda, e la versione classica del trade-off è in browser senza testa vs richieste HTTP.

Domande frequenti

Come imposto un proxy in browser-use?

Passa proxy= quando costruisci il Browser (anche esportato come BrowserSession), poi consegna quell'oggetto all'Agent. Il valore porta server con uno schema http:// esplicito, più username, password e una lista bypass opzionale. Non c'è un'impostazione proxy a livello di agente - appartiene alla sessione.

Perché la mia configurazione proxy per uso browser non funziona?

In ordine di probabilità: l'agente sta girando su una sessione diversa da quella che hai configurato, server manca del suo schema, hai impostato cdp_url quindi il browser è stato lanciato altrove senza flag proxy, o una variabile d'ambiente proxy globale ti sta sovrascrivendo. Verifica il proxy con un client HTTP semplice prima - un errore DNS nel log dell'agente di solito significa che nessun proxy è collegato.

Ogni agente per uso browser può usare un IP diverso?

Sì, e dovresti. Crea il Browser all'interno di ogni coroutine del compito con le proprie credenziali proxy piuttosto che condividere un'istanza. Aggiungere un identificatore di sessione unico al nome utente del gateway fissa ogni agente a un'uscita distinta per la durata della sua esecuzione, così dieci agenti paralleli sembrano dieci utenti invece di uno molto occupato.

Quale tipo di proxy è più adatto agli agenti per uso browser?

Residenziale rotante per ricerche e controlli di prezzo dove ogni compito è indipendente, residenziale sticky per qualsiasi cosa con un login o un carrello, e mobile quando il target è ostile o solo mobile. Gli IP del datacenter vanno bene per target interni e pagine non protette, e sono molto più economici per gigabyte - il che conta, perché un agente browser muove molti gigabyte.

Un proxy impedisce a browser-use di essere rilevato?

No. Un proxy risolve solo il livello IP; l'impronta di un Chromium automatizzato è un problema separato, così come il comportamento di un agente che clicca con precisione millimetrica. Le uscite residenziali di fiducia rimuovono il segnale più semplice, ma abbinale a una build del browser orientata alla furtività se il target gestisce seriamente i bot.

Niente qui è esotico: il proxy è una proprietà della sessione, e le due cose che lo rompono sono uno schema mancante e una sessione che non hai mai consegnato. Fai bene queste cose, dai a ogni agente parallelo la propria uscita sticky, e tieni il gateway lontano dalle tue chiamate API del modello. Per una visione più ampia, vedi la nostra mappa dei framework anti-rilevamento e dei proxy autenticati.

Esegui browser-use su oltre 90M di IP residenziali in più di 200 paesi