Обратный прокси (reverse proxy)

Что такое обратный прокси и чем он отличается от прямого

Руководство MDN делит прокси на два вида. Прямой прокси работает от имени клиентов, например для кеширования или сокрытия того, кто просматривает сайты. Обратный делает противоположное: работает от имени серверов и контролирует и защищает доступ к ним для балансировки нагрузки, аутентификации, расшифровки или кеширования. Посетители видят один публичный адрес и не узнают, какой backend ответил.

В nginx руководство по обратному прокси описывает задачу как отправку запроса клиента проксируемому серверу, получение ответа и возврат его клиенту. Ключевая директива это proxy_pass внутри location. Она может указывать на один backend или на именованную группу серверов, а соседние директивы вроде fastcgi_pass и uwsgi_pass покрывают не-HTTP протоколы приложений. Типичные задачи: терминация TLS один раз на границе, кеширование ответов и распределение нагрузки.

Минимальный обратный прокси на nginx и как его проверить

Этот блок терминирует TLS и передаёт запросы приложению на том же хосте. Заголовок Host важно задать, потому что, как сказано в документации nginx, по умолчанию он равен $proxy_host, то есть адресу backend:

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/ssl/example.com.crt;
    ssl_certificate_key /etc/ssl/example.com.key;
    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Проверьте и перезагрузите конфигурацию без разрыва соединений командой sudo nginx -t && sudo systemctl reload nginx, затем посмотрите заголовки ответа через curl -I https://example.com/. Помните: URI в proxy_pass заменяет совпавшую часть пути запроса, а без URI путь передаётся как есть, что объясняет справочник по модулю proxy. По умолчанию nginx также буферизует ответ backend (proxy_buffering on) и ждёт между чтениями не более 60 секунд (proxy_read_timeout).

Реальный IP клиента и проблема доверия

За прокси backend видит адрес прокси вместо клиента. Исходный адрес несёт заголовок X-Forwarded-For, но MDN говорит прямо: если сервер доступен напрямую, ни одной части этого списка доверять нельзя, а для защитных задач, таких как ограничение частоты, нужно брать только адреса, добавленные доверенным прокси. Любой клиент может отправить поддельный заголовок.

Модуль realip не собирается по умолчанию и подменяет адрес клиента только для перечисленных отправителей:

set_real_ip_from 192.0.2.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Доверяйте только адресам собственных прокси. Широкий диапазон в set_real_ip_from позволяет любому внутри него выбрать себе адрес и обойти limit_req или списки разрешённых. Если прокси в цепочке несколько, real_ip_recursive on заставляет nginx брать из заголовка последний недоверенный адрес, а не просто последний.

Плюсы для безопасности, риски и место в защите

Обратный прокси даёт одно место, где можно настроить TLS, заголовки безопасности, ограничение частоты запросов и WAF, а CDN перед ним может поглотить флуд до того, как он дойдёт до вас. Он также скрывает исходный сервер, но только пока его адрес остаётся закрытым. Если backend по-прежнему отвечает из открытого интернета, атакующие могут обойти прокси целиком, поэтому закройте его межсетевым экраном для всех, кроме прокси.

Риски связаны с настройкой. Прокси это единая точка отказа. Неверное доверие к пересылаемым заголовкам ломает журналы и лимиты. Если цель proxy_pass строится из данных клиента, например $http_host, посетители выбирают, куда подключается nginx, и он превращается в открытый прокси. Пройдите руководство по безопасности nginx, а о роли CDN и об атаке SYN-флуд читайте в руководстве по защите от DDoS.

Связанные термины: nginx, TLS / SSL, WAF, Ограничение частоты запросов, limit_req.