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