Reverse Proxy
Тема дорожной карты · Nginx
Обратный прокси — это сервер, стоящий между клиентами и одним или несколькими бэкенд-серверами приложений: он принимает клиентские запросы, перенаправляет их соответствующему вышестоящему сервису и возвращает ответ upstream клиенту; Nginx является одним из наиболее популярных решений для реализации обратного прокси в продакшен-инфраструктуре. Nginx в роли обратного прокси обеспечивает централизованное завершение SSL/TLS, снимая криптографическую нагрузку с серверов приложений, а также буферизацию запросов, манипуляцию заголовками, сжатие и кэширование, улучшающие как производительность, так и безопасность. Основная директива proxy_pass в блоке location указывает Nginx, куда перенаправлять запросы, тогда как директивы proxy_set_header гарантируют, что вышестоящие приложения получают исходный IP и протокол клиента через заголовки X-Real-IP, X-Forwarded-For и X-Forwarded-Proto. Развёртывания обратного прокси Nginx обычно стоят перед серверами приложений на Node.js, Python (Gunicorn/uWSGI), Java (Tomcat/Spring Boot), PHP-FPM и Ruby (Puma), обеспечивая горизонтальное масштабирование за счёт распределения трафика между несколькими экземплярами upstream через блок upstream. Сочетание Nginx в роли обратного прокси с балансировкой нагрузки, проверками работоспособности и SSL/TLS-терминацией составляет основу практически любой современной высокодоступной веб-архитектуры.
Как это работает
Reverse Proxy — самая частая production-роль nginx: принять HTTP от клиентов, пробросить на upstream-backend. proxy_pass http://backend; (с опциональным upstream-блоком для нескольких backend). Прокидывайте client-инфу через proxy_set_header X-Real-IP $remote_addr;, X-Forwarded-For $proxy_add_x_forwarded_for, X-Forwarded-Proto $scheme, Host $host. Таймауты (proxy_connect_timeout, proxy_send_timeout, proxy_read_timeout) предотвращают зависание. WebSocket-поддержка через proxy_http_version 1.1 + Connection: upgrade.
Когда применять
Всегда прокидывайте X-Forwarded-For + X-Real-IP — backend-логи/аудит зависят от реального client-IP. Всегда разумные таймауты; дефолты слишком мягкие (60s) для многих приложений — подгоняйте под SLO. proxy_buffering off — для streaming-ответов (SSE, long polling). keepalive 32; в upstream-блоке — для переиспользования соединений с backend.
Типичные ошибки
Ловушки Reverse Proxy: не прокидывают X-Forwarded-Proto и backend решает HTTPS на основе своего req.protocol (всегда HTTP за nginx); proxy_pass http://backend без trailing slash иногда дополняет location URI (тонкие URL-rewrite — читайте доку); upstream без keepalive (TCP-handshake на каждый запрос); 502 / 504 не обработаны грациозно (дефолтная страница уродлива).
Связанные понятия
Полезные ресурсы
Проверить знания (1)
Загрузка вопросов…