Zaawansowany Nginx na Debianie 13: HTTP/2, PHP-FPM, Redis, Memcached i rate limiting

Co konfigurujemy

Punktem wyjścia jest działający stack z poprzedniego wpisu: Nginx, PHP-FPM i MariaDB na Debianie 13. Tutaj idziemy dalej — dokładamy HTTP/2, dwie warstwy cache (Redis i Memcached) oraz mechanizmy ograniczania ruchu. Architektura wygląda tak:

W tym stacku to aplikacja PHP korzysta z Redisa, Memcached i MariaDB — Nginx łączy się wyłącznie z PHP-FPM (przez FastCGI) i nie rozmawia ani z bazą, ani z cache. Redis i Memcached odciążają bazę danych, trzymając w pamięci RAM to, co inaczej trzeba by liczyć przy każdym żądaniu.

Czy Nginx mógłby sięgać do cache sam? Dla Memcached — tak, ma wbudowany moduł ngx_http_memcached_module (bez dodatkowych pakietów), więc potrafi serwować zbuforowane odpowiedzi z pominięciem PHP. To jednak opcja zaawansowana; w typowym WordPressie cache obsługuje warstwa PHP. Dla Redisa rdzeń Nginx nie ma modułu, a my świadomie nie sięgamy po moduły zewnętrzne (np. z nginx-extras) — Redisem zarządza aplikacja.

HTTP/2

HTTP/2 to nowsza wersja protokołu HTTP. Zamiast otwierać wiele połączeń TCP, multipleksuje wiele żądań i odpowiedzi w jednym połączeniu, kompresuje nagłówki (HPACK) i ogranicza narzut. Na Debianie 13 (Nginx 1.26+) włączamy go osobną dyrektywą http2 on; — flaga przy listen jest już przestarzała:

server {
    listen 443 ssl;
    http2 on;                # od Nginx 1.25.1 — osobna dyrektywa
    server_name example.com;
    # ... TLS, root, location ...
}

PHP-FPM

Nginx nie wykonuje PHP samodzielnie — przekazuje żądania do PHP-FPM (FastCGI Process Manager) przez gniazdo uniksowe. Kluczowa dobra praktyka to osobna pula (pool) dla każdej strony, z własnym użytkownikiem i własnym gniazdem:

; /etc/php/8.4/fpm/pool.d/example.conf
[example]
user = example_web
group = example_web
; gniazdo tej puli — Nginx (www-data) musi mieć do niego dostęp
listen = /run/php/example.sock
listen.owner = www-data
listen.group = www-data
; przy pm = dynamic wymagane są też trzy parametry pm.*_servers
pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
; twardy hardening na poziomie puli
php_admin_value[open_basedir] = /var/www/example.com:/tmp
php_admin_value[disable_functions] = exec,passthru,shell_exec,system,proc_open,popen

Redis

Redis to szybki magazyn danych w pamięci RAM. W tym stacku używamy go z poziomu aplikacji do dwóch rzeczy: jako cache obiektów (np. wyniki kosztownych zapytań do MariaDB) i jako magazyn sesji PHP współdzielony między procesami:

; /etc/php/8.4/fpm/pool.d/example.conf — sesje PHP w Redis
; wymaga rozszerzenia: apt install php8.4-redis
php_value[session.save_handler] = redis
php_value[session.save_path]    = "unix:///run/redis/redis.sock?persistent=1"
; gdy Redis ma requirepass, dodaj do save_path parametr auth, np. &auth=twoje_haslo

W odróżnieniu od Memcached, Nginx nie łączy się z Redisem — jego rdzeń nie ma takiego modułu, a my świadomie nie instalujemy modułów zewnętrznych (np. z nginx-extras). Redis pozostaje domeną aplikacji: to ona zapisuje i odczytuje cache obiektów oraz sesje. Dzięki temu konfiguracja Nginx jest prostsza, a stos lżejszy w utrzymaniu.

Memcached

Memcached to prosty, wielowątkowy cache klucz–wartość, również trzymany w RAM. Stawiamy go obok Redisa do tego, w czym jest najlepszy: ulotnego cache fragmentów i wyników, gdzie nie potrzebujemy trwałości ani złożonych typów danych.

# /etc/memcached.conf
-m 256                  # limit pamięci (MB)
-l 127.0.0.1            # tylko localhost
-U 0                    # wyłącz nasłuch UDP

Memcached ma jeszcze jedno, opcjonalne zastosowanie specyficzne dla Nginx. Dzięki modułowi ngx_http_memcached_module — który jest częścią standardowego Nginx (nie wymaga pakietów typu nginx-extras) — Nginx potrafi serwować odpowiedzi bezpośrednio z Memcached, w ogóle nie uruchamiając PHP, pod warunkiem że właściwy klucz wcześniej umieściła tam aplikacja (moduł działa tylko do odczytu):

