Первый прокси я поднимал не ради красивой архитектуры, а чтобы офис из двенадцати человек перестал убивать интернет-канал роликами в обед. Поставил Squid на старую машину, включил кэш - трафик упал почти вдвое. Один компьютер начал работать за всех. С тех пор прошло больше десяти лет, а суть та же: прокси это посредник. Он стоит между вами и сайтом, принимает запрос, идёт на сайт от своего имени, получает ответ и отдаёт вам.
Из этой схемы растёт всё остальное: кэш, фильтрация, распределение нагрузки, тестирование, парсинг. Сайт видит не ваш адрес, а адрес прокси. Провайдер видит не сайт, а соединение с прокси. Каждый сценарий в реальной работе выглядит по-своему, поэтому разберу их отдельно.
Прокси это не VPN, и путаница тут дорого стоит
Самый частый вопрос от клиентов: «А чем это отличается от VPN?». Отличается, и заметно. VPN заворачивает весь трафик устройства в шифрованный туннель на уровне операционной системы. Прокси работает на уровне приложения или протокола. Браузер пошёл через прокси, а почтовый клиент и мессенджер отправились напрямую. Для одного проекта это плюс, для другого головная боль.
Второе отличие тоньше, и именно на нём ловят новичков. Прокси сам по себе не обязан шифровать. HTTP-прокси видит содержимое запроса в открытом виде, включая заголовки и адреса. HTTPS-прокси видит только домен, до которого вы стучитесь: дальше идёт туннель через CONNECT, а содержимое остаётся зашифрованным на стороне сайта. Свой собственный узел - нормально. Чужой бесплатный - вы отдаёте ему всё, что не зашифровано.
Что реально происходит с запросом
Схема короткая, объясню на пальцах. Вы открываете сайт, браузер обращается не к нему, а к прокси. Дальше по шагам.
- Клиент отправляет запрос на адрес и порт прокси-сервера, а не на сайт.
- Прокси разбирает запрос: домен, путь, заголовки. Если включена подмена адреса, подставляет свой IP.
- Прокси открывает соединение с целевым сервером и передаёт туда запрос. Сайт отвечает ему, а не вам.
- Ответ возвращается на прокси, тот отдаёт его клиенту и, если настроено кэширование, кладёт копию к себе.
В цепочке есть два места, где можно влиять на результат. Первое - заголовки. Прокси подчищает User-Agent, добавляет X-Forwarded-For или убирает лишнее, чтобы запрос выглядел обычным. Второе - кэш. Если страница лежала в кэше и не протухла, прокси отдаёт её сразу, не беспокоя сайт.
Кэш, который экономит деньги и нервы
Самый недооценённый сценарий. В офисе на 150-200 человек 30-40% трафика это повторные запросы: обновления, картинки, скрипты, одни и те же страницы. Прокси с нормальным кэшем срезает эту часть и разгружает канал. Одна компания на 180 человек после такой настройки отказалась от апгрейда тарифа у провайдера - канала хватило на всех. Экономия не космическая, но за год набегает прилично.
Сайтам кэш тоже полезен. Ресурс с прокси-прослойкой получает меньше одинаковых запросов и держит нагрузку ровнее. CDN это не отменяет, но для внутренней инфраструктуры и корпоративных порталов работает отлично. Главное правило: кэшировать статику и осторожно с динамикой. Прокси, закэшировавший корзину интернет-магазина, покажет пользователю чужие товары. Такие истории случаются, и разбирать их потом неприятно.
Зачем прокси бизнесу, а не только сисадминам
В 2016-м я помогал команде, которая собирала цены с маркетплейсов. Они ходили с одного сервера и получали капчу каждые триста запросов. Поставили пул прокси с ротацией, разнесли запросы по разным адресам, настроили задержки. Задача закрылась за неделю, а не за месяц ручного тыкания.
На Reddit практикующие маркетологи отмечают, что пул с ротацией снимает не только капчу: он убирает проблему «один адрес - один лимит» и даёт сравнение выдачи по регионам. Ветка применений на этом не кончается. Проверка рекламы по регионам: запустили кампанию и хотите увидеть объявление в Новосибирске, а не только в Москве. Антифрод: служба безопасности пускает часть трафика через отдельные узлы, чтобы отследить подозрительные паттерны. Тестирование: разработчик смотрит, как приложение ведёт себя при задержке 200 мс или в другом часовом поясе. Инструмент один, настройки разные.
Типы прокси: разница не в названии, а в поведении
Практике полезны три разреза. Первый - протокол: HTTP, HTTPS, SOCKS5. Второй - уровень анонимности: прозрачный, анонимный, элитный. Третий - источник адреса: датацентр, резидентский, мобильный. Начнём с протоколов, вокруг них больше всего путаницы.
HTTP-прокси понимает только HTTP и HTTPS. Он разбирает заголовки, кэширует, фильтрует по URL. Для веб-задач этого хватает, а иногда и больше, чем нужно. HTTPS-прокси фактически туннелирует соединение и не лезет внутрь. SOCKS5 работает уровнем ниже: ему всё равно, что внутри - HTTP, торренты, игровой трафик, UDP. Он просто передаёт пакеты. Нужно гонять не только веб - смотрите на SOCKS5.
Отдельно про MTProto. Это протокол Telegram, и прокси для него настраивается иначе. Не веб-серфинг, а конкретное приложение: свой узел, своя авторизация, свой формат шифрования пакетов. В архитектуре это отдельный туннель, который держит соединение открытым и экономит задержку при переключении между дата-центрами мессенджера. Если поднимаете собственный VPS для корпоративного общения, MTProto стоит рассматривать как отдельный сервис, а не как «ещё один прокси».
Анонимность: прозрачный, анонимный, элитный
Прозрачный прокси не скрывает ваш IP и сам сообщает сайту, что он прокси. Звучит бесполезно, но для корпоративной фильтрации это ровно то, что нужно: админ видит, кто куда ходил, а сайт получает заголовок X-Forwarded-For. Анонимный прячет ваш адрес, но может выдать себя заголовком Via. Элитный не палится ничем: сайт видит обычного посетителя.
«Элитность» важна для парсинга и сервисов, которые агрессивно фильтруют трафик. Внутренней сети она не нужна и только мешает диагностике. Гнаться за максимальной скрытностью там, где задача в другом, смысла нет. Это как тонировка на служебной газели: ехать быстрее не станет.
Настройка в браузере: куда нажимать
Chrome и большинство браузеров на Chromium берут настройки из системы. На Windows это Параметры → Сеть и Интернет → Прокси, дальше вручную указываете адрес и порт. На macOS - Системные настройки → Сеть → Дополнительно → Прокси. Для корпоративного узла там же ставится исключение для локальных адресов, иначе внутренние сервисы начнут ходить через прокси и тормозить.
Firefox удобнее для тестов: у него свои настройки, систему он не трогает. Настройки → Основные → Настройки сети → Настроить вручную. Один профиль гоняет трафик через прокси, остальные работают напрямую. Проверяете рекламу или вёрстку по регионам - не нужно переключать весь компьютер, экономия времени заметная.
Telegram: что настраивается внутри приложения
В Telegram есть отдельный раздел для прокси: Настройки → Данные и память → Прокси. Там добавляется узел: тип SOCKS5 или MTProto, адрес, порт, при необходимости логин и пароль. Для корпоративного сервера это стандартный сценарий: компания поднимает свой узел, сотрудники добавляют его в приложение и работают через него, в том числе из кафе на публичном Wi-Fi.
Разница в архитектуре. SOCKS5 в Telegram - обычный туннель, MTProto - прокси на стороне самого мессенджера. Отличается место шифрования и скорость переключения между дата-центрами. При нестабильной сети MTProto даёт меньше рывков, потому что держит соединение иначе. Если корпоративный SOCKS5 уже есть, второй узел ради мессенджера обычно не нужен.
WhatsApp: отдельного переключателя нет
В WhatsApp нет собственного раздела для прокси, как в Telegram. Приложение ходит через системные настройки устройства или через корпоративный профиль, если телефон управляется MDM. Для WhatsApp вы либо настраиваете прокси на уровне Wi-Fi или мобильной сети, либо используете системное решение.
Для офиса это даже удобнее. Админ один раз прописывает профиль на устройствах - и всё общение идёт через корпоративный узел. Сотруднику ничего нажимать не нужно, а компания получает предсказуемый трафик и единые правила.
Публичный Wi-Fi и собственный узел
Когда вы подключаетесь к Wi-Fi в аэропорту или кофейне, трафик идёт через чужое оборудование. HTTPS спасает содержимое, но не метаданные: какие домены вы открываете, в какое время, с какого устройства. Прокси на собственном VPS добавляет ещё один слой: точка входа одна, правила одни, логи только у вас.
Прокси не заменит здравый смысл. Заходите на сайт по HTTP - никакой посредник не сделает передачу данных защищённой. Связка «свой узел плюс HTTPS плюс запрет на HTTP в браузере» закрывает большинство бытовых рисков. Я так делаю несколько лет и ни разу не пожалел.
Бесплатные прокси: арифметика, которая не сходится
Публичные списки прокси выглядят соблазнительно: бесплатно, много, бери и пользуйся. Кто-то платит за эти серверы, и платит не из доброты. Владелец бесплатного прокси видит ваш незашифрованный трафик, может подменять контент, вставлять рекламу, собирать логи. Скорость обычно такая, что парсинг превращается в медитацию.
В обсуждениях на Reddit всплывал неочевидный нюанс: часть бесплатных узлов живёт за счёт вставки рекламы в чужой трафик, и владелец узнаёт об этом месяцами. Отдельный риск - подмена ответа. Вы запрашиваете страницу банка, а получаете похожую страницу с другим адресом формы. Или скачиваете обновление, а внутри исполняемый файл с сюрпризом. Оправдать публичный бесплатный прокси в рабочей задаче я не могу. Для разового теста на коленке сойдёт, в бизнес-процесс это тащить нельзя.
Как выбрать прокси под задачу
Универсального ответа нет, но есть пять параметров, которые закрывают почти все вопросы.
- Протокол. Веб-задачи закрывает HTTP или HTTPS, всё остальное требует SOCKS5.
- Тип адреса. Датацентровые дешевле и быстрее, резидентские выглядят как обычные пользователи, мобильные нужны для самых капризных сервисов.
- География. Проверяете рекламу в регионе - адрес должен быть в этом регионе, а не «примерно рядом».
- Ротация. Для парсинга нужна смена адреса по таймеру или по количеству запросов, иначе смысла в пуле нет.
- Лимиты и скорость. Смотрите не на максимальную цифру в описании, а на то, сколько соединений держите одновременно.
И шестой неформальный параметр - поддержка. Пул падает в три часа ночи, у вас выгрузка, и скорость ответа важнее цены. По этому критерию я выбираю поставщиков несколько лет.
Где брать прокси и как не переплатить
Для рабочих задач держу под рукой каталог прокси с фильтрами по стране, типу и протоколу. Удобно собирать пул под конкретный проект: парсинг маркетплейсов, проверка объявлений или корпоративный узел для распределённой команды. В каталоге параметры каждого узла видны сразу, без переписки с менеджером на полдня.
Начинать советую с небольшого пула и одной задачи. Возьмите 10-20 адресов, прогоните реальный сценарий, посмотрите процент успешных ответов и задержку. Цифры устраивают - расширяйте. Так вы не попадёте на годовую предоплату за 500 адресов, которые потом окажутся не нужны. Подход отработан на десятке проектов.
С чего начать завтра: три вопроса перед покупкой
Прокси берёт запрос, идёт с ним на сайт от своего имени и возвращает ответ. Из этого факта растут кэш, фильтрация, распределение нагрузки, парсинг и защита трафика в чужой сети. Наличие прокси само по себе ничего не улучшает: важны настройки и понимание, какой трафик вы через него пускаете.
Дальше арифметика. Посчитайте, сколько запросов в сутки делает ваш проект и какие сайты посещает. Определите, нужен веб-протокол или SOCKS5. Решите, где хранить логи и кто их читает. После этого выбирайте пул, а не наоборот. От публичных бесплатных списков держитесь подальше: экономия там измеряется часами простоя и седыми волосами.