Прокси-сервер

Прокси-сервер, или Proxy Server, — промежуточный сетевой узел, через который клиент обращается к другому серверу или сервису. Вместо прямого соединения пользователь или приложение отправляет запрос Proxy, а тот самостоятельно устанавливает соединение с целевым ресурсом и возвращает полученный результат.

Прокси используются в корпоративных сетях, веб-инфраструктуре, облаках, API, системах безопасности и распределенных приложениях. Они могут фильтровать трафик, ограничивать доступ, кэшировать данные, скрывать внутреннюю инфраструктуру, выполнять TLS Termination и распределять запросы между Backend Servers.

Прокси-сервер разрывает прямое взаимодействие между клиентом и целевым сервисом и становится посредником, через которого проходит сетевой или прикладной трафик.

Что такое прокси-сервер простыми словами

Прокси можно представить как посредника.

Вместо схемы:

Client → Website

используется:

Client → Proxy → Website

Сайт получает запрос от Proxy, а ответ сначала возвращается Proxy и только затем передается клиенту.

Такой посредник может выполнять дополнительные действия: проверять правила доступа, записывать Logs, изменять Headers, кэшировать Response или выбирать один из нескольких Backend Servers.

Зачем нужен прокси-сервер

Прокси решает разные задачи в зависимости от того, где он расположен и какой трафик обрабатывает.

• централизованный выход пользователей в интернет;
• фильтрация сайтов;
• контроль корпоративного трафика;
• кэширование ресурсов;
• скрытие внутренних IP-адресов;
• защита Backend Servers;
• балансировка запросов;
• TLS Termination;
• Rate Limiting;
• маршрутизация API.

Основные виды прокси

Forward Proxy

Forward Proxy находится со стороны клиента.

Пользователь отправляет запрос Proxy, а тот обращается к внешнему сайту от своего имени.

User
↓
Forward Proxy
↓
Internet

Такую схему часто используют в корпоративных сетях для централизованного контроля доступа в интернет.

Для чего используют Forward Proxy

Forward Proxy может:

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

Reverse Proxy

Reverse Proxy находится перед сервером или группой Backend Servers.

Для внешнего пользователя именно Proxy выглядит как основной сервер приложения.

Internet
↓
Reverse Proxy
↓
Backend 1
Backend 2
Backend 3

Клиенту не нужно знать реальные IP и Ports внутренних сервисов.

Для чего используют Reverse Proxy

Reverse Proxy может выполнять:

• Load Balancing;
• TLS Termination;
• Routing по Host и Path;
• кэширование;
• Rate Limiting;
• сжатие данных;
• добавление Security Headers;
• сокрытие Backend Architecture.

Forward Proxy и Reverse Proxy

Прокси и NAT

Proxy и NAT иногда решают похожие внешние задачи, но работают по-разному.

NAT изменяет IP Addresses и Ports сетевого соединения. Proxy принимает соединение клиента и создает отдельное соединение к серверу.

Client → Proxy
Proxy → Server

Между Client и Server существуют две отдельные сессии.

Прокси и Firewall

Firewall решает, разрешить или заблокировать сетевой трафик, а Proxy выступает активным посредником между сторонами.

Эти механизмы часто работают совместно.

Например, Firewall разрешает пользователям обращаться только к корпоративному Proxy, а прямые интернет-соединения блокирует.

Прокси и WAF

WAF часто реализуется как Reverse Proxy или интегрируется с ним.

Обычный Reverse Proxy маршрутизирует HTTP Requests, а WAF дополнительно анализирует Payload на SQL Injection, XSS и другие Web Attacks.

Таким образом, каждый WAF может выполнять Proxy-функции, но не каждый Proxy является WAF.

Прокси и HTTP

HTTP Proxy понимает структуру HTTP Requests и Responses.

Он может анализировать:

• Method;
• URL;
• Host;
• Headers;
• Cookies;
• Status Code;
• Content-Type.

Это позволяет выполнять маршрутизацию и фильтрацию на прикладном уровне.

HTTP Forward Proxy

При обычном HTTP клиент отправляет Proxy запрос с информацией о целевом ресурсе.

Proxy самостоятельно подключается к серверу, получает Response и возвращает его клиенту.

HTTPS через Proxy

Для HTTPS существует несколько моделей.

Forward Proxy может создать туннель между Client и целевым HTTPS Server, не расшифровывая содержимое TLS Traffic.

