ERR_TUNNEL_CONNECTION_FAILED в Chrome: как найти причину

Краткий ответ

Chrome показывает ERR_TUNNEL_CONNECTION_FAILED, когда не удается установить туннель через прокси. В списке ошибок Chromium указан этап сбоя. Чтобы разобраться в причине, откройте инструкцию к своему аккаунту: совпадает ли адрес сервера, верно ли указан порт, выбран ли нужный способ доступа? Если используется HTTP-прокси, следующий шаг – посмотреть ответ на CONNECT.

Прежде чем менять настройки, откройте еще один HTTPS-сайт. Для каждого адреса запишите результат: страница загрузилась или появилась конкретная ошибка. Это сравнение пригодится, если сбой повторяется только на одном сайте.

Главное

• Ответ 407 – повод проверить способ доступа и данные для аутентификации.
• Успешное создание туннеля не исключает последующую ошибку TLS.
• Если curl загружает страницу, сравните его параметры с адресом сервера и логином в активном профиле Chrome.

На каком этапе прервалось HTTPS-соединение?

Ошибка относится к созданию туннеля. При обращении к HTTPS-сайту через HTTP-прокси Chrome сначала просит посредника соединиться с нужным узлом, например example.com:443. Для этого используется CONNECT. Когда туннель открыт, через него начинается обмен TLS с сайтом. RFC 9110 допускает ограничения на адреса и порты, к которым разрешены такие подключения.

Если вы проверяли доступность порта, уточните, чей это был порт. Успешное соединение с прокси-сервером говорит только об этом участке маршрута. Доступ к сайту через него еще предстоит проверить: установленное TCP-соединение само по себе не подтверждает, что запрос будет выполнен.

Сохраните полное название ошибки. Для ERR_PROXY_CONNECTION_FAILED в Chromium указаны другие операции: определение адреса по имени прокси или открытие сокета к нему. Сбои HTTP CONNECT из этого определения исключены. При такой ошибке начинают с проверки связи с посредником; в нашей статье разбирается следующий этап – создание туннеля.

Использует ли Chrome нужные параметры подключения?

Фактические настройки Chrome могут отличаться от тех, которые вы собирались применить. Откройте инструкцию провайдера рядом с сохраненной конфигурацией. Посимвольно сравните адрес и порт, затем проверьте протокол. Для HTTPS-страницы не обязательно нужен HTTPS-прокси. Если в аккаунте выданы параметры HTTP-подключения, используйте их: соединение с HTTPS-сайтом пойдет через туннель.

Выясните, откуда браузер получил настройки. Конфигурация, применяемая к профилю, может отличаться от параметров операционной системы. Еще один возможный источник – расширение. Системные настройки не гарантируют, что конкретное приложение выбрало именно их.

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

Как посмотреть ответ прокси через curl?

Укажите HTTP-прокси явно и включите диагностический вывод. Ниже – шаблон команды для Bash, а не результат нашего тестирования:

curl --verbose --proxy "http://PROXY_HOST:PROXY_PORT" --noproxy "" --proxy-user "USERNAME" "https://example.com/"

Перед запуском замените:

• PROXY_HOST и PROXY_PORT – на адрес и порт своего HTTP-прокси.
• USERNAME – на логин аккаунта. Пароль введите, когда curl его запросит.
• https://example.com/ – на адрес страницы, которая не открылась в Chrome.

Если способ доступа не предусматривает логин и пароль, удалите целиком пару —proxy-user «USERNAME».

Для диагностики здесь используются три параметра:

• —proxy задает адрес посредника.
• —verbose выводит сведения об обмене данными.
• —noproxy «» задает пустой список исключений для этого запроса, переопределяя исключения из окружения.

Описание параметров есть в руководстве curl, а ввод пароля по запросу объясняется в руководстве по HTTP-запросам. Запускайте шаблон в Bash либо адаптируйте кавычки под свою оболочку: пустое значение должно дойти до curl.

Найдите в журнале исходящий CONNECT и ответ на него. Условный пример запроса и требования аутентификации выглядит так – это не запись реальной проверки MangoProxy:

> CONNECT example.com:443 HTTP/1.1
< HTTP/1.1 407 Proxy Authentication Required

В первой строке указан адрес назначения, а не порт, на котором работает сам прокси. Во второй посредник запрашивает аутентификацию. Ответ 407 относится к созданию туннеля; сайт еще не вернул ответ на запрос страницы.

В своем журнале прочитайте и следующие сообщения. После 407 может идти еще одна попытка с аутентификацией. Ответ 200 Connection Established означает, что туннель открыт, но последующий обмен TLS или загрузка страницы все еще могут завершиться ошибкой. Запишите итог попытки, а перед передачей журнала удалите секретные данные.

Что проверять после ответа?

При 407 начните с аутентификации. Если CONNECT отклонен, уточните, разрешен ли доступ к указанному узлу и порту. Когда туннель уже принят, а сбой возникает на этапе TLS, разбирайте последующее сообщение. Эти ситуации требуют разных действий:

