Вторник, 11 утра, вы запускаете парсер на ноутбуке и видите: сорок процентов запросов вернули 429. Коллега на соседнем столе в это же время спокойно тянет те же данные через свой VPS. Разница в одном: у него трафик идёт через прокси, у вас нет. И пока вы читаете эту статью, где-то в вашей системе уже стоит забытая настройка пятилетней давности, которая тормозит всё.
Ниже разобрано, как поменять прокси на компьютере в каждом слое: системные настройки Windows и macOS, отдельные браузеры, терминал Linux и код на Python. Плюс разбор типовых ошибок, из-за которых «вроде включил, а не работает».
Windows 10 и 11: две настройки, которые живут отдельно, и это главная ловушка
Откройте Параметры, затем Сеть и Интернет, затем Прокси. Здесь три блока: автоматическое определение, скрипт настройки и ручная настройка. Переключатель «Использовать прокси-сервер» в третьем блоке покрывает браузеры на движке Chromium, Edge, системные приложения и большинство десктопных клиентов. Адрес и порт вводите в формате 185.х.х.х:8080, галочка «Не использовать для локальных адресов» по умолчанию спасает принтеры и локальные сервисы.
Подводный камень: netsh winhttp show proxy в командной строке покажет совсем другую картину. WinHTTP и WinINET (а это два разных стека) хранят настройки независимо. Первый используют службы, Windows Update, часть установщиков, второй — браузеры и пользовательские приложения. Если прокси включён только в интерфейсе, фоновые задачи продолжат ходить напрямую. Лечится командой netsh winhttp set proxy 185.х.х.х:8080 запущенной от администратора.
Третий слой — переменные среды. Некоторые утилиты (git, curl, npm) вообще не смотрят на системные настройки, только на HTTP_PROXY и HTTPS_PROXY. Задать их можно через тот же терминал: setx HTTPS_PROXY http://user:pass@185.х.х.х:8080. После этого перезапустите консоль, иначе переменная не подхватится.
Для отката: снять галочку в Параметрах и выполнить netsh winhttp reset proxy. Забыть про вторую команду — классическая причина истории «я выключил, а оно всё равно не грузится».
macOS: где живёт переключатель и почему его не видно
Системные настройки, раздел Сеть, выберите активное подключение (Wi-Fi или Ethernet), затем кнопка «Подробнее» или «Дополнительно», вкладка Прокси. Здесь шесть типов одновременно: HTTP, HTTPS, SOCKS, FTP, перенаправление и PAC. Включаете нужный, вводите адрес и порт.
Сеть в кафе подключена, дома другая — настройки применяются к конкретной службе (service), а не глобально. Переключились с Wi-Fi на Ethernet, и прокси будто исчез. Проверка через scutil --proxy в терминале покажет, что реально видит система для текущего интерфейса.
В поле «Исключения» перечисляйте домены через запятую: localhost, 127.0.0.1, *.local. Без этого отвалится Docker, часть IDE и локальные админки. Safari и Chrome на macOS берут системные настройки целиком, Firefox — нет, у него собственный конфиг.
Firefox, Chrome, Edge: три разные философии
Chrome и Edge наследуют системный прокси. Единственный способ поменять его только для браузера — флаг командной строки --proxy-server="socks5://185.х.х.х:1080" в ярлыке. Работает, но неудобно для ежедневного переключения.
Firefox независим. Настройки, в самом низу страницы — кнопка «Настройки сети», затем «Настроить вручную». Здесь же поле для SOCKS-хоста и галочка «Прокси DNS при использовании SOCKS 5». Включённая галочка означает, что доменные имена резолвятся на стороне прокси, а не у вас. Для парсинга это критично: без неё DNS-запросы утекают мимо туннеля и вы получаете совсем не тот география-сигнал, на который рассчитывали.
Расширения-переключатели (FoxyProxy и аналоги) удобны, если вы жонглируете десятком профилей для разных задач. Один профиль для работы, второй для тестов на своём VPS, третий для сбора данных. Правило простое: не ставьте расширения из случайных источников, они видят весь ваш трафик.
Linux: переменные среды, apt и браузеры отдельно
В терминале достаточно export https_proxy=http://user:pass@185.х.х.х:8080. Действует до закрытия сессии. Чтобы закрепить, добавьте строку в ~/.bashrc или ~/.zshrc. Для системного уровня (GUI-приложения GNOME) используйте gsettings set org.gnome.system.proxy mode 'manual' и далее host с port для каждой схемы.
Отдельная история — менеджеры пакетов. apt читает /etc/apt/apt.conf.d/95proxies, где прописываются строки вида Acquire::http::Proxy "http://185.х.х.х:8080";. Без этого sudo apt update продолжит ходить напрямую, даже если в браузере всё работает. Ещё один слой — sudo -E при запуске команд, чтобы переменные среды дошли до root-процесса.
Обсуждения на Reddit у системных администраторов регулярно всплывает одна и та же деталь: половина «прокси не работает» на Linux сводится к тому, что переменная задана в одной оболочке, а команда запускается из другой. Проверка простая: env | grep -i proxy в том же окне, откуда запускается сбойная команда.
SOCKS5 против HTTP: разница не в названии, а в том, что видит прокси
HTTP-прокси понимает сам протокол. Он видит метод, заголовки, URL. Для HTTPS работает через туннель CONNECT, где после установления соединения трафик уже не разбирается. Плюс: удобно кэшировать и фильтровать. Минус: конфигурация чувствительна к ошибкам, а корпоративные прокси нередко терминируют TLS и подсовывают свой сертификат.
SOCKS5 работает на уровне TCP-соединения. Ему всё равно, что внутри: HTTP, SSH, кастомный бинарный протокол, база данных. Поддерживает UDP (актуально для голосовых и части игровых протоколов), аутентификацию по логину-паролю и, при использовании socks5h, резолвинг DNS на стороне сервера. Для парсинга это дефолтный выбор: запросы уходят с консистентным набором признаков, без локального DNS-следа.
По задержке: SOCKS5 обычно быстрее HTTP CONNECT на десятки миллисекунд за счёт меньшего оверхеда. На одном запросе незаметно, на миллионе — уже счёт. Для загрузки тяжёлых медиафайлов в браузере разница неощутима, для высокочастотного парсинга и работы с API вопрос уже экономический.
Пример кода на Python с библиотекой requests:
proxies = {'http': 'http://185.х.х.х:8080', 'https': 'http://185.х.х.х:8080'}— HTTP-прокси для обоих протоколов.proxies = {'https': 'socks5h://user:pass@185.х.х.х:1080'}— SOCKS5 с удалённым резолвом DNS.- Для ротации подключайте
requests.Sessionи подменяйте прокси на каждый запрос или раз в N запросов.
Проверка через curl: curl -x socks5h://185.х.х.х:1080 https://api.example.com -v. Флаг -v покажет, установилось ли соединение с прокси и какой IP видит удалённая сторона. Если сертификат не совпадает с ожидаемым, ищите причину в корпоративной TLS-инспекции или в подменённом DNS.
Аутентификация и хранение паролей: где чаще всего утекает
Логин и пароль в URL вида http://user:pass@host:port — быстро, но небезопасно. Они попадают в историю оболочки, в логи приложений, в дампы трассировки. Для продакшена держите учётные данные в переменных среды или в секрет-менеджере, а не в коде.
Логи приложений при включённом прокси часто пишут полный URL запроса вместе с credentials. Перед тем как отдавать логи в систему мониторинга, настройте маскировку поля authorization и части URL до символа @. Мелочь, которая экономит инцидент.
Отдельно про публичный Wi-Fi в кафе и аэропортах. Прокси здесь не заменяет HTTPS, а дополняет: он скрывает от локального оператора, к каким доменам вы обращаетесь, и снижает риск атак на уровне локальной сети. При этом сам прокси-сервер видит все ваши запросы в открытом виде, если соединение идёт по HTTP. Только HTTPS до конечных точек.
Типичные ошибки, из-за которых настройка не работает
- Не тот тип прокси: адрес и порт HTTP-прокси вставлены в поле SOCKS. Симптом: соединение устанавливается, но запросы падают с ошибкой протокола.
- Локальные адреса не в списке исключений. Симптом: перестают открываться внутренние админки, Docker, dev-серверы.
- Кэш DNS: после смены прокси браузер ходит на старый IP. Очистите через
ipconfig /flushdnsна Windows или перезапуском браузера на других ОС. - PAC-файл, оставшийся с прошлой настройки: он автоматически возвращает всё назад. Проверьте оба адреса в системных настройках.
- Прокси не принимает соединения от вашего IP: нужен allow-list на стороне сервера. Частая история с корпоративными шлюзами.
- WinHTTP отдельно от WinINET на Windows: см. первый раздел.
- Проверка «открывается ли сайт» через браузер не показательна: браузер может кэшировать ответ. Используйте
curlи сервис определения внешнего IP.
Ротация и пул: почему один прокси хуже, чем пять
Одиночный прокси-сервер при интенсивных запросах почти гарантированно упрётся в лимиты целевой площадки. Практика простая: пул из 5-20 адресов, ротация по времени или по количеству запросов, sticky-сессии там, где важна авторизация. Sticky означает, что одна сессия держится за конкретный IP, пока не истечёт TTL, это нужно для логинов и корзины.
Для сбора данных используйте геораспределение: запросы идут через адреса в тех регионах, где находится аудитория. Это снижает количество капч и сохраняет корректность выдачи. Настройка простая: список прокси в конфиге приложения, ротация через пул, метрики по каждому узлу — время ответа, доля ошибок, доля 429. Узлы с высоким процентом ошибок выводятся из ротации автоматически.
Готовый пул удобнее собирать через каталог: 3seller.com/proxy — там подобраны прокси с фильтрами по географии, типу (HTTP, HTTPS, SOCKS5) и назначению. Для тестовых сценариев хватит минимального пакета, для регулярного парсинга — расширенного с ротацией.
Корпоративный сценарий: PAC-файл и WPAD
В компаниях прокси обычно настраивается не вручную, а через PAC-файл. По сути это JavaScript с функцией FindProxyForURL(url, host), которая для каждого адреса решает, идти напрямую или через конкретный шлюз. WPAD — автоматическое обнаружение PAC-файла по локальной сети. Включённый WPAD без контроля со стороны ИТ — потенциальная дыра: любой может подсунуть свой скрипт.
Если вам выдали PAC-файл, не копируйте его вручную. Уточните URL и вставьте в поле «Скрипт настройки» в Параметрах Windows или в соответствующее поле macOS. Тогда при смене правил на стороне ИТ всё обновится автоматически.
Как проверить, что новая настройка действительно работает
Первый шаг — внешний IP. Откройте сервис определения IP в браузере и сравните с тем, что показывает curl ifconfig.me из терминала. Совпадает — значит ни браузер, ни консоль не уходят мимо. Не совпадает — ищите рассинхрон между системным и терминальным уровнями.
Второй шаг — задержка. curl -w "%{time_connect} %{time_total}\n" -o /dev/null -s https://api.example.com покажет время установки соединения и полное время запроса. Сравните с прямым соединением: если разница в десятки миллисекунд, всё в порядке. Сотни миллисекунд — сервер перегружен или находится далеко.
Третий шаг — содержимое. curl -x ... https://api.example.com/headers вернёт заголовки, где видно реальный IP клиента и геолокацию. Если страна не та, что вы настраивали, проверьте, не сработал ли DNS-резолв локально (для SOCKS5 должна быть галочка «Прокси DNS» или схема socks5h в URL).
Что делать дальше
Начните с одного узла: системный прокси на рабочем компьютере, проверка через curl, замер задержки. Если работает — расширяйте до пула и переносите настройки в конфиги приложений. На 3seller.com/proxy можно подобрать прокси под тест и под продуктив: HTTP для браузерных сценариев, SOCKS5 для парсинга и высокочастотных вызовов API, отдельные пулы под конкретную географию и тип авторизации.
Настройки, которые вы трогали сегодня, скорее всего, придётся трогать снова. Заведите себе чек-лист: где менял, что проверял, чем откатывал. Это сэкономит вам полчаса в следующий раз, когда телефонный звонок «а почему у меня полсайта не открывается» застанет вас в разгар важного релиза.