Прямой прокси действует от имени клиентов, отправляющих исходящие запросы. Обратный прокси действует от имени серверов, получающих входящие запросы. При принятии решения о прямом прокси против обратного прокси начните с определения, чей трафик вы хотите контролировать: человека или приложение, отправляющее запрос, или веб-сайт, который его получает.
Оба являются посредниками, и оба могут отправлять запросы дальше. Их названия описывают их роль в архитектуре, а не обещание о безопасности, анонимности или производительности. Шлюз веб-сайта не становится автоматически службой для исходящего просмотра, а покупка исходящего прокси не публикует ваше приложение для посетителей.
Кратко
- Используйте прямой прокси, когда клиенту нужен определенный маршрут для исходящего доступа или политика доступа.
- Используйте обратный прокси, когда посетителям нужна точка входа в приложения, которые вы управляете.
- Аутентификация, шифрование, кэширование и ведение журналов зависят от фактической конфигурации, а не только от метки прокси.
- Обе роли могут существовать в одной системе, но у них разные владельцы, учетные данные и режимы отказа.
- Метка о жилом, провайдере или дата-центре описывает сетевое предложение; она не заменяет различие между прямым и обратным прокси.
Разница в одной таблице
| Вопрос | Прямой прокси | Обратный прокси |
|---|---|---|
| От чьего имени он действует? | От имени клиента или группы клиентов | От имени сервера или группы серверов |
| Типичный путь запроса | Приложение → прокси → назначение | Посетитель → прокси → приложение |
| Кто обычно его выбирает? | Оператор клиента или сетевой администратор | Оператор веб-сайта или сервиса |
| Какова непосредственная цель? | Контроль или маршрутизация исходящего доступа | Получение и маршрутизация входящего доступа |
| Типичная проблема аутентификации | Может ли этот клиент использовать прокси? | Может ли этот посетитель получить доступ к этому приложению? |
| Общая операционная проблема | Доступ к конечной точке, учетные данные и политика исходящего доступа | Состояние upstream, маршрутизация, сертификаты и доступ к источнику |
| Что он не предоставляет автоматически? | Публичную точку входа для вашего собственного веб-сайта | Другую исходящую идентичность для несвязанного браузерного трафика |
Это типичные роли, а не ограничения для конкретного программного пакета. Способный шлюз может поддерживать несколько функций, но каждая функция все равно требует явной конфигурации. Обзор прокси-серверов MDN различает промежуточные и шлюзовые прокси в пути HTTP-запроса.
Как работает прямой прокси
Представьте себе приложение для отчетности, отправляющее авторизованный запрос к внешнему сервису. Вместо того чтобы подключаться напрямую, оно отправляет запрос через настроенный прямой прокси. Прокси устанавливает следующее соединение и возвращает ответ по тому же логическому пути.
Оператор клиента может захотеть централизованную политику исходящего доступа, контролируемый сетевой маршрут или поддерживаемый способ для приложения достичь назначения. Точный результат зависит от протокола, поддержки прокси клиентом и конфигурации провайдера. Некоторые приложения имеют свои собственные настройки прокси; другие наследуют системные или средовые настройки.
Важный операционный вопрос заключается в том, использует ли предполагаемое приложение на самом деле прокси. Изменение настройки в одном инструменте не доказывает, что каждый процесс на компьютере следует ей. Фоновая служба, браузер и клиент командной строки могут иметь разные эффективные конфигурации.
Прямой прокси также не гарантирует, что назначение не увидит никакой другой идентифицирующей информации. Запросы могут включать учетные данные, куки и данные приложения. Выберите маршрут для законной технической необходимости и оцените обработку данных отдельно от адреса, используемого для сетевого соединения.
Пример: Запланированная интеграция данных
Рассмотрим гипотетическую интеграцию, которая получает разрешенные данные поставщика каждое утро. Ее оператор хочет, чтобы запросы выходили через задокументированную конечную точку. Оператор настраивает HTTP-клиент интеграции, хранит учетные данные прокси отдельно от токена API поставщика и проверяет как маршрут, так и поведение приложения.
Учетные данные прокси отвечают на вопрос, может ли интеграция использовать посредника. Токен поставщика отвечает на вопрос, может ли он читать данные поставщика. Рабочий прокси не предоставляет второго разрешения. Разделение этих обязанностей облегчает диагностику ошибок аутентификации.
Как работает обратный прокси
Теперь представьте себе публичный веб-сайт с приложением, работающим на частном сервисном порту. Посетители подключаются к «двери» веб-сайта. Обратный прокси получает этот трафик и перенаправляет его к настроенному upstream-приложению, затем возвращает ответ приложения.
Оператор веб-сайта выбирает upstream и контролирует точку входа. В зависимости от дизайна обратный прокси может обрабатывать завершение TLS, маршрутизацию между сервисами, буферизацию или распределение нагрузки. Это настроенные возможности, а не функции, которые следует предполагать, что каждая установка включает.
Документация обратного прокси NGINX объясняет, как передавать запросы на upstream с помощью proxy_pass, устанавливать заголовки запросов и контролировать буферизацию. Этот гид сосредоточен на выборе роли; детали установки и директивы относятся к документации для программного обеспечения, которое вы фактически развертываете.
Обратный прокси не может сделать нездоровое приложение здоровым. Если upstream-база данных недоступна, установка другого компонента перед ней не восстанавливает отсутствующие данные. Он может предоставить контролируемый ответ на сбой или перенаправить на другой здоровый экземпляр только тогда, когда архитектура была спроектирована для этого.
Пример: Два внутренних приложения под одним доменом
Предположим, небольшая команда управляет панелью мониторинга и службой документации. Это гипотетический дизайн, а не эталон. Обратный прокси может предоставить определенную публичную точку входа и отправлять запросы в соответствующее приложение в соответствии с настроенными хостами или путями.
Команда все еще должна решить, кто может получить доступ к каждому приложению, как обновляются сертификаты и доступны ли исходные сервисы напрямую. Упорядоченная структура домена полезна, но не заменяет контроль доступа. Проверьте как ожидаемый публичный маршрут, так и любые непреднамеренные альтернативные точки входа.
Аутентификация и доверие различаются с каждой стороны
Прямой прокси может требовать имя пользователя и пароль перед перенаправлением трафика. Приложение также может потребовать свои собственные учетные данные назначения. Держите две идентичности отдельно в конфигурации, журналах и отчетах об инцидентах.
С помощью обратного прокси посетители могут аутентифицироваться в приложении или в слое доступа перед ним. Приложение должно понимать, какие заголовки или утверждения идентичности оно может считать доверенными. Принятие заголовка идентичности, предоставленного посетителем, без доверенной границы может подорвать предполагаемый контроль.
Например, приложение может захотеть записать оригинальный адрес посетителя после того, как трафик пройдет через шлюз. Это требует преднамеренной конфигурации доверенного прокси. Простое чтение перенаправленного заголовка не устанавливает, что его содержимое является авторитетным. Настройки приложения и шлюза должны согласовываться по поводу того, какие компоненты могут его предоставлять.
В любом дизайне определите, кто может изменять конфигурацию маршрутизации. Администратор прокси может повлиять на то, куда идут запросы и какая информация проходит через посредника. Рассматривайте эту власть как значительное операционное разрешение, а не как безобидную настройку удобства.
Автоматически ли шифрует любой из прокси все?
Нет. Определите соединения отдельно. Может быть соединение от клиента к прокси и другое от прокси к назначению или upstream. Шифрование на одном соединении не устанавливает шифрование на другом.
Для обратного прокси, который завершает HTTPS, решите, требуется ли соединение с приложением также TLS, и проверьте соответствующие сертификаты и настройки доверия. Для прямого прокси различайте URL назначения от протокола, используемого для достижения конечной точки прокси.
Запишите эти выборы в архитектурной записи. Избегайте диаграммы, которая помечает весь маршрут как «безопасный», не объясняя, где начинается и заканчивается шифрование. Полезный обзор задает вопрос, что каждый посредник может наблюдать, где проходят учетные данные и какая сторона управляет настройками доверия.
Практический процесс выбора
1. Напишите запрос простым языком
Используйте предложение, например, «наш работник вызывает внешний API» или «клиенты открывают нашу панель мониторинга». Назовите запрашивающего и назначение. Это небольшое упражнение обычно определяет соответствующую сторону различия прокси до начала сравнения продуктов.
Если требование говорит только «нам нужен прокси», спросите, что должно измениться: маршрутизация исходящего, доступ к входящему приложению, аутентификация или управление трафиком. Эти цели могут требовать различных компонентов.
2. Определите границу, которую вы контролируете
Перечислите клиента, посредника и назначение. Укажите, какие системы управляет ваша команда, а какие принадлежат другой организации. Не разрабатывайте решение, которое предполагает административный контроль над сторонним веб-сайтом.
Для приложения, которым вы владеете, вы можете выбрать входной шлюз и настроить источник. Для стороннего API вы контролируете своего клиента и его авторизованный маршрут, но разрешения учетной записи API и правила использования остаются вне этой границы.
3. Определите необходимые протоколы и поведение
Включите протокол приложения, метод аутентификации, размер запроса, поведение потоковой передачи и ожидаемую продолжительность соединения. Успешный короткий запрос страницы не доказывает, что длительные потоки или большие загрузки будут работать корректно.
Используйте репрезентативные авторизованные тесты и запишите версию клиента. Избегайте трактовать слово «прокси» как доказательство того, что каждый протокол или механизм аутентификации будет работать. Совместимость является свойством полного пути соединения.
4. Назначьте владельца для каждого сбоя
Решите, кто проверяет конфигурацию клиента, доступность прокси, состояние приложения и обновление сертификатов. Дайте службе поддержки достаточно очищенной информации, чтобы различать сбой аутентификации прокси от сбоя upstream-приложения.
Также решите, как отключить или откатить изменение маршрута. Обратимая конфигурация гораздо легче в эксплуатации, чем не задокументированная зависимость, которую все обнаруживают во время сбоя.
5. Проверьте фактический результат
Для прямого прокси протестируйте, что предполагаемое приложение следует выбранному маршруту и завершает свою реальную задачу. Для обратного прокси протестируйте публичное имя хоста, маршрутизацию, аутентификацию и ожидаемое поведение upstream. Проверьте, что непреднамеренный прямой доступ ограничен там, где это требуется вашим дизайном.
Сохраните результат как небольшую запись о принятии, а не как скриншот одного успешного запроса. Включите нормальное поведение, один контролируемый сбой и шаг восстановления. Это создаст ссылку для будущих изменений.
Может ли система использовать оба?
Да. Веб-приложение может получать посетителей через обратный прокси, в то время как его фоновый работник использует прямой прокси для авторизованной внешней интеграции. Это разные пути запросов, даже если компоненты работают в одной инфраструктуре.
Держите их учетные данные, журналы и имена конфигураций различными. «Пароль прокси» является неоднозначной секретной меткой, когда развертывание содержит несколько посредников. Предпочитайте имена, которые идентифицируют сервис и цель, не раскрывая сам секрет.
Также учитывайте независимость отказов. Если исходный прокси недоступен, должен ли публичный приложение оставаться доступным, пока запланированные интеграции приостановлены? Если входной шлюз выходит из строя, могут ли операторы все еще получить доступ к консоли восстановления? Эти вопросы показывают, стал ли один компонент случайно зависимостью для несвязанных работ.
Где размещение и прокси-продукты подходят
Сервер предоставляет вам место для запуска программного обеспечения. Служба пересылки предоставляет совместимому клиенту маршрут для запросов. Их можно комбинировать, но ни один из них автоматически не включает другой. Существующее сравнение VPS и жилого прокси расширяет это различие.
Для размещения приложения или шлюза оцените обязанности по времени выполнения и обслуживанию Cloud VPS. Если вы выберете NGINX Proxy Manager, существующее руководство по развертыванию NGINX Proxy Manager охватывает эту отдельную задачу установки. Более широкое руководство по управлению VPS актуально для поддержания основного сервера.
Классификация провайдера или дата-центра исходящего прокси является другим решением. Это не говорит вам, нужен ли вашему веб-сайту обратный прокси, и это не устраняет необходимость в настройке аутентификации и доступа к приложению. Сначала выберите архитектуру, затем оцените сетевое предложение в соответствии с конкретным требованием.
Часто задаваемые вопросы
В чем основное различие между прямым прокси и обратным прокси?
Прямой прокси обслуживает клиентов, отправляющих исходящие запросы; обратный прокси обслуживает приложения, получающие входящие запросы. Определите, с какой стороны вы работаете и какое поведение трафика вы хотите изменить, прежде чем выбирать программное обеспечение или услугу.
Может ли обратный прокси изменить исходящий IP моего браузера?
Не просто существуя перед вашим веб-сайтом. Он обрабатывает запросы, адресованные приложениям, которые он обслуживает. Маршрутизация несвязанного браузерного трафика через посредника требует отдельной поддерживаемой конфигурации прямого прокси или сети.
Является ли обратный прокси тем же, что и балансировщик нагрузки?
Нет. Балансировка нагрузки является одной из возможных функций дизайна обратного прокси. Обратный прокси может перенаправлять на один upstream, а система балансировки нагрузки может работать по-разному. Проверьте фактическую конфигурацию, а не предполагайте избыточность по метке.
Делает ли прямой прокси запросы анонимными?
Такой гарантии не следует из роли. Вход в учетные записи, куки, данные запросов и журналы операторов все еще имеют значение. Оцените, какая информация отправляется и сохраняется, и используйте службу только для доступа, на который у вас есть разрешение.
Нужны ли мне оба для небольшого веб-сайта?
Не обязательно. Начните с требований приложения. Управляемая хостинг-служба может уже обрабатывать входную точку, и обычные исходящие запросы могут не требовать дополнительного прокси. Добавляйте компонент только тогда, когда он решает задокументированное требование и кто-то может его поддерживать.
Является ли прозрачный прокси третьим направлением?
Нет. Прозрачность описывает, как работает перехват или осведомленность клиента в конкретном контексте; это отдельное измерение от того, чьи запросы обслуживает посредник. Используйте точные описания пути трафика, а не рассматривайте каждую метку прокси как конкурирующую архитектуру.