Налаштування 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. Зв'яжіться з нами для аудиту поточної конфігурації.