Как настроить прокси в Windows 11 на уровне системы: «Параметры», реестр, netsh

Раздел 2.1 · Система и браузеры

1. Что понадобится

Подойдёт любая сборка Windows 11, включая LTSC и версии без Microsoft Store. Ничего доустанавливать не нужно: и графическая страница настроек, и netsh, и reg входят в систему.

Нужна строка подключения. Провайдеры отдают её в двух видах: IP:PORT и IP:PORT:LOGIN:PASS. Первый вид означает авторизацию по привязанному адресу, второй по паре логин и пароль. Все примеры ниже я пишу на адресе 203.0.113.10 и порте 8080, подставляйте свои значения без изменения структуры строк. Я держу рабочие машины на пуле, где список выдаётся ссылкой или файлом сразу в обоих форматах, и системная страница Windows принимает такую строку без переделки; это приватные серверные адреса под системную настройку, с двумя привязками в пакете и сменой привязки в кабинете.

Права администратора понадобятся на двух шагах: команда netsh winhttp и правка ветки HKLM. Пользовательская часть настройки, страница «Параметры» и ветка HKCU, работает из обычной учётной записи.

Определитесь заранее, какой протокол вы вносите. Порт HTTP-посредника обслуживает и обычные запросы, и туннель CONNECT для HTTPS, поэтому в графическом окне одна пара полей закрывает оба случая. Порт SOCKS5 системная страница «Параметры» не принимает вовсе, для него понадобится либо запись в реестре с префиксом socks=, либо отдельная программа. Я обычно завожу на машине оба доступа: HTTP для системной настройки и браузеров, SOCKS5 для программ, которые умеют его напрямую.

2. Параметры сети в приложении «Параметры» поле за полем

Откройте «Параметры», раздел «Сеть и Интернет», пункт «Прокси-сервер». Быстрее набрать ms-settings:network-proxy в окне «Выполнить». Страница делится на два блока: «Автоматическая настройка прокси-сервера» сверху и «Настройка прокси-сервера вручную» снизу. Нам нужен нижний.

Нажмите «Изменить» напротив пункта «Использовать прокси-сервер». Откроется окно «Изменение прокси-сервера» с четырьмя управляющими элементами.

Схему в поле адреса Windows не ждёт. Если вы вставили строку целиком и нажали «Сохранить», система запишет в реестр значение http://203.0.113.10:8080:8080, браузер выдаст отказ на первом же запросе, а окно настроек покажет всё как заполненное. Я проверяю поле глазами перед сохранением: адрес без схемы, порт отдельным числом.

Кнопка «Сохранить» применяет запись мгновенно, перезагрузка не нужна. Уже открытые вкладки Edge и Chrome подхватят её на следующем запросе. Программы на .NET и старые клиенты на WinINET читают настройку при создании соединения, поэтому их достаточно перезапустить.

Одна пара полей закрывает весь веб-трафик машины, потому что порт HTTP-посредника принимает и обычные запросы, и метод CONNECT, которым браузер строит туннель к сайту по HTTPS. Отсюда простое правило подбора доступа под системную страницу: берите порт, у которого оба режима разрешены на стороне поставщика, иначе обычные сайты откроются, а всё с замком в адресной строке начнёт отваливаться. Я проверяю это одним запросом сразу после ввода полей. Именно под такой сценарий подходят HTTP-прокси с выдачей списка файлом: порт один, строка короткая, поля Windows заполняются копированием без ручной разборки.

Значение из окна применяется только к текущей учётной записи Windows. Вторая учётка на той же машине увидит прямые соединения, и это ожидаемое поведение: страница «Параметры» правит пользовательский профиль. Для машины целиком понадобится раздел про WinHTTP ниже.

Верхний блок страницы трогать пока не надо. Переключатель «Автоматически определять параметры» отвечает за WPAD, поиск файла автонастройки по DNS и DHCP. Он включён по умолчанию и в домашней сети просто добавляет задержку к первому запросу. Когда ручной адрес внесён, я этот переключатель выключаю: так первый запрос уходит сразу.

