Nginx & Docker — деплой и обслуживание веб-сервисов

Nginx (произносится «энджин-икс») — HTTP-сервер и обратный прокси (reverse proxy). Создан в 2004 году Игорем Сысоевым для Rambler.ru как ответ на «C10k problem» — как обслужить 10 000 одновременных соединений на одном сервере, не съев всю память. С тех пор стал одним из двух главных веб-серверов интернета (второй — Apache).

В типовой архитектуре Nginx стоит первым, между интернетом и приложением:

Ключевое архитектурное отличие Nginx от старого Apache prefork — модель обработки соединений.

В 2026 году в мире Laravel/PHP-хостинга Nginx выиграл. Apache остался в 3 нишах: cPanel-хостинг (legacy), Windows-стек, и когда нужен .htaccess в shared-хостинге с mod_rewrite «на лету». Всё что новое строится — на Nginx.

# 1. Обновить индексы пакетов
sudo apt update

# 2. Поставить nginx
sudo apt install nginx -y

# 3. Автозапуск при загрузке системы
sudo systemctl enable nginx

# 4. Стартанули
sudo systemctl start nginx

# 5. Проверка версии
nginx -v          # короткая версия
nginx -V          # с флагами сборки: --with-http_ssl_module и т.д.

На CentOS / RHEL / AlmaLinux / Rocky: sudo dnf install nginx -y (или yum на старых). На macOS (dev): brew install nginx.

Nginx на Debian/Ubuntu раскладывает файлы по нескольким директориям — это важно знать, чтобы понимать что где искать:

/etc/nginx/
├── nginx.conf              # ГЛАВНЫЙ конфиг — общие настройки, worker'ы, включает всё остальное
├── mime.types              # таблица MIME-типов (.css → text/css, .png → image/png)
├── fastcgi_params          # стандартные переменные для FastCGI (PHP-FPM)
├── proxy_params            # стандартные заголовки для reverse proxy
├── snippets/               # переиспользуемые куски (fastcgi-php.conf, ssl-params.conf)
│   ├── fastcgi-php.conf
│   └── ssl-params.conf
├── conf.d/                 # *.conf файлы, включаемые из nginx.conf через include
│   └── (по умолчанию пусто)
├── sites-available/        # ВСЕ конфиги сайтов (по одному файлу на сайт)
│   ├── default
│   ├── example.com
│   └── api.example.com
└── sites-enabled/          # СИМЛИНКИ на активные сайты из sites-available/
    ├── default -> ../sites-available/default
    └── example.com -> ../sites-available/example.com

/var/log/nginx/             # ЛОГИ
├── access.log              # все запросы
├── error.log               # ошибки, критично при отладке
├── access.log.1.gz         # ротированные (logrotate)
└── error.log.1.gz

/var/www/                   # типичное место для сайтов (традиция, не обязательно)
├── html/                   # дефолтная welcome-страница
└── example.com/            # твой Laravel-проект
    └── public/             # root у Laravel всегда = public/

/usr/sbin/nginx             # сам бинарник
/var/run/nginx.pid          # PID главного процесса (нужен для reload)

