{"id":21459,"date":"2026-09-16T15:03:59","date_gmt":"2026-09-16T13:03:59","guid":{"rendered":"https:\/\/webhosting.de\/nginx-keepalive-requests-optimieren-webserver-performance-tuning\/"},"modified":"2026-09-16T15:03:59","modified_gmt":"2026-09-16T13:03:59","slug":"optimera-nginx-keepalive-foerfragningar-prestandajustering-av-webbservern","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/nginx-keepalive-requests-optimieren-webserver-performance-tuning\/","title":{"rendered":"Optimera NGINX Keepalive-f\u00f6rfr\u00e5gningar: H\u00f6gsta m\u00f6jliga webbserverprestanda genom m\u00e5linriktad finjustering"},"content":{"rendered":"<p>Med <strong>nginx keepalive<\/strong> Jag s\u00e4nker kostnaderna f\u00f6r uppkoppling, minskar antalet handskakningar och f\u00f6rb\u00e4ttrar svarstiderna m\u00e4rkbart. Noggrant anpassade timeouts, beg\u00e4ranbegr\u00e4nsningar per anslutning och \u00e5teranv\u00e4nda uppstr\u00f6ms-socklar ger m\u00e4tbara prestandaf\u00f6rb\u00e4ttringar utan ny h\u00e5rdvara.<\/p>\n\n<h2>Centrala punkter<\/h2>\n\n<ul>\n  <li><strong>Tidsfrister<\/strong> V\u00e4lj p\u00e5 ett klokt s\u00e4tt: L\u00e5t tomg\u00e5ngstiden vara s\u00e5 kort som m\u00f6jligt, men s\u00e5 l\u00e5ng som den \u00e4r anv\u00e4ndbar.<\/li>\n  <li><strong>F\u00f6rfr\u00e5gningar<\/strong> Begr\u00e4nsa per anslutning: H\u00e5llbara anslutningar, inga avbrott.<\/li>\n  <li><strong>Upstream-pooler<\/strong> Aktivera: Permanenta backend-anslutningar per arbetare.<\/li>\n  <li><strong>Arbetare<\/strong> och anpassa anslutningarna: Tillr\u00e4ckligt med platser f\u00f6r inaktiva och aktiva klienter.<\/li>\n  <li><strong>\u00d6vervakning<\/strong> etablera: \u00d6vervaka anslutningshastighet, latens och fel.<\/li>\n<\/ul>\n\n<h2>NGINX Keepalive: Effekt och kostnader<\/h2>\n\n<p>Jag l\u00e5ter medvetet TCP-anslutningarna vara \u00f6ppna, eftersom <strong>Handskakningar<\/strong> \u00e4r kostsamma och dominerar vid m\u00e5nga sm\u00e5 f\u00f6rfr\u00e5gningar. Persistenta socklar sparar inte bara RTT:er, utan j\u00e4mnar ocks\u00e5 ut CPU-belastningen, eftersom kryptografin f\u00f6r TLS beh\u00f6ver k\u00f6ras mindre ofta. Varje \u00f6ppen anslutning tar dock upp <strong>Resurser<\/strong>, till exempel filbeskrivare och buffertar, som jag m\u00e5ste h\u00e5lla koll p\u00e5. Konsten ligger i balansen: tillr\u00e4ckligt med \u00e5teranv\u00e4ndning f\u00f6r att uppr\u00e4tth\u00e5lla hastigheten, tillr\u00e4ckligt med resurser f\u00f6r nya anslutningar vid belastningstoppar. Den som lyckas hitta den r\u00e4tta balansen uppn\u00e5r konstant l\u00e5ga TTFB-v\u00e4rden och en snabb anv\u00e4ndarupplevelse.<\/p>\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-keepalive-optimierung-4271.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>HTTP\/2 och HTTP\/3: Multiplexing m\u00f6ter Keepalive<\/h2>\n\n<p>Med <strong>HTTP\/2<\/strong> och <strong>HTTP\/3<\/strong> Antalet n\u00f6dv\u00e4ndiga anslutningar per klient minskar eftersom flera str\u00f6mmar g\u00e5r via en och samma linje. Keepalive \u00e4r dock fortfarande viktigt: den enda anslutningen b\u00f6r f\u00f6rbli \u00f6ppen p\u00e5 ett tillf\u00f6rlitligt s\u00e4tt, annars g\u00e5r f\u00f6rdelen med multiplexering f\u00f6rlorad p\u00e5 grund av frekventa \u00e5teranslutningar.<\/p>\n<p>Jag ser till att det finns s\u00e4rskilda viloparametrar f\u00f6r moderna protokoll och att v\u00e4rdena st\u00e4mmer \u00f6verens med mina klient-timeouts. Vid tester b\u00f6rjar jag p\u00e5 en m\u00e5ttlig niv\u00e5 och h\u00f6jer v\u00e4rdena n\u00e4r belastningen \u00e4r stabil, tills antalet \u00e5teranslutningar minskar och f\u00f6rdr\u00f6jningarna f\u00f6rblir konstanta.<\/p>\n\n<pre><code>http {\n    # HTTP\/2: V\u00e4ntetid f\u00f6r oanv\u00e4nda men \u00f6ppna str\u00f6mmar\n    http2_idle_timeout 60s;\n\n    # HTTP\/3\/QUIC: liknande logik f\u00f6r UDP-baserade anslutningar\n    http3_idle_timeout 60s;\n\n    # TLS-\u00e5terupptagning minskar handskakningskostnaderna vid nya anslutningar\n    ssl_session_cache shared:SSL:50m;\n    ssl_session_timeout 1d;\n    ssl_session_tickets off;\n}\n<\/code><\/pre>\n\n<p>Multiplexering minskar det antal parallella TCP\/QUIC-anslutningar som kr\u00e4vs, men inte betydelsen av <strong>korrekta timeouts<\/strong>. Den som anv\u00e4nder HTTP\/2\/3 kan ofta st\u00e4lla in klientens tidsgr\u00e4nser n\u00e5got gener\u00f6sare, eftersom m\u00e5nga sm\u00e5 resurser skickas via samma kanal. Viktigt: F\u00f6rbli m\u00e4tbar <em>Tid till f\u00f6rsta byte<\/em>, felprocent och \u00f6ppna str\u00f6mmar per anslutning.<\/p>\n\n<h2>St\u00e4lla in Client-Keepalive korrekt<\/h2>\n\n<p>F\u00f6r webbl\u00e4sarklienter styr jag \u00e5teranv\u00e4ndningen via <strong>keepalive_timeout<\/strong> och <strong>keepalive_requests<\/strong>, s\u00e5 att socklarna h\u00e5ller tillr\u00e4ckligt l\u00e4nge utan att blockeras i evigheter. Som utg\u00e5ngspunkt anv\u00e4nder jag en timeout p\u00e5 30\u201360 sekunder och 100\u2013300 f\u00f6rfr\u00e5gningar per anslutning, och justerar sedan utifr\u00e5n m\u00e4tv\u00e4rdena. En detaljerad \u00f6versikt finns h\u00e4r <a href=\"https:\/\/webhosting.de\/sv\/http-keepalive-timeout-konfiguration-av-serverprestanda\/\">Guide till keepalive-timeout<\/a>, som f\u00f6rklarar hur detta p\u00e5verkar latensen och serverresurserna. Kortare timeout-tider l\u00e4mpar sig vid ett mycket stort antal korta anrop, medan l\u00e4ngre tidsf\u00f6nster \u00e4r l\u00e4mpliga vid periodiska API-anrop. Till att b\u00f6rja med st\u00e4ller jag in tydliga standardv\u00e4rden och m\u00e4ter effekten p\u00e5 \u00f6ppna anslutningar samt felm\u00f6nster.<\/p>\n\n<pre><code>http {\n    # Inaktiva anslutningar till klienten\n    keepalive_timeout 60s;\n    # \u00d6vre gr\u00e4ns f\u00f6r antalet f\u00f6rfr\u00e5gningar per TCP-anslutning\n    keepalive_requests 200;\n\n    # Valfritt: inaktivera Keep-Alive f\u00f6r vissa klienter (\u00e4ldre buggar)\n    # keepalive_disable msie6;\n}\n<\/code><\/pre>\n\n<h2>Upstream-Keepalive i omv\u00e4nd proxy<\/h2>\n\n<p>Mellan NGINX och backend-apparna anv\u00e4nder jag persistenta upstream-socklar, eftersom anslutningen till PHP-FPM, Node.js eller Python-tj\u00e4nster ocks\u00e5 <strong>F\u00f6rdr\u00f6jning<\/strong> kostar. F\u00f6r detta aktiverar jag ett l\u00e4mpligt antal \u00e5teranv\u00e4ndbara anslutningar per arbetare i uppstr\u00f6ms-poolen. Det \u00e4r viktigt att anv\u00e4nda HTTP\/1.1 bak\u00e5t och en tom Connection-header, annars bryter klientens beg\u00e4ran \u201eclose\u201c backend-persistensen. Jag utg\u00e5r fr\u00e5n antalet samtidiga f\u00f6rfr\u00e5gningar och st\u00e4ller in poolen s\u00e5 att det knappt uppst\u00e5r n\u00e5gra nya anslutningar. P\u00e5 s\u00e5 s\u00e4tt minskar anslutningstiden till backend, och hela kedjan levererar snabbare <strong>Svar p\u00e5 fr\u00e5gor<\/strong>.<\/p>\n\n<pre><code>upstream backend {\n    server 127.0.0.1:9000;\n    keepalive 64; # Antal best\u00e4ndiga uppstr\u00f6msanslutningar per arbetare\n}\n\nserver {\n    location \/ {\n proxy_pass http:\/\/backend;\n        proxy_http_version 1.1;\n proxy_set_header Connection \"\";\n # TCP-keepalive f\u00f6r uppstr\u00f6ms-socklar p\u00e5 operativsystemsniv\u00e5\n proxy_socket_keepalive on;\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_optimierung_miniature_4891.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dimensionering av poolen och anslutningsbudget<\/h2>\n\n<p>Jag ber\u00e4knar pooler p\u00e5 ett realistiskt s\u00e4tt: Antalet best\u00e5ende uppstr\u00f6msanslutningar ber\u00e4knas utifr\u00e5n <strong>worker_processes \u00d7 keepalive<\/strong> per uppstr\u00f6msm\u00e5l. Den som anv\u00e4nder 8 arbetare och keepalive 64 h\u00e5ller upp till 512 socklar \u00f6ppna per uppstr\u00f6msm\u00e5l \u2013 per instans. Bakom en lastbalanserare eller vid flera uppstr\u00f6msm\u00e5l kan detta snabbt bli ett stort antal.<\/p>\n<p>Mitt m\u00e5l: tillr\u00e4ckligt m\u00e5nga \u00f6ppna socklar f\u00f6r att majoriteten av f\u00f6rfr\u00e5gningarna <em>utan ny Connect<\/em> tillgodoses, men det finns fortfarande utrymme f\u00f6r toppar. Jag \u00f6vervakar m\u00e4tv\u00e4rdet \u201enya uppstr\u00f6msanslutningar per sekund\u201c och s\u00e4nker det tills ytterligare \u00f6kningar av poolstorleken inte l\u00e4ngre ger n\u00e5gon m\u00e4rkbar f\u00f6rb\u00e4ttring av latensen.<\/p>\n<p>Jag tar ocks\u00e5 h\u00e4nsyn till <strong>R\u00e4ttvisa<\/strong>: F\u00f6r stora pooler kan missgynna nyanl\u00e4nda klienter, eftersom arbetarslots upptas av inaktiva anslutningar. En rimlig gr\u00e4ns i kombination med aktiv \u00f6vervakning \u00e4r oftast snabbare \u00e4n att s\u00e4tta maximiv\u00e4rden p\u00e5 gissning.<\/p>\n\n<h2>Finjustering: Timeouts och beg\u00e4ranbegr\u00e4nsningar<\/h2>\n\n<p>Jag kombinerar timeout och beg\u00e4ranbegr\u00e4nsning s\u00e5 att anslutningarna effektivt \u00e5teranv\u00e4nds utan att leda till <strong>L\u00e4ngdskid\u00e5kare<\/strong> att bli. H\u00f6ga v\u00e4rden p\u00e5 b\u00e5da axlarna minimerar antalet anslutningar, men \u00f6kar risken f\u00f6r att socklar fastnar vid n\u00e4tverksproblem. L\u00e5ga v\u00e4rden s\u00e4kerst\u00e4ller nya anslutningar, men kr\u00e4ver ytterligare handskakningar. Jag g\u00e5r fram\u00e5t i sm\u00e5 steg, observerar fel och justerar med j\u00e4mna mellanrum. F\u00f6ljande tabell visar l\u00e4mpliga startintervall f\u00f6r olika anv\u00e4ndningsm\u00f6nster och ger en kompakt <strong>Orientering<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Scenario<\/th>\n      <th>keepalive_timeout<\/th>\n      <th>keepalive_requests<\/th>\n      <th>Ledtr\u00e5d<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>M\u00e5nga korta sidvisningar<\/td>\n      <td>10\u201330 sekunder<\/td>\n      <td>100-300<\/td>\n      <td>Snabb \u00e5teranv\u00e4ndning, l\u00e5g belastning vid inaktivitet<\/td>\n    <\/tr>\n    <tr>\n      <td>En typisk webbplats<\/td>\n      <td>60\u2013120 sekunder<\/td>\n      <td>200\u2013400<\/td>\n      <td>Bra medelv\u00e4rde f\u00f6r Assets och HTML<\/td>\n    <\/tr>\n    <tr>\n      <td>API med periodiska anrop<\/td>\n      <td>60\u2013120 sekunder<\/td>\n      <td>300\u20131000<\/td>\n      <td>H\u00f6gre \u00e5teranv\u00e4ndningsgrad f\u00f6r kunder<\/td>\n    <\/tr>\n    <tr>\n      <td>Interna tj\u00e4nster \/ Gatewayer<\/td>\n      <td>30\u201390 sekunder<\/td>\n      <td>500\u20131000+<\/td>\n      <td>Konstans \u00e4r viktigare \u00e4n minimala anslutningar<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Arbetstagaranpassning och kopplingar<\/h2>\n\n<p>Jag satte <strong>arbetare_processer<\/strong> p\u00e5 \u201dauto\u201d eller p\u00e5 antalet CPU-k\u00e4rnor och planera f\u00f6r tillr\u00e4ckligt m\u00e5nga <strong>arbetare_anslutningar<\/strong> eftersom inaktiva socklar upptar plats. F\u00f6r l\u00e5ga gr\u00e4nsv\u00e4rden f\u00f6rhindrar nya anslutningar, trots att det fortfarande finns ledig CPU-kapacitet. Den som anv\u00e4nder stora keepalive-pooler beh\u00f6ver tillr\u00e4ckligt med deskriptorer och h\u00e4ndelseplatser per arbetare. En bra introduktion finns i \u201e<a href=\"https:\/\/webhosting.de\/sv\/nginx-arbetaranslutningar-skalning-av-tusentals-foerfragningar-trafficboost\/\">Skala upp Worker-Connections<\/a>\u201c, som f\u00f6rklarar sambanden mellan h\u00e4ndelser, anslutningar och belastning. V\u00e4l genomt\u00e4nkta v\u00e4rden s\u00e4kerst\u00e4ller att \u00e5teranv\u00e4ndning vid inaktivitet och nya anslutningar kan existera parallellt.<\/p>\n\n<pre><code>worker_processes auto;\n\nevents {\n    worker_connections 4096;\n    # Valfritt: reuseport kan f\u00f6rb\u00e4ttra f\u00f6rdelningen p\u00e5 k\u00e4rnniv\u00e5\n    # multi_accept on;\n}\n\nhttp {\n    keepalive_timeout 60s;\n    keepalive_requests 200;\n\n upstream backend {\n server 127.0.0.1:9000;\n keepalive 64;\n    }\n}\n<\/code><\/pre>\n\n<h2>Optimering av operativsystem och socklar<\/h2>\n\n<p>Jag kontrollerar systemgr\u00e4nserna s\u00e5 att Keepalive kan n\u00e5 sin fulla potential. F\u00f6r f\u00e5 deskriptorer eller tr\u00e5nga socket-k\u00f6er leder till <strong>konstgjorda flaskhalsar<\/strong>. F\u00f6rutom ulimit och worker_rlimit_nofile spelar k\u00e4rnans begr\u00e4nsningar en avg\u00f6rande roll.<\/p>\n\n<pre><code># Exempel p\u00e5 sysctl-v\u00e4rden (justera med f\u00f6rsiktighet och efter tester)\nfs.file-max = 1000000\nnet.core.somaxconn = 65535\nnet.core.netdev_max_backlog = 16384\nnet.ipv4.ip_local_port_range = 1024 65000\nnet.ipv4.tcp_fin_timeout = 15\nnet.ipv4.tcp_tw_reuse = 1\nnet.ipv4.tcp_max_syn_backlog = 262144\n<\/code><\/pre>\n\n<p>Jag anpassar dessa v\u00e4rden efter omgivningen: m\u00e5nga kortlivade anslutningar gynnas av ett bredare portintervall och korta FIN-\/TIME_WAIT-tider. N\u00e4r det g\u00e4ller uppstr\u00f6ms-keepalive minskar jag <em>Neuconnects<\/em>, vilket g\u00f6r att TIME_WAIT-trycket minskar. Dessutom tar jag h\u00e4nsyn till <strong>NAT<\/strong>-Enheter mellan proxy och backend: Alltf\u00f6r str\u00e4nga tidsgr\u00e4nser f\u00f6r inaktivitet i n\u00e4tverket kan avbryta anslutningar p\u00e5 of\u00f6ruts\u00e4gbart s\u00e4tt. En rimlig begr\u00e4nsning av antalet f\u00f6rfr\u00e5gningar per socket och TCP-keepalives (<code>proxy_socket_keepalive on;<\/code>) f\u00f6rhindrar att anslutningarna blir \u201ef\u00f6r\u00e5ldrade\u201c.<\/p>\n\n<h2>St\u00e4ll in rubrik och HTTP-version korrekt<\/h2>\n\n<p>Jag \u00e4r uppm\u00e4rksam p\u00e5 <strong>HTTP\/1.1<\/strong> till backend, eftersom Upstream-Keepalive endast fungerar med det. Dessutom tar jag bort den aktiva anslutningsstyrningen via header, s\u00e5 att NGINX sj\u00e4lvst\u00e4ndigt hanterar persistensen. P\u00e5 klientsidan l\u00e5ter jag Keep-Alive k\u00f6ras enligt standarden och begr\u00e4nsar livsl\u00e4ngden via timeout och beg\u00e4ranbegr\u00e4nsning. Dessutom kontrollerar jag backend-idle-timeouts och st\u00e4ller in dem n\u00e5got h\u00f6gre \u00e4n NGINX f\u00f6r att undvika \u00e5terst\u00e4llningsfel. Rena rubriker s\u00e4kerst\u00e4ller <strong>\u00c5teranv\u00e4ndning<\/strong> utan o\u00f6nskade st\u00e4ngningar.<\/p>\n\n<pre><code># Exempel: Proxy-Location med korrekta rubriker\nlocation \/api\/ {\n    proxy_pass http:\/\/backend;\n    proxy_http_version 1.1;\n    proxy_set_header Connection \"\";\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-keepalive-optimization-7123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Skillnad: HTTP Keep-Alive j\u00e4mf\u00f6rt med TCP-Keepalive<\/h2>\n\n<p>Jag g\u00f6r en strikt \u00e5tskillnad mellan <strong>HTTP Keep-Alive<\/strong> (flera HTTP-f\u00f6rfr\u00e5gningar per anslutning) och <strong>TCP-Keepalive<\/strong> (Test p\u00e5 operativsystemsniv\u00e5 f\u00f6r att uppt\u00e4cka inaktiva motparter). Jag styr HTTP Keep-Alive med <code>keepalive_timeout<\/code> och <code>keepalive_requests<\/code>, medan TCP-keepalives, beroende p\u00e5 stacken, kan vara upp till <code>proxy_socket_keepalive on;<\/code> och systemparametrar. F\u00f6r backend-system som ansluter via instabila n\u00e4tverk aktiverar jag TCP-keepalives f\u00f6r att snabbare rensa bort h\u00e4ngande socklar.<\/p>\n\n<h2>L\u00e5ngk\u00f6rare och specialfall: WebSockets, SSE, gRPC<\/h2>\n\n<p>WebSockets och server-s\u00e4nda h\u00e4ndelser \u00e4r <strong>L\u00e4ngdskid\u00e5kare<\/strong>, som h\u00e5ller en anslutning \u00f6ppen under l\u00e5ng tid \u2013 h\u00e4r spelar klassisk \u00e5teranv\u00e4ndning en underordnad roll. Jag ser till att det finns l\u00e4mpliga <code>proxy_read_timeout<\/code> och skydda mig med <code>send_timeout<\/code> mot <em>Slowloris<\/em>-effekter. F\u00f6r gRPC (HTTP\/2-baserat) g\u00e4ller \u00f6verv\u00e4gandena kring multiplexering; jag st\u00e4ller in timeout-v\u00e4rdena f\u00f6r inaktivitet s\u00e5 att str\u00f6mmar inte st\u00e4ngs av i on\u00f6dan.<\/p>\n\n<pre><code>location \/ws\/ {\n    proxy_pass http:\/\/backend;\n    proxy_http_version 1.1;\n    proxy_set_header Upgrade $http_upgrade;\n    proxy_set_header Connection \"upgrade\";\n    proxy_read_timeout 300s;\n    send_timeout 30s;\n}\n<\/code><\/pre>\n\n<h2>\u00d6vervakning och m\u00e4tetal<\/h2>\n\n<p>Jag m\u00e4ter framg\u00e5ngen utifr\u00e5n nyckeltal som andelen nya uppstr\u00f6msanslutningar, <strong>uppstr\u00f6ms_anslutning_tid<\/strong> och andelen \u00f6ppna anslutningar per arbetare. Sjunkande anslutningshastigheter vid of\u00f6r\u00e4ndrat eller \u00f6kande antal f\u00f6rfr\u00e5gningar tyder p\u00e5 framg\u00e5ngsrik \u00e5teranv\u00e4ndning. P\u00e5fallande timeouts eller \u00e5terst\u00e4llningar av anslutningar signalerar inkonsekventa timeouts mellan NGINX och backend. Dessutom \u00f6vervakar jag minne, filbeskrivare och h\u00e4ndelsek\u00f6er under belastning. Den som kontrollerar regelbundet uppt\u00e4cker trender tidigt och f\u00f6rhindrar kostsamma <strong>Misslyckanden<\/strong>.<\/p>\n\n<h2>F\u00f6rb\u00e4ttringar av loggningen f\u00f6r \u00f6kad transparens vid \u00e5teranv\u00e4ndning<\/h2>\n\n<p>F\u00f6r att f\u00e5 en b\u00e4ttre \u00f6verblick ut\u00f6kar jag \u00e5tkomstloggen med uppkopplingsdetaljer. P\u00e5 s\u00e5 s\u00e4tt kan jag se hur ofta en TCP-anslutning \u00e5teranv\u00e4nds och hur anslutningstiderna utvecklas.<\/p>\n\n<pre><code>log_format keepalive_fmt\n  '$remote_addr $host \"$request\" $status $body_bytes_sent '\n  '$request_time $upstream_connect_time '\n  'conn:$connection reqs:$connection_requests';\n\naccess_log \/var\/log\/nginx\/access_keepalive.log keepalive_fmt;\n<\/code><\/pre>\n\n<p>Jag observerar medianv\u00e4rden samt P95- och P99-v\u00e4rden f\u00f6r <em>uppstr\u00f6ms_anslutning_tid<\/em> samt f\u00f6rdelningen av <em>$-anslutningsf\u00f6rfr\u00e5gningar<\/em>. Stigande Reuse-v\u00e4rden vid stabil latens inneb\u00e4r att pooler och timeouts \u00e4r l\u00e4mpligt valda.<\/p>\n\n<h2>Typiska st\u00f6testenar och l\u00f6sningar<\/h2>\n\n<p>F\u00f6r stora pooler fyller anslutningsslots medan nya klienter v\u00e4ntar, d\u00e4rf\u00f6r h\u00e5ller jag storlekarna p\u00e5 en rimlig niv\u00e5 och m\u00e4ter. Olika tidsgr\u00e4nser f\u00f6r inaktivitet mellan proxy och backend orsakar \u00e5terst\u00e4llningar, s\u00e5 jag st\u00e4ller in backenden till ett v\u00e4rde som \u00e4r minimalt h\u00f6gre \u00e4n <strong>NGINX<\/strong>. Ett gl\u00f6mt \u201eConnection: close\u201c i proxy-headern avbryter persistensen, d\u00e4rf\u00f6r rensar jag headern systematiskt. TLS-f\u00f6rhandlingar kan belasta processorn vid m\u00e5nga nya anslutningar, vilket jag mildrar genom en h\u00f6gre andel \u00e5teranv\u00e4ndning. Vid sporadiska n\u00e4tverksfel hj\u00e4lper en m\u00e5ttlig beg\u00e4randelimit per socket, s\u00e5 att gamla <strong>Sessioner<\/strong> inte leva f\u00f6r evigt.<\/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_optimierung_4723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktiska konfigurationer<\/h2>\n\n<p>F\u00f6r webbplatser med h\u00f6g trafik v\u00e4ljer jag en kort timeout och en medelh\u00f6g beg\u00e4ranbegr\u00e4nsning, s\u00e5 att resurserna fungerar effektivt. F\u00f6r API:er med \u00e5terkommande anrop h\u00f6jer jag gr\u00e4nsen f\u00f6r att ytterligare minska TCP- och TLS-handshakes. Jag dimensionerar uppstr\u00f6ms-pooler utifr\u00e5n f\u00f6rv\u00e4ntad parallellitet och testar med realistisk trafik. Varje milj\u00f6 beter sig olika, d\u00e4rf\u00f6r kontrollerar jag latensen och felbilderna efter \u00e4ndringar. Tv\u00e5 exempel visar <strong>Startv\u00e4rden<\/strong>, som jag sedan f\u00f6rfinar med hj\u00e4lp av m\u00e4tv\u00e4rden.<\/p>\n\n<pre><code># Scenario 1: H\u00f6gt trafikerad webbplats\nhttp {\n    keepalive_timeout 30s;\n    keepalive_requests 300;\n\n upstream app {\n server 127.0.0.1:8080;\n        keepalive 32;\n    }\n\n server {\n listen 443 ssl http2;\n # H\u00e5lla koll p\u00e5 HTTP\/2-inaktivitet\n http2_idle_timeout 45s;\n    }\n}\n<\/code><\/pre>\n\n<pre><code># Scenario 2: API med periodiska anrop\nhttp {\n    keepalive_timeout 75s;\n    keepalive_requests 1000;\n\n    upstream api_backend {\n server 127.0.0.1:9001;\n keepalive 64;\n    }\n\n    server {\n listen 443 ssl http2;\n # N\u00e5got l\u00e4ngre inaktivitetsf\u00f6nster f\u00f6r \u00e5terkommande anrop\n http2_idle_timeout 75s;\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\/serverraum-nginx-3721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Checklista f\u00f6r iterativ optimering<\/h2>\n\n<p>Jag b\u00f6rjar med en analys av nul\u00e4get: trafikm\u00f6nster, svarstider och felfrekvens anger takten. D\u00e4refter st\u00e4ller jag in klient-timeout och beg\u00e4ranbegr\u00e4nsning p\u00e5 stabila startv\u00e4rden och aktiverar uppstr\u00f6ms-pooler. Jag st\u00e4ller in backend-idle-timeouts n\u00e5got h\u00f6gre \u00e4n NGINX, s\u00e5 att inga ov\u00e4ntade <strong>\u00c5terst\u00e4llningar<\/strong> uppst\u00e5r. D\u00e4refter \u00f6vervakar jag anslutningshastigheter, anslutningstid och \u00f6ppna socklar per arbetare. Den som vill f\u00f6rdjupa sig i \u00e5teranv\u00e4ndningsgraden hittar tips kring <a href=\"https:\/\/webhosting.de\/sv\/http-anslutning-ateranvaendning-keepalive-optimering-serverperf-boost\/\">Anslutning \u00c5teranv\u00e4ndning<\/a> och rimliga \u00f6vre gr\u00e4nser.<\/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_opt_5731.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ytterligare diagnos: Mismatch och tidsbeteende<\/h2>\n\n<p>N\u00e4r anslutningarna avbryts utan n\u00e5gon uppenbar anledning letar jag efter <strong>Mismatchs<\/strong> i kedjan: Client-Idle vs. NGINX-Timeout vs. Backend-Idle och mellanliggande NAT\/gateways. Jag h\u00f6jer backend-timeouten n\u00e5got \u00f6ver NGINX-v\u00e4rdet, kontrollerar \u00e5terst\u00e4llningskoder i felloggen och observerar om <em>uppstr\u00f6ms_anslutning_tid<\/em> visar toppar. Ofta r\u00e4cker det med en liten buffert (t.ex. +10\u201320%) vid backend-timeout f\u00f6r att undvika \u00e5terst\u00e4llningar.<\/p>\n<p>Jag noterar dessutom \u201e<em>l\u00e5ngvarig n\u00e4rhet<\/em>\u201c-faser: Vid st\u00e4ngning l\u00e5ter NGINX inkommande data l\u00f6pa ut en kort stund, vilket tar upp resurser hos arbetarna. Ett mycket stort antal samtidiga st\u00e4ngningar kan binda upp h\u00e4ndelser. I s\u00e5dana fall kalibrerar jag st\u00e4ngningsf\u00f6nstren och h\u00e5ller det totala antalet \u00f6ppna anslutningar i balans genom l\u00e4mpliga keepalive-v\u00e4rden.<\/p>\n\n<h2>Sammanfattning: Keepalive som verktyg f\u00f6r att f\u00f6rb\u00e4ttra prestandan<\/h2>\n\n<p>Jag anv\u00e4nder Keepalive medvetet eftersom det s\u00e4nker kostnaderna f\u00f6r att uppr\u00e4tta anslutningar, minskar latensen och avlastar processorn. Kombinationen av l\u00e4mplig timeout, en tydlig beg\u00e4ranbegr\u00e4nsning och l\u00e4mpliga uppstr\u00f6mspooler ger m\u00e4rkbara <strong>hastighet<\/strong>. Utan \u00f6vervakning f\u00f6rblir potentialen outnyttjad, d\u00e4rf\u00f6r granskar jag nyckeltalen kontinuerligt och justerar v\u00e4rdena steg f\u00f6r steg. Den som beh\u00f6ver ytterligare reserver b\u00f6r h\u00e5lla koll p\u00e5 antalet arbetare, anslutningsslots och korrekt hantering av rubriker. Professionella konfigurationer, till exempel vid <strong>webhoster.de<\/strong>, utnyttjar dessa justeringsm\u00f6jligheter fullt ut och tillhandah\u00e5ller snabba, p\u00e5litliga tj\u00e4nster.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e4r dig hur du optimerar NGINX Keepalive-f\u00f6rfr\u00e5gningar f\u00f6r att avsev\u00e4rt \u00f6ka prestandan hos dina webbservrar. Med praktiska inst\u00e4llningar f\u00f6r keepalive_timeout, keepalive_requests, Upstream-Keepalive och worker-justering \u2013 inklusive fokus p\u00e5 NGINX Keepalive som en central inst\u00e4llningsparameter.<\/p>","protected":false},"author":1,"featured_media":21452,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-21459","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":"113","_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 keepalive","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":"21452","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/21459","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=21459"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/21459\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/21452"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=21459"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=21459"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=21459"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}