{"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":"optimally-configuring-nginx-upstream-keepalive-for-a-reverse-proxy-network","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/nginx-upstream-keepalive-optimal-konfigurieren-reverse-proxy-netzwerk\/","title":{"rendered":"Optimally Configuring NGINX Upstream Keepalive for Maximum Performance as a Reverse Proxy"},"content":{"rendered":"<p>I configure NGINX Upstream Keepalive so that the reverse proxy establishes fewer connections, delivers lower latency, and reliably handles traffic spikes. To do this, I adjust <strong>Pool Size<\/strong>, time limits, and headers in a targeted manner so that connections are reused and the data path remains streamlined.<\/p>\n\n<h2>Key points<\/h2>\n\n<ul>\n  <li><strong>HTTP\/1.1<\/strong> Enforce and clean up connection headers<\/li>\n  <li><strong>keepalive<\/strong> Size correctly for each worker<\/li>\n  <li><strong>Timeouts<\/strong> Adjust to backend values<\/li>\n  <li><strong>Requests\/Connection<\/strong> reduce and recycle<\/li>\n  <li><strong>Monitoring<\/strong> for connection speed and latency<\/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>Why Upstream Keepalive Drastically Reduces Connection Overhead<\/h2>\n\n<p>Without reuse, NGINX opens a new backend connection for each request, which requires extra handshakes, more CPU cycles, and additional kernel resources; this is exactly where <strong>Keepalive<\/strong> I have NGINX cache already established, currently idle sockets and reuse them for subsequent requests, which measurably reduces connection times. This lowers the connection rate per second, reduces backlog spikes, and minimizes context switches in the operating system. I save a noticeable amount of time through reused sessions, especially with TLS connections to the backend. This keeps the response chain consistent even at high throughput <strong>reliable<\/strong> and responds smoothly.<\/p>\n\n<h2>Basic Principle and the keepalive Directive in the Upstream<\/h2>\n\n<p>The Directive <strong>keepalive<\/strong> In the upstream block, this limits the number of idle backend connections cached per worker. This limit does not apply globally, but strictly per worker process, which is why I always keep an eye on the number of workers. When the pool is full, NGINX closes the connection that has been idle the longest first to make room for new sockets. For reuse, the proxy side requires HTTP\/1.1 and a neutralized Connection header. Without these prerequisites, the pool remains empty, even though I set \u201ekeepalive\u201c in the upstream, which many admins <strong>at first<\/strong> surprised.<\/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; # idle connections per worker\n    keepalive_requests 1000;   # recycling after N requests\n    keepalive_timeout 60s;     # idle lifetime\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>Mandatory Directives in the Location Block: HTTP\/1.1 and Header Control<\/h2>\n\n<p>I force NGINX to use HTTP\/1.1 in the proxy path because Keepalive doesn't work properly with HTTP\/1.0, causing connections to terminate unnecessarily; the directive <strong>proxy_http_version<\/strong> 1.1 is therefore required. In addition, I remove the `Connection` header for regular requests so that the backend does not receive a \u201eclose\u201c instruction. For upgrades such as WebSockets, I use `map` to specifically set `Connection: Upgrade` without affecting normal reuse. This keeps the connection policy consistent and decoupled from client headers. It is precisely this small change that prevents many elusive <strong>error patterns<\/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>Fine-Tuning: Selecting the Correct Values for `keepalive_requests` and `keepalive_timeout`<\/h2>\n\n<p>Using two adjustment screws, I control the lifespan and renewal of the connections so that the pool stays fresh and no orphaned sockets cause problems; these are <strong>keepalive_requests<\/strong> and keepalive_timeout. After N requests, NGINX intentionally closes the connection and reestablishes it as needed, which mitigates network aging effects. I tend to set the idle timeout on the shorter side, usually between 30 and 120 seconds, so that backends don\u2019t disconnect prematurely. Coordination is key: The NGINX value should never exceed the app server\u2019s timeout, otherwise connection resets will accumulate. If you\u2019d like to delve deeper into the background, you\u2019ll find practical tips in the article <a href=\"https:\/\/webhosting.de\/en\/http-keepalive-timeout-server-performance-configuration\/\">Keepalive Timeout<\/a>, which explains typical values and interactions.<\/p>\n\n<p>To help you get your bearings quickly, I've listed common default values and their respective purposes in a clear, easy-to-read table <strong>Table<\/strong>. These guidelines serve as a starting point and often end up slightly higher or lower after monitoring. A timeframe that\u2019s too short causes unnecessary re-establishments, while one that\u2019s too long keeps old connections open. I use the number of requests per connection to protect against outliers without emptying the pool. With these key metrics, I can very quickly achieve a system that works <strong>Defaults<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parameters<\/th>\n      <th>Purpose<\/th>\n      <th>reference value<\/th>\n      <th>Tuning Note<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>keepalive<\/td>\n      <td>Size of the idle pool per worker<\/td>\n      <td>32-64<\/td>\n      <td>Align with the simultaneous load per worker<\/td>\n    <\/tr>\n    <tr>\n      <td>keepalive_requests<\/td>\n      <td>Maximum requests per connection<\/td>\n      <td>500\u20131000<\/td>\n      <td>Set it a little higher for long streams<\/td>\n    <\/tr>\n    <tr>\n      <td>keepalive_timeout<\/td>\n      <td>Maximum idle time per connection<\/td>\n      <td>60s<\/td>\n      <td>Shorter or Same Backend Idle Timeout<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Determine Pool Size Based on Concurrent Connections<\/h2>\n\n<p>I don't choose the pool size based on requests per second, but rather on <strong>Concurrency<\/strong> per worker. First, I determine the average and maximum number of concurrent backend requests. Then I divide these numbers by the number of NGINX workers and round up. For 200 concurrent requests with four workers, I arrive at about 50 per worker, which makes keepalive 64 a suitable starting value. This way, I keep sockets available without keeping an unnecessarily large number of open <strong>Connections<\/strong> to bind.<\/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>Leverage the Unique Features of Newer NGINX Versions<\/h2>\n\n<p>Current versions often allow reuse by default, but set fairly conservative limits; I'll include the values anyway <strong>explicitly<\/strong> This ensures reproducibility, makes tuning easier, and prevents surprises after an update. Using the \u201elocal\u201c parameter, I can optionally restrict reuse to a single location if security profiles or header policies differ. This keeps the separation clean without losing the benefits of global reuse. By using clear values, I document my intentions and save time later <strong>Analysis time<\/strong>.<\/p>\n\n<h2>Monitoring and Metrics: Is the Configuration Actually Working?<\/h2>\n\n<p>First, I check the number of new backend connections per second; a significant drop indicates that the measures are taking effect <strong>Reuse<\/strong>. Then I monitor `upstream_connect_time`, which is close to zero when there are hits in the pool. Errors in the logs\u2014specifically connection resets\u2014indicate timeouts that are behind the backend values. In addition, I correlate backend CPU usage and latencies with the percentage of reused connections. For a deeper understanding of <a href=\"https:\/\/webhosting.de\/en\/http-connection-reuse-keepalive-optimization-serverperf-boost\/\">Connection Reuse<\/a> Examples that illustrate the effects under various load patterns are helpful.<\/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>Quickly Eliminate Common Sources of Error<\/h2>\n\n<p>If HTTP\/1.1 isn't supported by the backend, connections remain short-lived, no matter how high I <strong>keepalive<\/strong> set. If the client sends \u201eConnection: close\u201c and I pass the header through unfiltered, the backend closes each connection immediately after the response. If idle timeouts don't match, the app side terminates the connection first, and NGINX triggers a reset on the next request. An oversized pool keeps too many sockets open and wastes memory and ports. I check these four points during every analysis as <strong>First<\/strong>, because they explain 90 % of all problems.<\/p>\n\n<h2>Practical Example: Reference Configuration for High Throughput<\/h2>\n\n<p>With just a few instructions, I can get a heavily loaded proxy up and running quickly and reliably and ensure clean header forwarding; the following pattern has proven effective and is easy to <strong>customize<\/strong>. I set keepalive to 64, limit requests per connection to 1,000, and set the idle time to 60 seconds. In addition, I correctly pass along host and forwarded information so that backends can apply logic and rate limiting. This combination reduces CPU load, shortens response times, and handles load spikes more smoothly. This is exactly how I achieve a highly predictable <strong>Performance<\/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>Hosting Environments and Operational Considerations That Really Matter<\/h2>\n\n<p>I often place NGINX in front of PHP-FPM, Node.js, or Java services and make sure that network latency remains low and backend timeouts are consistent; this provides <strong>Plannability<\/strong>. A robust kernel network configuration with appropriate socket limits prevents a large number of open connections from interfering with one another. Even CPU allocation and fast storage paths help the backends maintain short response times. I also ensure that configurations are versioned so that changes remain traceable. With this discipline, the system remains stable during traffic spikes <strong>responsive<\/strong>.<\/p>\n\n<h2>Best practices for ongoing operations<\/h2>\n\n<p>I start with a keepalive of 32\u201364, 500\u20131,000 requests per connection, and a 60-second idle time, then systematically measure and adjust the values; this leads to quick <strong>achievements<\/strong>. I monitor every change with metrics on connection rates, latency, and error patterns until the curves stabilize. I base the pool size on concurrent requests, not on raw throughput per second. Timeouts should never be longer than their counterparts in the backend stack; otherwise, sporadic resets may occur. If you want to fine-tune performance further, you\u2019ll find tips on fine-tuning at <a href=\"https:\/\/webhosting.de\/en\/optimizing-nginx-keep-alive-requests-web-server-performance-tuning\/\">Optimize Keepalive Requests<\/a>, which makes recycling quite manageable.<\/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>Synchronizing Proxy Timeouts and TCP Keepalive<\/h2>\n\n<p>In addition to the keepalive parameters themselves, I fine-tune the transport timeouts. The trio of <strong>proxy_connect_timeout<\/strong>, <strong>proxy_send_timeout<\/strong> and <strong>proxy_read_timeout<\/strong> determines how patient NGINX is when establishing connections, sending, and receiving data. I never set these values higher than their counterparts in the backend; instead, I set them slightly lower so that errors become apparent early on and don't escalate on the app side. In addition, I enable <strong>proxy_socket_keepalive<\/strong>, so that the operating system sends periodic \"alive\" signals over inactive sockets and detects half-open connections. This prevents dead connections from remaining in the pool and causing latency spikes during the next request.<\/p>\n\n<pre><code>server {\n    listen 80;\n\n    location \/ {\n proxy_pass http:\/\/backend_pool;\n\n proxy_connect_timeout 3s;   # Fail quickly if connection cannot be established\n proxy_send_timeout    30s;  # Write to the backend\n proxy_read_timeout    30s;  # Responses from the backend\n proxy_socket_keepalive on;  # Enable OS TCP keep-alive\n    }\n}\n<\/code><\/pre>\n\n<p>For long-running streams (e.g., SSE or WebSockets), I increase only the read timeout, while the connect timeout remains unchanged. This allows me to respond quickly to faulty targets while letting legitimate, long responses run uninterrupted.<\/p>\n\n<h2>Resource Planning: worker_connections, FDs, and Ephemeral Ports<\/h2>\n\n<p>A clean keepalive pool is useless if file descriptor limits or port ranges are exhausted. Therefore, I plan to <strong>worker_connections<\/strong> and <strong>worker_rlimit_nofile<\/strong> with a margin. As a rough estimate, I calculate: Open FDs \u2248 (concurrent client connections + concurrent backend connections + pooled idle sockets) per worker. If I use multiple upstreams with pools, the requirement multiplies. I also pay close attention to the system\u2019s ephemeral port range, since NGINX acts as a TCP client toward the backend and accumulates TIME_WAIT states.<\/p>\n\n<pre><code>worker_processes auto;\nworker_rlimit_nofile 131072;\n\nevents {\n    worker_connections 8192;\n}\n<\/code><\/pre>\n\n<pre><code># Linux Examples (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>I'm taking a conservative approach: instead of aggressively clearing the TIME_WAIT state, I'm reducing the connection rate via keepalives. This way, kernel parameters remain uncritical and the behavior remains predictable.<\/p>\n\n<h2>Upstream Zones, Load Balancing Strategy, and DNS Rotation<\/h2>\n\n<p>When there are multiple workers, I share the balancer state via a <strong>zone<\/strong>, so that failures and loads remain consistent. Keepalive sockets are still assigned per worker, but the distribution becomes more even. For dynamic backends that move via DNS, I set \u201e<strong>resolve<\/strong>\u201c in the server lines and define a <strong>resolver<\/strong>. Important: When IPs rotate, the pool does not immediately recycle all old sockets; therefore, I believe <em>keepalive_requests<\/em> and realistic time limits so that the renewal takes effect promptly.<\/p>\n\n<pre><code>upstream backend_pool {\n    zone backend_zone 128k;  # shares balancer state\n    least_conn; # fair distribution for long requests\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;  #: a few, targeted retries\n<\/code><\/pre>\n\n<p>For sessions that are bound to a specific backend node (e.g., sticky state), I combine reuse with <em>ip_hash<\/em> or an external session mechanism. This prevents connection pooling from disrupting session consistency.<\/p>\n\n<h2>TLS to the Backend: SNI, Session Reuse, and Ciphers<\/h2>\n\n<p>The more TLS is used in the backend path, the more valuable Keepalive becomes. I enable SNI, specify the expected name, and ensure that the TLS session is reused. This reduces handshake overhead and smooths out latency spikes. I choose cipher suites and protocols selectively, without excluding older backends. For certificate validation (optional), the trust chain must be complete; otherwise, connections will occasionally drop.<\/p>\n\n<pre><code>upstream https_backend {\n    server backend.example.local:443;\n    keepalive 32;\n}\n\nserver {\n    listen 443 ssl;\n\n location \/ {\n proxy_pass https:\/\/https_backend;\n proxy_http_version 1.1;\n proxy_set_header Connection \"\";\n\n        proxy_ssl_server_name on;\n proxy_ssl_name backend.example.local;\n proxy_ssl_session_reuse on;\n proxy_ssl_protocols TLSv1.2 TLSv1.3;\n        proxy_ssl_ciphers HIGH:!aNULL:!MD5;\n # optional: proxy_ssl_verify on;\n # optional: proxy_ssl_trusted_certificate \/etc\/nginx\/ca.pem;\n    }\n}\n<\/code><\/pre>\n\n<p>If I manage the backend myself, I enable session tickets or caches there and use metrics to check whether resumption rates are increasing. Combined with Keepalive, this allows me to maintain consistently low connect and handshake times.<\/p>\n\n<h2>Special Cases: gRPC, WebSockets, and Connection-Bound Authentication<\/h2>\n\n<p>At <strong>gRPC<\/strong> NGINX operates upstream over HTTP\/2. Here, a small number of long-lived connections with many streams often yield the best results; the pool remains small but stable. For <strong>WebSockets<\/strong> I set long read timeouts and keep the header logic from the map solution so that upgrade connections aren't accidentally closed. <strong>NTLM<\/strong> or other connection-bound authentication methods require connection pinning; I separate such paths into their own locations and reduce pooling or reuse there to ensure that security handshakes are not mixed up between clients.<\/p>\n\n<pre><code># gRPC Example\nlocation \/grpc.Service\/ {\n    grpc_pass grpc:\/\/backend_pool;\n    grpc_read_timeout 300s;  Allow #-length streams\n}\n<\/code><\/pre>\n\n<p>It is crucial to establish a consistent connection policy for each path and to use keepalives extensively only where it is semantically non-critical.<\/p>\n\n<h2>Measurability in Practice: Access Logs with Upstream Timings<\/h2>\n\n<p>I'm adding upstream metrics to the access log. This lets me see at a glance whether a response came from a pooled socket (very short connect time) and how often backend errors occur. I also log the connection number and the number of requests made via the current client connection to identify correlations.<\/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>I also use status endpoints and OS socket statistics. A healthy state is indicated by: a decreasing connection rate to the backend, shorter `upstream_connect_time`, stable response times, and very few connection resets. Deviations almost always indicate mismatched timeouts or pools that are too small or too large.<\/p>\n\n<h2>Rollout Strategy and Low-Risk Tuning<\/h2>\n\n<p>I take an iterative approach: small steps, measure, adjust. First, I enable keepalives at a moderate level, then adjust timeouts and the number of requests per connection. I apply changes by reloading the page without disconnecting active connections. This keeps the risk low and makes it easy to pinpoint the effects.<\/p>\n\n<pre><code># Validate changes and load them without downtime\nnginx -t &amp;&amp; nginx -s reload\n<\/code><\/pre>\n\n<p>When I'm running multiple upstreams, I tune them one after another, starting with the most critical path. I set a monitoring window for each stage so that patterns in the metrics become clear. Only then do I scale the values up or down.<\/p>\n\n<h2>A Brief Summary of Your Reverse Proxy<\/h2>\n\n<p>I use HTTP\/1.1, clear the Connection header, and choose the pool size based on concurrent requests, not RPS; this supports the <strong>Performance<\/strong>. I use `keepalive_requests` and `keepalive_timeout` to keep connections alive and avoid surprises caused by stale sockets. Monitoring shows whether `upstream_connect_time` is approaching zero and whether the connection rate to the backend is decreasing. When errors occur, I first check the protocol version, header passing, timeouts, and pool size. This keeps your NGINX proxy running smoothly under heavy load <strong>responsive<\/strong> and predictable.<\/p>","protected":false},"excerpt":{"rendered":"<p>Learn how to optimally configure NGINX upstream keepalive in the nginx upstream block to significantly improve the performance of your reverse proxy.<\/p>","protected":false},"author":1,"featured_media":21606,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-21613","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"112","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":null,"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"NGINX Upstream","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21606","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21613","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/comments?post=21613"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21613\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/21606"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=21613"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=21613"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=21613"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}