Стек веб-сервера: nginx, PHP-FPM и Node

01Что делает веб-сервер и как это делает nginx

Представьте оживлённый ресторан. Хостес у входа встречает каждого гостя, раздаёт меню (статические файлы) и передаёт настоящие заказы на кухню (вашему приложению). Веб-сервер — это и есть хостес. Он слушает порты 80 и 443, разбирает HTTP-запрос, решает, кто должен на него ответить, и отправляет ответ обратно. nginx построен на событийной модели: небольшое число воркеров (обычно по одному на ядро CPU) каждый обслуживает тысячи соединений через неблокирующий ввод-вывод, поэтому простаивающий или медленный клиент почти ничего не стоит. Apache традиционно использовал процесс или поток на соединение (prefork/worker MPM); современный event MPM сократил разрыв, а сильные стороны Apache — файлы .htaccess на уровне каталогов и огромная экосистема модулей. На практике многие стеки, включая большинство хостинг-панелей, ставят nginx впереди для статики и TLS, а Apache держат за ним ради совместимости.

• Master-процесс: читает конфиг, открывает порты, управляет воркерами.
• Воркеры: обслуживают соединения; worker_processes auto подстраивается под число ядер CPU.
• .htaccess в Apache удобен, но читается при каждом запросе; в nginx аналога нет — и это сделано намеренно.

02Server-блоки и location

Конфиг nginx — это дерево. Контекст http хранит глобальные настройки. Внутри него каждый server-блок — это один виртуальный хост, который выбирается по порту и заголовку Host (server_name). Внутри server блоки location сопоставляются с путём URL и решают, что делать: отдать файл, передать в PHP, проксировать в Node или запретить. У сопоставления location есть правила, которые стоит запомнить: первыми побеждают точные совпадения (=), затем самый длинный префикс, если только не совпала ещё и location с регулярным выражением (~) — тогда побеждает первая совпавшая регулярка (префикс ^~ отключает проверку регулярок). try_files — рабочая лошадка: он проверяет реальный файл, затем каталог, а потом откатывается к точке входа приложения. В Ubuntu сайты лежат в /etc/nginx/sites-available и включаются симлинком в sites-enabled.

1server {
2    listen 80;
3    server_name static.example.com;
4    root /var/www/static/public;
5    index index.html;
6 
7    location / {
8        try_files $uri $uri/ =404;
9    }
10 
11    location ~* \.(css|js|svg|png|jpg|webp|woff2)$ {
12        expires 30d;
13        access_log off;
14    }
15 
16    location ~ /\.(?!well-known) {
17        deny all;
18    }
19}

03PHP-FPM: как nginx запускает PHP

nginx сам не умеет выполнять PHP. Он пересылает запрос по протоколу FastCGI в PHP-FPM (FastCGI Process Manager) — отдельный сервис, который держит наготове пул PHP-воркеров. Соединение обычно идёт через Unix-сокет, например /run/php/php8.5-fpm.sock (PHP 8.5 — версия по умолчанию в Ubuntu 26.04; в 24.04 поставляется 8.3). Пул — это группа воркеров со своим пользователем, сокетом и лимитами. Дайте каждому приложению собственный пул, работающий от собственного системного пользователя: тогда взломанный сайт не сможет читать файлы другого сайта, а одно медленное приложение не съест всех воркеров. pm = dynamic масштабирует число воркеров в заданных пределах; pm.max_children — жёсткий потолок, поэтому рассчитывайте его примерно как (RAM под PHP) делённое на (средний объём памяти воркера, для Laravel часто 40–80 MB). Когда заняты все дочерние процессы, запросы встают в очередь, и вы видите ошибки 502/504 и сообщение «server reached pm.max_children» в логе FPM.

