Configurare in modo ottimale il keepalive upstream di NGINX per ottenere le massime prestazioni come proxy inverso

Configurerò il Keepalive upstream di NGINX in modo che il reverse proxy stabilisca un numero inferiore di connessioni, garantisca latenze inferiori e gestisca in modo affidabile i picchi di carico. A tal fine, regolerò Dimensioni della piscina, i limiti di tempo e le intestazioni in modo mirato, affinché le connessioni vengano riutilizzate e il percorso dei dati rimanga snello.

Punti centrali

• HTTP/1.1 forzare e ripulire gli header di connessione
• keepalive dimensionare correttamente per ogni lavoratore
• Timeout adattare ai valori del backend
• Richieste/Connessione ridurre e riciclare
• Monitoraggio per la velocità di connessione e la latenza

Perché Upstream Keepalive riduce drasticamente lo sforzo di connessione

Senza il riutilizzo, NGINX apre una nuova connessione al backend per ogni richiesta, il che comporta handshake aggiuntivi, un maggior consumo di cicli CPU e un maggiore utilizzo delle risorse del kernel; è proprio qui che entra in gioco Keepalive . Faccio in modo che NGINX memorizzi nella cache i socket già stabiliti e attualmente inattivi, riutilizzandoli per le richieste successive; in questo modo i tempi di connessione si riducono in modo misurabile. Ciò abbassa la frequenza di connessione al secondo, riduce i picchi di backlog e rallenta i cambi di contesto nel sistema operativo. Soprattutto con TLS verso il backend, risparmio tempo in modo significativo grazie alle sessioni riutilizzate. In questo modo, la catena di risposte rimane stabile anche con un throughput elevato affidabile e risponde in modo fluido.

Principio di base e la direttiva keepalive nell'upstream

La direttiva keepalive Nel blocco `upstream`, si limita il numero di connessioni backend inattive memorizzate temporaneamente per ogni worker. Questo limite non è globale, ma si applica rigorosamente a ogni singolo processo worker; per questo motivo tengo sempre sotto controllo il numero di worker. Quando il pool è pieno, NGINX chiude per prima la connessione rimasta inattiva più a lungo, in modo da fare spazio a nuovi socket. Per il riutilizzo, il lato proxy richiede HTTP/1.1 e un header Connection neutralizzato. Senza questi prerequisiti, il pool rimane vuoto, anche se imposto „keepalive“ nell’upstream, cosa che molti amministratori all'inizio sorpreso.

upstream backend_pool {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;

    keepalive 32; # connessioni inattive per worker
    keepalive_requests 1000;   # riciclo dopo N richieste
    keepalive_timeout 60s;     # durata di inattività
}

server {
    listen 80;
    location / {
 proxy_pass http://backend_pool;
 proxy_http_version 1.1;
 proxy_set_header Connection "";
    }
}

Direttive obbligatorie nel blocco "Location": HTTP/1.1 e controllo delle intestazioni

Nel percorso proxy impongo a NGINX l’uso di HTTP/1.1, poiché Keepalive non funziona correttamente con HTTP/1.0 e le connessioni si interrompono inutilmente; la direttiva versione_http_proxy 1.1 è quindi obbligatorio. Inoltre, rimuovo l’header Connection per le richieste regolari, in modo che il backend non riceva un comando „close“. Per gli upgrade come i WebSocket, impiego in modo mirato „Connection: Upgrade“ tramite map, senza compromettere il normale riutilizzo. In questo modo la politica di connessione rimane coerente e slegata dalle intestazioni del client. È proprio questa piccola modifica a prevenire molti problemi difficili da individuare Immagini di errore.

location / {
    proxy_pass http://backend_pool;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
}

map $http_upgrade $connection_upgrade {
    default upgrade;
    "" "";
}

Regolazione fine: scegliere correttamente i valori di keepalive_requests e keepalive_timeout

