Прямой прокси против обратного проксиОдно реле, противоположные концы

«Forward proxy или reverse proxy» обсуждается как выбор между двумя технологиями. Но это не так. Оба являются одним и тем же: реле, делающим запрос от чьего-то имени и передающим ответ обратно. Они работают на одном программном обеспечении: один nginx, один HAProxy или один Envoy могут быть любым из них. Что различается, так это не машина, а то, какой конец соединения представляет реле, и следовательно, чью идентичность оно скрывает.

Forward proxy выступает за клиента. Он находится рядом с людьми, делающими запросы, смотрит в открытый интернет и скрывает того, кто спрашивает. Reverse proxy выступает за сервер. Он стоит перед origin-сервером, смотрит в сторону публики и скрывает того, кто отвечает. Одно реле, противоположные концы.

Поймите это единственное различие, и каждая строка в обычной сравнительной таблице вытекает из него сама по себе: кто его настраивает, чей IP видит другая сторона, где оно находится, для чего оно хорошо. Остальная часть этой статьи рассматривает две роли, а затем случаи, когда одна и та же машина одновременно играет обе роли.

Forward proxy vs Reverse proxy: краткая версия

Вот и всё различие в трёх строках. Каждое другое отличие, кто его развёртывает и где оно находится, вытекает из того, какой конец представляет реле.

Единственное, что меняется: чью сторону представляет прокси

Прокси, это один уровень косвенности. Он ретранслирует запрос так, чтобы другая сторона видела прокси вместо стоящей за ним стороны. У каждого реле два конца: клиентский и серверный, и то, какой из них оно представляет внешнему миру, определяет его роль.

Forward proxy развёртывается на стороне клиента. Ваш трафик выходит через него, поэтому интернет видит адрес прокси вместо вашего. Он скрывает клиента. Reverse proxy развёртывается на стороне сервера. Публичный трафик поступает к нему первым, поэтому посетители видят один опубликованный адрес вместо ваших реальных бэкендов. Он скрывает сервер.

Программному обеспечению безразлично, которую из этих ролей оно выполняет. Тот же nginx, который проксирует исходящий трафик для лаборатории машин, становится reverse proxy в тот момент, когда вы указываете его на собственный бэкенд и публикуете его адрес. Направление, это решение при развёртывании, а не категория продукта.

Forward proxy: замена клиента

Forward proxy действует от имени стоящих за ним людей. Вы настраиваете его на своих устройствах или в сети, указываете на него клиент, и с этого момента ваши запросы выходят через прокси. Адресат понятия не имеет, кто их изначально отправил; он видит только прокси. Именно такой прокси большинство людей имеет в виду, говоря «прокси», и именно это вручает вам прокси- или скрапинговый сервис.

Как forward proxy маршрутизирует запрос

1. Ваш клиент отправляет запрос на forward proxy, а не напрямую адресату.
2. Прокси заменяет ваш IP своим и перенаправляет запрос цели.
3. Цель получает запрос с адреса прокси и отвечает на него.
4. Прокси передаёт ответ обратно вам.

Для чего он подходит

• Анонимность. Цель видит IP прокси, а не ваш, в этом и есть весь смысл маршрутизации через него.
• Геодоступ. Выходите через IP в другой стране, чтобы получить доступ к контенту, доступному только региональным посетителям.
• Контроль исходящего трафика. Организация может фильтровать, логировать или блокировать то, к чему её пользователи обращаются на выходе.
• Веб-парсинг в масштабе. Распределяйте запросы по ротируемому пулу, чтобы ни один IP не перегружался и не попадал в блокировки.

Последний сценарий использования наиболее актуален для большинства читателей, и именно здесь IP за прокси начинает иметь значение. Forward proxy может выходить через адрес датацентра или резидентный, и этот выбор определяет, будет ли защищённая цель доверять запросу. Этот компромисс мы разбираем в статье датацентровые vs резидентные прокси, а протокол, на котором говорит прокси (HTTP или SOCKS), в статье что такое SOCKS5 прокси. Когда прокси предоставляется как программируемый endpoint, а не хост и порт, он становится API-прокси.

Reverse proxy: парадный вход сервера

Reverse proxy действует от имени стоящих за ним серверов. Владелец сайта развёртывает его, публикует его адрес как публичный endpoint и хранит реальные бэкенды в тайне. Посетители подключаются к reverse proxy, считая, что это сервер; он решает, какой бэкенд реально обрабатывает каждый запрос, и возвращает ответ так, как будто сам его произвёл. Reverse proxy почти повсеместно используются в масштабе: подавляющее большинство высоконагруженных сайтов стоят за одним, будь то self-hosted с nginx, HAProxy или Envoy, или через CDN вроде Cloudflare или Fastly.

Как reverse proxy маршрутизирует запрос

1. Посетитель отправляет запрос на опубликованный адрес reverse proxy.
2. Прокси выбирает работоспособный бэкенд, зачастую балансируя нагрузку между несколькими.
3. Выбранный бэкенд обрабатывает запрос, невидимый для посетителя.
4. Прокси возвращает ответ, так что посетитель всегда общается только с парадным входом.

Для чего он подходит

• Балансировка нагрузки. Распределяйте входящий трафик между многими бэкендами и обходите отказавшие, чтобы сайт оставался доступным под нагрузкой.
• Кеширование. Отдавайте сохранённые копии популярного контента без обращения к бэкенду, это снижает задержку и нагрузку на origin.
• Терминирование TLS. Обрабатывайте SSL/TLS на краю сети один раз, а не на каждом бэкенде.
• Защита origin. Скрывайте реальные серверы и создайте место для применения ограничений скорости, WAF и правил доступа до того, как трафик достигнет их.

