Почему системный прокси Windows работает не во всех программах

Системный прокси это подсказка, а не правило

Когда системный прокси Windows не работает в какой-то программе, чаще всего виновата не опечатка в адресе, а то, как эта настройка устроена. Адрес и порт, которые ты вводишь в «Параметрах» (раздел «Сеть и Интернет», пункт «Прокси-сервер»), сохраняются в настройках текущего пользователя. Windows не заставляет программы ими пользоваться. Это запись, которую приложение может прочитать через системную библиотеку WinINET и учесть, а может проигнорировать. Принудительного маршрута не появляется: пакеты программы, которая не спросила о прокси, уходят напрямую.

Поэтому один и тот же прокси на одном компьютере одновременно «работает» в браузере и «не работает» в мессенджере, лаунчере или скрипте. Разница не в прокси, а в том, какие программы согласились читать системную настройку. Системный прокси похож на табличку «вход через соседний подъезд»: вежливые программы ей следуют, остальные идут прямой дорогой, и формально никто ничего не нарушает.

Кто читает системные настройки, а кто нет

Браузеры на Chromium (Chrome, Edge, Яндекс Браузер) по умолчанию берут прокси из системы. Firefox тоже умеет использовать системные параметры, но у него есть своя вкладка с настройками сети, и если там выбран другой вариант, системный прокси для него не существует.

Дальше картина пёстрая. У многих программ свой сетевой код, который настройки WinINET просто не запрашивает. Консольные утилиты вроде curl ориентируются на переменные окружения HTTP_PROXY и HTTPS_PROXY. Приложения на Java используют собственные параметры запуска. Службы Windows работают от системной учётной записи, и настройки твоего пользователя к ним не относятся. Есть и отдельная системная настройка WinHTTP, которой пользуются некоторые служебные компоненты: её показывает команда netsh winhttp show proxy, и она может не совпадать с тем, что ты видишь в «Параметрах».

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

Скрипты и консольные утилиты живут по своим правилам

Отдельная категория это всё, что запускается из командной строки: curl, wget, git, менеджеры пакетов, скрипты на Python и Node.js. Большинство из них смотрит на переменные окружения HTTP_PROXY, HTTPS_PROXY и NO_PROXY или на собственные файлы конфигурации. Переменные задаются для текущего окна терминала командой set или в свойствах системы для всех новых процессов. Если ты поменял прокси в «Параметрах», а скрипт продолжает ходить напрямую, это ожидаемо: он о той настройке ничего не знает.

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

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

Окно настройки прокси в Windows рассчитано на простой случай: адрес и порт HTTP-прокси. Поля для логина и пароля там нет. Если прокси требует авторизацию, браузер покажет своё окно ввода пароля, а программа без такого окна получит от прокси ответ 407 и молча не подключится. Покупные прокси очень часто выдаются именно с логином и паролем, так что ситуация встречается постоянно.

С SOCKS5 ещё сложнее. Переключателя «это SOCKS5» в интерфейсе нет, и даже программы, которые читают системные настройки, ожидают там HTTP-прокси. В итоге SOCKS5 с логином и паролем через штатные средства Windows для произвольной программы фактически не настраивается. Если у тебя именно такой прокси, системная настройка почти наверняка не подойдёт, и решать задачу придётся внутри программы или снаружи, на уровне сети.

Исключения, PAC-скрипты и автоопределение

Даже в браузере системный прокси может срабатывать не для всех адресов. В тех же параметрах есть список исключений, для которых прокси не используется, и флажок «Не использовать прокси-сервер для локальных адресов». Если туда попал нужный домен, браузер пойдёт к нему напрямую. Кроме ручной настройки, есть сценарий настройки (PAC-файл) и автоматическое определение параметров. Сценарий решает для каждого адреса отдельно, идти через прокси или нет, и может отправлять разные сайты через разные серверы.

В корпоративной сети эти параметры нередко задаются групповой политикой, и тогда ручные изменения перезаписываются при следующем входе в систему. Если прокси «сам отключается» после перезагрузки, первым делом проверь, не управляется ли настройка организацией или программой, которая берёт сеть под свой контроль, например VPN-клиентом. Ещё один источник путаницы: расширения браузера для работы с прокси. Они берут управление сетевыми настройками внутри браузера и могут отправлять его трафик совсем не туда, куда указывает Windows. На время проверки такие расширения лучше отключить.

Как найти причину за несколько минут

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

• Открой в браузере сайт проверки IP: если адрес не сменился, проблема в прокси или в исключениях, а не в программе.
• Посмотри, нет ли у программы своего поля для прокси: собственные параметры приложения обычно важнее системных.
• Выполни в командной строке netsh winhttp show proxy и сравни результат с параметрами Windows.
• Если прокси с авторизацией, проверь, умеет ли программа спрашивать логин и пароль.
• Уточни протокол: SOCKS5 через системную настройку обычно не заработает.
• Перезапусти программу после изменения настроек: многие читают параметры прокси только при старте.
• Помни, что звонки и игры используют UDP, а HTTP-прокси с UDP не работает в принципе.

Когда проще перехватывать трафик на уровне сети

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

ProxyBridge устроен именно так. На вкладке «Главная» ты решаешь, какие программы через какой прокси идут: если у строки «Все остальные программы» выбран прокси, после нажатия «Подключить» через него идёт весь TCP-трафик компьютера. Если добавить программы кнопкой «Добавить программу», а остальным оставить «Напрямую», прокси получат только они (такой режим ещё называют split tunneling). Поддерживаются HTTP и SOCKS5 с логином и паролем, то есть ровно те случаи, где системная настройка сдаётся. UDP идёт через прокси, если это SOCKS5 с поддержкой UDP, иначе блокируется, чтобы не утекал IP; DNS-запросы по умолчанию тоже идут через прокси. Зато с VPN-клиентами вроде WireGuard и AmneziaWG программа работает вместе, выключать их не нужно.

Читайте также