Con due viti di regolazione controllo la durata e il rinnovo delle connessioni, in modo che la pool rimanga aggiornata e non ci siano socket abbandonati a creare problemi; si tratta di keepalive_requests e keepalive_timeout. Dopo N richieste, NGINX chiude la connessione in modo mirato e, se necessario, la ristabilisce, attenuando così gli effetti di degrado della rete. Impostiamo il timeout di inattività su valori piuttosto ridotti, solitamente tra i 30 e i 120 secondi, in modo che i backend non interrompano la connessione prima del tempo. È importante trovare il giusto equilibrio: il valore di NGINX non deve mai superare il timeout dei server delle applicazioni, altrimenti si verificheranno numerosi reset della connessione. Chi desidera approfondire l’argomento troverà consigli pratici nell’articolo Timeout keepalive, che illustra i valori tipici e le interazioni.

Per facilitare l'orientamento, riporto i valori iniziali più comuni e la rispettiva funzione in una tabella chiara Tabella. I valori di riferimento fungono da punto di partenza e, dopo il monitoraggio, spesso risultano leggermente superiori o inferiori. Un intervallo troppo breve genera inutili ricreazioni, uno troppo lungo mantiene attive vecchie connessioni. Il numero di richieste per connessione mi protegge dai valori anomali, senza svuotare il pool. Con questi parametri di riferimento ottengo risultati molto rapidi e funzionali Impostazioni predefinite.

Parametri	Scopo	valore indicativo	Nota sulla messa a punto
keepalive	Dimensione del pool di idle per worker	32-64	Allineare al carico simultaneo per worker
keepalive_requests	Richieste massime per connessione	500–1000	Per gli streaming di lunga durata, impostare un valore leggermente più alto
keepalive_timeout	Tempo massimo di inattività per connessione	Anni '60	Timeout di inattività del backend più breve o uguale

Determinare le dimensioni della pool in base alle connessioni simultanee

Non scelgo le dimensioni del pool in base alle richieste al secondo, bensì in base a Concorrenza per worker. Per prima cosa calcolo il numero medio e quello massimo di richieste backend parallele. Successivamente divido questi valori per il numero di worker NGINX e arrotondo per eccesso. Per 200 richieste simultanee con quattro worker, ottengo circa 50 per worker, quindi keepalive 64 è un valore iniziale adeguato. In questo modo mantengo disponibili i socket senza tenere aperte troppe connessioni inutili Connessioni per legare.

Sfruttare consapevolmente le caratteristiche specifiche delle versioni più recenti di NGINX

Le versioni attuali spesso consentono il riutilizzo per impostazione predefinita, ma applicano limiti piuttosto restrittivi; inserisco comunque i valori esplicitamente . Ciò garantisce la riproducibilità, facilita la messa a punto ed evita sorprese dopo un aggiornamento. Tramite il parametro „local“ posso, se lo desidero, limitare il riutilizzo a una singola location, qualora i profili di sicurezza o le politiche relative alle intestazioni differiscano. In questo modo la separazione rimane netta, senza perdere i vantaggi del riutilizzo a livello globale. Con valori chiari documento le intenzioni e risparmio tempo in seguito Tempo di analisi.

Monitoraggio e metriche: la configurazione è davvero efficace?

Per prima cosa verifico il numero di nuove connessioni al backend al secondo; un calo significativo indica che le misure stanno dando i loro frutti Riutilizzo. Poi osservo il parametro `upstream_connect_time`, che si avvicina a zero in caso di corrispondenze nel pool. Gli errori nei log, in particolare i reset delle connessioni, indicano il superamento dei limiti di tempo che stanno alla base dei valori del backend. Inoltre, metto in correlazione l’utilizzo della CPU del backend e le latenze con la percentuale di connessioni riutilizzate. Per una comprensione più approfondita della Riutilizzo delle connessioni Sono utili gli esempi che mostrano gli effetti in presenza di diversi modelli di carico.

Eliminare rapidamente le cause tipiche di errore

Se manca HTTP/1.1 sul backend, le connessioni hanno una durata breve, indipendentemente da quanto io keepalive impostare. Se il client invia „Connection: close“ e io inoltro l’header senza filtrarlo, il backend chiude ogni connessione subito dopo la risposta. Se i timeout di inattività non corrispondono, il lato dell’app interrompe per primo la connessione e NGINX subisce un reset alla richiesta successiva. Un pool sovradimensionato mantiene aperti troppi socket e spreca memoria e porte. In ogni analisi verifico questi quattro punti come Primo, perché spiegano il 90 % di tutti i problemi.