Forward vs Reverse proxy на первый взгляд

Когда одна машина играет обе роли

Метки forward и reverse описывают роль в соединении, а не постоянный тип, проштампованный на железе. Одно и то же программное обеспечение, иногда один и тот же запущенный процесс, может быть forward proxy для одного соединения и reverse proxy для другого.

CDN-край, наиболее наглядный пример. Для ваших посетителей это reverse proxy, выступающий за ваш origin и отдающий кешированный контент. Для вашего origin, когда он получает свежую копию, тот же край выглядит как клиент, приходящий через forward-хоп. Корпоративный шлюз, фильтрующий трафик сотрудников на выходе, это forward proxy; API-шлюз перед вашими микросервисами, это reverse proxy; sidecar сервисной сети, оба одновременно: он разворачивает входящие вызовы к своему сервису и перенаправляет его исходящие вызовы. Ничего в машинах не изменилось. Изменилось направление соединения.

Именно здесь вписывается и стек парсинга. При сборе публичных данных вам нужен forward proxy, представляющий вас перед целью и поглощающий факторы, из-за которых запросы блокируются: ротацию выходного IP, повторные попытки и обработку антибота. Делать это самостоятельно означает поддерживать IP-пулы и логику маршрутизации; управляемый forward proxy сворачивает всё это в один endpoint.

Как понять, что вам нужно

Задайте один вопрос: вы защищаете сторону, которая спрашивает, или сторону, которая отвечает?

Если вы обслуживаете сайт или API, вам нужен reverse proxy перед вашим origin, будь то nginx или Caddy, которые вы запускаете сами, или CDN, управляющий одним за вас. Он обеспечивает балансировку нагрузки, кеширование, TLS и единое место для применения защиты до того, как трафик достигнет вашего кода.

# Reverse proxy: one public address,
# real backends kept private behind it.
server {
    listen 443 ssl;
    server_name example.com;
    location / {
        proxy_pass http://10.0.0.5:8080;
    }
}

Если вы обращаетесь в интернет, для анонимности, геоспецифичных данных или парсинга в масштабе, вам нужен forward proxy, через который выходит ваш клиент. Цель видит прокси, а хороший управляет за вас выходными IP.

# Forward proxy: your client exits through it,
# so the target sees the proxy IP, not yours.
curl -x "http://_USER_TOKEN_:@smartproxy.crawlbase.com:8012" \
     -k "https://example.com/"

Если вы используете и то и другое, это нормально и правильно: ваше приложение стоит за reverse proxy, а оно обращается к сторонним данным через forward proxy. Они не конкуренты. Они противоположные концы разных соединений. Для стороны парсинга конкретно см. сравнение пулового endpoint в backconnect proxy vs crawling API, а если вы ещё выбираете выходные узлы, актуальный обзор в лучшие провайдеры прокси.

Часто задаваемые вопросы

Reverse proxy безопаснее, чем forward proxy?

Они защищают разные стороны, поэтому ни один из них не является «более безопасным» в абстрактном смысле. Reverse proxy укрепляет сервер: скрывает origin-серверы, терминирует TLS и даёт вам одно место для WAF и ограничения скорости. Forward proxy укрепляет клиента: скрывает того, кто спрашивает, и может фильтровать то, к чему обращаются пользователи. Выбирайте исходя из того, какую сторону нужно защитить.

Reverse proxy, то же самое, что VPN?

Нет. Reverse proxy работает на уровне приложений и ретранслирует конкретные запросы на бэкенд-серверы. VPN работает ниже, создавая зашифрованный туннель, по которому проходит весь трафик устройства в частную сеть. Reverse proxy стоит перед серверами; VPN подключает клиентов к сети.

CDN, это reverse proxy?

Да. CDN, это глобально распределённый reverse proxy перед вашим origin. Каждый край кеширует и отдаёт ваш контент, терминирует TLS и защищает реальные серверы, это именно роль reverse proxy, реализованная в масштабе.

Может ли один сервер быть одновременно forward и reverse proxy?

Да, потому что роль определяется соединением. CDN-край разворачивает трафик к вашим посетителям, выглядя при этом как forwarding-клиент для вашего origin, а sidecar сервисной сети разворачивает входящие вызовы и перенаправляет исходящие. Один и тот же процесс играет обе роли в зависимости от направления.

Нужен forward или reverse proxy для веб-парсинга?

Forward proxy. Парсинг, это задача доступа: вы клиент, и вы хотите, чтобы цель видела IP прокси вместо вашего. Reverse proxy стоит перед серверами, которыми вы владеете, поэтому он ничего не даёт для обращения к чужому сайту.

Балансировщик нагрузки, это reverse proxy?

Балансировка нагрузки, одна из задач, которые выполняет reverse proxy. Специализированный балансировщик нагрузки может работать ниже в стеке на транспортном уровне, но балансировщик на уровне приложений функционально является reverse proxy, специализирующимся на распределении трафика между бэкендами.

SR

Syeda Roushan Arshid

Контент-райтер · Crawlbase

Контент-райтер, освещавшая прокси, облачное хранение и безопасность данных в блоге Crawlbase, делая темы инфраструктуры и защиты данных понятными для широкой инженерной аудитории.