3. Логин, пароль и где Windows их запоминает

Поля для учётных данных в окне «Изменение прокси-сервера» нет. Windows спрашивает логин с паролем в момент первого запроса, ответом на код 407 Proxy Authentication Required. Диалог рисует браузер либо само приложение, система тут только передаёт код ответа.

В окне запроса есть флажок «Запомнить учётные данные». Отметите его, и пара уедет в Диспетчер учётных данных, раздел «Учётные данные Windows», записью, в имя которой входит адрес и порт посредника. Посмотреть список я предпочитаю из консоли:

cmdkey /list

Удалить конкретную запись, когда пароль сменился и диалог перестал появляться:

cmdkey /delete:203.0.113.10:8080

Открыть тот же список мышью: rundll32.exe keymgr.dll,KRShowKeyMgr. Полезно, когда учётка сохранилась в профиле Edge, а curl продолжает получать 407: у каждого хранилища свой набор записей, и запись браузера остальным программам не видна.

Второй способ авторизации избавляет от диалогов совсем. Вы привязываете внешний адрес машины в кабинете провайдера, и порт пускает вас по адресу источника. Для стационарной рабочей станции с постоянным адресом это самый спокойный вариант: система ничего не хранит, диалог не всплывает, планировщик заданий отрабатывает ночью без человека за столом. Я держу рабочий сервер именно так, на доступе, где привязка меняется в кабинете свободно и в пакет входят две привязки; список форматов выдачи у адресов IPv4 с короткой строкой подключения включает и IP:PORT, что для этого сценария и требуется.

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

4. Список исключений и его синтаксис

Поле исключений называется полностью так: «Не использовать прокси-сервер для адресов, начинающихся со следующих записей. Для разделения записей используйте точку с запятой (;)». Название длинное, зато точное: сравнение идёт по началу строки хоста, разделитель только точка с запятой.

Пробелы вокруг точки с запятой Windows терпит, лишние пустые записи тоже. Запятая ломает всё: список читается как одно длинное имя хоста, исключения перестают работать, и человек за машиной видит, что внутренние сервисы стали недоступны. Я собираю строку в блокноте и вставляю целиком.

Мой обычный набор для рабочей станции выглядит так: localhost;127.0.0.1;10.*;192.168.*;*.corp.local;<local>. Он оставляет снаружи всё внутреннее и отправляет наружу только настоящий интернет-трафик.

5. Тот же параметр через реестр и через netsh winhttp

Пользовательская настройка живёт в ветке HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings. Четыре значения покрывают всю страницу «Параметры»: ProxyEnable типа DWORD, ProxyServer, ProxyOverride и AutoConfigURL типа строка.

$key = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings'
Set-ItemProperty -Path $key -Name ProxyEnable  -Value 1 -Type DWord
Set-ItemProperty -Path $key -Name ProxyServer  -Value '203.0.113.10:8080'
Set-ItemProperty -Path $key -Name ProxyOverride -Value 'localhost;127.0.0.1;10.*;192.168.*;<local>'

В ProxyServer можно развести протоколы по разным портам, тогда строка пишется с префиксами и точкой с запятой между ними: http=203.0.113.10:8080;https=203.0.113.10:8080;socks=203.0.113.10:1080. Через графическое окно такую запись не внести, реестр её принимает и WinINET её исполняет. Именно так на моей машине появляется системный SOCKS5.

Правка реестра применяется не сразу: WinINET держит настройку в памяти процесса. Толчок делается вызовом InternetSetOption с кодами 39 и 37.

$sig = @'
[DllImport("wininet.dll", SetLastError = true, CharSet = CharSet.Auto)]
public static extern bool InternetSetOption(IntPtr hInternet, int dwOption, IntPtr lpBuffer, int dwBufferLength);
'@
$wi = Add-Type -MemberDefinition $sig -Name WinInet -Namespace Net -PassThru
$wi::InternetSetOption([IntPtr]::Zero, 39, [IntPtr]::Zero, 0) | Out-Null
$wi::InternetSetOption([IntPtr]::Zero, 37, [IntPtr]::Zero, 0) | Out-Null