Esempio pratico: configurazione di riferimento per un’elevata produttività

Con poche istruzioni riesco a riportare un proxy fortemente sovraccarico a uno stato di funzionamento veloce e affidabile e a garantire un inoltro corretto delle intestazioni; il modello seguente si è dimostrato efficace ed è facile da personalizzare. Impostato il keepalive a 64, limito le richieste per connessione a 1000 e mantengo un tempo di inattività di 60 secondi. Inoltre, inoltro correttamente le informazioni relative all’host e alle richieste inoltrate, in modo che i backend possano applicare la logica e la limitazione della velocità. Questa combinazione riduce il carico sulla CPU, accorcia i tempi di risposta e gestisce i picchi di carico in modo più fluido. È proprio così che ottengo una Prestazioni.

upstream app_backend {
    server 10.0.1.10:3000 max_fails=2 fail_timeout=30s;
    server 10.0.1.11:3000 max_fails=2 fail_timeout=30s;

    keepalive 64;
    keepalive_requests 1000;
    keepalive_timeout 60s;
}

server {
    listen 80;
    server_name example.com;

    location / {
 proxy_pass http://app_backend;
 proxy_http_version 1.1;
 proxy_set_header Connection "";
 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;
    }
}

Ambienti di hosting e aspetti operativi che contano davvero

Spesso utilizzo NGINX a monte di PHP-FPM, Node.js o servizi Java, assicurandomi che le latenze di rete rimangano basse e che i timeout del backend siano costanti; ciò garantisce Pianificabilità. Una solida configurazione di rete a livello di kernel, con limiti appropriati per i socket, impedisce che un numero elevato di connessioni aperte entri in conflitto. Un’allocazione uniforme della CPU e percorsi di archiviazione veloci aiutano i backend a mantenere tempi di risposta brevi. Inoltre, mi assicuro che le configurazioni siano versionate, in modo che le modifiche rimangano tracciabili. Grazie a questa disciplina, il sistema rimane stabile anche durante i picchi di traffico reattivo.

Le migliori pratiche per le operazioni in corso

Comincio con un keepalive di 32–64, 500–1000 richieste per connessione e 60 secondi di tempo di inattività, poi effettuo misurazioni sistematiche e adeguo i valori; questo porta a rapidi successi. Accompagno ogni modifica con metriche relative alla velocità di connessione, alla latenza e ai modelli di errore, finché le curve non si stabilizzano. Adeguo la dimensione del pool in base alle richieste simultanee, non alla velocità di trasmissione lorda al secondo. I timeout non devono mai essere più lunghi di quelli corrispondenti nello stack di backend, altrimenti si rischia di incorrere in reset sporadici. Chi desidera intervenire in modo più approfondito sulle impostazioni troverà indicazioni per la messa a punto fine all’indirizzo Ottimizzare le richieste keepalive, il che rende il riciclaggio facilmente gestibile.

Sincronizzazione dei timeout del proxy e del keepalive TCP

Oltre ai parametri relativi esclusivamente al keepalive, regolo con precisione i limiti di tempo di trasporto. La triade costituita da timeout_connessione_proxy, proxy_send_timeout e proxy_read_timeout determina il livello di pazienza di NGINX durante la creazione, l'invio e la ricezione dei dati. Non imposto mai questi valori al di sopra di quelli corrispondenti nel backend, ma leggermente al di sotto, in modo che gli errori vengano individuati tempestivamente e non si aggravino a livello dell'applicazione. Inoltre, attivo proxy_socket_keepalive, in modo che il sistema operativo invii a intervalli regolari segnali di attività tramite socket inattivi e rilevi le connessioni semiaperte. Ciò impedisce che le connessioni inattive rimangano nel pool e causino picchi di latenza alla successiva richiesta.

server {
    listen 80;

    location / {
 proxy_pass http://backend_pool;

 proxy_connect_timeout 3s;   # interruzione rapida se non è possibile stabilire la connessione
 proxy_send_timeout    30s;  # Scrittura sul backend
 proxy_read_timeout    30s;  # Risposte dal backend
 proxy_socket_keepalive on;  # Attiva il keepalive TCP del sistema operativo
    }
}

