Autenticazione Proxy SOCKS5 in Playwright: Perché Fallisce, 4 Soluzioni

Playwright accetta un server socks5:// e poi rifiuta il tuo nome utente e password. La limitazione è di Chromium, non di Playwright, ed è aperta dal 2021 — ecco i quattro modi per aggirarla, classificati.

L'autenticazione proxy SOCKS5 in Playwright non esiste, e saperlo in anticipo ti risparmia una serata. Passa un server socks5:// insieme a un nome utente e una password e Playwright rifiuta prima che il browser navighi. La richiesta di funzionalità su cui tutti si concentrano, microsoft/playwright#10567, è stata aperta a novembre 2021, è ancora aperta e porta ancora l'etichetta P3-collecting-feedback. La limitazione non è di Playwright da risolvere: risiede in Chromium. Questo post mostra le stringhe di errore esatte, spiega perché nessuna estensione o flag di configurazione ti salva e fornisce quattro soluzioni — lo scambio HTTP in una riga, la whitelist IP, un relay locale e Firefox.

L'errore che stai cercando

Ogni versione di questo problema produce una delle due stringhe. In Node ottieni Error: Browser does not support socks5 proxy authentication; in Python, le versioni più vecchie lo prefissano con playwright._impl._api_types.Error: e quelle più recenti con playwright._impl._errors.Error:. Il messaggio è lo stesso e viene lanciato al lancio, non alla navigazione:

const { chromium } = require('playwright');

// Fails immediately — no page is ever created
const browser = await chromium.launch({
  proxy: {
    server: 'socks5://gate.quantumproxies.io:PORT',
    username: 'USER',
    password: 'PASS',
  },
});
// Error: Browser does not support socks5 proxy authentication

// Python raises the same thing:
// playwright._impl._errors.Error: Browser does not support
// socks5 proxy authentication

Esiste una variante più silenziosa. Se elimini i campi delle credenziali e li inserisci invece nella stringa del server — socks5://USER:PASS@host:1080 — non viene lanciato nulla. Chromium ignora semplicemente la parte userinfo dell'URL, tenta una stretta di mano non autenticata, e il gateway la rifiuta. Vedi quindi net::ERR_SOCKS_CONNECTION_FAILED o un semplice timeout al primo goto(), che manda le persone a cercare bug di rete che non ci sono.

Dove l'autenticazione proxy SOCKS5 in Playwright effettivamente si rompe

La documentazione di Playwright è esplicita: i campi username e password nell'opzione proxy sono descritti come credenziali da usare "se il proxy HTTP richiede l'autenticazione". SOCKS è supportato solo come schema. Sotto, Chromium non ha mai implementato la sotto-negoziazione username/password da RFC 1929 per SOCKS5, motivo per cui l'entry nel tracker dei problemi di Chromium sull'autenticazione SOCKS5 (40323993) ha raccolto anni di commenti, perché l'estensione SwitchyOmega avverte gli utenti nel momento in cui selezionano SOCKS5 con credenziali, e perché Brave ed Edge si comportano in modo identico. È un motore, una lacuna, ereditata da tutto ciò che è costruito su di esso.

Questo è anche il motivo per cui il trucco che salva gli utenti di Selenium non aiuta qui. Un'estensione Manifest V3 può rispondere a una sfida proxy tramite chrome.webRequest.onAuthRequired, ma quel hook si attiva su risposte HTTP 407 Proxy Authentication Required. Una stretta di mano SOCKS5 è una negoziazione a livello di byte sul socket prima che esista qualsiasi HTTP, quindi non c'è evento da intercettare. E non confondere l'opzione context httpCredentials con l'autenticazione proxy: risponde alle sfide 401 dal sito web che stai visitando, mai al proxy. Per il quadro completo attraverso i framework stealth, la nostra mappa dei proxy autenticati nei framework anti-detect copre chi supporta cosa.

Soluzione 1: usa l'endpoint HTTP dello stesso gateway

Questa è la soluzione per circa nove utenti su dieci, ed è una riga. I fornitori seri espongono lo stesso pool di IP su entrambi i protocolli su porte diverse — ogni piano QuantumProxies fornisce endpoint HTTP e SOCKS5 con le stesse credenziali e la stessa sintassi di sessione. Cambia lo schema e la porta, mantieni tutto il resto, e i campi delle credenziali native di Playwright fanno il loro lavoro:

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(proxy={
        # was: "socks5://gate.quantumproxies.io:SOCKS_PORT"
        "server": "http://gate.quantumproxies.io:PORT",
        "username": "USER",
        "password": "PASS",
    })
    page = browser.new_page()
    page.goto("https://httpbin.org/ip")
    print(page.text_content("body"))   # must be the proxy exit IP
    browser.close()

