Перейти к содержимомуКак исправить ошибки Proxy Authorization Failed в Chrome DevTools
«Proxy authorization failed» в Chrome DevTools не всегда означает ту же проблему, что и сбой входа в прокси во всём браузере. Запрос может нормально работать в обычных вкладках и при этом ломаться внутри DevTools, потому что путь изменился из-за отладочной сессии, флагов запуска или тестового раннера. Это важно. Если вы пытаетесь понять, как исправить proxy authorization failed в Chrome и разобраться, почему возникает ошибка proxy authorization failed в Chrome DevTools, начните с того, чтобы точно определить, где возникает сбой, а не гадать о пароле.
1. Убедитесь, что ошибка идёт из DevTools, а не со стороны страницы
Откройте DevTools, повторно вызовите запрос и посмотрите, появляется ли сбой только в панели Network. Если страница загружается во вкладке, а fetch-вызов внутри DevTools падает, это не обычная недоступность сайта. Это проблема пути запроса, и часто она означает, что запрос проходит через промежуточный прокси, настроенный для отладочной сессии.
Проверьте, падает ли тот же URL вне DevTools при обычном открытии в браузере. Если нет, скорее всего, со страницей всё в порядке. Под подозрением прокси. Если страница не открывается и в обычной вкладке, проблема может быть в учётных данных прокси, хосте прокси или политике сетевого стека. Один сбой мало что говорит; два сбоя уже показывают, где искать.
Небольшая, но полезная деталь: DevTools может показывать запрос, который вообще не доходит до целевого сервера. В таком случае прокси отклоняет авторизацию ещё до того, как upstream-сайт что-то увидит. Это уже совсем другая история, чем ответ 4xx, пришедший от целевого приложения.
2. Проверьте точные детали запроса в панели Network
Нажмите на проблемную строку в панели Network и изучите заголовки запроса, заголовки ответа, статус-код и тайминги. Отказ прокси часто проявляется как 407, тогда как проблема на стороне целевого сервера может давать 401, 403 или что-то более необычное. Цифра имеет значение. Не пропускайте её.
Посмотрите и на тайминги. Если запрос зависает до появления заголовков ответа, возможно, прокси ждёт учётные данные или отклоняет туннель ещё до формирования соединения с upstream. Если заголовки ответа появляются быстро, а затем возникает страница ошибки, вероятнее всего, участвует уже целевой сервер. Такое разделение экономит время.
Есть ещё одна полезная подсказка: путь запроса. Fetch из DevTools к локальному API, staging-хосту или websocket-эндпоинту может вести себя иначе, чем обычная навигация. Если прокси настроен перехватывать только некоторые назначения, панель Network покажет закономерность уже за 2–3 повторных попытки. Именно так часто проявляется Chrome DevTools 407 proxy authorization failed.
Если нужны базовые термины вроде 407, upstream proxy и tunnel, загляните в глоссарий VPN и прокси — иногда в Chrome формулировки сбивают с толку. Здесь названия важны. От них зависит исправление.
3. Проверьте, что прокси настроен именно для отладочной сессии Chrome
Chrome DevTools не всегда использует тот же сетевой путь, что и обычная сессия браузера. Если Chrome запускался с флагом прокси, удалённым профилем отладки или переменной окружения, отладочная сессия может унаследовать другой маршрут, чем обычное окно. На Windows, macOS и Linux такое расхождение встречается достаточно часто, чтобы проверять его в первую очередь.
Начните со способа запуска. Chrome был открыт скриптом? Запускался с --proxy-server? Тестовый раннер указывал DevTools на отдельную папку профиля? Для shell-сессии, из которой запускался Chrome, была задана переменная окружения? Любой из этих факторов может вызвать ошибка proxy authorization failed в Chrome DevTools, хотя обычное окно браузера выглядит нормально.
Если вы работаете с автоматизацией, сравните с настройками браузера, описанными в руководстве как выбрать VPN. Конкретный контекст запуска может изменить путь прокси буквально одной строкой кода. Одной строкой.
При удалённой отладке профиль, открытый на порту 9222, может иметь собственные правила прокси, кэшированное состояние авторизации или корпоративную политику. Из-за этого окно DevTools, подключённое к такому профилю, может проходить авторизацию через прокси, которого ваш обычный Chrome вообще не касается. Повторите команду запуска. Затем сравните её с чистым локальным запуском.
4. Проверьте поведение fetch/XHR в DevTools и любые переопределённые заголовки
DevTools умеет инспектировать вызовы fetch и XHR, но рядом с ним могут работать инструменты, которые меняют эти запросы. Пользовательские заголовки, переопределённые заголовки авторизации и экспериментальные функции в DevTools могут мешать согласованию с прокси. Прокси ожидает одно, а запрос отправляет другое.
Проверьте, не добавлялся ли где-то в стеке ручной заголовок Proxy-Authorization. Это может быть сниппет в консоли, тестовый каркас, слой мокирования запросов или расширение браузера, которое переписывает заголовки. Если прокси ожидает собственный challenge-response сценарий, заранее заполненный или некорректный заголовок может сломать всё сразу.
Следите и за переопределениями, связанными с DevTools Protocol. Тестовый скрипт, использующий CDP, может задавать заголовки для всех запросов в сессии. Это помогает в API-тесте, а затем ломает handshake с прокси на первом HTTPS-туннеле. Короткие запросы иногда выявляют баг быстрее длинных.
Один практический приём: отключите пользовательские переопределения и повторно выполните один запрос из панели Network. Если запрос проходит, значит, прокси был не единственной переменной. Что-то в цепочке fetch/XHR в DevTools меняло заголовки или тайминг.
5. Проверьте на минимальном профиле и без слоя автоматизации
Расширения могут переписывать запросы, а автоматизация — оборачивать запросы Chrome DevTools в свой прокси-слой. Из-за этого сбой сложно прочитать. Упростите сессию. Запустите Chrome с минимальным профилем, без лишних расширений и без тестового раннера поверх него. Если ошибка исчезает, значит, проблема не в самом прокси.
Здесь стоит проверить service worker, потому что он может перехватывать запросы ещё до попадания в сетевой стек. Устаревший worker может кэшировать старый путь, перенаправлять на другой хост или превращать простой fetch в цепочку редиректов, которую прокси отказывается обслуживать. Особенно раздражает, когда запрос срабатывает один раз, а потом падает при втором клике.
Если вы используете Playwright, Puppeteer, Selenium или другой обёрточный инструмент, повторите тот же запрос без слоя автоматизации. Цель простая: доказать, может ли DevTools отправить запрос сам по себе. Если нет, прокси — лишь часть картины. Если да, следующим подозреваемым становится обёртка.
Для схем настройки прокси, которые хорошо сочетаются с автоматизацией, полезно почитать статью про авторизованный SOCKS5-прокси. SOCKS5 ведёт себя иначе, чем HTTP-прокси, и во время отладки эту разницу легко упустить. Очень легко.
6. Сравните поведение в инкогнито или в новом профиле Chrome
Инкогнито — не волшебное решение. Это более узкий тест. Откройте DevTools в инкогнито или создайте новый профиль Chrome и выполните тот же запрос один раз. Если ошибка исчезла, в исходном профиле, скорее всего, есть состояние, завязанное на сессию, которое влияет на запросы DevTools: расширение, политика или устаревший эксперимент.
Держите тест максимально узким. Не тратьте 30 минут на очистку всего подряд. Смысл в сравнении поведения DevTools, а не в том, чтобы пересобрать браузер с нуля. Чистый профиль быстрее даёт ответ и обычно позволяет сформировать более понятный баг-репорт.
Если новый профиль всё равно ломается, проблема, вероятно, находится вне пользовательских данных. Тогда остаются настройки запуска, сетевая политика или сам прокси. Если всё работает, зафиксируйте разницу: один профиль работает, другой — нет. Для поддержки это гораздо полезнее, чем скриншот общего сообщения об ошибке.
Часто спрашивают, как прокси-проблема вообще может зависеть от профиля. Обычно причина одна из трёх: сохранённые данные сайта, расширение браузера, которое трогает заголовки, или управляемая настройка, действующая только для одного профиля. Ничего эффектного. Всё вполне реально.
7. Убедитесь, что прокси принимает метод запроса и целевой URL
Некоторые прокси принимают обычную навигацию, но отклоняют конкретные HTTP-методы, которые использует DevTools, особенно PATCH, DELETE или preflight-запросы OPTIONS. Другие разрешают стандартный HTTPS-браузинг, но блокируют localhost, внутренние IP или websocket-соединения, используемые во время живой отладки. Из-за этого ошибка может казаться случайной. Но она не случайна.
Проверьте, идёт ли запрос на localhost, в приватную подсеть или на websocket-эндпоинт. Для таких маршрутов прокси может применять другие правила, чем для публичных сайтов. Туннель, который работает для https://example.com, может сразу ломаться для ws://127.0.0.1:9222 или staging-хоста на порту 8443.
Важен и метод. Прокси, который разрешает GET, всё равно может отклонить preflight OPTIONS, если не хватает авторизации или маршрут заблокирован политикой. В DevTools это может выглядеть так, будто сломался исходный запрос, хотя настоящая проблема началась на один шаг раньше.
Если прокси используется для тестирования сайтов, сравните поведение с руководством по best practices для proxy authentication. Оно не починит плохой прокси, но поможет понять, почему метод или цель обрабатываются иначе. Одно правило может изменить результат.
8. Соберите воспроизводимый сценарий для эскалации, удобный для DevTools
Если ошибка всё ещё не ушла, соберите набор данных, который действительно можно передать в поддержку или инфраструктурную команду. Запишите URL проблемного запроса, адрес прокси, версию Chrome, версию DevTools, точный текст ошибки в Network или Console, а также то, был ли запрос сделан через fetch, XHR, навигацию страницы или websocket. Эти шесть деталей экономят часы.
Если команда принимает HAR-файлы, сохраните HAR. Скриншот добавляйте только если на нём одновременно видны список запросов, статус-код и панель таймингов. Размытая строка в консоли — это недостаточно. Поддержке нужна последовательность, а не догадка.
Также запишите команду запуска. Если Chrome был запущен с флагом прокси, удалённым портом отладки, каталогом user-data или через тестовый раннер, укажите точный синтаксис. Один потерянный флаг может увести человека в тупик на полдня. Проверено.
Передавая кейс дальше, укажите, воспроизводится ли сбой только в DevTools, меняет ли что-то инкогнито и отклоняет ли прокси конкретный метод или цель. Эта последняя деталь часто и решает, где именно находится исправление: в Chrome, в прокси или в приложении за ним. Финальная подсказка обычно самая простая.