Per gli stream di lunga durata (ad esempio SSE o WebSockets), aumento esclusivamente il timeout di lettura, mentre il timeout di connessione rimane invariato. In questo modo reagisco rapidamente alle destinazioni non funzionanti, ma lascio che le risposte legittime e di lunga durata procedano senza interruzioni.

Pianificazione delle risorse: worker_connections, FD e porte effimere

Un pool Keepalive pulito non serve a nulla se si esauriscono i limiti dei descrittori di file o gli intervalli di porte. Ho quindi intenzione di connessioni_lavoratore e worker_rlimit_nofile con un margine di sicurezza. A grandi linee, calcolo: FD aperte ≈ (connessioni client simultanee + connessioni backend simultanee + socket inattive in pool) per ogni worker. Se utilizzo più upstream con pool, il fabbisogno si moltiplica. Presto inoltre attenzione all’intervallo delle porte effimere del sistema, poiché NGINX agisce come client TCP verso il backend e accumula stati TIME_WAIT.

worker_processes auto;
worker_rlimit_nofile 131072;

events {
    worker_connections 8192;
}

Esempi # per Linux (sysctl):
net.core.somaxconn = 4096
net.ipv4.ip_local_port_range = 10240 65535
net.ipv4.tcp_fin_timeout = 15

Adotto un approccio prudente: non elimino TIME_WAIT in modo aggressivo, ma riduco la frequenza delle connessioni tramite Keepalive. In questo modo i parametri del kernel non diventano critici e il comportamento rimane prevedibile.

Zone upstream, strategia di bilanciamento del carico e rotazione DNS

Se ci sono più worker, condivido lo stato del Balancer tramite un zona, in modo che i guasti e i pesi rimangano costanti. I socket keepalive rimangono comunque uno per ogni worker, ma la distribuzione diventa più uniforme. Nel caso di backend dinamici che cambiano indirizzo tramite DNS, imposto „risolvere“ nelle righe del server e definisci un resolver. Importante: quando gli indirizzi IP ruotano, il pool non ricicla immediatamente tutti i vecchi socket; ritengo quindi che keepalive_requests e scadenze realistiche, affinché il rinnovamento abbia effetto in tempi rapidi.

upstream backend_pool {
    zone backend_zone 128k;  # condivide lo stato del bilanciatore
    least_conn; # distribuzione equa per richieste lunghe

 server app-1.internal:8080 resolve;
    server app-2.internal:8080 resolve;

 keepalive 64;
    keepalive_requests 1000;
    keepalive_timeout 60s;
}

resolver 10.0.0.2 valid=30s;
resolver_timeout 5s;

proxy_next_upstream error timeout http_502 http_504;
proxy_next_upstream_tries 2;  # poche ripetizioni mirate

Per le sessioni associate a un determinato nodo backend (ad esempio, sticky state), combino il riutilizzo con ip_hash o un meccanismo di sessione esterno. Ciò impedisce che il pool di connessioni comprometta la coerenza della sessione.

TLS per il backend: SNI, riutilizzo delle sessioni e algoritmi di cifratura

Più il TLS viene utilizzato nel percorso di backend, più Keepalive diventa prezioso. Attivo l’SNI, definisco il nome previsto e garantisco il riutilizzo della sessione TLS. Ciò riduce i costi dell’handshake e attenua i picchi di latenza. Scelgo con attenzione le suite di cifratura e i protocolli, senza escludere i backend meno recenti. Durante la verifica del certificato (opzionale), la catena di fiducia deve essere completa, altrimenti le connessioni si interrompono sporadicamente.

upstream https_backend {
    server backend.example.local:443;
    keepalive 32;
}

server {
    listen 443 ssl;

 location / {
 proxy_pass https://https_backend;
 proxy_http_version 1.1;
 proxy_set_header Connection "";

        proxy_ssl_server_name on;
 proxy_ssl_name backend.example.local;
 proxy_ssl_session_reuse on;
 proxy_ssl_protocols TLSv1.2 TLSv1.3;
        proxy_ssl_ciphers HIGH:!aNULL:!MD5;
 # optional: proxy_ssl_verify on;
 # optional: proxy_ssl_trusted_certificate /etc/nginx/ca.pem;
    }
}