Non perdi nulla di misurabile. Per il traffico del browser un proxy HTTP apre un tunnel CONNECT e trasporta gli stessi byte criptati che farebbe un tunnel SOCKS5; le differenze tra i due protocolli contano per il traffico UDP e non-HTTP, non per il caricamento di una pagina. La nostra analisi di SOCKS5 rispetto ai proxy HTTP ha i dettagli. E poiché l'oggetto proxy è accettato anche da newContext(), le stesse credenziali ti danno la rotazione per contesto esattamente come descritto nella nostra guida all'integrazione proxy in Playwright.

Soluzione 2: la whitelist IP mantiene vivo socks5://

Se hai davvero bisogno dello schema SOCKS5 — un proxy che parla solo SOCKS, una catena di strumenti che lo assume — autentica la macchina invece della richiesta. Registra l'IP pubblico dello scraper con il tuo fornitore, rimuovi le credenziali, e Chromium è felice perché non c'è nulla da negoziare:

const { chromium } = require('playwright');

const browser = await chromium.launch({
  proxy: { server: 'socks5://gate.quantumproxies.io:PORT' }, // no creds
});
const page = await browser.newPage();
await page.goto('https://httpbin.org/ip');
console.log(await page.textContent('body'));
await browser.close();

La whitelist autentica una macchina, non uno script, e questo è tutto il compromesso. Un VPS o un'uscita d'ufficio con un indirizzo stabile funziona perfettamente; runner CI effimeri, container autoscalati e qualsiasi cosa dietro un NAT rotante falliranno nel momento in cui l'indirizzo cambia. Verifica l'uscita prima di fidarti di un'esecuzione — una connessione diretta silenziosa sembra esattamente come un proxy funzionante fino a quando il tuo obiettivo inizia a bloccare il tuo IP. Il nostro verificatore di qualità IP gratuito ti dice qual è effettivamente l'uscita, non solo che ha risposto.

Confronto delle quattro soluzioni per l'autenticazione proxy SOCKS5 in Playwright: endpoint HTTP, whitelist IP, relay locale e Firefox — Lo scambio dell'endpoint HTTP costa una riga e nessuna capacità. Tutto ciò che è a destra di esso ti compra lo schema socks5:// a un prezzo.

Soluzione 3: un relay locale che rimuove le credenziali

Quando l'IP non può essere inserito in whitelist e il fornitore non ha una porta HTTP, metti un traduttore davanti al browser. Il modello è sempre lo stesso: un listener locale senza autenticazione inoltra all'endpoint SOCKS5 a monte con credenziali allegate. Con gost, è un singolo comando:

# Local no-auth HTTP listener -> authenticated upstream SOCKS5
gost -L=http://127.0.0.1:8080 \
     -F=socks5://USER:PASS@gate.quantumproxies.io:PORT

# Playwright then points at the local hop, with no credentials:
#   proxy: { server: 'http://127.0.0.1:8080' }

Due regole. Collega il listener a 127.0.0.1, mai a 0.0.0.0 — un proxy senza autenticazione raggiungibile da internet è un relay aperto che verrà trovato e abusato entro poche ore. E tratta il relay come un processo che devi supervisionare: se muore, Chromium torna a un errore di connessione piuttosto che a una richiesta diretta, che è almeno rumorosa. Questo approccio è diventato abbastanza comune che i praticanti pubblicano piccoli relay costruiti appositamente; confrontiamo le opzioni nella nostra guida agli strumenti di relay SOCKS5 auth.

Soluzione 4: esegui Firefox invece di Chromium

Firefox implementa nativamente l'autenticazione username/password SOCKS5, che è la differenza a cui il thread del problema di Playwright continua a puntare. Cambia il tipo di browser e l'errore scompare:

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.firefox.launch(proxy={
        "server": "socks5://gate.quantumproxies.io:PORT",
        "username": "USER",
        "password": "PASS",
    })
    page = browser.new_page()
    page.goto("https://httpbin.org/ip")
    print(page.text_content("body"))   # confirm the exit before trusting it
    browser.close()