В изученной для статьи реализации HTTP/1.x в Chromium ветка обработки статусов принимает 200, а 407 передает обработчику аутентификации. Другие статусы в этой ветке приводят к ошибке туннеля. Это описание конкретного участка кода HTTP/1.x, а не общее правило для всех клиентов.

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

При отказе сохраните статус, адрес назначения и время. Ограничение CONNECT требует проверки соответствующего правила. Само по себе оно не доказывает, что сайт отклонил обычный запрос страницы: туннель еще не был создан.

Почему чекер показывает, что прокси работает?

Успешная проверка могла выполняться из другой сети или для другого адреса. Уточните ее условия, прежде чем считать статус «работает» объяснением сбоя в Chrome.

Публичный прокси-чекер MangoProxy предназначен для проверки статических прокси. Для резидентских страница предлагает воспользоваться инструментом в личном кабинете.

Сопоставьте неудачную попытку в браузере с запущенной командой. Совпадает ли URL в последнем аргументе? Одинаковы ли параметры сервера? Остальные условия удобно проверить по таблице:

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

Практические примеры: старый логин и отказ для порта

Оба случая ниже условные.

После обновления аккаунта остался прежний логин

В первом примере пользователь получил новые данные аккаунта, но не изменил логин в настройках браузера. Страница не открывается. Запрос через curl с тем же старым логином получает 407.

Расхождение обнаруживается при сравнении инструкции аккаунта с сохраненными параметрами. Пользователь обновляет логин и снова открывает тот же URL. Если страница загрузилась, в заметках фиксируются исправление и результат. Если нет – собирается новый диагностический вывод с актуальными данными. Адрес посредника во время этой проверки не меняется.

Порт 443 доступен, запрос к 8443 отклонен

Во втором примере сервис должен отвечать по двум адресам:

• https://service.example/
• https://service.example:8443/

Пользователь сохраняет прежние прокси, данные доступа и сеть. Первая страница загружается, а для второго адреса приходит отказ на CONNECT.

Имя узла в обоих URL одинаковое. Разница в том, что второй явно указывает порт назначения 8443 вместо стандартного 443. Порт подключения к самому посреднику остается прежним. Теперь поддержке можно задать конкретный вопрос: разрешено ли это назначение и доступен ли сервис на 8443 со стороны прокси? Ограничение – одна из возможных причин, которую еще нужно подтвердить.

Что отправить в поддержку?

Укажите адрес, который не открылся, полученный ответ и параметры, по которым можно найти попытку в журнале. Шаблон ниже продолжает условный пример с портом. Замените вымышленные значения и поля в скобках своими результатами:

Браузер и профиль: [версия и профиль, в котором возникла ошибка]
Время: [дата, время и часовой пояс]
Прокси: proxy.example:8080, HTTP
Доступ: логин и пароль; секретные данные не приложены

https://service.example/ – страница загрузилась
https://service.example:8443/ – ERR_TUNNEL_CONNECTION_FAILED

curl, тот же компьютер и сеть, второй URL:
> CONNECT service.example:8443 HTTP/1.1
< HTTP/1.1 403 Forbidden

Проверьте, пожалуйста, почему этот запрос CONNECT был отклонен,
разрешен ли указанный адрес назначения и доступен ли он
со стороны прокси-сервера.

В примере причина 403 остается открытой. Подставьте свой адрес назначения, время, параметры подключения и фактический ответ – это поможет найти нужную попытку. Пароли и заголовки авторизации в сообщение не включайте.

Термины

CONNECT – метод HTTP, который запрашивает туннель к указанному узлу и порту.

Endpoint – адрес и порт сервера, к которому клиент подключается для доступа к сервису.

Туннель – канал передачи данных, запрашиваемый при установлении соединения.

Аутентификация – проверка данных, которыми клиент подтверждает право доступа к прокси.

TLS – протокол защиты последующего соединения с HTTPS-сайтом.

Итоги

Сохраните URL с ошибкой вместе с ответом на запрос туннеля. Если обнаружено неверное значение в настройках, исправьте его и повторите проверку. Если причина отказа неясна, передайте данные в поддержку. После любого исправления откройте исходный адрес в том же профиле Chrome и запишите результат.

Часто задаваемые вопросы

Здесь мы ответили на самые часто задаваемые вопросы. Все равно не можешь найти ответа?

Задать вопрос

Это может быть блокировка со стороны сайта?

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

Поможет ли проверка другого сервера?

После проверки сохраненных параметров другой сервер может дать результат для сравнения. Оставьте прежние сайт и сеть. Если для замены нужен другой порт или логин, запишите эти изменения: они тоже могли повлиять на исход.

Стоит ли сначала удалить cookies?

Определение ошибки указывает на создание туннеля. Оно не дает оснований начинать с удаления cookies.

Почему в команде указано http://?

Этот префикс задает протокол подключения к посреднику. Отдельный HTTPS-URL обозначает сайт, к которому нужно обратиться через туннель. Для своего аккаунта используйте протокол из инструкции провайдера.

Что делать, если curl работает, а Chrome – нет?

Сравните активный профиль, источник конфигурации и данные доступа. Проверяйте один и тот же адрес в обоих клиентах.