{"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":"optymalna-konfiguracja-keepalive-w-nginx-dla-upstreamu-proxy-odwrotne-siec","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pl\/nginx-upstream-keepalive-optimal-konfigurieren-reverse-proxy-netzwerk\/","title":{"rendered":"Optymalna konfiguracja funkcji \u201eUpstream Keepalive\u201d w NGINX w celu uzyskania maksymalnej wydajno\u015bci jako serwer proxy odwrotny"},"content":{"rendered":"<p>Konfiguruj\u0119 funkcj\u0119 \u201eUpstream Keepalive\u201d w NGINX tak, aby serwer proxy odwrotny nawi\u0105zywa\u0142 mniej po\u0142\u0105cze\u0144, zapewnia\u0142 mniejsze op\u00f3\u017anienia i niezawodnie radzi\u0142 sobie ze szczytami obci\u0105\u017cenia. W tym celu dostosowuj\u0119 <strong>Wielko\u015b\u0107 basenu<\/strong>, limity czasowe i nag\u0142\u00f3wki w spos\u00f3b ukierunkowany, tak aby po\u0142\u0105czenia by\u0142y ponownie wykorzystywane, a \u015bcie\u017cka danych pozostawa\u0142a zoptymalizowana.<\/p>\n\n<h2>Punkty centralne<\/h2>\n\n<ul>\n  <li><strong>HTTP\/1.1<\/strong> wymusi\u0107 i oczy\u015bci\u0107 nag\u0142\u00f3wki po\u0142\u0105czenia<\/li>\n  <li><strong>keepalive<\/strong> Dopasowa\u0107 rozmiar do ka\u017cdego pracownika<\/li>\n  <li><strong>Limity czasu<\/strong> dostosowa\u0107 do warto\u015bci backendu<\/li>\n  <li><strong>\u017b\u0105dania\/Po\u0142\u0105czenie<\/strong> ogranicza\u0107 i poddawa\u0107 recyklingowi<\/li>\n  <li><strong>Monitoring<\/strong> w odniesieniu do szybko\u015bci po\u0142\u0105czenia i op\u00f3\u017anienia<\/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>Dlaczego funkcja Upstream Keepalive radykalnie zmniejsza obci\u0105\u017cenie zwi\u0105zane z nawi\u0105zywaniem po\u0142\u0105cze\u0144<\/h2>\n\n<p>Bez ponownego wykorzystania NGINX otwiera nowe po\u0142\u0105czenie z backendem dla ka\u017cdego \u017c\u0105dania, co wi\u0105\u017ce si\u0119 z dodatkowymi procedurami uzgadniania po\u0142\u0105czenia, wi\u0119kszym zu\u017cyciem cykli procesora oraz dodatkowymi zasobami j\u0105dra; w\u0142a\u015bnie w tym miejscu wkracza <strong>Keepalive<\/strong> . Ustawiam NGINX tak, aby buforowa\u0142 ju\u017c utworzone, obecnie nieaktywne gniazda i wykorzystywa\u0142 je do kolejnych \u017c\u0105da\u0144, co w wymierny spos\u00f3b skraca czas nawi\u0105zywania po\u0142\u0105cze\u0144. Zmniejsza to liczb\u0119 po\u0142\u0105cze\u0144 na sekund\u0119, ogranicza szczyty zaleg\u0142o\u015bci i spowalnia zmiany kontekstu w systemie operacyjnym. Szczeg\u00f3lnie w przypadku po\u0142\u0105cze\u0144 TLS z backendem odczuwalnie oszcz\u0119dzam czas dzi\u0119ki ponownemu wykorzystaniu sesji. Dzi\u0119ki temu \u0142a\u0144cuch odpowiedzi pozostaje stabilny nawet przy wysokiej przepustowo\u015bci <strong>niezawodny<\/strong> i dzia\u0142a p\u0142ynnie.<\/p>\n\n<h2>Podstawowa zasada i dyrektywa \u201ekeepalive\u201d w upstreemie<\/h2>\n\n<p>Dyrektywa <strong>keepalive<\/strong> W bloku upstream ogranicza liczb\u0119 buforowanych, nieaktywnych po\u0142\u0105cze\u0144 z serwerem backendowym na ka\u017cdy proces roboczy. Limit ten nie ma charakteru globalnego, lecz dotyczy \u015bci\u015ble ka\u017cdego procesu roboczego, dlatego zawsze zwracam uwag\u0119 na liczb\u0119 proces\u00f3w roboczych. Gdy pula jest pe\u0142na, NGINX zamyka najpierw po\u0142\u0105czenie pozostaj\u0105ce bezczynne najd\u0142u\u017cej, aby zwolni\u0107 miejsce dla nowych gniazd. Aby umo\u017cliwi\u0107 ponowne wykorzystanie, strona proxy wymaga protoko\u0142u HTTP\/1.1 oraz zneutralizowanego nag\u0142\u00f3wka Connection. Bez tych warunk\u00f3w pula pozostaje pusta, mimo \u017ce w ustawieniach upstream ustawi\u0142em opcj\u0119 \u201ekeepalive\u201c, co wielu administrator\u00f3w <strong>na pocz\u0105tku<\/strong> zaskoczony.<\/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; # po\u0142\u0105cze\u0144 bezczynnych na pracownika\n    keepalive_requests 1000;   # recykling po N \u017c\u0105daniach\n    keepalive_timeout 60s;     # czas trwania bezczynno\u015bci\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>Wymagane dyrektywy w bloku \u201eLocation\u201d: HTTP\/1.1 i kontrola nag\u0142\u00f3wk\u00f3w<\/h2>\n\n<p>W \u015bcie\u017cce proxy wymuszam na NGINX u\u017cycie protoko\u0142u HTTP\/1.1, poniewa\u017c funkcja Keepalive nie dzia\u0142a poprawnie z protoko\u0142em HTTP\/1.0, co powoduje niepotrzebne roz\u0142\u0105czanie po\u0142\u0105cze\u0144; dyrektywa <strong>proxy_http_version<\/strong> W zwi\u0105zku z tym 1.1 jest obowi\u0105zkowe. Dodatkowo usuwam nag\u0142\u00f3wek \u201eConnection\u201c z typowych \u017c\u0105da\u0144, aby backend nie otrzymywa\u0142 polecenia \u201eclose\u201c. W przypadku aktualizacji, takich jak WebSockets, za pomoc\u0105 mapy celowo ustawiam \u201eConnection: Upgrade\u201d, nie zak\u0142\u00f3caj\u0105c przy tym normalnego ponownego wykorzystania. Dzi\u0119ki temu polityka po\u0142\u0105cze\u0144 pozostaje sp\u00f3jna i niezale\u017cna od nag\u0142\u00f3wk\u00f3w klienta. W\u0142a\u015bnie ta niewielka zmiana zapobiega wielu trudnym do uchwycenia <strong>Obrazy b\u0142\u0119d\u00f3w<\/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>Precyzyjna regulacja: w\u0142a\u015bciwy dob\u00f3r warto\u015bci keepalive_requests i keepalive_timeout<\/h2>\n\n<p>Za pomoc\u0105 dw\u00f3ch \u015brub regulacyjnych kontroluj\u0119 trwa\u0142o\u015b\u0107 i odnawianie po\u0142\u0105cze\u0144, aby basen pozostawa\u0142 w dobrym stanie i nie przeszkadza\u0142y \u017cadne opuszczone gniazda; s\u0105 to <strong>keepalive_requests<\/strong> oraz keepalive_timeout. Po N \u017c\u0105daniach NGINX celowo zamyka po\u0142\u0105czenie i w razie potrzeby nawi\u0105zuje je ponownie, co \u0142agodzi skutki starzenia si\u0119 sieci. Limit czasu bezczynno\u015bci ustalam raczej na niskim poziomie, zazwyczaj mi\u0119dzy 30 a 120 sekund, aby serwery backendowe nie przerywa\u0142y po\u0142\u0105czenia przedwcze\u015bnie. Wa\u017cne jest odpowiednie dostrojenie: warto\u015b\u0107 w NGINX nigdy nie mo\u017ce przekracza\u0107 limitu czasu serwer\u00f3w aplikacji, w przeciwnym razie b\u0119dzie dochodzi\u0142o do cz\u0119stych reset\u00f3w po\u0142\u0105cze\u0144. Osoby pragn\u0105ce pog\u0142\u0119bi\u0107 swoj\u0105 wiedz\u0119 na ten temat znajd\u0105 praktyczne wskaz\u00f3wki w artykule <a href=\"https:\/\/webhosting.de\/pl\/konfiguracja-wydajnosci-serwera-http-keepalive-timeout\/\">Limit czasu keepalive<\/a>, kt\u00f3ry wyja\u015bnia typowe warto\u015bci i zale\u017cno\u015bci.<\/p>\n\n<p>Aby u\u0142atwi\u0107 orientacj\u0119, przedstawiam typowe warto\u015bci pocz\u0105tkowe wraz z ich przeznaczeniem w przejrzystej <strong>Tabela<\/strong>. Warto\u015bci orientacyjne s\u0142u\u017c\u0105 jako punkt wyj\u015bcia i po monitorowaniu cz\u0119sto okazuj\u0105 si\u0119 nieco wy\u017csze lub ni\u017csze. Zbyt kr\u00f3tki okres powoduje niepotrzebne ponowne tworzenie po\u0142\u0105cze\u0144, natomiast zbyt d\u0142ugi utrzymuje stare po\u0142\u0105czenia. Liczba \u017c\u0105da\u0144 na po\u0142\u0105czenie chroni mnie przed warto\u015bciami odstaj\u0105cymi, nie opr\u00f3\u017cniaj\u0105c przy tym puli. Dzi\u0119ki tym kluczowym danym bardzo szybko podejmuj\u0119 skuteczne <strong>Ustawienia domy\u015blne<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametry<\/th>\n      <th>Cel<\/th>\n      <th>warto\u015b\u0107 orientacyjna<\/th>\n      <th>Wskaz\u00f3wka dotycz\u0105ca tuningu<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>keepalive<\/td>\n      <td>Rozmiar puli stan\u00f3w bezczynno\u015bci na jednego pracownika<\/td>\n      <td>32-64<\/td>\n      <td>Dostosowa\u0107 do r\u00f3wnoczesnego obci\u0105\u017cenia na pracownika<\/td>\n    <\/tr>\n    <tr>\n      <td>keepalive_requests<\/td>\n      <td>Maksymalna liczba \u017c\u0105da\u0144 na po\u0142\u0105czenie<\/td>\n      <td>500\u20131000<\/td>\n      <td>W przypadku d\u0142ugich transmisji nale\u017cy ustawi\u0107 nieco wy\u017csz\u0105 warto\u015b\u0107<\/td>\n    <\/tr>\n    <tr>\n      <td>keepalive_timeout<\/td>\n      <td>Maksymalny czas bezczynno\u015bci na po\u0142\u0105czenie<\/td>\n      <td>lata 60.<\/td>\n      <td>Kr\u00f3tszy lub taki sam czas wyga\u015bni\u0119cia bezczynno\u015bci backendu<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Okre\u015blenie wielko\u015bci puli na podstawie liczby jednoczesnych po\u0142\u0105cze\u0144<\/h2>\n\n<p>Wielko\u015b\u0107 puli nie wybieram na podstawie liczby \u017c\u0105da\u0144 na sekund\u0119, lecz na podstawie <strong>Wsp\u00f3\u0142bie\u017cno\u015b\u0107<\/strong> na pracownika. Najpierw obliczam \u015bredni\u0105 i maksymaln\u0105 liczb\u0119 r\u00f3wnoleg\u0142ych \u017c\u0105da\u0144 do backendu. Nast\u0119pnie dziel\u0119 te liczby przez liczb\u0119 pracownik\u00f3w NGINX i zaokr\u0105glam w g\u00f3r\u0119. Przy 200 r\u00f3wnoczesnych \u017c\u0105daniach i czterech procesach pracowniczych otrzymuj\u0119 wynik oko\u0142o 50 na proces, co oznacza, \u017ce warto\u015b\u0107 pocz\u0105tkowa keepalive 64 jest odpowiednia. W ten spos\u00f3b zapewniam dost\u0119pno\u015b\u0107 gniazd bez niepotrzebnego otwierania zbyt wielu <strong>Po\u0142\u0105czenia<\/strong> wi\u0105za\u0107.<\/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>\u015awiadome wykorzystywanie szczeg\u00f3lnych cech nowszych wersji NGINX<\/h2>\n\n<p>Najnowsze wersje cz\u0119sto domy\u015blnie zezwalaj\u0105 na ponowne wykorzystanie, ale nak\u0142adaj\u0105 raczej konserwatywne ograniczenia; mimo to wpisuj\u0119 te warto\u015bci <strong>wyra\u017anie<\/strong> . Zapewnia to powtarzalno\u015b\u0107, u\u0142atwia dostosowywanie i zapobiega nieoczekiwanym sytuacjom po aktualizacji. Za pomoc\u0105 parametru \u201elocal\u201c mog\u0119 opcjonalnie ograniczy\u0107 ponowne wykorzystanie do jednej lokalizacji, je\u015bli profile bezpiecze\u0144stwa lub zasady dotycz\u0105ce nag\u0142\u00f3wk\u00f3w si\u0119 r\u00f3\u017cni\u0105. W ten spos\u00f3b rozdzielenie pozostaje wyra\u017ane, bez utraty globalnych korzy\u015bci p\u0142yn\u0105cych z ponownego wykorzystania. Dzi\u0119ki jasno okre\u015blonym warto\u015bciom dokumentuj\u0119 zamierzenia i oszcz\u0119dzam czas w przysz\u0142o\u015bci <strong>Czas analizy<\/strong>.<\/p>\n\n<h2>Monitorowanie i wska\u017aniki: czy ta konfiguracja naprawd\u0119 dzia\u0142a?<\/h2>\n\n<p>Najpierw sprawdzam liczb\u0119 nowych po\u0142\u0105cze\u0144 z backendem na sekund\u0119; wyra\u017any spadek wskazuje na skuteczno\u015b\u0107 <strong>Ponowne u\u017cycie<\/strong>. Nast\u0119pnie obserwuj\u0119 parametr `upstream_connect_time`, kt\u00f3rego warto\u015b\u0107 w przypadku trafie\u0144 w puli jest bliska zeru. B\u0142\u0119dy w logach, zw\u0142aszcza resetowanie po\u0142\u0105cze\u0144, wskazuj\u0105 na limity czasowe le\u017c\u0105ce u podstaw warto\u015bci backendu. Ponadto koreluj\u0119 obci\u0105\u017cenie procesora backendu i op\u00f3\u017anienia z odsetkiem ponownie wykorzystywanych po\u0142\u0105cze\u0144. Aby lepiej zrozumie\u0107 <a href=\"https:\/\/webhosting.de\/pl\/http-connection-reuse-keepalive-optymalizacja-serverperf-boost\/\">Ponowne wykorzystanie po\u0142\u0105cze\u0144<\/a> Pomocne s\u0105 przyk\u0142ady ilustruj\u0105ce te efekty w r\u00f3\u017cnych schematach obci\u0105\u017cenia.<\/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>Szybkie wyeliminowanie typowych \u017ar\u00f3de\u0142 b\u0142\u0119d\u00f3w<\/h2>\n\n<p>Je\u015bli brakuje protoko\u0142u HTTP\/1.1 w backendzie, po\u0142\u0105czenia s\u0105 kr\u00f3tkotrwa\u0142e, niezale\u017cnie od tego, jak wysoko ustawi\u0119 <strong>keepalive<\/strong> ustawiam. Je\u015bli klient wy\u015ble komunikat \u201eConnection: close\u201c, a ja przeka\u017c\u0119 ten nag\u0142\u00f3wek bez filtrowania, backend zamknie ka\u017cde po\u0142\u0105czenie bezpo\u015brednio po wys\u0142aniu odpowiedzi. Je\u015bli limity czasu bezczynno\u015bci nie s\u0105 zsynchronizowane, strona aplikacji jako pierwsza zako\u0144czy po\u0142\u0105czenie, a NGINX otrzyma reset przy nast\u0119pnym \u017c\u0105daniu. Zbyt du\u017ca pula utrzymuje zbyt wiele otwartych gniazd, marnuj\u0105c pami\u0119\u0107 operacyjn\u0105 i porty. Podczas ka\u017cdej analizy sprawdzam te cztery punkty jako <strong>Po pierwsze<\/strong>, poniewa\u017c wyja\u015bniaj\u0105 one 90 % wszystkich problem\u00f3w.<\/p>\n\n<h2>Przyk\u0142ad praktyczny: Konfiguracja referencyjna zapewniaj\u0105ca wysok\u0105 przepustowo\u015b\u0107<\/h2>\n\n<p>Wystarczy kilka polece\u0144, by przywr\u00f3ci\u0107 mocno obci\u0105\u017cony serwer proxy do stanu, w kt\u00f3rym dzia\u0142a szybko i niezawodnie, oraz zapewni\u0107 prawid\u0142owe przekazywanie nag\u0142\u00f3wk\u00f3w; poni\u017cszy wz\u00f3r sprawdzi\u0142 si\u0119 w praktyce i mo\u017cna go \u0142atwo <strong>dostosowanie<\/strong>. Ustawiam keepalive na 64, ograniczam liczb\u0119 \u017c\u0105da\u0144 na po\u0142\u0105czenie do 1000 i utrzymuj\u0119 60-sekundowy czas bezczynno\u015bci. Ponadto poprawnie przekazuj\u0119 informacje o ho\u015bcie i przekazanych danych, aby serwery backendowe mog\u0142y stosowa\u0107 logik\u0119 i ograniczenia przepustowo\u015bci. Takie po\u0142\u0105czenie odci\u0105\u017ca procesor, skraca czasy odpowiedzi i pozwala spokojniej radzi\u0107 sobie ze szczytami obci\u0105\u017cenia. W\u0142a\u015bnie w ten spos\u00f3b osi\u0105gam dobrze przewidywaln\u0105 <strong>Wydajno\u015b\u0107<\/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>\u015arodowiska hostingowe i aspekty operacyjne, kt\u00f3re naprawd\u0119 maj\u0105 znaczenie<\/h2>\n\n<p>Cz\u0119sto umieszczam NGINX przed us\u0142ugami PHP-FPM, Node.js lub Java i dbam o to, by op\u00f3\u017anienia sieciowe pozostawa\u0142y na niskim poziomie, a limity czasu backendu by\u0142y sp\u00f3jne; zapewnia to <strong>Mo\u017cliwo\u015b\u0107 planowania<\/strong>. Solidna konfiguracja sieciowa j\u0105dra z odpowiednimi limitami gniazd zapobiega kolizjom mi\u0119dzy wieloma otwartymi po\u0142\u0105czeniami. R\u00f3wnomierny przydzia\u0142 zasob\u00f3w procesora oraz szybkie \u015bcie\u017cki dost\u0119pu do pami\u0119ci masowej pomagaj\u0105 serwerom backendowym utrzyma\u0107 kr\u00f3tkie czasy odpowiedzi. Ponadto dbam o wersjonowanie konfiguracji, aby zmiany pozostawa\u0142y przejrzyste. Dzi\u0119ki tej dyscyplinie system dzia\u0142a stabilnie nawet podczas szczyt\u00f3w ruchu <strong>reagowalny<\/strong>.<\/p>\n\n<h2>Najlepsze praktyki dla bie\u017c\u0105cych operacji<\/h2>\n\n<p>Zaczynam od keepalive 32\u201364, 500\u20131000 \u017c\u0105da\u0144 na po\u0142\u0105czenie i 60 sekund czasu bezczynno\u015bci, a nast\u0119pnie systematycznie dokonuj\u0119 pomiar\u00f3w i dostosowuj\u0119 warto\u015bci; to pozwala szybko <strong>sukcesy<\/strong>. Ka\u017cd\u0105 zmian\u0119 monitoruj\u0119 za pomoc\u0105 wska\u017anik\u00f3w dotycz\u0105cych szybko\u015bci po\u0142\u0105cze\u0144, op\u00f3\u017anie\u0144 i wzorc\u00f3w b\u0142\u0119d\u00f3w, a\u017c krzywe stan\u0105 si\u0119 bardziej stabilne. Wielko\u015b\u0107 puli dostosowuj\u0119 do liczby jednoczesnych \u017c\u0105da\u0144, a nie do surowej przepustowo\u015bci na sekund\u0119. Limity czasu nigdy nie s\u0105 d\u0142u\u017csze ni\u017c ich odpowiedniki w stosie backendowym, w przeciwnym razie gro\u017c\u0105 sporadyczne resetowania. Osoby, kt\u00f3re chc\u0105 bardziej precyzyjnie dostosowa\u0107 parametry, znajd\u0105 wskaz\u00f3wki dotycz\u0105ce precyzyjnego dostrajania pod adresem <a href=\"https:\/\/webhosting.de\/pl\/optymalizacja-zadan-keepalive-w-nginx-dostrajanie-wydajnosci-serwera-www\/\">Optymalizacja \u017c\u0105da\u0144 keepalive<\/a>, co sprawia, \u017ce recykling jest \u0142atwy do opanowania.<\/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>Dostosowanie limit\u00f3w czasu serwera proxy i funkcji TCP Keepalive<\/h2>\n\n<p>Opr\u00f3cz samych parametr\u00f3w keepalive precyzyjnie dostosowuj\u0119 limity czasu transmisji. Ta tr\u00f3jca, sk\u0142adaj\u0105ca si\u0119 z <strong>proxy_connect_timeout<\/strong>, <strong>proxy_send_timeout<\/strong> oraz <strong>proxy_read_timeout<\/strong> okre\u015bla, jak cierpliwy jest NGINX podczas nawi\u0105zywania po\u0142\u0105cze\u0144, wysy\u0142ania i odbierania danych. Nigdy nie ustawiam tych warto\u015bci na poziomie wy\u017cszym ni\u017c ich odpowiedniki w backendzie, lecz nieco poni\u017cej, aby b\u0142\u0119dy by\u0142y widoczne na wczesnym etapie i nie eskalowa\u0142y po stronie aplikacji. Dodatkowo w\u0142\u0105czam <strong>proxy_socket_keepalive<\/strong>, aby system operacyjny wysy\u0142a\u0142 w regularnych odst\u0119pach czasu sygna\u0142y aktywno\u015bci dotycz\u0105ce nieaktywnych gniazd i wykrywa\u0142 po\u0142\u0105czenia p\u00f3\u0142otwarte. Zapobiega to pozostawaniu martwych po\u0142\u0105cze\u0144 w puli i powodowaniu skok\u00f3w op\u00f3\u017anie\u0144 przy nast\u0119pnym \u017c\u0105daniu.<\/p>\n\n<pre><code>server {\n    listen 80;\n\n    location \/ {\n proxy_pass http:\/\/backend_pool;\n\n proxy_connect_timeout 3s;   # szybkie zako\u0144czenie, je\u015bli nie mo\u017cna nawi\u0105za\u0107 po\u0142\u0105czenia\n proxy_send_timeout    30s;  # Zapis do backendu\n proxy_read_timeout    30s;  # Odpowiedzi z backendu\n proxy_socket_keepalive on;  # W\u0142\u0105cz keepalive protoko\u0142u TCP systemu operacyjnego\n    }\n}\n<\/code><\/pre>\n\n<p>W przypadku d\u0142ugotrwa\u0142ych strumieni (np. SSE lub WebSockets) zwi\u0119kszam wy\u0142\u0105cznie limit czasu odczytu, podczas gdy po\u0142\u0105czenie pozostaje aktywne. W ten spos\u00f3b szybko reaguj\u0119 na uszkodzone cele, ale nie zak\u0142\u00f3cam przep\u0142ywu prawid\u0142owych, d\u0142ugich odpowiedzi.<\/p>\n\n<h2>Planowanie zasob\u00f3w: worker_connections, FD i porty efemeryczne<\/h2>\n\n<p>Czysta pula keepalive nie ma sensu, je\u015bli wyczerpi\u0105 si\u0119 limity deskryptor\u00f3w plik\u00f3w lub zakresy port\u00f3w. Dlatego planuj\u0119 <strong>worker_connections<\/strong> oraz <strong>worker_rlimit_nofile<\/strong> z rezerw\u0105. Z grubsza obliczam: otwarte FD \u2248 (jednoczesne po\u0142\u0105czenia klienckie + jednoczesne po\u0142\u0105czenia z backendem + zgrupowane gniazda w stanie bezczynno\u015bci) na ka\u017cdy proces roboczy. Je\u015bli wykorzystuj\u0119 kilka strumieni upstream z pulami, zapotrzebowanie si\u0119 zwielokrotnia. Zwracam r\u00f3wnie\u017c uwag\u0119 na zakres port\u00f3w efemerycznych w systemie, poniewa\u017c NGINX dzia\u0142a jako klient TCP w kierunku backendu i gromadzi stany TIME_WAIT.<\/p>\n\n<pre><code>worker_processes auto;\nworker_rlimit_nofile 131072;\n\nevents {\n    worker_connections 8192;\n}\n<\/code><\/pre>\n\n<pre><code>Przyk\u0142ady dla systemu Linux # (sysctl):\nnet.core.somaxconn = 4096\nnet.ipv4.ip_local_port_range = 10240 65535\nnet.ipv4.tcp_fin_timeout = 15\n<\/code><\/pre>\n\n<p>Post\u0119puj\u0119 ostro\u017cnie: nie wy\u0142\u0105czam TIME_WAIT w spos\u00f3b agresywny, lecz zmniejszam cz\u0119stotliwo\u015b\u0107 po\u0142\u0105cze\u0144 za pomoc\u0105 keepalive. Dzi\u0119ki temu parametry j\u0105dra pozostaj\u0105 na niekrytycznym poziomie, a zachowanie systemu jest przewidywalne.<\/p>\n\n<h2>Strefy upstream, strategia r\u00f3wnowa\u017cenia obci\u0105\u017cenia i rotacja DNS<\/h2>\n\n<p>W przypadku wielu proces\u00f3w dziel\u0119 stan balancera za pomoc\u0105 <strong>strefa<\/strong>, aby awarie i obci\u0105\u017cenia pozostawa\u0142y sp\u00f3jne. Gniazda Keepalive nadal pozostaj\u0105 przypisane do poszczeg\u00f3lnych worker\u00f3w, ale ich rozk\u0142ad staje si\u0119 bardziej r\u00f3wnomierny. W przypadku dynamicznych backend\u00f3w, kt\u00f3re zmieniaj\u0105 lokalizacj\u0119 za po\u015brednictwem DNS, ustawiam \u201e<strong>rozwi\u0105za\u0107<\/strong>\u201c w wierszach serwera i zdefiniuj <strong>resolver<\/strong>. Wa\u017cne: Gdy adresy IP ulegaj\u0105 rotacji, pula nie odzyskuje od razu wszystkich starych gniazd; dlatego uwa\u017cam, \u017ce <em>keepalive_requests<\/em> oraz realistyczne terminy, aby zmiany zacz\u0119\u0142y szybko przynosi\u0107 efekty.<\/p>\n\n<pre><code>upstream backend_pool {\n    zone backend_zone 128k;  # dzieli stan balanceru\n    least_conn; # sprawiedliwy rozk\u0142ad przy d\u0142ugich \u017c\u0105daniach\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;  # \u2014 niewiele, ukierunkowanych powt\u00f3rze\u0144\n<\/code><\/pre>\n\n<p>W przypadku sesji powi\u0105zanych z konkretnym w\u0119z\u0142em zaplecza (np. w trybie sticky-state) \u0142\u0105cz\u0119 ponowne wykorzystanie z <em>ip_hash<\/em> lub zewn\u0119trznego mechanizmu sesji. Zapobiega to zak\u0142\u00f3caniu sp\u00f3jno\u015bci sesji przez pul\u0119 po\u0142\u0105cze\u0144.<\/p>\n\n<h2>TLS w backendzie: SNI, ponowne wykorzystanie sesji i szyfry<\/h2>\n\n<p>Im cz\u0119\u015bciej wykorzystuje si\u0119 TLS w \u015bcie\u017cce backendowej, tym wi\u0119ksze znaczenie ma funkcja Keepalive. W\u0142\u0105czam SNI, ustalam oczekiwan\u0105 nazw\u0119 i dbam o ponowne wykorzystanie sesji TLS. Obni\u017ca to koszty uzgadniania po\u0142\u0105czenia i wyg\u0142adza skoki op\u00f3\u017anie\u0144. Zestawy szyfr\u00f3w i protoko\u0142y wybieram w spos\u00f3b restrykcyjny, nie blokuj\u0105c przy tym starszych backend\u00f3w. Podczas weryfikacji certyfikatu (opcjonalnie) \u0142a\u0144cuch zaufania musi by\u0107 kompletny, w przeciwnym razie po\u0142\u0105czenia b\u0119d\u0105 sporadycznie si\u0119 roz\u0142\u0105cza\u0107.<\/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 # opcjonalnie: proxy_ssl_verify on;\n # opcjonalnie: proxy_ssl_trusted_certificate \/etc\/nginx\/ca.pem;\n    }\n}\n<\/code><\/pre>\n\n<p>Je\u015bli sam zarz\u0105dzam stron\u0105 backendow\u0105, w\u0142\u0105czam tam sesyjne tokeny lub pami\u0119\u0107 podr\u0119czn\u0105 i sprawdzam na podstawie wska\u017anik\u00f3w, czy wska\u017aniki wznowienia rosn\u0105. W po\u0142\u0105czeniu z funkcj\u0105 Keepalive uzyskuj\u0119 w ten spos\u00f3b stale niskie czasy nawi\u0105zywania po\u0142\u0105cze\u0144 i uzgadniania.<\/p>\n\n<h2>Przypadki szczeg\u00f3lne: gRPC, WebSockets i uwierzytelnianie oparte na po\u0142\u0105czeniu<\/h2>\n\n<p>Na stronie <strong>gRPC<\/strong> NGINX dzia\u0142a w trybie upstream przez HTTP\/2. W tym przypadku najlepsze wyniki cz\u0119sto zapewniaj\u0105 nieliczne, d\u0142ugotrwa\u0142e po\u0142\u0105czenia z du\u017c\u0105 liczb\u0105 strumieni; pula pozostaje niewielka, ale stabilna. W przypadku <strong>WebSockets<\/strong> Ustawiam d\u0142ugie limity czasu odczytu i zachowuj\u0119 logik\u0119 obs\u0142ugi nag\u0142\u00f3wk\u00f3w z rozwi\u0105zania \u201emap\u201d, aby po\u0142\u0105czenia aktualizacyjne nie zosta\u0142y przypadkowo zamkni\u0119te. <strong>NTLM<\/strong> lub inne metody uwierzytelniania oparte na po\u0142\u0105czeniu wymagaj\u0105 przypisania sta\u0142ego po\u0142\u0105czenia (connection pinning); wyodr\u0119bniam takie \u015bcie\u017cki do osobnych lokalizacji i ograniczam tam pulowanie lub ponowne wykorzystywanie, aby unikn\u0105\u0107 pomylenia procedur bezpiecze\u0144stwa mi\u0119dzy klientami.<\/p>\n\n<pre><code>Przyk\u0142ad # z gRPC\nlocation \/grpc.Service\/ {\n    grpc_pass grpc:\/\/backend_pool;\n    grpc_read_timeout 300s;  zezw\u00f3l na d\u0142ugie strumienie #\n}\n<\/code><\/pre>\n\n<p>Kluczowe znaczenie ma ustalenie sp\u00f3jnej polityki po\u0142\u0105cze\u0144 dla ka\u017cdej \u015bcie\u017cki oraz stosowanie funkcji Keepalive na szerok\u0105 skal\u0119 wy\u0142\u0105cznie tam, gdzie nie ma to znaczenia semantycznego.<\/p>\n\n<h2>Mierzalno\u015b\u0107 w praktyce: logi dost\u0119pu z czasami transmisji w kierunku upstream<\/h2>\n\n<p>Rozszerzam dziennik Access o wska\u017aniki upstream. Dzi\u0119ki temu od razu widz\u0119, czy odpowied\u017a pochodzi\u0142a z gniazda w puli (bardzo kr\u00f3tki czas po\u0142\u0105czenia) oraz jak cz\u0119sto wyst\u0119puj\u0105 b\u0142\u0119dy backendu. Ponadto rejestruj\u0119 numer po\u0142\u0105czenia oraz liczb\u0119 \u017c\u0105da\u0144 przes\u0142anych przez bie\u017c\u0105ce po\u0142\u0105czenie klienckie, aby zidentyfikowa\u0107 powi\u0105zania.<\/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>Dodatkowo korzystam z punkt\u00f3w ko\u0144cowych stanu oraz statystyk gniazd systemu operacyjnego. Prawid\u0142owy stan charakteryzuje si\u0119: malej\u0105c\u0105 liczb\u0105 po\u0142\u0105cze\u0144 z serwerem zaplecza, kr\u00f3tszym czasem upstream_connect_time, stabilnymi czasami odpowiedzi oraz rzadkimi resetami po\u0142\u0105cze\u0144. Odchylenia od normy niemal zawsze wskazuj\u0105 na niedostosowane limity czasowe lub zbyt ma\u0142e\/zbyt du\u017ce pule.<\/p>\n\n<h2>Strategia wdra\u017cania i dostosowywanie przy ograniczonym ryzyku<\/h2>\n\n<p>Post\u0119puj\u0119 iteracyjnie: ma\u0142e kroki, pomiary, dostosowywanie. Najpierw umiarkowanie w\u0142\u0105czam keepalive, a nast\u0119pnie dostosowuj\u0119 limity czasu i liczb\u0119 \u017c\u0105da\u0144 na po\u0142\u0105czenie. Zmiany wprowadzam poprzez od\u015bwie\u017cenie strony, bez roz\u0142\u0105czania aktywnych po\u0142\u0105cze\u0144. Dzi\u0119ki temu ryzyko pozostaje niewielkie, a efekty mo\u017cna jednoznacznie przypisa\u0107.<\/p>\n\n<pre><code># Sprawd\u017a zmiany i za\u0142aduj je bez przestoju\nnginx -t &amp;&amp; nginx -s reload\n<\/code><\/pre>\n\n<p>Je\u015bli obs\u0142uguj\u0119 kilka \u017ar\u00f3de\u0142 danych, optymalizuj\u0119 je po kolei, zaczynaj\u0105c od \u015bcie\u017cki o najwi\u0119kszym znaczeniu. Ka\u017cdemu etapowi przypisuj\u0119 okno obserwacyjne, aby wyra\u017anie wyodr\u0119bni\u0107 wzorce w wska\u017anikach. Dopiero potem zwi\u0119kszam lub zmniejszam warto\u015bci.<\/p>\n\n<h2>Zwi\u0119z\u0142e podsumowanie dotycz\u0105ce Twojego serwera proxy odwrotnego<\/h2>\n\n<p>Stawiam na HTTP\/1.1, usuwam nag\u0142\u00f3wek \u201eConnection\u201d i dobieram wielko\u015b\u0107 puli na podstawie liczby jednoczesnych \u017c\u0105da\u0144, a nie na podstawie RPS; to zapewnia <strong>Wydajno\u015b\u0107<\/strong>. Dzi\u0119ki parametrom `keepalive_requests` i `keepalive_timeout` utrzymuj\u0119 po\u0142\u0105czenia w aktywnym stanie i unikam nieoczekiwanych problem\u00f3w zwi\u0105zanych z nieaktualnymi gniazdami. Monitorowanie pokazuje, czy warto\u015b\u0107 `upstream_connect_time` d\u0105\u017cy do zera oraz czy zmniejsza si\u0119 liczba po\u0142\u0105cze\u0144 z backendem. W przypadku b\u0142\u0119d\u00f3w najpierw sprawdzam wersj\u0119 protoko\u0142u, przekazywanie nag\u0142\u00f3wk\u00f3w, limity czasowe i rozmiar puli. Dzi\u0119ki temu Tw\u00f3j serwer proxy NGINX b\u0119dzie dzia\u0142a\u0142 stabilnie nawet przy du\u017cym obci\u0105\u017ceniu <strong>responsywny<\/strong> i przewidywalne.<\/p>","protected":false},"excerpt":{"rendered":"<p>Dowiedz si\u0119, jak optymalnie skonfigurowa\u0107 funkcj\u0119 NGINX Upstream Keepalive w bloku \u201enginx upstream\u201d, aby znacznie zwi\u0119kszy\u0107 wydajno\u015b\u0107 swojego serwera proxy odwrotnego.<\/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":"107","_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\/pl\/wp-json\/wp\/v2\/posts\/21613","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=21613"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/21613\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media\/21606"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media?parent=21613"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/categories?post=21613"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/tags?post=21613"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}