В другой корпоративной архитектуре Proxy может выполнять TLS Inspection, если клиентские устройства настроены доверять корпоративному Certificate Authority.

HTTP CONNECT

Метод CONNECT используется Proxy для создания туннеля к указанному Host и Port.

Например, Browser просит Proxy открыть соединение к:

example.com:443

После установки Tunnel TLS Handshake может происходить непосредственно между Browser и сайтом.

TLS Inspection

При TLS Inspection корпоративный Proxy расшифровывает защищенный Traffic, анализирует его и создает новое TLS-соединение к внешнему серверу.

Client
↓ TLS
Proxy
↓ TLS
Website

Для этого устройства пользователей должны доверять корпоративному CA.

Риски TLS Inspection

Прокси получает доступ к расшифрованным данным, поэтому становится критичным Security Component.

Необходимо защищать Private Keys, ограничивать административный доступ и учитывать требования к конфиденциальности данных.

SOCKS Proxy

SOCKS работает на более универсальном уровне, чем HTTP Proxy, и может передавать различные типы Traffic.

Клиент сообщает Proxy адрес назначения, а тот устанавливает соответствующее соединение.

SOCKS используется для приложений, которым нужен Proxy, но которые работают не только с HTTP.

HTTP Proxy и SOCKS

Transparent Proxy

Transparent Proxy используется в архитектурах, где Traffic перенаправляется через Proxy без явного указания его адреса в каждом приложении.

Это позволяет централизованно применять Network Policy, но усложняет диагностику, поскольку пользователь может не знать о существовании посредника.

Explicit Proxy

При Explicit Proxy клиент знает Address Proxy и настроен использовать его напрямую.

Например:

Proxy: proxy.company.local
Port: 3128

Такая конфигурация может задаваться вручную или централизованно.

Proxy Authentication

Корпоративный Proxy может требовать Authentication.

Тогда правила доступа применяются не только к Source IP, но и к конкретному пользователю.

Например, отдел разработки имеет доступ к определенным техническим ресурсам, а Guest Users — нет.

Прокси и IP-адрес клиента

Когда Proxy создает новое соединение с Backend, сервер обычно видит Source IP самого Proxy.

Исходный адрес пользователя может передаваться отдельным HTTP Header, если это предусмотрено архитектурой.

X-Forwarded-For

X-Forwarded-For исторически широко используется для передачи исходного Client IP через HTTP Proxy.

Условный Header:

X-Forwarded-For: 192.0.2.10

Backend не должен безусловно доверять этому значению от любого клиента, поскольку Header можно подделать.

Forwarded Header

Существуют стандартизированные механизмы передачи информации о первоначальном клиенте и протоколе через Proxy.

Приложение должно доверять таким Headers только от известных промежуточных узлов.

Trusted Proxy

Backend Framework часто имеет список Trusted Proxies.

Только если Request пришел от известного Reverse Proxy, приложение использует forwarded-заголовки для определения Client IP и Scheme.

Это защищает от простой подмены таких значений внешним пользователем.

Прокси и DNS

В зависимости от конфигурации DNS Resolution может выполнять Client или сам Proxy.

Это влияет на доступность внутренних доменов, Logging и Privacy.

При диагностике важно понимать, где именно разрешается имя.

Прокси и кэширование

Proxy Cache сохраняет Response и повторно отдает его другим клиентам без запроса к Origin.

Client 1 → Proxy → Origin
Client 2 → Proxy Cache

Это уменьшает нагрузку на Server и ускоряет доставку часто используемого Content.

Когда Proxy Cache эффективен

Кэширование особенно полезно для:

• изображений;
• CSS и JavaScript;
• публичных файлов;
• часто запрашиваемых API Responses;
• статических HTML Pages.

Когда нельзя бездумно кэшировать

Response может содержать персональные или динамические данные.

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

Поэтому необходимо учитывать Cache-Control, Authorization и Cookies.

Прокси и CDN

CDN по сути выполняет часть функций глобально распределенного Reverse Proxy.

Edge Server принимает Request клиента, может отдать Cached Content или обратиться к Origin.

Дополнительно CDN может выполнять WAF, TLS Termination и DDoS Protection.

Прокси и Load Balancing

Reverse Proxy может распределять Requests между несколькими Backend Servers.

