Открываешь сайт в кафе, а он показывает цены для другого города. Или половина страниц не грузится, хотя Wi-Fi полный. В восьми случаях из десяти в системе остался включённый прокси, о котором ты забыл ещё в прошлом квартале. Настраивал парсер, тестировал рекламу, проверял гео - а потом просто закрыл вкладку.
Разберу, где прячется эта настройка на каждом уровне, в каком порядке её искать и что делать, если галочку снял, а легче не стало.
Прокси живёт на четырёх уровнях - выключать надо все
Главная ошибка - думать, что настройка одна. Трафик уходит через прокси из четырёх разных мест, и каждое включается отдельно.
Первый уровень - операционная система. Windows и macOS умеют гнать весь трафик через прокси на системном уровне. Тогда через него пойдут браузер, торрент-клиент и даже обновление Steam.
Второй - сам браузер. Firefox и Opera держат собственные настройки и плевать хотели на системные. Chrome и Edge наоборот: своих настроек не имеют и читают системные.
Третий уровень - расширения. Плагин «для маркетплейсов», «для арбитража», «для проверки гео» ставит свой прокси внутри себя. Галочки в системе на него не влияют вообще.
Четвёртый - VPN-клиент или антивирус с веб-щитом. Они поднимают локальный туннель и прописывают его как системный прокси. Снял галочку в Windows - клиент вернул её через пять секунд, потому что так запрограммирован.
Пока не понял, на каком уровне сидит проблема, любые действия - тыканье пальцем в небо. Сначала определи уровень, потом выключай.
Windows 10 и 11: три экрана, которые надо пройти
Начни с современного меню. Пуск - Параметры - Сеть и Интернет - Прокси-сервер. Тут два блока, и оба важны.
В блоке «Использовать сценарий настройки» переключатель должен стоять в положении «Откл.». Если там висит адрес PAC-файла, система тянет настройки с удалённого сервера, и ручные галочки не помогут. Часто этот пункт остаётся включённым после установки корпоративного софта или клиента для распределённых команд.
Ниже блок ручной настройки. Тумблер «Использовать прокси-сервер» выключаем. Заодно загляни в поле «Не использовать прокси для». Там бывает список исключений: локальные адреса ходят напрямую, всё остальное - через узел.
Второй экран - старый диалог свойств браузера. Он никуда не делся и работает там, где новый интерфейс врёт. Набери в поиске панели задач «Свойства браузера» (в английской локали Internet Options). Дальше вкладка «Подключения» и кнопка «Настройка сети». Снимаем «Автоматическое определение параметров» и «Использовать прокси-сервер для локальных подключений». ОК, ОК.
Третий экран - командная строка. Служебный софт, лаунчеры и менеджеры пакетов ходят через отдельный механизм WinHTTP. В интерфейсе он не виден. Проверяется командой в консоли от администратора: netsh winhttp show proxy. Если там что-то есть - сбрасывай через netsh winhttp reset proxy. Про эту штуку забывают почти все, а потом удивляются, почему установщик не качает файлы.
Старый путь через «Свойства обозревателя» на Windows 7 и не только
Если попал на машину с семёркой или на терминальный сервер, алгоритм тот же, только вход другой. Пуск - Панель управления. В правом верхнем углу переключи вид с «Категория» на «Крупные значки», иначе будешь блуждать по меню дольше, чем настраивать.
Дальше «Свойства обозревателя», вкладка «Подключения». Там список коммутируемых соединений и VPN. Выбираешь своё подключение, жмёшь «Настройка» и снимаешь «Использовать прокси-сервер для данного подключения». Если соединение одно, оно обычно уже выделено.
Нюанс, на котором спотыкаются: настройки для dial-up и для локальной сети - два разных окна. Первое открывается кнопкой «Настройка» под списком соединений, второе - кнопкой «Настройка сети» внизу. Прокси чаще прописан во втором, а люди лезут в первое и не находят.
Chrome и Edge: своих настроек нет, и это ловушка
Google Chrome не имеет собственного хранилища прокси. Совсем. Открой настройки, поищи что-нибудь про сеть - найдёшь только кнопку «Открыть настройки прокси-сервера компьютера» в разделе «Система». Нажатие выкидывает в тот самый диалог Windows, который разбирали выше.
Отсюда два следствия. Первое: поменял настройку в Chrome - поменял её для всей системы, включая Edge, почтовый клиент и мессенджеры. Второе: если в Chrome прокси «не отключается», проблема не в Chrome, а уровнем ниже.
Edge устроен так же, плюс иногда тащит настройки из профиля организации при входе в корпоративный аккаунт. Проверяется в edge://settings, но по факту всё сводится к системе.
Единственное, что в Chrome и Edge живёт отдельно - расширения. Про них ниже: это самый частый источник боли.
Opera, Firefox и Яндекс.Браузер: тут всё по-своему
Opera исторически имела собственный переключатель. В старых сборках он лежал в «Быстрых настройках» и назывался «Включить прокси-серверы». В новых версиях пункт переехал: Настройки - Дополнительно - раздел про систему и сеть. Логика та же: снять галочку и перезапустить браузер, иначе часть вкладок останется на старом соединении.
Firefox идёт дальше и держит полностью независимый стек. Настройки - Основные - в самом низу «Настройки сети» - «Настроить». Там четыре варианта: без прокси, автоматическое определение, системные настройки и ручная настройка. Выбираешь «Без прокси» - и Firefox ходит напрямую, даже если в Windows прописан узел.
Для продвинутых есть about:config и параметр network.proxy.type. Значение 0 - «без прокси», 1 - ручная настройка, 2 - PAC-файл, 4 - автоматическое определение, 5 - системные настройки. Если браузер упорно держит соединение, а в меню чисто, проверь этот параметр. Некоторые «оптимизаторы» и сборки меняют его напрямую.
Яндекс.Браузер в свежих версиях читает системные настройки, но может держать собственный переключатель в разделе «Сеть». Галочка в системе снята, а трафик всё равно идёт через узел - смотри настройки браузера отдельно.
Расширения - виновник, которого не видно
Типичная история из практики. Человек полгода назад поставил расширение для работы с маркетплейсами, оно подняло собственный туннель, и всё работало. Потом расширение обновилось, серверы разработчика умерли, а настройка осталась. Браузер тупит, половина сайтов не открывается, в системе всё чисто.
Проверяется просто. Открой список расширений (в Chrome это chrome://extensions, в других браузерах аналогичный раздел), выключи все подозрительные и перезапусти браузер. Дальше включай по одному и смотри, когда проблема вернётся. Долго, зато наверняка.
Отдельная категория - менеджеры прокси и антидетект-плагины. Они часто не просто ставят соединение, а перехватывают его через локальный порт. Выключил расширение - порт освободился, но системная настройка могла остаться. После отключения плагина пройди по системным экранам ещё раз.
И проверь видимый IP любым сервисом определения адреса. Совпадает с твоим реальным - всё чисто. Показывает чужой город - где-то остался узел.
macOS, iPhone и Android: два экрана и всё
На Mac: Системные настройки - Сеть - активное подключение (Wi-Fi или Ethernet) - Дополнительно - вкладка «Прокси». Там список протоколов: HTTP, HTTPS, SOCKS, FTP. Снимаешь все галочки, включая «Автонастройка прокси» и «Автоматическое определение прокси». Сохранить, применить.
На iPhone: Настройки - Wi-Fi - значок информации рядом с сетью - прокси - «Выкл.». Настройка привязана к конкретной сети, поэтому в кафе и дома её проверяют отдельно.
На Android: долгое нажатие на сеть - «Изменить» - «Дополнительные параметры» - «Прокси» - «Нет». В некоторых прошивках пункт спрятан в «Расширенных настройках».
Мобильные операторы прокси не ставят. Если на телефоне трафик идёт через узел, виноват профиль Wi-Fi, приложение с собственным туннелем или установленный профиль конфигурации. Последний смотри в Настройки - Основные - VPN и управление устройством.
Отключил, а интернет не заработал
Бывает, что все галочки сняты, а сайты не открываются. Тогда дело не в прокси как таковом, а в том, что после него осталось.
Первое - DNS. Если узел был прописан вместе с собственным DNS-сервером, после отключения система продолжает стучаться в недоступный адрес. Лечится сбросом: в Windows - ipconfig /flushdns в консоли, на macOS - sudo dscacheutil -flushcache.
Второе - VPN-клиент. Многие держат функцию, которая автоматически возвращает системный прокси при переподключении. Закрой клиент полностью, проверь настройки заново и только потом запускай.
Дальше PAC-файл по ссылке. Даже при выключенном тумблере в некоторых сборках Windows остаётся запись в реестре, и она подхватывается при старте. Проверь ветку параметров подключения в редакторе реестра или прогони сброс сети через Параметры - Сеть - Сброс сети.
Четвёртое - групповые политики. На рабочем ноутбуке настройка прилетает с домена и восстанавливается при каждой перезагрузке. Тут без администратора сети не обойтись, и это нормально.
Пятое - антивирус с веб-щитом. Он может держать собственный локальный прокси для проверки трафика и не сообщать об этом. Отключается в настройках защитника, в разделе про сеть или веб-защиту.
Прокси в терминале и коде - отдельный разговор
Если работаешь с командной строкой, помни про переменные окружения. HTTP_PROXY, HTTPS_PROXY, ALL_PROXY и их версии в нижнем регистре живут в профиле оболочки и переопределяют всё, что настроено в системе. Смотри вывод env или printenv и убирай лишние строки из .bashrc, .zshrc или профиля PowerShell.
В Python библиотека requests уважает эти переменные по умолчанию. Скрипт внезапно пошёл через старый узел, а в коде ничего не менялось - ищи переменную окружения. В curl есть флаг --noproxy: отключает прокси для конкретного запроса, не трогая окружение.
В Docker и CI-пайплайнах прокси часто прописан в конфиге демона или в секретах репозитория. Отлаживая сборку, проверяй не только код, но и настройки среды.
Когда отключать не надо, а надо менять на нормальный
Есть сценарии, где прокси - не ошибка, а рабочий инструмент. Сбор данных с маркетплейсов, мониторинг цен, проверка рекламы в разных регионах, несколько рабочих аккаунтов одновременно. Вопрос не «как выключить», а «почему текущий работает так плохо».
Бесплатные публичные узлы - лотерея. Половина не отвечает, вторая половина отдаёт задержку в 2-3 секунды, а третья тихо логирует трафик (да, половин три). Для парсинга в 50 потоков это гарантированный провал: скрипт валится на таймаутах, а ты ищешь баг в коде, которого там нет. На Reddit в обсуждениях парсинга этот сюжет всплывает с завидной регулярностью: виноват не код, а узел.
Разница между плохим и нормальным узлом видна по протоколу. SOCKS5 не переписывает заголовки и работает на уровне сокета: меньше задержка, стабильнее соединение, поддерживается UDP. HTTP/HTTPS-прокси удобнее для веб-задач с авторизацией. Резидентные адреса нужны там, где важна география и «живость» адреса, датацентровые - где важна скорость и цена.
Для регулярных задач я держу под рукой каталог 3seller.com/proxy. Там можно отфильтровать узлы по стране, типу и протоколу, посмотреть задержку и взять под конкретную задачу, а не «что дали». Экономит вечер на переборе того, что не работает.
Порядок, который экономит время
Если проблема уже случилась, иди сверху вниз. Сначала системные настройки Windows или macOS - там чаще всего и сидит причина. Потом браузер со своими настройками: Firefox, Opera, Яндекс. Дальше выключи расширения и перезапусти браузер. Затем проверь IP и, если он всё ещё чужой, лезь в VPN-клиент и антивирус.
И записывай, что менял. Через месяц вернёшься к этой же машине и не вспомнишь, какой пункт трогал. Пара строк в заметках спасает полчаса повторного расследования.
Сама настройка занимает минуту. Время уходит на то, чтобы найти, где она спрятана именно у тебя. Если после всех четырёх уровней трафик всё ещё идёт мимо - сбрасывай сеть и проверяй групповые политики: это последние два места, где прячется настройка.