# 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](https://github.com/microsoft/playwright/issues/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:

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

// Fails immediately — no page is ever created
const browser = await chromium.launch({
  proxy: {
    server: 'socks5://residentialpremium.quantumproxies.io:1080',
    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](https://quantumproxies.io/blog/anti-detect-frameworks-authenticated-proxies-map) 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](https://quantumproxies.io/socks5-proxies) 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:

```python
from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(proxy={
        # was: "socks5://residentialpremium.quantumproxies.io:1080"
        "server": "http://residentialpremium.quantumproxies.io:8080",
        "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](https://quantumproxies.io/blog/socks5-vs-http-proxy-difference) 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](https://quantumproxies.io/blog/playwright-proxy-integration).

## 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:

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

const browser = await chromium.launch({
  proxy: { server: 'socks5://residentialboson.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](https://quantumproxies.io/ip-checker) gratuito ti dice qual è effettivamente l'uscita, non solo che ha risposto.

![Le quattro soluzioni per l'autenticazione proxy SOCKS5 in Playwright una accanto all'altra: passare all'endpoint HTTP del gateway, mettere l'IP in whitelist, eseguire un relay locale o avviare Firefox. La scheda mostra il prezzo di ciascuna: il passaggio a HTTP costa una riga, le altre richiedono un IP fisso, un processo da supervisionare o un motore diverso.](https://res.cloudinary.com/dmqliab0t/image/upload/f_auto,q_auto,w_1200/v1785776550/blog/generated/qp-b10-003-diag1.png)
*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:

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

# 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](https://quantumproxies.io/blog/proxy-relay-socks5-auth-tools).

## 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:

```python
from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.firefox.launch(proxy={
        "server": "socks5://residentialpremium.quantumproxies.io:1080",
        "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.

![Configurazioni SOCKS5 di Playwright in Chromium: le credenziali nei campi del proxy generano un errore all'avvio, mentre le credenziali dentro la stringa del server socks5:// falliscono in silenzio con un errore di connessione SOCKS. La scheda elenca cosa funziona: l'endpoint HTTP con nome utente e password, socks5:// con un IP in whitelist o un relay locale.](https://res.cloudinary.com/dmqliab0t/image/upload/f_auto,q_auto,w_1200/v1785776551/blog/generated/qp-b10-003-diag2.png)
*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](https://quantumproxies.io/residential-proxies) 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](https://quantumproxies.io/socks5-proxies)