Proxy
↓
Backend 1
Backend 2
Backend 3

Это позволяет горизонтально масштабировать приложение.

Алгоритмы балансировки

Конкретный Proxy может выбирать Backend по разным алгоритмам:

• Round Robin;
• Least Connections;
• Hash;
• Weights;
• другие алгоритмы реализации.

Выбор зависит от типа нагрузки.

Health Check

Reverse Proxy может регулярно проверять состояние Backend.

Если Server не отвечает, он временно исключается из балансировки.

Это повышает Availability приложения.

Прокси и High Availability

Если весь Traffic проходит через один Proxy, он становится Single Point of Failure.

Для критичных сервисов необходимо использовать несколько экземпляров или Managed Load Balancer перед ними.

Прокси и TLS Termination

Reverse Proxy часто принимает HTTPS, расшифровывает Traffic и передает Request Backend.

Client
↓ HTTPS
Reverse Proxy
↓ HTTP или HTTPS
Backend

Так Certificates централизованно управляются на Proxy.

Re-encryption

После TLS Termination Proxy может снова зашифровать соединение до Backend.

Это полезно, если внутреннюю сеть нельзя считать полностью доверенной.

Прокси и Nginx

Nginx часто используется как Reverse Proxy.

Он может принимать HTTP/HTTPS Requests, выбирать Backend, добавлять Headers, выполнять TLS Termination и отдавать статический Content.

Пример Reverse Proxy

Внешний пользователь открывает:

https://example.com/api/orders

Reverse Proxy по Path отправляет Request на Order Service:

/api/orders → 10.0.2.25:8080

Пользователь не знает внутренний Address сервиса.

Прокси и API Gateway

API Gateway — специализированный Proxy для API, который дополнительно может выполнять Authentication, Rate Limiting, Routing, Transformation и Monitoring.

То есть API Gateway шире обычного Reverse Proxy по бизнес-функциям управления API.

Прокси и Microservices

В Microservices Proxy часто используется как единая внешняя точка входа.

Например:

/users → User Service
/orders → Order Service
/payments → Payment Service

Так клиенту не требуется знать адреса десятков внутренних сервисов.

Прокси и Service Mesh

Service Mesh также использует Proxy-механизмы для управления межсервисным Traffic.

Proxy может находиться рядом с Workload и обрабатывать mTLS, Routing, Retry и Telemetry.

Внешний Reverse Proxy и внутренний Service Mesh решают разные части сетевой архитектуры.

Sidecar Proxy

В классической модели Service Mesh рядом с приложением запускается отдельный Proxy.

Application отправляет Traffic через него, а Proxy применяет сетевые политики.

Так бизнес-код не обязан самостоятельно реализовывать часть инфраструктурных функций.

Прокси и Kubernetes

В Kubernetes функции Reverse Proxy часто выполняют Ingress Controller или Gateway.

Internet
↓
Ingress / Proxy
↓
Service
↓
Pods

Он маршрутизирует HTTP Requests на нужный Kubernetes Service.

Ingress Controller

Ingress Controller может выбирать Backend на основании Domain и Path.

Например:

api.example.com → api-service
shop.example.com → shop-service

При этом он часто выполняет TLS Termination.

Прокси и Docker

В Docker Compose Reverse Proxy удобно использовать для публикации нескольких Containers через один внешний Address.

Proxy находится в общей Docker Network и обращается к сервисам по DNS Names.

Прокси и Backend

Backend за Reverse Proxy должен корректно учитывать внешний Scheme, Host и Client IP.

Например, если Proxy завершает HTTPS и отправляет внутрь HTTP, приложение без правильной настройки может ошибочно считать исходный Request незашифрованным.

Прокси и Redirect

Неправильная обработка forwarded-информации иногда вызывает бесконечный Redirect:

Client HTTPS → Proxy → Backend HTTP
Backend думает, что нужен HTTPS → Redirect

Поэтому приложение должно знать, что первоначальный Client Request уже был HTTPS.

Прокси и WebSocket

Reverse Proxy может передавать WebSocket Connections, но должен поддерживать соответствующую модель Upgrade и долгоживущие соединения.

Неправильные Timeout могут приводить к регулярному разрыву WebSocket.

Прокси и gRPC

Proxy может маршрутизировать gRPC Traffic, если поддерживает необходимый HTTP/2 стек и Protocol Features.

