Proxy per agenti AI: Playwright MCP e browser-use 2026

L'agente AI che naviga autonomamente sui siti — Claude con Playwright MCP, browser-use, Browserbase cloud — si imbatte nello stesso muro di un normale parser: un paio di dozzine di richieste da un unico indirizzo, e poi invece della pagina arriva una sfida di Cloudflare. La differenza è che l'agente non si offende e semplicemente si blocca, bruciando token nei tentativi di "premere un pulsante che non esiste".

La soluzione è l'uso di proxy. Ma collegare un proxy all'agente si rivela inaspettatamente non ovvio: metà delle istruzioni su internet propone una sintassi che Chromium ignora silenziosamente. Di seguito sono riportate configurazioni funzionanti per i tre stack più comuni del 2026 e un'analisi delle trappole su cui tutti inciampano.

A chi serve

Guida per coloro che hanno già avviato l'agente e hanno riscontrato uno dei sintomi:

l'agente esegue 10–20 passaggi, e poi ogni passaggio successivo restituisce un captcha o una pagina "Verifica di essere umano";
l'agente non vede il contenuto corretto: i prezzi, i risultati e la disponibilità del prodotto vengono mostrati dal sito in base al tuo IP server, non al paese desiderato;
l'agente è avviato nel cloud (VPS, GitHub Actions, contenitore), e l'indirizzo del data center dell'host è già contrassegnato come bot;
hai configurato un proxy con nome utente e password, ma il browser si avvia come se il proxy non esistesse affatto.

Se sei ancora nella fase "perché gli agenti vengono bloccati" — prima leggi l'analisi su come i sistemi anti-bot distinguono il browser dell'agente da un umano: lì si parla dei segnali di rilevamento, e qui — pura pratica di connessione.

Trappola n. 1: Chromium non accetta nome utente e password nella stringa proxy

Il più comune errore, e costa ore di debug. La forma classica della stringa del provider è user:pass@host:port. La inserisci nel flag di avvio del browser:

--proxy-server="http://user:[email protected]:8080"

E non funziona. Chromium non supporta la trasmissione delle credenziali all'interno del flag --proxy-server: appare un errore in console riguardo un proxy non supportato, e il traffico passa oltre. Se rimuovi le credenziali e lasci solo host:port, il browser in modalità normale mostrerà una finestra di sistema per richiedere nome utente e password — e a quel punto tutto si ferma, perché in modalità headless non c'è finestra e non c'è nessuno da cui premere.

Da questo seguono tre percorsi funzionanti, e la scelta deve essere consapevole:

Autenticazione per IP (whitelist). La soluzione più pulita per gli agenti. Aggiungi l'indirizzo della macchina dove gira l'agente nella whitelist nel pannello del provider — e poi ti connetti senza nome utente e password, semplicemente con la stringa host:port. Il flag --proxy-server inizia a funzionare come previsto, headless non chiede più nulla. ProxyCove supporta entrambi i metodi — sia nome utente:password, sia IP-whitelist, e anche contemporaneamente, quindi per l'agente puoi creare una whitelist, mentre per i compiti manuali lasciare la password.
Trasmettere le credenziali a livello API, non di flag. Playwright, Puppeteer e browser-use possono accettare username e password come campi separati — non è lo stesso meccanismo del flag della riga di comando, e funziona. Utile quando scrivi il codice dell'agente tu stesso.
Relay locale. Imposti un proxy senza password che inoltra le richieste all'upstream con password, e indichi all'agente l'indirizzo locale. Opzione per i casi in cui la whitelist non è disponibile: ad esempio, l'IP della macchina è variabile.

Playwright MCP: configurazione che funziona davvero

Playwright MCP di Microsoft — oggi è lo standard de facto per gli agenti che necessitano di un vero browser. Il proxy è impostato con gli argomenti del server direttamente nella configurazione del client MCP:

{"mcpServers":{"playwright":{"command":"npx","args":["@playwright/mcp@latest","--browser","chromium","--headless","--proxy-server","http://gate.example.com:8080","--proxy-bypass",".local,.internal","--isolated","--viewport-size","1920x1080"]}}}