Вторая половина истории это WinHTTP, отдельный стек со своим хранилищем в HKLM. Он настраивается командой netsh из консоли с правами администратора.

netsh winhttp show proxy
netsh winhttp set proxy proxy-server="http=203.0.113.10:8080;https=203.0.113.10:8080" bypass-list="localhost;127.0.0.1;10.*;<local>"
netsh winhttp import proxy source=ie
netsh winhttp reset proxy

Команда import proxy source=ie копирует текущую пользовательскую настройку в WinHTTP, экономя ручной ввод. reset proxy возвращает прямые соединения. Обе команды печатают итоговую таблицу сразу после выполнения, поэтому отдельная проверка на этом шаге не нужна.

6. Настройки пользователя и настройки службы WinHTTP

Два хранилища живут независимо, и почти все жалобы вида «настроил, а половина программ идёт мимо» растут отсюда.

Практический вывод такой: страницу «Параметры» я заполняю для себя и браузеров, netsh winhttp выполняю на любой машине, где через посредник должны ходить службы и запланированные задания. Проверка обновлений Windows и Защитник читают ровно вторую настройку, и без неё сервер с закрытым наружу шлюзом будет молча копить ошибки в журнале.

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

7. Какие программы системную настройку игнорируют и что с ними делать

Разработчики берут сетевой стек по своему усмотрению, и часть популярных программ читает свои источники.

Firefox хранит параметры сети внутри профиля и по умолчанию системную запись только копирует, при этом собственный переключатель имеет приоритет. curl, wget, git, Python с библиотекой requests, Node.js и почти вся консоль смотрят на переменные окружения. Java читает свои ключи запуска -Dhttp.proxyHost и -Dhttp.proxyPort. Игровые клиенты, мессенджеры и часть торговых терминалов открывают сокеты напрямую и не читают ничего.

Для консольных программ переменные задаются один раз и переживают перезагрузку:

[Environment]::SetEnvironmentVariable('HTTP_PROXY','http://203.0.113.10:8080','User')
[Environment]::SetEnvironmentVariable('HTTPS_PROXY','http://203.0.113.10:8080','User')
[Environment]::SetEnvironmentVariable('NO_PROXY','localhost,127.0.0.1,.corp.local','User')

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

git настраивается отдельным ключом, потому что читает собственный конфиг раньше окружения:

git config --global http.proxy http://203.0.113.10:8080
git config --global https.proxy http://203.0.113.10:8080

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

8. Файл автонастройки

Файл автонастройки это текстовый сценарий на JavaScript с единственной функцией FindProxyForURL(url, host). Windows вызывает её на каждый запрос и получает строку с указанием, куда его отправить. Способ удобен, когда часть сайтов должна идти через посредник, а внутренние ресурсы напрямую.

function FindProxyForURL(url, host) {
  if (isPlainHostName(host) || shExpMatch(host, "*.corp.local")) {
    return "DIRECT";
  }
  if (isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0")) {
    return "DIRECT";
  }
  return "PROXY 203.0.113.10:8080; DIRECT";
}

Адрес сценария вносится переключателем «Использовать сценарий настройки» в верхнем блоке страницы «Параметры» либо ключом реестра:

Set-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' `
  -Name AutoConfigURL -Value 'http://10.0.0.5/proxy.pac'

Два условия, без которых сценарий не заработает. Веб-сервер обязан отдавать файл с типом содержимого application/x-ns-proxy-autoconfig; при типе text/plain часть клиентов файл прочтёт, Edge откажется. И путь вида file://C:/proxy.pac современные сборки Windows игнорируют, локальные сценарии отключены на уровне WinINET и WinHTTP. Поднимите файл на внутреннем веб-сервере, это надёжнее и заодно даёт одну точку правки на весь офис.

