Come ottimizzare Nginx Su server Linux – Guida semplificata

Ottimizzare Nginx su un server Linux, sintonizza i processi di lavoro e le connessioni per adattarli CPU e traffico, consentire I/O efficienti (epoll, sendfile), comprimere e memorizzare nella cache le risposte, ottimizzare i protocolli TLS/HTTP e allineare i limiti del sistema operativo (ulimits, sysctl) con Nginx richieste. Convalidare la configurazione, confrontare le modifiche e monitorare le metriche per garantire reali miglioramenti delle prestazioni e stabilità.

In questa guida imparerai esattamente come ottimizzare Nginx su Linux Server—dal nucleo Nginx dalla configurazione all'ottimizzazione del kernel Linux, caching, TLS e monitoraggio. Scritto per amministratori principianti e intermedi, questo manuale passo passo riflette oltre 12 anni di esperienza reale nell'hosting presso YouStable, aiutandoti a ottenere il massimo delle prestazioni, della sicurezza e dell'efficienza da Nginx.

Che cosa significa “ottimizzazione” per Nginx

L'ottimizzazione non è una singola modifica; è un allineamento a livello di stack tra Nginx, la tua applicazione (PHP-FPM, Node.js, Python) e il sistema operativoL'obiettivo è gestire più richieste al secondo con minore latenza e utilizzo delle risorse, senza sacrificare stabilità, sicurezza o manutenibilità.

Pre-volo: conferma la tua linea di base

• Aggiorna a un sistema supportato Nginx build (preferire la versione principale per funzionalità e correzioni).
• Conosci il tuo carico di lavoro: file statici, proxy inverso, PHP-FPM, Node.js o una combinazione di entrambi.
• Vedi CPU nuclei, RAMtipo di disco (SSD/NVMe) e capacità di rete.
• Limiti attuali di verifica: aprire i file, somaxconn, comportamento TIME_WAIT, parametri del kernel.

nginx -V
nginx -t
lscpu
ulimit -n
sysctl net.core.somaxconn net.ipv4.ip_local_port_range

Nucleo Nginx Ottimizzazione delle prestazioni

1) Processi e connessioni dei lavoratori

Impostare i lavoratori in modo che corrispondano alla fisicità CPU core e consentono un numero sufficiente di connessioni per worker per soddisfare la concorrenza di picco. Per la maggior parte dell'utilizzo web, Nginx È basato sugli eventi ed efficiente, con un numero ridotto di processi.

# /etc/nginx/nginx.conf
user  nginx;
worker_processes  auto;
worker_rlimit_nofile  200000;

events {
    use epoll;
    worker_connections  65535;
    multi_accept on;
    # accept_mutex off; # Off for high connection churn, test both
}

Suggerimento: assicurarsi che i limiti dei file aperti di sistema e i limiti delle unità systemd siano superiori a Nginxle esigenze.

# /etc/systemd/system/nginx.service.d/limits.conf
[Service]
LimitNOFILE=200000

2) Buffer, Keep-Alive e Timeout

Buffer di dimensioni adeguate e timeout ragionevoli impediscono il sovraccarico di memoria e il blocco delle connessioni.

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    keepalive_timeout  15;
    keepalive_requests 1000;

    client_header_buffer_size 1k;
    large_client_header_buffers 2 8k;
    client_body_buffer_size 16k;

    client_max_body_size 32m;

    # Timeouts
    client_body_timeout 10s;
    client_header_timeout 10s;
    send_timeout 10s;
}

3) Compressione Gzip o Brotli

La compressione delle risorse di testo consente di risparmiare larghezza di banda e velocizzare la distribuzione. Gzip è ampiamente supportato; Brotli può offrire una compressione migliore per le risorse statiche.

# Gzip (built-in)
gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_types text/plain text/css application/javascript application/json application/xml image/svg+xml;
gzip_vary on;

Per Brotli, installare il modulo e abilitalo come alternativa drop-in o insieme a gzip per i clienti che lo supportano.

4) TLS e HTTP/2 (e HTTP/3 se disponibile)

I protocolli moderni riducono la latenza. Utilizza HTTP/2 per il multiplexing e abilita cifrari robusti con accelerazione hardware. Se la tua build supporta QUIC/HTTP/3, esegui test accurati prima del lancio in produzione.

server {
    listen 443 ssl http2; # add "quic reuseport" if built with HTTP/3
    server_name example.com;

    ssl_certificate /etc/ssl/certs/fullchain.pem;
    ssl_certificate_key /etc/ssl/private/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256';
    ssl_prefer_server_ciphers off;

    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m; # ~400k sessions
    ssl_session_tickets off;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
}