Cosa è importante qui per punti:

--proxy-server accetta sia indirizzi HTTP che SOCKS5 nel formato socks5://host:port. Senza credenziali — vedi la trappola sopra.
--proxy-bypass — elenco di domini separati da virgole che bypassano il proxy. Non è un'opzione decorativa: se l'agente ha servizi interni o un'API locale, instradarli attraverso un canale residenziale significa traffico extra a pagamento per gigabyte.
--isolated mantiene il profilo in memoria e non lo scrive su disco. Utile quando ogni compito deve iniziare da un foglio pulito. Il rovescio della medaglia è che i cookie non sopravvivono al riavvio, e ogni sessione per il sito appare come un nuovo visitatore.
--user-data-dir — al contrario, profilo permanente. Per scenari con autenticazione, usalo invece dell'isolamento, e assicurati di fissare l'IP (vedi la sezione sui sticky qui sotto).
--storage-state consente di inserire cookie e localStorage salvati in una sessione isolata — compromesso tra i due precedenti.
--allowed-origins e --blocked-origins limitano dove l'agente può effettivamente andare. Risparmio sottovalutato: un agente che si dedica ad analisi e domini pubblicitari può facilmente triplicare il consumo di traffico.
--device (ad esempio, "iPhone 15") e --user-agent cambiano come l'agente si presenta come browser. Impostali in modo coerente con il tipo di proxy: un User-Agent mobile su un IP di data center è una contraddizione che il sistema anti-bot legge immediatamente.

Separatamente su --cdp-endpoint: collega MCP a un browser già avviato. Allora il proxy è configurato non con i flag MCP, ma all'avvio di quel browser — una causa tipica di perché "il proxy è impostato, ma l'IP è lo stesso".

browser-use: proxy tramite ProxySettings

Se l'agente è costruito su browser-use, la configurazione va nell'oggetto delle impostazioni, e qui è possibile passare nome utente e password — vengono inviati tramite API, non tramite riga di comando:

from browser_use import Browser, ProxySettings proxy = ProxySettings(server='http://gate.example.com:8080', username='user', password='pass', bypass='localhost,127.0.0.1') browser = Browser(proxy=proxy)

Il campo server è obbligatorio, gli altri sono opzionali. Lo stesso principio si applica anche in Playwright puro: il proxy è impostato globalmente all'avvio del browser, o separatamente per ogni contesto tramite browser.newContext({ proxy: { server: ... } }). La seconda opzione è la chiave per agenti paralleli: ogni contesto riceve il proprio indirizzo di uscita, e dieci compiti non condividono un solo IP.

Browser cloud: proxy a livello di sessione

Con Browserbase e servizi simili, il browser vive nel cloud di qualcun altro, quindi i flag di avvio non sono disponibili — il proxy è impostato nei parametri di sessione, di solito con una stringa del tipo http://nomeutente:password@gateway:port nella variabile d'ambiente del server MCP. La limitazione di Chromium qui non è un problema: il provider cloud gestisce la stringa e configura il browser dall'interno.

Un dettaglio pratico: i browser cloud hanno un proprio pool di proxy, e questo è condiviso tra tutti i clienti. Se il compito è sensibile alla reputazione dell'indirizzo — accesso all'account, lavoro con una piattaforma dove sei già noto — il tuo canale è più prevedibile rispetto a quello generale.

Rotazione o fissazione: scegli in base al tipo di compito

Errore comune dei principianti — attivare la rotazione per ogni richiesta e stupirsi del perché l'agente venga disconnesso. Gli scenari agenti hanno due modalità, e non sono intercambiabili:

Rotazione per ogni richiesta (su ProxyCove è la porta 824) — per esplorazione: aggirare cento schede prodotto, raccogliere risultati, controllare i prezzi in diverse regioni. Ogni richiesta parte da un nuovo indirizzo, collegarli tra loro è difficile.
Sessione fissata (porte 10000+, intervallo di cambio da 1 a 120 minuti) — per tutto ciò che consiste in passaggi: login, carrello, modulo multi-pagina, lungo dialogo con l'interfaccia. Se l'IP cambia nel mezzo della catena, il sito al meglio chiederà di ri-autenticarsi, nel peggiore dei casi — contrassegnerà la sessione come sospetta.

