Прокси для профиля: DNS, аутентификация и поведение при сбоях

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

Начните с четырёх независимых вопросов

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

1. Охват: какие запросы и протоколы браузера направляются через этот прокси?
2. Разрешение имён: устройство или прокси определяет адрес целевого узла?
3. Аутентификация: какие схемы клиента и прокси совместимы и где хранятся секреты?
4. Сбой: ошибка останавливает запрос, переключает на другой прокси или разрешает прямой маршрут?

Объединение всего в один переключатель «прокси включён» создаёт большинство неожиданностей. Chromium описывает выбор как разрешение маршрута на уровне URL: URL даёт упорядоченный список вариантов прокси ещё до обязательного определения адреса назначения. Исключения и запасные маршруты входят в это решение.

Что охватывает прокси профиля

Политика ProxySettings применяется на уровне профиля Chrome. Она выбирает прямой, системный, автоматически обнаруженный, фиксированный или PAC-режим, с отдельными полями исключений и обязательности PAC.

Граница уже, чем у VPN или сетевого пространства имён ОС. Она управляет запросами сетевого контекста браузера, но автоматически не охватывает:

• API-вызовы самого настольного менеджера;
• отдельный процесс обновления приложения или браузера;
• системные проверки DNS и соединения;
• приложение, запущенное из скачанного файла;
• отдельный нативный помощник расширения;
• локальные службы, доступные через неявные исключения loopback;
• протоколы, которые выбранный прокси-маршрут не переносит.

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

Проследим один HTTPS-запрос

Обычный переход по HTTPS проходит несколько этапов.

1. Выбор маршрута

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

Chromium также применяет неявные исключения для localhost и локальных адресов канала. Это защищает локальные origin от внешне управляемых настроек прокси, но требует уточнений к широкому выражению «весь трафик».

2. Поиск адреса и соединение с прокси

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

3. Аутентификация на прокси

HTTP-прокси, требующий учётные данные, обычно отвечает 407 Proxy Authentication Required с запросом аутентификации. RFC 9110 определяет этот обмен и поля Proxy-Authenticate и Proxy-Authorization.

Chromium не использует имя и пароль, встроенные в ручную настройку прокси. Документация указывает обычный браузерный процесс учётных данных. Поэтому менеджеру нужна явная интеграция с поддерживаемым запросом аутентификации, а не обещание работы любой строки user:password@host.

4. Соединение с назначением

При HTTP-прокси Chromium передаёт разрешение имени назначения прокси. Для HTTPS браузер запрашивает туннель CONNECT, затем устанавливает сквозной TLS с целевым узлом через этот туннель.

Прокси всё равно узнаёт имя назначения и метаданные соединения. Если участок клиент — прокси использует обычный HTTP, запрос CONNECT и имя на этом участке не защищены. HTTPS-прокси добавляет TLS между браузером и прокси, скрывая метаданные от наблюдателей между ними. Сам прокси по-прежнему видит запрошенное назначение.

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

Обработка DNS зависит от схемы прокси

Документированное поведение Chromium различается:

Маршрут	Где разрешается имя назначения	Важное ограничение
Прямой или исключение	Резолвер устройства или браузера	Трафик идёт без прокси профиля
HTTP-прокси	На прокси	Незащищённый участок клиент — прокси раскрывает HTTP-запросы; HTTPS использует CONNECT
HTTPS-прокси	На прокси	Клиент должен проверить TLS-сертификат прокси
SOCKS4	На клиенте	Только IPv4; Chromium не реализует переход к SOCKS4a
SOCKS5	На прокси	Chromium использует его для TCP-запросов URL и документирует отсутствие аутентификации SOCKS5

RFC 1928 допускает доменное имя в запросе SOCKS5 и определяет несколько методов аутентификации. Возможность протокола не гарантирует реализацию клиента. Chromium передаёт имена назначения SOCKS5-прокси, но указывает, что встроенный клиент не поддерживает методы аутентификации прокси. Доступ SOCKS5 с именем и паролем поэтому может требовать поддерживаемого посредника или другой схемы. Подтвердите реализацию до принятия настройки.

DNS-over-HTTPS добавляет ещё один уровень. Политика DnsOverHttpsMode различает automatic, допускающий переход к незащищённому DNS, и secure, при котором сбой защищённого DNS завершает разрешение ошибкой. Политика документирована на уровне браузера, а ProxySettings — профиля. Это полезное предупреждение: слово «профиль» в одной настройке не переносит её область на все настройки DNS.

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

• разрешение имени самого прокси;
• разрешение имени назначения;
• DNS прямых запросов и исключений;
• начальное подключение защищённого DNS и запасные пути;
• DNS компонентов вне сетевого контекста профиля.

Аутентификация: совместимость и защита секретов

Chromium документирует Basic, Digest, Negotiate и NTLM для HTTP-прокси. HTTPS-прокси добавляет защищённый участок до прокси и может поддерживать клиентские сертификаты. Аутентификация SOCKS4 и SOCKS5 не реализована встроенным клиентом Chromium, хотя методы существуют в спецификации SOCKS5.

