Звонок от знакомого на прошлой неделе: «Отключил прокси, а браузер всё равно половину сайтов не грузит». Подключаюсь удалённо, открываю Параметры, тумблер стоит в положении «Откл.». А трафик при этом уходит на сторонний узел. История настолько типовая, что я перестал удивляться. В Windows 11 настройка прокси живёт минимум в трёх местах, и выключить одно из них недостаточно.
Ниже пошаговый разбор: куда нажимать, что проверять после, и почему настройка иногда возвращается сама. Плюс отдельно про приложения, которые плевать хотели на системный тумблер.
Сначала убеждаемся, что проблема вообще в прокси
Прежде чем лезть в настройки, неплохо понять, с чем воюешь. Признаки включённого прокси на уровне системы выглядят так. Страницы открываются с задержкой 2-3 секунды, скорость режется втрое. Часть сайтов отдаёт ошибку соединения, а часть грузится нормально. Мессенджеры при этом работают, потому что у них свои каналы.
Ещё один маркер: в трее значок сети с восклицательным знаком, хотя Wi-Fi подключён и роутер раздаёт адреса. Или браузер пишет «Не удалось найти IP-адрес сервера» на всех вкладках сразу.
Самый быстрый способ увидеть системную настройку без кликов мышью - командная строка. Открываете командную строку или PowerShell и вводите netsh winhttp show proxy. Команда покажет, настроен ли прокси на уровне WinHTTP, то есть для служб и части приложений. Если в ответе «Прямое подключение», значит системный уровень чист, и копать нужно в браузере или в конкретной программе.
Отключение через Параметры занимает полминуты
Основной путь в Windows 11 такой. Жмёте «Пуск», открываете «Параметры». Или кликаете правой кнопкой по значку соединения в трее и выбираете «Параметры сети и Интернета». Второй вариант быстрее, я обычно пользуюсь им.
Дальше в левом меню или в списке находите «Прокси-сервер». Там будет два блока: автоматическая настройка и ручная.
- В блоке «Автоматическая настройка» выключаете переключатель «Определять параметры автоматически». Это важно сделать первым, потому что PAC-скрипт перетирает ручные настройки.
- В блоке «Использовать прокси-сервер» нажимаете кнопку «Настройка».
- В открывшемся окне ставите переключатель «Использовать прокси-сервер» в положение «Откл.».
- Сохраняете кнопкой «Сохранить».
После этого система перестаёт гнать трафик через узел. Но есть нюанс, о котором почти никто не пишет: настройка применяется не мгновенно ко всем процессам. Уже запущенные приложения держат старое соединение в памяти. Перезапуск браузера решает вопрос, а иногда нужен полный выход из системы.
Панель управления дублирует то же самое, и это не баг
Многие спрашивают, зачем лезть в Панель управления, если тумблер уже выключен в Параметрах. Отвечаю практикой: в Windows 11 эти два интерфейса правят один и тот же параметр, но применяют его по-разному. Старый диалог из Панели управления работает через WinINET и влияет на часть программ, которые новый интерфейс не всегда догоняет. Особенно это касается корпоративных сборок и машин после миграции с Windows 10.
Порядок действий:
- Открываете «Панель управления». Проще всего через поиск в «Пуске».
- Переключаете «Просмотр» в режим «Значки», если он стоит как «Категория».
- Находите раздел «Свойства браузера».
- Переходите на вкладку «Подключения» и жмёте «Настройка сети».
- Снимаете галочку «Автоматическое определение параметров» и все остальные отметки в этом окне.
- Жмёте «ОК» и применяете изменения.
Если в окне «Настройка сети» галочка «Использовать прокси-сервер для подключений LAN» стояла активной, а поля с адресом и портом заполнены, значит трафик действительно шёл через узел. После снятия галочки система вернётся к прямому подключению.
Тумблер выключен, а трафик всё равно уходит на узел
Вот здесь начинается самое интересное. Системная настройка отвечает только за те приложения, которые её читают. А читают её далеко не все. На Reddit в ветках по Windows 11 пользователи регулярно описывают тот же сценарий: системный тумблер выключен, а браузер продолжает ходить через узел.
Первое, что проверяю на чужой машине, это расширения браузера. Прокси-менеджеры вроде расширений для смены геолокации ставят собственный прокси внутри браузера и на системные настройки не смотрят вообще. Chrome и Edge с таким расширением будут работать через узел, даже если в Параметрах всё выключено. Отключаете расширение, и картина меняется.
Второе, что смотрю, это файл автоматической конфигурации, если он был прописан руками. Бывает, что человек когда-то вбил адрес PAC-скрипта в поле «Использовать скрипт настройки», а потом забыл. При этом переключатель «Определять параметры автоматически» стоит в положении «Откл.», и создаётся ощущение, что всё чисто. На деле скрипт продолжает работать, пока его адрес не стёрт из поля вручную.
Третье, это мессенджеры. Telegram, WhatsApp и часть корпоративных клиентов держат собственные настройки подключения. Системный тумблер на них не действует. В Telegram это Настройки, затем «Данные и память», затем «Прокси»: там список узлов и переключатель «Использовать прокси». Выключаете его, и приложение идёт напрямую. Если в списке висит узел, добавленный для теста полгода назад, он будет подниматься при каждом запуске.
В WhatsApp путь короче: Настройки, затем «Хранилище и данные», затем «Прокси». Там либо пусто, либо стоит ручной узел. Выключаете, перезапускаете приложение.
Четвёртое, это VPN-клиенты и корпоративные агенты. Они поднимают виртуальный адаптер и маршрутизируют трафик на уровне драйвера. Тут никакие настройки прокси не помогут, потому что прокси в системе может быть отключён, а трафик всё равно пойдёт через туннель. Проверяется просто: смотрите список сетевых адаптеров, и если там висит подключение от неизвестного клиента, отключаете его.
Настройка возвращается после перезагрузки, и вот почему
Классика, с которой сталкиваюсь пару раз в месяц. Человек всё выключил, перезагрузился, а прокси снова активен. Причин обычно три.
Первая: на машине стоит клиент, который сам себя прописывает в систему при старте. Это может быть корпоративный агент безопасности, менеджер прокси для работы или сомнительная программа, попавшая вместе с установщиком. Лечится поиском по автозагрузке: Диспетчер задач, вкладка «Автозагрузка», отключаете всё подозрительное и перезагружаетесь.
Вторая: групповая политика. Если ноутбук корпоративный, администратор мог прописать параметры через политики, и тогда ручное отключение откатится при следующем входе в систему. Проверяется в редакторе локальной групповой политики, раздел с настройками браузера и подключений. На домашней машине такого обычно нет, а вот на рабочей встречается регулярно. Здесь разговор только с админом, самому ломать политику не стоит.
Третья: параметр остался в реестре, а интерфейс его не показывает. В ветке Internet Settings есть значения, которые отвечают за прокси и за автоконфигурацию. Если интерфейс их не отображает, они всё равно применяются. Чистится либо вручную через редактор реестра, либо сбросом сетевых настроек.
Сброс делается так: Параметры, «Сеть и Интернет», «Дополнительные параметры сети», «Сброс сети». Кнопка вернёт сетевые компоненты к заводскому состоянию и перезагрузит компьютер. Настройки Wi-Fi при этом придётся вводить заново, так что пароль от роутера держите под рукой. И да, это крайняя мера, но она выручает, когда ничего другое не сработало.
Ещё один инструмент, который почему-то забывают: netsh winhttp reset proxy в командной строке с правами администратора. Команда сбрасывает системный прокси WinHTTP, который не виден в обычном интерфейсе Параметров. Часто именно он и остаётся включённым после всех манипуляций.
Ошибки, которые я вижу чаще всего
Первая и самая дорогая по времени: человек выключает прокси в браузере, но не проверяет, что тот же параметр активен в системе. Через час выясняется, что проблема была в другом приложении. Проверять нужно оба уровня сразу.
Вторая: после отключения не перезапускаются процессы. Браузер держит соединение, и кажется, что настройка не применилась. Закрыть все окна браузера полностью, а не просто свернуть, и открыть заново.
Третья: путаница между типами прокси. В системе настраивается HTTP или HTTPS, а приложение просит SOCKS5. Человек выключает системный HTTP-прокси, а приложение продолжает ходить через SOCKS5, потому что у него свой конфиг. Это разные уровни, и они не связаны.
Четвёртая: отключили прокси, но оставили включённым «автоматическое определение параметров». Система находит конфигурацию через DHCP или DNS и подставляет узел сама. Всегда выключайте этот пункт первым.
Прокси - это инструмент, а не поломка
Держу в голове простую мысль: прокси сам по себе не проблема. Проблема в том, что он остался включённым, когда перестал быть нужным. Или в том, что его поставили на глазок, без понимания архитектуры.
С точки зрения техники всё прозрачно. SOCKS5 работает на уровне сессии и умеет передавать любой трафик, включая UDP, поэтому его берут для игр, стриминга и парсинга. HTTP-прокси видит только веб-запросы, зато умеет кешировать и фильтровать. MTProto - это протокол Telegram. Внутри него прокси настраивается отдельно: клиент строит собственный канал до узла, а не пользуется системным.
Задержка зависит от расстояния до узла и от того, насколько грамотно настроена балансировка. Один сервер на 50 человек в офисе - это боль, пять узлов с распределением нагрузки - это норма. Парсинг маркетплейсов без ротации адресов вообще не имеет смысла, потому что площадка отдаёт заглушку после сотни запросов с одного адреса. Всё это решается на этапе выбора провайдера, а не после.
Если для рабочих задач нужен предсказуемый узел с понятными характеристиками, а не случайный сервер из чата, смотрю в сторону готовых каталогов. Например, каталог прокси 3seller даёт выбор по типу, географии и назначению, с описанием каждого варианта. Удобно тем, что не нужно гадать, потянет ли узел нагрузку: параметры видны заранее.
Что проверить, если нужен управляемый прокси, а не отключение
Бывает обратная ситуация: прокси отключили, а через неделю он понадобился снова, уже осознанно. Тогда логика другая. Сначала определяется задача: работа с большим числом запросов, доступ к геозависимым данным, разделение трафика внутри команды. Под каждую задачу свой тип узла.
Для парсинга и сбора данных берут пул адресов с ротацией, чтобы запросы не упирались в лимиты площадки. Для корпоративного сегмента поднимают собственный VPS: полный контроль, стабильный адрес, понятный владелец. Для мобильных приложений иногда нужен мобильный прокси, потому что часть сервисов иначе отдаёт неполные данные.
И главное: настраивать прокси лучше на уровне приложения, а не всей системы. Тогда отключение не превращается в квест, а рабочие и личные процессы не мешают друг другу. Системный прокси держите выключенным, а нужные программы пусть ходят через свой конфиг.
Проверка после настройки занимает минуту. Открываете сайт проверки IP, смотрите адрес и провайдера. Запускаете netsh winhttp show proxy и убеждаетесь, что системный уровень чист. Перезагружаетесь и повторяете обе проверки. Если результат тот же, значит настройка закрепилась, и больше вы к этому вопросу не вернётесь.
Начните с самого простого: откройте Параметры, выключите «Определять параметры автоматически», затем тумблер в разделе «Использовать прокси-сервер». Проверьте браузер. Если не помогло, идите в «Свойства браузера» и повторите там. Девять из десяти случаев закрываются на этом шаге, остальные требуют проверки автозагрузки и приложений с собственными настройками.