ERR_TUNNEL_CONNECTION_FAILED: диагноз содержится в самой ошибке

Большинство браузерных ошибок расплывчаты. Эта - нет, и в этом хорошая новость.

Когда вы открываете HTTPS-сайт через прокси, браузер не отправляет запрос напрямую. Он сначала просит прокси построить туннель, отправляя HTTP-запрос CONNECT с указанием хоста и порта. Прокси должен ответить 200 Connection Established, после чего зашифрованный трафик проходит через него нетронутым.

ERR_TUNNEL_CONNECTION_FAILED означает, что этот обмен не завершился. Не то что сайт недоступен, не то что интернет сломался, не то что DNS запутался. Сбой произошёл на этапе прокси.

Это даёт диагноз ещё до того, как вы что-то меняли: в вашем соединении есть прокси, и проблема именно в нём. Вопрос только в том, какой именно прокси и почему он отказал.

«Но я не использую прокси»

Значит, у вас есть тот, который вы не настраивали специально. В примерном порядке частоты встречаемости:

• VPN-клиент, запущенный или полузапущенный. Многие прописывают системный прокси и оставляют его после падения или некорректного отключения.
• Расширение браузера. Блокировщики рекламы, инструменты приватности и расширения типа «бесплатный VPN» могут установить прокси через API расширений, и в баг-трекере самого Chromium есть сообщения об этой ошибке именно из этого источника.
• Корпоративная или учебная конфигурация. PAC-файл или политика, отправленная централизованно, часто указывающая на прокси, который отвечает только изнутри офисной сети. Поэтому ноутбук работает в офисе и не работает дома.
• Остаточные системные настройки. Параметры локальной сети Windows и сетевые прокси macOS хранят то, что в них последний раз записали, в том числе программы, которые вы уже удалили.
• Вредоносное ПО или adware, которое обычно внедряется в качестве локального прокси.

Быстрее всего разобраться так: откройте тот же сайт в другом браузере и через мобильный интернет. Если не работает только один браузер - дело в расширении или его собственных настройках прокси. Если все браузеры на компьютере не работают, а на телефоне всё в порядке - дело в системе или сети.

Где искать по платформам

Строка про WSL регулярно сбивает людей с толку. Терминал внутри WSL и браузер на той же машине могут вообще расходиться во мнении о том, существует ли прокси, поэтому один работает, а другой нет.

Если вы настраивали прокси специально

Это та часть, которую пропускают стандартные гайды, потому что их совет - «отключите прокси». Если прокси - это суть, вот шесть способов, которыми он порождает именно эту ошибку.

1. Неправильный порт или правильный порт для неправильного протокола. SOCKS5-эндпоинт, введённый в поле HTTP-прокси, будет каждый раз проваливать рукопожатие CONNECT. То же самое с HTTP-портом, введённым как SOCKS. Проверьте, на каком протоколе на самом деле говорит порт, прежде чем грешить на учётные данные.

2. Аутентификация не проходит. Родственная ошибка - 407 Proxy Authentication Required, и эти два запроса находятся в одном кластере не просто так: в зависимости от клиента неудачная авторизация всплывает как одна или другая. Если вы видите 407 где-то рядом, начните с этого, с руководства по исправлению 407.

3. Прокси не разрешает CONNECT на этот порт. Многие прокси разрешают CONNECT на 443 и отклоняют всё остальное. Если в URL, который не открывается, нестандартный порт - вот ваш ответ.

4. Ваш IP не в белом списке. Провайдеры, которые аутентифицируют по IP, а не по логину, молча отклоняют туннели с неизвестных адресов. Ваш домашний адрес изменился, или вы сменили сеть, и больше ничего не менялось.

5. Прокси мёртв, истёк или заблокирован. Неоплаченный или истёкший адрес не сообщает об этом вежливо, со стороны браузера это выглядит именно так.

6. Апстрим блокирует пункт назначения. Некоторые провайдеры блокируют определённые порты или категории. Запрос на туннель в порядке, прокси просто не откроет его к этому хосту.

Отделить эти случаи за одну минуту можно, протестировав прокси вне браузера:

curl -x http://USER:PASS@HOST:PORT -I https://example.com

200 или 301 означает, что прокси и учётные данные работают, а проблема в конфигурации браузера. 407 означает аутентификацию. Отказ в соединении означает, что эндпоинт или порт неверны. Эта и остальные предпокупочные проверки описаны в статье как протестировать прокси перед покупкой.

По браузерам

Chrome, Edge, Opera и Brave - всё это Chromium, поэтому у них одинаковый текст ошибки и общий системный прокси, если его не переопределяет расширение. Это объясняет два типичных паттерна:

• Не работает в Chrome и Edge, но работает в Firefox. Firefox хранит собственные настройки прокси и по умолчанию игнорирует системные, поэтому он незаметно обходит то, что сломано. Firefox покажет другое сообщение для той же базовой проблемы.
• Не работает только в одном браузере на Chromium. У этого браузера есть расширение или флаг командной строки, устанавливающий прокси, который остальные не используют.

Safari использует системные настройки macOS, поэтому на том же Mac ведёт себя как Chrome.

Почему в этом всплывают Teams, Outlook, Gmail и YouTube

