Утро начинается не с кофе, а с ошибки ERR_PROXY_CONNECTION_FAILED в Chrome, хотя Telegram при этом работает. В девяти случаях из десяти в Windows 10 остался включённым прокси, о котором вы давно забыли: от старого рабочего проекта, после установки VPN-клиента или тестового парсера. Сброс занимает две минуты, если знать, где смотреть.
Дальше - то, что я реально делаю на машинах коллег и на своих тестовых стендах. Без магии: точки входа в интерфейсе и пара мест, куда обычно никто не заглядывает.
Начните с экрана «Прокси-сервер» в Параметрах
Жмите Win+I, дальше «Сеть и Интернет», в левом меню «Прокси-сервер». Windows 10 держит здесь три независимых блока, и путаница почти всегда из-за них. Люди выключают один, забывают второй, а потом удивляются, что браузер по-прежнему молчит.
Первый блок - «Определять параметры автоматически». Если тумблер включён, система тянет настройки из PAC-скрипта по ссылке. Часто там прописан адрес корпоративного сервера, который вы видели последний раз полгода назад, или давно умерший ресурс. Выключаем без сожалений.
Второй блок - «Использовать прокси-сервер». Тут адрес и порт вручную. Переводим тумблер в «Откл.». Заполненные поля можно не трогать, они не применяются. Но нажать «Сохранить» стоит и убедиться, что блок стал неактивным и поля посерели.
Третий - «Сценарий настройки». Если внутри висит ссылка на .pac-файл, удаляйте её кнопкой «Настроить». Пока ссылка на месте, Windows периодически дёргает её и заново применяет правила, даже если вы вроде бы всё отключили.
После всех манипуляций перезагрузитесь. Не потому что «так принято», а потому что часть служб кэширует параметры и подхватывает их только при старте. Пропустите этот шаг - половина проверок покажет неверный результат.
Старые настройки в Панели управления живут отдельно
Вот тут начинается самое интересное, и об этом мало кто пишет в инструкциях. В Windows 10 два независимых набора параметров прокси: новый в Параметрах и старый, через Панель управления → Свойства браузера → вкладка «Подключения» → «Настройка сети». Формально они про одно и то же, но читаются разными классами программ и синхронизируются по логике, которую никто толком не документировал.
Практический вывод простой. Если после сброса в Параметрах браузер всё равно лезет через прокси, идите в старый диалог и снимайте галочку там. На Reddit админы описывают ту же историю регулярно: человек сутки ищет причину, переустанавливает браузер, а дело в двух хранилищах настроек, которые живут своей жизнью.
Ещё нюанс: старый диалог не всегда открывается привычным путём, потому что в свежих сборках «Свойства браузера» спрятаны. Открывайте через Панель управления, а не через настройки Edge или Chrome. Иначе попадёте в другое окно и запутаетесь окончательно.
Прокси включается сам после перезагрузки
Классика жанра: вы всё выключили, перезагрузились, а тумблер снова зелёный. Значит, настройку возвращает какая-то программа, а не сама Windows. Бороться надо с ней, а не с интерфейсом.
Ищем виновника через командную строку от администратора. Запускаете netstat с ключами abno и фильтруете вывод по LISTENING и типичному порту прокси. Дальше смотрите PID и в диспетчере задач сопоставляете его с процессом. Либо в настройках этой программы есть пункт про внешний прокси, либо она стартует вместе с системой и делает что хочет при каждом входе.
Из личного опыта: чаще всего это корпоративные VPN-клиенты. У многих в интерфейсе есть вкладка «Внешний прокси» с опцией «настраивать автоматически». Пока она включена, клиент при каждом запуске прописывает свои параметры в систему, и вы боретесь с симптомом, а не с причиной. Снимите галочку там - проблема исчезнет без танцев с реестром.
Второй частый источник - расширения браузера с функцией «ускорителя» или смены региона. Третий - антивирус с веб-щитом: он фильтрует трафик через локальный порт и заодно правит настройки. Проверять по одному, отключая автозапуск, иначе не поймать момент.
Сброс на уровне системы: netsh winhttp
Отдельная песня, о которой знают не все даже из тех, кто работает в поддержке. Кроме пользовательских настроек в Windows есть WinHTTP-прокси. Его используют службы, центр обновления, некоторые установщики и фоновые агенты. Живёт он в другом месте и в интерфейсе Параметров не отображается вообще.
Посмотреть текущее состояние: netsh winhttp show proxy. Сбросить: netsh winhttp reset proxy. Команда возвращает «Прямой доступ» и снимает настройки, которые могли прописать корпоративные скрипты, установщик какого-нибудь SDK или агент системы мониторинга.
Если пользуетесь системным прокси осознанно, например для служебного трафика на выделенном узле, команда set proxy с параметрами вернёт всё обратно. Для чистового сброса хватает reset. Выполнять от имени администратора, иначе получите отказ в доступе и решите, что метод не работает.
Реестр: где физически лежат параметры
Ветка HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings. Ключи ProxyEnable, ProxyServer, ProxyOverride и AutoConfigURL. Единица в ProxyEnable означает включённый прокси, ноль - выключенный. Пустое значение AutoConfigURL означает отсутствие PAC-скрипта.
Лезть туда руками стоит только когда интерфейс врёт или не открывается. Сценарий такой: закрыли все браузеры, поправили значения, перезапустили explorer.exe, проверили результат. Правки в ветке пользователя не затрагивают WinHTTP, о котором шла речь выше. Два разных механизма, два разных места.
Заодно проверьте ветку HKEY_LOCAL_MACHINE на предмет тех же ключей. Если настройка прописана там, она применится ко всем пользователям машины. Тогда ваш личный сброс будет держаться только до следующего входа в систему.
Браузеры придётся проверять по одному
Chrome и Edge по умолчанию берут системные настройки, так что после сброса в Windows они подхватят новое состояние сами. Firefox живёт своей жизнью: у него в разделе настроек сети отдельный пункт про прокси, вплоть до собственных правил и исключений. Opera тоже умеет хранить своё. Если из всей системы прокси остался только в одном браузере, ищите именно там, а не в Windows.
Заодно пройдитесь по расширениям. Ставлю на то, что найдётся хотя бы одно с правом «управлять настройками прокси», о котором вы забыли пару лет назад. Отключать по одному и проверять результат, иначе не поймать виновника.
Как убедиться, что сброс действительно сработал
Простая проверка, которую я делаю всегда. Открываете сайт определения внешнего адреса и смотрите, совпадает ли он с адресом вашего провайдера. Совпадает - прокси не используется. Видите чужой адрес - остался либо WinHTTP-прокси, либо настройки в конкретном приложении.
Второй маркер - скорость и задержка. Через прокси страницы открываются заметно медленнее, особенно если узел в другой стране. Пропала задержка - скорее всего всё чисто.
Третий: проверьте то, что раньше работало через прокси. Внутренние панели, парсеры, скрипты на Python с прописанным прокси в переменных окружения. Они системные настройки игнорируют и продолжают стучаться по старым адресам. «Сброс не сработал» может оказаться проблемой конкретного скрипта, а не Windows.
Когда сброс не даёт результата
Три вещи, которые я проверяю в последнюю очередь, когда всё остальное не помогло.
- Служба или драйвер сетевого фильтра от антивируса. Временное отключение щита сразу показывает, в нём ли дело.
- Задача в планировщике, которая при старте системы запускает скрипт с настройками сети. Смотрите список активных задач, особенно с триггером «При входе в систему».
- Групповые политики. Если машина корпоративная, настройку может возвращать администратор домена. Бороться локально бессмысленно, проще написать в поддержку.
И ещё один момент, который экономит нервы. После сброса перезагрузитесь дважды. Первый раз система применит изменения, второй покажет, возвращается ли настройка. Если после второго тумблер снова горит, у вас точно живёт резидентная программа, и искать её надо через netstat, а не перебором в интернете.
Windows 7 и 8: логика та же, путь другой
Если вы попали на эту статью с более старой системой, алгоритм почти не меняется. В восьмёрке Параметры выглядят похоже, а в семёрке всё делается через Панель управления → Свойства браузера → Подключения → Настройка сети. Снимаете галочку, применяете, перезагружаетесь. Команды netsh winhttp работают одинаково во всех трёх версиях, так что этот способ универсальный.
Чем SOCKS5 отличается от HTTP, если вы настраиваете прокси осознанно
Сброс - половина задачи. Вторая половина: поставить рабочий прокси и не ловить те же грабли через неделю. Тут полезно понимать, что вы вообще прописываете в систему.
HTTP-прокси работает на уровне приложения и разбирает заголовки. Он умеет кэшировать ответы, фильтровать по адресам, аккуратно логировать запросы. Для веб-задач этого хватает, но любой не-HTTP трафик он просто не пропустит.
SOCKS5 работает на уровне сессии и не разбирает содержимое пакетов. Ему всё равно, что внутри, поэтому он тянет любой TCP-трафик: парсеры, клиенты баз данных, игровые протоколы. Накладные расходы ниже, задержка меньше, а шифрование остаётся на уровне приложения. Для большинства задач нормально.
MTProto, если речь про мессенджеры, это отдельная архитектура с шифрованием пакетов на транспортном уровне. В настройках Windows он не прописывается, потому что клиент работает с ним внутри себя. Знать это полезно хотя бы для того, чтобы не искать его в системных параметрах и не тратить время.
Балансировка между несколькими узлами и снижение задержки решаются на уровне пула, а не отдельной настройки. Для парсинга это критично: один узел упирается в лимиты за час, а пул из десяти живёт неделями.
Где брать прокси, чтобы не переделывать всё заново
Для регулярных задач я держу отдельные узлы под каждый сценарий: сбор данных, проверка выдачи по регионам, тестирование рекламных кабинетов. Смешивать всё в одном адресе - плохая идея. Лимиты и география у задач разные, и однажды вы упрётесь в потолок именно там, где не ждали.
Каталог, которым пользуюсь сам, лежит на 3seller.com/proxy. Там есть фильтры по стране, типу и протоколу - удобно, когда нужно быстро подобрать узел под конкретную задачу, а не гадать по названию. SOCKS5 беру для парсинга, потому что он не привязан к HTTP-заголовкам. HTTP с авторизацией - когда нужен аккуратный выход в веб из скрипта или бота.
Для корпоративного сценария с собственным VPS логика другая: поднимаете узел у себя, настраиваете аутентификацию, ограничиваете доступ по адресу офиса и прописываете его в системе через тот же экран «Прокси-сервер». Тогда после перезагрузки ничего не отваливается: настройка ваша, а не чужого клиента, который стартует вместе с системой.
Публичный Wi-Fi в кафе или аэропорту - отдельная история. Тут прокси с шифрованием или связка с корпоративным узлом снимает часть рисков, особенно когда вы логинитесь в рабочие панели и почту через открытую сеть. Задержку тоже можно держать под контролем, если узлов больше одного и вы понимаете, какой из них ближе.
Что сделать прямо сейчас
Откройте Параметры по Win+I, выключите все три блока на экране прокси, сохраните и перезагрузитесь. Потом запустите netsh winhttp show proxy и убедитесь, что там прямой доступ. Если после перезагрузки тумблер снова горит, в системе живёт программа, которая считает себя главнее. Ищите её через netstat, а не через поиск в интернете.
И на будущее: когда ставите очередной клиент с надписью VPN или «ускоритель интернета», сразу заглядывайте в его настройки на предмет пункта про прокси. Пять секунд внимания экономят полчаса утренней диагностики и один неприятный разговор с коллегами, у которых тоже перестал открываться рабочий портал.