Risolvere ERR_TUNNEL_CONNECTION_FAILED con un proxy
Aggiornato:
Per caricare una pagina https:// tramite un proxy, il browser invia una richiesta CONNECT e attende che il proxy apra un tunnel verso il sito. L'errore ERR_TUNNEL_CONNECTION_FAILED compare quando il proxy risponde con un errore anziché accettare la richiesta. Il problema è che Chrome non specifica l'errore esatto, quindi il primo passo consiste nell'individuare il codice reale.
Due casi che abbiamo riprodotto
Entrambi i test sono stati eseguiti su un proxy di prova, qui riportato con l'indirizzo di documentazione 203.0.113.10:8080 e user123:pass456. In una normale finestra di Chrome il 407 non genera un errore di tunnel: Chrome apre invece una finestra di accesso per inserire nome utente e password del proxy. Gli errori di tunnel causati da un 407 si manifestano quindi soprattutto nei tool di automazione e nelle applicazioni che non supportano l'inserimento interattivo della password.
| Il proxy risponde a CONNECT con | Chrome mostra | curl mostra |
|---|---|---|
407 senza possibilità di inserire la password (headless Chrome) | ERR_TUNNEL_CONNECTION_FAILED | curl: (56) CONNECT tunnel failed, response 407 |
502 perché il proxy non riesce a raggiungere il sito | ERR_TUNNEL_CONNECTION_FAILED | curl: (56) CONNECT tunnel failed, response 502 |
Cause, in ordine di probabilità
- Uno script di automazione non invia le credenziali. Il flag
--proxy-serverdi Chrome accetta solo host e porta, non user:pass. Puppeteer o Selenium headless ricevono un 407 e segnalano un errore di tunnel. - Un'app mobile su una rete Wi-Fi con proxy protetto da password. L'app non dispone di una schermata di login, quindi il traffico HTTPS si blocca mentre la navigazione da browser continua a funzionare.
- Il proxy non riesce a raggiungere la destinazione. Restituisce 502 alla richiesta CONNECT; la pagina 502 Bad Gateway analizza la questione in dettaglio.
- Solo alcuni siti non funzionano. La destinazione è offline o applica un blocco, mentre gli altri siti continuano a funzionare attraverso lo stesso proxy.
Trovare il codice reale con un comando curl
Esegui curl -v -x http://user123:[email protected]:8080 https://example.com sostituendo i valori con i tuoi. Controlla la riga immediatamente successiva a > CONNECT example.com:443 HTTP/1.1: un codice 407 indica di seguire la guida al 407; un 502 rimanda alla destinazione o all'instradamento a monte del proxy. Se preferisci non usare il terminale, incolla la riga nel proxy checker, che segnalerà auth failed (407) o HTTP 502 negli stessi scenari.
Soluzioni per ambiente
- Puppeteer: mantieni
--proxy-server=http://host:portall'avvio e chiamapage.authenticate({ username, password })prima della navigazione. Esempio completo nella guida ai proxy per Puppeteer. - Playwright: passa
proxy: { server, username, password }all'avvio del browser e Playwright gestirà automaticamente la risposta al 407; consulta la guida a Playwright. - Selenium: Chrome non supporta user:pass da riga di comando; la guida a Selenium illustra le soluzioni applicabili.
- Chrome su Windows: se la finestra di accesso non viene mai mostrata, verifica che un'estensione proxy non la stia bloccando, quindi riprova in una finestra priva di estensioni.
- Smartphone: per le app che richiedono un proxy autenticato, utilizza un'app proxy che supporti user:pass, come descritto nella guida alla configurazione su Android.
Passo dopo passo
- 1
Identifica la risposta a CONNECT
Esegui
curl -v -xcon la riga del tuo proxy o incollala nel checker per verificare se il proxy restituisce 407 o 502. - 2
Per il 407: inserisci correttamente le credenziali
Negli script, usa la funzione di autenticazione della libreria anziché inserire user:pass in
--proxy-server. - 3
Per il 502: prova un altro sito
Carica un sito ad alta disponibilità come example.com attraverso lo stesso proxy. Se funziona, il problema risiede nella destinazione originale.
- 4
Esegui nuovamente e verifica l'IP di uscita
Una volta aperto il tunnel, visita il mio IP dallo stesso browser per confermare che il traffico passi dal proxy.
Domande frequenti
Perché le pagine HTTP si caricano mentre quelle HTTPS falliscono?
Il protocollo HTTP semplice non richiede CONNECT: il proxy inoltra direttamente la richiesta. Solo HTTPS apre un tunnel, motivo per cui gli errori di tunnel si verificano unicamente lì.
Cosa provoca ERR_TUNNEL_CONNECTION_FAILED su Android?
Il più delle volte un'applicazione che non riesce a trasmettere nome utente e password a un proxy Wi-Fi. Prova ad aprire la stessa pagina in Chrome per Android: se Chrome richiede l'accesso e la carica, il problema è l'app.
Posso inserire user:pass all'interno di --proxy-server?
No. Chrome ignora le credenziali in quel flag, generando un 407 e il conseguente errore di tunnel. Esegui invece l'autenticazione tramite Puppeteer, Playwright o un'estensione.
Passare a SOCKS5 risolverà l'errore di tunnel?
Solo se il tuo ordine include SOCKS5. VinaProxy supporta sia HTTP(S) che SOCKS5; seleziona il protocollo indicato per il tuo ordine nella dashboard, poiché una mancata corrispondenza provoca errori differenti.
Proxy compatibili con Puppeteer e Playwright
I proxy di VinaProxy utilizzano l'autenticazione standard user:pass, supportata nativamente dalle più diffuse librerie di automazione.
Vedi le tariffe