Знакомая история: «купил сервер, вбил адрес в браузер — не работает». Дальше выясняется классика: авторизацию не включили, TLS не подняли, локальные адреса в исключения не добавили. Настройка web proxy состоит из трёх независимых слоёв — сервера, транспорта и клиента. Пропустите любой, и получите либо отказ в соединении, либо тихую утечку трафика мимо прокси.
web proxy нужен не только ради анонимности, у него есть инженерные задачи, за которые компании платят деньги. Разберу все три слоя по порядку, с деталями, которые всплывают только на второй или третьей попытке.
Что происходит в момент, когда вы включаете прокси
Прокси-сервер - промежуточное звено между клиентом и сайтом. Клиент отправляет запрос на прокси, тот идёт дальше, а сайт видит адрес прокси, а не ваш. Это база, но дальше начинаются нюансы.
Ключевое отличие web proxy от VPN в уровне работы. VPN заворачивает весь трафик машины на уровне IP. Web proxy работает на уровне приложения, понимает методы, заголовки, куки, умеет кэшировать ответы и фильтровать запросы по правилам. Отсюда его сильные стороны — тонкий контроль и логика на входе.
Для HTTPS обычный HTTP-прокси содержимое не видит. Он получает команду CONNECT и прокладывает туннель, внутри которого уже TLS. Если нужна инспекция содержимого, придется ставить свой корневой сертификат на клиентов. В корпоративной среде это отдельная история с юридическими и этическими нюансами.
Три сценария, где web proxy реально экономит время и деньги
Корпоративный шлюз. Прокси в связке с SWG (Secure Web Gateway) отсекает запросы к нежелательным категориям, проверяет скачиваемые файлы антивирусом, ведёт журнал. В компании на 200-300 человек такая схема снимает с сисадмина половину ручной работы и кучу входящих «а почему у меня не открывается».
Сбор данных и парсинг. Когда вы тянете цены с десятка площадок, один адрес умирает за пару часов. Пул прокси с ротацией распределяет нагрузку, снижает риск получить капчу. Тут важна стабильность и скорость отклика.
Защита трафика в чужой сети. Аэропорт, отель, кофейня — владелец точки доступа видит ваш трафик. Если он идёт через собственный узел по TLS, снаружи остаётся только шифрованный канал. Мобильный сотрудник с ноутбуком перестаёт быть лёгкой добычей.
HTTP, HTTPS или SOCKS5: определитесь до настройки
Разница не косметическая. HTTP-прокси понимает протокол, кэширует, умеет ACL и работу с заголовками. Подходит для браузеров и веб-приложений. HTTPS через него идёт как туннель CONNECT, содержимое не разбирается.
SOCKS5 работает на уровне сессии, ему всё равно, какой протокол внутри. Поддерживает UDP, даёт меньше накладных расходов, поэтому для игр, VoIP и нестандартных протоколов берут именно его. По задержке SOCKS5 обычно выигрывает, по управляемости проигрывает HTTP.
MTProto для Telegram - отдельная история со своей обвязкой и требованиями к секрету. А WEB-proxy для мессенджера работает поверх обычного веб-сервера.
Кэш, ACL и балансировка: что даёт HTTP-прокси сверху
Кэширование возвращает деньги на трафике и время на отклике. Статику, обновления пакетов, картинки прокси отдаёт из локального хранилища, внешний канал не нагружается. В офисе на сотню человек разница заметна уже в первый месяц.
ACL - это правила: кому можно, куда можно, в какое время. Через них закрывают соцсети в рабочие часы, отсекают категории, ограничивают методы. SWG с антивирусом на входе добавляет проверку скачиваемых файлов.
Балансировка между несколькими узлами снижает задержку и убирает единую точку отказа. Тонкость одна: сессия с авторизацией должна попадать на тот же узел. Sticky-логика настраивается на стороне балансировщика.
Свой узел на VPS: порядок действий, который работает
Для десятка клиентов хватит одного ядра и гигабайта памяти. Узкое место почти всегда канал, а не процессор. Если планируете парсинг в несколько сотен потоков, смотрите на 2-4 ядра и нормальный сетевой лимит.
- Поставить чистую ОС, обновить пакеты, создать отдельного пользователя под сервис.
- Закрыть файрволом всё лишнее, оставить только нужное.
- Выбрать софт: Squid для кэша и сложных ACL, 3proxy для лёгкости, tinyproxy для минимализма.
- Включить авторизацию. Логин с паролем или привязка по адресу, но не открытый узел.
- Настроить TLS. Самоподписанный сертификат годится только для тестов.
- Включить логирование и мониторинг: доступность, объём трафика, активные сессии.
Авторизация - пункт, который пропускают чаще всего. Открытый прокси находят сканеры за считанные часы. Дальше в логах появляется чужой трафик, а провайдер присылает письмо про подозрительную активность.
С DNS отдельная возня. Клиент может резолвить имена локально, часть запросов уходит мимо прокси. Для корпоративной схемы резолвинг лучше перенести на сторону сервера: не будет утечек и расхождений в геолокации.
Настройка в браузере: куда именно нажимать
Chrome сам прокси не настраивает, он открывает системные параметры. Windows: Параметры, Сеть и Интернет, Прокси, раздел «Настройка прокси вручную». Включаете переключатель, вписываете адрес и порт. Галочка «Не использовать прокси для локальных адресов» обязательна, иначе внутренние сервисы перестанут открываться.
Firefox: Настройки, Основные, внизу «Настройки сети», кнопка «Настроить». Выбираете ручную конфигурацию, отдельно заполняете HTTP и HTTPS. Тут же настраивается SOCKS5 и проксирование DNS. Расширения-менеджеры удобны для переключения профилей, но часть расширений ходит в сеть в обход прокси.
macOS: Системные настройки, Сеть, активное подключение, Дополнительно, вкладка Прокси. На Linux настройки подхватываются из окружения, а для терминала переменные задаются отдельно. Иначе curl и git пойдут напрямую.
WEB-proxy для Telegram: как устроено и что писать в hostname
В Telegram Desktop уже находили компоненты нового транспорта, который в коде называется WEB Proxy. Схема понятна по разбору, который выложили на Хабре: веб-сервер, рядом tproxy_relay, сверху edge-proxy. Клиент общается с сервером как с обычным сайтом, а полезная нагрузка идёт через тот же канал.
Механика такая: клиент формирует хеш и передаёт его в параметре запроса. Имя хоста берётся из значения, которое вы указали в настройках прокси. Сервер отдаёт страницу по base_path, и для этой страницы доступен API, который использует Telegram.
С точки зрения инфраструктуры удобство в том, что не нужно держать отдельный нестандартный порт. Всё идёт по обычному HTTPS, согласование проходит быстрее, а логи выглядят привычно.
Главная практическая деталь: в поле hostname указывается ровно тот домен, на котором поднят ваш веб-сервер, без вариаций вроде www. Если давать доступ через другое имя, проверка по хосту не пройдёт.
Пошагово в приложении: Настройки, Данные и память, Прокси, Добавить прокси, выбрать тип WEB, вписать hostname, сохранить. Если хеш не сходится, приложение молча не подключится.
Пять ошибок, которые повторяют почти все
Открытый узел без авторизации. Через несколько часов в логах чужие запросы, через день письмо от провайдера. Лечится одним правилом и паролем.
Забытый allowlist локальных адресов. Внутренние панели, принтеры, тестовые стенды отваливаются, и человек ищет причину в браузере.
Самоподписанный сертификат в проде. Клиент не подключается, в логах пусто, потому что ошибка на этапе рукопожатия.
Утечка DNS. Запросы на резолвинг уходят напрямую, вы получаете не ту геолокацию. В браузере это отдельная галочка.
Один узел на все задачи. Парсинг, корпоративный шлюз и личный браузер на одном адресе означают, что падение одного сценария тянет за собой остальные. Разносите роли по разным узлам.
Прокси для парсинга живёт по другим правилам
Тут важна не анонимность, а пул и управление. Нужны ротация, sticky-сессии для сценариев с авторизацией, лимиты на количество соединений. Сайты быстро вычисляют шаблонное поведение: одинаковые интервалы, одинаковый User-Agent.
Частные прокси быстрее и безопаснее публичных. На общем адресе вы наследуете репутацию соседей вместе с капчами. Для задач, где важна предсказуемость, выделенный вариант почти всегда окупается.
Ещё момент про задержку. Географически близкий узел даёт меньше RTT, но если целевой сайт отдаёт контент по региону, близость не поможет. Считайте долю успешных запросов на тысячу.
Где брать узлы, если поднимать свой сервер не хочется
Свой VPS хорош, когда у вас одна задача и один регион. Когда нужно десять стран, мобильные адреса и разные протоколы, дешевле взять готовое. Эксперты из домклик в обсуждениях на Reddit отмечают, что удобно иметь доступ к каталогу с фильтрами по стране, типу и протоколу. Заходите в каталог прокси 3seller, где можно взять пробный объём, прежде чем платить за пакет.
Логика выбора простая: для браузера и корпоративного шлюза берите HTTP или HTTPS с авторизацией. Для парсинга и нестандартных протоколов смотрите SOCKS5. Для мобильных сценариев ищите мобильные адреса — они дороже, но ведут себя как обычный пользователь.
Сколько ресурсов съедает узел на практике
Считайте от канала. Гигабитный линк и сотня активных клиентов упираются в сеть, а не в процессор. Для офиса на 50-100 человек обычно хватает двух ядер, четырёх гигабайт и диска под кэш.
Для парсинга картина обратная. Канал нужен скромный, а количество одновременных соединений и файловые дескрипторы упираются в лимиты быстро. Проверьте системные лимиты до запуска.
Что проверить перед тем, как считать задачу закрытой
- Запросы действительно идут через прокси, а не напрямую.
- DNS резолвится на стороне сервера, а не на клиенте.
- Локальные адреса в исключениях, внутренние сервисы открываются.
- Авторизация включена, узел не отвечает анонимным запросам.
- Сертификат валидный, ошибок рукопожатия в логах нет.
- Мониторинг показывает трафик и активные сессии, а не только «процесс запущен».
Настройка web proxy почти никогда не заканчивается на моменте, когда браузер открыл первую страницу. Настоящая проверка начинается через сутки. Возьмите один сценарий, поднимите под него отдельный узел, прогоните под нагрузкой и только потом расширяйте на остальные задачи. Так вы потратите вечер вместо недели.