1; /etc/php/8.5/fpm/pool.d/api.conf
2[api]
3user = api
4group = api
5listen = /run/php/php8.5-fpm-api.sock
6listen.owner = www-data
7listen.group = www-data
8pm = dynamic
9pm.max_children = 20
10pm.start_servers = 4
11pm.min_spare_servers = 2
12pm.max_spare_servers = 6
13pm.max_requests = 500
14request_terminate_timeout = 60s

04Laravel API за nginx

У Laravel одна точка входа — public/index.php, и корень документов должен указывать на папку public, чтобы .env, storage и vendor никогда не были доступны из веба. try_files сначала отдаёт реальные файлы, а всё остальное отправляет в index.php, сохраняя строку запроса. Использование $realpath_root вместо $document_root важно, когда вы деплоите через симлинк «current»: PHP тогда видит разрешённый путь релиза, и OPcache не продолжает отдавать старый релиз после переключения симлинка. Пути к сертификатам ниже — те, что certbot создаёт для Let's Encrypt. http2 on — современный способ включить HTTP/2; старая форма «listen 443 ssl http2» устарела начиная с nginx 1.25.1.

1server {
2    listen 443 ssl;
3    http2 on;
4    server_name api.example.com;
5    root /var/www/api/current/public;
6    index index.php;
7    ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
8    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;
9    client_max_body_size 20m;
10 
11    location / { try_files $uri $uri/ /index.php?$query_string; }
12 
13    location ~ \.php$ {
14        include snippets/fastcgi-php.conf;
15        fastcgi_pass unix:/run/php/php8.5-fpm-api.sock;
16        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
17        fastcgi_param DOCUMENT_ROOT $realpath_root;
18    }
19    location ~ /\.(?!well-known) { deny all; }
20}

05Фронтенд на Next.js через reverse proxy

Node-приложение (Next.js, NestJS, Express) — это собственный HTTP-сервер, слушающий локальный порт, например 127.0.0.1:3000. nginx работает как reverse proxy: принимает публичное HTTPS-соединение и пересылает запрос на этот порт, добавляя заголовки, чтобы приложение знало реальный IP клиента и протокол. Привязывайте Node-приложение к 127.0.0.1, чтобы до него никогда нельзя было достучаться напрямую. Держите процесс живым через pm2 (pm2 start npm --name web -- start, затем pm2 startup и pm2 save) или через юнит systemd с Restart=always. Блок map относится к контексту http; он пропускает апгрейд до WebSocket, оставляя обычные запросы на переиспользуемых keepalive-соединениях. Добавьте второй server-блок на порту 80, который отвечает 301 с переходом на HTTPS, и включите gzip (gzip_types для CSS, JS, JSON, SVG); для Brotli нужен дополнительный модуль — или можно поручить сжатие на краю CDN вроде Cloudflare.

1map $http_upgrade $connection_upgrade { default upgrade; '' ''; }
2upstream web_app { server 127.0.0.1:3000; keepalive 16; }
3server {
4    listen 443 ssl;
5    http2 on;
6    server_name example.com;
7    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
8    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
9 
10    location / {
11        proxy_pass http://web_app;
12        proxy_http_version 1.1;
13        proxy_set_header Host $host;
14        proxy_set_header X-Real-IP $remote_addr;
15        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
16        proxy_set_header X-Forwarded-Proto $scheme;
17        proxy_set_header Upgrade $http_upgrade;
18        proxy_set_header Connection $connection_upgrade;
19    }
20}

06Перезагрузка и деплой без простоя

Никогда не перезапускайте nginx, чтобы применить изменение конфига. Проверьте конфиг, а затем сделайте reload: master-процесс читает новый конфиг, запускает новых воркеров и даёт старым завершить текущие запросы, прежде чем выйти. Если проверка не прошла, ничего не меняется, и продолжает работать старый конфиг. Та же идея применима к приложениям. PHP-FPM поддерживает плавный reload. Для Laravel деплойте каждый релиз в отдельную папку, выполняйте там composer install и миграции, затем атомарно переключайте симлинк «current» и делайте reload PHP-FPM; откат — это просто возврат симлинка назад. Перезапустите воркеры очередей (php artisan queue:restart), чтобы они подхватили новый код. Для Node pm2 reload в режиме cluster перезапускает инстансы по одному; с единственным инстансом в режиме fork это фактически restart, поэтому для настоящего нулевого простоя запускайте как минимум два инстанса.

