{"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":"optymalizacja-zadan-keepalive-w-nginx-dostrajanie-wydajnosci-serwera-www","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pl\/nginx-keepalive-requests-optimieren-webserver-performance-tuning\/","title":{"rendered":"Optymalizacja \u017c\u0105da\u0144 Keepalive w NGINX: maksymalna wydajno\u015b\u0107 serwera WWW dzi\u0119ki ukierunkowanemu dostrajaniu"},"content":{"rendered":"<p>Z <strong>nginx keepalive<\/strong> Obni\u017cam koszty nawi\u0105zywania po\u0142\u0105cze\u0144, ograniczam liczb\u0119 procedur uzgadniania i wyra\u017anie skracam czas odpowiedzi. Precyzyjnie dostosowane limity czasu, ograniczenia liczby \u017c\u0105da\u0144 na po\u0142\u0105czenie oraz ponowne wykorzystywanie gniazd upstream zapewniaj\u0105 wymierny wzrost wydajno\u015bci bez konieczno\u015bci zakupu nowego sprz\u0119tu.<\/p>\n\n<h2>Punkty centralne<\/h2>\n\n<ul>\n  <li><strong>Limity czasu<\/strong> Warto wybra\u0107 odpowiednie ustawienia: czas bezczynno\u015bci powinien by\u0107 tak kr\u00f3tki, jak to konieczne, i tak d\u0142ugi, jak to przydatne.<\/li>\n  <li><strong>\u017b\u0105dania<\/strong> Ograniczanie liczby po\u0142\u0105cze\u0144: trwa\u0142e gniazda, brak zawieszania si\u0119.<\/li>\n  <li><strong>Pule upstreamowe<\/strong> W\u0142\u0105cz: Sta\u0142e po\u0142\u0105czenia z backendem dla ka\u017cdego pracownika.<\/li>\n  <li><strong>Pracownik<\/strong> oraz dostosowa\u0107 po\u0142\u0105czenia: wystarczaj\u0105ca liczba slot\u00f3w dla klient\u00f3w w trybie bezczynno\u015bci i aktywnych.<\/li>\n  <li><strong>Monitoring<\/strong> Skonfigurowa\u0107: monitorowa\u0107 szybko\u015b\u0107 po\u0142\u0105czenia, op\u00f3\u017anienie i liczb\u0119 b\u0142\u0119d\u00f3w.<\/li>\n<\/ul>\n\n<h2>NGINX Keepalive: dzia\u0142anie i koszty<\/h2>\n\n<p>Celowo utrzymuj\u0119 otwarte po\u0142\u0105czenia TCP, poniewa\u017c <strong>U\u015bciski d\u0142oni<\/strong> s\u0105 kosztowne i dominuj\u0105 w przypadku wielu ma\u0142ych \u017c\u0105da\u0144. Trwa\u0142e gniazda nie tylko oszcz\u0119dzaj\u0105 RTT, ale tak\u017ce wyr\u00f3wnuj\u0105 obci\u0105\u017cenie procesora, poniewa\u017c kryptografia dla protoko\u0142u TLS uruchamia si\u0119 rzadziej. Ka\u017cde otwarte po\u0142\u0105czenie zajmuje jednak <strong>Zasoby<\/strong>, na przyk\u0142ad deskryptory plik\u00f3w i bufory, na kt\u00f3re musz\u0119 zwraca\u0107 uwag\u0119. Sztuka polega na znalezieniu odpowiedniej r\u00f3wnowagi: wystarczaj\u0105ca ilo\u015b\u0107 ponownego wykorzystania, by zapewni\u0107 szybko\u015b\u0107, oraz wystarczaj\u0105cy bud\u017cet na nowe po\u0142\u0105czenia w okresach szczytowego obci\u0105\u017cenia. Kto osi\u0105gnie t\u0119 r\u00f3wnowag\u0119, uzyska stale niskie warto\u015bci TTFB i zapewni u\u017cytkownikom wra\u017cenie szybko\u015bci dzia\u0142ania.<\/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 i HTTP\/3: multipleksowanie spotyka si\u0119 z keepalive<\/h2>\n\n<p>Z <strong>HTTP\/2<\/strong> oraz <strong>HTTP\/3<\/strong> zmniejsza si\u0119 liczba niezb\u0119dnych po\u0142\u0105cze\u0144 na klienta, poniewa\u017c przez jedno \u0142\u0105cze przep\u0142ywa kilka strumieni. Funkcja Keepalive pozostaje jednak istotna: jedno po\u0142\u0105czenie powinno pozostawa\u0107 niezawodnie otwarte, w przeciwnym razie korzy\u015b\u0107 wynikaj\u0105ca z multipleksowania zostanie zniwelowana przez cz\u0119ste ponowne nawi\u0105zywanie po\u0142\u0105cze\u0144.<\/p>\n<p>Zwracam uwag\u0119 na dedykowane parametry stanu bezczynno\u015bci dla nowoczesnych protoko\u0142\u00f3w i dbam o to, by warto\u015bci te by\u0142y dostosowane do limit\u00f3w czasu moich klient\u00f3w. Podczas test\u00f3w zaczynam od umiarkowanych warto\u015bci i zwi\u0119kszam je przy stabilnym obci\u0105\u017ceniu, a\u017c cz\u0119stotliwo\u015b\u0107 ponownego nawi\u0105zywania po\u0142\u0105cze\u0144 spadnie, a op\u00f3\u017anienia pozostan\u0105 na sta\u0142ym poziomie.<\/p>\n\n<pre><code>http {\n    # HTTP\/2: czas bezczynno\u015bci dla nieu\u017cywanych, ale otwartych strumieni\n    http2_idle_timeout 60s;\n\n    # HTTP\/3\/QUIC: podobna logika dla po\u0142\u0105cze\u0144 opartych na protokole UDP\n    http3_idle_timeout 60s;\n\n    # Wznowienie po\u0142\u0105czenia TLS zmniejsza koszty uzgadniania po\u0142\u0105czenia przy ponownym nawi\u0105zywaniu po\u0142\u0105cze\u0144\n    ssl_session_cache shared:SSL:50m;\n    ssl_session_timeout 1d;\n    ssl_session_tickets off;\n}\n<\/code><\/pre>\n\n<p>Multipleksowanie zmniejsza wymagan\u0105 liczb\u0119 r\u00f3wnoleg\u0142ych po\u0142\u0105cze\u0144 TCP\/QUIC, ale nie zmniejsza znaczenia <strong>prawid\u0142owe przerwy na \u017c\u0105danie<\/strong>. U\u017cytkownicy protoko\u0142\u00f3w HTTP\/2\/3 cz\u0119sto mog\u0105 ustawi\u0107 nieco d\u0142u\u017csze limity czasu po stronie klienta, poniewa\u017c wiele niewielkich zasob\u00f3w przep\u0142ywa przez ten sam kana\u0142. Wa\u017cne: nale\u017cy zachowa\u0107 mo\u017cliwo\u015b\u0107 pomiaru <em>Czas do pierwszego bajtu<\/em>, wska\u017aniki b\u0142\u0119d\u00f3w i otwarte strumienie dla ka\u017cdego po\u0142\u0105czenia.<\/p>\n\n<h2>Prawid\u0142owe skonfigurowanie funkcji Client-Keepalive<\/h2>\n\n<p>W przypadku klient\u00f3w przegl\u0105darkowych zarz\u0105dzam ponownym wykorzystaniem za pomoc\u0105 <strong>keepalive_timeout<\/strong> oraz <strong>keepalive_requests<\/strong>, aby gniazda dzia\u0142a\u0142y wystarczaj\u0105co d\u0142ugo, nie blokuj\u0105c si\u0119 w niesko\u0144czono\u015b\u0107. Na pocz\u0105tek ustawiam limit czasu na 30\u201360 sekund i 100\u2013300 \u017c\u0105da\u0144 na po\u0142\u0105czenie, a nast\u0119pnie dostosowuj\u0119 te warto\u015bci na podstawie wska\u017anik\u00f3w. Szczeg\u00f3\u0142owe wyja\u015bnienie mo\u017cna znale\u017a\u0107 w tym <a href=\"https:\/\/webhosting.de\/pl\/konfiguracja-wydajnosci-serwera-http-keepalive-timeout\/\">Przewodnik po limitach czasu keepalive<\/a>, kt\u00f3ry wyja\u015bnia wp\u0142yw na op\u00f3\u017anienia i zasoby serwera. Kr\u00f3tsze limity czasu sprawdzaj\u0105 si\u0119 w przypadku bardzo du\u017cej liczby kr\u00f3tkich wywo\u0142a\u0144, natomiast d\u0142u\u017csze pomagaj\u0105 przy okresowych dost\u0119pach do API. Na pocz\u0105tek ustalam jasne warto\u015bci domy\u015blne i mierz\u0119 wp\u0142yw na liczb\u0119 otwartych po\u0142\u0105cze\u0144 oraz rodzaje b\u0142\u0119d\u00f3w.<\/p>\n\n<pre><code>http {\n    # Po\u0142\u0105czenia w stanie bezczynno\u015bci z klientem\n    keepalive_timeout 60s;\n    # Maksymalna liczba \u017c\u0105da\u0144 na po\u0142\u0105czenie TCP\n    keepalive_requests 200;\n\n    # Opcjonalnie: wy\u0142\u0105czenie funkcji Keep-Alive dla okre\u015blonych klient\u00f3w (b\u0142\u0119dy starszych wersji)\n    # keepalive_disable msie6;\n}\n<\/code><\/pre>\n\n<h2>Funkcja Upstream-Keepalive w serwerze proxy odwrotnym<\/h2>\n\n<p>Pomi\u0119dzy NGINX a aplikacjami backendowymi korzystam z trwa\u0142ych gniazd upstream, poniewa\u017c nawi\u0105zanie po\u0142\u0105czenia z PHP-FPM, Node.js lub us\u0142ugami w j\u0119zyku Python r\u00f3wnie\u017c <strong>Op\u00f3\u017anienie<\/strong> kosztuje. W tym celu aktywuj\u0119 w puli upstream odpowiedni\u0105 liczb\u0119 po\u0142\u0105cze\u0144 wielokrotnego u\u017cytku na ka\u017cdego pracownika. Wa\u017cne jest, aby u\u017cywa\u0107 protoko\u0142u HTTP\/1.1 w kierunku serwera oraz pustego nag\u0142\u00f3wka Connection, w przeciwnym razie \u017c\u0105danie klienta \u201eclose\u201c przerwie trwa\u0142o\u015b\u0107 po\u0142\u0105czenia z backendem. Kieruj\u0119 si\u0119 liczb\u0105 jednoczesnych \u017c\u0105da\u0144 i konfiguruj\u0119 pul\u0119 tak, aby prawie nie powstawa\u0142y nowe po\u0142\u0105czenia. W ten spos\u00f3b skraca si\u0119 czas nawi\u0105zywania po\u0142\u0105czenia z backendem, a ca\u0142y \u0142a\u0144cuch zapewnia szybsze <strong>Odpowiedzi<\/strong>.<\/p>\n\n<pre><code>upstream backend {\n    server 127.0.0.1:9000;\n    keepalive 64; # Liczba trwa\u0142ych po\u0142\u0105cze\u0144 upstream na ka\u017cdy worker\n}\n\nserver {\n    location \/ {\n proxy_pass http:\/\/backend;\n        proxy_http_version 1.1;\n proxy_set_header Connection \"\";\n # Utrzymywanie po\u0142\u0105cze\u0144 TCP dla gniazd upstream na poziomie systemu operacyjnego\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>Wymiarowanie basenu i bud\u017cet na po\u0142\u0105czenia<\/h2>\n\n<p>Obliczam puli w spos\u00f3b realistyczny: liczba trwa\u0142ych po\u0142\u0105cze\u0144 upstream wynika z <strong>worker_processes \u00d7 keepalive<\/strong> na ka\u017cdy upstream. Je\u015bli u\u017cywa si\u0119 8 proces\u00f3w roboczych i warto\u015bci keepalive wynosz\u0105cej 64, otwarte pozostaje do 512 gniazd na ka\u017cdy upstream \u2013 na ka\u017cd\u0105 instancj\u0119. W przypadku korzystania z modu\u0142u r\u00f3wnowa\u017cenia obci\u0105\u017cenia lub przy wi\u0119kszej liczbie cel\u00f3w upstream liczba ta mo\u017ce szybko wzrosn\u0105\u0107.<\/p>\n<p>Moja docelowa warto\u015b\u0107: wystarczaj\u0105ca liczba otwartych gniazd, aby wi\u0119kszo\u015b\u0107 \u017c\u0105da\u0144 <em>bez nowego Connect<\/em> jest obs\u0142ugiwany, ale pozostaje jeszcze margines na obs\u0142ug\u0119 szczyt\u00f3w. Monitoruj\u0119 wska\u017anik \u201enowe po\u0142\u0105czenia wychodz\u0105ce na sekund\u0119\u201c i zmniejszam go, a\u017c dalsze zwi\u0119kszanie rozmiaru puli nie przyniesie ju\u017c znacz\u0105cej poprawy op\u00f3\u017anienia.<\/p>\n<p>Bior\u0119 r\u00f3wnie\u017c pod uwag\u0119 <strong>Sprawiedliwo\u015b\u0107<\/strong>: Zbyt du\u017ce pule mog\u0105 stawia\u0107 nowo przyby\u0142ych klient\u00f3w w niekorzystnej sytuacji, poniewa\u017c sloty pracownik\u00f3w zajmuj\u0105 nieaktywne po\u0142\u0105czenia. Umiarkowany limit po\u0142\u0105czony z aktywnym monitorowaniem zazwyczaj dzia\u0142a szybciej ni\u017c warto\u015bci maksymalne ustalane na chybi\u0142 trafi\u0142.<\/p>\n\n<h2>Dostrajanie: limity czasu i limity \u017c\u0105da\u0144<\/h2>\n\n<p>\u0141\u0105cz\u0119 limit czasu i limit \u017c\u0105da\u0144 w taki spos\u00f3b, aby po\u0142\u0105czenia by\u0142y efektywnie ponownie wykorzystywane, bez <strong>Narciarz biegowy<\/strong> . Wysokie warto\u015bci na obu osiach minimalizuj\u0105 liczb\u0119 po\u0142\u0105cze\u0144 typu \u201eConnect\u201d, ale zwi\u0119kszaj\u0105 ryzyko zawieszania si\u0119 gniazd w przypadku problem\u00f3w z sieci\u0105. Niskie warto\u015bci zapewniaj\u0105 \u015bwie\u017ce po\u0142\u0105czenia, ale wymagaj\u0105 dodatkowych procedur uzgadniania. Post\u0119puj\u0119 ma\u0142ymi krokami, obserwuj\u0119 b\u0142\u0119dy i dostosowuj\u0119 ustawienia w okre\u015blonych odst\u0119pach czasu. Poni\u017csza tabela przedstawia sensowne przedzia\u0142y warto\u015bci pocz\u0105tkowych dla r\u00f3\u017cnych wzorc\u00f3w u\u017cytkowania i dostarcza zwi\u0119z\u0142\u0105 <strong>Orientacja<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Scenariusz<\/th>\n      <th>keepalive_timeout<\/th>\n      <th>keepalive_requests<\/th>\n      <th>Wskaz\u00f3wka<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Wiele kr\u00f3tkich ods\u0142on stron<\/td>\n      <td>10\u201330 s<\/td>\n      <td>100-300<\/td>\n      <td>Szybkie ponowne wykorzystanie, niewielkie obci\u0105\u017cenie w stanie bezczynno\u015bci<\/td>\n    <\/tr>\n    <tr>\n      <td>Typowa strona internetowa<\/td>\n      <td>60\u2013120 s<\/td>\n      <td>200\u2013400<\/td>\n      <td>Dobry poziom \u015bredni dla plik\u00f3w Assets i HTML<\/td>\n    <\/tr>\n    <tr>\n      <td>API z okresowymi wywo\u0142aniami<\/td>\n      <td>60\u2013120 s<\/td>\n      <td>300\u20131000<\/td>\n      <td>Wy\u017cszy wska\u017anik ponownego wykorzystania w\u015br\u00f3d klient\u00f3w<\/td>\n    <\/tr>\n    <tr>\n      <td>Us\u0142ugi wewn\u0119trzne \/ bramy<\/td>\n      <td>30\u201390 s<\/td>\n      <td>500\u20131000+<\/td>\n      <td>Sta\u0142o\u015b\u0107 jest wa\u017cniejsza ni\u017c minimalna liczba po\u0142\u0105cze\u0144<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Optymalizacja pracownik\u00f3w i powi\u0105zania<\/h2>\n\n<p>W\u0142o\u017cy\u0142em <strong>worker_processes<\/strong> na \u201eauto\u201d lub na liczb\u0119 rdzeni procesora i zaplanuj wystarczaj\u0105c\u0105 ilo\u015b\u0107 <strong>worker_connections<\/strong> poniewa\u017c gniazda w stanie bezczynno\u015bci zajmuj\u0105 sloty. Zbyt niskie limity uniemo\u017cliwiaj\u0105 przyjmowanie nowych po\u0142\u0105cze\u0144, mimo \u017ce procesor dysponuje jeszcze woln\u0105 moc\u0105 obliczeniow\u0105. Kto korzysta z du\u017cych pul keepalive, potrzebuje wystarczaj\u0105cej liczby deskryptor\u00f3w i slot\u00f3w zdarze\u0144 na ka\u017cdego pracownika. Dobrym wprowadzeniem do tematu jest \u201e<a href=\"https:\/\/webhosting.de\/pl\/nginx-skalowanie-polaczen-workerow-obsluga-tysiecy-zadan-zwiekszenie-przepustowosci-ruchu\/\">Skalowanie po\u0142\u0105cze\u0144 pracownik\u00f3w<\/a>\u201c, kt\u00f3ra wyja\u015bnia powi\u0105zania mi\u0119dzy zdarzeniami, po\u0142\u0105czeniami i obci\u0105\u017ceniem. Przemy\u015blane warto\u015bci gwarantuj\u0105, \u017ce ponowne wykorzystanie w stanie bezczynno\u015bci i nowe po\u0142\u0105czenia mog\u0105 funkcjonowa\u0107 r\u00f3wnolegle.<\/p>\n\n<pre><code>worker_processes auto;\n\nevents {\n    worker_connections 4096;\n    # Opcjonalnie: reuseport mo\u017ce poprawi\u0107 rozk\u0142ad obci\u0105\u017cenia na poziomie j\u0105dra\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>Optymalizacja systemu operacyjnego i gniazd<\/h2>\n\n<p>Sprawdzam ograniczenia systemowe, aby funkcja Keepalive mog\u0142a w pe\u0142ni wykorzysta\u0107 sw\u00f3j potencja\u0142. Zbyt ma\u0142a liczba deskryptor\u00f3w lub przepe\u0142nione kolejki gniazd powoduj\u0105 <strong>sztuczne w\u0105skie gard\u0142a<\/strong>. Opr\u00f3cz ulimit i worker_rlimit_nofile decyduj\u0105ce znaczenie maj\u0105 ograniczenia j\u0105dra.<\/p>\n\n<pre><code># Przyk\u0142adowe warto\u015bci sysctl (nale\u017cy dostosowywa\u0107 je ostro\u017cnie i po przeprowadzeniu test\u00f3w)\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>Dostosowuj\u0119 te warto\u015bci do warunk\u00f3w otoczenia: wiele po\u0142\u0105cze\u0144 kr\u00f3tkotrwa\u0142ych zyskuje na szerszym zakresie port\u00f3w i kr\u00f3tszych czasach trwania stan\u00f3w FIN i TIME_WAIT. W przypadku keepalive\u2019u w kierunku upstream zmniejszam <em>Neuconnects<\/em>, co powoduje zmniejszenie obci\u0105\u017ce\u0144 zwi\u0105zanych z faz\u0105 TIME_WAIT. Ponadto bior\u0119 pod uwag\u0119 <strong>NAT<\/strong>-Urz\u0105dzenia pomi\u0119dzy serwerem proxy a serwerem zaplecza: Zbyt agresywne limity czasu bezczynno\u015bci w sieci powoduj\u0105 nieprzewidywalne roz\u0142\u0105czanie po\u0142\u0105cze\u0144. Umiarkowany limit \u017c\u0105da\u0144 na gniazdo oraz mechanizmy utrzymywania po\u0142\u0105cze\u0144 TCP (<code>proxy_socket_keepalive on;<\/code>) zapobiegaj\u0105 \u201estarym\u201c po\u0142\u0105czeniom.<\/p>\n\n<h2>Prawid\u0142owe ustawienie nag\u0142\u00f3wka i wersji HTTP<\/h2>\n\n<p>Zwracam uwag\u0119 na <strong>HTTP\/1.1<\/strong> do backendu, poniewa\u017c funkcja Upstream-Keepalive dzia\u0142a tylko w ten spos\u00f3b. Ponadto usuwam aktywne sterowanie po\u0142\u0105czeniami za pomoc\u0105 nag\u0142\u00f3wk\u00f3w, aby NGINX samodzielnie zarz\u0105dza\u0142 trwa\u0142o\u015bci\u0105 po\u0142\u0105cze\u0144. Po stronie klienta pozwalam, aby funkcja Keep-Alive dzia\u0142a\u0142a zgodnie ze standardem i ograniczam czas \u017cycia po\u0142\u0105cze\u0144 za pomoc\u0105 limitu czasu (timeout) oraz limitu \u017c\u0105da\u0144 (request-limit). Dodatkowo sprawdzam limity czasu bezczynno\u015bci serwer\u00f3w backendowych (backend-idle-timeouts) i ustawiam je na warto\u015b\u0107 minimalnie wy\u017csz\u0105 ni\u017c w NGINX, aby unikn\u0105\u0107 b\u0142\u0119d\u00f3w resetowania. Poprawnie skonfigurowane nag\u0142\u00f3wki zapewniaj\u0105 <strong>Ponowne u\u017cycie<\/strong> bez niepo\u017c\u0105danych zamkni\u0119\u0107.<\/p>\n\n<pre><code># Przyk\u0142ad: Lokalizacja proxy z poprawnymi nag\u0142\u00f3wkami\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>R\u00f3\u017cnica: HTTP Keep-Alive a TCP Keep-Alive<\/h2>\n\n<p>Dokonuj\u0119 \u015bcis\u0142ego rozr\u00f3\u017cnienia mi\u0119dzy <strong>HTTP Keep-Alive<\/strong> (kilka \u017c\u0105da\u0144 HTTP na jedno po\u0142\u0105czenie) oraz <strong>TCP-Keepalive<\/strong> (Testy na poziomie systemu operacyjnego w celu wykrycia nieaktywnych punkt\u00f3w ko\u0144cowych). Funkcj\u0119 HTTP Keep-Alive kontroluj\u0119 za pomoc\u0105 <code>keepalive_timeout<\/code> oraz <code>keepalive_requests<\/code>, podczas gdy komunikaty TCP Keepalive, w zale\u017cno\u015bci od stosu, wynosz\u0105 <code>proxy_socket_keepalive on;<\/code> oraz parametry systemowe. W przypadku serwer\u00f3w dzia\u0142aj\u0105cych w niestabilnych sieciach w\u0142\u0105czam funkcj\u0119 TCP-Keepalive, aby szybciej usuwa\u0107 zawieszone gniazda.<\/p>\n\n<h2>Procesy d\u0142ugotrwa\u0142e i przypadki szczeg\u00f3lne: WebSockets, SSE, gRPC<\/h2>\n\n<p>WebSockets i zdarzenia wysy\u0142ane przez serwer s\u0105 <strong>Narciarz biegowy<\/strong>, kt\u00f3re utrzymuj\u0105 po\u0142\u0105czenie przez d\u0142ugi czas \u2013 w tym przypadku klasyczna metoda Reuse odgrywa drugorz\u0119dn\u0105 rol\u0119. Dbam o odpowiednie <code>proxy_read_timeout<\/code> i chro\u0144 mnie za pomoc\u0105 <code>send_timeout<\/code> przeciwko <em>Slowloris<\/em>-efekty. W przypadku gRPC (opartego na HTTP\/2) nale\u017cy uwzgl\u0119dni\u0107 kwestie zwi\u0105zane z multipleksowaniem; limity czasu bezczynno\u015bci ustalam tak, aby strumienie nie by\u0142y niepotrzebnie przerywane.<\/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>Monitorowanie i wska\u017aniki<\/h2>\n\n<p>Sukces oceniam na podstawie wska\u017anik\u00f3w, takich jak odsetek nowych po\u0142\u0105cze\u0144 typu upstream, <strong>upstream_connect_time<\/strong> oraz odsetek otwartych po\u0142\u0105cze\u0144 na jednego pracownika. Spadaj\u0105ce wska\u017aniki po\u0142\u0105cze\u0144 przy sta\u0142ej lub rosn\u0105cej liczbie \u017c\u0105da\u0144 wskazuj\u0105 na skuteczne ponowne wykorzystanie po\u0142\u0105cze\u0144. Nietypowe przekroczenia limit\u00f3w czasu lub resetowanie po\u0142\u0105cze\u0144 sygnalizuj\u0105 rozbie\u017cno\u015bci w limitach czasu mi\u0119dzy NGINX a zapleczem. Ponadto obserwuj\u0119 pami\u0119\u0107, deskryptory plik\u00f3w i kolejki zdarze\u0144 pod obci\u0105\u017ceniem. Regularne sprawdzanie pozwala wcze\u015bnie wykrywa\u0107 trendy i zapobiega kosztownym <strong>Awarie<\/strong>.<\/p>\n\n<h2>Ulepszenia w zakresie rejestrowania w celu zapewnienia przejrzysto\u015bci ponownego wykorzystania<\/h2>\n\n<p>Aby uzyska\u0107 lepszy wgl\u0105d w dane, rozszerzam dziennik dost\u0119pu o szczeg\u00f3\u0142y po\u0142\u0105cze\u0144. Dzi\u0119ki temu mog\u0119 sprawdzi\u0107, jak cz\u0119sto ponownie wykorzystywane jest dane po\u0142\u0105czenie TCP oraz jak zmieniaj\u0105 si\u0119 czasy nawi\u0105zywania po\u0142\u0105cze\u0144.<\/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>Obserwuj\u0119 warto\u015bci mediany oraz P95\/P99 wynosz\u0105ce <em>upstream_connect_time<\/em> oraz podzia\u0142 <em>$_\u017c\u0105dania_po\u0142\u0105cze\u0144<\/em>. Rosn\u0105ce liczby ponownych pr\u00f3b przy stabilnym op\u00f3\u017anieniu oznaczaj\u0105, \u017ce pule i limity czasu zosta\u0142y odpowiednio dobrane.<\/p>\n\n<h2>Typowe przeszkody i rozwi\u0105zania<\/h2>\n\n<p>Zbyt du\u017ce pule zajmuj\u0105 gniazda po\u0142\u0105cze\u0144, podczas gdy nowi klienci czekaj\u0105, dlatego utrzymuj\u0119 ich rozmiary na umiarkowanym poziomie i monitoruj\u0119 je. R\u00f3\u017cnice w czasach wyga\u015bni\u0119cia bezczynno\u015bci mi\u0119dzy serwerem proxy a serwerem zaplecza powoduj\u0105 resetowanie, wi\u0119c ustawiam czas wyga\u015bni\u0119cia na serwerze zaplecza na minimalnie wy\u017cszy ni\u017c <strong>NGINX<\/strong>. Zapomniane \u201eConnection: close\u201c w nag\u0142\u00f3wku proxy przerywa trwa\u0142o\u015b\u0107 po\u0142\u0105czenia, dlatego konsekwentnie czyszcz\u0119 ten nag\u0142\u00f3wek. Negocjacja TLS mo\u017ce obci\u0105\u017ca\u0107 procesor przy du\u017cej liczbie nowych po\u0142\u0105cze\u0144, co \u0142agodz\u0119 poprzez zwi\u0119kszenie udzia\u0142u ponownego wykorzystania. W przypadku sporadycznych b\u0142\u0119d\u00f3w sieciowych pomocne jest umiarkowane ograniczenie liczby \u017c\u0105da\u0144 na gniazdo, dzi\u0119ki czemu stare <strong>Sesje<\/strong> nie \u017cy\u0107 wiecznie.<\/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>Konfiguracje dostosowane do praktyki<\/h2>\n\n<p>W przypadku stron internetowych o du\u017cym nat\u0119\u017ceniu ruchu wybieram kr\u00f3tki czas oczekiwania i \u015brednio wysoki limit \u017c\u0105da\u0144, aby zasoby dzia\u0142a\u0142y wydajnie. W przypadku interfejs\u00f3w API z powtarzaj\u0105cymi si\u0119 wywo\u0142aniami zwi\u0119kszam ten limit, aby jeszcze bardziej skr\u00f3ci\u0107 czas uzgadniania po\u0142\u0105cze\u0144 TCP i TLS. Wielko\u015b\u0107 pul upstreamowych dobieram na podstawie przewidywanej r\u00f3wnoleg\u0142o\u015bci i testuj\u0119 przy u\u017cyciu realistycznego ruchu. Ka\u017cde \u015brodowisko zachowuje si\u0119 inaczej, dlatego po wprowadzeniu zmian sprawdzam op\u00f3\u017anienia i profile b\u0142\u0119d\u00f3w. Oto dwa przyk\u0142ady: <strong>Warto\u015bci pocz\u0105tkowe<\/strong>, kt\u00f3re nast\u0119pnie dopracowuj\u0119 za pomoc\u0105 wska\u017anik\u00f3w.<\/p>\n\n<pre><code># Scenariusz 1: Strona internetowa o du\u017cym nat\u0119\u017ceniu ruchu\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 Monitorowanie czasu bezczynno\u015bci HTTP\/2 w trybie #\n http2_idle_timeout 45s;\n    }\n}\n<\/code><\/pre>\n\n<pre><code># Scenariusz 2: API z okresowymi wywo\u0142aniami\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 # Nieco d\u0142u\u017csze okno bezczynno\u015bci dla powtarzaj\u0105cych si\u0119 wywo\u0142a\u0144\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>Lista kontrolna dotycz\u0105ca optymalizacji iteracyjnej<\/h2>\n\n<p>Zaczn\u0119 od analizy obecnej sytuacji: rytm wyznaczaj\u0105 wzorce ruchu, czasy odpowiedzi i wska\u017anik b\u0142\u0119d\u00f3w. Nast\u0119pnie ustawiam limit czasu klienta i limit \u017c\u0105da\u0144 na rozs\u0105dne warto\u015bci pocz\u0105tkowe oraz aktywuj\u0119 pule upstream. Limity czasu bezczynno\u015bci backendu ustawiam nieco wy\u017cej ni\u017c w NGINX, aby unikn\u0105\u0107 nieoczekiwanych <strong>Resety<\/strong> wyst\u0119puj\u0105. Nast\u0119pnie monitoruj\u0119 liczb\u0119 po\u0142\u0105cze\u0144, czas po\u0142\u0105czenia oraz liczb\u0119 otwartych gniazd na ka\u017cdego pracownika. Osoby, kt\u00f3re chc\u0105 zg\u0142\u0119bi\u0107 temat stopnia ponownego wykorzystania, znajd\u0105 wskaz\u00f3wki dotycz\u0105ce <a href=\"https:\/\/webhosting.de\/pl\/http-connection-reuse-keepalive-optymalizacja-serverperf-boost\/\">Ponowne u\u017cycie po\u0142\u0105czenia<\/a> oraz rozs\u0105dne pu\u0142apy.<\/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>Dodatkowa diagnoza: niedopasowania i zachowanie czasowe<\/h2>\n\n<p>Gdy po\u0142\u0105czenia zrywaj\u0105 si\u0119 pozornie \u201ebez powodu\u201c, szukam <strong>Niedopasowania<\/strong> w \u0142a\u0144cuchu: bezczynno\u015b\u0107 klienta vs. limit czasu NGINX vs. bezczynno\u015b\u0107 serwera zaplecza oraz po\u015brednicz\u0105ce urz\u0105dzenia NAT\/bramy. Nieznacznie zwi\u0119kszam limit czasu serwera zaplecza powy\u017cej warto\u015bci NGINX, sprawdzam kody resetowania w dzienniku b\u0142\u0119d\u00f3w i obserwuj\u0119, czy <em>upstream_connect_time<\/em> Wykazuje skoki. Cz\u0119sto wystarczy niewielki bufor (np. +10\u201320%) w przypadku przekroczenia limitu czasu po stronie serwera, aby wyeliminowa\u0107 resetowanie.<\/p>\n<p>Zwracam r\u00f3wnie\u017c uwag\u0119 na \u201e<em>uj\u0119cie zbli\u017caj\u0105ce si\u0119 powoli<\/em>\u201cFazy -: Podczas zamykania NGINX na kr\u00f3tko przepuszcza przychodz\u0105ce dane, co anga\u017cuje zasoby proces\u00f3w roboczych. Bardzo du\u017ca liczba jednoczesnych zamkni\u0119\u0107 mo\u017ce blokowa\u0107 zdarzenia. W takich przypadkach dostosowuj\u0119 przedzia\u0142y czasowe zamykania i utrzymuj\u0119 w r\u00f3wnowadze ca\u0142kowit\u0105 liczb\u0119 otwartych po\u0142\u0105cze\u0144 poprzez odpowiednie warto\u015bci keepalive.<\/p>\n\n<h2>Podsumowanie: Keepalive jako czynnik wp\u0142ywaj\u0105cy na wydajno\u015b\u0107<\/h2>\n\n<p>Celowo stosuj\u0119 Keepalive, poniewa\u017c obni\u017ca to koszty nawi\u0105zywania po\u0142\u0105cze\u0144, zmniejsza op\u00f3\u017anienia i odci\u0105\u017ca procesor. Po\u0142\u0105czenie odpowiedniego limitu czasu, w\u0142a\u015bciwego limitu \u017c\u0105da\u0144 i odpowiednich pul upstream zapewnia zauwa\u017calne <strong>Pr\u0119dko\u015b\u0107<\/strong>. Bez monitorowania potencja\u0142 pozostaje niewykorzystany, dlatego na bie\u017c\u0105co sprawdzam wska\u017aniki i stopniowo dostosowuj\u0119 warto\u015bci. Kto potrzebuje dodatkowych rezerw, powinien zwr\u00f3ci\u0107 uwag\u0119 na liczb\u0119 worker\u00f3w, sloty po\u0142\u0105cze\u0144 i prawid\u0142owe przetwarzanie nag\u0142\u00f3wk\u00f3w. Profesjonalne konfiguracje, na przyk\u0142ad w przypadku <strong>webhoster.de<\/strong>, w pe\u0142ni wykorzystuj\u0105 te mo\u017cliwo\u015bci i zapewniaj\u0105 szybkie, niezawodne us\u0142ugi.<\/p>","protected":false},"excerpt":{"rendered":"<p>Dowiedz si\u0119, jak zoptymalizowa\u0107 \u017c\u0105dania keepalive w NGINX, aby znacznie zwi\u0119kszy\u0107 wydajno\u015b\u0107 serwer\u00f3w WWW. Dzi\u0119ki praktycznym ustawieniom parametr\u00f3w keepalive_timeout, keepalive_requests, Upstream-Keepalive oraz dostosowaniu worker\u00f3w \u2013 z naciskiem na keepalive w NGINX jako kluczowy element regulacji.<\/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":"109","_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\/pl\/wp-json\/wp\/v2\/posts\/21459","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/comments?post=21459"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/21459\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media\/21452"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media?parent=21459"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/categories?post=21459"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/tags?post=21459"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}