L'agente lavora quasi sempre nella seconda modalità: per definizione esegue una sequenza di passaggi, non un solo colpo. I dettagli sulla scelta dell'intervallo e errori comuni sono trattati nella guida su quando sono necessarie le sessioni sticky e come configurarle.

Cinque insidie

SOCKS5 con autenticazione in Chromium. La sintassi socks5:// in Playwright esiste, ma la combinazione "SOCKS5 più nome utente e password" nei browser basati su Chromium è storicamente problematica — la richiesta corrispondente nel tracker di Playwright è aperta da novembre 2021. Se hai scelta, per gli agenti prendi un canale HTTP(S), è più prevedibile.
Perdita di DNS e WebRTC. Il traffico passa attraverso il proxy, mentre i nomi vengono risolti direttamente o WebRTC restituisce l'indirizzo reale — e tutta la mascheratura perde significato. Controlla questo prima, non dopo l'avvio dell'agente: come nascondere WebRTC quando si lavora tramite proxy.
Disallineamento tra geo e locale. IP in Germania, fuso orario della macchina di Mosca, lingua dell'interfaccia inglese — un insieme che di per sé appare come automazione. In Playwright, la località e il fuso orario sono impostati nei parametri di contesto, portali in linea con il paese del proxy.
Traffico che non hai ordinato. L'agente apre la pagina interamente, insieme a immagini, font e script pubblicitari. Su un canale residenziale con pagamento per gigabyte, questo è un costo significativo — blocca i domini superflui e, dove possibile, disabilita il caricamento dei media.
Il proxy non è impostato dove parte il browser. Quando si lavora tramite --cdp-endpoint, tramite un wrapper Docker o un servizio cloud, i flag MCP non influenzano la connessione reale. La prima cosa da fare dopo la configurazione è far aprire all'agente qualsiasi servizio di verifica IP e assicurarsi che l'indirizzo e il paese siano quelli giusti.

Quale tipo di proxy scegliere per l'agente

La regola è semplice: più il compito è vicino a un utente reale, più "umana" deve essere l'indirizzo.

Proxy residenziali — base per gli agenti. Questi sono indirizzi di provider domestici, e per il sito l'agente appare come un visitatore normale. Necessari ovunque ci sia Cloudflare, prezzi regionali e qualsiasi accenno a anti-bot.
Proxy mobili — artiglieria pesante per social media e piattaforme dove gli account sono trattati con particolare nervosismo. Dietro un solo indirizzo mobile ci sono migliaia di abbonati reali, quindi bannarlo completamente costa caro alla piattaforma.
Proxy di data center — per API interne, ambienti di test e fonti aperte senza protezione. Veloci e a buon mercato, ma su siti protetti l'agente si imbatterà in una sfida quasi immediatamente.

Un dettaglio utile per gli scenari agenti: cambiare protocollo su ProxyCove avviene sostituendo il prefisso nella stringa di connessione — HTTP, HTTPS e SOCKS5 sono disponibili sullo stesso proxy, non è necessario riconfigurare il proxy stesso. Ci sono più di 195 paesi nel pool, quindi "mostrare all'agente i risultati locali" si risolve scegliendo il paese al momento dell'acquisto.

Conclusione

Collegare un proxy all'agente AI non è una sola riga, ma tre soluzioni consecutive: come autenticarsi (per l'agente headless quasi sempre una whitelist IP, non una password), dove impostare il proxy (flag MCP, oggetto delle impostazioni o parametri della sessione cloud — ma necessariamente dove il browser viene realmente avviato) e in quale modalità lavorare (per scenari multi-passaggio — indirizzo fissato, non rotazione per ogni richiesta). Inoltre, è obbligatorio controllare le perdite di DNS e WebRTC prima del lancio operativo.

Fallo una volta con attenzione — e l'agente smetterà di sprecare token per conversazioni con captcha. I proxy residenziali di ProxyCove si collegano a Playwright MCP e browser-use in pochi minuti, pagamento in base al traffico, la whitelist IP per la modalità headless è attivabile nel pannello.