Это Debian-специфичный паттерн (в CentOS его нет — там просто conf.d/*.conf). Идея простая:

• sites-available/ — хранилище всех конфигов сайтов. Даже отключённые сайты остаются здесь.
• sites-enabled/ — активные сайты. Это только симлинки на файлы из sites-available/.
• nginx.conf подключает через include /etc/nginx/sites-enabled/*; — только то, что в enabled.

Включить сайт:

# Создать симлинк
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

# Проверить конфиг
sudo nginx -t

# Применить
sudo systemctl reload nginx

Отключить сайт (без удаления файла):

sudo rm /etc/nginx/sites-enabled/example.com
sudo systemctl reload nginx

На маке Nginx ставят через Homebrew — для локальной разработки, не для прода. Устройство там заметно другое, чем на Debian, и первые грабли начинаются сразу.

# 1. Установка
brew install nginx

# 2. Запуск как сервис (поднимется и после перезагрузки)
brew services start nginx

# 3. Статус всех brew-сервисов
brew services list

# 4. Перезапуск после правки конфига
brew services restart nginx

# 5. Проверка
nginx -v
curl http://localhost:8080

Симлинк (symbolic link, символьная ссылка) — файл-указатель на другой файл или папку. По смыслу то же, что ярлык в Windows: сам он ничего не содержит, только говорит «иди туда, там настоящий файл».

Когда ты набираешь nginx, система:

1. находит nginx в PATH — это /opt/homebrew/bin/nginx;
2. видит, что это симлинк;
3. переходит по нему в Cellar/nginx/1.31.7/bin/nginx;
4. запускает настоящий бинарник.

# ln -s ЦЕЛЬ ИМЯ_ССЫЛКИ    (-s = symbolic)
ln -s /opt/homebrew/Cellar/nginx/1.31.7/bin/nginx /opt/homebrew/bin/nginx

# Посмотреть
ls -l /opt/homebrew/bin/nginx
# lrwxr-xr-x@ 1 observer admin 32 ... nginx -> ../Cellar/nginx/1.31.7/bin/nginx
#  ↑ первая буква l = link, стрелка показывает цель

# Куда указывает, одной командой
readlink /opt/homebrew/bin/nginx

# Перезаписать существующий симлинк (-f = force)
ln -sf /новый/путь/nginx /opt/homebrew/bin/nginx

$ ls -l /opt/homebrew/bin/nginx
lrwxr-xr-x ... nginx -> ../Cellar/nginx/1.31.7/bin/nginx   # ссылка есть

$ nginx
zsh: no such file or directory: nginx                        # цели нет

# Починить
brew link nginx          # пересоздать ссылки формулы
brew reinstall nginx     # если link не помог

# Найти все битые ссылки в каталоге
find /opt/homebrew/bin -type l ! -exec test -e {} \; -print

PHP-FPM из Homebrew по умолчанию слушает TCP-порт 9000, а не unix-сокет — в отличие от Debian, где обычно /run/php/php8.3-fpm.sock. Это первое, обо что спотыкаются при переносе конфига с сервера на мак.

# Ставим PHP (придёт вместе с php-fpm) и запускаем
brew install php@8.3
brew services start php@8.3

# Проверить, на чём слушает
grep "^listen =" /opt/homebrew/etc/php/8.3/php-fpm.d/www.conf
# listen = 127.0.0.1:9000

Конфиг сайта кладём в servers/ — например /opt/homebrew/etc/nginx/servers/myapp.conf:

server {
    listen 8000;
    server_name localhost;

    # У Laravel root ВСЕГДА указывает на public/
    root /Users/username/projects/myapp/public;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass 127.0.0.1:9000;   # на Debian тут был бы unix-сокет
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

# Проверить синтаксис и применить
nginx -t
brew services restart nginx

Соглашение: /var/www/example.com/ — корень проекта, /var/www/example.com/public/ — то, что Nginx смотрит как root (там лежит index.php). Владелец — www-data:www-data (пользователь, под которым бегает Nginx и PHP-FPM на Ubuntu/Debian).

sudo mkdir -p /var/www/example.com
sudo chown -R $USER:www-data /var/www/example.com
cd /var/www/example.com

# Клонируем проект
git clone git@github.com:youruser/yourrepo.git .

# Права: storage и bootstrap/cache должны быть writable для www-data
sudo chown -R www-data:www-data storage bootstrap/cache
sudo chmod -R 775 storage bootstrap/cache

Всегда проверяй конфиг ДО перезапуска:

sudo nginx -t

Что покажет:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Или с ошибкой:

nginx: [emerg] "server" directive is not allowed here in /etc/nginx/sites-enabled/example.com:15
nginx: configuration file /etc/nginx/nginx.conf test failed

Идиоматический workflow:

# 1. Правим конфиг
sudo nano /etc/nginx/sites-available/example.com

# 2. Проверяем синтаксис
sudo nginx -t

# 3. Если ок — reload
sudo systemctl reload nginx

# Одной командой (сначала проверка, потом reload):
sudo nginx -t && sudo systemctl reload nginx

До systemd управляли через kill -СИГНАЛ <master-pid>. Иногда полезно понимать, что делает reload:

# PID главного процесса
cat /var/run/nginx.pid

# Ручной reload через сигнал (эквивалент systemctl reload)
sudo kill -HUP $(cat /var/run/nginx.pid)

# После logrotate — переоткрыть логи
sudo kill -USR1 $(cat /var/run/nginx.pid)

Приложение не отвечает — по шагам:

1. sudo systemctl status nginx — что говорит systemd. active (running) — Nginx жив, дело в бэкенде. failed — Nginx не запускается.
2. sudo journalctl -u nginx -n 50 --no-pager — последние 50 строк лога сервиса. Причина падения обычно в первой красной строке.
3. sudo tail -f /var/log/nginx/error.log — живой поток ошибок Nginx. Показывает 502/504/permission denied/upstream timed out.
4. sudo nginx -t — если правил конфиг перед падением, проверь синтаксис.
5. ss -tlnp | grep -E ':80|:443' — что вообще слушает эти порты (может, Apache занял).
6. sudo systemctl status php8.3-fpm — если Nginx работает, но 502 — умер PHP-FPM.

Nginx-конфиг иерархический — директивы живут в разных контекстах:

Директивы наследуются от родителя к потомку: gzip on в http — включает gzip во всех server внутри.

# /etc/nginx/nginx.conf — главный конфиг

# Под каким пользователем работают worker-процессы
user www-data;

# Кол-во worker'ов. auto = равно кол-ву CPU-ядер (оптимально)
worker_processes auto;

# PID главного процесса — где записан
pid /run/nginx.pid;

# Динамические модули (brotli, geoip и т.д.)
include /etc/nginx/modules-enabled/*.conf;

events {
    # Сколько соединений на один worker (не то же, что клиентов!)
    worker_connections 1024;
    # worker_connections × worker_processes = максимум соединений сервера
    # 1024 × 4 CPU = 4096 одновременных клиентов
}

http {
    # ───── I/O оптимизации ─────
    sendfile on;              # Ядро копирует файл сразу в сокет — быстро
    tcp_nopush on;            # Отправить заголовок и данные одним пакетом
    tcp_nodelay on;           # Не буферизовать (нужно для keep-alive)

    # ───── Таймауты ─────
    keepalive_timeout 65;     # Держать соединение открытым 65 сек
    client_body_timeout 12;   # Ждать тело запроса 12 сек
    client_header_timeout 12; # Ждать заголовки 12 сек
    send_timeout 10;          # Между двумя send'ами клиенту

    # ───── Размеры ─────
    client_max_body_size 20M; # !! Максимальный upload (по умолчанию 1M — часто мало)
    client_body_buffer_size 16K;
    large_client_header_buffers 4 8k;

    # ───── MIME-типы ─────
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    # ───── Скрыть версию Nginx (безопасность) ─────
    server_tokens off;

    # ───── Gzip компрессия ─────
    gzip on;
    gzip_vary on;               # Vary: Accept-Encoding — важно для CDN/кешей
    gzip_min_length 1024;      # Не жать файлы меньше 1KB (накладные больше выигрыша)
    gzip_comp_level 5;         # 1..9. 5 — золотая середина CPU/размер
    gzip_types
        text/plain text/css application/json application/javascript
        text/xml application/xml application/xml+rss text/javascript
        application/vnd.ms-fontobject application/x-font-ttf font/opentype
        image/svg+xml image/x-icon;

    # ───── Логи ─────
    log_format main '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';
    access_log /var/log/nginx/access.log main;
    error_log  /var/log/nginx/error.log warn;

    # ───── Подключаем конфиги сайтов ─────
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Server block = виртуальный хост = конфигурация одного сайта. На одном сервере с одним IP могут крутиться десятки сайтов — Nginx различает их по заголовку Host, который присылает браузер.

Каждый сайт — свой файл в /etc/nginx/sites-available/, симлинк в sites-enabled/.

# /etc/nginx/sites-available/example.com
server {
    listen 80;
    listen [::]:80;                    # IPv6
    server_name example.com www.example.com;

    root /var/www/example.com/public;
    index index.html index.htm index.php;

    location / {
        try_files $uri $uri/ =404;
    }
}

Пришёл запрос GET /page HTTP/1.1 с Host: example.com. Nginx:

1. Смотрит на порт и IP из listen. Отбрасывает блоки, которые не слушают этот адрес.
2. Из оставшихся сравнивает заголовок Host с server_name:
   • Точное совпадение (example.com)
   • Затем wildcard в начале (*.example.com)
   • Затем wildcard в конце (example.*)
   • Затем regex
3. Если ничего не подошло — берётся default_server (в listen 80 default_server;), либо первый server-блок в конфиге.

# Блок 1: HTTP → HTTPS редирект
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    # Один return, всё остальное — незачем
    return 301 https://example.com$request_uri;
}

# Блок 2: www → non-www на HTTPS
server {
    listen 443 ssl http2;
    server_name www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    return 301 https://example.com$request_uri;
}

# Блок 3: основной сайт
server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    root /var/www/example.com/public;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # PHP — см. раздел про PHP-FPM
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

location — правило для конкретного URL-пути внутри server. По одному URL может подходить несколько location'ов — Nginx выбирает один по приоритету.

server {
    listen 80;
    server_name example.com;
    root /var/www/example.com/public;

    # 1. Точное — favicon.ico. Отдать без логирования.
    location = /favicon.ico {
        access_log off;
        log_not_found off;
    }

    # 2. Префикс с приоритетом ^~ — вся /admin/ через специальный handler
    location ^~ /admin/ {
        auth_basic "Admin area";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }

    # 3. Regex case-insensitive — статика с кешем на год
    location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff|woff2)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # 4. Regex — PHP-файлы через FPM
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }

    # 5. Дефолтный префикс — Laravel-роутинг: не файл? → index.php
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

try_files — пробует найти файлы по очереди, отдаёт первый существующий. Последний аргумент — что делать, если ничего не нашлось.

try_files $uri $uri/ /index.php?$query_string;

Разбор: для запроса GET /blog/hello-world:

1. $uri = /blog/hello-world — есть такой файл в root? Нет.
2. $uri/ = /blog/hello-world/ — есть такая директория? Нет.
3. Fallback: передать в /index.php?$query_string — Laravel возьмёт URL из REQUEST_URI и разберётся сам через свой роутер.

Обе задают путь на диске, но по-разному считают URL:

# root — доступ к /static/logo.png → /var/www/site/static/logo.png
location /static/ {
    root /var/www/site;
}

# alias — тот же URL /static/logo.png → /var/www/assets/logo.png
location /static/ {
    alias /var/www/assets/;   # !! обязательно / в конце
}

PHP-FPM (FastCGI Process Manager) — отдельный сервис, который держит пул PHP-процессов и обрабатывает запросы по протоколу FastCGI. Nginx не умеет сам исполнять PHP — он передаёт запрос PHP-FPM'у, тот выполняет index.php, возвращает результат, Nginx отдаёт клиенту.

# Добавляем PPA от Ondrej (все свежие версии PHP)
sudo add-apt-repository ppa:ondrej/php -y
sudo apt update

# Ставим PHP 8.3 FPM + типовые расширения для Laravel
sudo apt install -y \
    php8.3-fpm php8.3-cli \
    php8.3-mysql php8.3-pgsql php8.3-sqlite3 \
    php8.3-mbstring php8.3-xml php8.3-curl php8.3-zip \
    php8.3-gd php8.3-bcmath php8.3-intl php8.3-redis

# Автозапуск + старт
sudo systemctl enable php8.3-fpm
sudo systemctl start php8.3-fpm

# Проверка
sudo systemctl status php8.3-fpm
php -v

/etc/php/8.3/fpm/
├── php.ini                # общий php.ini для FPM (memory_limit, upload_max_filesize)
├── php-fpm.conf           # глобальные настройки FPM
└── pool.d/
    └── www.conf           # настройки пула по умолчанию (user, socket, pm.*)

/run/php/
└── php8.3-fpm.sock        # unix-сокет, через который Nginx стучится к FPM

/var/log/php8.3-fpm.log    # логи FPM (fatal ошибки PHP)

[www]
user = www-data
group = www-data

# Слушать на unix-сокете (быстрее TCP на localhost)
listen = /run/php/php8.3-fpm.sock
listen.owner = www-data
listen.group = www-data

# Управление процессами
pm = dynamic          # dynamic / static / ondemand
pm.max_children = 20  # макс одновременно PHP-процессов
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500 # перезапускать процесс каждые 500 запросов (защита от утечек)

# Логи медленных запросов
slowlog = /var/log/php8.3-fpm.slow.log
request_slowlog_timeout = 5s

Через unix-сокет (рекомендуется, если Nginx и FPM на одной машине):

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

Через TCP (когда FPM на другом сервере):

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass 127.0.0.1:9000;
}

Содержимое snippets/fastcgi-php.conf — стандартный шаблон Ubuntu:

# Regex splits PATH_INFO from SCRIPT_FILENAME
fastcgi_split_path_info ^(.+?\.php)(/.*)$;

# Проверка что файл существует ДО передачи в FPM
try_files $fastcgi_script_name =404;

# Передаваемые FastCGI-параметры
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
include fastcgi_params;

server {
    listen 80;
    server_name example.com;
    root /var/www/example.com/public;
    index index.php;

    client_max_body_size 20M;
    charset utf-8;

    # Все URL Laravel: файл нет → отдать в index.php
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # favicon и robots — молча, без логов
    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    # PHP через FPM
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_read_timeout 300;   # для долгих операций (импорт CSV и т.п.)
    }

    # Запретить доступ к .htaccess и любым скрытым файлам
    location ~ /\.(?!well-known).* {
        deny all;
    }

    error_log /var/log/nginx/example.com.error.log;
    access_log /var/log/nginx/example.com.access.log;
}

Оба называются «прокси» и оба пересылают трафик, но стоят по разные стороны и решают противоположные задачи.

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;

        # Без этих заголовков бэкенд увидит вместо клиента сам Nginx
        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;
    }
}

После проксирования бэкенд видит TCP-соединение от Nginx. Настоящий IP, хост и схему нужно передать явно.

upstream backend {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;

    # Держать соединения открытыми — экономит TCP-рукопожатия
    keepalive 32;
}

server {
    location / {
        proxy_pass http://backend;

        # keepalive к upstream работает только с HTTP/1.1 и пустым Connection
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

WebSocket начинается как обычный HTTP-запрос с просьбой сменить протокол. Nginx должен эту просьбу пропустить, иначе соединение оборвётся на рукопожатии.

location /ws {
    proxy_pass http://127.0.0.1:6001;

    proxy_http_version 1.1;
    proxy_set_header Upgrade    $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host       $host;

    # Иначе Nginx разорвёт простаивающий сокет через 60 секунд
    proxy_read_timeout 3600s;
}

TLS (Transport Layer Security) — криптографический протокол, который даёт три вещи:

Самая частая схема в проде: HTTPS заканчивается на reverse proxy, а дальше внутрь идёт обычный HTTP.

По шагам:

1. Прокси держит сертификаты. Например для example.com. Сертификат содержит публичный ключ и подпись удостоверяющего центра (CA).
2. Клиент подключается по HTTPS. Происходит TLS handshake: стороны договариваются о шифрах, клиент проверяет сертификат, обмениваются ключами.
3. Прокси «разбирает» TLS — расшифровывает входящий трафик. Это и называется терминацией.
4. Дальше идёт расшифрованный HTTP — обычно во внутреннюю сеть: http://backend:3000 или к PHP-FPM.
5. Бэкенд не думает про сертификаты. Ему не нужно настраивать HTTPS, обновлять сертификаты и следить за версиями TLS — он получает обычный HTTP-запрос.

# Установка (Debian/Ubuntu)
sudo apt install certbot python3-certbot-nginx -y

# Выпуск сертификата — certbot сам правит конфиг Nginx и перезагружает его
sudo certbot --nginx -d example.com -d www.example.com

# Только выпустить, конфиг не трогать
sudo certbot certonly --nginx -d example.com

# Проверить автопродление вхолостую
sudo certbot renew --dry-run

# Список выпущенных
sudo certbot certificates

# HTTP — только редирект на HTTPS
server {
    listen 80;
    server_name example.com www.example.com;

    # Исключение для certbot, иначе продление сломается
    location /.well-known/acme-challenge/ {
        root /var/www/html;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    http2 on;
    server_name example.com www.example.com;

    # Сертификат и приватный ключ
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Только современные версии — 1.0 и 1.1 устарели и небезопасны
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384;

    # Кеш сессий — меньше полных handshake'ов
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # OCSP stapling — сервер сам прикладывает ответ о валидности
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
    resolver 1.1.1.1 8.8.8.8 valid=300s;

    # HSTS — браузер запомнит, что сюда только по HTTPS
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    root /var/www/example.com/public;
    index index.php;
}

Rate limiting — ограничение количества запросов от одного клиента за промежуток времени. Проще: «не больше N запросов в секунду с одного IP, пользователя или API-ключа».

• не больше 5 запросов в секунду с одного IP;
• не больше 100 запросов в минуту на один API-ключ;
• не больше 10 попыток логина в минуту с одного IP.

При превышении сервер обычно возвращает 429 Too Many Requests или 503, либо задерживает запрос, либо ненадолго ставит его в очередь.

# Зона объявляется в http-блоке, один раз
limit_req_zone $binary_remote_addr zone=api:10m rate=5r/s;

server {
    location /api/ {
        limit_req zone=api burst=10 nodelay;
        limit_req_status 429;        # по умолчанию 503
        proxy_pass http://backend;
    }
}

limit_conn_zone $binary_remote_addr zone=addr:10m;

server {
    limit_conn addr 10;          # максимум 10 соединений с одного IP
    limit_conn_status 429;
}

# В http-блоке: убрать версию Nginx из заголовка Server и страниц ошибок
server_tokens off;

# Доступ по IP — порядок директив важен
location /admin/ {
    allow 203.0.113.0/24;
    allow 10.0.0.5;
    deny  all;                 # всё остальное — 403
}

# Закрыть служебные файлы
location ~ /\.(?!well-known) {
    deny all;
}

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options    "nosniff" always;
add_header X-Frame-Options           "SAMEORIGIN" always;
add_header Referrer-Policy           "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy    "default-src 'self'" always;

Slowloris — атака медленными запросами. Атакующий открывает много соединений и шлёт заголовки по байту, не завершая запрос. Соединения висят, воркеры заняты, новые клиенты не обслуживаются. Трафика почти нет — обычные анти-DDoS срабатывают плохо.

client_header_timeout 10s;   # сколько ждём заголовки целиком
client_body_timeout   10s;   # сколько ждём тело запроса
send_timeout          10s;   # пауза между записями при ответе
keepalive_timeout     15s;   # дефолт 75s — слишком щедро

client_max_body_size  20m;   # заодно от залива огромных файлов

limit_conn_zone $binary_remote_addr zone=slow:10m;
limit_conn slow 20;

Самое частое заблуждение: «настроили rate limit и headers — безопасность закрыта». Nginx и приложение защищают разные вещи и работают вместе, а не вместо друг друга.

http {
    server_tokens off;

    client_header_timeout 10s;
    client_body_timeout   10s;
    keepalive_timeout     15s;
    client_max_body_size  20m;

    limit_req_zone  $binary_remote_addr zone=general:10m rate=30r/s;
    limit_req_zone  $binary_remote_addr zone=login:10m   rate=5r/m;
    limit_conn_zone $binary_remote_addr zone=addr:10m;

    limit_req_status  429;
    limit_conn_status 429;

    server {
        limit_req  zone=general burst=50 nodelay;
        limit_conn addr 20;

        # Логин — отдельный жёсткий лимит против брутфорса
        location = /login {
            limit_req zone=login burst=3 nodelay;
            try_files $uri /index.php?$query_string;
        }
    }
}

Уровни кэша не заменяют друг друга, а дополняют. Запрос может быть обслужен на любом из них — чем раньше, тем дешевле.

# В http-блоке: где хранить и сколько памяти под ключи
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m
                 max_size=1g inactive=60m use_temp_path=off;

server {
    location / {
        proxy_cache my_cache;
        proxy_cache_valid 200 301 10m;      # успешные — 10 минут
        proxy_cache_valid 404 1m;               # ошибки — минуту

        # Не отдавать кэш авторизованным
        proxy_cache_bypass $cookie_session;
        proxy_no_cache     $cookie_session;

        # Удобно видеть в ответе HIT / MISS / BYPASS
        add_header X-Cache-Status $upstream_cache_status;

        proxy_pass http://backend;
    }
}

Ключ по умолчанию — $scheme$proxy_host$request_uri. Всё, чего в ключе нет, кэш считает одинаковым.

# Для PHP-FPM напрямую, без промежуточного HTTP-бэкенда
fastcgi_cache_path /var/cache/nginx/fcgi levels=1:2 keys_zone=php:10m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

location ~ \.php$ {
    fastcgi_cache php;
    fastcgi_cache_valid 200 1m;        # микрокеширование
    fastcgi_cache_bypass $cookie_laravel_session;
    fastcgi_no_cache     $cookie_laravel_session;
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

Бесплатного способа «сбросить один URL» в открытом Nginx нет — директива proxy_cache_purge есть только в коммерческом Nginx Plus. В open source три варианта:

На небольших и средних проектах proxy_cache часто закрывает задачу полностью. Varnish мощнее и гибче — VCL, ESI, продвинутая инвалидация, — но Nginx проще по одной причине: он уже стоит как reverse proxy, и кэш включается парой директив вместо отдельного сервиса в стеке.