Первый раз я настроил прокси в 2013 году и потратил на это сорок минут. Не потому что сложно, а потому что в интернете не было ни одного нормального объяснения: либо «введите IP и порт», либо лекция про инкапсуляцию пакетов. На деле всё проще. Прокси - это посредник, который берет ваш запрос, подписывает его своим адресом и передает дальше. Настройка занимает пять минут, если знать, куда смотреть.
Дальше - конкретика: где настройки лежат на Windows, macOS и телефонах, какой протокол брать под задачу, как проверить результат и на чем сыпятся новички.
Что происходит, когда вы включаете прокси
Схема из трех шагов. Компьютер соединяется с прокси-сервером и просит открыть нужный сайт. Прокси подменяет данные клиента своими и обращается к сайту от своего имени. Ответ возвращается к вам, но сайт видит адрес прокси, а не ваш домашний IP.
Один нюанс новички пропускают. Прокси сам по себе не шифрует трафик. HTTP-прокси видит, куда вы ходите, и в теории может вести логи. SOCKS5 работает на уровне сокетов и не разбирает содержимое, но и он не дарит шифрование, если сверху не запущен TLS. Защиту дает HTTPS или отдельный туннель, прокси лишь меняет точку выхода в сеть.
Разница снимает половину вопросов. Люди ждут от прокси анонимности уровня VPN, а получают просто другой адрес выхода. Для парсинга этого достаточно. Для работы с чувствительными данными нужен еще и шифрованный канал.
HTTP или SOCKS5: что выбрать под задачу
HTTP-прокси понимает веб-трафик, умеет кэшировать и проще всего прописывается в браузере. SOCKS5 работает с любым трафиком, включая UDP и нестандартные порты, поэтому его берут для игр, клиентов с собственными протоколами и самописных приложений.
Правило, которое сложилось за годы практики: браузер, сбор данных с сайтов, работа с API - это HTTP или HTTPS. Всё, что не похоже на обычный веб-запрос, тянет на SOCKS5. Есть еще SOCKS4, но он без авторизации и без UDP, так что в 2027 году смысла в нем немного.
Отдельно про MTProto. Это протокол Telegram, и прокси в нем - не то же самое, что системный прокси. В приложении он настраивается отдельно и работает как промежуточный узел для трафика мессенджера. Системная настройка Windows или macOS на Telegram не распространяется, это разные уровни.
Windows: где спрятаны настройки и почему они не всегда работают
Порядок такой:
- Параметры → Сеть и Интернет → Прокси-сервер.
- В разделе ручной настройки нажать Настроить.
- Включить переключатель «Использовать прокси-сервер».
- Вписать адрес сервера и порт, при необходимости имя хоста.
- Нажать Сохранить.
После этого браузер при первом запросе к сайту может попросить логин и пароль от прокси. Если сервис выдал их вместе с адресом, вводите и работаете.
Главная засада: системный прокси в Windows подхватывают не все программы. Chrome и Edge берут настройки из системы. А клиенты, которые ходят через собственные библиотеки, часто игнорируют эти параметры и лезут напрямую. Проверяется просто: включаете прокси, открываете сайт проверки IP в браузере и в интересующем приложении. Если адреса разные, приложение прокси не видит.
Второй момент - поле исключений для локальных адресов. Там по умолчанию уже есть список. Если у вас внутренний сервис или домашняя сеть, убедитесь, что они в исключениях, иначе часть запросов уйдет не туда и вы получите странные таймауты.
macOS: вкладка, которую легко пропустить
Системные настройки → Сеть → выбрать активное подключение (Wi-Fi или Ethernet) → Подробнее → вкладка Прокси. Дальше выбираете протокол: Веб-прокси (HTTP) и Защищенный веб-прокси (HTTPS) для браузера, SOCKS для остального. Вводите адрес и порт. Если сервер требует авторизации, ставите галочку и заполняете логин с паролем. ОК, затем Применить.
Мелочь, которая экономит нервы. На macOS настройки привязаны к конкретной сетевой службе. Настроили для домашнего Wi-Fi, пришли в офис, там другая служба, и прокси не работает. Проверяйте, для какой сети включен профиль, а не только сам факт включения.
Android и iOS: настройка живет внутри Wi-Fi
На телефонах системного прокси, как в Windows, нет. Настройка хранится внутри конкретной беспроводной сети. Android: долгое нажатие на сеть → Изменить → Дополнительные параметры → Прокси в положение Вручную → хост, порт, при необходимости логин и пароль. iOS: Настройки → Wi-Fi → значок i рядом с сетью → Настройка прокси → Вручную.
С мобильным интернетом такой фокус не пройдет: в стандартном интерфейсе настроек прокси там нет. Для мобильных сценариев берут приложение с собственным клиентом или поднимают соединение на уровне устройства.
Мобильные прокси - отдельная история. Адреса идут с сетей сотовых операторов, стоят дороже датацентровых. Для площадок, которые жестко фильтруют серверные диапазоны, разница бывает решающей. Брать их для теста верстки бессмысленно, а для работы с аккаунтами в соцсетях иногда без вариантов.
Браузеры: один профиль, один адрес
В Chrome и Firefox есть собственные настройки прокси, которые перекрывают системные. Firefox держит отдельный раздел в настройках, там же задается список исключений и SOCKS5 с удаленным DNS.
Прием, которым пользуюсь постоянно: отдельный профиль браузера под каждый прокси. В Chrome это отдельный ярлык с ключом --proxy-server, в Firefox контейнеры или отдельные профили. Так можно держать рабочий аккаунт на одном адресе, тестовый на другом и не путаться. Заодно снижается риск, что площадка свяжет аккаунты по одинаковому отпечатку IP.
Про ключ --proxy-server подробнее. В свойствах ярлыка Chrome дописываете --proxy-server="socks5://адрес:порт", и этот экземпляр браузера ходит через прокси, не трогая системные настройки. Удобно, когда нужно быстро сравнить поведение сайта с разных адресов, не переключая весь компьютер.
Telegram и WhatsApp: настройки внутри приложения
В Telegram прокси настраивается в разделе Данные и память → Прокси → Добавить прокси. Выбираете тип (MTProto или SOCKS5), вводите адрес, порт, при необходимости секрет и данные авторизации. После сохранения включаете переключатель, и мессенджер идет через узел.
WhatsApp отдельной настройки не имеет, он живет на системном прокси. На Android это значит, что прокси придется прописать в Wi-Fi, на iOS аналогично. Если системного прокси нет, вариант один: прокси на уровне сети или отдельное приложение-клиент.
Linux и консоль: proxychains решает почти всё
В консоли удобнее всего proxychains. Открываете /etc/proxychains4.conf, в секции [ProxyList] указываете свои узлы в формате тип адрес порт. Дальше запускаете нужную команду через proxychains4, и всё приложение идет через прокси.
Проверка занимает секунду: proxychains4 -q curl ipinfo.io покажет адрес выхода. Совпал с адресом прокси, значит работает.
Для разовых задач хватает переменных окружения: export http_proxy и export https_proxy с адресом и портом. Большинство CLI-утилит их подхватывают. Для git есть свои настройки, для docker свой конфиг, для apt свои параметры. Универсального переключателя нет, но принцип один и тот же: приложение должно узнать, куда идти за соединением.
Прокси в коде: Python и не только
В requests всё делается через параметр proxies: словарь с ключами http и https и значениями вида http://логин:пароль@адрес:порт. Если запросов много, берите requests.Session и вешайте прокси на сессию. Иначе каждый вызов открывает новое соединение, а на сотне запросов это превращается в заметные задержки.
В асинхронном коде на httpx или aiohttp прокси задается на клиента целиком. Дальше главное - ротация. Если вы дергаете сайт с одного адреса сотнями запросов в минуту, никакой прокси не спасет от бана. Нужен либо пул адресов с ротацией, либо нормальный rate limit. Второе часто эффективнее и дешевле, чем покупать лишний трафик.
На практике я делаю так: сессия с прокси, пауза между запросами от 0.5 до 2 секунд, ротация адреса раз в 50-100 запросов, обработка кодов 403 и 429 с повторной попыткой на другом узле. Такой сетап живет месяцами там, где наивный скрипт умирает за десять минут.
Парсинг и мультиаккаунты: где прокси реально помогает
Сбор открытых данных - самый частый сценарий. Маркетплейсы, агрегаторы, сайты конкурентов отдают цены и наличие. Скрипт, который забирает пять тысяч карточек товара, с одного IP упирается в капчу уже на второй сотне. С пула адресов и нормальными паузами сбор идет стабильно.
Мультиаккаунты в рекламе и на площадках - второй сценарий. Тут работает связка: отдельный адрес, отдельный профиль браузера, отдельные куки. Прокси сам по себе не спасет, если вы заходите в один и тот же браузер с двух аккаунтов. Площадка свяжет их по отпечатку, а не по IP.
Третий сценарий спрашивают реже, но он есть. Работа с публичного Wi-Fi в кафе или аэропорту. Трафик идет через чужое оборудование, и лишний посредник с шифрованием не помешает, особенно если речь о корпоративном ноутбуке с рабочими данными. Тут прокси работает как дополнительный слой приватности.
Свой узел на VPS: когда это оправдано
Иногда проще поднять прокси самому. Берете VPS, ставите 3proxy или squid, настраиваете авторизацию по логину и паролю, закрываете порт от внешнего мира. Получаете стабильный адрес, который знаете только вы. Минус один: адрес датацентровый, и часть площадок его не любит.
Для корпоративного узла это рабочий вариант. Команда ходит через один шлюз, вы видите логи, контролируете политику. Для парсинга тоже годится, если сайт не фильтрует серверные диапазоны. А вот для работы с аккаунтами на строгих площадках свой VPS почти всегда проигрывает резидентским адресам.
Резидентские, датацентровые, мобильные: разница в задаче, а не в цене
Датацентровые - адреса из облаков и серверных. Быстрые, дешевые, стабильные. Минус в том, что многие площадки держат базы таких диапазонов и режут их на входе. Для парсинга открытых сайтов, работы с API и тестов подходят отлично.
Резидентские приходят из реальных домашних подключений. Дороже, медленнее, но площадки относятся к ним лояльнее. Хороши там, где нужна максимальная похожесть на обычного пользователя.
Самый дорогой вариант - мобильные, они идут с сетей сотовых операторов. И самое высокое доверие со стороны сайтов. Брать их стоит, когда остальные типы уже не проходят.
Параметры, на которые смотрю перед покупкой: география (нужен ли конкретный город или страна), модель оплаты за трафик или за адрес, поддержка SOCKS5, авторизация по логину и паролю, скорость отклика и лимит одновременных соединений. Последнее часто забывают, а именно на нем ломается параллельный парсинг.
Где брать прокси и на что смотреть в каталоге
Не раз наступал на грабли с сервисами, где витрина красивая, а половина адресов мертва уже на второй день. Поэтому смотрю на три вещи: сколько живет адрес, есть ли внятная ротация и дают ли тест на пару дней. Каталог прокси по ссылке https://3seller.com/proxy как раз из тех, где параметры видны сразу: тип, гео, протокол, цена. Не приходится угадывать, что внутри.
Перед покупкой большого пакета всегда берите минимум и проверьте на своих задачах. Один и тот же адрес может отлично работать для сбора карточек товаров и моментально ловить капчу на другом сайте. Дело не в качестве прокси, а в том, как конкретная площадка смотрит на диапазон.
Как проверить, что прокси реально работает
Открываете любой сервис проверки IP и смотрите адрес выхода. Совпал с тем, что выдал провайдер, значит настройка применилась. Не совпал, ищите ошибку в порту, логине или в том, что приложение игнорирует системные настройки.
Дальше проверьте DNS. Если прокси HTTP, запросы на разрешение имен могут уходить мимо него, и геозависимые сайты все равно определят ваш регион. В SOCKS5 есть удаленное разрешение имен, и это одна из причин, почему его любят для работы с сайтами, которые смотрят на страну.
Третий тест на скорость. Замерьте время отклика до прокси и до целевого сайта. Если разница в разы, узел перегружен или далеко. Для парсинга это критично, потому что задержка умножается на количество запросов.
Ошибки, которые я вижу чаще всего
Путать прокси и VPN. VPN шифрует весь трафик устройства, прокси работает точечно и только для того приложения, которому вы его прописали. Настроили в браузере, значит браузер и идет через узел, остальное нет.
Вторая классика - настроить и не проверить. Половина вопросов в поддержку начинается с «я все сделал, не работает», а на деле переключатель не сохранен или выбран не тот профиль сети.
Гнать трафик с одного адреса в десять потоков и удивляться бану. Прокси не делает вас невидимым, он просто меняет адрес. Поведение при этом остается поведением бота.
Брать прокси без авторизации. Открытый прокси в интернете - это либо медленно, либо небезопасно, либо и то и другое. Нормальный сервис всегда дает логин с паролем или привязку по IP.
И самая незаметная ошибка - забыть про часовой пояс и язык браузера. Прокси из другой страны при русской локали и московском времени выглядит подозрительно. Мелочь, но именно на таких мелочах сыпятся аккаунты.
Короткий чек-лист перед первым запуском
- Проверили адрес выхода до и после настройки.
- Убедились, что нужное приложение реально использует прокси.
- Задали паузы между запросами и лимит потоков.
- Продумали ротацию, если работаете с пулом адресов.
- Сохранили логин и пароль в менеджере паролей, а не в блокноте.
Начните с одного адреса и одной задачи. Настройте, проверьте, посмотрите на поведение сайта. Когда поймете, как это работает на вашем сценарии, добавляйте пул и ротацию. Каталог прокси на 3seller.com/proxy удобен тем, что можно взять небольшой объем под тест, а резидентский пакет или датацентровый - решать уже по результатам. Экономит и деньги, и время на переделку настроек.