1# nginx: validate, then graceful reload
2sudo nginx -t && sudo systemctl reload nginx
3 
4# Laravel release switch (atomic symlink swap)
5ln -sfn /var/www/api/releases/2026-11-05_1200 /var/www/api/current
6sudo systemctl reload php8.5-fpm
7php /var/www/api/current/artisan queue:restart
8 
9# Node: rolling restart of a pm2 cluster
10pm2 reload web

07Хостинг-панели или «голый» сервер

Панели вроде Plesk и cPanel устанавливают и обслуживают за вас весь этот стек: веб-сервер, версии PHP, базы данных, почту, DNS, сертификаты и бэкапы — всё через веб-интерфейс. Они отлично подходят, когда множеством небольших сайтов должны управлять не специалисты или когда вы продаёте хостинг. Цена — контроль и накладные расходы. Панели добавляют лицензионные платежи, лишние сервисы, которые едят память и требуют патчей, собственные шаблоны конфигов, перезаписывающие ручные правки, и большую поверхность атаки (сама панель — это страница входа в интернете). «Голый» сервер с nginx, PHP-FPM, Node и парой скриптов легче и полностью понятен, но каждая его часть на вас: обновления, сертификаты, бэкапы и мониторинг. Для нескольких приложений, которые ведёт инженер, «голый» сервер обычно лучше; для десятков сайтов-визиток и почтовых ящиков панель всё ещё может быть прагматичным выбором.

08Буферизация, медленные клиенты и потоковые ответы

Одна из самых ценных задач nginx незаметна — буферизация. Когда телефон на слабом соединении отправляет форму, nginx сначала читает всё тело запроса (в памяти до client_body_buffer_size, дальше во временный файл) и только потом передаёт его PHP-FPM или Node. На обратном пути он быстро читает весь ответ upstream в proxy- или FastCGI-буферы и сам понемногу отдаёт его медленному клиенту. Дорогой воркер приложения освобождается за миллисекунды, а не занят секундами из-за человека в поезде. Исключение — стриминг: Server-Sent Events, long polling и потоковые ответы AI или отчётов должны доходить до клиента по мере генерации. Для таких location отключайте proxy buffering и увеличивайте proxy_read_timeout, который по умолчанию равен 60 секундам между двумя чтениями. Приложение также может отключить буферизацию для конкретного ответа заголовком X-Accel-Buffering: no.

1location /events/ {
2    proxy_pass http://web_app;
3    proxy_http_version 1.1;
4    proxy_set_header Connection "";
5    proxy_set_header Host $host;
6    proxy_buffering off;          # send bytes as soon as they arrive
7    proxy_cache off;
8    proxy_read_timeout 1h;        # default 60s would cut idle streams
9}

09Microcaching: как пережить всплеск трафика

Для страниц, одинаковых для всех анонимных посетителей (список товаров, публичный ответ API), nginx может кэшировать ответ upstream всего на одну секунду. Звучит бесполезно, но при 500 запросах в секунду это превращает 500 выполнений PHP в одно. fastcgi_cache_lock заставляет параллельные запросы к одному незакэшированному ключу ждать единственного обращения к upstream, а не набрасываться толпой на PHP, а fastcgi_cache_use_stale с updating отдаёт слегка устаревшую копию, пока один запрос обновляет её в фоне. Опасность — закэшировать персональные данные. Кэшируйте только GET и HEAD для анонимных пользователей: обходите кэш, если есть сессионная cookie или заголовок Authorization, и никогда не кэшируйте ответы, которые ставят cookie. Заголовок X-Cache (HIT, MISS, BYPASS, STALE) позволяет проверить поведение через curl -I. proxy_cache работает так же перед Node-приложениями.