Даже совместимая схема может быть небезопасна при неверном транспорте. RFC 7617 объясняет, что данные Basic лишь кодируются Base64 и требуют защищённого канала, например TLS. Basic через обычный HTTP-прокси раскрывает пароль тому, кто наблюдает этот участок.

Менеджер должен разделять:

• несекретные метаданные: схему, узел, порт и метку провайдера;
• ссылку на секрет для службы жизненного цикла или сети;
• значение учётных данных в защищённом хранилище;
• состояние соединения без секретов для интерфейса и аудита;
• подробную диагностику только для управляемого процесса поддержки.

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

Сбои и их признаки

Сбой	Вероятный симптом	Что проверить
Неверная схема	Ошибка TLS или согласования протокола	Не указан ли HTTPS-адрес как HTTP или наоборот?
Имя прокси не разрешается	Ошибка до соединения с прокси	Какой резолвер выполнял начальный запрос?
Порт недоступен	Тайм-аут или отказ соединения	Есть ли дальше другой прокси или DIRECT?
Неподдерживаемая аутентификация	Повторяющийся 407 или запрос входа	Реализует ли браузер запрошенную схему?
Неверные или истёкшие данные	407 после отправки данных	Получен ли секрет по ссылке и скрыт ли он из вывода?
Ошибка сертификата HTTPS-прокси	Защищённое соединение отклонено	Сохраняется ли проверка сертификата?
Прокси не разрешает назначение	Ошибка узла или туннеля	Не повторил ли клиент запрос напрямую?
CONNECT запрещён	HTTPS-переход к назначению не работает	Считается ли отказ политикой, а не разрешением обхода?
PAC недоступен	Задержка выбора или смена маршрута	Обязателен ли PAC или возможен скрытый DIRECT?
Слишком широкое исключение	Часть сайтов соединяется напрямую	Понятны ли правила узлов, поддоменов, портов и неявные исключения?
WebRTC использует другой интерфейс	Медиа идёт иначе, чем страница	Отключён ли UDP вне прокси?
Старое соединение пережило изменение	Прежний маршрут временно сохраняется	Закрываются ли соединения или перезапускается профиль?
Избыточная диагностика	URL, имена или секреты попадают в файл поддержки	Каковы режим сокрытия и срок хранения?

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

Особенно важен сбой PAC. Chromium документирует возможность незаметно перейти к прямому маршруту при недоступном PAC, если он не помечен обязательным. Поле ProxyPacMandatory в ProxySettings предназначено именно для предотвращения такого перехода.

Для WebRTC и UDP нужно отдельное решение

Страница может использовать WebRTC-маршруты, не равнозначные обычным HTTP- и HTTPS-запросам. Стандартная политика WebRtcIPHandling может использовать все доступные интерфейсы. Режим disable_non_proxied_udp ограничивает WebRTC TCP на публичном интерфейсе, если настроенный прокси не поддерживает UDP.

Это политика уровня профиля, но отдельная мера. Она может ухудшить медиасвязь или нарушить процесс, которому нужен прямой UDP. Явно выберите и проверьте компромисс. Успешная загрузка страницы не подтверждает полное удержание трафика в прокси.

Выберите поведение при отказе

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

Хорошая политика явно называет вариант:

• Обязательный прокси: остановить затронутые запросы, если маршрут недоступен.
• Разрешённый набор прокси: пробовать только указанные альтернативы с равнозначной политикой.
• Прямой маршрут разрешён: показать смену и записать событие без секретов.
• Явное исключение: описать класс назначений и причину прямого доступа.

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

Безопасная матрица проверки

Используйте адреса и DNS-зоны, которыми владеете или которые разрешено наблюдать. До запуска запишите ожидаемые результаты.

1. Сопоставьте заявленную схему с реальным транспортом адреса.
2. Проверьте HTTP, HTTPS, WebSocket и нужный WebRTC.
3. Наблюдайте адрес выхода на подконтрольном назначении.
4. Определите резолвер назначения и резолвер имени прокси.
5. Сделайте тестовые учётные данные просроченными и убедитесь, что исходное значение не появляется в интерфейсе, журналах и выводе автоматизации.
6. Отключите тестовый прокси и подтвердите заданную блокировку либо запасной маршрут.
7. Запретите одно подконтрольное назначение CONNECT и убедитесь, что отказ не превращается в прямой доступ.
8. Сделайте тестовый PAC недоступным и проверьте обязательный режим.
9. Проверьте нужные исключения точного узла, поддомена, локальных адресов, адресов канала, IPv4 и IPv6.
10. Измените прокси при активных соединениях и выясните момент вступления нового маршрута в силу.
11. Соберите только нужную диагностику, затем проверьте хранение и удаление.

Рекомендации Chromium NetLog рассматривают сетевые журналы как вопрос приватности и безопасности. Режимы с сокрытием могут исключать чувствительные поля, а подробные — включать cookies и заголовки аутентификации. Обращайтесь с файлом поддержки по его фактическому режиму записи, а не по названию.