Настройка Nginx: конфигурация, оптимизация, безопасность

Проблема: стандартный Nginx не выдерживает нагрузку

Клиент обратился: типовой проект на Laravel 10 и PHP 8.3 падал при 1000 параллельных запросах. Nginx из репозитория выдавал частые 502, статика грузилась по 3–5 секунд. Мы выяснили, что worker_connections и fastcgi буферы были дефолтными, кэширование не настроено, а rate limiting отсутствовал. После глубокой оптимизации — агрессивного кэширования, тюнинга SSL и введения rate limiting — P99 latency упал с 5 секунд до 200 мс, сервер стабильно держит 12 000 RPS. Ниже — проверенные настройки из продакшена, которые мы применяем на всех проектах. Свяжитесь с нами для аудита вашего проекта — оценим текущую конфигурацию и предложим оптимальный план.

Мы не просто копируем типовые конфиги, а адаптируем под конкретный стек. Для одних подходит микротинг worker_processes под ядра CPU, для других — активация sendfile и tcp_nopush. Важно понимать, где узкое место: дисковая подсистема, сеть или сам бэкенд.

Какие проблемы решаем

• Медленная загрузка страниц из-за неэффективной обработки статики и отсутствия кэширования. Например, отдача CSS/JS без gzip и без expires.
• Падения под нагрузкой из-за неверно настроенных таймаутов и буферов fastcgi. Частая причина — worker_connections = 1024 при ожидаемых 10k RPS.
• Утечки памяти из-за плохих конфигураций worker_processes и worker_connections. На VPS с 2 ГБ RAM лучше ставить auto, а вручную ограничивать 2 процессами.
• DDoS-атаки на API или логин — без rate limiting даже простая бот-сеть положит сервер. Мы используем зоны по $binary_remote_addr с ограничением 30/5 запросов в минуту.
• Небезопасная конфигурация: открытые server_tokens, слабые SSL-настройки, отсутствие HSTS.

Базовая конфигурация для Laravel/PHP

Стартовая точка — этот шаблон. Мы используем его для 80% PHP-проектов.

# /etc/nginx/sites-available/myapp.conf
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;
    root /var/www/myapp/current/public;
    index index.php;

    # SSL
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;

    # Заголовки безопасности
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    add_header X-Frame-Options "DENY" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    charset utf-8;
    client_max_body_size 50M;

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

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
        fastcgi_buffers 16 16k;
        fastcgi_buffer_size 32k;
        fastcgi_read_timeout 300;
    }

    # Статика — максимальное кеширование
    location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg|woff2?|ttf|eot)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
        access_log off;
    }

    # Запретить доступ к скрытым файлам
    location ~ /\. {
        deny all;
        access_log off;
        log_not_found off;
    }
}

Дополнительные настройки

Reverse Proxy для Node.js

Если бэкенд на Node.js, меняем fastcgi на proxy_pass:

upstream nodejs_app {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
    keepalive 32;
}

server {
    listen 443 ssl http2;

    location / {
        proxy_pass http://nodejs_app;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        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;
        proxy_cache_bypass $http_upgrade;
        proxy_read_timeout 300;
    }
}

Gzip и кеширование

Отдельный файл для gzip и proxy_cache:

# /etc/nginx/conf.d/gzip.conf
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_min_length 1024;
gzip_types
    text/plain text/css text/xml text/javascript
    application/json application/javascript application/xml+rss
    application/atom+xml image/svg+xml font/ttf font/otf;

# Proxy cache (для кеширования ответов бэкенда)
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=app_cache:10m
                 max_size=1g inactive=60m use_temp_path=off;

location /api/public/ {
    proxy_cache app_cache;
    proxy_cache_valid 200 10m;
    proxy_cache_use_stale error timeout updating;
    add_header X-Cache-Status $upstream_cache_status;
    proxy_pass http://app;
}

Rate Limiting

Защита API и логина:

limit_req_zone $binary_remote_addr zone=api:10m rate=30r/m;
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location /api/ {
    limit_req zone=api burst=10 nodelay;
    limit_req_status 429;
    proxy_pass http://app;
}

location /login {
    limit_req zone=login burst=2 nodelay;
    proxy_pass http://app;
}

Логирование

Формат JSON для интеграции с системами мониторинга:

log_format combined_json escape=json
    '{'
        '"time":"$time_iso8601",'
        '"remote_addr":"$remote_addr",'
        '"method":"$request_method",'
        '"uri":"$request_uri",'
        '"status":$status,'
        '"request_time":$request_time,'
        '"bytes_sent":$bytes_sent,'
        '"http_referer":"$http_referer",'
        '"http_user_agent":"$http_user_agent"'
    '}';

access_log /var/log/nginx/access.log combined_json;
error_log  /var/log/nginx/error.log warn;

Тестирование конфигурации

Простые команды для проверки:

Сравнение до/после

