{"id":21658,"date":"2026-09-22T17:33:35","date_gmt":"2026-09-22T15:33:35","guid":{"rendered":"https:\/\/webhosting.de\/?p=21658"},"modified":"2026-09-22T17:33:39","modified_gmt":"2026-09-22T15:33:39","slug":"configuring-the-nginx-resolver-cache-correctly","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/nginx-resolver-cache-richtig-konfigurieren\/","title":{"rendered":"Configuring the NGINX Resolver Cache Correctly"},"content":{"rendered":"<div class=\"wh-article\" data-wh-layout=\"2.1.2\" style=\"width:100%;max-width:820px;margin:0 auto;color:#263b4b;font-family:inherit;font-size:18px;line-height:1.8;text-align:start;overflow-wrap:break-word;box-sizing:border-box\"><p class=\"wh-lead\" style=\"font-size:20px;line-height:1.7;color:#233746;margin:0 0 1.1em\">The <strong style=\"font-weight:700;color:inherit\">NGINX Resolver<\/strong> Cached DNS responses for backend names, but not HTTP responses. For a robust reverse proxy configuration, use a trusted internal nameserver, generally allow well-maintained DNS TTLs to take effect, and set <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">valid<\/code> only as a deliberate override. The resolver becomes particularly important when dealing with variable targets in <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">proxy_pass<\/code> as well as for dynamic upstreams, whose functionality depends on the installed version of NGINX.   <\/p>\n<nav class=\"wh-toc\" aria-label=\"Contents of this article\" style=\"display:block;margin:28px 0 38px;padding:22px;border:1px solid #d9e4e8;border-radius:14px;background:#f4f8f8\"><p class=\"wh-toc-title\" style=\"font-size:13px;font-weight:700;letter-spacing:.08em;color:#49656b;margin:0 0 14px\">Go directly to the section<\/p><div class=\"wh-toc-grid\" style=\"display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,280px),1fr));gap:10px\"><div class=\"wh-toc-item\" style=\"display:block;min-width:0;margin:0;padding:0\"><a class=\"wh-toc-link\" href=\"#resolver-grundlagen\" style=\"display:block;height:100%;padding:12px 15px;border:1px solid #dce6e8;border-radius:9px;background:#fff;color:#18575b;font-size:14px;line-height:1.5;font-weight:600;text-decoration:none;box-sizing:border-box\">Understanding the NGINX Resolver and DNS Cache<\/a><\/div>\n<div class=\"wh-toc-item\" style=\"display:block;min-width:0;margin:0;padding:0\"><a class=\"wh-toc-link\" href=\"#cache-arten-abgrenzen\" style=\"display:block;height:100%;padding:12px 15px;border:1px solid #dce6e8;border-radius:9px;background:#fff;color:#18575b;font-size:14px;line-height:1.5;font-weight:600;text-decoration:none;box-sizing:border-box\">A DNS cache is not an HTTP cache<\/a><\/div>\n<div class=\"wh-toc-item\" style=\"display:block;min-width:0;margin:0;padding:0\"><a class=\"wh-toc-link\" href=\"#laufzeitauflosung-und-versionen\" style=\"display:block;height:100%;padding:12px 15px;border:1px solid #dce6e8;border-radius:9px;background:#fff;color:#18575b;font-size:14px;line-height:1.5;font-weight:600;text-decoration:none;box-sizing:border-box\">When NGINX Needs to Resolve Names Again<\/a><\/div>\n<div class=\"wh-toc-item\" style=\"display:block;min-width:0;margin:0;padding:0\"><a class=\"wh-toc-link\" href=\"#ttl-und-valid-planen\" style=\"display:block;height:100%;padding:12px 15px;border:1px solid #dce6e8;border-radius:9px;background:#fff;color:#18575b;font-size:14px;line-height:1.5;font-weight:600;text-decoration:none;box-sizing:border-box\">Explicitly set TTL and valid<\/a><\/div>\n<div class=\"wh-toc-item\" style=\"display:block;min-width:0;margin:0;padding:0\"><a class=\"wh-toc-link\" href=\"#variabler-proxy-pass\" style=\"display:block;height:100%;padding:12px 15px;border:1px solid #dce6e8;border-radius:9px;background:#fff;color:#18575b;font-size:14px;line-height:1.5;font-weight:600;text-decoration:none;box-sizing:border-box\">Resolving variables correctly in `proxy_pass`<\/a><\/div>\n<div class=\"wh-toc-item\" style=\"display:block;min-width:0;margin:0;padding:0\"><a class=\"wh-toc-link\" href=\"#dynamische-upstreams\" style=\"display:block;height:100%;padding:12px 15px;border:1px solid #dce6e8;border-radius:9px;background:#fff;color:#18575b;font-size:14px;line-height:1.5;font-weight:600;text-decoration:none;box-sizing:border-box\">Configuring Dynamic Upstreams with `resolve`<\/a><\/div>\n<div class=\"wh-toc-item\" style=\"display:block;min-width:0;margin:0;padding:0\"><a class=\"wh-toc-link\" href=\"#sicher-ausrollen\" style=\"display:block;height:100%;padding:12px 15px;border:1px solid #dce6e8;border-radius:9px;background:#fff;color:#18575b;font-size:14px;line-height:1.5;font-weight:600;text-decoration:none;box-sizing:border-box\">Carefully Verify the Configuration and Roll It Out<\/a><\/div>\n<div class=\"wh-toc-item\" style=\"display:block;min-width:0;margin:0;padding:0\"><a class=\"wh-toc-link\" href=\"#resolver-fehler-eingrenzen\" style=\"display:block;height:100%;padding:12px 15px;border:1px solid #dce6e8;border-radius:9px;background:#fff;color:#18575b;font-size:14px;line-height:1.5;font-weight:600;text-decoration:none;box-sizing:border-box\">Systematically Narrowing Down Typical Resolver Errors<\/a><\/div>\n<div class=\"wh-toc-item\" style=\"display:block;min-width:0;margin:0;padding:0\"><a class=\"wh-toc-link\" href=\"#betriebsentscheidung\" style=\"display:block;height:100%;padding:12px 15px;border:1px solid #dce6e8;border-radius:9px;background:#fff;color:#18575b;font-size:14px;line-height:1.5;font-weight:600;text-decoration:none;box-sizing:border-box\">Select a resolver strategy for operation<\/a><\/div>\n<\/div><\/nav><section class=\"wh-section\" aria-labelledby=\"resolver-grundlagen\" style=\"display:block;margin:0 0 36px;min-width:0\"><h2 id=\"resolver-grundlagen\" style=\"margin:38px 0 18px;color:#172f41;font-size:clamp(24px,1.25rem + 1vw,30px);font-weight:700;line-height:1.3;scroll-margin-top:115px\">Understanding the NGINX Resolver and DNS Cache<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">A reverse proxy first needs an IP address for a backend with a hostname. The <strong style=\"font-weight:700;color:inherit\">NGINX Resolver<\/strong> It queries the name servers specified in the configuration. The DNS response is cached so that NGINX does not have to resolve the name again for every request during its validity period. This cache applies exclusively to name resolution for the target system. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">The Directive <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">resolver<\/code> contains one or more resolver addresses or supported resolver identifiers. Unless a different port is specified, NGINX uses port 53; if multiple servers are listed, requests are routed using the round-robin method, according to the documentation. For a robust bootstrap configuration, static IP addresses are often preferable because their resolution does not depend on DNS itself. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">By default, NGINX takes into account both IPv4 and IPv6 addresses associated with a name. This is appropriate if the network reliably transmits both protocol families all the way to the backend. Parameters such as <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">ipv4=off<\/code> or <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">ipv6=off<\/code> They specifically exclude a family, but they are not a general cache optimization. Whether they are necessary depends on the accessibility of the specific backend, not on the mere existence of an AAAA record. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">The resolver is neither a full-fledged recursive DNS server nor does it automatically adopt all settings from <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">\/etc\/resolv.conf<\/code>. NGINX uses the explicitly specified name servers. For internal zones and production backend names, these should be trusted, appropriately secured resolvers within your own network. This ensures that responsibility for private names and protection against manipulated DNS responses remain within a controllable infrastructure. <\/p>\n<\/section><section class=\"wh-section\" aria-labelledby=\"cache-arten-abgrenzen\" style=\"display:block;margin:0 0 36px;min-width:0\"><h2 id=\"cache-arten-abgrenzen\" style=\"margin:38px 0 18px;color:#172f41;font-size:clamp(24px,1.25rem + 1vw,30px);font-weight:700;line-height:1.3;scroll-margin-top:115px\">A DNS cache is not an HTTP cache<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">The resolver's DNS response cache stores mappings between names and DNS responses, such as A or AAAA addresses. Its purpose is to enable the resolver to reach a backend again without having to repeat the name resolution process each time. Therefore, if a backend IP address changes, the validity of the DNS response is what matters\u2014not the content of a previously delivered HTTP response. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Separately, it stores <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">proxy_cache<\/code> HTTP responses from an upstream server. Depending on the configuration, the key may include, for example, the URI, host, or header; a match returns a previously cached response to the client. Problems here can manifest as outdated pages, incorrect variants, or unexpected cache hits. This function does not determine which IP address NGINX uses when establishing a new backend connection. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">The open-file cache is a third-level cache: It stores file information and open descriptors for local file system accesses, but neither DNS responses nor HTTP content. Anyone who wants to learn more about this distinction in the context of static delivery can find it in the article on <a href=\"https:\/\/webhosting.de\/en\/nginx-cache-optimization-window\/\">Configuring the NGINX Open File Cache<\/a>. However, it does not provide a basis for deciding on a resolver TTL.<\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Flushing, purging, or resetting an HTTP cache therefore does not speed up a DNS change. Conversely, a new DNS resolution does not correct an incorrectly cached HTTP response. With a reverse proxy, the <strong style=\"font-weight:700;color:inherit\">DNS Cache<\/strong> It also relies on names and addresses: It neither checks the health of an application nor does it replace load balancing, retries, or proper timeout planning for the upstream.  <\/p>\n<\/section><section class=\"wh-section\" aria-labelledby=\"laufzeitauflosung-und-versionen\" style=\"display:block;margin:0 0 36px;min-width:0\"><h2 id=\"laufzeitauflosung-und-versionen\" style=\"margin:38px 0 18px;color:#172f41;font-size:clamp(24px,1.25rem + 1vw,30px);font-weight:700;line-height:1.3;scroll-margin-top:115px\">When NGINX Needs to Resolve Names Again<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">NGINX may already know a hostname when it reads the configuration. The situation is different for a variable target, such as <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">proxy_pass http:\/\/$backend;<\/code>. NGINX first searches for the resulting name in defined upstream groups. If it does not find a matching name there, it requires a configured resolver at runtime to determine the destination address. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">The message <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">no resolver defined<\/code> In this context, it does not indicate a missing HTTP cache. It means that NGINX does not know of a DNS server to perform the necessary runtime resolution. <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">resolver<\/code> may be used in the context of <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">http<\/code>, <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">server<\/code> or <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">location<\/code> are listed. A key entry in the <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">http<\/code>-Block is appropriate when multiple virtual hosts use the same resolver; a narrower scope is only suitable if the requirements actually differ.  <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">This runtime resolution, which has been available for a long time, should be distinguished from the dynamic updating of a classic upstream group. The resolver configuration directly in the <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">upstream<\/code>-block and <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">server hostname resolve<\/code> According to the NGINX documentation, these features are available in the open-source version starting with version 1.27.3. Older open-source installations should not be assumed to support this pattern automatically; historically, some of these features were reserved for NGINX Plus. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Before planning dynamic upstreams, check the installed output and build information. The following command displays the NGINX version, the compiler version, and the `configure` parameters used during the build. <\/p>\n<div class=\"wh-code-window\" data-wh-code style=\"margin:28px 0 34px;border:1px solid #2c4656;border-radius:12px;overflow:hidden;background:#132a3b;box-shadow:0 9px 25px -13px rgba(15,35,55,.2)\"><div class=\"wh-code-toolbar\" style=\"display:flex;flex-wrap:wrap;align-items:center;justify-content:space-between;gap:10px;padding:11px 16px;background:#223e50;color:#edf5fa;font-size:13px;line-height:1.5;font-weight:600\"><span>Code<\/span><button type=\"button\" class=\"wh-code-copy\" data-wh-copy hidden style=\"padding:6px 11px;border:1px solid #7893a1;border-radius:6px;background:transparent;color:#fff;font-size:12px;line-height:1.5;font-weight:600;cursor:pointer\">Copy code<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Copied<\/span><span data-wh-copy-fallback hidden>Code highlighted\u2014please copy<\/span><\/div><pre class=\"wh-code\" data-no-translation translate=\"no\" style=\"display:block;margin:0;padding:20px;max-width:100%;overflow-x:auto;color:#edf5fa;background:#132a3b;font:14px\/1.75 ui-monospace,SFMono-Regular,Menlo,Consolas,monospace;white-space:pre;direction:ltr;text-align:left\"><code class=\"language-text\" style=\"font:inherit;color:inherit;background:transparent;padding:0;border:0;white-space:inherit\">nginx -V<\/code><\/pre><\/div><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">For critical deployments, compare the displayed status with the documentation for the specific package being used and its provider. The key factor is whether this installation documents and provides the required functionality. Only then is a <strong style=\"font-weight:700;color:inherit\">dynamic upstream<\/strong> A robust architectural decision. <\/p>\n<\/section><section class=\"wh-section\" aria-labelledby=\"ttl-und-valid-planen\" style=\"display:block;margin:0 0 36px;min-width:0\"><h2 id=\"ttl-und-valid-planen\" style=\"margin:38px 0 18px;color:#172f41;font-size:clamp(24px,1.25rem + 1vw,30px);font-weight:700;line-height:1.3;scroll-margin-top:115px\">Explicitly set TTL and valid<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Without any additional configuration, the NGINX resolver cache follows the <strong style=\"font-weight:700;color:inherit\">DNS-TTL<\/strong> in the response from the queried nameserver. If the authoritative DNS operator changes the IP address of a backend, NGINX uses the previous response until its TTL expires. Only when name resolution is required again afterward does NGINX query the resolver once more. This ensures that the validity period remains controllable at the point where the name data is maintained. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">The parameter <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">valid<\/code> completely replaces this TTL with the configured time period. In other words, it does not set an upper limit on the DNS TTL, nor does it define a regular refresh in addition to the TTL. A value of <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">valid=30s<\/code> It can shorten a longer DNS TTL, but it can also extend a TTL that was intentionally set to be short. This must align with the backend's migration and deployment plans. <\/p>\n<figure class=\"wp-block-image size-large wh-figure\" aria-describedby=\"wh-caption-detail1\" style=\"display:block;float:none;clear:both;width:100%;max-width:760px;margin:34px auto 40px;border:1px solid #dae5e9;border-radius:14px;overflow:hidden;background:#f5f8fa;box-shadow:0 10px 28px -17px rgba(24,47,60,.28);box-sizing:border-box\"><div class=\"wh-figure-media\" style=\"display:block;background:#eef3f5;line-height:0\"><img loading=\"lazy\" width=\"800\" height=\"534\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-dns-ttl-valid-entscheidung-219e8485-detail1-c640f6c4f5-1024x683.webp\" class=\"wp-image-21662\" alt=\"Illustration showing the effect of DNS-TTL and &quot;valid&quot; on the cache duration in the NGINX resolver.\" decoding=\"async\" srcset=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-dns-ttl-valid-entscheidung-219e8485-detail1-c640f6c4f5-1024x683.webp 1024w, https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-dns-ttl-valid-entscheidung-219e8485-detail1-c640f6c4f5-300x200.webp 300w, https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-dns-ttl-valid-entscheidung-219e8485-detail1-c640f6c4f5-768x512.webp 768w, https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-dns-ttl-valid-entscheidung-219e8485-detail1-c640f6c4f5-18x12.webp 18w, https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-dns-ttl-valid-entscheidung-219e8485-detail1-c640f6c4f5.webp 1536w\" sizes=\"auto, (max-width: 800px) 100vw, 800px\" ><\/div><figcaption class=\"wh-caption\" id=\"wh-caption-detail1\" style=\"display:block;margin:0;padding:12px 18px 15px;border-top:1px solid #dce5e9;color:#506575;background:#f5f8fa;font-size:14px;line-height:1.55;text-align:start\">DNS TTL and a \"valid\" override determine, in different ways, how long responses are used.<\/figcaption><\/figure><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">If the zone is maintained reliably, a configuration without an override is the appropriate starting point. The address in the example is selected based on the networks described in the documentation and must not be used as a production resolver. Instead, enter the address of an accessible and trusted DNS resolver from your own network.<\/p>\n<div class=\"wh-code-window\" data-wh-code style=\"margin:28px 0 34px;border:1px solid #2c4656;border-radius:12px;overflow:hidden;background:#132a3b;box-shadow:0 9px 25px -13px rgba(15,35,55,.2)\"><div class=\"wh-code-toolbar\" style=\"display:flex;flex-wrap:wrap;align-items:center;justify-content:space-between;gap:10px;padding:11px 16px;background:#223e50;color:#edf5fa;font-size:13px;line-height:1.5;font-weight:600\"><span>Code<\/span><button type=\"button\" class=\"wh-code-copy\" data-wh-copy hidden style=\"padding:6px 11px;border:1px solid #7893a1;border-radius:6px;background:transparent;color:#fff;font-size:12px;line-height:1.5;font-weight:600;cursor:pointer\">Copy code<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Copied<\/span><span data-wh-copy-fallback hidden>Code highlighted\u2014please copy<\/span><\/div><pre class=\"wh-code\" data-no-translation translate=\"no\" style=\"display:block;margin:0;padding:20px;max-width:100%;overflow-x:auto;color:#edf5fa;background:#132a3b;font:14px\/1.75 ui-monospace,SFMono-Regular,Menlo,Consolas,monospace;white-space:pre;direction:ltr;text-align:left\"><code class=\"language-nginx\" style=\"font:inherit;color:inherit;background:transparent;padding:0;border:0;white-space:inherit\">resolver 192.0.2.53;\nresolver_timeout 5s;<\/code><\/pre><\/div><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">An override may be useful if the DNS TTL cannot be adjusted and there is a documented operational policy. In that case, the override explicitly shows how long NGINX caches responses. It is not a general performance optimization: Shorter times can trigger more DNS queries, while longer times can delay the switch to new backend addresses. <\/p>\n<div class=\"wh-code-window\" data-wh-code style=\"margin:28px 0 34px;border:1px solid #2c4656;border-radius:12px;overflow:hidden;background:#132a3b;box-shadow:0 9px 25px -13px rgba(15,35,55,.2)\"><div class=\"wh-code-toolbar\" style=\"display:flex;flex-wrap:wrap;align-items:center;justify-content:space-between;gap:10px;padding:11px 16px;background:#223e50;color:#edf5fa;font-size:13px;line-height:1.5;font-weight:600\"><span>Code<\/span><button type=\"button\" class=\"wh-code-copy\" data-wh-copy hidden style=\"padding:6px 11px;border:1px solid #7893a1;border-radius:6px;background:transparent;color:#fff;font-size:12px;line-height:1.5;font-weight:600;cursor:pointer\">Copy code<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Copied<\/span><span data-wh-copy-fallback hidden>Code highlighted\u2014please copy<\/span><\/div><pre class=\"wh-code\" data-no-translation translate=\"no\" style=\"display:block;margin:0;padding:20px;max-width:100%;overflow-x:auto;color:#edf5fa;background:#132a3b;font:14px\/1.75 ui-monospace,SFMono-Regular,Menlo,Consolas,monospace;white-space:pre;direction:ltr;text-align:left\"><code class=\"language-nginx\" style=\"font:inherit;color:inherit;background:transparent;padding:0;border:0;white-space:inherit\">resolver 192.0.2.53 valid=30s;\nresolver_timeout 5s;<\/code><\/pre><\/div><div class=\"wh-table-scroll\" tabindex=\"0\" role=\"region\" aria-label=\"Initial decisions for DNS TTL and valid\" style=\"width:100%;max-width:100%;overflow-x:auto;margin:28px 0;border:1px solid #dce5e9;border-radius:14px;background:#fff;box-shadow:0 10px 28px -16px rgba(24,47,60,.32);box-sizing:border-box\"><table style=\"width:100%;min-width:580px;border-collapse:separate;border-spacing:0;border:0;margin:0;font-size:15px;line-height:1.6;background:#fff\"><caption style=\"padding:20px;text-align:start;font-size:17px;line-height:1.5;font-weight:700;color:#173246;background:#fff\">Initial decisions for DNS TTL and valid<\/caption><thead><tr><th scope=\"col\" style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#19394d;color:#fff\">Operational Situation<\/th><th scope=\"col\" style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#19394d;color:#fff\">Initial Decision<\/th><th scope=\"col\" style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#19394d;color:#fff\">Reason<\/th><th scope=\"col\" style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#19394d;color:#fff\">Risk<\/th><\/tr><\/thead><tbody><tr><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#fff;color:#294252\">DNS zone with properly maintained TTLs<\/td><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#fff;color:#294252\">Omit \"valid\"<\/td><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#fff;color:#294252\">NGINX follows the cache duration specified by the DNS.<\/td><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#fff;color:#294252\">The TTL must match the modification window.<\/td><\/tr><tr><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#f4f7f9;color:#294252\">TTL cannot be controlled; changes are rare<\/td><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#f4f7f9;color:#294252\">Document \"valid\" explicitly<\/td><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#f4f7f9;color:#294252\">The holding period for the proxy can now be planned.<\/td><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#f4f7f9;color:#294252\">Old destination addresses can be used for longer than intended by the DNS.<\/td><\/tr><tr><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#fff;color:#294252\">Frequent service or container changes<\/td><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#fff;color:#294252\">Prefer short TTLs in authoritative DNS<\/td><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#fff;color:#294252\">The DNS remains the primary source for up-to-date information.<\/td><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#fff;color:#294252\">More queries can put a strain on the resolver infrastructure.<\/td><\/tr><tr><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#f4f7f9;color:#294252\">DNS-Based Service Discovery<\/td><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#f4f7f9;color:#294252\">Check Dynamic Upstream with resolve<\/td><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#f4f7f9;color:#294252\">Upstream members can track DNS changes.<\/td><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#f4f7f9;color:#294252\">The version and architecture must support the feature.<\/td><\/tr><\/tbody><\/table><\/div><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">The decision therefore does not begin with a specific number of seconds, but rather with the question of who controls DNS data and how quickly a backend change must take effect. <strong style=\"font-weight:700;color:inherit\">valid<\/strong> is a deliberate modification to this rule. It is not suitable as a blanket solution to speed up the reverse proxy or to mask DNS issues. <\/p>\n<\/section><section class=\"wh-section\" aria-labelledby=\"variabler-proxy-pass\" style=\"display:block;margin:0 0 36px;min-width:0\"><h2 id=\"variabler-proxy-pass\" style=\"margin:38px 0 18px;color:#172f41;font-size:clamp(24px,1.25rem + 1vw,30px);font-weight:700;line-height:1.3;scroll-margin-top:115px\">Resolving variables correctly in `proxy_pass`<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Contains <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">proxy_pass<\/code> If the hostname is a variable, NGINX must process the resulting hostname at runtime. First, NGINX searches for a matching upstream group; if it does not find one, it requires a configured resolver for the name. If one is missing, the typical message is <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">no resolver defined<\/code> This is not a reference to an HTTP cache, but rather to the missing DNS configuration for this execution path. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">The following example deliberately highlights the runtime resolution. The resolver is located in the <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">http<\/code>-context and therefore applies to multiple virtual hosts, unless a more specific setting overrides it. The documentation address used must be replaced by the internal resolver of the respective environment. <\/p>\n<div class=\"wh-code-window\" data-wh-code style=\"margin:28px 0 34px;border:1px solid #2c4656;border-radius:12px;overflow:hidden;background:#132a3b;box-shadow:0 9px 25px -13px rgba(15,35,55,.2)\"><div class=\"wh-code-toolbar\" style=\"display:flex;flex-wrap:wrap;align-items:center;justify-content:space-between;gap:10px;padding:11px 16px;background:#223e50;color:#edf5fa;font-size:13px;line-height:1.5;font-weight:600\"><span>Code<\/span><button type=\"button\" class=\"wh-code-copy\" data-wh-copy hidden style=\"padding:6px 11px;border:1px solid #7893a1;border-radius:6px;background:transparent;color:#fff;font-size:12px;line-height:1.5;font-weight:600;cursor:pointer\">Copy code<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Copied<\/span><span data-wh-copy-fallback hidden>Code highlighted\u2014please copy<\/span><\/div><pre class=\"wh-code\" data-no-translation translate=\"no\" style=\"display:block;margin:0;padding:20px;max-width:100%;overflow-x:auto;color:#edf5fa;background:#132a3b;font:14px\/1.75 ui-monospace,SFMono-Regular,Menlo,Consolas,monospace;white-space:pre;direction:ltr;text-align:left\"><code class=\"language-nginx\" style=\"font:inherit;color:inherit;background:transparent;padding:0;border:0;white-space:inherit\">http {\n    resolver 192.0.2.53;\n    resolver_timeout 5s;\n\n    server {\n        listen 80;\n\n        location \/ {\n            set $backend api.internal.example;\n            proxy_pass http:\/\/$backend;\n        }\n    }\n}<\/code><\/pre><\/div><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">The Directive <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">resolver_timeout<\/code> does not control the cache duration. It limits how long NGINX waits for a name resolution; the documented default is 30 seconds. The choice falls under the category of error budgets: A value that is too high can delay a failed request until an error response is returned, while a value that is too low can cause avoidable resolution errors when internal resolvers are temporarily slow. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">For a single, clearly defined location, the resolver can be used in the <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">location<\/code>-block. If multiple locations or servers require the same resolution, a common scope in the <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">server<\/code>- or <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">http<\/code>-Block requires less maintenance. NGINX allows this directive in all three contexts; its scope should reflect the actual operational structure, not just serve to temporarily resolve a single error message. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Even with variable targets, DNS timeouts and connections to the backend remain separate error categories. Successful name resolution does not prove that the target port is reachable or that the application is responding. Conversely, a longer upstream timeout does not resolve an unreachable resolver address. <\/p>\n<\/section><section class=\"wh-section\" aria-labelledby=\"dynamische-upstreams\" style=\"display:block;margin:0 0 36px;min-width:0\"><h2 id=\"dynamische-upstreams\" style=\"margin:38px 0 18px;color:#172f41;font-size:clamp(24px,1.25rem + 1vw,30px);font-weight:700;line-height:1.3;scroll-margin-top:115px\">Configuring Dynamic Upstreams with `resolve`<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">For a named backend group, a dynamic upstream may be more readable than a variable target value in each location. This pattern separates the definition of backend members from the routing: <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">proxy_pass<\/code> refers to the group, while the hostname in the upstream can be updated via DNS. This is particularly useful when multiple routes point to the same application. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">The parameter <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">resolve<\/code> for a <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">server<\/code>-This entry has existed since NGINX 1.5.12. However, according to the documentation, it is only available in the NGINX Open Source version starting with 1.27.3; prior to that, this feature was commercially restricted. The resolver configuration directly in the <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">upstream<\/code>-Block is documented for open source starting with version 1.27.3. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">The <strong style=\"font-weight:700;color:inherit\">Shared Memory Zone<\/strong> It is neither a cache timeout nor a DNS data path. It provides shared memory within NGINX that is required for dynamically changing upstream configurations. If NGINX resolves the DNS and finds other addresses for the name, the upstream group can be adjusted based on this internally managed state without a restart. <\/p>\n<figure class=\"wp-block-image size-large wh-figure\" aria-describedby=\"wh-caption-detail2\" style=\"display:block;float:none;clear:both;width:100%;max-width:760px;margin:34px auto 40px;border:1px solid #dae5e9;border-radius:14px;overflow:hidden;background:#f5f8fa;box-shadow:0 10px 28px -17px rgba(24,47,60,.28);box-sizing:border-box\"><div class=\"wh-figure-media\" style=\"display:block;background:#eef3f5;line-height:0\"><img loading=\"lazy\" width=\"800\" height=\"534\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-dynamischer-upstream-resolve-219e8485-detail2-f2a645bcd2-1024x683.webp\" class=\"wp-image-21663\" alt=\"Conceptual diagram of a dynamic NGINX upstream with a separate DNS resolver, internal shared-memory state, and backend addresses.\" decoding=\"async\" srcset=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-dynamischer-upstream-resolve-219e8485-detail2-f2a645bcd2-1024x683.webp 1024w, https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-dynamischer-upstream-resolve-219e8485-detail2-f2a645bcd2-300x200.webp 300w, https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-dynamischer-upstream-resolve-219e8485-detail2-f2a645bcd2-768x512.webp 768w, https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-dynamischer-upstream-resolve-219e8485-detail2-f2a645bcd2-18x12.webp 18w, https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-dynamischer-upstream-resolve-219e8485-detail2-f2a645bcd2.webp 1536w\" sizes=\"auto, (max-width: 800px) 100vw, 800px\" ><\/div><figcaption class=\"wh-caption\" id=\"wh-caption-detail2\" style=\"display:block;margin:0;padding:12px 18px 15px;border-top:1px solid #dce5e9;color:#506575;background:#f5f8fa;font-size:14px;line-height:1.55;text-align:start\">The shared-memory zone manages upstream state within NGINX; DNS resolution and backend connections remain separate.<\/figcaption><\/figure><div class=\"wh-code-window\" data-wh-code style=\"margin:28px 0 34px;border:1px solid #2c4656;border-radius:12px;overflow:hidden;background:#132a3b;box-shadow:0 9px 25px -13px rgba(15,35,55,.2)\"><div class=\"wh-code-toolbar\" style=\"display:flex;flex-wrap:wrap;align-items:center;justify-content:space-between;gap:10px;padding:11px 16px;background:#223e50;color:#edf5fa;font-size:13px;line-height:1.5;font-weight:600\"><span>Code<\/span><button type=\"button\" class=\"wh-code-copy\" data-wh-copy hidden style=\"padding:6px 11px;border:1px solid #7893a1;border-radius:6px;background:transparent;color:#fff;font-size:12px;line-height:1.5;font-weight:600;cursor:pointer\">Copy code<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Copied<\/span><span data-wh-copy-fallback hidden>Code highlighted\u2014please copy<\/span><\/div><pre class=\"wh-code\" data-no-translation translate=\"no\" style=\"display:block;margin:0;padding:20px;max-width:100%;overflow-x:auto;color:#edf5fa;background:#132a3b;font:14px\/1.75 ui-monospace,SFMono-Regular,Menlo,Consolas,monospace;white-space:pre;direction:ltr;text-align:left\"><code class=\"language-nginx\" style=\"font:inherit;color:inherit;background:transparent;padding:0;border:0;white-space:inherit\">http {\n    resolver 192.0.2.53;\n    resolver_timeout 5s;\n\n    upstream application_pool {\n        zone application_pool 64k;\n        server app.internal.example resolve;\n    }\n\n    server {\n        listen 80;\n\n        location \/ {\n            proxy_pass http:\/\/application_pool;\n        }\n    }\n}<\/code><\/pre><\/div><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">As with all examples, <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">192.0.2.53<\/code> only for a documentation address. In practice, the registered resolver must reliably recognize internal names, be accessible from the NGINX network, and be considered trustworthy. Before implementing the changes, you should also verify the actual functionality of the installed package rather than deriving the configuration solely from a current example. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">A service that is accessible exclusively via IPv4 may justify a targeted restriction: <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">resolver 192.0.2.53 ipv6=off;<\/code> Prevents AAAA queries and the selection of an IPv6 address for this resolver context. However, this is a network architecture decision. If dual-stack is functioning properly, IPv6 should not be disabled simply out of habit; by default, NGINX resolves both IP families. <\/p>\n<\/section><section class=\"wh-section\" aria-labelledby=\"sicher-ausrollen\" style=\"display:block;margin:0 0 36px;min-width:0\"><h2 id=\"sicher-ausrollen\" style=\"margin:38px 0 18px;color:#172f41;font-size:clamp(24px,1.25rem + 1vw,30px);font-weight:700;line-height:1.3;scroll-margin-top:115px\">Carefully Verify the Configuration and Roll It Out<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Before making a change, first check where the resolver directives actually apply. To do this, locate the active configuration\u2014including any included files\u2014and determine whether the resolver applies to the entire <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">http<\/code>-context, intended only for a single virtual host or a single path. A scope that is too narrow may prevent another variable proxy path from finding a resolver; conversely, a scope that is too broad makes it difficult to track changes later on. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Each adjustment is followed by the <strong style=\"font-weight:700;color:inherit\">Syntax Check<\/strong>. It reads the configuration and also attempts to open referenced files. This allows you to detect typos, invalid directives, and problems in include files before reloading. However, the check does not verify that the specified DNS server is reachable, knows the expected name, or that the backend behind a resolved address accepts connections. <\/p>\n<div class=\"wh-code-window\" data-wh-code style=\"margin:28px 0 34px;border:1px solid #2c4656;border-radius:12px;overflow:hidden;background:#132a3b;box-shadow:0 9px 25px -13px rgba(15,35,55,.2)\"><div class=\"wh-code-toolbar\" style=\"display:flex;flex-wrap:wrap;align-items:center;justify-content:space-between;gap:10px;padding:11px 16px;background:#223e50;color:#edf5fa;font-size:13px;line-height:1.5;font-weight:600\"><span>Code<\/span><button type=\"button\" class=\"wh-code-copy\" data-wh-copy hidden style=\"padding:6px 11px;border:1px solid #7893a1;border-radius:6px;background:transparent;color:#fff;font-size:12px;line-height:1.5;font-weight:600;cursor:pointer\">Copy code<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Copied<\/span><span data-wh-copy-fallback hidden>Code highlighted\u2014please copy<\/span><\/div><pre class=\"wh-code\" data-no-translation translate=\"no\" style=\"display:block;margin:0;padding:20px;max-width:100%;overflow-x:auto;color:#edf5fa;background:#132a3b;font:14px\/1.75 ui-monospace,SFMono-Regular,Menlo,Consolas,monospace;white-space:pre;direction:ltr;text-align:left\"><code class=\"language-text\" style=\"font:inherit;color:inherit;background:transparent;padding:0;border:0;white-space:inherit\">nginx -t\nnginx -s reload<\/code><\/pre><\/div><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Do not perform the reload until the check has been successfully completed. <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">nginx -s reload<\/code> This causes NGINX to start new workers with the new configuration and to gracefully terminate old workers. Depending on the installed package and operating system, the service manager provided by that system may trigger the reload instead. To do this, follow the documented installation procedure rather than using commands from an external environment. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Next, schedule a technical review during the designated change window. Compare the expected DNS TTL with the time at which a new backend address is to be used, and verify the service\u2019s reachability via the actually permitted IP family. Also document the resolver address, the selected scope, and any <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">valid<\/code>-Override. This makes it possible to determine, in the event of a malfunction, whether the cause is DNS, routing, or the application. <\/p>\n<\/section><section class=\"wh-section\" aria-labelledby=\"resolver-fehler-eingrenzen\" style=\"display:block;margin:0 0 36px;min-width:0\"><h2 id=\"resolver-fehler-eingrenzen\" style=\"margin:38px 0 18px;color:#172f41;font-size:clamp(24px,1.25rem + 1vw,30px);font-weight:700;line-height:1.3;scroll-margin-top:115px\">Systematically Narrowing Down Typical Resolver Errors<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Start troubleshooting the target expression in <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">proxy_pass<\/code>. If it contains a variable, NGINX must resolve the hostname it contains at runtime, unless that hostname belongs to a defined upstream group. The message <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">no resolver defined<\/code> therefore first points to a missing element or one that is not visible in the relevant context <strong style=\"font-weight:700;color:inherit\">Resolver Configuration<\/strong> . Add a trusted nameserver in the appropriate context instead of hastily replacing the hostname with a static IP address. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">If a resolver is configured, the next step is to check its address, network path, and authority for the zone in use. A public resolver cannot know internal names; an unreachable resolver, on the other hand, causes resolution timeouts. Also check whether the directive is overridden by a more specific setting. NGINX uses only the explicitly specified name servers; it does not automatically use all settings from <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">\/etc\/resolv.conf<\/code>. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">If an old destination address remains active after a DNS change, check the response TTL and whether a <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">valid<\/code>. A long override replaces the TTL of the DNS response and can delay the propagation of a change accordingly. The permissible correction is not a blanket rule of the shortest possible duration, but rather a value that is appropriate for the change window and the resilience of the DNS infrastructure; often, omitting <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">valid<\/code> the cleaner solution. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">If you experience connection problems after successfully resolving the address, disconnect DNS from the backend connection. Check whether A and AAAA responses are available and whether the destination is actually routed and reachable via IPv6. <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">ipv6=off<\/code> is only suitable for an architecture that is verifiably IPv4-only. A DNS timeout affects name resolution; a connection error to an already known IP address, on the other hand, points to a problem with routing, a firewall, a port, or an application. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">For dynamic upstreams, the version, shared-memory zone, and <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">resolve<\/code> are compatible. The documented open-source support for this applies starting with NGINX 1.27.3; older installations should not be treated as equivalent. <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">status_zone<\/code> Furthermore, API-based resolver statistics are not a general monitoring solution for NGINX Open Source, as the features mentioned pertain to commercial use cases. <\/p>\n<\/section><section class=\"wh-section\" aria-labelledby=\"betriebsentscheidung\" style=\"display:block;margin:0 0 36px;min-width:0\"><h2 id=\"betriebsentscheidung\" style=\"margin:38px 0 18px;color:#172f41;font-size:clamp(24px,1.25rem + 1vw,30px);font-weight:700;line-height:1.3;scroll-margin-top:115px\">Select a resolver strategy for operation<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">The right strategy doesn't start with a blanket cache value, but with DNS control and the rate of change. If your team can maintain the authoritative zone and if its TTLs realistically reflect the deployment window, then a <strong style=\"font-weight:700;color:inherit\">TTL-Controlled Resolution<\/strong> without <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">valid<\/code> is usually the most logical starting point. DNS then remains the authoritative source for determining how long a response is used. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">A deliberately placed <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">valid<\/code> This is an option if you can't control the TTL and can justify a different cache duration for operational reasons. Be sure to determine what level of downtime is acceptable: A longer value reduces the number of potential DNS queries, but may point to an address that is no longer valid after a move. It is neither an upper limit for the DNS TTL nor a general performance toggle. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Select the NGINX pattern based on the routing structure. A variable <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">proxy_pass<\/code> is suitable when the destination is determined at runtime for each request or configuration; this requires a resolver in the appropriate scope. For a named backend group with DNS-based address changes, an upstream with <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">zone<\/code> and <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">resolve<\/code> That's clear, provided that NGINX Open Source 1.27.3 or later is actually available. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Only then do you decide <strong style=\"font-weight:700;color:inherit\">Timeouts and IP Families<\/strong>. The resolver timeout must match the client and upstream timeouts so that a lack of a DNS response does not cause disproportionate delays. Enable IPv4 or IPv6 only as appropriate for your network architecture. Use only secure resolvers that can reliably respond to internal zones. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">DNS resolution and upstream keepalive serve different purposes. The resolver determines which backend address NGINX can use; keepalive maintains already established, inactive backend connections for reuse. A change to connection reuse therefore replaces neither TTL planning nor resolver checking. For sizing this connection layer, the article on <a href=\"https:\/\/webhosting.de\/en\/optimally-configuring-nginx-upstream-keepalive-for-a-reverse-proxy-network\/\">NGINX Upstream Keepalive<\/a> the resolver strategy.<\/p>\n<\/section><section class=\"wh-sources\" style=\"margin:40px 0 0;padding:24px 0 0;border-top:1px solid #dce5e9;color:#596b7b;font-size:14px;line-height:1.65\"><h2 style=\"margin:38px 0 18px;color:#172f41;font-size:clamp(24px,1.25rem + 1vw,30px);font-weight:700;line-height:1.3;scroll-margin-top:115px\">Sources and Current State of Knowledge<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Status of the research: <time datetime=\"2026-09-22\">2026-09-22<\/time><\/p><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Research date: September 22, 2026. The examples of dynamic upstreams with a resolver in the upstream block and the `server \u2026 resolve` directive in NGINX Open Source refer to the documented support starting with version 1.27.3; for distribution packages, the build and vendor documentation are also authoritative.<\/p><div class=\"wh-source-urls\"><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\"><span class=\"wh-source-url\" data-no-translation dir=\"ltr\" style=\"overflow-wrap:anywhere;font:12px\/1.6 ui-monospace,monospace;direction:ltr\">https:\/\/nginx.org\/en\/docs\/http\/ngx_http_core_module.html<\/span><\/p><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\"><span class=\"wh-source-url\" data-no-translation dir=\"ltr\" style=\"overflow-wrap:anywhere;font:12px\/1.6 ui-monospace,monospace;direction:ltr\">https:\/\/nginx.org\/en\/docs\/http\/ngx_http_upstream_module.html<\/span><\/p><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\"><span class=\"wh-source-url\" data-no-translation dir=\"ltr\" style=\"overflow-wrap:anywhere;font:12px\/1.6 ui-monospace,monospace;direction:ltr\">https:\/\/nginx.org\/en\/docs\/http\/ngx_http_proxy_module.html<\/span><\/p><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\"><span class=\"wh-source-url\" data-no-translation dir=\"ltr\" style=\"overflow-wrap:anywhere;font:12px\/1.6 ui-monospace,monospace;direction:ltr\">https:\/\/nginx.org\/en\/docs\/switches.html<\/span><\/p><\/div><\/section><\/div>","protected":false},"excerpt":{"rendered":"<p>Here's how to configure the NGINX resolver for dynamic backends: DNS TTL, valid, resolver_timeout, variable proxy_pass targets, and dynamic upstreams are clearly separated from one another.<\/p>","protected":false},"author":1,"featured_media":21661,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-21658","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,"surfer_file_name":null,"surfer_file_original_url":null,"_wp_attachment_image_alt":null,"litespeed-optimize-set":null,"litespeed-optimize-size":null,"_oembed_b5e1eb923ad3b086e579b1befcd4075c":null,"_elementor_source_image_hash":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,"_source_url":null,"_elementor_migrations_state_8b2d":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":"834","_wh_make_key":"wh_219e84857fe17178a13ef75220ad3e62","rank_math_internal_links_processed":"1","_wh_make_topic":"NGINX Resolver Cache richtig konfigurieren","_wh_make_input_keywords":["nginx resolver","dns cache nginx","reverse proxy"],"_wh_make_config":{"research_model":"gpt-5.6-terra","writer_model":"gpt-5.6-terra","review_model":"gpt-5.6-sol","image_model":"gpt-image-2.5-flare","image_quality":"medium","image_format":"webp","final_status":"draft","charts_enabled":true},"_wh_make_links":{"I1":{"id":"I1","post_id":20898,"url":"https:\/\/webhosting.de\/nginx-cache-optimierung-fenster\/","title":"Optimizing NGINX Open File Cache: How to Get More Performance Out of Your Server","excerpt":"NGINX Cache noticeably speeds up when I configure the Open File Cache specifically: It keeps file metadata and handles in memory, reducing the need for costly file system accesses. By setting appropriate values for `max`, `inactive`, `valid`, and `min_uses`, I optimize the delivery of static content for fast response times and lower I\/O load. Key Points Metadata Cache: Stores existence, size, timestamps, and handles instead of content Sizing: Balance between RAM usage, hit rate, and change rate Contexts: Ideal for images\/CSS\/JS; exclude dynamic paths Validation: Ensure up-to-date status with `open_file_cache_valid` Measurement: Check effects on latency, I\/O, and error rate What the Open File Cache Actually Stores With the Open File Cache, I do not cache file contents, but rather structured information: Does a file exist, how large is it, when was it modified, and which descriptor is already open? This information is available in memory and shortens the path to the next response. Every disk I\/O operation avoided reduces the I\/O load and conserves CPU time, which is especially important when dealing with many small files. According to the NGINX documentation, this feature includes open descriptors, directory information, and lookup errors. This speeds up directory scans and access paths that would otherwise have to go back to the disk with every request. I deliberately use this mechanism for directories that are accessed frequently, such as media libraries and build assets. The effect is particularly noticeable in projects with many assets, where the file system would otherwise become a bottleneck. The cache noticeably reduces system calls like `stat()`, `open()`, and `readdir()`. At the same time, control remains finely granular because I define the scope and validity of the entries separately. This allows me to keep the data up to date without losing the benefits of caching. When the Open File Cache Is Worth It I enable the cache specifically for static content delivery: images, CSS, JavaScript, fonts, and downloads. In dynamic areas like login pages, shopping carts, or personalized routes, I avoid using it\u2014different rules apply there. WordPress and headless front ends benefit greatly because themes, plugins, and B"},"I2":{"id":"I2","post_id":21613,"url":"https:\/\/webhosting.de\/nginx-upstream-keepalive-optimal-konfigurieren-reverse-proxy-netzwerk\/","title":"Optimally Configuring NGINX Upstream Keepalive for Maximum Performance as a Reverse Proxy","excerpt":"I configure NGINX Upstream Keepalive so that the reverse proxy establishes fewer connections, delivers lower latency, and reliably handles traffic spikes. In doing so, I specifically adjust the pool size, timeouts, and headers to ensure that connections are reused and the data path remains streamlined. Key Points: Enforce HTTP\/1.1 and clean up Connection headers; correctly size keepalive per worker; adjust timeouts to backend values; limit and recycle requests\/connection and recycle them Monitor connection rate and latency Why upstream keepalive drastically reduces connection overhead Without connection reuse, NGINX opens a new backend connection for each request, which incurs extra handshakes, more CPU cycles, and additional kernel resources; this is exactly where Keepalive comes in. I have NGINX cache already established, currently idle sockets and use 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. Especially with TLS connections to the backend, I save a noticeable amount of time by reusing sessions. This ensures that the response chain remains reliable and responsive even at high throughput. Basic Principle and the `keepalive` Directive in the Upstream The `keepalive` directive in the `upstream` block limits the number of cached, idle backend connections 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 unused 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 configuration\u2014which surprises many admins at first. upstream backend_pool { server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080; keepalive 32; # idle connections per worker keepalive_requests 1000; # Recycling after N requests keepalive_timeout 60s; # Idle lifetime } server { listen 80; location \/ { proxy_pass http:\/\/backend_pool; proxy_http_version 1."},"I3":{"id":"I3","post_id":21371,"url":"https:\/\/webhosting.de\/nginx-cache-purge-richtig-einsetzen-fastcgi-cache-optimierung-cloud\/","title":"Using NGINX Cache Purge Correctly: A Practical Guide to Fast and Secure Cache Invalidation","excerpt":"I\u2019ll show you how to flush the Nginx cache selectively without serving visitors outdated responses or risking security vulnerabilities. Using clear purge strategies, clean cache keys, and secure automation, I\u2019ll set up a workflow that keeps WordPress and PHP-FPM fast and up to date. Key Points Plan cache keys carefully: host, URI, headers, and necessary cookies Combine purge strategies: expiration times, targeted keys, controlled purges Always prioritize security: internal IPs, authentication, logging, no open endpoints Use automation: WordPress hooks and deployment triggers for purges Enable monitoring: X-FastCGI-Cache, logs, cache sizes Understand NGINX caching: the foundation for effective purging Before I purge, I understand how NGINX stores data. NGINX serves HTTP backends via a proxy cache and dynamic PHP responses via the FastCGI cache; there are also variants like uWSGI or SCGI for special setups, which I\u2019ll only touch on here. In typical WordPress or PHP stacks, the FastCGI cache in particular has the greatest impact because it writes finished HTML pages from PHP-FPM to the file system and serves them directly on the next request. This reduces CPU and database load and shortens response times, as long as the content is up to date. This is precisely where smart purging determines whether users receive fresh responses or see outdated pages. Cache Keys: The Key to Targeted Purging Every hit is based on a cache key, which usually consists of the host, request URI, relevant headers, and minimal cookie components. I design the key so that it only accounts for differences that actually change the HTML output; otherwise, I unnecessarily fragment the cache. I use Vary headers, language, or device classes sparingly and use test requests to verify whether the desired variation is truly needed. A consistent key makes it possible later to remove only those objects affected by a change, rather than deleting large directories. Clean keys save I\/O, keep the hit rate high, and make purge requests much easier. Cache Key Design in Practice: Normalization and Reduction In practice, I normalize the"}},"_wh_make_stage":"entwurf","_wh_make_research_date":"2026-09-22","_wh_make_sitemap_info":{"index":"https:\/\/webhosting.de\/sitemap_index.xml","sitemaps":["https:\/\/webhosting.de\/post-sitemap1.xml","https:\/\/webhosting.de\/post-sitemap2.xml","https:\/\/webhosting.de\/post-sitemap3.xml","https:\/\/webhosting.de\/post-sitemap4.xml"],"url_count":3093,"fetched_at":"2026-09-22T12:46:54+00:00","selected_ids":[20898,21613,21371]},"_wh_make_draft_hash":"5b351e82d8899903abedab15952a73228481053c80797bd235b6a3f2315ceb53","_wh_make_work":{"version":"2.1","identity":{"sheet_ref":"1VMjxV8Q73i0Q1HO6s-u4jNHVRF0snliGCeg97intLPs","sheet_name":"Tabellenblatt1","external_id":"1387","topic":"NGINX Resolver Cache richtig konfigurieren","keywords":["nginx resolver","dns cache nginx","reverse proxy"],"category_input":"834"},"config":{"research_model":"gpt-5.6-terra","writer_model":"gpt-5.6-terra","review_model":"gpt-5.6-sol","image_model":"gpt-image-2.5-flare","image_quality":"medium","image_format":"webp","final_status":"draft","charts_enabled":true},"phase":"done","pending":null,"receipts":{"7e2b1c513e60dc0ba4a63225a6044a84":"de77a5847626e5c876c14c4f815bef4badfdcd266cea5e88e0accad643c0bb5d","baaff9ded58232ae66eefb69d24f634e":"1de8b750fffb4e7bc3f6e08fb4b784a4a37fc714fb953a039e4c301a3a799453","169d5bbdbed22beabba6ffd2f26f331f":"f1b3117662de6dfd95b9b1599d26b61ee6fe48feb64749a81c2f66adef2d2f8d","cffcc92b8528af841e1fe3ddc05b65de":"0d7578a35e52e215d83d12725209c5d9e67e20cfa56386cf33fc0cad9552e012","4212988fd5f83721f7803df991538ab6":"07548f1498cd2ff743ebd6de5ea94f0efe6bce4eeb3fe37290271cb6f4a00cb4","c1e970624062326f7482251bcbb892c2":"94a73b305e5f9d30fe2dcc46ea0c1e18b8a13055c5c047265b9f2df7a36f67cf","568d0ea3d1deac494745ac14c07e6912":"0e7ef4c09976d53d4b9c908e42d9d2b8a90442f48fb935a7c77de499047bcb62","c7ecb2035315905ecac2f6b1fa84e5b0":"041b86b66ff6c263dec39b1ff1c062e6afb4c0150d964bdcfc94a005dee868b4","7b3776cd29d1e9a3b809afafa4813481":"b153b9bc646a106169b81d2a4addfc33670e8ea0072351131d5e9b6c7c2d9b97","5b5e1b21bffe4a0bfdb7dfd48920901e":"7f9a3c595c20b29f3eb962068f54be9dce587c6e52117aefc538465740a6d460","7594b20fccaef84f9a91fe8c3840a2e2":"369f0a2aac21f66f4bee5e8a351ee1f9382324980b8f763582d334e8fdca47e5","79237b042532b66151636fda1da9df14":"72c7d4c25bd38451c5dc13d52496f2d2f59599185f91356943dedc96a77aa68b","4d0c489e203812f39a130fa88633e22f":"364f1c1b9fd0a29791ba483710d68ad5ff25b0de292d1a2d6e7259a19820a2c4"},"parts":{"1":[{"id":"resolver-grundlagen","heading":"NGINX Resolver und DNS-Cache verstehen","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Ein Reverse Proxy ben\u00f6tigt f\u00fcr ein Backend mit Hostnamen zun\u00e4chst eine IP-Adresse. Der ","ref":""},{"kind":"strong","text":"NGINX-Resolver","ref":""},{"kind":"text","text":" fragt daf\u00fcr die in der Konfiguration festgelegten Nameserver ab. Die erhaltene DNS-Antwort wird zwischengespeichert, damit NGINX den Namen w\u00e4hrend seiner G\u00fcltigkeitsdauer nicht f\u00fcr jede Anfrage erneut aufl\u00f6sen muss. Dieser Cache betrifft ausschlie\u00dflich die Namensaufl\u00f6sung zum Zielsystem.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Die Direktive ","ref":""},{"kind":"code","text":"resolver","ref":""},{"kind":"text","text":" enth\u00e4lt eine oder mehrere IPv4- oder IPv6-Adressen von DNS-Servern. Ohne abweichende Portangabe verwendet NGINX Port 53; bei mehreren eingetragenen Servern erfolgen die Anfragen laut Dokumentation im Round-Robin-Verfahren. Damit bestimmt die Konfiguration ausdr\u00fccklich, welche Resolver NGINX f\u00fcr diese Aufl\u00f6sung befragt.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Standardm\u00e4\u00dfig ber\u00fccksichtigt NGINX IPv4- und IPv6-Adressen eines Namens. Das ist passend, wenn das Netzwerk beide Protokollfamilien bis zum Backend zuverl\u00e4ssig transportiert. Parameter wie ","ref":""},{"kind":"code","text":"ipv4=off","ref":""},{"kind":"text","text":" oder ","ref":""},{"kind":"code","text":"ipv6=off","ref":""},{"kind":"text","text":" schlie\u00dfen eine Familie gezielt aus, sind aber keine allgemeine Cache-Optimierung. Ob sie erforderlich sind, entscheidet die Erreichbarkeit des konkreten Backends und nicht die blo\u00dfe Existenz eines AAAA-Records.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Der Resolver ist weder ein vollwertiger rekursiver DNS-Server noch eine automatische \u00dcbernahme aller Einstellungen aus ","ref":""},{"kind":"code","text":"\/etc\/resolv.conf","ref":""},{"kind":"text","text":". NGINX nutzt die explizit angegebenen Nameserver. F\u00fcr interne Zonen und produktive Backend-Namen sollten das vertrauensw\u00fcrdige, angemessen abgesicherte Resolver im eigenen Netzwerk sein. So bleiben Zust\u00e4ndigkeit f\u00fcr private Namen und Schutz vor manipulierten DNS-Antworten in einer kontrollierbaren Infrastruktur.","ref":""},{"kind":"citation","text":"","ref":"S1"}]}]},{"id":"cache-arten-abgrenzen","heading":"DNS-Cache ist kein HTTP-Cache","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Der DNS-Response-Cache des Resolvers speichert Zuordnungen zwischen Namen und DNS-Antworten, etwa A- oder AAAA-Adressen. Sein Zweck ist, ein Backend erneut erreichen zu k\u00f6nnen, ohne jede Namensaufl\u00f6sung wiederholen zu m\u00fcssen. \u00c4ndert sich eine Backend-IP, ist deshalb die G\u00fcltigkeit der DNS-Antwort relevant \u2013 nicht der Inhalt einer zuvor ausgelieferten HTTP-Antwort.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Davon getrennt speichert ","ref":""},{"kind":"code","text":"proxy_cache","ref":""},{"kind":"text","text":" HTTP-Responses eines Upstreams. Der Schl\u00fcssel umfasst je nach Konfiguration beispielsweise URI, Host oder Header; ein Treffer liefert eine bereits gespeicherte Antwort an den Client. Probleme zeigen sich hier als veraltete Seiten, falsche Varianten oder unerwartete Cache-Hits. Diese Funktion entscheidet nicht, welche IP NGINX beim Aufbau einer neuen Backend-Verbindung verwendet.","ref":""},{"kind":"citation","text":"","ref":"S3"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Der Open-File-Cache ist eine dritte Ebene: Er h\u00e4lt Dateiinformationen und offene Deskriptoren f\u00fcr lokale Dateisystemzugriffe vor, aber weder DNS-Antworten noch HTTP-Inhalte. Wer diese Abgrenzung f\u00fcr statische Auslieferung vertiefen m\u00f6chte, findet sie im Beitrag zur ","ref":""},{"kind":"internal_link","text":"Konfiguration des NGINX Open File Cache","ref":"I1"},{"kind":"text","text":". F\u00fcr die Wahl einer Resolver-TTL liefert er jedoch keine Entscheidungsgrundlage.","ref":""}]},{"type":"paragraph","runs":[{"kind":"text","text":"Das Leeren, Purgen oder Abstimmen eines HTTP-Caches beschleunigt daher keine DNS-\u00c4nderung. Umgekehrt behebt eine neue DNS-Aufl\u00f6sung keine fehlerhaft gecachte HTTP-Antwort. Beim Reverse Proxy begrenzt der ","ref":""},{"kind":"strong","text":"DNS-Cache","ref":""},{"kind":"text","text":" sich zudem auf Namen und Adressen: Er pr\u00fcft weder die Gesundheit einer Anwendung noch ersetzt er Load-Balancing, Retries oder die korrekte Timeout-Planung zum Upstream.","ref":""},{"kind":"citation","text":"","ref":"S1"},{"kind":"citation","text":"","ref":"S3"}]}]},{"id":"laufzeitauflosung-und-versionen","heading":"Wann NGINX Namen erneut aufl\u00f6sen muss","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Ein Hostname kann NGINX bereits beim Einlesen der Konfiguration bekannt sein. Anders ist der Fall bei einem variablen Ziel, etwa ","ref":""},{"kind":"code","text":"proxy_pass http:\/\/$backend;","ref":""},{"kind":"text","text":". NGINX sucht den resultierenden Namen zun\u00e4chst in definierten Upstream-Gruppen. Findet es dort keinen passenden Namen, braucht es zur Laufzeit einen konfigurierten Resolver, um die Zieladresse zu ermitteln.","ref":""},{"kind":"citation","text":"","ref":"S3"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Die Meldung ","ref":""},{"kind":"code","text":"no resolver defined","ref":""},{"kind":"text","text":" weist in diesem Zusammenhang nicht auf einen fehlenden HTTP-Cache hin. Sie bedeutet, dass NGINX f\u00fcr die notwendige Laufzeitaufl\u00f6sung keinen DNS-Server kennt. ","ref":""},{"kind":"code","text":"resolver","ref":""},{"kind":"text","text":" darf im Kontext ","ref":""},{"kind":"code","text":"http","ref":""},{"kind":"text","text":", ","ref":""},{"kind":"code","text":"server","ref":""},{"kind":"text","text":" oder ","ref":""},{"kind":"code","text":"location","ref":""},{"kind":"text","text":" stehen. Ein zentraler Eintrag im ","ref":""},{"kind":"code","text":"http","ref":""},{"kind":"text","text":"-Block eignet sich, wenn mehrere virtuelle Hosts denselben Resolver nutzen; ein engerer Scope passt nur bei tats\u00e4chlich abweichenden Anforderungen.","ref":""},{"kind":"citation","text":"","ref":"S1"},{"kind":"citation","text":"","ref":"S3"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Von dieser lang verf\u00fcgbaren Laufzeitaufl\u00f6sung ist die dynamische Aktualisierung einer klassischen Upstream-Gruppe zu trennen. Laut Dokumentation stehen die Resolver-Konfiguration direkt im ","ref":""},{"kind":"code","text":"upstream","ref":""},{"kind":"text","text":"-Block sowie ","ref":""},{"kind":"code","text":"server hostname resolve","ref":""},{"kind":"text","text":" in NGINX Open Source ab Version 1.27.3 zur Verf\u00fcgung. \u00c4ltere Open-Source-Installationen d\u00fcrfen nicht so behandelt werden, als unterst\u00fctzten sie dieses Muster automatisch; historisch waren entsprechende Funktionen teilweise NGINX Plus vorbehalten.","ref":""},{"kind":"citation","text":"","ref":"S2"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Vor der Planung dynamischer Upstreams pr\u00fcfst du die installierte Ausgabe und Build-Informationen. Der folgende Befehl zeigt die NGINX-Version sowie Kompilierungsoptionen.","ref":""}]},{"type":"code","language":"text","code":"nginx -V","source_ids":["S2"]},{"type":"paragraph","runs":[{"kind":"text","text":"Die sichtbare Versionsnummer ist dennoch nicht immer der vollst\u00e4ndige Nachweis f\u00fcr den Funktionsumfang: Distributionen k\u00f6nnen Sicherheits- oder Funktionspatches zur\u00fcckportieren. Vergleiche bei kritischen Deployments deshalb Paketdokumentation, Build und die f\u00fcr deine Installation geltende Herstellerinformation. Erst danach ist ein ","ref":""},{"kind":"strong","text":"dynamischer Upstream","ref":""},{"kind":"text","text":" eine belastbare Architekturentscheidung.","ref":""},{"kind":"citation","text":"","ref":"S2"}]}]}],"2":[{"id":"ttl-und-valid-planen","heading":"TTL und valid bewusst festlegen","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Der Resolver-Cache von NGINX richtet sich ohne eine zus\u00e4tzliche Vorgabe nach der ","ref":""},{"kind":"strong","text":"DNS-TTL","ref":""},{"kind":"text","text":" in der Antwort des abgefragten Nameservers. \u00c4ndert der autoritative DNS-Betreiber die IP-Adresse eines Backends, nutzt NGINX die bisherige Antwort bis zu deren TTL-Ablauf und fragt anschlie\u00dfend erneut ab. Damit bleibt die G\u00fcltigkeitsdauer dort steuerbar, wo die Namensdaten gepflegt werden.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Der Parameter ","ref":""},{"kind":"code","text":"valid","ref":""},{"kind":"text","text":" ersetzt diese TTL vollst\u00e4ndig durch den konfigurierten Zeitraum. Er begrenzt die DNS-TTL also nicht nur nach oben und definiert auch kein regelm\u00e4\u00dfiges Auffrischen zus\u00e4tzlich zur TTL. Ein Wert von ","ref":""},{"kind":"code","text":"valid=30s","ref":""},{"kind":"text","text":" kann eine l\u00e4ngere DNS-TTL verk\u00fcrzen, aber ebenso eine bewusst kurze TTL verl\u00e4ngern. Das muss zur Umzugs- und Deployment-Planung des Backends passen.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Wenn die Zone verl\u00e4sslich gepflegt wird, ist eine Konfiguration ohne Override die nachvollziehbare Ausgangsbasis. Die Adresse im Beispiel ist gem\u00e4\u00df den Dokumentationsnetzen gew\u00e4hlt und darf nicht als produktiver Resolver \u00fcbernommen werden. Trage stattdessen die Adresse eines erreichbaren und vertrauensw\u00fcrdigen DNS-Resolvers aus dem eigenen Netzwerk ein.","ref":""}]},{"type":"code","language":"nginx","code":"resolver 192.0.2.53;\nresolver_timeout 5s;","source_ids":["S1"]},{"type":"paragraph","runs":[{"kind":"text","text":"Ein Override kann sinnvoll sein, wenn die DNS-TTL nicht beeinflussbar ist und eine dokumentierte betriebliche Vorgabe existiert. Dann macht die Abweichung ausdr\u00fccklich sichtbar, wie lange NGINX Antworten h\u00e4lt. Sie ist keine allgemeine Leistungsoptimierung: K\u00fcrzere Zeiten k\u00f6nnen mehr DNS-Abfragen ausl\u00f6sen, l\u00e4ngere Zeiten k\u00f6nnen den Wechsel auf neue Backend-Adressen verz\u00f6gern.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"code","language":"nginx","code":"resolver 192.0.2.53 valid=30s;\nresolver_timeout 5s;","source_ids":["S1"]},{"type":"table","caption":"Ausgangsentscheidungen f\u00fcr DNS-TTL und valid","headers":["Betriebssituation","Ausgangsentscheidung","Begr\u00fcndung","Risiko"],"rows":[["DNS-Zone mit gepflegten TTLs","valid weglassen","NGINX folgt der vom DNS vorgegebenen Cache-Dauer.","Die TTL muss zum \u00c4nderungsfenster passen."],["TTL nicht steuerbar, Wechsel selten","valid bewusst dokumentieren","Die Haltedauer wird f\u00fcr den Proxy planbar.","Alte Zieladressen k\u00f6nnen l\u00e4nger genutzt werden als vom DNS vorgesehen."],["H\u00e4ufige Service- oder Container-Wechsel","Kurze TTL im autoritativen DNS bevorzugen","Das DNS bleibt die ma\u00dfgebliche Quelle f\u00fcr Aktualit\u00e4t.","Mehr Abfragen k\u00f6nnen die Resolver-Infrastruktur belasten."],["DNS-basierte Service-Erkennung","Dynamischen Upstream mit resolve pr\u00fcfen","Die Upstream-Mitglieder k\u00f6nnen DNS-\u00c4nderungen folgen.","Version und Architektur m\u00fcssen die Funktion unterst\u00fctzen."]],"source_ids":["S1"]},{"type":"paragraph","runs":[{"kind":"text","text":"Die Entscheidung beginnt daher nicht mit einer festen Sekundenangabe, sondern mit der Frage, wer DNS-Daten kontrolliert und wie schnell ein Backend-Wechsel wirksam werden muss. ","ref":""},{"kind":"strong","text":"valid","ref":""},{"kind":"text","text":" ist ein bewusster Eingriff in diese Regelung. Er eignet sich nicht als pauschaler Schalter, um den Reverse Proxy schneller zu machen oder DNS-Probleme zu verdecken.","ref":""},{"kind":"citation","text":"","ref":"S1"}]}]},{"id":"variabler-proxy-pass","heading":"Variablen in proxy_pass korrekt aufl\u00f6sen","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Enth\u00e4lt ","ref":""},{"kind":"code","text":"proxy_pass","ref":""},{"kind":"text","text":" eine Variable, muss NGINX den resultierenden Hostnamen zur Laufzeit behandeln. Zun\u00e4chst sucht NGINX nach einer passenden Upstream-Gruppe; findet es keine, ben\u00f6tigt es f\u00fcr den Namen einen konfigurierten Resolver. Fehlt dieser, ist die typische Meldung ","ref":""},{"kind":"code","text":"no resolver defined","ref":""},{"kind":"text","text":" kein Hinweis auf einen HTTP-Cache, sondern auf die fehlende DNS-Konfiguration f\u00fcr diesen Ausf\u00fchrungspfad.","ref":""},{"kind":"citation","text":"","ref":"S3"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Das folgende Muster macht die Laufzeitaufl\u00f6sung bewusst sichtbar. Der Resolver steht im ","ref":""},{"kind":"code","text":"http","ref":""},{"kind":"text","text":"-Kontext und gilt dadurch f\u00fcr mehrere virtuelle Hosts, sofern keine spezifischere Einstellung ihn \u00fcberschreibt. Die verwendete Dokumentationsadresse muss durch den internen Resolver der jeweiligen Umgebung ersetzt werden.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"code","language":"nginx","code":"http {\n    resolver 192.0.2.53;\n    resolver_timeout 5s;\n\n    server {\n        listen 80;\n\n        location \/ {\n            set $backend api.internal.example;\n            proxy_pass http:\/\/$backend;\n        }\n    }\n}","source_ids":["S1","S3"]},{"type":"paragraph","runs":[{"kind":"text","text":"Die Direktive ","ref":""},{"kind":"code","text":"resolver_timeout","ref":""},{"kind":"text","text":" steuert nicht die Cache-Dauer. Sie begrenzt, wie lange NGINX auf eine Namensaufl\u00f6sung wartet; der dokumentierte Standard betr\u00e4gt 30 Sekunden. Die Wahl geh\u00f6rt zu den \u00fcbrigen Fehlerbudgets: Ein zu hoher Wert kann eine fehlgeschlagene Anfrage bis zur Fehlerantwort verz\u00f6gern, ein zu niedriger Wert erzeugt bei zeitweise langsamen internen Resolvern vermeidbare Aufl\u00f6sungsfehler.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"F\u00fcr einen einzelnen, klar abgegrenzten Standort kann der Resolver im ","ref":""},{"kind":"code","text":"location","ref":""},{"kind":"text","text":"-Block stehen. Ben\u00f6tigen mehrere Locations oder Server dieselbe Aufl\u00f6sung, ist ein gemeinsamer Scope im ","ref":""},{"kind":"code","text":"server","ref":""},{"kind":"text","text":"- oder ","ref":""},{"kind":"code","text":"http","ref":""},{"kind":"text","text":"-Block wartungs\u00e4rmer. NGINX erlaubt die Direktive in allen drei Kontexten; der Geltungsbereich sollte die tats\u00e4chliche Betriebsstruktur abbilden, nicht nur eine einzelne Fehlermeldung kurzfristig beseitigen.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Auch bei variablen Zielen bleiben DNS-Timeout und Verbindung zum Backend getrennte Fehlerklassen. Eine erfolgreiche Namensaufl\u00f6sung beweist weder, dass der Zielport erreichbar ist, noch dass die Anwendung antwortet. Umgekehrt behebt ein h\u00f6herer Upstream-Timeout keine nicht erreichbare Resolver-Adresse.","ref":""},{"kind":"citation","text":"","ref":"S3"}]}]},{"id":"dynamische-upstreams","heading":"Dynamische Upstreams mit resolve konfigurieren","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"F\u00fcr eine benannte Backend-Gruppe kann ein dynamischer Upstream lesbarer sein als ein variabler Zielwert in jeder Location. Das Muster trennt die Definition der Backend-Mitglieder vom Routing: ","ref":""},{"kind":"code","text":"proxy_pass","ref":""},{"kind":"text","text":" verweist auf die Gruppe, w\u00e4hrend der Hostname im Upstream \u00fcber DNS aktualisiert werden kann. Das ist besonders passend, wenn mehrere Routen dieselbe Anwendung ansprechen.","ref":""},{"kind":"citation","text":"","ref":"S2"}]},{"type":"paragraph","runs":[{"kind":"text","text":"F\u00fcr NGINX Open Source dokumentiert NGINX die Direktive ","ref":""},{"kind":"code","text":"resolver","ref":""},{"kind":"text","text":" im ","ref":""},{"kind":"code","text":"upstream","ref":""},{"kind":"text","text":"-Block und den Parameter ","ref":""},{"kind":"code","text":"resolve","ref":""},{"kind":"text","text":" bei ","ref":""},{"kind":"code","text":"server","ref":""},{"kind":"text","text":" ab Version 1.27.3. \u00c4ltere Open-Source-Installationen d\u00fcrfen daher nicht nach demselben Schema behandelt werden; historisch waren vergleichbare Funktionen teilweise NGINX Plus vorbehalten.","ref":""},{"kind":"citation","text":"","ref":"S2"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Die ","ref":""},{"kind":"strong","text":"Shared-Memory-Zone","ref":""},{"kind":"text","text":" ist dabei kein Cache-Timeout. Sie stellt den gemeinsamen Speicher bereit, den dynamisch ver\u00e4nderte Upstream-Konfigurationen ben\u00f6tigen. Erkennt NGINX bei der DNS-Aufl\u00f6sung andere Adressen f\u00fcr den Namen, kann die Upstream-Gruppe anhand dieser gemeinsam verwalteten Daten ohne Neustart angepasst werden.","ref":""},{"kind":"citation","text":"","ref":"S2"}]},{"type":"code","language":"nginx","code":"http {\n    resolver 192.0.2.53;\n    resolver_timeout 5s;\n\n    upstream application_pool {\n        zone application_pool 64k;\n        server app.internal.example resolve;\n    }\n\n    server {\n        listen 80;\n\n        location \/ {\n            proxy_pass http:\/\/application_pool;\n        }\n    }\n}","source_ids":["S1","S2"]},{"type":"paragraph","runs":[{"kind":"text","text":"Wie bei allen Beispielen steht ","ref":""},{"kind":"code","text":"192.0.2.53","ref":""},{"kind":"text","text":" nur f\u00fcr eine Dokumentationsadresse. In der Praxis muss der eingetragene Resolver interne Namen zuverl\u00e4ssig kennen, aus dem NGINX-Netz erreichbar sein und als vertrauensw\u00fcrdig gelten. Vor der \u00dcbernahme ist au\u00dferdem der tats\u00e4chliche Funktionsumfang des installierten Pakets zu pr\u00fcfen, statt die Konfiguration allein aus einem aktuellen Beispiel abzuleiten.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Ein Dienst, der ausschlie\u00dflich \u00fcber IPv4 erreichbar ist, kann eine gezielte Einschr\u00e4nkung rechtfertigen: ","ref":""},{"kind":"code","text":"resolver 192.0.2.53 ipv6=off;","ref":""},{"kind":"text","text":" verhindert AAAA-Abfragen und die Auswahl einer IPv6-Adresse f\u00fcr diesen Resolver-Kontext. Das ist jedoch eine Netzarchitekturentscheidung. Bei funktionierendem Dual Stack sollte IPv6 nicht allein aus Gewohnheit deaktiviert werden; standardm\u00e4\u00dfig l\u00f6st NGINX beide IP-Familien auf.","ref":""},{"kind":"citation","text":"","ref":"S1"}]}]}],"3":[{"id":"sicher-ausrollen","heading":"Konfiguration sicher pr\u00fcfen und ausrollen","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Vor einer \u00c4nderung pr\u00fcfst du zun\u00e4chst, an welcher Stelle die Resolver-Direktiven tats\u00e4chlich gelten. Suche dazu die aktive Konfiguration einschlie\u00dflich eingebundener Dateien und kl\u00e4re, ob der Resolver f\u00fcr das gesamte ","ref":""},{"kind":"code","text":"http","ref":""},{"kind":"text","text":"-Kontext, nur f\u00fcr einen virtuellen Host oder lediglich f\u00fcr einen einzelnen Pfad vorgesehen ist. Ein zu enger Scope kann dazu f\u00fchren, dass ein anderer variabler Proxy-Pfad keinen Resolver findet; ein zu weiter Scope erschwert dagegen die sp\u00e4tere Zuordnung von \u00c4nderungen.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Nach jeder Anpassung folgt der ","ref":""},{"kind":"strong","text":"Syntaxcheck","ref":""},{"kind":"text","text":". Er liest die Konfiguration ein und versucht auch, referenzierte Dateien zu \u00f6ffnen. Damit lassen sich Schreibfehler, ung\u00fcltige Direktiven und Probleme in Include-Dateien vor einem Reload erkennen. Der Check beweist jedoch nicht, dass der eingetragene DNS-Server erreichbar ist, den erwarteten Namen kennt oder das Backend hinter einer aufgel\u00f6sten Adresse Verbindungen annimmt.","ref":""},{"kind":"citation","text":"","ref":"S4"}]},{"type":"code","language":"text","code":"nginx -t\nnginx -s reload","source_ids":["S4"]},{"type":"paragraph","runs":[{"kind":"text","text":"F\u00fchre den Reload erst nach erfolgreicher Pr\u00fcfung aus. ","ref":""},{"kind":"code","text":"nginx -s reload","ref":""},{"kind":"text","text":" veranlasst NGINX, neue Worker mit der neuen Konfiguration zu starten und alte Worker kontrolliert zu beenden. Abh\u00e4ngig vom installierten Paket und Betriebssystem kann stattdessen der dort vorgesehene Service-Manager den Reload ausl\u00f6sen. Verwende daf\u00fcr den dokumentierten Betriebsweg der Installation, statt Befehle aus einer fremden Umgebung zu \u00fcbernehmen.","ref":""},{"kind":"citation","text":"","ref":"S4"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Plane anschlie\u00dfend eine fachliche Pr\u00fcfung im vorgesehenen \u00c4nderungsfenster. Vergleiche die erwartete DNS-TTL mit dem Zeitpunkt, ab dem eine neue Backend-Adresse genutzt werden soll, und pr\u00fcfe die Erreichbarkeit des Dienstes \u00fcber die tats\u00e4chlich erlaubte IP-Familie. Dokumentiere au\u00dferdem Resolver-Adresse, gew\u00e4hlten Scope und ein m\u00f6gliches ","ref":""},{"kind":"code","text":"valid","ref":""},{"kind":"text","text":"-Override. So l\u00e4sst sich bei einer St\u00f6rung unterscheiden, ob DNS, Routing oder die Anwendung die Ursache ist.","ref":""},{"kind":"citation","text":"","ref":"S1"}]}]},{"id":"resolver-fehler-eingrenzen","heading":"Typische Resolver-Fehler systematisch eingrenzen","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Beginne die Fehlersuche beim Zielausdruck in ","ref":""},{"kind":"code","text":"proxy_pass","ref":""},{"kind":"text","text":". Enth\u00e4lt er eine Variable, muss NGINX den darin enthaltenen Hostnamen zur Laufzeit aufl\u00f6sen, sofern dieser nicht zu einer definierten Upstream-Gruppe geh\u00f6rt. Die Meldung ","ref":""},{"kind":"code","text":"no resolver defined","ref":""},{"kind":"text","text":" weist daher zun\u00e4chst auf eine fehlende oder im wirksamen Kontext nicht sichtbare ","ref":""},{"kind":"strong","text":"Resolver-Konfiguration","ref":""},{"kind":"text","text":" hin. Erg\u00e4nze einen vertrauensw\u00fcrdigen Nameserver im passenden Kontext, statt den Hostnamen vorschnell durch eine feste IP zu ersetzen.","ref":""},{"kind":"citation","text":"","ref":"S3"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Ist ein Resolver konfiguriert, pr\u00fcfst du als N\u00e4chstes dessen Adresse, Netzweg und Zust\u00e4ndigkeit f\u00fcr die verwendete Zone. Ein \u00f6ffentlicher Resolver kann interne Namen nicht kennen; ein nicht erreichbarer Resolver erzeugt dagegen Aufl\u00f6sungs-Timeouts. Kontrolliere au\u00dferdem, ob die Direktive durch eine spezifischere Einstellung \u00fcberschrieben wird. NGINX verwendet nur die ausdr\u00fccklich angegebenen Nameserver, nicht automatisch s\u00e4mtliche Einstellungen aus ","ref":""},{"kind":"code","text":"\/etc\/resolv.conf","ref":""},{"kind":"text","text":".","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Bleibt nach einem DNS-Wechsel eine alte Zieladresse aktiv, kontrolliere die Antwort-TTL und ein gesetztes ","ref":""},{"kind":"code","text":"valid","ref":""},{"kind":"text","text":". Ein langer Override ersetzt die TTL der DNS-Antwort und kann die \u00dcbernahme einer \u00c4nderung entsprechend verz\u00f6gern. Die zul\u00e4ssige Korrektur ist keine pauschal m\u00f6glichst kurze Dauer, sondern ein Wert, der zum \u00c4nderungsfenster und zur Belastbarkeit der DNS-Infrastruktur passt; oft ist das Weglassen von ","ref":""},{"kind":"code","text":"valid","ref":""},{"kind":"text","text":" die sauberere L\u00f6sung.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Bei Verbindungsproblemen nach erfolgreicher Aufl\u00f6sung trennst du DNS von der Backend-Verbindung. Pr\u00fcfe, ob A- und AAAA-Antworten vorliegen und ob das Ziel \u00fcber IPv6 tats\u00e4chlich geroutet und erreichbar ist. ","ref":""},{"kind":"code","text":"ipv6=off","ref":""},{"kind":"text","text":" ist nur f\u00fcr einen nachweislich IPv4-only betriebenen Architekturfall geeignet. Ein DNS-Timeout betrifft die Namensaufl\u00f6sung; ein Verbindungsfehler zur bereits bekannten IP verweist dagegen auf Routing, Firewall, Port oder Anwendung.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"F\u00fcr dynamische Upstreams m\u00fcssen au\u00dferdem Versionsstand, Shared-Memory-Zone und ","ref":""},{"kind":"code","text":"resolve","ref":""},{"kind":"text","text":" zusammenpassen. Die hierf\u00fcr dokumentierte Open-Source-Unterst\u00fctzung gilt ab NGINX 1.27.3; \u00e4ltere Installationen d\u00fcrfen nicht als gleichwertig behandelt werden. ","ref":""},{"kind":"code","text":"status_zone","ref":""},{"kind":"text","text":" und API-basierte Resolver-Statistiken sind zudem keine allgemeine Monitoring-L\u00f6sung f\u00fcr NGINX Open Source, da die genannten Funktionen kommerziellen Umfang betreffen.","ref":""},{"kind":"citation","text":"","ref":"S2"}]}]},{"id":"betriebsentscheidung","heading":"Resolver-Strategie f\u00fcr den Betrieb w\u00e4hlen","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Die passende Strategie beginnt nicht mit einem pauschalen Cache-Wert, sondern mit DNS-Hoheit und \u00c4nderungsrate. Kann dein Team die autoritative Zone pflegen und bilden deren TTLs das Deployment-Fenster realistisch ab, ist eine ","ref":""},{"kind":"strong","text":"TTL-gesteuerte Aufl\u00f6sung","ref":""},{"kind":"text","text":" ohne ","ref":""},{"kind":"code","text":"valid","ref":""},{"kind":"text","text":" meist der nachvollziehbarste Ausgangspunkt. DNS bleibt dann die ma\u00dfgebliche Quelle daf\u00fcr, wie lange eine Antwort verwendet wird.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Ein bewusst gesetztes ","ref":""},{"kind":"code","text":"valid","ref":""},{"kind":"text","text":" kommt infrage, wenn du die TTL nicht beeinflussen kannst und eine abweichende Cache-Dauer betrieblich begr\u00fcnden kannst. Halte dabei fest, welche Ausfallfolge akzeptabel ist: Ein l\u00e4ngerer Wert senkt m\u00f6gliche DNS-Abfragen, kann aber nach einem Umzug auf eine nicht mehr passende Adresse zeigen. Er ist weder eine Obergrenze f\u00fcr die DNS-TTL noch ein allgemeiner Performance-Schalter.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"W\u00e4hle das NGINX-Muster danach anhand der Routing-Struktur. Ein variabler ","ref":""},{"kind":"code","text":"proxy_pass","ref":""},{"kind":"text","text":" eignet sich, wenn das Ziel pro Anfrage oder Konfiguration zur Laufzeit bestimmt wird; daf\u00fcr ist ein Resolver im passenden Scope erforderlich. F\u00fcr eine benannte Backend-Gruppe mit DNS-basierten Adress\u00e4nderungen ist ein Upstream mit ","ref":""},{"kind":"code","text":"zone","ref":""},{"kind":"text","text":" und ","ref":""},{"kind":"code","text":"resolve","ref":""},{"kind":"text","text":" klarer, sofern NGINX Open Source 1.27.3 oder neuer tats\u00e4chlich verf\u00fcgbar ist.","ref":""},{"kind":"citation","text":"","ref":"S2"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Erst anschlie\u00dfend bestimmst du ","ref":""},{"kind":"strong","text":"Timeouts und IP-Familien","ref":""},{"kind":"text","text":". Der Resolver-Timeout muss zu Client- und Upstream-Timeouts passen, damit eine ausbleibende DNS-Antwort Fehler nicht unverh\u00e4ltnism\u00e4\u00dfig verz\u00f6gert. IPv4 oder IPv6 schaltest du nur entsprechend der Netzarchitektur frei. Verwende ausschlie\u00dflich abgesicherte Resolver, die interne Zonen zuverl\u00e4ssig beantworten k\u00f6nnen.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"DNS-Aufl\u00f6sung und Upstream-Keepalive l\u00f6sen unterschiedliche Aufgaben. Der Resolver entscheidet, welche Backend-Adresse NGINX verwenden kann; Keepalive h\u00e4lt bereits aufgebaute, inaktive Backend-Verbindungen zur Wiederverwendung vor. Eine \u00c4nderung an der Verbindungswiederverwendung ersetzt daher weder TTL-Planung noch Resolver-Pr\u00fcfung. F\u00fcr die Dimensionierung dieser Verbindungsebene erg\u00e4nzt der Beitrag zu ","ref":""},{"kind":"internal_link","text":"NGINX Upstream Keepalive","ref":"I2"},{"kind":"text","text":" die Resolver-Strategie.","ref":""}]}]}]},"plan":{"reader_question":"Wie konfiguriere ich den NGINX-eigenen DNS-Resolver so, dass ein Reverse Proxy Backend-Namen zuverl\u00e4ssig aufl\u00f6st, DNS-\u00c4nderungen angemessen \u00fcbernimmt und weder unn\u00f6tig veraltete IP-Adressen noch vermeidbare DNS-Anfragen entstehen?","sections":[{"id":"resolver-grundlagen","heading":"NGINX Resolver und DNS-Cache verstehen","part":1,"target_words":270,"purpose":"Definiert die Aufgaben des nginx resolver: Er fragt festgelegte Nameserver ab und cached DNS-Antworten f\u00fcr Namensaufl\u00f6sungen. Zuerst den Ablauf vom Hostnamen zur Backend-IP erkl\u00e4ren, danach Resolver-Adresse, mehrere Nameserver und IPv4\/IPv6 einordnen. Klar abgrenzen, dass dies kein rekursiver DNS-Server und kein automatisches \u00dcbernehmen von \/etc\/resolv.conf ist. Vertrauensw\u00fcrdige interne Resolver als Sicherheitsvoraussetzung nennen.","source_ids":["S1"],"internal_link_ids":[]},{"id":"cache-arten-abgrenzen","heading":"DNS-Cache ist kein HTTP-Cache","part":1,"target_words":260,"purpose":"Die h\u00e4ufige Verwechslung von DNS-Response-Cache, proxy_cache und Open-File-Cache anhand von Speicherobjekt, Zweck, G\u00fcltigkeit und Fehlerbild aufl\u00f6sen. Ein kurzer Gegen\u00fcberstellungsabsatz soll zeigen, weshalb das Leeren oder Abstimmen eines HTTP-Caches keine DNS-\u00c4nderung beschleunigt. Abschlie\u00dfend Grenzen des Resolver-Caches f\u00fcr Reverse Proxies benennen; der erg\u00e4nzende interne Beitrag vertieft ausschlie\u00dflich den Open-File-Cache.","source_ids":["S1","S3"],"internal_link_ids":["I1"]},{"id":"laufzeitauflosung-und-versionen","heading":"Wann NGINX Namen erneut aufl\u00f6sen muss","part":1,"target_words":270,"purpose":"Erkl\u00e4rt den Unterschied zwischen beim Einlesen der Konfiguration bekannten Namen und einer Laufzeitaufl\u00f6sung, etwa bei Variablen in proxy_pass. Den Fehler \u201eno resolver defined\u201c fachlich einordnen und die Kontexte http, server und location erl\u00e4utern. Danach die Versionsgrenze f\u00fcr dynamische upstream-Gruppen sauber trennen: resolver im upstream-Block sowie server ... resolve sind laut Dokumentation ab NGINX Open Source 1.27.3 verf\u00fcgbar. nginx -V als Vorpr\u00fcfung einf\u00fchren und Paket-Backports als Pr\u00fcfgrenze erw\u00e4hnen.","source_ids":["S1","S2","S3"],"internal_link_ids":[]},{"id":"ttl-und-valid-planen","heading":"TTL und valid bewusst festlegen","part":2,"target_words":300,"purpose":"Die Cache-Regel schrittweise erkl\u00e4ren: Ohne valid gilt die DNS-TTL, mit valid ersetzt NGINX diese Dauer vollst\u00e4ndig. Ein Konfigurationsbeispiel ohne valid und eines mit bewusstem valid=30s gegen\u00fcberstellen; die Dokumentationsadresse ausdr\u00fccklich als nicht produktiv nutzbar markieren. Eine informative Tabelle ordnet Betriebssituationen, Ausgangsentscheidung, Begr\u00fcndung und Risiko zu, etwa gepflegte TTLs, seltene Wechsel und Service-Erkennung. Herausarbeiten, dass valid weder Obergrenze noch allgemeiner Performance-Schalter ist.","source_ids":["S1"],"internal_link_ids":[]},{"id":"variabler-proxy-pass","heading":"Variablen in proxy_pass korrekt aufl\u00f6sen","part":2,"target_words":270,"purpose":"An einem kompakten Reverse-Proxy-Beispiel mit set $backend und proxy_pass http:\/\/$backend zeigen, wann NGINX zur Laufzeit den Resolver ben\u00f6tigt. Die Direktiven resolver und resolver_timeout in sinnvoller Reihenfolge erl\u00e4utern und den Scope f\u00fcr mehrere virtuelle Hosts gegen\u00fcber einem einzelnen location-Block abw\u00e4gen. resolver_timeout deutlich von der Cache-Dauer unterscheiden und seine Wahl zu Client- und Upstream-Timeouts in Beziehung setzen. Keine pauschale Sekundenempfehlung geben, sondern Auswirkungen zu hoher und zu niedriger Werte erkl\u00e4ren.","source_ids":["S1","S3"],"internal_link_ids":[]},{"id":"dynamische-upstreams","heading":"Dynamische Upstreams mit resolve konfigurieren","part":2,"target_words":280,"purpose":"Das Muster aus resolver, upstream, zone, server hostname resolve und proxy_pass als lesbare Alternative zum variablen Ziel vorstellen. Das vollst\u00e4ndige Beispiel in Konfigurationsbl\u00f6cke gliedern und erkl\u00e4ren, wie Shared Memory und DNS-\u00c4nderungen zusammenh\u00e4ngen. Deutlich machen, dass die dokumentierte Open-Source-Voraussetzung NGINX 1.27.3 oder neuer ist und \u00e4ltere Installationen nicht gleich behandelt werden d\u00fcrfen. IPv4-only als separaten Architekturfall mit ipv6=off einordnen, ohne daraus eine allgemeine Optimierung abzuleiten.","source_ids":["S1","S2"],"internal_link_ids":[]},{"id":"sicher-ausrollen","heading":"Konfiguration sicher pr\u00fcfen und ausrollen","part":3,"target_words":260,"purpose":"Einen sicheren \u00c4nderungsablauf f\u00fcr die Resolver-Konfiguration beschreiben: Kontext und include-Struktur pr\u00fcfen, nginx -t ausf\u00fchren und erst danach einen Reload veranlassen. Erkl\u00e4ren, was der Syntaxcheck abdeckt und was er nicht als DNS-Funktionstest beweist. nginx -s reload als NGINX-Mechanismus einordnen und darauf hinweisen, dass paketabh\u00e4ngig ein Service-Manager zust\u00e4ndig sein kann. Ein kurzer Pr\u00fcfkatalog verbindet erwartete DNS-TTL, Backend-Erreichbarkeit, IP-Familie und \u00c4nderungsfenster.","source_ids":["S4","S1"],"internal_link_ids":[]},{"id":"resolver-fehler-eingrenzen","heading":"Typische Resolver-Fehler systematisch eingrenzen","part":3,"target_words":270,"purpose":"Eine fehlersuchende Reihenfolge statt einer blo\u00dfen Fehlerliste liefern: variabler Host ohne resolver, falsche oder nicht erreichbare Resolver-IP, zu weit oder zu eng gesetzter Scope, langes valid sowie unpassende IPv6-Ergebnisse. Je Fehlerbild Ursache, Konfigurationspr\u00fcfung und zul\u00e4ssige Korrektur in kurzen Abs\u00e4tzen verbinden. DNS-Timeouts von Backend-Verbindungsproblemen unterscheiden. Zus\u00e4tzlich klarstellen, dass status_zone und API-basierte Resolver-Statistiken nicht als allgemeine Open-Source-Monitoringl\u00f6sung dargestellt werden d\u00fcrfen.","source_ids":["S1","S2","S3"],"internal_link_ids":[]},{"id":"betriebsentscheidung","heading":"Resolver-Strategie f\u00fcr den Betrieb w\u00e4hlen","part":3,"target_words":250,"purpose":"Die Entscheidung zwischen TTL-gesteuerter Aufl\u00f6sung, bewusstem valid-Override, variablem proxy_pass und dynamischer upstream-Gruppe anhand von \u00c4nderungsrate, DNS-Hoheit, Versionsstand und Ausfallfolgen zusammenf\u00fchren. Einen praxisnahen Entscheidungsweg in klaren Abs\u00e4tzen formulieren: zuerst DNS und Netzarchitektur, dann NGINX-Muster, zuletzt Timeout- und IP-Familienwahl. Herausstellen, dass DNS-Cache und Upstream-Keepalive unterschiedliche Ebenen betreffen; der interne Beitrag erg\u00e4nzt die Verbindungswiederverwendung, ersetzt aber keine Resolver-Planung.","source_ids":["S1","S2"],"internal_link_ids":["I2"]}]},"repairs":1,"reviews":2,"issues":[],"guard":{"content_md5":"00d4ee046c92de068b9c7a606af6b568","title":"Configuring the NGINX Resolver Cache Correctly","slug":"configuring-the-nginx-resolver-cache-correctly","excerpt":"Here's how to configure the NGINX resolver for dynamic backends: DNS TTL, valid, resolver_timeout, variable proxy_pass targets, and dynamic upstreams are clearly separated from one another.","status":"draft","featured_media":21661},"verify":{"content_md5":"00d4ee046c92de068b9c7a606af6b568","title":"Configuring the NGINX Resolver Cache Correctly","slug":"configuring-the-nginx-resolver-cache-correctly","excerpt":"Here's how to configure the NGINX resolver for dynamic backends: DNS TTL, valid, resolver_timeout, variable proxy_pass targets, and dynamic upstreams are clearly separated from one another.","status":"draft","featured_media":21661},"row_number":1881,"created_at":"2026-09-22T12:46:54+00:00","updated_at":"2026-09-22T12:54:44+00:00","verified_at":"2026-09-22T12:54:39+00:00"},"_wh_make_research":"Recherche-Briefing f\u00fcr webhosting.de  \nThema: NGINX Resolver Cache richtig konfigurieren  \nRecherche-Stand: 22. September 2026\n\nLeserfrage und Artikelziel\n\nDer geplante Artikel beantwortet die Frage: Wie konfiguriere ich den NGINX-eigenen DNS-Resolver so, dass ein Reverse Proxy Backend-Namen zuverl\u00e4ssig aufl\u00f6st, DNS-\u00c4nderungen angemessen \u00fcbernimmt und dabei weder unn\u00f6tig veraltete IP-Adressen noch vermeidbare DNS-Anfragen entstehen?\n\nIm Mittelpunkt steht der Unterschied zwischen drei oft vermischten Funktionen:\n\n1. DNS-Aufl\u00f6sung von Upstream-Zielen durch NGINX,\n2. DNS-Antwort-Cache des NGINX-Resolvers,\n3. HTTP-Response-Cache mit `proxy_cache`.\n\nDer Artikel sollte sehr fr\u00fch klarstellen: `resolver` konfiguriert keinen HTTP-Cache und ersetzt auch keinen vollwertigen rekursiven DNS-Server. NGINX fragt die angegebenen Nameserver ab und cached Antworten f\u00fcr die Namensaufl\u00f6sung. Der Resolver ist insbesondere n\u00f6tig, wenn NGINX einen Hostnamen zur Laufzeit ermitteln muss, etwa weil `proxy_pass` Variablen enth\u00e4lt. ([nginx.org](https:\/\/nginx.org\/en\/docs\/http\/ngx_http_core_module.html?utm_source=openai))\n\nVoraussetzungen und sinnvolle Zielgruppe\n\nDie Anleitung richtet sich an Administratoren von Linux-Webservern, die NGINX als Reverse Proxy vor Anwendungen, Containern, APIs oder externen SaaS-Endpunkten einsetzen. Vorausgesetzt werden Zugriff auf die NGINX-Konfiguration, Verst\u00e4ndnis f\u00fcr `http`, `server` und `location` sowie ein vorhandener, vertrauensw\u00fcrdiger DNS-Resolver im Netzwerk.\n\nVor jeder Konfigurationsentscheidung muss die tats\u00e4chlich eingesetzte NGINX-Version gepr\u00fcft werden. Das ist wichtig, weil Funktionen f\u00fcr dynamisch aktualisierte `upstream`-Gruppen historisch teilweise nur in NGINX Plus verf\u00fcgbar waren und sp\u00e4ter in NGINX Open Source kamen. Der `resolver` im `http`-, `server`- und `location`-Kontext ist eine lang etablierte Funktion. Die Resolver-Konfiguration direkt im `upstream`-Block ist laut offizieller Dokumentation seit NGINX 1.27.3 verf\u00fcgbar. Ebenso ist der Parameter `resolve` f\u00fcr `upstream server` seit dieser Version in Open Source verf\u00fcgbar; davor war er dort Teil des kommerziellen Angebots. ([nginx.org](https:\/\/nginx.org\/en\/docs\/http\/ngx_http_upstream_module.html))\n\nAls sichere Vorpr\u00fcfung eignet sich folgender Terminalbefehl:\n\nTerminalbefehl:\n```text\nnginx -V\n```\n\nEr zeigt Version und Build-Optionen. Bei Distributionen k\u00f6nnen Sicherheits- und Funktionspatches zur\u00fcckportiert sein; allein die sichtbare Hauptversionsnummer reicht deshalb nicht immer als Beleg f\u00fcr einen konkreten Funktionsumfang.\n\nGesicherte technische Funktionsweise\n\nDie Direktive `resolver` enth\u00e4lt die IP-Adressen der DNS-Server, die NGINX f\u00fcr die Namensaufll\u00f6sung nutzen soll. Mehrere Server sind m\u00f6glich; NGINX fragt sie laut Dokumentation im Round-Robin-Verfahren ab. Ohne expliziten Port verwendet NGINX Port 53. Als Resolver-Adresse sind IPv4- und IPv6-Adressen m\u00f6glich. ([nginx.org](https:\/\/nginx.org\/en\/docs\/http\/ngx_http_core_module.html?utm_source=openai))\n\nDie zentrale Cache-Regel lautet: Ohne `valid` verwendet NGINX f\u00fcr DNS-Antworten grunds\u00e4tzlich die TTL aus der DNS-Antwort. Mit `valid=zeit` wird diese G\u00fcltigkeitsdauer \u00fcberschrieben. Das ist keine Angabe f\u00fcr eine Obergrenze oder ein \u201eRefresh-Intervall\u201c, sondern eine explizite Ersatzvorgabe f\u00fcr die TTL-basierte Cache-Dauer. Wer beispielsweise `valid=10m` setzt, kann damit auch eine vom autoritativen DNS bewusst kurz gesetzte TTL verl\u00e4ngern. Das erh\u00f6ht das Risiko, dass ein Reverse Proxy nach einem Backend-Wechsel noch bis zum Ablauf dieser zehn Minuten eine alte Adresse verwendet. ([nginx.org](https:\/\/nginx.org\/en\/docs\/http\/ngx_http_core_module.html?utm_source=openai))\n\nDer Parameter `resolver_timeout` betrifft nicht die Cache-Laufzeit. Er begrenzt, wie lange NGINX auf die Namensaufl\u00f6sung wartet; die offizielle Voreinstellung betr\u00e4gt 30 Sekunden. F\u00fcr produktive Request-Pfade sollte der Artikel erkl\u00e4ren, dass ein DNS-Timeout immer im Verh\u00e4ltnis zu den \u00fcbrigen Upstream- und Client-Timeouts gew\u00e4hlt werden muss. Ein zu hoher Wert kann Fehlerantworten verz\u00f6gern, ein zu niedriger Wert kann bei einer tats\u00e4chlich langsamen internen DNS-Infrastruktur unn\u00f6tige Aufl\u00f6sungsfehler erzeugen. ([nginx.org](https:\/\/nginx.org\/en\/docs\/http\/ngx_http_core_module.html?utm_source=openai))\n\nNGINX l\u00f6st standardm\u00e4\u00dfig sowohl IPv4- als auch IPv6-Adressen auf. Mit `ipv4=off` beziehungsweise `ipv6=off` l\u00e4sst sich eine Protokollfamilie gezielt ausschlie\u00dfen. Das ist sinnvoll, wenn das Backend nur \u00fcber eine Familie erreichbar ist oder ein unvollst\u00e4ndiges IPv6-Routing zu vermeidbaren Verbindungsproblemen f\u00fchrt. Es sollte aber nicht pauschal als Optimierung dargestellt werden: Eine Deaktivierung von IPv6 ist eine Architekturentscheidung, keine allgemeine Cache-Einstellung. ([nginx.org](https:\/\/nginx.org\/en\/docs\/http\/ngx_http_core_module.html?utm_source=openai))\n\nPraxisfall 1: Variabler `proxy_pass` zu einem dynamischen Backend\n\nEin h\u00e4ufiger Fall sind Container-Plattformen oder externe API-Ziele, deren IP-Adresse sich \u00e4ndern kann. Enth\u00e4lt `proxy_pass` eine Variable, sucht NGINX den Namen zun\u00e4chst in definierten Upstream-Gruppen. Wird er dort nicht gefunden, muss NGINX ihn \u00fcber einen konfigurierten Resolver aufl\u00f6sen. Fehlt die `resolver`-Direktive, ist diese Laufzeitaufl\u00f6sung nicht zuverl\u00e4ssig konfiguriert und typische Fehlermeldungen wie \u201eno resolver defined\u201c sind die Folge. ([nginx.org](https:\/\/nginx.org\/en\/docs\/http\/ngx_http_proxy_module.html?utm_source=openai))\n\nSicheres Konfigurationsbeispiel, Dateikonfiguration:\n\n```text\nhttp {\n    resolver 192.0.2.53 valid=30s;\n    resolver_timeout 5s;\n\n    server {\n        listen 80;\n\n        location \/ {\n            set $backend api.internal.example;\n            proxy_pass http:\/\/$backend;\n        }\n    }\n}\n```\n\nDie Adresse `192.0.2.53` ist eine Dokumentationsadresse und kein zu verwendender produktiver Resolver. Im sp\u00e4teren Artikel muss ausdr\u00fccklich stehen, dass Administratoren stattdessen die IP-Adresse ihres internen, abgesicherten DNS-Resolvers einsetzen.\n\nDas Beispiel eignet sich didaktisch, weil es die Laufzeitaufl\u00f6sung sichtbar macht. Die Zeit `30s` darf jedoch nicht als Standardempfehlung erscheinen. Wenn die DNS-Zone korrekt gepflegte TTLs liefert, ist eine Konfiguration ohne `valid` in vielen F\u00e4llen die bessere Ausgangsbasis:\n\nDateikonfiguration:\n\n```text\nresolver 192.0.2.53;\nresolver_timeout 5s;\n```\n\nDamit bleibt die Cache-Dauer an die DNS-TTL gebunden. Die richtige Entscheidung h\u00e4ngt von Deployment-Intervallen, DNS-TTL, Fehlertoleranz und der Belastbarkeit der Resolver-Infrastruktur ab.\n\nPraxisfall 2: Feste Upstream-Gruppe mit DNS-\u00c4nderungen\n\nBei einer klassischen Upstream-Gruppe reicht ein Hostname im `server`-Eintrag nicht automatisch als Konzept f\u00fcr kontinuierliche DNS-Nachverfolgung. F\u00fcr dynamische IP-\u00c4nderungen innerhalb einer Upstream-Gruppe steht in aktuellen Open-Source-Versionen der Parameter `resolve` zur Verf\u00fcgung. Voraussetzung sind ein `resolver` sowie eine Shared-Memory-Zone mit `zone`. NGINX \u00fcberwacht dann \u00c4nderungen an den zum Namen geh\u00f6renden IP-Adressen und passt die Upstream-Konfiguration ohne NGINX-Neustart an. ([nginx.org](https:\/\/nginx.org\/en\/docs\/http\/ngx_http_upstream_module.html))\n\nDateikonfiguration:\n\n```text\nhttp {\n    resolver 192.0.2.53;\n    resolver_timeout 5s;\n\n    upstream application_pool {\n        zone application_pool 64k;\n        server app.internal.example resolve;\n    }\n\n    server {\n        listen 80;\n\n        location \/ {\n            proxy_pass http:\/\/application_pool;\n        }\n    }\n}\n```\n\nDieses Muster ist f\u00fcr einen Reverse Proxy mit mehreren DNS-Adresswechseln oft lesbarer als ein variabler `proxy_pass`. Es trennt Backend-Gruppe, Load-Balancing und Routing. Der Artikel sollte dennoch keine pauschale Aussage treffen, dass dies auf jeder Installation funktioniert: Er muss NGINX 1.27.3 oder neuer als dokumentierte Open-Source-Voraussetzung nennen und auf die Versionspr\u00fcfung verweisen. ([nginx.org](https:\/\/nginx.org\/en\/docs\/http\/ngx_http_upstream_module.html))\n\nPraxisfall 3: Dual Stack und gezielte Einschr\u00e4nkung\n\nWenn ein interner Dienst nur \u00fcber IPv4 erreichbar ist, kann folgende Konfiguration sinnvoll sein:\n\nDateikonfiguration:\n\n```text\nresolver 192.0.2.53 ipv6=off;\nresolver_timeout 5s;\n```\n\nDas verhindert AAAA-Abfragen durch NGINX. Der Artikel sollte den Nutzen konkret erkl\u00e4ren: weniger unn\u00f6tige Aufl\u00f6sungsversuche und keine Auswahl einer IPv6-Adresse f\u00fcr ein Ziel, das \u00fcber IPv6 nicht erreichbar ist. Nicht behaupten sollte er hingegen, dass dies DNS \u201ebeschleunigt\u201c oder generell erforderlich macht; daf\u00fcr fehlen ohne Umgebungsdaten belastbare Messwerte.\n\nEntscheidungshilfe f\u00fcr `valid`\n\nGeeignete Tabelleninformationen:\n\n| Betriebssituation | Sinnvolle Ausgangsentscheidung | Begr\u00fcndung | Risiko |\n|---|---|---|---|\n| DNS-Zone mit gepflegten TTLs | `valid` weglassen | NGINX richtet den Cache an der DNS-TTL aus | DNS-TTL muss zur Deployment-Strategie passen |\n| TTL kann nicht beeinflusst werden, Backend wechselt selten | `valid` bewusst und dokumentiert setzen | Cache-Zeit wird planbar | NGINX kann l\u00e4nger als DNS vorgesehen alte Ziele verwenden |\n| H\u00e4ufige Container- oder Service-Wechsel | kurze TTL im autoritativen DNS bevorzugen | DNS bleibt zentrale Quelle der Aktualit\u00e4t | Mehr DNS-Anfragen m\u00f6glich |\n| Einmalig stabile interne IP | statische IP oder regul\u00e4re Upstream-Konfiguration pr\u00fcfen | DNS-Dynamik ist eventuell nicht n\u00f6tig | Verlust von Flexibilit\u00e4t bei sp\u00e4teren Umz\u00fcgen |\n| DNS-basierte Service-Erkennung | `upstream`, `zone`, `resolve` pr\u00fcfen | \u00c4nderungen k\u00f6nnen ohne NGINX-Reload verfolgt werden | Versions- und Architekturabh\u00e4ngigkeit |\n\nEine sinnvolle Kernaussage: `valid` ist ein bewusstes Override f\u00fcr Betriebsanforderungen, nicht eine universelle Performance-Optimierung. Es gibt keinen allgemein sicheren Zahlenwert.\n\nAbgrenzungen und Grenzen\n\nDer NGINX-Resolver verwendet ausschlie\u00dflich die angegebenen Nameserver. Die Konfiguration ist daher nicht dasselbe wie das automatische \u00dcbernehmen aller Einstellungen aus `\/etc\/resolv.conf`. F\u00fcr produktive Reverse Proxies sind \u00f6ffentliche Resolver meist nicht die passende Standardwahl, wenn interne Namen oder private Service-Zonen aufgel\u00f6st werden m\u00fcssen. Die NGINX-Dokumentation empfiehlt ausdr\u00fccklich DNS-Server in einem angemessen abgesicherten, vertrauensw\u00fcrdigen lokalen Netzwerk, um DNS-Spoofing-Risiken zu senken. ([nginx.org](https:\/\/nginx.org\/en\/docs\/http\/ngx_http_core_module.html?utm_source=openai))\n\n`status_zone` darf nicht als allgemeine Monitoring-Funktion f\u00fcr NGINX Open Source beschrieben werden. Die Direktive erm\u00f6glicht DNS-Server-Statistiken, ist laut offizieller Dokumentation aber Teil des kommerziellen Angebots. Ebenso sollten API-basierte Resolver-Statistiken nicht als Open-Source-Standard empfohlen werden. ([nginx.org](https:\/\/nginx.org\/en\/docs\/http\/ngx_http_upstream_module.html))\n\nTypische Fehler, die der Artikel behandeln sollte\n\nErstens: `proxy_cache` mit DNS-Cache verwechseln. `proxy_cache` speichert HTTP-Antworten; `resolver` speichert DNS-Antworten. Beide Cache-Arten haben unterschiedliche Schl\u00fcssel, Laufzeiten und Fehlerbilder. ([nginx.org](https:\/\/nginx.org\/en\/docs\/http\/ngx_http_proxy_module.html?utm_source=openai))\n\nZweitens: Einen variablen Host in `proxy_pass` verwenden, aber keinen `resolver` konfigurieren. Das f\u00fchrt bei der Laufzeitaufl\u00f6sung zu Fehlern. ([nginx.org](https:\/\/nginx.org\/en\/docs\/http\/ngx_http_proxy_module.html?utm_source=openai))\n\nDrittens: `valid` sehr lang setzen und erwarten, dass neue DNS-Eintr\u00e4ge sofort verwendet werden. Tats\u00e4chlich \u00fcberschreibt `valid` die Antwort-TTL. ([nginx.org](https:\/\/nginx.org\/en\/docs\/http\/ngx_http_core_module.html?utm_source=openai))\n\nViertens: Den Resolver zu eng im `location`-Block definieren, obwohl mehrere virtuelle Hosts oder Upstreams ihn ben\u00f6tigen. Der Artikel sollte erl\u00e4utern, dass `resolver` im `http`, `server` und `location` erlaubt ist; der Scope sollte zur Betriebsstruktur passen. ([nginx.org](https:\/\/nginx.org\/en\/docs\/http\/ngx_http_core_module.html?utm_source=openai))\n\nF\u00fcnftens: Eine Konfiguration \u00e4ndern, ohne Syntax und Einbindung zu pr\u00fcfen. Ein sicheres Vorgehen ist:\n\nTerminalbefehl:\n```text\nnginx -t\n```\n\nEr pr\u00fcft Syntax und versucht, referenzierte Dateien zu \u00f6ffnen. Erst danach ist ein Reload sinnvoll:\n\nTerminalbefehl:\n```text\nnginx -s reload\n```\n\nBeim Reload startet NGINX neue Worker mit der neuen Konfiguration und f\u00e4hrt alte Worker kontrolliert herunter. Der Artikel sollte darauf hinweisen, dass Befehle je nach Betriebssystempaket \u00fcber einen Service-Manager ausgef\u00fchrt werden k\u00f6nnen, ohne konkrete produktive Befehle f\u00fcr unbekannte Installationen vorzugeben. ([nginx.org](https:\/\/nginx.org\/en\/docs\/switches.html?utm_source=openai))","_wh_make_sources":{"S1":{"id":"S1","url":"https:\/\/nginx.org\/en\/docs\/http\/ngx_http_core_module.html?utm_source=openai","title":"Modules ngx_http_core_module"},"S2":{"id":"S2","url":"https:\/\/nginx.org\/en\/docs\/http\/ngx_http_upstream_module.html","title":"Modules ngx_http_upstream_module"},"S3":{"id":"S3","url":"https:\/\/nginx.org\/en\/docs\/http\/ngx_http_proxy_module.html?utm_source=openai","title":"Modules ngx_http_proxy_module"},"S4":{"id":"S4","url":"https:\/\/nginx.org\/en\/docs\/switches.html?utm_source=openai","title":"Command-line parameters"}},"_wh_make_usage":{"research":{"input_tokens":28762,"output_tokens":3845,"response_id":"resp_0c203d2ffc88d28d016ab278c1b4b087d2a892423b9e98a1f4","model":"gpt-5.6-terra","search_calls":3},"plan_baaff9ded58232ae66eefb69d24f634e":{"input_tokens":5774,"output_tokens":1620,"response_id":"resp_05adc2eb39aa1a17016ab27906970087d2a0cefc7d95b462a4","model":"gpt-5.6-terra","search_calls":0},"part1_169d5bbdbed22beabba6ffd2f26f331f":{"input_tokens":8403,"output_tokens":2034,"response_id":"resp_096300afe69ec05a016ab27922e1a087d2a907c8fbec0c945c","model":"gpt-5.6-terra","search_calls":0},"part2_cffcc92b8528af841e1fe3ddc05b65de":{"input_tokens":8442,"output_tokens":2721,"response_id":"resp_08e8051180511049016ab279408dd887d29092222d120bb2a3","model":"gpt-5.6-terra","search_calls":0},"part3_4212988fd5f83721f7803df991538ab6":{"input_tokens":8486,"output_tokens":2357,"response_id":"resp_092eaf834038b71b016ab27967ee6c87d2b8d91da1bca2f3c5","model":"gpt-5.6-terra","search_calls":0},"package_c1e970624062326f7482251bcbb892c2":{"input_tokens":13803,"output_tokens":1342,"response_id":"resp_0d9f60220ed3aed3016ab2798dc70087d2964196b0a52a9812","model":"gpt-5.6-terra","search_calls":0},"review_568d0ea3d1deac494745ac14c07e6912":{"input_tokens":45384,"output_tokens":1665,"response_id":"resp_0daad4be99ffb434016ab279a88fa487d2a892555437b9ca53","model":"gpt-5.6-sol","search_calls":3},"repair_c7ecb2035315905ecac2f6b1fa84e5b0":{"input_tokens":15714,"output_tokens":3828,"response_id":"resp_0c608ec174d79ac8016ab279e7c8f887d2a51a278f49b0843b","model":"gpt-5.6-terra","search_calls":0},"review_7b3776cd29d1e9a3b809afafa4813481":{"input_tokens":36758,"output_tokens":1372,"response_id":"resp_035cae4afa066ae0016ab27a167e2c87d290866499c5b61e17","model":"gpt-5.6-sol","search_calls":2},"image_hero":{"input_tokens":108,"output_tokens":343,"response_id":"","model":"gpt-image-2.5-flare","search_calls":0},"image_detail1":{"input_tokens":102,"output_tokens":343,"response_id":"","model":"gpt-image-2.5-flare","search_calls":0},"image_detail2":{"input_tokens":142,"output_tokens":343,"response_id":"","model":"gpt-image-2.5-flare","search_calls":0}},"_wh_make_last_error":"","_wh_make_write_intent":{"before":{"content_md5":"31c8942dfa87aa18dd5679839114276d","title":"Configuring the NGINX Resolver Cache Correctly","slug":"configuring-the-nginx-resolver-cache-correctly","excerpt":"Here's how to configure the NGINX resolver for dynamic backends: DNS TTL, valid, resolver_timeout, variable proxy_pass targets, and dynamic upstreams are clearly separated from one another.","status":"draft","featured_media":0},"expected":{"content_md5":"00d4ee046c92de068b9c7a606af6b568","title":"Configuring the NGINX Resolver Cache Correctly","slug":"configuring-the-nginx-resolver-cache-correctly","excerpt":"Here's how to configure the NGINX resolver for dynamic backends: DNS TTL, valid, resolver_timeout, variable proxy_pass targets, and dynamic upstreams are clearly separated from one another.","status":"draft","featured_media":21661},"at":"2026-09-22T12:54:28+00:00"},"_wh_make_design_version":"2.1.2","rank_math_title":"NGINX Resolver Cache richtig konfigurieren","_wh_make_doc":{"title":"Configuring the NGINX Resolver Cache Correctly","slug":"configuring-the-nginx-resolver-cache-correctly","excerpt":"Here's how to configure the NGINX resolver for dynamic backends: DNS TTL, valid, resolver_timeout, variable proxy_pass targets, and dynamic upstreams are clearly separated from one another.","seo":{"title":"Configuring the NGINX Resolver Cache Correctly","description":"Setting Up the NGINX Resolver Correctly: Planning DNS TTL, valid, resolver_timeout, and dynamic upstreams for reverse proxies in a way that makes sense.","focus_keyword":"NGINX Resolver Cache"},"lead":[{"kind":"text","text":"Der ","ref":""},{"kind":"strong","text":"NGINX-Resolver","ref":""},{"kind":"text","text":" cached DNS-Antworten f\u00fcr Backend-Namen, nicht jedoch HTTP-Antworten. F\u00fcr eine robuste Reverse-Proxy-Konfiguration verwendest du einen vertrauensw\u00fcrdigen internen Nameserver, l\u00e4sst gepflegte DNS-TTLs meist wirken und setzt ","ref":""},{"kind":"code","text":"valid","ref":""},{"kind":"text","text":" nur als bewusstes Override. Besonders wichtig wird der Resolver bei variablen Zielen in ","ref":""},{"kind":"code","text":"proxy_pass","ref":""},{"kind":"text","text":" sowie bei dynamischen Upstreams, deren Funktionsumfang von der installierten NGINX-Version abh\u00e4ngt.","ref":""},{"kind":"citation","text":"","ref":"S1"},{"kind":"citation","text":"","ref":"S2"},{"kind":"citation","text":"","ref":"S3"}],"images":{"hero":{"prompt":"Konzeptionelle technische Illustration eines Reverse Proxy vor mehreren Backend-Diensten: links ein einzelner Proxy-Knoten, in der Mitte ein klarer DNS-Aufl\u00f6sungsweg mit kurzzeitigem Cache-Symbol, rechts austauschbare Backend-IP-Knoten; ruhige blaugr\u00fcne Farbpalette, viel Freiraum, pr\u00e4zise isometrische Darstellung, keine Schrift, keine Zahlen, keine Logos.","alt":"Konzeptionelle Darstellung eines NGINX Reverse Proxy mit DNS-Resolver-Cache und wechselnden Backend-Adressen.","caption":"Die Illustration trennt Namensaufl\u00f6sung, DNS-Cache und die Verbindung zum eigentlichen Backend.","filename_base":"nginx-resolver-cache-reverse-proxy","section_id":"","after_block":0},"detail1":{"prompt":"Konzeptionelle Ablaufgrafik zur TTL-Entscheidung: ein DNS-Record gelangt in einen kleinen Cache, zwei Wege zeigen entweder die \u00dcbernahme der DNS-TTL oder eine bewusst gesetzte abweichende Haltedauer; dezente blaue und orange Akzente, klare Blickf\u00fchrung von links nach rechts, keine Schrift, keine Zahlen, keine Logos.","alt":"Illustration zur Wirkung von DNS-TTL und valid auf die Cache-Dauer im NGINX-Resolver.","caption":"DNS-TTL und ein valid-Override bestimmen auf unterschiedliche Weise, wie lange Antworten verwendet werden.","filename_base":"nginx-dns-ttl-valid-entscheidung","section_id":"ttl-und-valid-planen","after_block":2},"detail2":{"prompt":"Konzeptionelle technische Illustration eines dynamischen NGINX-Upstreams: ein NGINX-Knoten erh\u00e4lt DNS-Antworten von einem separat dargestellten Resolver und verbindet sich mit mehreren wechselnden Backend-Adressknoten. Innerhalb des NGINX-Knotens ist ein klar abgegrenzter gemeinsamer Zustandsbereich als Shared-Memory-Zone dargestellt, ohne ihn als Netzwerkstation oder DNS-Datenpfad zu zeigen; ruhige blaugr\u00fcne Farbgebung, wenige klare Elemente, viel Freiraum, keine Schrift, keine Zahlen, keine Logos.","alt":"Konzeptionelle Darstellung eines dynamischen NGINX-Upstreams mit getrenntem DNS-Resolver, internem Shared-Memory-Zustand und Backend-Adressen.","caption":"Die Shared-Memory-Zone verwaltet Upstream-Zustand innerhalb von NGINX; DNS-Aufl\u00f6sung und Backend-Verbindungen bleiben getrennte Wege.","filename_base":"nginx-dynamischer-upstream-resolve","section_id":"dynamische-upstreams","after_block":3}},"chart":null,"social":{"facebook":"NGINX Resolver, DNS-TTL und valid werden h\u00e4ufig mit HTTP-Caching verwechselt. Der Beitrag zeigt, wie du dynamische Backend-Namen im Reverse Proxy sauber planst.","instagram":"DNS-Cache ist nicht gleich HTTP-Cache: So planst du NGINX Resolver, TTL, valid und dynamische Upstreams f\u00fcr wechselnde Backend-Adressen.","tiktok":"NGINX nutzt f\u00fcr variable proxy_pass-Ziele einen Resolver. Warum valid die DNS-TTL ersetzt und kein Refresh-Intervall ist, erkl\u00e4rt der Leitfaden.","youtube":"NGINX Resolver Cache konfigurieren: DNS-TTL, valid, resolver_timeout und dynamische Upstreams im Reverse Proxy verst\u00e4ndlich erkl\u00e4rt.","threads":"Ein langer valid-Wert kann alte Backend-IP-Adressen l\u00e4nger halten als die DNS-TTL vorsieht. Wann ein Override sinnvoll ist \u2013 und wann nicht.","x":"NGINX Resolver richtig planen: DNS-TTL wirkt standardm\u00e4\u00dfig, valid ersetzt sie als bewusster Override. Wichtig bei variablem proxy_pass und dynamischen Upstreams \u2013 HTTP-Cache ist etwas anderes."},"avatar_script":"Wenn NGINX ein Backend \u00fcber einen Hostnamen erreicht, entscheidet der Resolver, welche Adresse verwendet wird und wie lange diese DNS-Antwort im Cache bleibt. Wichtig ist die Trennung: proxy_cache speichert HTTP-Antworten, der Resolver dagegen DNS-Daten. Ohne valid folgt NGINX grunds\u00e4tzlich der TTL aus der DNS-Antwort. Mit valid ersetzt du diese Dauer vollst\u00e4ndig, was bei Backend-Umz\u00fcgen bewusst geplant werden muss. Variable proxy_pass-Ziele ben\u00f6tigen einen Resolver im passenden Kontext. F\u00fcr DNS-aktualisierte Upstream-Gruppen kommen zus\u00e4tzlich zone und resolve infrage, allerdings nur mit dem passenden NGINX-Funktionsumfang. Pr\u00fcfe daher Version, DNS-Zust\u00e4ndigkeit, Timeout-Budget und IPv4- oder IPv6-Erreichbarkeit, bevor du die Konfiguration ausrollst.","version_note":"Recherche-Stand: 22. September 2026. Die Beispiele f\u00fcr dynamische Upstreams mit resolver im upstream-Block und server \u2026 resolve beziehen sich in NGINX Open Source auf die dokumentierte Unterst\u00fctzung ab Version 1.27.3; bei Distributionspaketen sind Build- und Herstellerdokumentation zus\u00e4tzlich ma\u00dfgeblich.","sections":[{"id":"resolver-grundlagen","heading":"NGINX Resolver und DNS-Cache verstehen","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Ein Reverse Proxy ben\u00f6tigt f\u00fcr ein Backend mit Hostnamen zun\u00e4chst eine IP-Adresse. Der ","ref":""},{"kind":"strong","text":"NGINX-Resolver","ref":""},{"kind":"text","text":" fragt daf\u00fcr die in der Konfiguration festgelegten Nameserver ab. Die erhaltene DNS-Antwort wird zwischengespeichert, damit NGINX den Namen w\u00e4hrend seiner G\u00fcltigkeitsdauer nicht f\u00fcr jede Anfrage erneut aufl\u00f6sen muss. Dieser Cache betrifft ausschlie\u00dflich die Namensaufl\u00f6sung zum Zielsystem.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Die Direktive ","ref":""},{"kind":"code","text":"resolver","ref":""},{"kind":"text","text":" enth\u00e4lt eine oder mehrere Resolver-Adressen beziehungsweise unterst\u00fctzte Resolver-Bezeichner. Ohne abweichende Portangabe verwendet NGINX Port 53; bei mehreren eingetragenen Servern erfolgen die Anfragen laut Dokumentation im Round-Robin-Verfahren. F\u00fcr eine robuste Bootstrap-Konfiguration sind feste IP-Adressen oft nachvollziehbar, weil ihre Aufl\u00f6sung nicht selbst von DNS abh\u00e4ngt.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Standardm\u00e4\u00dfig ber\u00fccksichtigt NGINX IPv4- und IPv6-Adressen eines Namens. Das ist passend, wenn das Netzwerk beide Protokollfamilien bis zum Backend zuverl\u00e4ssig transportiert. Parameter wie ","ref":""},{"kind":"code","text":"ipv4=off","ref":""},{"kind":"text","text":" oder ","ref":""},{"kind":"code","text":"ipv6=off","ref":""},{"kind":"text","text":" schlie\u00dfen eine Familie gezielt aus, sind aber keine allgemeine Cache-Optimierung. Ob sie erforderlich sind, entscheidet die Erreichbarkeit des konkreten Backends und nicht die blo\u00dfe Existenz eines AAAA-Records.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Der Resolver ist weder ein vollwertiger rekursiver DNS-Server noch eine automatische \u00dcbernahme aller Einstellungen aus ","ref":""},{"kind":"code","text":"\/etc\/resolv.conf","ref":""},{"kind":"text","text":". NGINX nutzt die explizit angegebenen Nameserver. F\u00fcr interne Zonen und produktive Backend-Namen sollten das vertrauensw\u00fcrdige, angemessen abgesicherte Resolver im eigenen Netzwerk sein. So bleiben Zust\u00e4ndigkeit f\u00fcr private Namen und Schutz vor manipulierten DNS-Antworten in einer kontrollierbaren Infrastruktur.","ref":""},{"kind":"citation","text":"","ref":"S1"}]}]},{"id":"cache-arten-abgrenzen","heading":"DNS-Cache ist kein HTTP-Cache","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Der DNS-Response-Cache des Resolvers speichert Zuordnungen zwischen Namen und DNS-Antworten, etwa A- oder AAAA-Adressen. Sein Zweck ist, ein Backend erneut erreichen zu k\u00f6nnen, ohne jede Namensaufl\u00f6sung wiederholen zu m\u00fcssen. \u00c4ndert sich eine Backend-IP, ist deshalb die G\u00fcltigkeit der DNS-Antwort relevant \u2013 nicht der Inhalt einer zuvor ausgelieferten HTTP-Antwort.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Davon getrennt speichert ","ref":""},{"kind":"code","text":"proxy_cache","ref":""},{"kind":"text","text":" HTTP-Responses eines Upstreams. Der Schl\u00fcssel umfasst je nach Konfiguration beispielsweise URI, Host oder Header; ein Treffer liefert eine bereits gespeicherte Antwort an den Client. Probleme zeigen sich hier als veraltete Seiten, falsche Varianten oder unerwartete Cache-Hits. Diese Funktion entscheidet nicht, welche IP NGINX beim Aufbau einer neuen Backend-Verbindung verwendet.","ref":""},{"kind":"citation","text":"","ref":"S3"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Der Open-File-Cache ist eine dritte Ebene: Er h\u00e4lt Dateiinformationen und offene Deskriptoren f\u00fcr lokale Dateisystemzugriffe vor, aber weder DNS-Antworten noch HTTP-Inhalte. Wer diese Abgrenzung f\u00fcr statische Auslieferung vertiefen m\u00f6chte, findet sie im Beitrag zur ","ref":""},{"kind":"internal_link","text":"Konfiguration des NGINX Open File Cache","ref":"I1"},{"kind":"text","text":". F\u00fcr die Wahl einer Resolver-TTL liefert er jedoch keine Entscheidungsgrundlage.","ref":""}]},{"type":"paragraph","runs":[{"kind":"text","text":"Das Leeren, Purgen oder Abstimmen eines HTTP-Caches beschleunigt daher keine DNS-\u00c4nderung. Umgekehrt behebt eine neue DNS-Aufl\u00f6sung keine fehlerhaft gecachte HTTP-Antwort. Beim Reverse Proxy begrenzt der ","ref":""},{"kind":"strong","text":"DNS-Cache","ref":""},{"kind":"text","text":" sich zudem auf Namen und Adressen: Er pr\u00fcft weder die Gesundheit einer Anwendung noch ersetzt er Load-Balancing, Retries oder die korrekte Timeout-Planung zum Upstream.","ref":""},{"kind":"citation","text":"","ref":"S1"},{"kind":"citation","text":"","ref":"S3"}]}]},{"id":"laufzeitauflosung-und-versionen","heading":"Wann NGINX Namen erneut aufl\u00f6sen muss","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Ein Hostname kann NGINX bereits beim Einlesen der Konfiguration bekannt sein. Anders ist der Fall bei einem variablen Ziel, etwa ","ref":""},{"kind":"code","text":"proxy_pass http:\/\/$backend;","ref":""},{"kind":"text","text":". NGINX sucht den resultierenden Namen zun\u00e4chst in definierten Upstream-Gruppen. Findet es dort keinen passenden Namen, braucht es zur Laufzeit einen konfigurierten Resolver, um die Zieladresse zu ermitteln.","ref":""},{"kind":"citation","text":"","ref":"S3"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Die Meldung ","ref":""},{"kind":"code","text":"no resolver defined","ref":""},{"kind":"text","text":" weist in diesem Zusammenhang nicht auf einen fehlenden HTTP-Cache hin. Sie bedeutet, dass NGINX f\u00fcr die notwendige Laufzeitaufl\u00f6sung keinen DNS-Server kennt. ","ref":""},{"kind":"code","text":"resolver","ref":""},{"kind":"text","text":" darf im Kontext ","ref":""},{"kind":"code","text":"http","ref":""},{"kind":"text","text":", ","ref":""},{"kind":"code","text":"server","ref":""},{"kind":"text","text":" oder ","ref":""},{"kind":"code","text":"location","ref":""},{"kind":"text","text":" stehen. Ein zentraler Eintrag im ","ref":""},{"kind":"code","text":"http","ref":""},{"kind":"text","text":"-Block eignet sich, wenn mehrere virtuelle Hosts denselben Resolver nutzen; ein engerer Scope passt nur bei tats\u00e4chlich abweichenden Anforderungen.","ref":""},{"kind":"citation","text":"","ref":"S1"},{"kind":"citation","text":"","ref":"S3"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Von dieser lang verf\u00fcgbaren Laufzeitaufl\u00f6sung ist die dynamische Aktualisierung einer klassischen Upstream-Gruppe zu trennen. Die Resolver-Konfiguration direkt im ","ref":""},{"kind":"code","text":"upstream","ref":""},{"kind":"text","text":"-Block sowie ","ref":""},{"kind":"code","text":"server hostname resolve","ref":""},{"kind":"text","text":" sind laut Dokumentation in NGINX Open Source ab Version 1.27.3 verf\u00fcgbar. \u00c4ltere Open-Source-Installationen d\u00fcrfen nicht so behandelt werden, als unterst\u00fctzten sie dieses Muster automatisch; entsprechende Funktionen waren historisch teilweise NGINX Plus vorbehalten.","ref":""},{"kind":"citation","text":"","ref":"S2"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Vor der Planung dynamischer Upstreams pr\u00fcfst du die installierte Ausgabe und Build-Informationen. Der folgende Befehl gibt die NGINX-Version, die Compiler-Version und die beim Build verwendeten Configure-Parameter aus.","ref":""},{"kind":"citation","text":"","ref":"S4"}]},{"type":"code","language":"text","code":"nginx -V","source_ids":["S4"]},{"type":"paragraph","runs":[{"kind":"text","text":"Vergleiche den angezeigten Stand bei kritischen Deployments mit der Dokumentation des konkret eingesetzten Pakets und dessen Anbieters. Ma\u00dfgeblich ist, ob diese Installation die ben\u00f6tigte Funktion dokumentiert und bereitstellt. Erst danach ist ein ","ref":""},{"kind":"strong","text":"dynamischer Upstream","ref":""},{"kind":"text","text":" eine belastbare Architekturentscheidung.","ref":""},{"kind":"citation","text":"","ref":"S2"}]}]},{"id":"ttl-und-valid-planen","heading":"TTL und valid bewusst festlegen","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Der Resolver-Cache von NGINX richtet sich ohne eine zus\u00e4tzliche Vorgabe nach der ","ref":""},{"kind":"strong","text":"DNS-TTL","ref":""},{"kind":"text","text":" in der Antwort des abgefragten Nameservers. \u00c4ndert der autoritative DNS-Betreiber die IP-Adresse eines Backends, nutzt NGINX die bisherige Antwort bis zu deren TTL-Ablauf. Erst wenn danach wieder eine Namensaufl\u00f6sung erforderlich ist, fragt NGINX den Resolver erneut ab. Damit bleibt die G\u00fcltigkeitsdauer dort steuerbar, wo die Namensdaten gepflegt werden.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Der Parameter ","ref":""},{"kind":"code","text":"valid","ref":""},{"kind":"text","text":" ersetzt diese TTL vollst\u00e4ndig durch den konfigurierten Zeitraum. Er begrenzt die DNS-TTL also nicht nur nach oben und definiert auch kein regelm\u00e4\u00dfiges Auffrischen zus\u00e4tzlich zur TTL. Ein Wert von ","ref":""},{"kind":"code","text":"valid=30s","ref":""},{"kind":"text","text":" kann eine l\u00e4ngere DNS-TTL verk\u00fcrzen, aber ebenso eine bewusst kurze TTL verl\u00e4ngern. Das muss zur Umzugs- und Deployment-Planung des Backends passen.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Wenn die Zone verl\u00e4sslich gepflegt wird, ist eine Konfiguration ohne Override die nachvollziehbare Ausgangsbasis. Die Adresse im Beispiel ist gem\u00e4\u00df den Dokumentationsnetzen gew\u00e4hlt und darf nicht als produktiver Resolver \u00fcbernommen werden. Trage stattdessen die Adresse eines erreichbaren und vertrauensw\u00fcrdigen DNS-Resolvers aus dem eigenen Netzwerk ein.","ref":""}]},{"type":"code","language":"nginx","code":"resolver 192.0.2.53;\nresolver_timeout 5s;","source_ids":["S1"]},{"type":"paragraph","runs":[{"kind":"text","text":"Ein Override kann sinnvoll sein, wenn die DNS-TTL nicht beeinflussbar ist und eine dokumentierte betriebliche Vorgabe existiert. Dann macht die Abweichung ausdr\u00fccklich sichtbar, wie lange NGINX Antworten h\u00e4lt. Sie ist keine allgemeine Leistungsoptimierung: K\u00fcrzere Zeiten k\u00f6nnen mehr DNS-Abfragen ausl\u00f6sen, l\u00e4ngere Zeiten k\u00f6nnen den Wechsel auf neue Backend-Adressen verz\u00f6gern.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"code","language":"nginx","code":"resolver 192.0.2.53 valid=30s;\nresolver_timeout 5s;","source_ids":["S1"]},{"type":"table","caption":"Ausgangsentscheidungen f\u00fcr DNS-TTL und valid","headers":["Betriebssituation","Ausgangsentscheidung","Begr\u00fcndung","Risiko"],"rows":[["DNS-Zone mit gepflegten TTLs","valid weglassen","NGINX folgt der vom DNS vorgegebenen Cache-Dauer.","Die TTL muss zum \u00c4nderungsfenster passen."],["TTL nicht steuerbar, Wechsel selten","valid bewusst dokumentieren","Die Haltedauer wird f\u00fcr den Proxy planbar.","Alte Zieladressen k\u00f6nnen l\u00e4nger genutzt werden als vom DNS vorgesehen."],["H\u00e4ufige Service- oder Container-Wechsel","Kurze TTL im autoritativen DNS bevorzugen","Das DNS bleibt die ma\u00dfgebliche Quelle f\u00fcr Aktualit\u00e4t.","Mehr Abfragen k\u00f6nnen die Resolver-Infrastruktur belasten."],["DNS-basierte Service-Erkennung","Dynamischen Upstream mit resolve pr\u00fcfen","Die Upstream-Mitglieder k\u00f6nnen DNS-\u00c4nderungen folgen.","Version und Architektur m\u00fcssen die Funktion unterst\u00fctzen."]],"source_ids":["S1"]},{"type":"paragraph","runs":[{"kind":"text","text":"Die Entscheidung beginnt daher nicht mit einer festen Sekundenangabe, sondern mit der Frage, wer DNS-Daten kontrolliert und wie schnell ein Backend-Wechsel wirksam werden muss. ","ref":""},{"kind":"strong","text":"valid","ref":""},{"kind":"text","text":" ist ein bewusster Eingriff in diese Regelung. Er eignet sich nicht als pauschaler Schalter, um den Reverse Proxy schneller zu machen oder DNS-Probleme zu verdecken.","ref":""},{"kind":"citation","text":"","ref":"S1"}]}]},{"id":"variabler-proxy-pass","heading":"Variablen in proxy_pass korrekt aufl\u00f6sen","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Enth\u00e4lt ","ref":""},{"kind":"code","text":"proxy_pass","ref":""},{"kind":"text","text":" eine Variable, muss NGINX den resultierenden Hostnamen zur Laufzeit behandeln. Zun\u00e4chst sucht NGINX nach einer passenden Upstream-Gruppe; findet es keine, ben\u00f6tigt es f\u00fcr den Namen einen konfigurierten Resolver. Fehlt dieser, ist die typische Meldung ","ref":""},{"kind":"code","text":"no resolver defined","ref":""},{"kind":"text","text":" kein Hinweis auf einen HTTP-Cache, sondern auf die fehlende DNS-Konfiguration f\u00fcr diesen Ausf\u00fchrungspfad.","ref":""},{"kind":"citation","text":"","ref":"S3"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Das folgende Muster macht die Laufzeitaufl\u00f6sung bewusst sichtbar. Der Resolver steht im ","ref":""},{"kind":"code","text":"http","ref":""},{"kind":"text","text":"-Kontext und gilt dadurch f\u00fcr mehrere virtuelle Hosts, sofern keine spezifischere Einstellung ihn \u00fcberschreibt. Die verwendete Dokumentationsadresse muss durch den internen Resolver der jeweiligen Umgebung ersetzt werden.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"code","language":"nginx","code":"http {\n    resolver 192.0.2.53;\n    resolver_timeout 5s;\n\n    server {\n        listen 80;\n\n        location \/ {\n            set $backend api.internal.example;\n            proxy_pass http:\/\/$backend;\n        }\n    }\n}","source_ids":["S1","S3"]},{"type":"paragraph","runs":[{"kind":"text","text":"Die Direktive ","ref":""},{"kind":"code","text":"resolver_timeout","ref":""},{"kind":"text","text":" steuert nicht die Cache-Dauer. Sie begrenzt, wie lange NGINX auf eine Namensaufl\u00f6sung wartet; der dokumentierte Standard betr\u00e4gt 30 Sekunden. Die Wahl geh\u00f6rt zu den \u00fcbrigen Fehlerbudgets: Ein zu hoher Wert kann eine fehlgeschlagene Anfrage bis zur Fehlerantwort verz\u00f6gern, ein zu niedriger Wert erzeugt bei zeitweise langsamen internen Resolvern vermeidbare Aufl\u00f6sungsfehler.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"F\u00fcr einen einzelnen, klar abgegrenzten Standort kann der Resolver im ","ref":""},{"kind":"code","text":"location","ref":""},{"kind":"text","text":"-Block stehen. Ben\u00f6tigen mehrere Locations oder Server dieselbe Aufl\u00f6sung, ist ein gemeinsamer Scope im ","ref":""},{"kind":"code","text":"server","ref":""},{"kind":"text","text":"- oder ","ref":""},{"kind":"code","text":"http","ref":""},{"kind":"text","text":"-Block wartungs\u00e4rmer. NGINX erlaubt die Direktive in allen drei Kontexten; der Geltungsbereich sollte die tats\u00e4chliche Betriebsstruktur abbilden, nicht nur eine einzelne Fehlermeldung kurzfristig beseitigen.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Auch bei variablen Zielen bleiben DNS-Timeout und Verbindung zum Backend getrennte Fehlerklassen. Eine erfolgreiche Namensaufl\u00f6sung beweist weder, dass der Zielport erreichbar ist, noch dass die Anwendung antwortet. Umgekehrt behebt ein h\u00f6herer Upstream-Timeout keine nicht erreichbare Resolver-Adresse.","ref":""},{"kind":"citation","text":"","ref":"S3"}]}]},{"id":"dynamische-upstreams","heading":"Dynamische Upstreams mit resolve konfigurieren","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"F\u00fcr eine benannte Backend-Gruppe kann ein dynamischer Upstream lesbarer sein als ein variabler Zielwert in jeder Location. Das Muster trennt die Definition der Backend-Mitglieder vom Routing: ","ref":""},{"kind":"code","text":"proxy_pass","ref":""},{"kind":"text","text":" verweist auf die Gruppe, w\u00e4hrend der Hostname im Upstream \u00fcber DNS aktualisiert werden kann. Das ist besonders passend, wenn mehrere Routen dieselbe Anwendung ansprechen.","ref":""},{"kind":"citation","text":"","ref":"S2"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Der Parameter ","ref":""},{"kind":"code","text":"resolve","ref":""},{"kind":"text","text":" f\u00fcr einen ","ref":""},{"kind":"code","text":"server","ref":""},{"kind":"text","text":"-Eintrag existiert historisch seit NGINX 1.5.12. In NGINX Open Source ist er laut Dokumentation jedoch erst ab Version 1.27.3 verf\u00fcgbar; zuvor war diese Funktion kommerziell beschr\u00e4nkt. Auch die Resolver-Konfiguration direkt im ","ref":""},{"kind":"code","text":"upstream","ref":""},{"kind":"text","text":"-Block ist f\u00fcr Open Source ab 1.27.3 dokumentiert.","ref":""},{"kind":"citation","text":"","ref":"S2"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Die ","ref":""},{"kind":"strong","text":"Shared-Memory-Zone","ref":""},{"kind":"text","text":" ist dabei kein Cache-Timeout und kein DNS-Datenpfad. Sie stellt innerhalb von NGINX gemeinsamen Speicher bereit, den dynamisch ver\u00e4nderte Upstream-Konfigurationen ben\u00f6tigen. Erkennt NGINX bei der DNS-Aufl\u00f6sung andere Adressen f\u00fcr den Namen, kann die Upstream-Gruppe anhand dieses intern verwalteten Zustands ohne Neustart angepasst werden.","ref":""},{"kind":"citation","text":"","ref":"S2"}]},{"type":"code","language":"nginx","code":"http {\n    resolver 192.0.2.53;\n    resolver_timeout 5s;\n\n    upstream application_pool {\n        zone application_pool 64k;\n        server app.internal.example resolve;\n    }\n\n    server {\n        listen 80;\n\n        location \/ {\n            proxy_pass http:\/\/application_pool;\n        }\n    }\n}","source_ids":["S1","S2"]},{"type":"paragraph","runs":[{"kind":"text","text":"Wie bei allen Beispielen steht ","ref":""},{"kind":"code","text":"192.0.2.53","ref":""},{"kind":"text","text":" nur f\u00fcr eine Dokumentationsadresse. In der Praxis muss der eingetragene Resolver interne Namen zuverl\u00e4ssig kennen, aus dem NGINX-Netz erreichbar sein und als vertrauensw\u00fcrdig gelten. Vor der \u00dcbernahme ist au\u00dferdem der tats\u00e4chliche Funktionsumfang des installierten Pakets zu pr\u00fcfen, statt die Konfiguration allein aus einem aktuellen Beispiel abzuleiten.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Ein Dienst, der ausschlie\u00dflich \u00fcber IPv4 erreichbar ist, kann eine gezielte Einschr\u00e4nkung rechtfertigen: ","ref":""},{"kind":"code","text":"resolver 192.0.2.53 ipv6=off;","ref":""},{"kind":"text","text":" verhindert AAAA-Abfragen und die Auswahl einer IPv6-Adresse f\u00fcr diesen Resolver-Kontext. Das ist jedoch eine Netzarchitekturentscheidung. Bei funktionierendem Dual Stack sollte IPv6 nicht allein aus Gewohnheit deaktiviert werden; standardm\u00e4\u00dfig l\u00f6st NGINX beide IP-Familien auf.","ref":""},{"kind":"citation","text":"","ref":"S1"}]}]},{"id":"sicher-ausrollen","heading":"Konfiguration sicher pr\u00fcfen und ausrollen","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Vor einer \u00c4nderung pr\u00fcfst du zun\u00e4chst, an welcher Stelle die Resolver-Direktiven tats\u00e4chlich gelten. Suche dazu die aktive Konfiguration einschlie\u00dflich eingebundener Dateien und kl\u00e4re, ob der Resolver f\u00fcr das gesamte ","ref":""},{"kind":"code","text":"http","ref":""},{"kind":"text","text":"-Kontext, nur f\u00fcr einen virtuellen Host oder lediglich f\u00fcr einen einzelnen Pfad vorgesehen ist. Ein zu enger Scope kann dazu f\u00fchren, dass ein anderer variabler Proxy-Pfad keinen Resolver findet; ein zu weiter Scope erschwert dagegen die sp\u00e4tere Zuordnung von \u00c4nderungen.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Nach jeder Anpassung folgt der ","ref":""},{"kind":"strong","text":"Syntaxcheck","ref":""},{"kind":"text","text":". Er liest die Konfiguration ein und versucht auch, referenzierte Dateien zu \u00f6ffnen. Damit lassen sich Schreibfehler, ung\u00fcltige Direktiven und Probleme in Include-Dateien vor einem Reload erkennen. Der Check beweist jedoch nicht, dass der eingetragene DNS-Server erreichbar ist, den erwarteten Namen kennt oder das Backend hinter einer aufgel\u00f6sten Adresse Verbindungen annimmt.","ref":""},{"kind":"citation","text":"","ref":"S4"}]},{"type":"code","language":"text","code":"nginx -t\nnginx -s reload","source_ids":["S4"]},{"type":"paragraph","runs":[{"kind":"text","text":"F\u00fchre den Reload erst nach erfolgreicher Pr\u00fcfung aus. ","ref":""},{"kind":"code","text":"nginx -s reload","ref":""},{"kind":"text","text":" veranlasst NGINX, neue Worker mit der neuen Konfiguration zu starten und alte Worker kontrolliert zu beenden. Abh\u00e4ngig vom installierten Paket und Betriebssystem kann stattdessen der dort vorgesehene Service-Manager den Reload ausl\u00f6sen. Verwende daf\u00fcr den dokumentierten Betriebsweg der Installation, statt Befehle aus einer fremden Umgebung zu \u00fcbernehmen.","ref":""},{"kind":"citation","text":"","ref":"S4"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Plane anschlie\u00dfend eine fachliche Pr\u00fcfung im vorgesehenen \u00c4nderungsfenster. Vergleiche die erwartete DNS-TTL mit dem Zeitpunkt, ab dem eine neue Backend-Adresse genutzt werden soll, und pr\u00fcfe die Erreichbarkeit des Dienstes \u00fcber die tats\u00e4chlich erlaubte IP-Familie. Dokumentiere au\u00dferdem Resolver-Adresse, gew\u00e4hlten Scope und ein m\u00f6gliches ","ref":""},{"kind":"code","text":"valid","ref":""},{"kind":"text","text":"-Override. So l\u00e4sst sich bei einer St\u00f6rung unterscheiden, ob DNS, Routing oder die Anwendung die Ursache ist.","ref":""},{"kind":"citation","text":"","ref":"S1"}]}]},{"id":"resolver-fehler-eingrenzen","heading":"Typische Resolver-Fehler systematisch eingrenzen","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Beginne die Fehlersuche beim Zielausdruck in ","ref":""},{"kind":"code","text":"proxy_pass","ref":""},{"kind":"text","text":". Enth\u00e4lt er eine Variable, muss NGINX den darin enthaltenen Hostnamen zur Laufzeit aufl\u00f6sen, sofern dieser nicht zu einer definierten Upstream-Gruppe geh\u00f6rt. Die Meldung ","ref":""},{"kind":"code","text":"no resolver defined","ref":""},{"kind":"text","text":" weist daher zun\u00e4chst auf eine fehlende oder im wirksamen Kontext nicht sichtbare ","ref":""},{"kind":"strong","text":"Resolver-Konfiguration","ref":""},{"kind":"text","text":" hin. Erg\u00e4nze einen vertrauensw\u00fcrdigen Nameserver im passenden Kontext, statt den Hostnamen vorschnell durch eine feste IP zu ersetzen.","ref":""},{"kind":"citation","text":"","ref":"S3"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Ist ein Resolver konfiguriert, pr\u00fcfst du als N\u00e4chstes dessen Adresse, Netzweg und Zust\u00e4ndigkeit f\u00fcr die verwendete Zone. Ein \u00f6ffentlicher Resolver kann interne Namen nicht kennen; ein nicht erreichbarer Resolver erzeugt dagegen Aufl\u00f6sungs-Timeouts. Kontrolliere au\u00dferdem, ob die Direktive durch eine spezifischere Einstellung \u00fcberschrieben wird. NGINX verwendet nur die ausdr\u00fccklich angegebenen Nameserver, nicht automatisch s\u00e4mtliche Einstellungen aus ","ref":""},{"kind":"code","text":"\/etc\/resolv.conf","ref":""},{"kind":"text","text":".","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Bleibt nach einem DNS-Wechsel eine alte Zieladresse aktiv, kontrolliere die Antwort-TTL und ein gesetztes ","ref":""},{"kind":"code","text":"valid","ref":""},{"kind":"text","text":". Ein langer Override ersetzt die TTL der DNS-Antwort und kann die \u00dcbernahme einer \u00c4nderung entsprechend verz\u00f6gern. Die zul\u00e4ssige Korrektur ist keine pauschal m\u00f6glichst kurze Dauer, sondern ein Wert, der zum \u00c4nderungsfenster und zur Belastbarkeit der DNS-Infrastruktur passt; oft ist das Weglassen von ","ref":""},{"kind":"code","text":"valid","ref":""},{"kind":"text","text":" die sauberere L\u00f6sung.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Bei Verbindungsproblemen nach erfolgreicher Aufl\u00f6sung trennst du DNS von der Backend-Verbindung. Pr\u00fcfe, ob A- und AAAA-Antworten vorliegen und ob das Ziel \u00fcber IPv6 tats\u00e4chlich geroutet und erreichbar ist. ","ref":""},{"kind":"code","text":"ipv6=off","ref":""},{"kind":"text","text":" ist nur f\u00fcr einen nachweislich IPv4-only betriebenen Architekturfall geeignet. Ein DNS-Timeout betrifft die Namensaufl\u00f6sung; ein Verbindungsfehler zur bereits bekannten IP verweist dagegen auf Routing, Firewall, Port oder Anwendung.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"F\u00fcr dynamische Upstreams m\u00fcssen au\u00dferdem Versionsstand, Shared-Memory-Zone und ","ref":""},{"kind":"code","text":"resolve","ref":""},{"kind":"text","text":" zusammenpassen. Die hierf\u00fcr dokumentierte Open-Source-Unterst\u00fctzung gilt ab NGINX 1.27.3; \u00e4ltere Installationen d\u00fcrfen nicht als gleichwertig behandelt werden. ","ref":""},{"kind":"code","text":"status_zone","ref":""},{"kind":"text","text":" und API-basierte Resolver-Statistiken sind zudem keine allgemeine Monitoring-L\u00f6sung f\u00fcr NGINX Open Source, da die genannten Funktionen kommerziellen Umfang betreffen.","ref":""},{"kind":"citation","text":"","ref":"S2"}]}]},{"id":"betriebsentscheidung","heading":"Resolver-Strategie f\u00fcr den Betrieb w\u00e4hlen","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Die passende Strategie beginnt nicht mit einem pauschalen Cache-Wert, sondern mit DNS-Hoheit und \u00c4nderungsrate. Kann dein Team die autoritative Zone pflegen und bilden deren TTLs das Deployment-Fenster realistisch ab, ist eine ","ref":""},{"kind":"strong","text":"TTL-gesteuerte Aufl\u00f6sung","ref":""},{"kind":"text","text":" ohne ","ref":""},{"kind":"code","text":"valid","ref":""},{"kind":"text","text":" meist der nachvollziehbarste Ausgangspunkt. DNS bleibt dann die ma\u00dfgebliche Quelle daf\u00fcr, wie lange eine Antwort verwendet wird.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Ein bewusst gesetztes ","ref":""},{"kind":"code","text":"valid","ref":""},{"kind":"text","text":" kommt infrage, wenn du die TTL nicht beeinflussen kannst und eine abweichende Cache-Dauer betrieblich begr\u00fcnden kannst. Halte dabei fest, welche Ausfallfolge akzeptabel ist: Ein l\u00e4ngerer Wert senkt m\u00f6gliche DNS-Abfragen, kann aber nach einem Umzug auf eine nicht mehr passende Adresse zeigen. Er ist weder eine Obergrenze f\u00fcr die DNS-TTL noch ein allgemeiner Performance-Schalter.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"W\u00e4hle das NGINX-Muster danach anhand der Routing-Struktur. Ein variabler ","ref":""},{"kind":"code","text":"proxy_pass","ref":""},{"kind":"text","text":" eignet sich, wenn das Ziel pro Anfrage oder Konfiguration zur Laufzeit bestimmt wird; daf\u00fcr ist ein Resolver im passenden Scope erforderlich. F\u00fcr eine benannte Backend-Gruppe mit DNS-basierten Adress\u00e4nderungen ist ein Upstream mit ","ref":""},{"kind":"code","text":"zone","ref":""},{"kind":"text","text":" und ","ref":""},{"kind":"code","text":"resolve","ref":""},{"kind":"text","text":" klarer, sofern NGINX Open Source 1.27.3 oder neuer tats\u00e4chlich verf\u00fcgbar ist.","ref":""},{"kind":"citation","text":"","ref":"S2"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Erst anschlie\u00dfend bestimmst du ","ref":""},{"kind":"strong","text":"Timeouts und IP-Familien","ref":""},{"kind":"text","text":". Der Resolver-Timeout muss zu Client- und Upstream-Timeouts passen, damit eine ausbleibende DNS-Antwort Fehler nicht unverh\u00e4ltnism\u00e4\u00dfig verz\u00f6gert. IPv4 oder IPv6 schaltest du nur entsprechend der Netzarchitektur frei. Verwende ausschlie\u00dflich abgesicherte Resolver, die interne Zonen zuverl\u00e4ssig beantworten k\u00f6nnen.","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"DNS-Aufl\u00f6sung und Upstream-Keepalive l\u00f6sen unterschiedliche Aufgaben. Der Resolver entscheidet, welche Backend-Adresse NGINX verwenden kann; Keepalive h\u00e4lt bereits aufgebaute, inaktive Backend-Verbindungen zur Wiederverwendung vor. Eine \u00c4nderung an der Verbindungswiederverwendung ersetzt daher weder TTL-Planung noch Resolver-Pr\u00fcfung. F\u00fcr die Dimensionierung dieser Verbindungsebene erg\u00e4nzt der Beitrag zu ","ref":""},{"kind":"internal_link","text":"NGINX Upstream Keepalive","ref":"I2"},{"kind":"text","text":" die Resolver-Strategie.","ref":""}]}]}]},"_wh_make_word_report":{"words":2328,"min":2000,"max":3000,"target":2500,"ok":true,"missing":0,"excess":0,"lead_words":52,"section_words":{"resolver-grundlagen":207,"cache-arten-abgrenzen":204,"laufzeitauflosung-und-versionen":231,"ttl-und-valid-planen":359,"variabler-proxy-pass":235,"dynamische-upstreams":245,"sicher-ausrollen":246,"resolver-fehler-eingrenzen":288,"betriebsentscheidung":261}},"_wh_make_review":{"verdict":"pass","issues":[],"checked_source_ids":["S1","S2","S3","S4"],"summary":"Der Artikel ist fachlich plausibel und wird durch die gepr\u00fcften offiziellen NGINX-Quellen gest\u00fctzt. Die Trennung von DNS-Resolver-Cache, proxy_cache und Open File Cache ist korrekt. Ebenso stimmen die Aussagen zu DNS-TTL und valid, resolver_timeout, IPv4-\/IPv6-Aufl\u00f6sung, variablen proxy_pass-Zielen sowie den zul\u00e4ssigen Kontexten der resolver-Direktive. Die Versionsabgrenzung f\u00fcr dynamische Open-Source-Upstreams ist sauber: server \u2026 resolve war vor NGINX 1.27.3 kommerziell beschr\u00e4nkt, und resolver im upstream-Kontext ist seit 1.27.3 dokumentiert. Die Shared-Memory-Zone wird nicht als DNS-Datenpfad oder Cache-Laufzeit missverstanden. Konfigurationsbeispiele, Tabelle, Versionshinweis, Befehle und Reload-Beschreibung sind konsistent. Die Dokumentationsadresse 192.0.2.53 wird ausdr\u00fccklich nicht als produktiver Resolver ausgegeben. Bildkonzepte zeigen keine irref\u00fchrende Netzwerktopologie, und der Artikel behauptet keine eigenen Messungen oder praktischen Tests."},"_wh_make_review_doc_hash":"7409c5542ad659234dbfa2ed6abe78c26f8e117847396c732fd01ae84e63d022","_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,"inline_featured_image":null,"_yoast_wpseo_linkdex":null,"_eael_widget_elements":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_trp_translated_slug_en_us":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_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_wh_make_writer_raw":null,"_wh_make_design_backup_204":null,"_wp_desired_post_slug":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":"1","_edit_lock":"1790104142:1","_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":"91","_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,"_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":"68","rank_math_contentai_score":null,"ilj_limitincominglinks":"","ilj_maxincominglinks":"1","ilj_limitoutgoinglinks":"","ilj_maxoutgoinglinks":"1","ilj_limitlinksperparagraph":"","ilj_linksperparagraph":"1","ilj_blacklistdefinition":[],"ilj_linkdefinition":[],"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"NGINX Resolver Cache","rank_math_og_content_image":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":"21661","_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":"NGINX Resolver korrekt einrichten: DNS-TTL, valid, resolver_timeout und dynamische Upstreams f\u00fcr Reverse Proxies verst\u00e4ndlich planen.","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21658","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=21658"}],"version-history":[{"count":3,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21658\/revisions"}],"predecessor-version":[{"id":21664,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21658\/revisions\/21664"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/21661"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=21658"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=21658"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=21658"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}