Строка возврата поддерживает запасные варианты через точку с запятой. Запись PROXY 203.0.113.10:8080; DIRECT означает: попробовать посредник, при отказе идти напрямую. На рабочих машинах я запасной DIRECT убираю, чтобы отказ порта стал заметен сразу.

Полезных встроенных функций в сценарии всего несколько, и я пользуюсь четырьмя. isPlainHostName отделяет короткие внутренние имена. shExpMatch сравнивает строку с шаблоном, где звёздочка заменяет любой кусок. dnsResolve вместе с isInNet проверяет попадание адреса в подсеть, вызов идёт в сеть и подтормаживает, поэтому его я держу последним по порядку. myIpAddress пригождается на ноутбуке, который ходит и в офис, и из дома: по своему адресу сценарий понимает, где машина сейчас, и меняет маршрут без участия человека.

Отладка сценария выглядит так. Я открываю файл в браузере обычной ссылкой и убеждаюсь, что он отдаётся текстом без ошибки сервера. Затем правлю одну строку и перезапускаю браузер: результат вызова кэшируется на время сеанса, и без перезапуска правка остаётся невидимой. Третий шаг проверка через GetSystemWebProxy из раздела ниже, она печатает конечный маршрут для конкретного адреса и показывает, какую ветку сценария выбрала система.

9. Проверка после настройки

Сначала смотрим, что система вообще запомнила. Пользовательская часть:

Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
  Select-Object ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL

Часть службы:

netsh winhttp show proxy

Дальше проверяем, что порт вообще отвечает. Отказ на этом шаге снимает половину вопросов:

Test-NetConnection -ComputerName 203.0.113.10 -Port 8080 -InformationLevel Detailed

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

$direct = Invoke-RestMethod -Uri 'https://api.ipify.org'
$viaProxy = Invoke-RestMethod -Uri 'https://api.ipify.org' -Proxy 'http://203.0.113.10:8080'
"прямо: $direct ; через посредник: $viaProxy"

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

$cred = Get-Credential
Invoke-RestMethod -Uri 'https://api.ipify.org' -Proxy 'http://203.0.113.10:8080' -ProxyCredential $cred

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

[System.Net.WebRequest]::GetSystemWebProxy().GetProxy('https://example.com')

Проверка в браузере занимает минуту. Открываю страницу с определением адреса, сверяю с тем, что вернул PowerShell, потом захожу на любой внутренний ресурс из списка исключений и убеждаюсь, что он открылся. Третий шаг: смотрю в заголовки, которые сайт видит от клиента. Посредник, добавляющий X-Forwarded-For и Via, показывает сайту исходный адрес, поэтому для рабочих задач я беру анонимные адреса для системной настройки и сверяю вывод на странице проверки заголовков.

Ещё один быстрый признак: откройте «Диспетчер задач», вкладку «Производительность», и посмотрите на счётчик сети во время загрузки крупного файла. Трафик через посредник идёт ровным потоком по одному соединению.

Полную картину по конкретному процессу даёт Get-NetTCPConnection. Команда показывает, куда именно программа открыла сокеты, и заодно ловит клиентов, которые системную запись прочитали и всё равно пошли своим путём.

Get-NetTCPConnection -State Established |
  Where-Object { $_.OwningProcess -eq (Get-Process msedge)[0].Id } |
  Select-Object RemoteAddress, RemotePort |
  Sort-Object RemoteAddress -Unique

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

10. Разбор ошибок

Отдельно про журнал: обращения WinHTTP видны в журнале событий Windows, раздел «Журналы приложений и служб». Когда служба молчит и ошибку показывать отказывается, я иду туда и смотрю коды соединений; там же видно, читает ли она вообще машинную настройку.

Дальше по этому справочнику: браузер со своими настройками сети разобран в статье про профили и параметры соединения в Firefox, правила переключения по доменам в Chrome в материале о расширении SwitchyOmega, настройка на телефоне в инструкции для точки доступа и Wi-Fi на Android. Для программ, которые системную запись не читают вовсе, посмотрите разбор перехвата соединений в Proxifier для настольных приложений.