Se gestisco personalmente il backend, attivo lì i ticket di sessione o le cache e verifico tramite le metriche se i tassi di ripresa aumentano. In combinazione con Keepalive, riesco così a ottenere tempi di connessione e di handshake costantemente bassi.

Casi particolari: gRPC, WebSockets e autenticazione legata alla connessione

All'indirizzo gRPC NGINX opera a monte tramite HTTP/2. In questo caso, poche connessioni di lunga durata con molti flussi spesso garantiscono i risultati migliori; il pool rimane piccolo ma stabile. Per WebSocket Imposto timeout di lettura lunghi e mantengo la logica delle intestazioni della soluzione "map", in modo che le connessioni di aggiornamento non vengano chiuse accidentalmente. NTLM oppure altre autenticazioni legate alla connessione richiedono il "connection pinning"; separo tali percorsi in location distinte e lì riduco il pooling o il riutilizzo, in modo che gli handshake di sicurezza non vengano confusi tra i client.

Esempio gRPC #
location /grpc.Service/ {
    grpc_pass grpc://backend_pool;
    grpc_read_timeout 300s;  Consenti flussi lunghi #
}

È fondamentale definire una politica di connessione coerente per ogni percorso e utilizzare Keepalive su larga scala solo laddove non sia semanticamente critico.

Misurabilità nella pratica: log di accesso con tempi di upstream

Sto ampliando il log di Access con metriche upstream. In questo modo posso capire a colpo d’occhio se una risposta proviene da un socket in pool (tempo di connessione molto breve) e con quale frequenza si verificano errori nel backend. Inoltre, registro il numero di connessione e il numero di richieste effettuate tramite la connessione client corrente, al fine di individuare eventuali correlazioni.

log_format upstream_timing '$remote_addr - $host "$request" '
 'up=$upstream_addr '
 'sc=$status usc=$upstream_status '
                           'cc=$connection cr=$connection_requests '
 'tc=$upstream_connect_time '
 'th=$upstream_header_time '
 'tr=$upstream_response_time';

access_log /var/log/nginx/access_upstream.log upstream_timing;

Inoltre, utilizzo gli endpoint di stato e le statistiche dei socket del sistema operativo. Uno stato ottimale è caratterizzato da: un tasso di connessione al backend in calo, un upstream_connect_time più breve, tempi di risposta stabili e quasi nessun reset della connessione. Eventuali anomalie indicano quasi sempre limiti di tempo non adeguati o pool troppo piccoli o troppo grandi.

Strategia di implementazione e messa a punto a basso rischio

Procedo in modo iterativo: piccoli passi, misurazione, adeguamento. Per prima cosa attivo il keepalive in modo moderato, poi regolo i timeout e il numero di richieste per connessione. Applico le modifiche ricaricando la pagina, senza interrompere le connessioni attive. In questo modo il rischio rimane basso e gli effetti sono facilmente attribuibili.

# Convalida le modifiche e ricarica senza tempi di inattività
nginx -t && nginx -s reload

Quando gestisco più flussi a monte, li ottimizzo uno dopo l’altro, partendo dal percorso più critico. A ogni livello assegno una finestra di osservazione, in modo che emergano chiaramente gli andamenti nelle metriche. Solo dopo procedo ad aumentare o diminuire i valori.

Sintesi concisa per il tuo proxy inverso

Utilizzo HTTP/1.1, lascio vuoto l’header Connection e scelgo la dimensione del pool in base alle richieste simultanee, non in base all’RPS; questo contribuisce a Prestazioni. Con keepalive_requests e keepalive_timeout mantengo attive le connessioni ed evito sorprese dovute a socket obsoleti. Il monitoraggio mostra se upstream_connect_time tende a zero e se la frequenza delle connessioni al backend diminuisce. In caso di errori, controllo innanzitutto la versione del protocollo, il passaggio delle intestazioni, i timeout e la dimensione del pool. In questo modo il tuo proxy NGINX rimane stabile anche sotto carico elevato reattivo e prevedibile.