5) Intestazioni di distribuzione e memorizzazione nella cache dei file statici

Servire contenuti statici direttamente da Nginx con intestazioni di cache per ridurre al minimo la rivalidazione e il carico di origine.

location ~* \.(?:css|js|jpg|jpeg|gif|png|svg|ico|webp|woff2?)$ {
    access_log off;
    log_not_found off;
    expires 30d;
    add_header Cache-Control "public, max-age=2592000, immutable";
}

Ottimizzazione della Nginx come proxy inverso

6) Keep-Alive e buffer a monte

Mantenere le connessioni upstream attive per ridurre il sovraccarico dovuto all'handshake. Ottimizzare i buffer per stabilizzare lo streaming delle risposte senza accumulare memoria.

upstream api_backend {
    server 127.0.0.1:3000 max_fails=3 fail_timeout=10s;
    keepalive 64;
}

location /api/ {
    proxy_pass http://api_backend;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;

    proxy_buffers 16 32k;
    proxy_busy_buffers_size 64k;
    proxy_read_timeout 30s;
}

7) PHP-Ottimizzazione di FPM e FastCGI

La maggior parte di WordPress/PHP collo di bottiglia dei siti a PHP-FPM. Utilizzare socket persistenti e microcaching per ridurre l'overhead dinamico.

upstream php {
    server unix:/run/php/php-fpm.sock;
    keepalive 32;
}

fastcgi_cache_path /var/cache/nginx/fastcgi levels=1:2 keys_zone=PHP:100m inactive=60m max_size=2g;
map $request_method $skip_cache { default 0; POST 1; }

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php-fpm.sock;

    fastcgi_read_timeout 30s;
    fastcgi_buffers 16 16k;
    fastcgi_buffer_size 32k;

    # Microcache
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
    fastcgi_cache PHP;
    fastcgi_cache_valid 200 301 302 1m;
    add_header X-Cache $upstream_cache_status;
}

Escludere percorsi personalizzati o sessioni di accesso dalla memorizzazione nella cache per evitare di fornire contenuti privati ​​ad altri.

8) Proxy/Microcaching per API

Il microcaching TTL breve attenua i picchi di traffico per gli endpoint memorizzabili nella cache senza rischi di obsolescenza.

proxy_cache_path /var/cache/nginx/proxy levels=1:2 keys_zone=API:100m inactive=30m max_size=1g;

location /v1/ {
    proxy_cache API;
    proxy_cache_valid 200 10s;
    proxy_cache_use_stale error timeout updating http_502 http_503 http_504;
    add_header X-Cache $upstream_cache_status;
}

Ottimizzazione del kernel Linux e del livello del sistema operativo

Le impostazioni del tuo Linux devono corrispondere NginxModelli di concorrenza e connessione. Queste impostazioni di sysctl sono punti di partenza sicuri: esegui un benchmark e regola in base al tuo carico di lavoro.

# /etc/sysctl.d/99-nginx.conf
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 16384
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_syncookies = 1
fs.file-max = 500000

sysctl --system
echo "* soft nofile 200000" >> /etc/security/limits.conf
echo "* hard nofile 200000" >> /etc/security/limits.conf

Su sistemi multi-core molto attivi, testare il reuseport e l'affinità IRQ per gli interrupt di rete. Eseguire sempre il rollout in modo incrementale.

Registrazione, osservabilità e benchmarking

9) Registri di accesso e buffering

Registrare ogni richiesta statica è costoso. Disattivare per le risorse e memorizzare le scritture nel buffer per i percorsi dinamici.

log_format main '$remote_addr - $remote_user [$time_local] '
                '"$request" $status $body_bytes_sent '
                '"$http_referer" "$http_user_agent" '
                '$request_time $upstream_response_time';

access_log /var/log/nginx/access.log main buffer=128k flush=1s;

10) Metriche e stato

Abilita stub_status o un esportatore per alimentare Prometheus/Grafana. Tieni traccia delle connessioni attive, della frequenza delle richieste, della latenza upstream, del tasso di hit della cache e degli errori.

location /nginx_status {
    stub_status;
    allow 127.0.0.1;
    deny all;
}

11) Benchmark prima e dopo

Utilizzare dimensioni realistiche di concorrenza e payload. Confrontare i percentili di latenza (p50/p95/p99), non solo le medie.

# Example tools
wrk -t4 -c400 -d30s https://example.com/
ab -n 20000 -c 200 https://example.com/

Rafforzamento della sicurezza durante l'ottimizzazione

