Настройка 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. Свяжитесь с нами для аудита текущей конфигурации.