Конспект раздела: обратный прокси

Раздел про решение №4 во второй его ветке: содержимое отдаёт не диск, а другое приложение.

Что настраивают у любого прокси

1. КУДА идёт запрос        proxy_pass (слеш решает, какой URI увидит бэкенд)
2. ЧТО бэкенд знает        proxy_set_header: Host, X-Real-IP, X-Forwarded-*
3. СКОЛЬКО ждать           proxy_connect/send/read_timeout
4. КАК отдавать клиенту    proxy_buffering, proxy_buffer_size

Слеш в proxy_pass

location /api/  +  http://app:8000;      →  /api/cart   (URI как есть)
location /api/  +  http://app:8000/;     →  /cart       (префикс заменён)
location /api   +  http://app:8000/;     →  //cart      (location без слеша → двойной слеш)
location /api   +  http://app:8000/v2/;  →  /v2//cart   ← тоже двойной слеш
location /api/  +  http://$backend/;     →  /           ← переменная выбрасывает путь

Четыре строки заголовков

proxy_set_header Host              $host;
proxy_set_header X-Real-IP         $remote_addr;
proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

Настоящий адрес клиента даёт realip, а не доверие к X-Forwarded-For. Список set_real_ip_from пишут узким, а real_ip_recursive оставляют выключенным, пока доверенное звено одно: с широким списком on позволяет клиенту назначить себе любой адрес.

Другие обработчики

Ловушки раздела списком

• путь в proxy_pass длиннее слеша при непарных концах → двойной слеш и 404;
• переменная в proxy_pass → путь запроса выброшен, бэкенд отвечает корнем;
• своё правило proxy_redirect → умолчание отменено, работавшие редиректы сломаны;
• proxy_set_header/fastcgi_param в location → унаследованные исчезли целиком;
• X-Forwarded-For без realip → подделывается тривиально;
• нет X-Forwarded-Proto → бесконечный редирект за TLS-терминатором;
• proxy_read_timeout - пауза между чтениями, а не общее время;
• 502 too big header - раздутые cookie не влезли в proxy_buffer_size;
• php-локация без try_files $uri =404 - исполнение чужого файла через PATH_INFO;
• каталог загрузок без своего блока - исполнение загруженного shell.php;
• proxy_buffering off глобально - воркер бэкенда занят на всех маршрутах;
• поток «пачками» - это ответ с Content-Length или сжатие, чанкованный идёт сразу и при включённой буферизации;
• бэкенд литеральным адресом, а не группой upstream - соединение на каждый запрос.

Свежее (проверено по CHANGES)

С 1.29.7 proxy_http_version по умолчанию 1.1, keepalive в upstream включён сам, Connection: close бэкенду не шлётся - строка из старых руководств больше не нужна. Значение 2 (HTTP/2 к бэкенду) есть с 1.29.4. Проверено на стенде: keepalive работает в группе, а литеральный адрес в proxy_pass группой не является и открывает соединение на каждый запрос.

Чек-лист: что ты должен уметь объяснить

• Как слеш в proxy_pass меняет URI на бэкенде и когда правда появляется //.
• Что делает с путём переменная в proxy_pass.
• Что бэкенд видит без proxy_set_header и почему это ломает ссылки.
• Чем realip лучше логирования X-Forwarded-For.
• Что именно ограничивает proxy_read_timeout.
• Зачем в WebSocket-конфиге нужен map вместо жёсткого Connection: upgrade.
• Чем на самом деле помогает буферизация и что задерживает поток.
• Почему рубежей у php-локации два и какой из них что закрывает.