Не каждый старый HTTP Proxy корректно работает с gRPC.

Прокси и TCP

Не все Proxy работают только с HTTP.

Layer 4 Proxy может принимать TCP Connection и создавать другое TCP Connection к Backend, не анализируя прикладное содержимое.

Это полезно для Database, Message Broker и других Protocols.

TCP Proxy

Например, внешний Address:

proxy.example.com:5432

может направляться на один из внутренних PostgreSQL Servers.

При этом Proxy не обязан понимать SQL.

UDP Proxy

Некоторые Proxy и Load Balancers способны работать и с UDP Traffic.

Так как UDP не создает TCP-like Connection, модель учета состояния отличается.

Прокси и Database

Database Proxy может управлять пулом соединений, балансировкой чтения и переключением между серверами.

Он скрывает физическую топологию базы от приложения.

Например, Backend всегда подключается к одному Endpoint, даже если Primary Database изменился.

Прокси и Connection Pooling

Некоторые специализированные Database Proxies поддерживают Connection Pooling.

Это позволяет тысячам Application Connections эффективнее использовать ограниченное число реальных соединений к Database.

Прокси и Rate Limiting

Reverse Proxy может ограничить частоту Requests до передачи Backend.

Например:

/login → 10 requests/minute per client
/api/search → 100 requests/minute

Так приложение получает меньше нежелательной нагрузки.

Прокси и Authentication

Proxy может проверять Authentication до Backend.

Например, корпоративный Reverse Proxy требует Single Sign-On, а только после успешного входа передает Request внутреннему приложению.

Прокси и Zero Trust

Identity-aware Proxy используется в Zero Trust архитектуре для предоставления доступа к внутренним приложениям без открытия всей сети через VPN.

Пользователь проходит Authentication, а Proxy разрешает доступ только к конкретному Application.

Прокси и VPN

Proxy и VPN не являются синонимами.

В корпоративной среде технологии могут использоваться одновременно.

Прокси и анонимность

Forward Proxy может скрывать Client IP от конечного Website, который увидит Address Proxy.

Но сам Proxy при этом видит Source Client и потенциально может вести Logs.

Поэтому наличие Proxy не означает полной анонимности.

Прокси и геолокация

Website обычно определяет сетевое местоположение по IP Proxy, а не конечного Client.

Из-за этого Proxy иногда используется для доступа к ресурсам от имени Address другого региона.

Однако реальные сервисы могут учитывать и дополнительные признаки.

Прокси и безопасность

Proxy концентрирует большой объем Traffic и поэтому сам должен быть хорошо защищен.

• ограничивайте Management Access;
• обновляйте программное обеспечение;
• защищайте TLS Private Keys;
• не создавайте Open Proxy;
• контролируйте Logs;
• ограничивайте разрешенные Destinations;
• используйте Authentication при необходимости.

Open Proxy

Open Proxy доступен произвольным внешним пользователям без нормального контроля.

Такой сервер может использоваться злоумышленниками для Spam, Scanning и других нежелательных действий.

В результате Public IP владельца Proxy может попасть в Blocklists.

Почему нельзя оставлять корпоративный Proxy открытым

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

Доступ следует ограничивать Network Policy и Authentication.

Proxy Logs

Logs могут содержать:

Конфиденциальность логов

URL, Headers и Query Parameters могут содержать персональные или секретные данные.

Не следует без необходимости записывать Authorization Tokens, Passwords или полный чувствительный Payload.

Прокси и Observability

Reverse Proxy является удобной точкой для измерения общего состояния Web Application.

Можно отслеживать:

• Request Rate;
• Latency;
• 5xx Errors;
• Active Connections;
• Backend Health;
• Cache Hit Ratio.

502 Bad Gateway

Ошибка 502 часто означает, что Reverse Proxy не получил корректный Response от Backend.

Причина может быть в остановленном приложении, неправильном Port или сбое Network Connection.

504 Gateway Timeout

504 появляется, когда Proxy слишком долго ждет ответ Backend.

Проблема может быть связана с медленной Database, внешним API, зависшим Application или слишком коротким Timeout.

Proxy Timeout

Proxy обычно имеет несколько Timeout: на установление соединения, чтение Response и передачу данных.

Слишком короткие значения вызывают ложные ошибки, а слишком длинные позволяют зависшим Connections слишком долго занимать ресурсы.

Buffering

