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

Когда сброс прокси через командную строку действительно нужен

Короткий ответ: чаще всего помогает либо netsh winhttp reset proxy, либо отключение пользовательского прокси через реестр. Какая команда нужна именно вам, зависит от того, где был задан прокси: для служб и части системных компонентов это один уровень, для браузеров и пользовательских приложений — другой.

На практике путаница возникает постоянно. Специалист сбрасывает WinHTTP, а Chrome или Edge по-прежнему ходят через старый адрес. Или наоборот: в параметрах пользователя прокси уже выключен, но скрипт, апдейтер или корпоративный агент продолжает использовать старую схему подключения.

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

Самая частая ошибка — считать, что команда netsh winhttp reset proxy сбрасывает вообще весь прокси в Windows. Это не так. Она очищает только настройки WinHTTP.

Главная путаница: в Windows не один прокси

Если упростить, в Windows обычно приходится иметь дело минимум с двумя зонами настроек. Первая — WinHTTP. Вторая — пользовательские параметры прокси, которые используют браузеры и часть приложений через системные сетевые настройки.

Где задан проксиЧто обычно используетЧем сбрасываетсяЧто важно помнить
WinHTTPСлужбы, агенты, часть системных компонентов и фоновых приложенийnetsh winhttp reset proxyНе отключает пользовательский прокси для браузеров
Параметры текущего пользователяChrome, Edge и другие программы, которые берут системный прокси пользователяКоманды reg add и reg deleteНастройки лежат в профиле пользователя, а не в WinHTTP
Собственные настройки приложенияFirefox, парсеры, антидетект, скрипты, API-клиентыСбрасываются внутри самой программыСистемные команды их не трогают
Переменные окруженияCLI-инструменты, библиотеки, некоторые скриптыОчистка переменных в текущем сеансеДаже после системного сброса трафик может идти через прокси из переменных

Для SEO-мониторинга, рекламной аналитики, парсинга открытых данных и QA это особенно важно. Один и тот же компьютер может одновременно использовать системный прокси, отдельный SOCKS5-прокси в приложении и еще один адрес в переменных окружения для скриптов.

Мобильные прокси России от 590 ₽ с ротацией

Отслеживайте, меняйте, переключайте и группируйте прокси в одном месте.

Перейти в личный кабинет

Какие команды реально используются для сброса

1. Сброс WinHTTP-прокси

Если прокси был задан для WinHTTP, базовая команда выглядит так:

netsh winhttp reset proxy

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

netsh winhttp show proxy

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

2. Отключение пользовательского прокси через командную строку

Если прокси прописан в параметрах текущего пользователя, через CMD обычно отключают флаг использования прокси и удаляют сохраненные значения адреса и PAC-скрипта.

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable /t REG_DWORD /d 0 /f
reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServer /f
reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v AutoConfigURL /f

Что делает каждая команда:

  • ProxyEnable = 0 — выключает использование ручного прокси;
  • ProxyServer — удаляет сохраненный адрес и порт прокси-сервера;
  • AutoConfigURL — удаляет URL PAC-скрипта, если раньше использовалась автоконфигурация.

Если команда удаления сообщает, что значение не найдено, это не всегда ошибка. Часто это просто значит, что такой параметр уже отсутствует.

Команды с HKCU меняют настройки текущего пользователя. Если вы открыли командную строку под другой учетной записью, прокси сбросится не там, где вы ожидаете.

3. Очистка переменных окружения в текущем сеансе

Для разработчиков, парсеров и тех, кто запускает CLI-инструменты, еще один частый источник проблемы — переменные окружения. Даже при чистых системных настройках утилита может продолжать использовать прокси из HTTP_PROXY или HTTPS_PROXY.

set HTTP_PROXY=
set HTTPS_PROXY=
set ALL_PROXY=

Это очищает переменные только в текущем окне CMD. Уже запущенные процессы и другие сеансы такие изменения не получат. Если вы работаете через профили в антидетект-браузере или через программу с собственным сетевым стеком, системный сброс тоже не затронет их внутренние параметры.

Порядок действий без лишних экспериментов

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

  2. Проверьте текущее состояние WinHTTP.
    Выполните netsh winhttp show proxy. Если там виден старый адрес или ручной прокси, сбрасывайте именно WinHTTP.

  3. Отключите пользовательский прокси, если он мог остаться в профиле.
    Выполните команды с reg add и reg delete для раздела Internet Settings.

  4. Перезапустите приложение, которое тестируете.
    Некоторые программы читают настройки только при старте. Без перезапуска можно получить ложный вывод, что сброс не сработал.

  5. Проверьте отдельные источники прокси внутри приложения.
    Firefox, парсеры, API-клиенты, браузерные профили и софт под ротационные прокси нередко хранят адрес отдельно от системы.

Как проверить, что прокси действительно сброшен

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

Проверка WinHTTP

netsh winhttp show proxy

