Перейти до змістуЯк виправити помилки Proxy Authorization Failed у Chrome DevTools
«Proxy authorization failed» у Chrome DevTools — це не завжди та сама проблема, що й збій входу через проксі на рівні всього браузера. Запит може успішно виконуватися у звичайних вкладках і все одно падати в DevTools, бо шлях змінився через сеанс налагодження, прапорці запуску або тестовий раннер. Ця різниця важлива. Якщо ви намагаєтеся зрозуміти як виправити Proxy Authorization Failed у Chrome DevTools, почніть із того, щоб довести, де саме виникає збій, а не вгадувати пароль. Саме тому запит на кшталт proxy authorization failed Chrome DevTools варто розглядати як окремий сценарій, а не як звичайну помилку входу в браузері.
1. Переконайтеся, що помилка йде саме з DevTools, а не зі сторінки
Відкрийте DevTools, повторно запустіть запит і подивіться, чи помилка з’являється лише в панелі Network. Якщо сторінка відкривається у вкладці, але виклик fetch у DevTools не працює, це не схоже на звичайний збій сайту. Це проблема на шляху запиту, і часто це означає, що запит іде через проміжний проксі, налаштований для сеансу налагодження.
Перевірте, чи той самий URL не ламається поза DevTools під час звичайного відкриття в браузері. Якщо ні — зі сторінкою, ймовірно, усе гаразд. Під підозрою проксі. Якщо сторінка також не відкривається у звичайній вкладці, проблема може бути в облікових даних проксі, хості проксі або в політиці мережевого стеку. Один збій мало що каже; два збої вже підказують, де шукати.
Невелика, але корисна деталь: DevTools може показати запит, який взагалі не доходить до цільового сервера. У такому разі проксі відхиляє авторизацію ще до того, як upstream-сайт щось побачить. Це зовсім інша історія, ніж відповідь 4xx від самого цільового застосунку, і саме тут часто з’являється формулювання Chrome DevTools 407 proxy authorization failed.
2. Перевірте точні деталі запиту в панелі Network
Клацніть по помилковому рядку в панелі Network і перегляньте заголовки запиту, заголовки відповіді, код статусу та час виконання. Відмова проксі часто проявляється як 407, тоді як проблема на боці цільового сервера може виглядати як 401, 403 або щось дивніше. Число має значення. Не пропускайте його.
Подивіться і на графік часу. Якщо запит зависає до появи заголовків відповіді, проксі може чекати на облікові дані або відхиляти тунель ще до встановлення з’єднання з upstream. Якщо заголовки відповіді з’являються швидко, а потім виникає сторінка помилки, тоді, можливо, задіяний уже цільовий сервер. Такий поділ економить час.
Є ще одна корисна підказка: шлях запиту. Виклик fetch у DevTools до локального API, staging-хоста або websocket-ендпойнта може поводитися інакше, ніж звичайний запит навігації. Якщо проксі налаштований перехоплювати лише деякі напрямки, панель Network покаже цей шаблон уже після 2–3 повторів.
Для базових термінів на кшталт 407, upstream proxy і tunnel довідник глосарій VPN та проксі допоможе, коли формулювання в Chrome стають заплутаними. Тут назви мають значення. Вони змінюють спосіб виправлення.
3. Перевірте, чи проксі налаштований саме для сеансу налагодження Chrome
Chrome DevTools не завжди використовує той самий мережевий шлях, що й ваш щоденний сеанс браузера. Якщо Chrome запускали з прапорцем проксі, віддаленим профілем налагодження або змінною середовища, сеанс налагодження може успадкувати інший маршрут, ніж звичайний застосунок на робочому столі. На Windows, macOS і Linux така невідповідність трапляється достатньо часто, щоб перевірити її першою.
Почніть зі способу запуску. Chrome відкривали скриптом? Його запускали з --proxy-server? Тестовий раннер спрямовував DevTools на окрему директорію профілю? Для shell-сеансу, який відкрив Chrome, була встановлена змінна середовища? Будь-що з цього може спричинити помилку proxy authorization failed у DevTools, тоді як звичайне вікно браузера виглядає нормально.
Якщо ви працюєте з автоматизацією, порівняйте сеанс із налаштуванням браузера, описаним у гіді як обрати VPN. Сам контекст запуску може змінити шлях проксі буквально одним рядком коду. Одним рядком.
Для віддаленого налагодження профіль, відкритий на порті 9222, може мати власні правила проксі, кешований стан авторизації або корпоративну політику. Це означає, що вікно DevTools, під’єднане до такого профілю, може авторизовуватися через проксі, якого ваш звичайний екземпляр Chrome ніколи не торкається. Повторіть команду запуску. Потім порівняйте її з чистим локальним стартом.
4. Перевірте поведінку fetch/XHR у DevTools і будь-які перевизначені заголовки
DevTools може переглядати виклики fetch і XHR, але поруч можуть працювати інструменти, що змінюють їх. Власні заголовки запиту, перевизначені заголовки авторизації та експериментальні функції в DevTools можуть заважати узгодженню з проксі. Проксі очікує одного, а запит може надсилати інше.
Перевірте, чи десь у стеку не додано ручний заголовок Proxy-Authorization. Це стосується фрагмента в консолі, тестового хендлера, шару мокінгу запитів або розширення браузера, яке переписує заголовки. Якщо проксі очікує власний challenge-response процес, попередньо заповнений або некоректний заголовок може зламати все одразу.
Також стежте за перевизначеннями, пов’язаними з DevTools Protocol. Тестовий скрипт, що використовує CDP, може встановлювати заголовки для кожного запиту в сеансі. Це може допомогти в API-тесті, а потім зламати рукостискання з проксі на першому HTTPS-тунелі. Короткі запити іноді виявляють баг швидше, ніж довгі.
Одна практична хитрість: вимкніть власні перевизначення і повторно надішліть один запит із панелі Network. Якщо запит проходить, проксі був не єдиною змінною. Щось у шляху fetch/XHR у DevTools змінювало заголовки або час виконання.
5. Перевірте на мінімальному профілі без шару автоматизації
Розширення можуть переписувати запити, а автоматизація — обгортати запити Chrome DevTools своїм проксі-шаром. Через це помилку важко прочитати. Спрощуйте сеанс. Запустіть Chrome з мінімальним профілем, без додаткових розширень і без тестового раннера перед ним. Якщо помилка зникає, несправний шар — не сам проксі.
Service workers тут теж варто перевірити, бо вони можуть перехоплювати запити ще до того, як ті потраплять у мережевий стек. Застарілий worker може кешувати старий шлях, перенаправляти на інший хост або перетворювати простий fetch у ланцюжок редиректів, який проксі відхиляє. Особливо це дратує, коли запит працює один раз, а потім ламається на другому кліку.
Якщо ви використовуєте Playwright, Puppeteer, Selenium або іншу обгортку, повторіть той самий запит без шару автоматизації. Мета проста: довести, чи може сам DevTools виконати запит. Якщо ні, проксі — лише частина історії. Якщо так, обгортка стає наступним підозрюваним.
Для схем налаштування проксі, які добре поєднуються з автоматизацією, корисним доповненням буде стаття про автентифікований SOCKS5-проксі. SOCKS5 поводиться інакше, ніж HTTP-проксі, і цю різницю легко не помітити під час налагодження. Легко не помітити.
6. Порівняйте поведінку в інкогніто або в новому профілі Chrome
Режим інкогніто — не магічне рішення. Це просто вужчий тест. Відкрийте DevTools в інкогніто або створіть новий профіль Chrome і один раз повторіть той самий запит. Якщо помилка зникає, у вихідному профілі, ймовірно, є сесійна умова, що впливає на запити DevTools, наприклад розширення, політика або застарілий експеримент.
Тримайте тест вузьким. Не витрачайте 30 хвилин на очищення всього підряд. Завдання — порівняти поведінку DevTools, а не перебудувати браузер із нуля. Чистий профіль дає швидшу відповідь і зазвичай чистіший звіт про баг.
Якщо новий профіль усе одно не працює, проблема з проксі, ймовірно, не в user data. Тоді залишаються параметри запуску, мережева політика або сам проксі. Якщо працює, зафіксуйте різницю: один профіль працює, інший — ні. Таке формулювання корисніше для підтримки, ніж скріншот загальної помилки.
Люди часто питають, як узагалі може бути прив’язана до профілю проблема з проксі. Зазвичай причина одна з трьох: збережені дані сайту, які впливають на запити, розширення браузера, що чіпляється до заголовків, або кероване налаштування, яке діє лише для одного профілю. Усе це неефектно. Усе це реально.
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 це може виглядати так, ніби зламався початковий запит, хоча справжня проблема виникла на один хоп раніше.
Якщо проксі використовується для тестування сайтів, порівняйте цю поведінку з посібником із найкращих практик proxy authentication. Це не виправить поганий проксі, але може пояснити, чому метод або ціль обробляються інакше. Одне правило може змінити результат.
8. Зберіть зрозумілий для DevTools репрод для ескалації
Якщо помилка не зникає, зберіть репрод, яким справді може скористатися підтримка або інфраструктурна команда. Запишіть URL проблемного запиту, адресу проксі, версію Chrome, версію DevTools, точний текст помилки в Network або Console, а також те, чи запит ішов через fetch, XHR, навігацію сторінки або websocket. Ці шість деталей економлять години.
Збережіть HAR-файл, якщо команда його приймає. Додайте скріншот лише тоді, коли на ньому видно список запитів, код статусу й панель часу в одному вікні. Розмита лінія в консолі — цього недостатньо. Команді підтримки потрібна послідовність, а не здогадка.
Запишіть і команду запуску. Якщо Chrome стартував із прапорцем проксі, портом remote debug, директорією user-data або тестовим раннером, наведіть точний синтаксис. Один пропущений прапорець може відправити людину хибним шляхом на пів дня. Було.
Передаючи кейс, зазначте, чи DevTools самостійно відтворює збій, чи щось змінює інкогніто, і чи проксі відхиляє конкретний метод або ціль. Саме ця остання деталь часто визначає, де має бути виправлення: у Chrome, у проксі чи в застосунку за ним. Остання підказка зазвичай найпростіша.