Reverse Proxy может временно буферизовать Request или Response.

Это полезно для защиты медленного Client от прямого удержания Backend Connection.

Но для Streaming-приложений Buffering иногда нужно отключать или настраивать отдельно.

Прокси и Streaming

Для Server-Sent Events, больших Downloads и потоковой передачи необходимо учитывать Buffers и Timeout.

Конфигурация, подходящая для обычного короткого HTTP Request, может мешать Streaming.

Прокси и загрузка файлов

Proxy может ограничивать максимальный Request Body.

Если пользователь пытается загрузить файл больше установленного лимита, запрос будет отклонен до Backend.

Это защищает сервер от чрезмерной нагрузки, но лимиты должны соответствовать бизнес-задаче.

Прокси и Compression

Reverse Proxy может сжимать HTTP Responses перед передачей клиенту.

Для текстовых форматов вроде HTML, JSON и CSS это уменьшает объем Traffic.

Header Modification

Proxy может добавлять или удалять HTTP Headers.

Например, он передает Backend информацию о Client IP или первоначальном HTTPS Scheme.

Также может добавлять Security Headers в Response.

Host-based Routing

Один Proxy способен обслуживать несколько доменов:

api.example.com → API Backend
shop.example.com → Shop Backend
admin.example.com → Admin Backend

Выбор выполняется по HTTP Host.

Path-based Routing

Proxy может выбирать Backend по URL Path:

/api/users → User Service
/api/orders → Order Service
/static → Static Storage

Этот подход часто используется в микросервисах.

Прокси и отказоустойчивость

Reverse Proxy может обнаружить неработающий Backend и направить новые Requests на другие экземпляры.

Но уже выполняющийся Request может завершиться ошибкой, поэтому приложение и Client должны учитывать Retry.

Retry на Proxy

Автоматически повторять Request безопасно не всегда.

GET обычно повторить проще, чем POST создания платежа.

Proxy должен учитывать HTTP Method и идемпотентность операции.

Прокси и Sticky Sessions

Некоторые приложения требуют, чтобы пользователь в течение Session попадал на один Backend.

Proxy может реализовать Session Affinity по Cookie, IP или другому признаку.

Однако Stateless Architecture обычно масштабируется проще.

Прокси и Cache Hit

Cache Hit означает, что Proxy уже имеет подходящий Response и не обращается к Origin.

Cache Miss — необходимых данных нет, поэтому Request отправляется Backend.

Cache Invalidation

Основная сложность Proxy Cache — своевременно удалить устаревшее содержимое.

Если товар изменил цену, клиент не должен долго видеть старое значение из Cache.

Прокси в корпоративной сети

Компания может направлять весь Browser Traffic через Forward Proxy.

Он проверяет пользователя, применяет Policy и сохраняет Security Logs.

Например, запрещается доступ к известным вредоносным ресурсам, а загрузка определенных типов файлов ограничивается.

Прокси для серверов

Не только сотрудники, но и Servers могут использовать Egress Proxy.

Например, Production Backend разрешено обращаться во внешнюю сеть только через Proxy, который позволяет доступ к заданным API и Package Repositories.

Это уменьшает неограниченный исходящий Internet Access.

Egress Proxy

Egress Proxy централизует исходящий Application Traffic.

Через него удобно применять Allowlist, Logging и Authentication внешних соединений.

Прокси и SSRF

SSRF позволяет злоумышленнику заставить Backend обращаться к нежелательным внутренним или внешним адресам.

Egress Proxy и Firewall Policy могут ограничить Destinations, доступные приложению, и уменьшить последствия части таких атак.

Прокси и производительность

Proxy добавляет промежуточный сетевой Hop и обработку, но при грамотной архитектуре может ускорять систему за счет Cache, Compression, Connection Reuse и близкого расположения к пользователю.

Поэтому Proxy не следует автоматически считать причиной задержки.

Connection Reuse

Proxy может сохранять долгоживущие Connections к Backend и использовать их для множества Client Requests.

Это уменьшает количество TCP и TLS Handshakes.

Прокси как точка отказа

Если Proxy недоступен, пользователь не сможет попасть к рабочему Backend.

Поэтому критичный Proxy необходимо делать отказоустойчивым и мониторить.

Типичные ошибки при настройке прокси