• Nascondi versione: server_tokens off;
• HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy e una solida Content-Security-Policy.
• Limitare le velocità di richiesta e le connessioni per mitigare gli abusi.

server_tokens off;

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;

location / {
    limit_req zone=req_per_ip burst=20 nodelay;
    limit_conn conn_per_ip 20;
}

Errori comuni da evitare

• Sovra-allocazione di worker_connections senza aumentare i limiti dei file del sistema operativo.
• Lasciare i timeout predefiniti troppo alti, causando una conservazione delle risorse in stile slowloris.
• Abilitazione della memorizzazione nella cache aggressiva per pagine specifiche dell'utente (ad esempio, amministrazione di WordPress, carrello).
• Manca la deprecazione del push del server HTTP/2 e ci si affida ad esso; utilizzare invece i suggerimenti di precaricamento.
• Ignorando i colli di bottiglia a monte (DB, PHP-FPM) e incolpando Nginx.

Esempio di configurazione passo passo

Di seguito è riportata una baseline sicura e ad alte prestazioni che puoi adattare. Convalida sempre con nginx -t e esegui stage prima della produzione.

user nginx;
worker_processes auto;
worker_rlimit_nofile 200000;

events {
    use epoll;
    worker_connections 65535;
    multi_accept on;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    keepalive_timeout 15;
    keepalive_requests 1000;

    # Compression
    gzip on;
    gzip_comp_level 5;
    gzip_min_length 256;
    gzip_types text/plain text/css application/json application/javascript application/xml image/svg+xml;
    gzip_vary on;

    # Logging
    log_format main '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent" '
                    '$request_time $upstream_response_time';
    access_log /var/log/nginx/access.log main buffer=128k flush=1s;
    error_log /var/log/nginx/error.log warn;

    # Caches
    proxy_cache_path /var/cache/nginx/proxy levels=1:2 keys_zone=API:100m inactive=30m max_size=1g;
    fastcgi_cache_path /var/cache/nginx/fastcgi levels=1:2 keys_zone=PHP:100m inactive=60m max_size=2g;

    # Status
    server {
        listen 127.0.0.1:8080;
        location /nginx_status { stub_status; allow 127.0.0.1; deny all; }
    }

    # Site
    server {
        listen 80;
        listen 443 ssl http2;
        server_name example.com;
        root /var/www/html;
        index index.php index.html;

        ssl_certificate /etc/ssl/certs/fullchain.pem;
        ssl_certificate_key /etc/ssl/private/privkey.pem;
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_session_cache shared:SSL:50m;

        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

        location ~* \.(?:css|js|jpg|jpeg|gif|png|svg|ico|webp|woff2?)$ {
            access_log off;
            expires 30d;
            add_header Cache-Control "public, max-age=2592000, immutable";
        }

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

        location ~ \.php$ {
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_pass unix:/run/php/php-fpm.sock;
            fastcgi_read_timeout 30s;
            fastcgi_buffers 16 16k;
            fastcgi_buffer_size 32k;
            fastcgi_cache PHP;
            fastcgi_cache_valid 200 301 302 1m;
            add_header X-Cache $upstream_cache_status;
        }
    }
}

Checklist di convalida e implementazione

• nginx -t supera il test; la configurazione è sotto controllo di versione.
• I limiti di sistema (nofile, somaxconn) superano Nginx richieste.
• Benchmark prima e dopo; monitora la latenza p95, RPS, CPU, memoria.
• Le regole della cache escludono gli endpoint personalizzati o amministrativi.
• Punteggio TLS testato; HTTP/2 abilitato; Brotli/Gzip verificato tramite intestazioni di risposta.
• Registri di accesso memorizzati nel buffer; registri delle risorse disabilitati.
• Piano di rollback pronto; modifiche implementate durante il periodo di traffico ridotto.

Quando scegliere l'hosting gestito

Se preferisci risultati senza tentativi ed errori, considera un managed VPS or server dedicato. A YouStable, i nostri ingegneri pre-calibrano Nginx, PHPFPM e il kernel Linux configurano la cache e l'osservabilità, ottimizzando continuamente il carico di lavoro per garantire prestazioni ottimali con minori rischi e tempi di inattività.

Allineando Nginx configurazione, caching, TLS e parametri del kernel Linux con il tuo carico di lavoro effettivo, e convalidando ogni modifica, puoi ottenere significativi miglioramenti in termini di produttività ed esperienza utente. Se desideri che gli esperti gestiscano questo aspetto end-to-end, YouStable'S manageI server d sono progettati per essere veloci fin dal primo giorno.

FAQ: Come ottimizzare Nginx su server Linux