{"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":"konfigurera-nginx-upstream-keepalive-optimalt-omvaend-proxy-i-naetverket","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/nginx-upstream-keepalive-optimal-konfigurieren-reverse-proxy-netzwerk\/","title":{"rendered":"Optimera inst\u00e4llningarna f\u00f6r NGINX Upstream Keepalive f\u00f6r maximal prestanda som omv\u00e4nd proxy"},"content":{"rendered":"<p>Jag konfigurerar NGINX Upstream Keepalive s\u00e5 att den omv\u00e4nda proxyn uppr\u00e4ttar f\u00e4rre anslutningar, ger l\u00e4gre latens och p\u00e5 ett tillf\u00f6rlitligt s\u00e4tt hanterar belastningstoppar. I samband med detta justerar jag <strong>Poolens storlek<\/strong>, tidsgr\u00e4nser och rubriker p\u00e5 ett m\u00e5linriktat s\u00e4tt s\u00e5 att anslutningar \u00e5teranv\u00e4nds och datav\u00e4gen f\u00f6rblir slimmad.<\/p>\n\n<h2>Centrala punkter<\/h2>\n\n<ul>\n  <li><strong>HTTP\/1.1<\/strong> tvinga fram och rensa Connection-rubriker<\/li>\n  <li><strong>keepalive<\/strong> dimensionera korrekt per arbetare<\/li>\n  <li><strong>Tidsfrister<\/strong> anpassa till backend-v\u00e4rden<\/li>\n  <li><strong>F\u00f6rfr\u00e5gningar\/Anslutning<\/strong> begr\u00e4nsa och \u00e5tervinna<\/li>\n  <li><strong>\u00d6vervakning<\/strong> f\u00f6r anslutningshastighet och f\u00f6rdr\u00f6jning<\/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>Varf\u00f6r Upstream Keepalive drastiskt minskar anslutningsarbetet<\/h2>\n\n<p>Utan \u00e5teranv\u00e4ndning \u00f6ppnar NGINX en ny backend-anslutning f\u00f6r varje beg\u00e4ran, vilket medf\u00f6r extra handskakningar, fler CPU-cykler och ytterligare k\u00e4rnresurser; det \u00e4r just h\u00e4r som <strong>Keepalive<\/strong> Jag l\u00e5ter NGINX cacha redan uppr\u00e4ttade, tillf\u00e4lligt inaktiva socklar och anv\u00e4nda dem f\u00f6r efterf\u00f6ljande f\u00f6rfr\u00e5gningar, vilket m\u00e4rkbart minskar anslutningstiderna. Detta s\u00e4nker antalet anslutningar per sekund, minskar toppar i backloggen och bromsar kontextbyten i operativsystemet. S\u00e4rskilt vid TLS-anslutningar till backend sparar jag m\u00e4rkbart tid genom \u00e5teranv\u00e4nda sessioner. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir svarskedjan stabil \u00e4ven vid h\u00f6g genomstr\u00f6mning <strong>p\u00e5litlig<\/strong> och reagerar smidigt.<\/p>\n\n<h2>Grundprincipen och keepalive-direktivet i Upstream<\/h2>\n\n<p>Direktivet <strong>keepalive<\/strong> I upstream-blocket begr\u00e4nsas antalet inaktiva backend-anslutningar som cachelagras per arbetare. Denna gr\u00e4ns g\u00e4ller inte globalt, utan strikt per arbetarprocess, vilket \u00e4r anledningen till att jag alltid h\u00e5ller koll p\u00e5 antalet arbetare. N\u00e4r poolen \u00e4r full st\u00e4nger NGINX f\u00f6rst den anslutning som varit oanv\u00e4nd l\u00e4ngst, s\u00e5 att det finns plats f\u00f6r nya socklar. F\u00f6r \u00e5teranv\u00e4ndning kr\u00e4ver proxysidan HTTP\/1.1 och en neutraliserad Connection-header. Utan dessa f\u00f6ruts\u00e4ttningar f\u00f6rblir poolen tom, trots att jag st\u00e4ller in \u201ekeepalive\u201c i uppstr\u00f6msinst\u00e4llningarna, vilket m\u00e5nga administrat\u00f6rer <strong>inledningsvis<\/strong> \u00f6verraskad.<\/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; # inaktiva anslutningar per arbetare\n    keepalive_requests 1000;   # \u00e5teranv\u00e4ndning efter N f\u00f6rfr\u00e5gningar\n    keepalive_timeout 60s;     # livsl\u00e4ngd f\u00f6r inaktiva anslutningar\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>Obligatoriska direktiv i Location-blocket: HTTP\/1.1 och kontroll av rubriker<\/h2>\n\n<p>Jag tvingar NGINX att anv\u00e4nda HTTP\/1.1 i proxys\u00f6kv\u00e4gen, eftersom Keepalive inte fungerar korrekt med HTTP\/1.0 och anslutningarna avslutas i on\u00f6dan; direktiven <strong>proxy_http_version<\/strong> 1.1 \u00e4r d\u00e4rf\u00f6r obligatoriskt. Dessutom tar jag bort Connection-headern f\u00f6r vanliga f\u00f6rfr\u00e5gningar, s\u00e5 att backenden inte f\u00e5r n\u00e5gon \u201eclose\u201c-instruktion. F\u00f6r uppgraderingar som WebSockets anger jag specifikt \u201eConnection: Upgrade\u201c via map, utan att det p\u00e5verkar den normala \u00e5teranv\u00e4ndningen. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir anslutningspolicyn konsekvent och frist\u00e5ende fr\u00e5n klienthuvuden. Just denna lilla \u00e4ndring f\u00f6rhindrar m\u00e5nga sv\u00e5rf\u00e5ngade <strong>Felbilder<\/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>Finjustering: V\u00e4lj r\u00e4tt v\u00e4rden f\u00f6r keepalive_requests och keepalive_timeout<\/h2>\n\n<p>Med tv\u00e5 justeringsskruvar reglerar jag livsl\u00e4ngden och f\u00f6rnyelsen av anslutningarna, s\u00e5 att poolen f\u00f6rblir fr\u00e4sch och inga \u00f6vergivna uttag st\u00f6r; det \u00e4r <strong>keepalive_requests<\/strong> och keepalive_timeout. Efter N f\u00f6rfr\u00e5gningar st\u00e4nger NGINX av anslutningen medvetet och \u00e5teruppr\u00e4ttar den vid behov, vilket d\u00e4mpar effekterna av n\u00e4tverksf\u00f6rdr\u00f6jningar. Jag st\u00e4ller in idle-timeouten ganska kort, oftast mellan 30 och 120 sekunder, s\u00e5 att backend-servrarna inte bryter anslutningen i f\u00f6rtid. Det \u00e4r viktigt att st\u00e4lla in v\u00e4rdena r\u00e4tt: NGINX-v\u00e4rdet f\u00e5r aldrig \u00f6verstiga app-serverns timeout, annars blir det m\u00e5nga \u00e5teruppkopplingar. Den som vill f\u00f6rdjupa sig i bakgrunden hittar praktiska tips i artikeln <a href=\"https:\/\/webhosting.de\/sv\/http-keepalive-timeout-konfiguration-av-serverprestanda\/\">Keepalive-timeout<\/a>, som f\u00f6rklarar typiska v\u00e4rden och v\u00e4xelverkan.<\/p>\n\n<p>F\u00f6r att underl\u00e4tta orienteringen visar jag vanliga startv\u00e4rden och deras respektive syfte i en \u00f6versk\u00e5dlig <strong>Tabell<\/strong>. Riktv\u00e4rdena fungerar som utg\u00e5ngspunkt och hamnar ofta n\u00e5got h\u00f6gre eller l\u00e4gre efter \u00f6vervakning. En f\u00f6r kort tidsperiod leder till on\u00f6diga \u00e5teruppbyggnader, medan en f\u00f6r l\u00e5ng tidsperiod h\u00e5ller kvar gamla anslutningar. Antalet f\u00f6rfr\u00e5gningar per anslutning skyddar mot extremv\u00e4rden utan att t\u00f6mma poolen. Med dessa nyckeltal kan jag mycket snabbt f\u00e5 fram fungerande <strong>Standardinst\u00e4llningar<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametrar<\/th>\n      <th>Syfte<\/th>\n      <th>riktv\u00e4rde<\/th>\n      <th>Tips om tuning<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>keepalive<\/td>\n      <td>Storleken p\u00e5 idle-poolen per arbetare<\/td>\n      <td>32-64<\/td>\n      <td>Anpassa efter den samtidiga belastningen per arbetare<\/td>\n    <\/tr>\n    <tr>\n      <td>keepalive_requests<\/td>\n      <td>Max. antal f\u00f6rfr\u00e5gningar per anslutning<\/td>\n      <td>500\u20131000<\/td>\n      <td>Vid l\u00e5nga s\u00e4ndningar b\u00f6r man s\u00e4tta gr\u00e4nsen n\u00e5got h\u00f6gre<\/td>\n    <\/tr>\n    <tr>\n      <td>keepalive_timeout<\/td>\n      <td>Maximal inaktivitetstid per anslutning<\/td>\n      <td>60-talet<\/td>\n      <td>Kortare eller samma tidsgr\u00e4ns f\u00f6r inaktivitet i backend<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Best\u00e4mma poolstorlek utifr\u00e5n antalet samtidiga anslutningar<\/h2>\n\n<p>Jag v\u00e4ljer poolstorleken inte utifr\u00e5n antalet f\u00f6rfr\u00e5gningar per sekund, utan utifr\u00e5n <strong>Samtidighet<\/strong> per arbetare. F\u00f6rst ber\u00e4knar jag det genomsnittliga och det maximala antalet parallella backend-f\u00f6rfr\u00e5gningar. D\u00e4refter delar jag dessa siffror med antalet NGINX-arbetare och avrundar upp\u00e5t. F\u00f6r 200 samtidiga f\u00f6rfr\u00e5gningar med fyra arbetare blir det cirka 50 per arbetare, vilket inneb\u00e4r att keepalive 64 passar som startv\u00e4rde. P\u00e5 s\u00e5 s\u00e4tt h\u00e5ller jag socklarna tillg\u00e4ngliga utan att ha on\u00f6digt m\u00e5nga \u00f6ppna <strong>Anslutningar<\/strong> f\u00f6r att binda.<\/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>Att medvetet utnyttja s\u00e4rdragen i nyare versioner av NGINX<\/h2>\n\n<p>I de senaste versionerna \u00e4r \u00e5teranv\u00e4ndning ofta till\u00e5ten som standard, men gr\u00e4nserna \u00e4r ganska konservativa; jag anger \u00e4nd\u00e5 v\u00e4rdena <strong>explicit<\/strong> . Detta s\u00e4kerst\u00e4ller reproducerbarhet, underl\u00e4ttar finjusteringen och f\u00f6rhindrar \u00f6verraskningar efter en uppdatering. Med parametern \u201elocal\u201c kan jag valfritt begr\u00e4nsa \u00e5teranv\u00e4ndningen till en viss plats om s\u00e4kerhetsprofiler eller header-policyer skiljer sig \u00e5t. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir \u00e5tskillnaden tydlig utan att man globalt g\u00e5r miste om f\u00f6rdelarna med \u00e5teranv\u00e4ndning. Med tydliga v\u00e4rden dokumenterar jag avsikter och sparar tid senare <strong>Analystid<\/strong>.<\/p>\n\n<h2>\u00d6vervakning och m\u00e4tv\u00e4rden: Fungerar konfigurationen verkligen?<\/h2>\n\n<p>Jag kontrollerar f\u00f6rst antalet nya backend-anslutningar per sekund; en tydlig minskning visar att \u00e5tg\u00e4rderna har gett resultat <strong>\u00c5teranv\u00e4ndning<\/strong>. Sedan tittar jag p\u00e5 upstream_connect_time, som ligger n\u00e4ra noll vid tr\u00e4ffar i poolen. Fel i loggarna, s\u00e4rskilt \u00e5teranslutningar, tyder p\u00e5 tidsgr\u00e4nser som ligger bakom backend-v\u00e4rdena. Dessutom korrelerar jag backend-CPU och latenser med andelen \u00e5teranv\u00e4nda anslutningar. F\u00f6r en djupare f\u00f6rst\u00e5else av <a href=\"https:\/\/webhosting.de\/sv\/http-anslutning-ateranvaendning-keepalive-optimering-serverperf-boost\/\">\u00c5teranv\u00e4ndning av anslutningar<\/a> Exempel som visar effekterna vid olika belastningsm\u00f6nster \u00e4r till hj\u00e4lp.<\/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>Snabbt \u00e5tg\u00e4rda vanliga felk\u00e4llor<\/h2>\n\n<p>Om HTTP\/1.1 saknas till backend blir anslutningarna kortlivade, oavsett hur h\u00f6gt jag <strong>keepalive<\/strong> st\u00e4ller in. Om klienten skickar \u201eConnection: close\u201c och jag vidarebefordrar rubriken ofiltrerad, st\u00e4nger backenden varje anslutning direkt efter svaret. Om tidsgr\u00e4nserna f\u00f6r inaktivitet inte st\u00e4mmer \u00f6verens avslutar appen anslutningen f\u00f6rst och NGINX f\u00e5r en \u00e5terst\u00e4llning vid n\u00e4sta beg\u00e4ran. En \u00f6verdimensionerad pool h\u00e5ller f\u00f6r m\u00e5nga socklar \u00f6ppna och sl\u00f6sar bort minne och portar. Jag kontrollerar dessa fyra punkter vid varje analys som <strong>F\u00f6rst<\/strong>, eftersom de f\u00f6rklarar 90 % av alla problem.<\/p>\n\n<h2>Praktiskt exempel: Referenskonfiguration f\u00f6r h\u00f6g genomstr\u00f6mning<\/h2>\n\n<p>Med n\u00e5gra f\u00e5 anvisningar f\u00e5r jag en kraftigt belastad proxy att fungera snabbt och p\u00e5litligt och s\u00e4kerst\u00e4ller en korrekt vidarebefordran av rubriker; f\u00f6ljande modell har visat sig fungera v\u00e4l och \u00e4r l\u00e4tt att <strong>anpassa<\/strong>. Jag st\u00e4ller in keepalive p\u00e5 64, begr\u00e4nsar antalet f\u00f6rfr\u00e5gningar per anslutning till 1 000 och har en inaktivitetstid p\u00e5 60 sekunder. Dessutom vidarebefordrar jag v\u00e4rd- och vidarebefordringsinformation korrekt s\u00e5 att backend-systemen kan till\u00e4mpa logik och hastighetsbegr\u00e4nsning. Denna kombination skonar CPU:n, f\u00f6rkortar svarstiderna och hanterar belastningstoppar p\u00e5 ett mer smidigt s\u00e4tt. Det \u00e4r precis s\u00e5 jag uppn\u00e5r en v\u00e4l ber\u00e4knbar <strong>Prestanda<\/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>Webbhotellsmilj\u00f6er och driftsaspekter som verkligen spelar roll<\/h2>\n\n<p>Jag placerar ofta NGINX framf\u00f6r PHP-FPM-, Node.js- eller Java-tj\u00e4nster och ser till att n\u00e4tverksf\u00f6rdr\u00f6jningarna h\u00e5lls l\u00e5ga och att tidsgr\u00e4nserna i backend \u00e4r konsekventa; detta ger <strong>Planerbarhet<\/strong>. En stabil n\u00e4tverkskonfiguration i k\u00e4rnan med l\u00e4mpliga socket-gr\u00e4nser f\u00f6rhindrar att ett stort antal \u00f6ppna anslutningar kolliderar. En j\u00e4mn CPU-f\u00f6rdelning och snabba lagringsv\u00e4gar hj\u00e4lper backend-servrarna att uppr\u00e4tth\u00e5lla korta svarstider. Dessutom ser jag till att konfigurationerna versioneras s\u00e5 att \u00e4ndringar f\u00f6rblir sp\u00e5rbara. Med denna disciplin klarar systemet \u00e4ven trafiktoppar <strong>reagerbar<\/strong>.<\/p>\n\n<h2>B\u00e4sta praxis f\u00f6r l\u00f6pande verksamhet<\/h2>\n\n<p>Jag b\u00f6rjar med keepalive 32\u201364, 500\u20131000 f\u00f6rfr\u00e5gningar per anslutning och 60 sekunders inaktivitetstid, m\u00e4ter sedan systematiskt och justerar v\u00e4rdena; det ger snabba <strong>framg\u00e5ngar<\/strong>. Varje \u00e4ndring f\u00f6ljer jag upp med m\u00e4tv\u00e4rden f\u00f6r anslutningshastighet, latens och felm\u00f6nster tills kurvorna blir mer stabila. Storleken p\u00e5 poolen anpassar jag efter antalet samtidiga f\u00f6rfr\u00e5gningar, inte efter den r\u00e5a genomstr\u00f6mningen per sekund. Timeouts f\u00e5r aldrig vara l\u00e4ngre \u00e4n motsvarigheterna i backend-stacken, annars riskerar man sporadiska \u00e5terst\u00e4llningar. Den som vill justera hastigheten mer ing\u00e5ende hittar tips om finjustering under <a href=\"https:\/\/webhosting.de\/sv\/optimera-nginx-keepalive-foerfragningar-prestandajustering-av-webbservern\/\">Optimera keepalive-f\u00f6rfr\u00e5gningar<\/a>, vilket g\u00f6r \u00e5tervinningen l\u00e4tt att hantera.<\/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>Justering av proxy-timeouts och TCP-keepalive<\/h2>\n\n<p>F\u00f6rutom de rena Keepalive-parametrarna finjusterar jag transporttidsgr\u00e4nserna noggrant. Kombinationen av <strong>proxy_anslutning_timeout<\/strong>, <strong>proxy_send_timeout<\/strong> och <strong>proxy_read_timeout<\/strong> best\u00e4mmer hur t\u00e5lmodig NGINX \u00e4r vid uppbyggnad, s\u00e4ndning och mottagning. Jag st\u00e4ller aldrig in dessa v\u00e4rden h\u00f6gre \u00e4n motsvarande v\u00e4rden i backend, utan n\u00e5got l\u00e4gre, s\u00e5 att fel uppt\u00e4cks tidigt och inte eskalerar p\u00e5 app-sidan. Dessutom aktiverar jag <strong>proxy_socket_keepalive<\/strong>, s\u00e5 att operativsystemet med j\u00e4mna mellanrum skickar livstecken via inaktiva socklar och uppt\u00e4cker halv\u00f6ppna anslutningar. Detta f\u00f6rhindrar att d\u00f6da anslutningar blir kvar i poolen och orsakar latensspikar vid n\u00e4sta beg\u00e4ran.<\/p>\n\n<pre><code>server {\n    listen 80;\n\n    location \/ {\n proxy_pass http:\/\/backend_pool;\n\n proxy_connect_timeout 3s;   # avbryt snabbt om anslutning inte \u00e4r m\u00f6jlig\n proxy_send_timeout    30s;  # Skrivning till backend\n proxy_read_timeout    30s;  # Svar fr\u00e5n backend\n proxy_socket_keepalive on;  # Aktivera OS-TCP-keepalive\n    }\n}\n<\/code><\/pre>\n\n<p>F\u00f6r str\u00f6mmar som p\u00e5g\u00e5r under l\u00e5ng tid (t.ex. SSE eller WebSockets) \u00f6kar jag endast tidsgr\u00e4nsen f\u00f6r l\u00e4sning, medan anslutningen f\u00f6rblir aktiv. P\u00e5 s\u00e5 s\u00e4tt kan jag reagera snabbt p\u00e5 felaktiga m\u00e5l, samtidigt som legitima, l\u00e5nga svar f\u00e5r passera ost\u00f6rt.<\/p>\n\n<h2>Resursplanering: worker_connections, FD:er och tillf\u00e4lliga portar<\/h2>\n\n<p>En ren keepalive-pool hj\u00e4lper inte om gr\u00e4nserna f\u00f6r filbeskrivare eller portintervall \u00e4r utt\u00f6mda. Jag planerar d\u00e4rf\u00f6r att <strong>arbetare_anslutningar<\/strong> och <strong>arbetare_rlimit_nofile<\/strong> med en viss marginal. Grovt r\u00e4knat: \u00d6ppna FD:er \u2248 (samtidiga klientanslutningar + samtidiga backend-anslutningar + poolade inaktiva socklar) per arbetare. Om jag anv\u00e4nder flera uppstr\u00f6ms med pooler multipliceras behovet. Jag \u00e4r ocks\u00e5 uppm\u00e4rksam p\u00e5 systemets omr\u00e5de f\u00f6r tillf\u00e4lliga portar, eftersom NGINX agerar som en TCP-klient mot backend och ackumulerar TIME_WAIT-tillst\u00e5nd.<\/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># Linux-exempel (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>Jag v\u00e4ljer en konservativ strategi: jag avbryter inte TIME_WAIT p\u00e5 ett aggressivt s\u00e4tt, utan s\u00e4nker ist\u00e4llet anslutningsfrekvensen med hj\u00e4lp av keepalive. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir k\u00e4rnparametrarna icke-kritiska och beteendet f\u00f6ruts\u00e4gbart.<\/p>\n\n<h2>Upstream-zoner, balanseringsstrategi och DNS-rotation<\/h2>\n\n<p>Om det finns flera arbetare delar jag balanseringsstatus via en <strong>zon<\/strong>, s\u00e5 att avbrott och belastning f\u00f6rblir konsekventa. Keepalive-socklarna finns visserligen fortfarande per worker, men f\u00f6rdelningen blir j\u00e4mnare. F\u00f6r dynamiska backend-tj\u00e4nster som flyttas via DNS st\u00e4ller jag in \u201e<strong>resolve<\/strong>\u201c i serverraderna och definiera en <strong>resolver<\/strong>. Viktigt: N\u00e4r IP-adresserna roterar \u00e5teranv\u00e4nder inte poolen omedelbart alla gamla socklar; d\u00e4rf\u00f6r anser jag att <em>keepalive_requests<\/em> och tidsgr\u00e4nser inom rimliga ramar, s\u00e5 att f\u00f6rnyelsen snabbt f\u00e5r genomslag.<\/p>\n\n<pre><code>upstream backend_pool {\n    zone backend_zone 128k;  # delar balancerarens tillst\u00e5nd\n    least_conn; # r\u00e4ttvis f\u00f6rdelning vid l\u00e5nga f\u00f6rfr\u00e5gningar\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;  # f\u00e5, riktade f\u00f6rs\u00f6k\n<\/code><\/pre>\n\n<p>F\u00f6r sessioner som \u00e4r knutna till en specifik backend-nod (t.ex. sticky-state) kombinerar jag \u00e5teranv\u00e4ndning med <em>ip_hash<\/em> eller en extern sessionsmekanism. Detta f\u00f6rhindrar att anslutningspoolning st\u00f6r sessionskonsistensen.<\/p>\n\n<h2>TLS till backend: SNI, \u00e5teranv\u00e4ndning av sessioner och krypteringsalgoritmer<\/h2>\n\n<p>Ju mer TLS anv\u00e4nds i backend-v\u00e4gen, desto viktigare \u00e4r Keepalive. Jag aktiverar SNI, anger det f\u00f6rv\u00e4ntade namnet och ser till att TLS-sessionen \u00e5teranv\u00e4nds. Detta minskar handskakningskostnaderna och j\u00e4mnar ut latensspikar. Jag v\u00e4ljer krypteringssviter och protokoll med f\u00f6rsiktighet, utan att st\u00e4nga ute \u00e4ldre backend-system. Vid certifikatverifiering (valfritt) m\u00e5ste f\u00f6rtroendekedjan vara komplett, annars bryts anslutningarna sporadiskt.<\/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>N\u00e4r jag sj\u00e4lv \u00f6vervakar backend-sidan aktiverar jag sessionstickets eller -cacher d\u00e4r och kontrollerar med hj\u00e4lp av m\u00e4tv\u00e4rden om \u00e5terupptagningsgraden \u00f6kar. I kombination med Keepalive uppn\u00e5r jag p\u00e5 s\u00e5 s\u00e4tt genomg\u00e5ende korta anslutnings- och handskakningstider.<\/p>\n\n<h2>S\u00e4rskilda fall: gRPC, WebSockets och anslutningsbunden autentisering<\/h2>\n\n<p>Med <strong>gRPC<\/strong> fungerar NGINX uppstr\u00f6ms via HTTP\/2. H\u00e4r ger ofta ett f\u00e5tal l\u00e5ngvariga anslutningar med m\u00e5nga str\u00f6mmar de b\u00e4sta resultaten; poolen f\u00f6rblir liten men stabil. F\u00f6r <strong>WebSockets<\/strong> Jag st\u00e4ller in l\u00e5nga l\u00e4s-timeouts och beh\u00e5ller header-logiken fr\u00e5n map-l\u00f6sningen, s\u00e5 att uppgraderingsanslutningar inte st\u00e4ngs av misstag. <strong>NTLM<\/strong> eller andra anslutningsbundna autentiseringsmetoder kr\u00e4ver anslutningsbindning; jag delar upp s\u00e5dana v\u00e4gar i separata platser och minskar d\u00e4r poolning eller \u00e5teranv\u00e4ndning, s\u00e5 att s\u00e4kerhetshandskakningar inte blandas ihop mellan klienter.<\/p>\n\n<pre><code># gRPC-exempel\nlocation \/grpc.Service\/ {\n    grpc_pass grpc:\/\/backend_pool;\n    grpc_read_timeout 300s;  Till\u00e5t #-l\u00e5nga str\u00f6mmar\n}\n<\/code><\/pre>\n\n<p>Det \u00e4r avg\u00f6rande att fastst\u00e4lla en konsekvent anslutningspolicy f\u00f6r varje v\u00e4g och endast anv\u00e4nda Keepalive i stor utstr\u00e4ckning d\u00e4r det inte \u00e4r semantiskt kritiskt.<\/p>\n\n<h2>M\u00e4tbarhet i praktiken: \u00e5tkomstloggar med uppstr\u00f6ms-tidsangivelser<\/h2>\n\n<p>Jag ut\u00f6kar Access-loggen med uppstr\u00f6msm\u00e5tt. P\u00e5 s\u00e5 s\u00e4tt kan jag med ett \u00f6gonkast se om ett svar kom fr\u00e5n en socket i poolen (mycket kort anslutningstid) och hur ofta backend-fel uppst\u00e5r. Dessutom loggar jag anslutningsnumret och antalet f\u00f6rfr\u00e5gningar via den aktuella klientanslutningen f\u00f6r att kunna hitta korrelationer.<\/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>Dessutom anv\u00e4nder jag operativsystemets status\u00e4ndpunkter och socketstatistik. Ett normalt tillst\u00e5nd k\u00e4nnetecknas av: sjunkande anslutningshastighet till backenden, kortare upstream_connect_time, stabila svarstider och n\u00e4stan inga anslutnings\u00e5terst\u00e4llningar. Avvikelser tyder n\u00e4stan alltid p\u00e5 felaktigt inst\u00e4llda tidsgr\u00e4nser eller f\u00f6r sm\u00e5\/f\u00f6r stora pooler.<\/p>\n\n<h2>Lanseringsstrategi och riskminimerande finjustering<\/h2>\n\n<p>Jag arbetar stegvis: sm\u00e5 steg, m\u00e4ta, justera. F\u00f6rst aktiverar jag Keepalive i m\u00e5ttlig utstr\u00e4ckning, d\u00e4refter justerar jag timeouts och antalet f\u00f6rfr\u00e5gningar per anslutning. Jag till\u00e4mpar \u00e4ndringarna genom att ladda om sidan, utan att bryta aktiva anslutningar. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir risken l\u00e5g och effekterna g\u00e5r att tydligt koppla till varandra.<\/p>\n\n<pre><code># Validera \u00e4ndringar och ladda om utan driftstopp\nnginx -t &amp;&amp; nginx -s reload\n<\/code><\/pre>\n\n<p>N\u00e4r jag hanterar flera uppstr\u00f6msprocesser finjusterar jag dem en efter en, med b\u00f6rjan p\u00e5 den mest kritiska v\u00e4gen. Varje steg f\u00e5r ett observationsf\u00f6nster s\u00e5 att m\u00f6nster i m\u00e4tv\u00e4rdena tydligt framtr\u00e4der. F\u00f6rst d\u00e4refter skalar jag upp eller ner v\u00e4rdena.<\/p>\n\n<h2>En kort sammanfattning f\u00f6r din omv\u00e4nda proxy<\/h2>\n\n<p>Jag anv\u00e4nder HTTP\/1.1, t\u00f6mmer Connection-rubriken och v\u00e4ljer poolstorleken utifr\u00e5n antalet samtidiga f\u00f6rfr\u00e5gningar, inte utifr\u00e5n RPS; detta bidrar till att <strong>Effekt<\/strong>. Med keepalive_requests och keepalive_timeout h\u00e5ller jag anslutningarna aktiva och undviker \u00f6verraskningar p\u00e5 grund av f\u00f6r\u00e5ldrade socklar. \u00d6vervakningen visar om upstream_connect_time tenderar att n\u00e4rma sig noll och om anslutningsfrekvensen till backenden minskar. Vid fel kontrollerar jag f\u00f6rst protokollversion, vidarebefordran av rubriker, tidsgr\u00e4nser och poolstorlek. S\u00e5 h\u00e4r h\u00e5ller du din NGINX-proxy ig\u00e5ng under h\u00f6g belastning <strong>lyh\u00f6rd<\/strong> och f\u00f6ruts\u00e4gbar.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e4r dig hur du konfigurerar NGINX Upstream Keepalive p\u00e5 b\u00e4sta s\u00e4tt i nginx-upstream-blocket f\u00f6r att avsev\u00e4rt f\u00f6rb\u00e4ttra prestandan hos din omv\u00e4nda proxy.<\/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":"112","_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":null,"_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\/sv\/wp-json\/wp\/v2\/posts\/21613","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/comments?post=21613"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/21613\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/21606"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=21613"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=21613"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=21613"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}