Ошибки прокси в Chrome: что означает каждый код и чем −111 отличается от −130

Главная пара: −130 против −111

Названия похожи, стадии разные, и лечение тоже. ERR_PROXY_CONNECTION_FAILED значит, что до прокси вообще не дошли: комментарий в исходнике описывает это как ошибку при разрешении имени или при открытии сокета — и отдельно оговаривает, что сюда не входят сбои во время самого метода CONNECT.

ERR_TUNNEL_CONNECTION_FAILED — обратный случай: прокси доступен, соединение с ним установлено, но туннель через CONNECT не поднялся. В исходниках все места, где возвращается этот код, находятся уже после успешного подключения к прокси: неверная строка статуса, посторонние данные после заголовков, любой ответ на CONNECT кроме 200 и 407.

Таблица

Значения сверены с net_error_list.h в основной ветке Chromium. Привязывать их к версии браузера не нужно и не стоит: файл живёт своей жизнью, коды из него удаляются и добавляются, поэтому здесь указана дата сверки, а не номер версии.

# Сверено с net_error_list.h в main, 17 августа 2026.
# Все значения отрицательные — «ошибка 130» не существует.
#
# ВИДНО НА СТРАНИЦЕ ОШИБКИ
  ERR_PROXY_CONNECTION_FAILED        -130   до прокси не дошли: не разрешилось
                                            имя или не открылся сокет
  ERR_TUNNEL_CONNECTION_FAILED       -111   прокси ответил, но туннель не встал
  ERR_PROXY_CERTIFICATE_INVALID      -136   сертификат HTTPS-прокси невалиден
  ERR_PROXY_AUTH_UNSUPPORTED         -115   прокси предложил схему авторизации,
                                            которой Chrome не умеет
  ERR_UNEXPECTED_PROXY_AUTH          -323   пришёл 407, хотя запрос шёл не через
                                            прокси
  ERR_MANDATORY_PROXY_CONFIGURATION_FAILED
                                     -131   обязательный PAC не скачался,
                                            не разобрался или не выполнился
  ERR_EMPTY_RESPONSE                 -324   соединение закрыли, не прислав данных
  ERR_CONNECTION_REFUSED             -102
  ERR_CONNECTION_RESET               -101
  ERR_CONNECTION_TIMED_OUT           -118
  ERR_NAME_NOT_RESOLVED              -105
#
# НЕ ДОХОДИТ ДО СТРАНИЦЫ
  ERR_PROXY_AUTH_REQUESTED           -127   перехватывается и превращается
                                            в окно ввода логина и пароля
  ERR_NO_SUPPORTED_PROXIES           -336   внутренний; комментарии в исходниках
                                            прямо говорят, что он не для глаз

На странице видно имя, а не номер

Chrome печатает на странице ошибки символьное имя в форме ERR_ЧТО_ТО, а номер не показывает. Поэтому искать по номеру бесполезно, а вставлять в поиск нужно имя — что люди и делают. Номера полезны в другом: они не меняются вместе с формулировками и годятся как якорь при чтении логов.

Ещё деталь: у ERR_PROXY_CONNECTION_FAILED своя страница с заголовком про отсутствие интернета и подсказкой, что с прокси-сервером что-то не так или адрес неверен. А у ERR_TUNNEL_CONNECTION_FAILED отдельной страницы нет — он попадает на общий экран «Не удаётся получить доступ к сайту». Отсутствие внятного текста здесь не значит, что ошибка менее конкретна.

Два кода, которых вы не увидите

ERR_PROXY_AUTH_REQUESTED до страницы не доходит: он перехватывается и заменяется на запрос учётных данных, то есть пользователь видит окно ввода логина и пароля. Любопытная деталь — если это окно закрыть, запрос завершится как ERR_TUNNEL_CONNECTION_FAILED. То есть часть жалоб на −111 это просто отменённый ввод пароля.

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

Что Chrome делает при отказе прокси

Здесь стоит развеять популярное заблуждение. Chrome не уходит молча напрямую, когда прокси отказал: при единственном настроенном прокси все запросы просто падают с ERR_PROXY_CONNECTION_FAILED. Переход на прямое соединение происходит, только если DIRECT явно указан в списке прокси — тогда это очередной элемент списка, а не выдуманный запасной путь.

Переключение на следующий прокси вызывают только отказы уровня соединения: не разрешилось имя прокси, не установился TCP-сокет. Неудачная попытка построить туннель к таким отказам не относится — раньше относилась, но поведение изменили, потому что оно ломало конфигурации, где прокси намеренно отклоняет часть запросов.

Единственный случай молчаливого прямого соединения

Он есть, но не там, где его ищут. Если используется PAC-скрипт и его не удалось скачать, разрешение прокси молча откатывается на прямое соединение. Исключение — когда PAC помечен как обязательный: тогда запросы падают с ERR_MANDATORY_PROXY_CONFIGURATION_FAILED. Так что если трафик неожиданно пошёл мимо прокси, смотреть надо на PAC, а не на сам прокси.