Процесс работы

1. Аудит текущей конфигурации — проверяем log-файлы, нагрузку, выявляем узкие места.
2. Проектирование архитектуры — выбираем схему (reverse proxy, standalone, с upstream).
3. Реализация — настройка виртуальных хостов, SSL (Let's Encrypt или ваш сертификат), rate limiting, кэширование, gzip, заголовки безопасности, логирование, оптимизация worker-процессов.
4. Тестирование — нагрузочное тестирование (ab, wrk), проверка безопасности (SSL Labs), анализ логов.
5. Документация — схема конфигурации, команды управления, инструкция по обновлению.

Что входит в работу

• Полная документация конфигурации с описанием всех параметров.
• Скрипты автоматизации развёртывания (Ansible или Docker Compose).
• Настройка мониторинга и оповещений (Prometheus + Alertmanager или аналоги).
• Обучение вашей команды: как вносить изменения, выполнять рестарт, анализировать логи.
• Гарантия на работоспособность конфига 30 дней с поддержкой.

Наш опыт

Мы работаем с Nginx более 8 лет. За это время настроили свыше 100 production-серверов для проектов от лендингов до высоконагруженных e-commerce платформ. На каждый проект выдаём документацию и гарантию 30 дней на работоспособность конфига.

Согласно официальной документации Nginx, правильная настройка уровня OS (sysctl) и worker'ов даёт прирост пропускной способности до 50%.

Как настроить rate limiting для защиты от DDoS?

Для каждого сценария — своя зона. Для API мы используем лимит 30 запросов в минуту на IP с burst 10. Для логина — 5 запросов в минуту с burst 2. Обязательно выставляем limit_req_status 429 и логируем reject'ы. Комбинируем с geo-фильтрацией и fail2ban. Такой подход отражает даже простые DDoS-атаки.

Почему SSL влияет на Core Web Vitals?

SSL-рукопожатие напрямую сказывается на LCP и TTFB. Если настроены слабые шифры (TLS 1.0) или отсутствует OCSP Stapling, время handshake может достигать 300 мс. Мы используем только TLS 1.2/1.3, современные ciphers ECDHE+AES-GCM и включаем OCSP Stapling. Это снижает TTFB на 15–20% без дополнительных затрат.

Пошаговая проверка конфигурации

1. Выполните nginx -t — убедитесь в синтаксической корректности.
2. Загрузите нагрузку с помощью ab -n 1000 -c 100 и отслеживайте статусы ответов.
3. Проверьте заголовки безопасности через curl: curl -I https://example.com | grep -i strict.
4. Протестируйте rate limiting: отправьте 100 запросов за 1 минуту и убедитесь, что 429 появляется после превышения лимита.

Получите консультацию инженера — мы бесплатно оценим ваш проект и предложим оптимальный план настройки Nginx. Свяжитесь с нами для аудита текущей конфигурации.

Мы регулярно сталкиваемся с ситуацией: «Сайт не открывается» в 3 часа ночи — и выясняется, что disk full на VPS, потому что логи nginx не ротировались полгода. Или сервер лёг под нагрузкой в день запуска рекламной кампании, потому что на shared хостинге стоял лимит в 50 одновременных соединений. Настройка хостинга и деплоя — это не про «где дешевле», это про то, что происходит в момент, когда что-то идёт не так. Наша команда помогает избежать таких инцидентов, проектируя инфраструктуру с учётом реальных паттернов нагрузки.

Когда выбирать Vercel и Netlify?

Vercel создан под Next.js — деплой в один push, preview deployments для каждого PR, автоматический CDN, Edge Functions, ISR без конфигурации. Для фронтенд-проектов и JAMstack это оптимальный выбор: нет операционной нагрузки, time-to-deploy измеряется минутами.

Ограничения реальные: Vercel Serverless Functions запускаются в us-east-1 по умолчанию (latency для Европы +80–100ms), Function timeout 300 секунд на Pro, Bandwidth 1TB/месяц на Pro. Для тяжёлого backend — нужны воркеры или отдельный сервер.

Netlify ближе к статике и Edge Functions на базе Deno Deploy. Build minutes — основное ограничение на бесплатном тарифе.

Почему Docker — основа предсказуемого деплоя?

«Работает на моей машине» — классика. Docker решает это через контейнеризацию окружения. Но плохой Dockerfile создаёт новые проблемы.

Типичная ошибка: копировать всё в образ без .dockerignore, получать 800MB образ вместо 80MB. node_modules внутри образа весит столько же. Правильно: multi-stage build.

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app
COPY --from=builder /app/.next ./.next
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./package.json
EXPOSE 3000
CMD ["npm", "start"]

Итоговый образ: 180MB вместо 1.2GB. Время сборки CI сокращается из-за layer caching — если package.json не изменился, слой с npm ci берётся из кэша.

Docker Compose для локальной разработки и простых продакшен-сценариев: приложение + PostgreSQL + Redis в одной конфигурации. Для production на одном сервере — вполне рабочий вариант, если нет требований горизонтального масштабирования.

Подробнее о контейнеризации — Wikipedia: Docker.

Как настроить Nginx как reverse proxy?

Nginx перед приложением — стандарт для VPS и выделенных серверов. Основные функции: SSL termination, gzip, static files, rate limiting, upstream балансировка.

Конфигурация, которую часто делают неправильно: worker_processes auto — количество процессов равно числу CPU. worker_connections 1024 — это 1024 на каждый воркер-процесс. При 4 CPU и 1024 connections = 4096 одновременных соединений. Для высоконагруженного сайта нужно worker_connections 4096 и настройка keepalive_timeout 65.

Для статических ассетов с хешем в имени файла:

location ~* \.(js|css|woff2|png|webp)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

immutable сообщает браузеру: не проверяй этот файл даже при hard refresh. Правильно работает только с content-hashed именами файлов (что делает Vite/webpack по умолчанию). Документация — Wikipedia: Nginx.

AWS: гибкость и сложность

EC2 + Auto Scaling Group — классика для горизонтального масштабирования. AMI с предустановленным приложением, Launch Template, ASG с min/desired/max instances, Application Load Balancer. При CPU > 70% на 3 минуты — scale out, при CPU < 30% на 15 минут — scale in. Health check через ALB исключает нездоровые инстансы из ротации.

ECS Fargate — контейнеры без управления EC2. Деплой Docker-образа, задаёте CPU/память (512 CPU units = 0.5 vCPU, от 512MB памяти), Fargate запускает. Дороже Lambda, но нет cold start и нет timeout-ограничений. Подходит для long-running процессов, WebSocket-серверов, тяжёлых воркеров.

RDS для PostgreSQL с Multi-AZ: автоматический failover за 1–2 минуты при падении primary. Read Replicas для масштабирования чтения. RDS Proxy для connection pooling — Lambda-функции не умеют держать долгосрочные соединения, прокси буферизует это.

Kubernetes: когда это оправдано

K8s добавляет значительную операционную сложность. Оправдан, когда: несколько команд деплоят независимые сервисы, нужна тонкая настройка ресурсов на сервис, canary deployments и blue/green без простоя — требование.

AWS EKS, GKE или managed k8s от Hetzner (дешевле). Helm charts для стандартных сервисов. Horizontal Pod Autoscaler по CPU и custom metrics (RPS через Prometheus).

Для большинства стартапов и средних проектов — Kubernetes избыточен. ECS или Fly.io дают 80% возможностей при 20% операционной сложности.

Мониторинг и alerting

Сервер без мониторинга — это ожидание инцидента. Минимальный стек: Prometheus + Grafana (или Grafana Cloud для managed), alerting на disk > 80%, memory > 85%, CPU > 90% за 5 минут, error rate > 1%. Uptime через Better Uptime или Upptime (self-hosted).

Logs: Loki + Grafana или CloudWatch Logs Insights. Структурированные JSON-логи (winston, pino) — обязательно, иначе поиск по логам превращается в боль.

Что входит в настройку хостинга

• Аудит текущей инфраструктуры и профилирование нагрузки
• Выбор целевой архитектуры (VPS, AWS, serverless, Kubernetes)
• Настройка CI/CD pipeline (GitHub Actions, GitLab CI) с автоматическим деплоем
• IaC через Terraform или Pulumi (инфраструктура как код)
• Конфигурация Nginx, SSL-сертификаты, HTTP/2, brotli
• Мониторинг и алертинг (Prometheus + Grafana, PagerDuty)
• Документация runbooks и обучение команды

Дополнительно: пишите, если нужна миграция с текущего хостинга или интеграция с внешними сервисами.

Процесс работы

1. Аудит текущей инфраструктуры (2–5 дней)
2. Выбор целевой архитектуры с обоснованием по нагрузке и бюджету (1–3 дня)
3. Настройка CI/CD pipeline (GitHub Actions, GitLab CI) (2–5 дней)
4. IaC через Terraform или Pulumi (3–10 дней)
5. Настройка мониторинга и alerting (2–5 дней)
6. Документация runbooks и обучение команды (1–3 дня)

Наш опыт — 7 лет на рынке, более 50 проектов, гарантия работоспособности после деплоя.

Сроки

• Базовый деплой на VPS с Docker + Nginx + CI/CD: 1–2 недели.
• Настройка AWS инфраструктуры с Auto Scaling, RDS, CDN: 3–6 недель.
• Миграция на EKS с нуля: 6–12 недель.
• Настройка Vercel/Netlify для JAMstack: 3–5 дней.

Стоимость рассчитывается индивидуально в зависимости от сложности и объёма работ. Получите консультацию — оценим вашу архитектуру за один день.