Ноутбук вчера спокойно ходил через корпоративный прокси. Сегодня половина сайтов не открывается, мессенджер висит на «подключении», браузер выдаёт ERR_PROXY_CONNECTION_FAILED. Знакомая картина. В девяти случаях из десяти человек переустанавливает браузер, чистит кэш и ругает провайдера, хотя дело в трёх строчках настроек, оставшихся с прошлого раза.
Я сбрасывал прокси сотни раз: на тестовых машинах после парсеров, на клиентских ноутбуках после уволившихся сотрудников, на своём после экспериментов с SOCKS5. Ниже порядок действий, который реально работает: от самого быстрого к самому радикальному.
Сначала определи, где сидит прокси: в системе, в браузере или в приложении
Три разных уровня, и путать их дорого. Системный прокси в Windows задают WinHTTP и WinINET: через них ходят обновления, установщики, часть legacy-софта и браузеры на Chromium. Отдельный прокси может жить в настройках самого браузера - у Firefox он свой. Третий слой - приложения вроде Telegram, у которых собственный список подключений и полный игнор системных настроек.
Проверка занимает минуту. Открываешь любой сайт проверки IP и смотришь, совпадает адрес с твоим или нет. Совпадает - системный прокси уже не работает, проблема в другом. Не совпадает - идёшь по уровням ниже.
Командная строка Windows: одна строка и перезагрузка
Самый быстрый способ сбросить настройки прокси сервера в Windows. Открываешь меню Пуск, находишь «Командная строка», правой кнопкой и «Запустить от имени администратора». В чёрном окне пишешь:
netsh winhttp reset proxy
Enter, потом перезагрузка. Команда сносит конфигурацию WinHTTP - тот слой, через который ходят системные службы, установщики и часть приложений. В справочнике Microsoft по netsh прямо оговорено: WinINET эта команда не трогает. А через WinINET работает половина старого софта и сам браузер, если берёт параметры из системы. Поэтому после netsh загляни руками во второй слой, о нём дальше.
Параметры Windows 10 и 11: три блока, в которых все путаются
Пуск, шестерёнка, «Сеть и интернет», раздел «Прокси». Здесь три независимых блока.
Первый, «Автоматическое определение параметров». Галочка включает WPAD: система сама ищет конфигурацию в локальной сети. Дома она не нужна почти никогда, а в офисе с ней бывают сюрпризы. Вышел из корпоративной сети, а Windows продолжает искать PAC-файл и подвешивает запросы на несколько секунд. Снимаешь галочку.
Второй блок, «Использовать скрипт настройки». Тут прописан адрес PAC-файла, часто внутренний, вида http://.../proxy.pac. Если ты больше не в той сети, скрипт недоступен, а браузер висит в ожидании ответа. Отключаешь.
Третий, «Использовать прокси-сервер вручную» с кнопкой «Настроить». Открывается окно с полями адреса и порта, списком исключений и кнопкой «Дополнительно». Сбрасываешь так: снимаешь тумблер и сохраняешь. Обязательно проверь исключения - бывает, тумблер выключен, а список доменов остался и продолжает ломать доступ к конкретным сайтам.
Сброс сети: тяжёлая артиллерия, к которой стоит идти не сразу
Параметры, «Сеть и интернет», «Состояние», пункт «Сброс сети», кнопка «Сбросить сейчас». Вариант ядерный. Windows пересоздаёт сетевые адаптеры, сносит сохранённые Wi-Fi профили вместе с паролями, откатывает VPN-клиенты и сетевые компоненты к заводскому состоянию. Прокси уходит вместе с ними.
Прибегаю к нему, когда netsh не помог, а в реестре явно остался мусор от корпоративного клиента. Минус очевиден: заново вводить пароли от всех сетей и перенастраивать VPN. Держи эти данные под рукой перед нажатием.
Реестр: где настройки живут на самом деле
Ветка HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings. Там параметры ProxyEnable, ProxyServer, ProxyOverride и AutoConfigURL. Если AutoConfigURL ссылается на давно мёртвый адрес, никакой тумблер в параметрах его не уберёт - значение вернётся после перезапуска. Удаляешь, перезагружаешься.
Тут же частая история: настройки перезаписывает групповая политика или клиент антивируса. Диагностика простая. Сбросил, перезагрузился, а ProxyEnable снова равен единице. Значит, источник снаружи, и ковырять надо не Windows, а то, что ей управляет.
Chrome, Edge и Яндекс.Браузер: один движок, разные двери
Все они на Chromium и по умолчанию берут системные настройки. Открываешь три точки, «Настройки», в поиске по настройкам набираешь «прокси», выбираешь пункт «Открыть настройки прокси-сервера компьютера». Откроется то самое окно Windows. Логика простая: сбросил в системе, сбросилось в браузере.
Но есть нюанс, о котором мало кто помнит. Расширения могут держать собственный прокси и игнорировать системные параметры. На Reddit в тредах с жалобами на ERR_PROXY_CONNECTION_FAILED виновником чаще всего оказывается именно расширение, а не система. У меня был такой случай: человек трижды сбрасывал сеть, а трафик продолжал уходить через узел - виновато расширение для смены геолокации, установленное полгода назад и благополучно забытое. Открывай список расширений и отключай подозрительные пачкой, потом включай по одному.
Второй нюанс - ярлык. Если браузер запускается с параметром --proxy-server в свойствах ярлыка, системные настройки ему не указ. Правой кнопкой по ярлыку, «Свойства», поле «Объект». Лишний хвост после пути к exe удаляется, ярлык пересоздаётся.
Firefox идёт своим путём
У него собственный стек и своя страница: три полосы, «Настройки», «Основные», в самом низу «Настройки сети» и кнопка «Настроить». Три варианта на выбор: без прокси, автоопределение, ручная настройка. Выбираешь «Без прокси», готово.
Глубже есть about:config, где network.proxy.type задаёт режим: 0 напрямую, 1 вручную, 2 PAC-скрипт, 4 автоопределение, 5 системные настройки. Значение 5 ставят те, кто хочет синхронизировать браузер с Windows. Отдельная боль: Firefox хранит всё в профиле, и при переносе профиля с другой машины настройки переезжают вместе с ним. Свежий профиль решает вопрос за минуту.
macOS: два места, а не одно
Системные настройки, «Сеть», выбираешь активное подключение, «Дополнительно», вкладка «Прокси». Снимаешь галочки со всех протоколов: HTTP, HTTPS, SOCKS, FTP, автоматическая настройка прокси, автопрокси. Потом «ОК» и обязательно «Применить» - без этого изменения не вступят в силу. На этой кнопке ловятся почти все.
Второе место - терминал. Переменные http_proxy, https_proxy и all_proxy живут в ~/.zshrc или ~/.bash_profile, и через них ходит всё, что запускается из консоли: git, curl, npm, docker. Сбросил в интерфейсе, а git всё равно стучится в мёртвый узел. Проверяй файлы профиля и ~/.curlrc, там тоже бывает прописан адрес.
Android и iOS: настройки привязаны к Wi-Fi, а не к телефону
Android: «Настройки», «Сеть и интернет», «Wi-Fi», тап по сети, карандаш, «Дополнительные параметры», «Прокси», выбираешь «Нет». iOS: «Настройки», «Wi-Fi», синяя буква i рядом с сетью, внизу «Настройка прокси», «Выкл».
Ключевой момент, который упускают. Параметры хранятся в профиле конкретной сети. Сбросил на домашнем Wi-Fi, а в кафе всё равно может стоять чужой прокси, если телефон к той сети когда-то подключался. Проверяй именно ту сеть, через которую идёт трафик прямо сейчас.
Telegram и WhatsApp: сброс внутри приложения
Telegram: «Настройки», «Данные и память», «Прокси». Там список подключений и переключатель «Использовать прокси». Выключаешь, клиент идёт напрямую. Само MTProto-подключение остаётся в списке, удалить можно долгим тапом или свайпом. Заодно проверь тип соединения в продвинутых настройках.
В WhatsApp отдельного раздела нет, мессенджер берёт системные параметры Wi-Fi или мобильной сети. Путь тот же, что описан выше.
У MTProto собственный транспорт поверх TCP: пакеты шифруются, нагрузка распределяется между дата-центрами. Для задач, где важна предсказуемая задержка при обращении к API из разных регионов, это даёт ровный пинг. SOCKS5 устроен проще - работает на уровне сессии, содержимое пакета не трогает, потому и удобен для парсинга и сбора данных с распределённых узлов.
Прокси возвращается после сброса. Вот почему
Три типовых виновника. Групповые политики в корпоративной сети: сбрасываешь, а при следующем входе в домен всё на месте. Клиент антивируса или DLP-системы, который подменяет настройки ради инспекции трафика. И программа либо расширение, прописавшееся в автозагрузку.
Порядок проверки простой. Сбросил, перезагрузился, посмотрел. Вернулось? Смотри автозагрузку, потом политики, и только потом думай про переустановку системы. В корпоративной среде честнее сразу идти к админу: он один знает, где лежит политика, и не будет вслед за тобой ломать себе сеть.
Когда сбрасывать не надо
Половина обращений ко мне по этой теме заканчивается не сбросом, а нормальной настройкой. Люди сносят рабочий прокси, потому что тот «тормозит», а на деле узел перегружен или выбран не под задачу. Прокси для сбора данных с маркетплейсов и прокси для панели аналитики - разные истории по нагрузке, географии и типу адресов.
Если после сброса выяснилось, что прокси был нужен (а он почти всегда был нужен), не хватай первый попавшийся из бесплатных списков. Такие узлы живут часами, логируются и отдают твой трафик неизвестно кому. Нормальный путь - подобрать пул под конкретную задачу: резидентные для сбора данных по регионам, датацентровые для скорости, мобильные для площадок, которые режут обычные адреса. Каталог с фильтрами по стране, типу и протоколу есть на 3seller.com/proxy, там же видно цены и условия, без регистрации и звонков менеджера.
Быстрый порядок действий, если сеть легла прямо сейчас
- Проверь IP на любом сервисе: совпадает с твоим или нет.
- Windows: netsh winhttp reset proxy от админа, перезагрузка.
- Параметры, «Сеть и интернет», «Прокси»: снять автоопределение, скрипт и ручной режим.
- Браузер: отключить подозрительные расширения, проверить ярлык на лишние параметры.
- Не помогло: сброс сети, потом реестр, потом автозагрузка и политики.
Сброс настроек прокси сервера редко бывает сложной технической задачей. Сложность в другом: понять, какой из трёх уровней держит трафик, и не снести по пути рабочий узел, который ещё пригодится. Начни с команды в консоли, дальше по списку - и в девяти случаях из десяти вечер останется свободным.