Fai il passo di verifica, ogni volta. Il fatto che Playwright non lanci non è prova che le credenziali siano state usate — solo un'eco IP lo è. E sii chiaro su cosa stai acquistando: un motore di rendering diverso, una superficie di impronte digitali diversa e un ecosistema stealth che pende pesantemente verso Chromium. Se il tuo obiettivo accetta già Firefox questo è gratuito. Se hai scelto Chromium per motivi anti-bot, cambiare motore per risolvere un problema di proxy è il compromesso sbagliato — prendi la soluzione 1 e mantieni il tuo browser.

La decisione, in una riga ciascuna

Il fornitore ha una porta HTTP: usala. Una riga, autenticazione nativa, stesse uscite, nessun processo extra.
IP pubblico fisso: inseriscilo in whitelist e mantieni socks5:// senza credenziali.
Nessuno dei due: esegui un relay locale collegato a loopback e punta Playwright a 127.0.0.1.
Già su Firefox: passa le credenziali e verifica l'IP di uscita una volta.
Mai: credenziali all'interno della stringa server. Chromium le elimina senza una parola.

Elenco di configurazioni proxy SOCKS5 in Playwright che funzionano in Chromium rispetto a configurazioni che lanciano o falliscono silenziosamente — Chromium accetta lo schema SOCKS5 e mai le credenziali. Tutto ciò che è a destra di questa lista fallisce — metà senza un errore.

Domande frequenti

Playwright supporta l'autenticazione proxy SOCKS5?

Non con Chromium. L'opzione proxy di Playwright documenta nome utente e password come credenziali HTTP(S), e Chromium non ha un'implementazione username/password SOCKS5 a cui passarle, quindi il lancio fallisce. Firefox in Playwright lo supporta. Il problema di tracciamento, microsoft/playwright#10567, è aperto da novembre 2021 senza una correzione programmata.

Cosa significa 'Browser does not support socks5 proxy authentication'?

Significa che hai passato credenziali insieme a un server socks5:// a un lancio di Chromium. Playwright valida la combinazione e rifiuta piuttosto che aprire un browser che le ignorerebbe silenziosamente. Spostati all'endpoint HTTP del gateway e mantieni i campi delle credenziali, o autentica tramite whitelist IP e rimuovile del tutto.

Come uso un proxy SOCKS5 con Playwright in Python?

Passa proxy={"server": "socks5://host:port"} senza nome utente o password, e fai autorizzare l'IP pubblico della tua macchina dal fornitore. Se l'IP non è stabile, usa l'endpoint HTTP dello stesso gateway con credenziali, o inoltra tramite un relay locale. Conferma sempre l'uscita contro un endpoint di eco IP.

Un'estensione Chrome può aggiungere l'autenticazione SOCKS5?

No. Il trucco dell'estensione usato per i proxy HTTP autenticati si basa su chrome.webRequest.onAuthRequired, che si attiva su risposte HTTP 407. SOCKS5 autentica durante la stretta di mano del socket, prima che esista qualsiasi richiesta HTTP, quindi nessuna API di estensione può vederlo. Le estensioni di switcher proxy avvertono di questa limitazione per lo stesso motivo.

SOCKS5 è più veloce di HTTP per lo scraping con Playwright?

Non in modo significativo. Il traffico HTTPS attraverso un proxy HTTP utilizza un tunnel CONNECT, quindi entrambi i protocolli trasportano lo stesso stream criptato con un overhead comparabile. I veri vantaggi di SOCKS5 sono il supporto UDP e la neutralità del protocollo, nessuno dei quali viene utilizzato dal caricamento di una pagina del browser. Scegli l'endpoint che si autentica pulitamente.

La versione breve: smetti di cercare di far fare a Chromium qualcosa che non ha mai fatto. Sposta il lavoro sull'endpoint HTTP, o inserisci in whitelist e rimuovi le credenziali — e se devi mantenere socks5:// con un'uscita rotante, metti un relay nel mezzo piuttosto che un workaround nel tuo codice. Una volta che l'autenticazione è fuori gioco, la cosa che decide se l'esecuzione ha successo è il pool dietro di essa: uscite residenziali in oltre 200 paesi, con rotazione per richiesta o sessioni sticky quando un flusso necessita di un'identità.

Ottieni endpoint HTTP e SOCKS5 su un unico piano