{"id":21613,"date":"2026-09-21T08:33:31","date_gmt":"2026-09-21T06:33:31","guid":{"rendered":"https:\/\/webhosting.de\/nginx-upstream-keepalive-optimal-konfigurieren-reverse-proxy-netzwerk\/"},"modified":"2026-09-21T08:33:31","modified_gmt":"2026-09-21T06:33:31","slug":"configurazione-ottimale-del-keepalive-upstream-di-nginx-proxy-inverso-rete","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/nginx-upstream-keepalive-optimal-konfigurieren-reverse-proxy-netzwerk\/","title":{"rendered":"Configurare in modo ottimale il keepalive upstream di NGINX per ottenere le massime prestazioni come proxy inverso"},"content":{"rendered":"<p>Configurer\u00f2 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\u00f2 <strong>Dimensioni della piscina<\/strong>, i limiti di tempo e le intestazioni in modo mirato, affinch\u00e9 le connessioni vengano riutilizzate e il percorso dei dati rimanga snello.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<ul>\n  <li><strong>HTTP\/1.1<\/strong> forzare e ripulire gli header di connessione<\/li>\n  <li><strong>keepalive<\/strong> dimensionare correttamente per ogni lavoratore<\/li>\n  <li><strong>Timeout<\/strong> adattare ai valori del backend<\/li>\n  <li><strong>Richieste\/Connessione<\/strong> ridurre e riciclare<\/li>\n  <li><strong>Monitoraggio<\/strong> per la velocit\u00e0 di connessione e la latenza<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-serverkonfiguration-8234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Perch\u00e9 Upstream Keepalive riduce drasticamente lo sforzo di connessione<\/h2>\n\n<p>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; \u00e8 proprio qui che entra in gioco <strong>Keepalive<\/strong> . Faccio in modo che NGINX memorizzi nella cache i socket gi\u00e0 stabiliti e attualmente inattivi, riutilizzandoli per le richieste successive; in questo modo i tempi di connessione si riducono in modo misurabile. Ci\u00f2 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 <strong>affidabile<\/strong> e risponde in modo fluido.<\/p>\n\n<h2>Principio di base e la direttiva keepalive nell'upstream<\/h2>\n\n<p>La direttiva <strong>keepalive<\/strong> Nel blocco `upstream`, si limita il numero di connessioni backend inattive memorizzate temporaneamente per ogni worker. Questo limite non \u00e8 globale, ma si applica rigorosamente a ogni singolo processo worker; per questo motivo tengo sempre sotto controllo il numero di worker. Quando il pool \u00e8 pieno, NGINX chiude per prima la connessione rimasta inattiva pi\u00f9 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 \u201ekeepalive\u201c nell\u2019upstream, cosa che molti amministratori <strong>all'inizio<\/strong> sorpreso.<\/p>\n\n<pre><code>upstream backend_pool {\n    server 192.168.1.10:8080;\n    server 192.168.1.11:8080;\n    server 192.168.1.12:8080;\n\n    keepalive 32; # connessioni inattive per worker\n    keepalive_requests 1000;   # riciclo dopo N richieste\n    keepalive_timeout 60s;     # durata di inattivit\u00e0\n}\n\nserver {\n    listen 80;\n    location \/ {\n proxy_pass http:\/\/backend_pool;\n proxy_http_version 1.1;\n proxy_set_header Connection \"\";\n    }\n}\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx_upstream_keepalive_3471.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Direttive obbligatorie nel blocco \"Location\": HTTP\/1.1 e controllo delle intestazioni<\/h2>\n\n<p>Nel percorso proxy impongo a NGINX l\u2019uso di HTTP\/1.1, poich\u00e9 Keepalive non funziona correttamente con HTTP\/1.0 e le connessioni si interrompono inutilmente; la direttiva <strong>versione_http_proxy<\/strong> 1.1 \u00e8 quindi obbligatorio. Inoltre, rimuovo l\u2019header Connection per le richieste regolari, in modo che il backend non riceva un comando \u201eclose\u201c. Per gli upgrade come i WebSocket, impiego in modo mirato \u201eConnection: Upgrade\u201c tramite map, senza compromettere il normale riutilizzo. In questo modo la politica di connessione rimane coerente e slegata dalle intestazioni del client. \u00c8 proprio questa piccola modifica a prevenire molti problemi difficili da individuare <strong>Immagini di errore<\/strong>.<\/p>\n\n<pre><code>location \/ {\n    proxy_pass http:\/\/backend_pool;\n    proxy_http_version 1.1;\n    proxy_set_header Connection \"\";\n    proxy_set_header Upgrade $http_upgrade;\n    proxy_set_header Connection $connection_upgrade;\n}\n\nmap $http_upgrade $connection_upgrade {\n    default upgrade;\n    \"\" \"\";\n}\n<\/code><\/pre>\n\n<h2>Regolazione fine: scegliere correttamente i valori di keepalive_requests e keepalive_timeout<\/h2>\n\n<p>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 <strong>keepalive_requests<\/strong> e keepalive_timeout. Dopo N richieste, NGINX chiude la connessione in modo mirato e, se necessario, la ristabilisce, attenuando cos\u00ec gli effetti di degrado della rete. Impostiamo il timeout di inattivit\u00e0 su valori piuttosto ridotti, solitamente tra i 30 e i 120 secondi, in modo che i backend non interrompano la connessione prima del tempo. \u00c8 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\u2019argomento trover\u00e0 consigli pratici nell\u2019articolo <a href=\"https:\/\/webhosting.de\/it\/http-keepalive-timeout-configurazione-delle-prestazioni-del-server\/\">Timeout keepalive<\/a>, che illustra i valori tipici e le interazioni.<\/p>\n\n<p>Per facilitare l'orientamento, riporto i valori iniziali pi\u00f9 comuni e la rispettiva funzione in una tabella chiara <strong>Tabella<\/strong>. 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 <strong>Impostazioni predefinite<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametri<\/th>\n      <th>Scopo<\/th>\n      <th>valore indicativo<\/th>\n      <th>Nota sulla messa a punto<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>keepalive<\/td>\n      <td>Dimensione del pool di idle per worker<\/td>\n      <td>32-64<\/td>\n      <td>Allineare al carico simultaneo per worker<\/td>\n    <\/tr>\n    <tr>\n      <td>keepalive_requests<\/td>\n      <td>Richieste massime per connessione<\/td>\n      <td>500\u20131000<\/td>\n      <td>Per gli streaming di lunga durata, impostare un valore leggermente pi\u00f9 alto<\/td>\n    <\/tr>\n    <tr>\n      <td>keepalive_timeout<\/td>\n      <td>Tempo massimo di inattivit\u00e0 per connessione<\/td>\n      <td>Anni '60<\/td>\n      <td>Timeout di inattivit\u00e0 del backend pi\u00f9 breve o uguale<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Determinare le dimensioni della pool in base alle connessioni simultanee<\/h2>\n\n<p>Non scelgo le dimensioni del pool in base alle richieste al secondo, bens\u00ec in base a <strong>Concorrenza<\/strong> 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 \u00e8 un valore iniziale adeguato. In questo modo mantengo disponibili i socket senza tenere aperte troppe connessioni inutili <strong>Connessioni<\/strong> per legare.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-reverse-proxy-setup-5038.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sfruttare consapevolmente le caratteristiche specifiche delle versioni pi\u00f9 recenti di NGINX<\/h2>\n\n<p>Le versioni attuali spesso consentono il riutilizzo per impostazione predefinita, ma applicano limiti piuttosto restrittivi; inserisco comunque i valori <strong>esplicitamente<\/strong> . Ci\u00f2 garantisce la riproducibilit\u00e0, facilita la messa a punto ed evita sorprese dopo un aggiornamento. Tramite il parametro \u201elocal\u201c 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 <strong>Tempo di analisi<\/strong>.<\/p>\n\n<h2>Monitoraggio e metriche: la configurazione \u00e8 davvero efficace?<\/h2>\n\n<p>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 <strong>Riutilizzo<\/strong>. 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\u2019utilizzo della CPU del backend e le latenze con la percentuale di connessioni riutilizzate. Per una comprensione pi\u00f9 approfondita della <a href=\"https:\/\/webhosting.de\/it\/riutilizzo-della-connessione-http-keepalive-ottimizzazione-serverperf-boost\/\">Riutilizzo delle connessioni<\/a> Sono utili gli esempi che mostrano gli effetti in presenza di diversi modelli di carico.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx_keepalive_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Eliminare rapidamente le cause tipiche di errore<\/h2>\n\n<p>Se manca HTTP\/1.1 sul backend, le connessioni hanno una durata breve, indipendentemente da quanto io <strong>keepalive<\/strong> impostare. Se il client invia \u201eConnection: close\u201c e io inoltro l\u2019header senza filtrarlo, il backend chiude ogni connessione subito dopo la risposta. Se i timeout di inattivit\u00e0 non corrispondono, il lato dell\u2019app 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 <strong>Primo<\/strong>, perch\u00e9 spiegano il 90 % di tutti i problemi.<\/p>\n\n<h2>Esempio pratico: configurazione di riferimento per un\u2019elevata produttivit\u00e0<\/h2>\n\n<p>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 \u00e8 dimostrato efficace ed \u00e8 facile da <strong>personalizzare<\/strong>. Impostato il keepalive a 64, limito le richieste per connessione a 1000 e mantengo un tempo di inattivit\u00e0 di 60 secondi. Inoltre, inoltro correttamente le informazioni relative all\u2019host e alle richieste inoltrate, in modo che i backend possano applicare la logica e la limitazione della velocit\u00e0. Questa combinazione riduce il carico sulla CPU, accorcia i tempi di risposta e gestisce i picchi di carico in modo pi\u00f9 fluido. \u00c8 proprio cos\u00ec che ottengo una <strong>Prestazioni<\/strong>.<\/p>\n\n<pre><code>upstream app_backend {\n    server 10.0.1.10:3000 max_fails=2 fail_timeout=30s;\n    server 10.0.1.11:3000 max_fails=2 fail_timeout=30s;\n\n    keepalive 64;\n    keepalive_requests 1000;\n    keepalive_timeout 60s;\n}\n\nserver {\n    listen 80;\n    server_name example.com;\n\n    location \/ {\n proxy_pass http:\/\/app_backend;\n proxy_http_version 1.1;\n proxy_set_header Connection \"\";\n proxy_set_header Host $host;\n        proxy_set_header X-Real-IP $remote_addr;\n        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n proxy_set_header X-Forwarded-Proto $scheme;\n    }\n}\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-keepalive-setup-3294.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ambienti di hosting e aspetti operativi che contano davvero<\/h2>\n\n<p>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\u00f2 garantisce <strong>Pianificabilit\u00e0<\/strong>. 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\u2019allocazione 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 <strong>reattivo<\/strong>.<\/p>\n\n<h2>Le migliori pratiche per le operazioni in corso<\/h2>\n\n<p>Comincio con un keepalive di 32\u201364, 500\u20131000 richieste per connessione e 60 secondi di tempo di inattivit\u00e0, poi effettuo misurazioni sistematiche e adeguo i valori; questo porta a rapidi <strong>successi<\/strong>. Accompagno ogni modifica con metriche relative alla velocit\u00e0 di connessione, alla latenza e ai modelli di errore, finch\u00e9 le curve non si stabilizzano. Adeguo la dimensione del pool in base alle richieste simultanee, non alla velocit\u00e0 di trasmissione lorda al secondo. I timeout non devono mai essere pi\u00f9 lunghi di quelli corrispondenti nello stack di backend, altrimenti si rischia di incorrere in reset sporadici. Chi desidera intervenire in modo pi\u00f9 approfondito sulle impostazioni trover\u00e0 indicazioni per la messa a punto fine all\u2019indirizzo <a href=\"https:\/\/webhosting.de\/it\/ottimizzazione-delle-richieste-keepalive-di-nginx-ottimizzazione-delle-prestazioni-del-server-web\/\">Ottimizzare le richieste keepalive<\/a>, il che rende il riciclaggio facilmente gestibile.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-server-einstellung-7845.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sincronizzazione dei timeout del proxy e del keepalive TCP<\/h2>\n\n<p>Oltre ai parametri relativi esclusivamente al keepalive, regolo con precisione i limiti di tempo di trasporto. La triade costituita da <strong>timeout_connessione_proxy<\/strong>, <strong>proxy_send_timeout<\/strong> e <strong>proxy_read_timeout<\/strong> 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 <strong>proxy_socket_keepalive<\/strong>, in modo che il sistema operativo invii a intervalli regolari segnali di attivit\u00e0 tramite socket inattivi e rilevi le connessioni semiaperte. Ci\u00f2 impedisce che le connessioni inattive rimangano nel pool e causino picchi di latenza alla successiva richiesta.<\/p>\n\n<pre><code>server {\n    listen 80;\n\n    location \/ {\n proxy_pass http:\/\/backend_pool;\n\n proxy_connect_timeout 3s;   # interruzione rapida se non \u00e8 possibile stabilire la connessione\n proxy_send_timeout    30s;  # Scrittura sul backend\n proxy_read_timeout    30s;  # Risposte dal backend\n proxy_socket_keepalive on;  # Attiva il keepalive TCP del sistema operativo\n    }\n}\n<\/code><\/pre>\n\n<p>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.<\/p>\n\n<h2>Pianificazione delle risorse: worker_connections, FD e porte effimere<\/h2>\n\n<p>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 <strong>connessioni_lavoratore<\/strong> e <strong>worker_rlimit_nofile<\/strong> con un margine di sicurezza. A grandi linee, calcolo: FD aperte \u2248 (connessioni client simultanee + connessioni backend simultanee + socket inattive in pool) per ogni worker. Se utilizzo pi\u00f9 upstream con pool, il fabbisogno si moltiplica. Presto inoltre attenzione all\u2019intervallo delle porte effimere del sistema, poich\u00e9 NGINX agisce come client TCP verso il backend e accumula stati TIME_WAIT.<\/p>\n\n<pre><code>worker_processes auto;\nworker_rlimit_nofile 131072;\n\nevents {\n    worker_connections 8192;\n}\n<\/code><\/pre>\n\n<pre><code>Esempi # per Linux (sysctl):\nnet.core.somaxconn = 4096\nnet.ipv4.ip_local_port_range = 10240 65535\nnet.ipv4.tcp_fin_timeout = 15\n<\/code><\/pre>\n\n<p>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.<\/p>\n\n<h2>Zone upstream, strategia di bilanciamento del carico e rotazione DNS<\/h2>\n\n<p>Se ci sono pi\u00f9 worker, condivido lo stato del Balancer tramite un <strong>zona<\/strong>, in modo che i guasti e i pesi rimangano costanti. I socket keepalive rimangono comunque uno per ogni worker, ma la distribuzione diventa pi\u00f9 uniforme. Nel caso di backend dinamici che cambiano indirizzo tramite DNS, imposto \u201e<strong>risolvere<\/strong>\u201c nelle righe del server e definisci un <strong>resolver<\/strong>. Importante: quando gli indirizzi IP ruotano, il pool non ricicla immediatamente tutti i vecchi socket; ritengo quindi che <em>keepalive_requests<\/em> e scadenze realistiche, affinch\u00e9 il rinnovamento abbia effetto in tempi rapidi.<\/p>\n\n<pre><code>upstream backend_pool {\n    zone backend_zone 128k;  # condivide lo stato del bilanciatore\n    least_conn; # distribuzione equa per richieste lunghe\n\n server app-1.internal:8080 resolve;\n    server app-2.internal:8080 resolve;\n\n keepalive 64;\n    keepalive_requests 1000;\n    keepalive_timeout 60s;\n}\n\nresolver 10.0.0.2 valid=30s;\nresolver_timeout 5s;\n\nproxy_next_upstream error timeout http_502 http_504;\nproxy_next_upstream_tries 2;  # poche ripetizioni mirate\n<\/code><\/pre>\n\n<p>Per le sessioni associate a un determinato nodo backend (ad esempio, sticky state), combino il riutilizzo con <em>ip_hash<\/em> o un meccanismo di sessione esterno. Ci\u00f2 impedisce che il pool di connessioni comprometta la coerenza della sessione.<\/p>\n\n<h2>TLS per il backend: SNI, riutilizzo delle sessioni e algoritmi di cifratura<\/h2>\n\n<p>Pi\u00f9 il TLS viene utilizzato nel percorso di backend, pi\u00f9 Keepalive diventa prezioso. Attivo l\u2019SNI, definisco il nome previsto e garantisco il riutilizzo della sessione TLS. Ci\u00f2 riduce i costi dell\u2019handshake 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.<\/p>\n\n<pre><code>upstream https_backend {\n    server backend.example.local:443;\n    keepalive 32;\n}\n\nserver {\n    listen 443 ssl;\n\n location \/ {\n proxy_pass https:\/\/https_backend;\n proxy_http_version 1.1;\n proxy_set_header Connection \"\";\n\n        proxy_ssl_server_name on;\n proxy_ssl_name backend.example.local;\n proxy_ssl_session_reuse on;\n proxy_ssl_protocols TLSv1.2 TLSv1.3;\n        proxy_ssl_ciphers HIGH:!aNULL:!MD5;\n # optional: proxy_ssl_verify on;\n # optional: proxy_ssl_trusted_certificate \/etc\/nginx\/ca.pem;\n    }\n}\n<\/code><\/pre>\n\n<p>Se gestisco personalmente il backend, attivo l\u00ec i ticket di sessione o le cache e verifico tramite le metriche se i tassi di ripresa aumentano. In combinazione con Keepalive, riesco cos\u00ec a ottenere tempi di connessione e di handshake costantemente bassi.<\/p>\n\n<h2>Casi particolari: gRPC, WebSockets e autenticazione legata alla connessione<\/h2>\n\n<p>All'indirizzo <strong>gRPC<\/strong> 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 <strong>WebSocket<\/strong> 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. <strong>NTLM<\/strong> oppure altre autenticazioni legate alla connessione richiedono il \"connection pinning\"; separo tali percorsi in location distinte e l\u00ec riduco il pooling o il riutilizzo, in modo che gli handshake di sicurezza non vengano confusi tra i client.<\/p>\n\n<pre><code>Esempio gRPC #\nlocation \/grpc.Service\/ {\n    grpc_pass grpc:\/\/backend_pool;\n    grpc_read_timeout 300s;  Consenti flussi lunghi #\n}\n<\/code><\/pre>\n\n<p>\u00c8 fondamentale definire una politica di connessione coerente per ogni percorso e utilizzare Keepalive su larga scala solo laddove non sia semanticamente critico.<\/p>\n\n<h2>Misurabilit\u00e0 nella pratica: log di accesso con tempi di upstream<\/h2>\n\n<p>Sto ampliando il log di Access con metriche upstream. In questo modo posso capire a colpo d\u2019occhio 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.<\/p>\n\n<pre><code>log_format upstream_timing '$remote_addr - $host \"$request\" '\n 'up=$upstream_addr '\n 'sc=$status usc=$upstream_status '\n                           'cc=$connection cr=$connection_requests '\n 'tc=$upstream_connect_time '\n 'th=$upstream_header_time '\n 'tr=$upstream_response_time';\n\naccess_log \/var\/log\/nginx\/access_upstream.log upstream_timing;\n<\/code><\/pre>\n\n<p>Inoltre, utilizzo gli endpoint di stato e le statistiche dei socket del sistema operativo. Uno stato ottimale \u00e8 caratterizzato da: un tasso di connessione al backend in calo, un upstream_connect_time pi\u00f9 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.<\/p>\n\n<h2>Strategia di implementazione e messa a punto a basso rischio<\/h2>\n\n<p>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.<\/p>\n\n<pre><code># Convalida le modifiche e ricarica senza tempi di inattivit\u00e0\nnginx -t &amp;&amp; nginx -s reload\n<\/code><\/pre>\n\n<p>Quando gestisco pi\u00f9 flussi a monte, li ottimizzo uno dopo l\u2019altro, partendo dal percorso pi\u00f9 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.<\/p>\n\n<h2>Sintesi concisa per il tuo proxy inverso<\/h2>\n\n<p>Utilizzo HTTP\/1.1, lascio vuoto l\u2019header Connection e scelgo la dimensione del pool in base alle richieste simultanee, non in base all\u2019RPS; questo contribuisce a <strong>Prestazioni<\/strong>. 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 <strong>reattivo<\/strong> e prevedibile.<\/p>","protected":false},"excerpt":{"rendered":"<p>Scopri come configurare in modo ottimale il Keepalive upstream di NGINX nel blocco \"nginx upstream\" per migliorare notevolmente le prestazioni del tuo proxy inverso.<\/p>","protected":false},"author":1,"featured_media":21606,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-21613","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"98","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"NGINX Upstream","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21606","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21613","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=21613"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21613\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/21606"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=21613"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=21613"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=21613"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}