Если сброс выполнен успешно, WinHTTP должен показывать прямой доступ без прокси-сервера. Формулировка может немного отличаться в зависимости от версии Windows, но смысл один: ручной прокси больше не задан.

Проверка пользовательских параметров

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServer
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v AutoConfigURL

На что смотреть:

  • ProxyEnable должен быть равен 0x0 или отсутствовать как активный признак ручного прокси;
  • ProxyServer не должен содержать адрес и порт;
  • AutoConfigURL не должен содержать ссылку на PAC-скрипт.

Проверка в самой программе

Здесь уже важна логика конкретного приложения. Браузер должен открывать страницы без системного прокси, парсер — перестать отправлять запросы через старый IP, а тестовое приложение — показать, что сетевой маршрут изменился. Если программа умеет отображать текущий прокси или лог подключения, лучше проверить и там.

Почему команда сработала, а трафик все равно идет через прокси

Такое бывает часто, и почти всегда причина не в самой команде, а в другом уровне конфигурации. Ниже — типичные сценарии, которые регулярно встречаются в рабочих связках маркетологов, QA и парсеров.

У приложения собственные настройки прокси

Firefox может использовать отдельные сетевые параметры, а не системные. Парсеры, чекеры, боты для тестирования и десктопные клиенты API часто сохраняют адрес прокси внутри своего профиля или проекта. Системный сброс на них не влияет.

Настройки возвращает политика или управляющий софт

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

Остался PAC-скрипт или автодетект

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

Прокси задан переменными окружения

Это типично для разработчиков и серверных задач. Скрипт на Python, Node.js, Java или CLI-утилита может брать HTTP_PROXY и HTTPS_PROXY, полностью игнорируя системные настройки пользователя.

Команда выполнена не под тем пользователем

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

Когда нужен уже не сброс прокси, а более широкий сетевой сброс

Если прокси уже выключен, но ошибки остались, проблема может быть не в нем. Например, в поврежденном Winsock-каталоге, старом DNS-кэше или некорректных параметрах TCP/IP.

Для таких случаев используют более общий набор команд:

ipconfig /flushdns
netsh winsock reset
netsh int ip reset

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

Если задача — просто убрать старый прокси перед тестом, не начинайте с полного сетевого сброса. Сначала очистите именно тот уровень, где был задан прокси. Так быстрее и безопаснее для рабочей машины.

Что проверить перед повторной настройкой прокси

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

Для командной работы это особенно важно. Когда часть трафика идет через системный прокси, часть — через настройки проекта, а часть — через отдельные профили, диагностика превращается в лотерею. Лучше заранее договориться, где именно команда хранит сетевые параметры.

Что запомнить

Сброс прокси через командную строку — это не одна универсальная команда, а набор действий для разных уровней настройки. Для WinHTTP нужен netsh winhttp reset proxy. Для пользовательского прокси — отключение ProxyEnable и очистка значений ProxyServer и AutoConfigURL. Для CLI-утилит отдельно проверьте переменные окружения.

Если после этого приложение все еще ходит через прокси, почти наверняка адрес прописан внутри самой программы, возвращается политикой или считывается из другого профиля. В рабочих задачах по SEO, QA, рекламе и мониторингу это стандартная история, а не исключение.

Частые вопросы по теме

Есть ли одна команда, которая полностью убирает весь прокси в Windows?

Нет, универсальной команды обычно нет. netsh winhttp reset proxy очищает только WinHTTP. Браузерный и пользовательский прокси обычно сбрасывают отдельно через параметры текущего пользователя. А у части приложений есть собственные настройки, которые системные команды вообще не затрагивают.

Нужно ли запускать командную строку от имени администратора?

Для работы с WinHTTP и общей сетевой диагностикой так надежнее. Но команды с разделом HKCU важнее выполнять под правильным пользователем, а не просто с повышенными правами. Если открыть CMD под другой учетной записью, вы измените чужой профиль, а не свой рабочий.

Поможет ли netsh winhttp reset proxy, если прокси остался в Chrome или Edge?

Обычно нет. Эти браузеры на Windows ориентируются на пользовательские системные параметры прокси, а не на WinHTTP как на единственный источник. Если старый адрес остался именно в браузере, смотрите настройки текущего пользователя и возможные внутренние расширения или профили.

Почему после сброса в Windows Firefox все равно использует прокси?

Потому что Firefox может работать со своей отдельной конфигурацией сети. Если в нем вручную указан HTTP- или SOCKS-прокси, системный сброс на это не подействует. В такой ситуации нужно менять параметры уже в самом браузере или в профиле, который вы используете.

Почему прокси возвращается после перезагрузки или входа в систему?

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

Когда стоит делать netsh winsock reset и netsh int ip reset?

Только если проблема уже не сводится к прокси. Эти команды помогают при более широких сетевых сбоях, но они затрагивают стек TCP/IP и требуют аккуратности. Для обычной замены или отключения прокси их использовать как первый шаг обычно не нужно.