1. Оставить Proxy доступным всему интернету.
2. Не настроить Trusted Proxy в Backend.
3. Передавать неправильный Client IP.
4. Создать слишком короткий Timeout.
5. Кэшировать персональные Responses.
6. Открыть Backend в обход Reverse Proxy.
7. Не настроить Health Checks.
8. Хранить Secrets в Access Logs.
9. Не учитывать WebSocket или Streaming.
10. Создать единственный Proxy без High Availability.

Прямой доступ к Backend в обход Proxy

Если Security Policy реализована на Reverse Proxy, но Backend имеет собственный Public IP, злоумышленник может попытаться обратиться к нему напрямую.

Firewall должен разрешать Backend Connections только от Proxy или Load Balancer.

Как правильно внедрить Reverse Proxy

Шаг 1. Определить внешний Endpoint

Пользователи должны обращаться к Proxy, а не напрямую к Backend.

Шаг 2. Настроить Routing

Определите соответствие Host и Path внутренним сервисам.

Шаг 3. Закрыть Backend

Firewall разрешает Connections только от Proxy.

Шаг 4. Настроить TLS

HTTPS завершается на Proxy или передается дальше в зависимости от модели безопасности.

Шаг 5. Настроить Forwarded Headers

Backend должен корректно определять Client IP и исходный Scheme.

Шаг 6. Добавить Health Checks

Неработающие Backend Instances нужно исключать из Routing.

Шаг 7. Настроить Timeout

Значения должны соответствовать реальной работе приложения.

Шаг 8. Добавить Monitoring

Следите за Latency, 5xx, Connections и состоянием Backends.

Практический пример

Компания имеет три приложения: интернет-магазин, API и административную панель.

Все они размещены во внутренней сети и не имеют прямого Public Access.

Перед ними устанавливается Reverse Proxy с Public IP.

Правила выглядят так:

shop.example.com → 10.0.10.20:8080
api.example.com → 10.0.20.20:8080
admin.example.com → 10.0.30.20:8080

Proxy принимает HTTPS и управляет TLS Certificates.

Для административного домена разрешены Requests только из корпоративного VPN.

Интернет-магазин распределяется между тремя Backend Instances через Load Balancing.

Static Content кэшируется, а персональные Responses не попадают в общий Cache.

Firewall запрещает любые прямые Connections из интернета к Backend.

Access Logs отправляются в централизованную систему, а Health Checks автоматически исключают неработающий экземпляр.

Таким образом, Proxy становится единой контролируемой точкой входа для нескольких приложений.

Прокси-сервер для бизнеса

Для бизнеса Proxy полезен как инфраструктурный слой между пользователями, интернетом и корпоративными приложениями.

Forward Proxy помогает централизовать исходящий Traffic сотрудников и Servers, а Reverse Proxy — защищать и масштабировать публичные сервисы.

Через Proxy можно централизованно управлять TLS Certificates, Logging, Routing и Access Policy, не изменяя каждое приложение отдельно.

При этом сам Proxy становится критичной частью инфраструктуры и требует резервирования, обновления и мониторинга.

Когда нужен Forward Proxy

• нужно контролировать доступ сотрудников в интернет;
• требуется единый Egress Point;
• нужно централизованное Logging;
• серверы должны обращаться только к разрешенным внешним ресурсам;
• необходимо скрыть Client IP от целевого сервиса.

Когда нужен Reverse Proxy

• несколько Backend Servers используют один Public Endpoint;
• нужно централизовать HTTPS;
• требуется Load Balancing;
• нужно маршрутизировать Requests по Host или Path;
• Backend нельзя открывать напрямую;
• требуется кэширование или Rate Limiting.

Связанные термины

Краткий итог

Прокси-сервер — посредник между клиентом и целевым сервисом. Он принимает одно соединение и создает другое, благодаря чему может контролировать, изменять, фильтровать и маршрутизировать Traffic.

Forward Proxy представляет клиента и чаще используется для централизованного выхода в интернет. Reverse Proxy представляет Backend и применяется перед сайтами, API и микросервисами для TLS Termination, Load Balancing, Routing и защиты внутренней инфраструктуры.

Proxy отличается от NAT тем, что активно завершает и создает соединения, а от Firewall — тем, что не только разрешает или запрещает Traffic, но и непосредственно передает его дальше. В production Proxy необходимо защищать от обхода, правильно настраивать Trusted Headers, Timeout, Cache и High Availability.