Ситуация классическая. Купил прокси, открыл кабинет, увидел строку из адреса, порта, логина и пароля - и завис. Куда это вставлять: в браузер, в систему или в конкретное приложение? Ответ зависит от того, что должно ходить через узел - одна вкладка или весь трафик с машины.
Ниже то, что я проделывал десятки раз на разных машинах: Windows 11, macOS, Linux, браузеры, телефоны, мессенджеры. С путями по меню и названиями полей, а не с общими словами.
Данные, которые нужны до первого клика
Из личного кабинета поставщика вы выносите четыре значения: адрес (он же host или IP), порт, логин, пароль. Иногда вместо пары логин-пароль дают один длинный ключ авторизации. Формат другой, суть та же.
Отдельно посмотрите на протокол. HTTP и HTTPS работают на уровне приложения. SOCKS5 живёт на уровне сессии и пробрасывает любой TCP-трафик, включая UDP через поддерживающие это узлы. Если в кабинете написано socks5, а вы вставляете данные в поле HTTP в настройках Windows, соединения не будет. Самая частая причина из тех, что я видел.
Адрес и порт разделяются двоеточием. Не точкой и не пробелом. Звучит смешно, пока не посидишь полчаса над ошибкой, где вместо двоеточия стоит точка.
Как добавить прокси в Windows 11
Пуск, Настройки, Сеть и Интернет, Прокси-сервер. Дальше блок «Настройка прокси вручную», там кнопка «Начать настройку». В некоторых сборках она называется «Изменить».
Включаете тумблер «Использовать прокси-сервер». В поле «Адрес» вводите хост, в поле «Порт» число. Если провайдер требует авторизацию, Windows спросит логин и пароль при первом обращении. Отдельных полей для них в этом окне нет, и это сбивает с толку.
Ниже строка «Не использовать прокси-сервер для адресов, начинающихся с». Сюда через точку с запятой перечисляете локальные адреса и внутренние домены. В корпоративной сети без этого списка вы отрежете себе доступ к принтеру, вики и тестовому стенду. Проверено на живых людях.
Нажимаете «Сохранить». Проверка простая: откройте браузер и зайдите на сервис, который показывает ваш адрес. Он должен отличаться от того, что вы видите без прокси. Совпадает - где-то опечатка.
Есть нюанс, о котором мало кто говорит. Системные настройки Windows подхватывают не все приложения. Часть софта лезет в сеть напрямую, потому что у него своя реализация HTTP-клиента и свой стек. Нужен трафик конкретной программы, а не всей машины - системных настроек недостаточно.
Расширенные настройки и разные узлы для разных протоколов
В том же окне есть кнопка «Дополнительно». Там можно задать отдельный узел для HTTP, HTTPS, FTP и SOCKS. Полезно, когда в руках разные типы прокси под разные задачи. Один HTTP для веб-запросов, один SOCKS5 для приложений, которые умеют только его.
Заполнять все четыре поля не нужно. Оставляйте пустыми те, что не используете. Иначе Windows попробует применить пустое значение и получит ошибку.
Флаг «Не использовать прокси-сервер для локальных адресов» оставьте включённым, если не понимаете, зачем он. Отключают его в редких случаях, когда весь трафик без исключений должен идти через один узел, включая обращения к localhost-сервисам.
macOS: то же самое, но в другом месте
Системные настройки, Сеть, выбираете активное подключение (Wi-Fi или Ethernet), кнопка «Подробнее», вкладка «Прокси».
Дальше список протоколов: Web proxy (HTTP), Secure web proxy (HTTPS), FTP proxy, SOCKS proxy, Automatic proxy configuration. Ставите галочку напротив нужного, вводите адрес и порт.
Важно не пропустить галочку «Прокси-сервер требует пароль». Она открывает поля для логина и пароля. Без неё macOS попробует подключиться без авторизации и получит отказ, а вы будете думать, что узел не работает.
Кнопка «ОК», потом «Применить». Без «Применить» настройки не вступят в силу. Окно просто закроется, а конфиг останется прежним. На этом месте спотыкаются чаще, чем на вводе данных.
Linux: два разных подхода
Первый способ - переменные окружения. Для консольных утилит, curl, wget, git, работает почти всегда. Экспортируете http_proxy и https_proxy в формате http://логин:пароль@адрес:порт. Для разовой сессии хватит. Для постоянного использования прописываете в ~/.bashrc или ~/.zshrc.
Не забудьте no_proxy для localhost и внутренних подсетей. Иначе часть скриптов начнёт ломаться на ровном месте, и вы будете искать причину в коде, а не в окружении.
Второй способ - proxychains. Он перехватывает сетевые вызовы через LD_PRELOAD и прогоняет их через цепочку узлов. Конфиг лежит в /etc/proxychains4.conf.
В секции [ProxyList] в конце файла добавляете строки в формате: тип, адрес, порт. Поддерживаются socks4, socks5, http. Нужна авторизация - в той же строке через пробел указываете логин и пароль. Дальше запускаете команду через proxychains4 -q. Флаг -q убирает служебный вывод, чтобы не мешал читать результат.
Минус proxychains в том, что он не дружит со статически слинкованными бинарниками и частью приложений на Go. Команда упорно ходит напрямую - дело в этом, а не в ваших настройках.
Браузер: отдельный профиль, отдельные настройки
У Chrome и большинства браузеров на Chromium по умолчанию стоит системный прокси. То есть браузер берёт настройки из операционной системы. Настроили Windows - Chrome уже ходит через узел. Ничего дополнительно делать не нужно, и это многих путает.
Другое дело, когда прокси нужен только в браузере и только в одном профиле. Тогда запускаете браузер с ключом --proxy-server=адрес:порт и отдельной директорией профиля. Получаете изолированный экземпляр, который не трогает систему и остальные окна.
В Firefox своя история. Настройки, внизу «Настройки сети», кнопка «Настроить». Там ручная конфигурация отдельно для HTTP, HTTPS, FTP и SOCKS, либо PAC-файл.
PAC - это скрипт, который решает, куда отправлять каждый конкретный запрос. Удобно, когда часть трафика должна идти напрямую, а часть через узел. Для парсинга и работы с большим количеством доменов экономит нервы и время на переключения.
И отдельно про расширения-переключатели. Их десятки, они удобны, но каждое живёт по своим правилам. Некоторые игнорируют авторизацию в URL. Некоторые не умеют SOCKS5 с логином. Расширение не подключается, а системные настройки работают - дело в расширении, а не в прокси.
Телефон: Android и iOS
Android. Настройки, Сеть и интернет, Wi-Fi (или Мобильная сеть), выбираете активную сеть, «Изменить», «Дополнительные параметры», «Прокси», «Вручную». Вводите хост, порт, при необходимости логин и пароль. Сохраняете.
Ограничение: настройка привязана к конкретной Wi-Fi сети. Переключились на мобильный интернет - прокси перестал действовать. Для постоянной работы нужны приложения, которые поднимают локальный туннель, но это уже другой сценарий и другие настройки.
iOS. Настройки, Wi-Fi, синяя кнопка с буквой i рядом с сетью, внизу «Настройка прокси», «Вручную». Поля «Сервер», «Порт», «Аутентификация». То же ограничение с привязкой к конкретной сети.
Telegram и WhatsApp: где это внутри приложения
Telegram на Android: Настройки, Данные и память, Прокси. Включаете «Использовать прокси», выбираете «Добавить прокси». Тип SOCKS5 или MTProto. Вводите сервер, порт, логин и пароль, если они есть. Сохраняете, потом нажимаете «Подключиться».
В десктопной версии путь похожий: Настройки, Продвинутые настройки, Тип подключения, «Прокси», «Добавить прокси». Интерфейс чуть отличается между Windows и macOS, логика одна.
WhatsApp на Android: Настройки, Хранилище и данные, Прокси. Включаете «Использовать прокси», вводите хост и порт, нажимаете «Сохранить». В iOS такого пункта в меню нет, там настройка идёт через системный уровень.
Вокруг MTProto много путаницы, поэтому уточню. Это не просто прокси, а протокол с собственной схемой шифрования и мультиплексированием потоков. Он даёт меньше задержек на нестабильных каналах за счёт того, что не переустанавливает соединение при каждом сбое. Для корпоративного узла на своём VPS это разумный выбор. Для парсинга сайтов нет, там нужен обычный HTTP или SOCKS5.
SOCKS5 против HTTP: что выбирать под задачу
HTTP-прокси понимает только HTTP и HTTPS. Он видит заголовки, может их менять, кэшировать ответы, применять фильтры. Для веб-задач этого хватает, и настройка проще.
SOCKS5 работает на уровне TCP-сессии и не вникает в содержимое. Пробрасывает любой протокол: почту, SSH, игровой трафик, кастомные бинарные протоколы. Плюс умеет UDP-ассоциации, что важно для голосовых сервисов и части игр.
По шифрованию расклад такой. SOCKS5 сам по себе не шифрует, он только перенаправляет. Шифрование появляется на уровне выше, в HTTPS или в самом протоколе приложения. Нужен зашифрованный канал до узла - это отдельная настройка, обычно через SSH-туннель или собственный VPS с настроенным сервером.
Для балансировки нагрузки в парсинге SOCKS5 удобнее. Можно держать пул узлов и раскидывать запросы по ним, не привязываясь к прикладному протоколу. Для простой работы в браузере хватит HTTP, и городить SOCKS5 там не за чем.
Корпоративный узел на своём VPS: что настроить на стороне сервера
Если вы поднимаете прокси сами, а не покупаете готовый, на сервере нужен демон, который слушает порт и умеет авторизацию. Для SOCKS5 это обычно ssh с ключом -D или специализированный сервер, для HTTP вариантов тоже хватает.
Три вещи, которые обязательно сделать. Закрыть доступ по IP-белому списку, включить авторизацию по логину и паролю, ограничить число одновременных соединений. Без этого ваш узел через сутки найдут сканеры и превратят в бесплатный релей для чужого трафика. Проверено, я видел такие серверы с нагрузкой в сотни мегабит и владельцем, который ничего не понимал.
Второй момент - логи. По умолчанию демоны пишут в лог каждый запрос, и на активном узле это гигабайты в сутки. Отключите лишнее или настройте ротацию, иначе диск закончится в самый неподходящий момент.
Как проверить, что прокси реально работает
Браузер - плохой индикатор. Он может отдать страницу из кэша и создать ложное чувство, что всё в порядке. Проверять надо на запросе, который точно идёт в сеть.
Из консоли это curl с флагом -x и адресом узла, плюс сервис, возвращающий ваш внешний адрес. Ответ должен содержать адрес прокси, а не ваш домашний. Вернулся ваш - узел не подключился, а curl молча пошёл напрямую.
Второй тест - время ответа. Запрос висит 10 секунд и падает по таймауту - скорее всего порт закрыт или узел не принимает ваш адрес. Третий тест - авторизация. Специально введите неверный пароль. Ошибка не изменилась - значит авторизация вообще не запрашивается, и вы ходите не туда.
Ошибки, из-за которых ничего не работает
Первая и главная: перепутан тип прокси. Ввели данные SOCKS5 в поле HTTP. Симптом - браузер молча не открывает страницы или выдаёт таймаут без объяснений.
Вторая: неверный формат авторизации. В некоторых приложениях логин и пароль вводятся в отдельные поля, в других вшиваются в URL как логин:пароль@адрес:порт. Вставили не туда - сервер вернёт 407.
Лишний http:// в поле «Адрес» ломает разбор строки. Windows ждёт чистое имя хоста или IP, без префикса. Третья по частоте ошибка после двух предыдущих.
Четвёртая: узел привязан к вашему адресу. Многие провайдеры требуют авторизацию по IP, то есть прокси работает только с того адреса, который вы указали в кабинете. Сменили интернет или включили мобильную точку доступа - соединения нет. Скорее защита от перепродажи, чем баг.
Пятая: локальный фаервол или антивирус режет исходящие на нестандартный порт. Проверяется просто. Пробуете подключиться к тому же узлу через telnet или curl из консоли. Консоль соединяется, а браузер нет - дело в браузере или в его настройках.
Зачем это всё в рабочем контексте
Настройка прокси не самоцель, а инструмент под конкретную задачу. Самая частая - сбор данных. Парсинг цен, мониторинг выдачи, отслеживание упоминаний бренда. Здесь важен пул адресов, ротация и стабильность. Иначе сайт быстро начнёт отдавать заглушки вместо контента.
Вторая задача - тестирование. Проверить, как сайт выглядит для пользователя из другого региона, можно только через узел в этом регионе. Третья - работа с несколькими рекламными кабинетами, где важен чистый адрес на каждый профиль.
Четвёртая - защита трафика в публичных сетях. Когда подключаетесь к Wi-Fi в кафе или аэропорту, трафик до вашего собственного узла на VPS закрывает локальный сегмент от любопытных соседей. Для сотрудников в разъездах это базовая гигиена, а не паранойя.
Под каждую задачу нужны разные узлы. Для парсинга резидентские или мобильные, чтобы выглядеть как обычный пользователь. Для внутренних задач датацентровые, они быстрее и дешевле. Для регионального тестирования важна география, а не скорость.
На Reddit в тредах про сбор данных регулярно всплывает один и тот же вывод: пул из десяти случайных узлов проигрывает трём, подобранным под конкретный сайт. Ротация ради ротации только добавляет таймаутов.
Каталог, где можно посмотреть типы, страны и объёмы, лежит на 3seller.com/proxy. Там же видно, под какие протоколы подходит каждый вариант. Чтобы не купить SOCKS5, когда вам нужен HTTP, и наоборот.
Когда понимаешь, куда именно вводить адрес и порт, весь процесс занимает пару минут. Сложности начинаются не на этапе настройки, а на этапе выбора типа узла под задачу. Начните с одного прокси, прогоните через него реальный сценарий, посмотрите на задержки и на то, как ведёт себя целевой сервис. И только потом масштабируйте на пул. Десяток узлов, купленных наугад, обойдётся дороже, чем один, выбранный под конкретную работу.