1# http context
2fastcgi_cache_path /var/cache/nginx/api levels=1:2 keys_zone=api_cache:50m
3                   max_size=1g inactive=10m use_temp_path=off;
4 
5# inside location ~ \.php$
6fastcgi_cache api_cache;
7fastcgi_cache_key "$scheme$request_method$host$request_uri";
8fastcgi_cache_valid 200 1s;
9fastcgi_cache_lock on;
10fastcgi_cache_use_stale error timeout updating http_500 http_503;
11fastcgi_cache_background_update on;
12fastcgi_cache_bypass $cookie_app_session $http_authorization;
13fastcgi_no_cache     $cookie_app_session $http_authorization;
14add_header X-Cache $upstream_cache_status always;

10Rate limiting через limit_req

limit_req реализует leaky bucket по ключу, обычно по адресу клиента. limit_req_zone находится в контексте http и задаёт ключ, зону общей памяти и скорость (r/s или r/m). На 64-битных системах каждое состояние занимает 128 байт, так что зона 10m отслеживает около 80 000 адресов. limit_req внутри location применяет лимит. burst — размер очереди для запросов сверх скорости. Без nodelay запросы из очереди задерживаются, чтобы уложиться в скорость: upstream работает ровно, но страницы кажутся медленными; с nodelay они обслуживаются сразу, а отклоняются только запросы сверх burst. delay=N (с версии 1.15.7) совмещает оба режима. Отказы по умолчанию отдаются как 503, что для мониторинга выглядит как авария, поэтому задайте limit_req_status 429. Используйте $binary_remote_addr вместо $remote_addr ради экономии памяти и, если впереди стоит CDN, сначала настройте реальные IP, иначе все посетители окажутся в одном ведре CDN.

1# http context
2limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
3limit_req_zone $binary_remote_addr zone=api:10m   rate=10r/s;
4limit_req_status 429;
5 
6# server context
7location = /api/login {
8    limit_req zone=login burst=5 nodelay;
9    try_files $uri /index.php?$query_string;
10}
11location /api/ {
12    limit_req zone=api burst=20 nodelay;
13    try_files $uri /index.php?$query_string;
14}

11Пограничные случаи: default server, реальные IP и лимиты соединений

Если заголовок Host запроса не совпадает ни с одним server_name, nginx передаёт его default server для этого порта — первому объявленному, если ни один не помечен default_server. Сканеры, обращающиеся прямо к вашему IP, увидят ваш первый сайт, а по HTTPS — и его сертификат, что раскрывает, какие домены там живут. Этого позволяет избежать catch-all server, который отклоняет TLS handshake (ssl_reject_handshake, nginx 1.19.4+) и закрывает обычный HTTP нестандартным кодом 444. За Cloudflare или балансировщиком используйте модуль realip: set_real_ip_from для каждого доверенного диапазона прокси и real_ip_header CF-Connecting-IP или X-Forwarded-For, чтобы логи, rate limit и fail2ban видели посетителя. Никогда не доверяйте этому заголовку от недоверенных источников. И наконец, ёмкость: worker_processes, умноженное на worker_connections, ограничивает число одновременных соединений, а проксируемый запрос использует два (клиент плюс upstream), поэтому вместе с worker_connections увеличивайте worker_rlimit_nofile.

1server {
2    listen 80 default_server;
3    listen 443 ssl default_server;
4    server_name _;
5    ssl_reject_handshake on;   # no certificate leaked to IP scanners
6    return 444;                # close the connection without a response
7}
8 
9# http context, behind Cloudflare (one line per range from cloudflare.com/ips)
10set_real_ip_from 173.245.48.0/20;
11real_ip_header CF-Connecting-IP;