Все они - просто HTTPS через тот же самый хоп. В них нет ничего специфического: если туннель падает, падает весь HTTPS, а люди ищут тот сайт, который как раз открывали.

Два приложения действительно отличаются:

• VS Code хранит собственную настройку прокси и может не работать, пока браузер работает.
• Всё, что в WSL или контейнере, имеет полностью собственное окружение, согласно таблице выше.

Порядок исправления

1. Попробуйте мобильный интернет или другую сеть. За десять секунд разделит «моя машина» и «эта сеть».
2. Попробуйте другой браузер. Разделит конфигурацию браузера и конфигурацию системы.
3. Проверьте системные настройки прокси для вашей платформы в таблице выше и отключите всё, что вы не устанавливали сознательно.
4. Отключите расширения или откройте приватное окно, где они по умолчанию отключены, и посмотрите, исчезнет ли ошибка.
5. Полностью закройте VPN-клиент, а не просто отключитесь от него.
6. Если прокси намеренный, выполните тест curl выше и проработайте шесть причин.

Что это не исправит

Стоит назвать, потому что популярные советы для этой ошибки в основном унаследованы от других ошибок:

• Очистка кеша. Сбой происходит до того, как начинается загрузка контента.
• Сброс DNS. Разрешение имён не падало, падал туннель. DNS важен только если само имя хоста прокси не разрешается.
• Сброс всего сетевого стека. Иногда срабатывает, но только потому, что попутно стирает настройки прокси, что третий пункт делает намеренно и обратимо.
• Переход на публичный DNS-резолвер. Та же история, что с очисткой кеша.

Если инструкция начинается с кеша и DNS применительно к этой конкретной ошибке, значит проблему с прокси пытаются решить как обычный сбой соединения.

Если вы здесь потому, что настраиваете прокси

Тогда эта ошибка - скорее информационное сообщение о конфигурации, чем поломка, и полезная последовательность действий такая:

1. Убедитесь, что конечная точка говорит на том протоколе, который вы указали при настройке, согласно различиям между типами прокси.
2. Проверьте аутентификацию отдельно через curl, прежде чем подключать браузер.
3. Убедитесь, что с этого адреса вообще разрешено подключаться к целевому ресурсу, поскольку некоторые сайты блокируют целые категории адресов. Родственный случай, когда отказ исходит от сайта, а не от прокси, разобран в статье почему Reddit пишет, что вас заблокировала сетевая защита.

Получение чистого 200 Connection Established через curl до запуска браузера экономит большую часть времени, которое люди теряют на эту ошибку.

FAQ

Что означает ERR_TUNNEL_CONNECTION_FAILED?

Что браузер попросил прокси-сервер открыть зашифрованный туннель до сайта с помощью HTTP-метода CONNECT, а прокси не завершил это рукопожатие. Это именно сбой прокси, а не проблема интернета, DNS или самого сайта.

Как исправить ERR_TUNNEL_CONNECTION_FAILED?

Найдите прокси. Проверьте системные настройки прокси, отключите расширения браузера, полностью закройте клиент VPN и попробуйте другой браузер и другую сеть, чтобы сузить круг. Если прокси был настроен намеренно, протестируйте его через curl вне браузера, чтобы отделить проблему с учетными данными от неправильного порта или мертвой конечной точки.

Я не использую прокси, почему я это вижу?

Потому что что-то настроило его за вас: VPN-клиент, который не убрал за собой настройки, расширение браузера, корпоративная или школьная политика, оставшиеся настройки от удаленного ПО или рекламное ПО. Ошибка появляется только когда прокси встал на пути, так что задача целиком в том, чтобы его найти.

ERR_TUNNEL_CONNECTION_FAILED это HTTP-код статуса?

Нет. Это сетевая ошибка Chromium, а не HTTP-ответ. Ближайший HTTP-эквивалент - это то, что должен был бы вернуть прокси: 200 Connection Established при успехе или что-то вроде 407 Proxy Authentication Required, когда учетные данные отклонены.

Почему это происходит в Chrome, но не в Firefox?

Потому что браузеры на Chromium по умолчанию используют системные настройки прокси, а у Firefox свои собственные. Firefox ничего не чинит, он просто полностью обходит сломанный прокси, что тоже полезно для диагностики.

Можно ли обойти ERR_TUNNEL_CONNECTION_FAILED?

Только убрав или починив прокси на пути. Никакого флага браузера или трюка не существует, потому что браузер сообщает о том, что обязательный шаг не был выполнен. Если прокси принадлежит вашему работодателю или учебному заведению, сеть работает так, как она настроена.

Почему это показывают Teams, Outlook или Gmail?

Они ничего особенного не делают. Всё это HTTPS-трафик через тот же самый прокси-переход, так что когда туннель падает, они падают вместе со всем остальным. Исключение, которое стоит знать, это VS Code, у него своя собственная настройка прокси.

Помогает ли очистка кеша или сброс DNS?

Редко, и не по той причине, о которой думают. Туннель падает раньше, чем запрашивается какой-либо контент, поэтому в кеше нечему быть неправильным. DNS имеет значение только если имя самого прокси-сервера не разрешается.