location / {
    set $memcached_key "$uri";
    memcached_pass 127.0.0.1:11211;     # spróbuj podać z Memcached...
    error_page 404 502 504 = @app;      # ...a w razie pudła oddaj do PHP
}

location @app {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/example.sock;
}

To jeden z niewielu przypadków, gdy Nginx „rozmawia" z warstwą cache samodzielnie. W typowym WordPressie i tak zwykle cache obsługuje wtyczka po stronie PHP, ale dla własnych aplikacji potrafi to dać zauważalny zysk — najszybsze żądanie to takie, które nigdy nie dotarło do PHP.

Ograniczanie żądań — ngx_http_limit_req

Moduł ngx_http_limit_req (wbudowany w Nginx) ogranicza tempo żądań według wybranego klucza — zwykle adresu IP. Działa w oparciu o algorytm „cieknącego wiadra" (leaky bucket): definiujemy strefę i dozwoloną częstotliwość, a Nginx wygładza nadmiarowy ruch. Strefę deklarujemy w kontekście http, a stosujemy w server/location:

# kontekst http { } — definicja strefy
limit_req_zone $binary_remote_addr zone=req_per_ip:10m rate=10r/s;

# w location, np. logowanie do WordPressa
location = /wp-login.php {
    limit_req zone=req_per_ip burst=20 nodelay;
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/example.sock;
}

Ograniczanie połączeń — ngx_http_limit_conn

Bliźniaczy moduł ngx_http_limit_conn ogranicza liczbę jednoczesnych połączeń z jednego klucza (IP). Tam, gdzie limit_req patrzy na tempo, limit_conn patrzy na równoległość:

# kontekst http { }
limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;

# w server { } lub location { }
limit_conn conn_per_ip 10;     # maks. 10 równoczesnych połączeń z jednego IP

Bezpieczeństwo przekrojowo

Poza punktowymi uwagami przy każdym komponencie, na poziomie całego serwera pilnujemy kilku stałych zasad:

• Ukryj wersję — server_tokens off; nie zdradza numeru Nginx (mniej podpowiedzi dla skanerów).
• Nagłówki bezpieczeństwa — Strict-Transport-Security (HSTS), X-Content-Type-Options: nosniff, X-Frame-Options, Referrer-Policy.
• Blokuj pliki ukryte i wrażliwe — odmowa dostępu do .git, .env, kopii zapasowych.
• Cache i bazy tylko na localhost — Redis, Memcached i MariaDB nie wychodzą poza 127.0.0.1.

server_tokens off;
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;

location ~ /\.(?!well-known) { deny all; }   # blokuj .git, .env itp.

Pełny przykład konfiguracji

Wszystko razem — strefy limitów w kontekście http, a poniżej kompletny serwer wirtualny z HTTP/2, FastCGI do PHP-FPM, nagłówkami i ograniczeniami ruchu:

# /etc/nginx/conf.d/limits.conf  (kontekst http)
limit_req_zone  $binary_remote_addr zone=req_per_ip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;

# /etc/nginx/sites-available/example.com
server {
    listen 443 ssl;
    http2 on;
    server_name example.com www.example.com;
    root /var/www/example.com;
    index index.php;

    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;

    server_tokens off;
    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;

    limit_conn conn_per_ip 10;          # globalnie dla tego serwera

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

    location = /wp-login.php {
        limit_req zone=req_per_ip burst=20 nodelay;   # ochrona logowania
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/example.sock;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/example.sock;       # pula PHP-FPM strony
    }

    location ~ /\.(?!well-known) { deny all; }
}

# Przekierowanie HTTP -> HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Po każdej zmianie testujemy składnię i przeładowujemy usługę:

nginx -t && systemctl reload nginx

Jak robimy to w LinuxLab

Taka konfiguracja nie powstaje ręcznie przy każdym wdrożeniu — mamy ją opisaną w rolach Ansible (strefy limitów, pule PHP-FPM, hardening Redisa i Memcached), a infrastrukturę pod nią powołujemy Terraformem. Dzięki temu każdy serwer dostaje identyczny, przetestowany zestaw zabezpieczeń i optymalizacji. Połączenie wydajności (HTTP/2, cache) z kontrolą ruchu (limit_req, limit_conn) to realne zapobieganie awariom: serwer pozostaje szybki pod normalnym obciążeniem i odporny, gdy ruch staje się złośliwy.

Podsumowanie

Wydajny Nginx to suma świadomych decyzji: HTTP/2 skraca czas ładowania, PHP-FPM z osobnymi pulami daje izolację i kontrolę zasobów, Redis i Memcached odciążają bazę, a limit_req i limit_conn chronią serwer przed nadużyciami. Przy każdym z tych elementów warto zadać dwa pytania: po co go tak używam i jak go zabezpieczam — odpowiedzi na nie odróżniają konfigurację „działającą" od konfiguracji produkcyjnej.