Самая частая история: ноутбук достался от уволившегося сотрудника, интернет вроде есть, а половина сайтов открывается через раз и курьерский трекинг не грузится. Или парсер на рабочей машине внезапно начал ловить 403 на ровном месте. Оба сценария в девяти случаях из десяти упираются в одно: машина сидит на прокси, а владелец об этом не знает. Ниже - как найти прокси сервер на компьютере руками, без гаданий и без установки сомнительных утилит.
Windows: адрес живёт в четырёх местах, а не в одном
Начни с нового интерфейса. Пуск, Настройки, Сеть и Интернет, Прокси-сервер. В Windows 11 этот экран показывает сразу всё: переключатель автоматического определения параметров, поле скрипта настройки и блок ручной настройки с адресом и портом. Тумблер «Использовать прокси-сервер» включён - машина ходит наружу не напрямую. Адрес и порт лежат прямо в полях, копируются и переносятся в любой клиент.
Дальше классика, которая никуда не делась с 2001 года. Панель управления, Сеть и Интернет, Свойства браузера, вкладка Подключения, кнопка Настройка сети. Тот самый системный апплет, из которого настройки читают Chrome, Edge, IE-режим и куча корпоративного софта. Окно одинаковое в Windows 7, 10 и 11 - поэтому в техподдержке просят открыть именно его. Здесь же снимается галка, если прокси нужно отключить. На Reddit в тредах для сисадминов это окно всплывает чаще любых инструкций: люди годами ищут прокси в настройках браузера, а он всё это время живёт в системном апплете.
Третий тайник - автоматическая конфигурация. Включено «Автоматическое определение параметров» или прописан адрес скрипта настройки - руками адрес не увидите. Скрипт придётся скачать: открываете URL из поля в браузере, получаете файл с расширением .pac, читаете блокнотом и ищете строку с функцией FindProxyForURL. Внутри - условия по доменам и тип протокола с адресом узла. Читается за минуту, если знать, что искать.
Четвёртый уровень - реестр, и он полезен, когда интерфейс врёт или заблокирован. Ветка HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings хранит параметры ProxyEnable, ProxyServer и AutoConfigURL. Быстрый способ посмотреть без Regedit - команда reg query с путём к ветке в командной строке. ProxyEnable равный единице означает, что системный прокси активен. Ноль - отключён, даже если поля в интерфейсе чем-то заполнены.
macOS: всё в одном окне, но за кнопкой Дополнительно
В свежих версиях macOS путь такой: Системные настройки, Сеть, активное подключение (Wi-Fi или Ethernet), затем Дополнительно и вкладка Прокси. В старых системах логика та же, только называется Системные предпочтения. Дальше список протоколов с чекбоксами: веб-прокси HTTP, защищённый HTTPS, SOCKS, FTP. Активный протокол показывает сервер и порт, рядом кнопка для ввода учётных данных, если сервер требует авторизацию.
Ниже в том же окне живёт блок автоматической настройки прокси с полем для URL файла конфигурации. Аналог PAC из Windows, логика чтения ровно та же: скачать, открыть текстовым редактором, найти правило с адресом. Поле заполнено, а чекбоксы протоколов пустые - трафик маршрутизируется скриптом, и адрес надо искать именно в нём.
Есть приём для тех, кто дружит с терминалом. Команда scutil --proxy выводит текущую конфигурацию системы одной простынёй, без похода по меню. Удобно, когда нужно снять состояние с чужой машины по удалённому доступу и не кликать мышкой по видеозвонку. Там же видно, включён ли автоконфиг и какой адрес прописан для HTTP и SOCKS отдельно.
Linux: настройки есть на трёх уровнях сразу
Графическая часть зависит от окружения. В GNOME это Настройки, Сеть, Прокси, где переключатель между режимами Отключено, Вручную и Автоматически. Ручной режим показывает поля для HTTP, HTTPS, FTP и SOCKS, автоматический - строку с URL скрипта. В KDE логика похожая, только пункты называются иначе и лежат в параметрах системы.
Второй уровень - переменные окружения. Многие консольные инструменты вообще не смотрят в системные настройки, они читают http_proxy, https_proxy и all_proxy из окружения. Проверить просто: команда printenv с именем переменной покажет значение, если оно задано. Живут такие строки в ~/.bashrc, ~/.profile, /etc/environment или в конфиге конкретного демона - и именно там чаще всего обнаруживается прокси, о котором пользователь давно забыл.
Третий уровень - настройки пакетных менеджеров и системных служб. APT, Docker, git, npm и pip умеют держать собственные параметры подключения, независимо от графического интерфейса. Браузер ходит нормально, а git push висит - смотрите конфиг git и переменные окружения, а не системные настройки сети.
Браузер может жить своей жизнью
Chrome и Edge по умолчанию используют системные настройки. В меню Настройки, Система есть кнопка открытия параметров прокси компьютера - она просто перебрасывает в то самое окно Windows или macOS, которое мы разбирали выше. Нюанс: расширения-переключатели держат собственный список профилей и подменяют маршрут на уровне вкладки. Системный прокси выключен, а трафик всё равно идёт через сервер - почти наверняка виновато расширение.
Firefox исторически игнорирует систему и настраивается отдельно. Настройки, Основные, в самом низу Настройки сети, кнопка Настройки соединения. Три варианта: без прокси, ручная настройка с полями для HTTP, HTTPS и SOCKS, автоматическая конфигурация по URL. В корпоративной среде сюда же прилетает конфиг через файл политик - поля становятся серыми, рядом появляется пометка, что параметры заданы администратором.
Отдельно про локальные клиенты. Локальный адрес в настройках вместо внешнего означает, что на машине крутится приложение, которое поднимает туннель и отдаёт трафик в локальный порт. В системных настройках такие клиенты часто не показываются вовсе, работают как отдельный сервис. Проверяется через список слушающих портов в терминале или через диспетчер задач: ищите процесс, в названии которого есть proxy, tunnel или имя конкретного клиента.
PAC-файл - это просто JavaScript, и его можно прочитать
Автоматическая конфигурация пугает людей больше, чем нужно. По сути это текстовый файл с функцией, которая получает адрес сайта и возвращает строку с типом протокола и адресом узла или DIRECT. Всё. Разберите файл глазами - найдёте несколько условий по доменам и список узлов, через которые маршрутизируется трафик. Иногда там же лежит резервный маршрут на случай недоступности основного.
Проблема в том, что не все скрипты отдаются статикой. Некоторые генерируются на лету и зависят от учётной записи или текущей сети. Тогда смотрите вкладку сети в инструментах разработчика: запрос за конфигурацией виден в списке, ответ открывается и читается целиком. Способ быстрее, чем выпрашивать адрес у администратора.
Когда настройки залочены политикой
На корпоративных машинах параметры часто управляются доменом, и поля в интерфейсе просто неактивны. Проверяется в браузере: страница политик в Chrome и Edge покажет список применённых правил. Если в списке есть параметр, отвечающий за прокси, руками вы ничего не измените до выхода из домена. В Windows аналогичную картину даёт редактор групповых политик, но открывать его без прав администратора бессмысленно.
Практический вывод простой: не ломайте управляемую конфигурацию, это видно в логах и заканчивается разговором с безопасниками. Нужен другой маршрут для рабочих задач - поднимайте отдельный профиль браузера или портативную сборку со своими настройками. Так вы не трогаете корпоративный контур и не рискуете доступом к внутренним ресурсам.
Проверка: трафик действительно идёт через прокси
Найти адрес - половина дела. Вторая половина - убедиться, что он рабочий и применяется. Самый быстрый способ: запросить у любого сервиса, показывающего внешний адрес, ответ через curl или через страницу в браузере. Адрес совпадает с прописанным - всё работает. Не совпадает - приложение не подхватило настройки, либо их перекрывает что-то ещё.
Типичные грабли, на которые я наступал сам и наблюдал у коллег. Первое: поменяли прокси, а приложение не перезапустили, и оно держит старое соединение. Второе: одновременно включён VPN, и маршрут уходит в туннель мимо прокси. Третье: код ответа 407 вместо 200 - это требование авторизации, а не поломка сервера. Четвёртое: указали SOCKS в поле для HTTP и удивляетесь, почему часть запросов проходит, а часть нет.
SOCKS5 и HTTP: разница, которую видно прямо в настройках
В окнах настройки протоколы перечислены отдельно, и это не формальность. HTTP-прокси работает на уровне приложения: понимает заголовки, умеет кэшировать ответы и передавать HTTPS через туннель. SOCKS5 работает ниже, на уровне сессии, и ему всё равно, что внутри - HTTP, FTP или бинарный поток. Отсюда разные сценарии: браузеру хватает HTTP, играм, мессенджерам и нестандартным протоколам нужен SOCKS5.
С задержками SOCKS5 аккуратнее при большом числе параллельных соединений: он не разбирает содержимое пакетов. Для парсинга это ощутимая разница - сотня потоков через HTTP-прокси упирается в обработку заголовков, через SOCKS5 идёт ровнее. Плюс нормальная аутентификация по логину и паролю, что важно, когда узлом пользуется команда, а не один человек.
Зачем вообще искать прокси на своей машине
Сценариев ровно три, и все они про работу. Первый - отладка: нужно понять, почему конкретный сервис не открывается, и исключить маршрутизацию. Второй - парсинг и сбор данных: антибот-защита режет по адресу, и без ротации узлов выборка встаёт через двадцать минут после старта. Третий - безопасность в публичных сетях: кафе, аэропорт, коворкинг, где трафик лучше гнать через собственный узел или корпоративный шлюз, а не отдавать в открытый Wi-Fi.
Отдельная история - геозависимые проверки. Нужно посмотреть, как выглядит выдача или интерфейс сервиса для другого региона, и без узла в нужной стране это не сделать. Здесь важно не количество адресов, а качество: чистые подсети, нормальная скорость и предсказуемая геолокация.
Где брать узлы, чтобы не собирать их по помойкам
Бесплатные списки из открытых источников живут недолго и часто уже сидят в чёрных списках у антибот-систем. Экономия в триста рублей оборачивается вечером на перебор нерабочих адресов. Нормальный путь - готовый каталог с понятными фильтрами по стране, типу и протоколу. Например, каталог прокси 3seller.com: резидентные пулы для сервисов, чувствительных к репутации адреса, датацентровые под скорость и объём, мобильные для самых капризных площадок.
Практическая деталь, которую замечаешь только на дистанции: смотрите не на заявленное число адресов, а на ротацию по запросу и липкие сессии. Для парсинга каталогов нужна смена адреса каждые несколько минут, для работы с аккаунтами - удержание одного на сессию. И проверяйте поддержку SOCKS5, если планируете гонять через узел не только браузер.
Мелкие детали, которые экономят час
После смены настроек перезапускайте приложение целиком, а не вкладку. Системные параметры читаются на старте процесса, и старый маршрут может жить в памяти ещё долго. На Linux добавьте проверку переменных окружения в тот же чек-лист, что и графические настройки, иначе поймаете классику: браузер ходит, а скрипт нет.
Держите под рукой один быстрый способ проверки внешнего адреса и один способ проверить доступность узла. Этого хватит, чтобы за пару минут отделить проблему маршрута от проблемы самого сайта. Записывайте, какие настройки меняли: через неделю не вспомните, включали ли автоконфиг или это было в прошлом квартале. Живой пример из практики: коллега полчаса искал причину 407, а виновата была старая строка с переменной в ~/.zshrc, оставшаяся с прошлого проекта.
Начните с системных параметров сети, потом проверьте браузер, затем переменные окружения. В большинстве случаев адрес находится на первом шаге, и вся история заканчивается за две минуты вместо часа перебора гипотез.