Отстраняване на ERR_TUNNEL_CONNECTION_FAILED при използване на прокси
Updated:
За да зареди страница с https:// през прокси, браузърът изпраща заявка CONNECT и изчаква проксито да отвори тунел към сайта. ERR_TUNNEL_CONNECTION_FAILED се появява, когато проксито отговори на тази заявка с грешка вместо с потвърждение. Уловката е, че Chrome не посочва конкретната грешка, така че първата задача е да откриете реалния код.
Два случая, които възпроизведохме
И двата случая бяха тествани с тестово прокси, посочено тук с документационния адрес 203.0.113.10:8080 и user123:pass456. В нормален прозорец на Chrome грешка 407 не води до грешка в тунела – вместо това Chrome отваря диалогов прозорец за вход с потребителско име и парола за проксито. Затова грешките в тунела, причинени от 407, се появяват предимно в инструменти за автоматизация и в приложения, които не могат да изискат парола.
| Проксито отговаря на CONNECT с | Chrome показва | curl показва |
|---|---|---|
407 без възможност за въвеждане на парола (headless Chrome) | ERR_TUNNEL_CONNECTION_FAILED | curl: (56) CONNECT tunnel failed, response 407 |
502, тъй като проксито не може да достигне сайта | ERR_TUNNEL_CONNECTION_FAILED | curl: (56) CONNECT tunnel failed, response 502 |
Причини, подредени по вероятност
- Скрипт за автоматизация не изпраща идентификационни данни. Флагът
--proxy-serverна Chrome приема само хост и порт, без user:pass. Headless Puppeteer или Selenium получава 407 и съобщава за срив на тунела. - Мобилно приложение зад защитено с парола Wi-Fi прокси. Приложението няма диалогов прозорец за вход, поради което HTTPS спира да работи, докато браузърът продължава да функционира.
- Проксито не може да достигне целевия сайт. Връща 502 при CONNECT; страницата за 502 Bad Gateway разглежда това подробно.
- Само определени сайтове не се зареждат. Крайната дестинация блокира заявката или е недостъпна, докато други сайтове работят през същото прокси.
Открийте реалния код с една команда curl
Изпълнете curl -v -x http://user123:[email protected]:8080 https://example.com със собствените си стойности. Погледнете реда веднага след > CONNECT example.com:443 HTTP/1.1: код 407 означава да следвате ръководството за 407; код 502 насочва към проблем с дестинацията или с връзката зад проксито. Ако предпочитате да не използвате терминал, поставете реда в инструмента за проверка на прокси, който показва auth failed (407) или HTTP 502 при същите ситуации.
Решения според средата
- Puppeteer: запазете
--proxy-server=http://host:portпри стартиране и извикайтеpage.authenticate({ username, password })преди навигация. Пълен пример ще намерите в ръководството за прокси в Puppeteer. - Playwright: подайте
proxy: { server, username, password }при стартиране на браузъра и Playwright ще обработи 407 вместо вас; вижте Playwright. - Selenium: Chrome не приема user:pass от командния ред; ръководството за Selenium показва работещи решения.
- Chrome в Windows: ако диалоговият прозорец за вход така и не се появи, проверете дали разширение за прокси не го блокира, след което опитайте отново в прозорец без разширения.
- Телефони: за приложения, които изискват прокси с автентикация, използвайте прокси приложение, поддържащо user:pass, както е описано в ръководството за настройка в Android.
Стъпка по стъпка
- 1
Установете отговора на CONNECT
Изпълнете
curl -v -xс вашия прокси ред или го поставете в инструмента за проверка, за да разберете дали проксито връща 407 или 502. - 2
При 407: подайте идентификационните данни правилно
В скриптовете използвайте механизма за автентикация на библиотеката, вместо да поставяте user:pass в
--proxy-server. - 3
При 502: опитайте друг сайт
Заредете голям сайт, например example.com, през същото прокси. Ако той се отваря, проблемът е в първоначалната дестинация.
- 4
Стартирайте отново и потвърдете изходния IP адрес
След като тунелът се отвори, посетете моя IP адрес в същия браузър, за да потвърдите, че трафикът преминава през проксито.
Често задавани въпроси
Защо http страниците се зареждат, а https страниците дават грешка?
Обикновеният http не изисква CONNECT; проксито препраща заявката директно. Само https отваря тунел, затова грешките в тунела възникват единствено при него.
Какво причинява ERR_TUNNEL_CONNECTION_FAILED в Android?
Най-често приложение, което не може да предаде потребителското име и паролата към Wi-Fi прокси. Опитайте да отворите същата страница в Chrome за Android; ако Chrome изведе подкана за вход и я зареди, проблемът е в приложението.
Мога ли да поставя user:pass в --proxy-server?
Не. Chrome игнорира идентификационните данни в този флаг, което води до 407 и грешка в тунела. Автентикирайте се през Puppeteer, Playwright или чрез разширение.
Преминаването към SOCKS5 ще премахне ли грешката в тунела?
Само ако поръчката ви е за SOCKS5. VinaProxy предлага както HTTP(S), така и SOCKS5; изберете протокола, посочен за вашата поръчка в таблото за управление, тъй като несъответствието води до други грешки.
Проксита, съвместими с Puppeteer и Playwright
Прокситата на VinaProxy използват стандартен вход с user:pass, който популярните библиотеки за автоматизация поддържат директно.
Вижте цените