{"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":"korrekt-konfiguration-af-nginx-resolver-cachen","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/nginx-resolver-cache-richtig-konfigurieren\/","title":{"rendered":"Korrekt konfiguration af NGINX-resolver-cachen"},"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\">Der <strong style=\"font-weight:700;color:inherit\">NGINX-resolver<\/strong> Cachelagrede DNS-svar for backend-navne, men ikke HTTP-svar. For at opn\u00e5 en robust reverse-proxy-konfiguration skal du bruge en p\u00e5lidelig intern navneserver, lade velvedligeholdte DNS-TTL\u2019er for det meste virke og indstille <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> kun som en bevidst overskrivning. Resolveren bliver is\u00e6r vigtig ved variable m\u00e5l i <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> samt ved dynamiske upstreams, hvis funktionalitet afh\u00e6nger af den installerede NGINX-version.   <\/p>\n<nav class=\"wh-toc\" aria-label=\"Indholdet af denne artikel\" 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\">G\u00e5 direkte til afsnittet<\/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\">Forst\u00e5else af NGINX-resolver og 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\">DNS-cachen er ikke en 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\">Hvorn\u00e5r NGINX skal opl\u00f8se navne igen<\/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\">Indstil TTL og valid bevidst<\/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\">Korrekt opl\u00f8sning af variabler i 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\">Konfigurer dynamiske upstreams med `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\">Kontroller konfigurationen grundigt og implementer den<\/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\">Systematisk indsn\u00e6vring af typiske resolver-fejl<\/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\">V\u00e6lg en resolver-strategi til driften<\/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\">Forst\u00e5else af NGINX-resolver og DNS-cache<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">En reverse proxy skal f\u00f8rst og fremmest have en IP-adresse til et backend med et v\u00e6rtsnavn. Den <strong style=\"font-weight:700;color:inherit\">NGINX-resolver<\/strong> foresp\u00f8rger i stedet de navneservere, der er angivet i konfigurationen. Det modtagne DNS-svar gemmes i cachen, s\u00e5 NGINX ikke beh\u00f8ver at opsl\u00e5 navnet p\u00e5 ny for hver foresp\u00f8rgsel i l\u00f8bet af dets gyldighedsperiode. Denne cache vedr\u00f8rer udelukkende navneopslag til m\u00e5lsystemet. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Direktivet <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> indeholder en eller flere resolver-adresser eller underst\u00f8ttede resolver-identifikatorer. Hvis der ikke er angivet en anden port, bruger NGINX port 53; hvis der er angivet flere servere, behandles foresp\u00f8rgslerne if\u00f8lge dokumentationen efter round-robin-princippet. For en robust bootstrap-konfiguration er faste IP-adresser ofte at foretr\u00e6kke, da deres opl\u00f8sning ikke selv afh\u00e6nger af DNS. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Som standard tager NGINX h\u00f8jde for b\u00e5de IPv4- og IPv6-adresser for et navn. Dette er passende, hvis netv\u00e6rket p\u00e5lideligt transporterer begge protokolfamilier helt frem til backend. Parametre som <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> eller <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> udelukker m\u00e5lrettet en bestemt familie, men udg\u00f8r ikke en generel cache-optimering. Om de er n\u00f8dvendige, afh\u00e6nger af tilg\u00e6ngeligheden af det konkrete backend og ikke af den blotte eksistens af en AAAA-post. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Resolveren er hverken en fuldgyldig rekursiv DNS-server eller en automatisk overtagelse af alle indstillinger fra <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 bruger de eksplicit angivne navneservere. For interne zoner og produktive backend-navne b\u00f8r det v\u00e6re en p\u00e5lidelig og tilstr\u00e6kkeligt sikret resolver i det eget netv\u00e6rk. P\u00e5 den m\u00e5de forbliver ansvaret for private navne og beskyttelsen mod manipulerede DNS-svar inden for en infrastruktur, der kan kontrolleres. <\/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\">DNS-cachen er ikke en HTTP-cache<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Resolverens DNS-responscache gemmer sammenkoblinger mellem navne og DNS-svar, f.eks. A- eller AAAA-adresser. Form\u00e5let er at kunne opn\u00e5 forbindelse til et backend igen uden at skulle gentage hver eneste navneopl\u00f8sning. Hvis en backend-IP \u00e6ndrer sig, er det derfor gyldigheden af DNS-svaret, der er relevant \u2013 ikke indholdet af et tidligere leveret HTTP-svar. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Uafh\u00e6ngigt heraf gemmer <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-svar fra en upstream. N\u00f8glen omfatter, afh\u00e6ngigt af konfigurationen, for eksempel URI, host eller header; et hit leverer et allerede gemt svar til klienten. Problemer viser sig her i form af for\u00e6ldede sider, forkerte varianter eller uventede cache-hits. Denne funktion bestemmer ikke, hvilken IP NGINX bruger, n\u00e5r der oprettes en ny backend-forbindelse. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Open-File-Cache er et tredje lag: Den indeholder filoplysninger og \u00e5bne deskriptorer til adgang til det lokale filsystem, men hverken DNS-svar eller HTTP-indhold. Hvis man \u00f8nsker at uddybe denne afgr\u00e6nsning i forbindelse med statisk levering, kan man finde den i artiklen om <a href=\"https:\/\/webhosting.de\/da\/vindue-til-optimering-af-nginx-cachen\/\">Konfiguration af NGINX Open File Cache<\/a>. Han giver dog ikke noget grundlag for at v\u00e6lge en Resolver-TTL.<\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">T\u00f8mning, rensning eller opdatering af en HTTP-cache fremskynder derfor ikke en DNS-\u00e6ndring. Omvendt l\u00f8ser en ny DNS-opslag ikke et problem med et forkert cachelagret HTTP-svar. Ved en reverse proxy begr\u00e6nser <strong style=\"font-weight:700;color:inherit\">DNS-cache<\/strong> desuden baserer sig p\u00e5 navne og adresser: Den kontrollerer hverken en applikations tilstand og erstatter heller ikke load-balancing, gentagne fors\u00f8g eller korrekt timeout-planl\u00e6gning i forhold til 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\">Hvorn\u00e5r NGINX skal opl\u00f8se navne igen<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">NGINX kan allerede kende et v\u00e6rtsnavn, n\u00e5r konfigurationen indl\u00e6ses. Det er anderledes med en variabel destination, f.eks. <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 s\u00f8ger f\u00f8rst efter det resulterende navn i de definerede upstream-grupper. Hvis det ikke finder et passende navn der, har det brug for en konfigureret resolver under k\u00f8rsel for at bestemme m\u00e5ladressen. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Meddelelsen <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> Dette tyder ikke p\u00e5, at der mangler en HTTP-cache. Det betyder, at NGINX ikke kender nogen DNS-server til den n\u00f8dvendige opl\u00f8sning under k\u00f8rsel. <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> m\u00e5 i denne sammenh\u00e6ng <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> eller <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> st\u00e5r. En central post i <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 er velegnet, n\u00e5r flere virtuelle v\u00e6rter bruger den samme resolver; et sn\u00e6vrere anvendelsesomr\u00e5de er kun relevant, hvis kravene rent faktisk adskiller sig.  <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Denne k\u00f8rselstidsopl\u00f8sning, der har v\u00e6ret tilg\u00e6ngelig i lang tid, skal adskilles fra den dynamiske opdatering af en klassisk upstream-gruppe. Resolver-konfigurationen direkte i <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>-blokken samt <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> If\u00f8lge dokumentationen er de tilg\u00e6ngelige i NGINX Open Source fra version 1.27.3 og frem. \u00c6ldre Open Source-installationer m\u00e5 ikke antages automatisk at underst\u00f8tte dette m\u00f8nster; historisk set var s\u00e5danne funktioner delvist forbeholdt NGINX Plus. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Inden du planl\u00e6gger dynamiske upstreams, skal du kontrollere de installerede output- og build-oplysninger. F\u00f8lgende kommando viser NGINX-versionen, kompilatorversionen og de configure-parametre, der blev brugt under buildet. <\/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>Kode<\/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\">Kopier kode<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Kopieret<\/span><span data-wh-copy-fallback hidden>Kode er markeret \u2013 kopier venligst<\/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\">Sammenlign den viste status ved kritiske implementeringer med dokumentationen for den konkrete pakke, der anvendes, og dens udbyder. Det afg\u00f8rende er, om denne installation dokumenterer og stiller den n\u00f8dvendige funktion til r\u00e5dighed. F\u00f8rst derefter er en <strong style=\"font-weight:700;color:inherit\">dynamisk upstream<\/strong> et robust arkitektonisk valg. <\/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\">Indstil TTL og valid bevidst<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">NGINX\u2019 resolver-cache f\u00f8lger som standard, uden yderligere angivelser, <strong style=\"font-weight:700;color:inherit\">DNS-TTL<\/strong> i svaret fra den forespurgte navneserver. Hvis den autoritative DNS-udbyder \u00e6ndrer IP-adressen p\u00e5 et backend, bruger NGINX det hidtidige svar, indtil dets TTL udl\u00f8ber. F\u00f8rst n\u00e5r der efterf\u00f8lgende igen er behov for en navneopl\u00f8sning, foresp\u00f8rger NGINX resolveren p\u00e5 ny. Dermed forbliver gyldighedsperioden styrbar d\u00e9r, hvor navnedataene vedligeholdes. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Parameteren <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> erstatter denne TTL fuldst\u00e6ndigt med den konfigurerede periode. Den s\u00e6tter alts\u00e5 ikke kun en \u00f8vre gr\u00e6nse for DNS-TTL\u2019en og definerer heller ikke en regelm\u00e6ssig opdatering ud over TTL\u2019en. En v\u00e6rdi p\u00e5 <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> kan forkorte en l\u00e6ngere DNS-TTL, men ogs\u00e5 forl\u00e6nge en bevidst kort TTL. Dette skal passe ind i planl\u00e6gningen af flytningen og implementeringen af backend-systemet. <\/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 af, hvordan DNS-TTL og valid p\u00e5virker cache-varigheden i NGINX-resolveren.\" 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 og en valid-override bestemmer p\u00e5 forskellige m\u00e5der, hvor l\u00e6nge svarene skal v\u00e6re gyldige.<\/figcaption><\/figure><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Hvis zonen vedligeholdes p\u00e5lideligt, er en konfiguration uden overskrivning det mest fornuftige udgangspunkt. Adressen i eksemplet er valgt i overensstemmelse med dokumentationsnetv\u00e6rkene og m\u00e5 ikke anvendes som en produktiv resolver. Indtast i stedet adressen p\u00e5 en tilg\u00e6ngelig og p\u00e5lidelig DNS-resolver fra dit eget netv\u00e6rk.<\/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>Kode<\/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\">Kopier kode<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Kopieret<\/span><span data-wh-copy-fallback hidden>Kode er markeret \u2013 kopier venligst<\/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\">En overstyring kan v\u00e6re hensigtsm\u00e6ssig, hvis DNS-TTL ikke kan \u00e6ndres, og der findes en dokumenteret driftsm\u00e6ssig retningslinje. Derefter viser afvigelsen tydeligt, hvor l\u00e6nge NGINX opbevarer svarene. Det er ikke en generel ydeevneoptimering: Kortere tider kan udl\u00f8se flere DNS-foresp\u00f8rgsler, mens l\u00e6ngere tider kan forsinke overgangen til nye backend-adresser. <\/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>Kode<\/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\">Kopier kode<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Kopieret<\/span><span data-wh-copy-fallback hidden>Kode er markeret \u2013 kopier venligst<\/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=\"Indledende beslutninger vedr\u00f8rende DNS-TTL og 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\">Indledende beslutninger vedr\u00f8rende DNS-TTL og 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\">Driftsforhold<\/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\">Indledende afg\u00f8relse<\/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\">\u00c5rsag<\/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\">Risiko<\/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 med opdaterede TTL-v\u00e6rdier<\/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\">udelade \u00bbvalid\u00ab<\/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 f\u00f8lger den cache-varighed, der er angivet af 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\">TTL skal passe til \u00e6ndringsvinduet.<\/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 kan ikke styres, udskiftning sker sj\u00e6ldent<\/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\">dokumentere \u00bbvalid\u00ab bevidst<\/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\">Det bliver muligt at planl\u00e6gge, hvor l\u00e6nge proxyen skal v\u00e6re aktiv.<\/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\">Gamle m\u00e5ladresser kan bruges l\u00e6ngere, end det er forudset i 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\">Hyppige serviceeftersyn eller udskiftning af containere<\/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\">Foretr\u00e6k korte TTL-v\u00e6rdier i den autoritative 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\">DNS er stadig den vigtigste kilde til aktuelle oplysninger.<\/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\">Flere foresp\u00f8rgsler kan belaste resolver-infrastrukturen.<\/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-baseret tjenestegenkendelse<\/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\">Kontroller dynamisk upstream med 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-medlemmerne kan f\u00f8lge med i \u00e6ndringer i 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:#f4f7f9;color:#294252\">Versionen og arkitekturen skal underst\u00f8tte funktionen.<\/td><\/tr><\/tbody><\/table><\/div><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Afg\u00f8relsen tager derfor ikke udgangspunkt i et bestemt antal sekunder, men i sp\u00f8rgsm\u00e5let om, hvem der kontrollerer DNS-dataene, og hvor hurtigt et skift af backend skal tr\u00e6de i kraft. <strong style=\"font-weight:700;color:inherit\">gyldig<\/strong> er et bevidst indgreb i denne regel. Det egner sig ikke som en generel l\u00f8sning til at g\u00f8re reverse proxyen hurtigere eller til at skjule DNS-problemer. <\/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\">Korrekt opl\u00f8sning af variabler i proxy_pass<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Indeholder <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> en variabel, skal NGINX behandle det resulterende v\u00e6rtsnavn under k\u00f8rsel. F\u00f8rst s\u00f8ger NGINX efter en passende upstream-gruppe; hvis den ikke finder nogen, har den brug for en konfigureret resolver til navnet. Mangler denne, er den typiske meddelelse <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> Der er ikke tale om en HTTP-cache, men om manglende DNS-konfiguration for denne eksekveringssti. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">F\u00f8lgende eksempel g\u00f8r k\u00f8rselstidsopl\u00f8sningen bevidst synlig. Resolveren befinder sig i <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>-konteksten og g\u00e6lder derfor for flere virtuelle v\u00e6rter, medmindre en mere specifik indstilling tilsides\u00e6tter den. Den anvendte dokumentationsadresse skal erstattes med det p\u00e5g\u00e6ldende milj\u00f8s interne resolver. <\/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>Kode<\/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\">Kopier kode<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Kopieret<\/span><span data-wh-copy-fallback hidden>Kode er markeret \u2013 kopier venligst<\/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\">Direktivet <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> bestemmer ikke cachevarigheden. Den begr\u00e6nser, hvor l\u00e6nge NGINX venter p\u00e5 en navneopl\u00f8sning; den dokumenterede standard er 30 sekunder. Valget h\u00f8rer til de \u00f8vrige fejlbudgetter: En for h\u00f8j v\u00e6rdi kan forsinke en mislykket foresp\u00f8rgsel indtil fejlmeddelelsen, mens en for lav v\u00e6rdi medf\u00f8rer un\u00f8dvendige opslagsfejl, n\u00e5r de interne opslagsmaskiner midlertidigt er langsomme. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">For en enkelt, klart afgr\u00e6nset placering kan resolveren i <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>-blokken. Hvis flere lokationer eller servere har brug for den samme opl\u00f8sning, skal der oprettes et f\u00e6lles scope i <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>- eller <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>-Blok kr\u00e6ver mindre vedligeholdelse. NGINX tillader direktivet i alle tre sammenh\u00e6nge; anvendelsesomr\u00e5det b\u00f8r afspejle den faktiske driftsstruktur og ikke blot l\u00f8se en enkelt fejlmeddelelse p\u00e5 kort sigt. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Selv ved variable m\u00e5l forbliver DNS-timeout og forbindelsen til backend separate fejlkategorier. En vellykket navneopl\u00f8sning beviser hverken, at m\u00e5lporten er tilg\u00e6ngelig, eller at applikationen svarer. Omvendt l\u00f8ser en l\u00e6ngere upstream-timeout ikke problemet med en utilg\u00e6ngelig resolver-adresse. <\/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\">Konfigurer dynamiske upstreams med `resolve`<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">For en navngivet backend-gruppe kan en dynamisk upstream v\u00e6re mere overskuelig end en variabel m\u00e5lv\u00e6rdi p\u00e5 hvert enkelt sted. M\u00f8nsteret adskiller definitionen af backend-medlemmerne fra routingen: <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> henviser til gruppen, mens v\u00e6rtsnavnet i upstream kan opdateres via DNS. Dette er is\u00e6r velegnet, n\u00e5r flere ruter peger p\u00e5 den samme applikation. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Parameteren <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> til en <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>-Indstillingen har historisk set eksisteret siden NGINX 1.5.12. I NGINX Open Source er den if\u00f8lge dokumentationen dog f\u00f8rst tilg\u00e6ngelig fra version 1.27.3; f\u00f8r da var denne funktion begr\u00e6nset til den kommercielle version. Ogs\u00e5 resolver-konfigurationen direkte i <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>-Blokken er dokumenteret som open source fra version 1.27.3. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Die <strong style=\"font-weight:700;color:inherit\">Shared-Memory-Zone<\/strong> Der er her tale om hverken en cache-timeout eller en DNS-datavej. Den stiller f\u00e6lles hukommelse til r\u00e5dighed inden for NGINX, som er n\u00f8dvendig for dynamisk \u00e6ndrede upstream-konfigurationer. Hvis NGINX ved DNS-opl\u00f8sningen finder andre adresser for navnet, kan upstream-gruppen tilpasses p\u00e5 baggrund af denne internt administrerede tilstand uden genstart. <\/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=\"Konceptuel fremstilling af en dynamisk NGINX-upstream med separat DNS-resolver, intern tilstand i delt hukommelse og backend-adresser.\" 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\">Shared-Memory-zonen administrerer upstream-tilstanden internt i NGINX; DNS-opl\u00f8sning og backend-forbindelser forbliver adskilte.<\/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>Kode<\/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\">Kopier kode<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Kopieret<\/span><span data-wh-copy-fallback hidden>Kode er markeret \u2013 kopier venligst<\/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\">Som i alle eksempler g\u00e6lder det, at <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> kun til en dokumentationsadresse. I praksis skal den registrerede resolver kende de interne navne p\u00e5lideligt, v\u00e6re tilg\u00e6ngelig fra NGINX-netv\u00e6rket og betragtes som p\u00e5lidelig. Inden implementeringen skal man desuden kontrollere det installerede pakkes faktiske funktionsomfang i stedet for udelukkende at udlede konfigurationen ud fra et aktuelt eksempel. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">En tjeneste, der udelukkende er tilg\u00e6ngelig via IPv4, kan berettige en m\u00e5lrettet begr\u00e6nsning: <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> forhindrer AAAA-foresp\u00f8rgsler og valg af en IPv6-adresse for denne resolver-kontekst. Dette er dog et valg, der skal tr\u00e6ffes p\u00e5 netv\u00e6rksarkitekturniveau. N\u00e5r Dual Stack fungerer korrekt, b\u00f8r IPv6 ikke deaktiveres blot af vane; som standard l\u00f8ser NGINX begge IP-familier. <\/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\">Kontroller konfigurationen grundigt og implementer den<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Inden du foretager en \u00e6ndring, skal du f\u00f8rst kontrollere, hvor resolver-direktiverne rent faktisk g\u00e6lder. Gennemg\u00e5 derfor den aktive konfiguration, herunder de indl\u00e6ste filer, og fastsl\u00e5, om resolveren g\u00e6lder for hele <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>-kontekst, der kun er beregnet til en virtuel v\u00e6rt eller blot til en enkelt sti. Et for sn\u00e6vert anvendelsesomr\u00e5de kan medf\u00f8re, at en anden variabel proxy-sti ikke kan finde en resolver; et for bredt anvendelsesomr\u00e5de g\u00f8r derimod den senere tilknytning af \u00e6ndringer vanskelig. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Efter hver tilpasning f\u00f8lger <strong style=\"font-weight:700;color:inherit\">Syntakscheck<\/strong>. Den indl\u00e6ser konfigurationen og fors\u00f8ger ogs\u00e5 at \u00e5bne de filer, der henvises til. P\u00e5 den m\u00e5de kan man opdage stavefejl, ugyldige direktiver og problemer i include-filer, inden man genindl\u00e6ser. Kontrollen beviser dog ikke, at den angivne DNS-server er tilg\u00e6ngelig, kender det forventede navn eller at backend'et bag en opl\u00f8st adresse accepterer forbindelser. <\/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>Kode<\/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\">Kopier kode<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Kopieret<\/span><span data-wh-copy-fallback hidden>Kode er markeret \u2013 kopier venligst<\/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\">Udf\u00f8r f\u00f8rst genindl\u00e6sningen, n\u00e5r kontrollen er gennemf\u00f8rt med et positivt resultat. <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> f\u00e5r NGINX til at starte nye worker-processer med den nye konfiguration og afslutte de gamle worker-processer p\u00e5 en kontrolleret m\u00e5de. Afh\u00e6ngigt af den installerede pakke og operativsystemet kan den dertilh\u00f8rende servicemanager i stedet udl\u00f8se genindl\u00e6sningen. Brug derfor den dokumenterede fremgangsm\u00e5de for installationen i stedet for at overtage kommandoer fra et eksternt milj\u00f8. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Planl\u00e6g derefter en teknisk test inden for det fastsatte \u00e6ndringsvindue. Sammenlign den forventede DNS-TTL med det tidspunkt, hvorfra en ny backend-adresse skal tages i brug, og kontroller, om tjenesten er tilg\u00e6ngelig via den faktisk tilladte IP-familie. Dokumenter desuden resolver-adressen, det valgte omfang og en eventuel <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. P\u00e5 den m\u00e5de kan man i tilf\u00e6lde af en fejl skelne mellem, om \u00e5rsagen ligger i DNS, routing eller applikationen. <\/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\">Systematisk indsn\u00e6vring af typiske resolver-fejl<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Start fejlfindingen ved m\u00e5ludtrykket i <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>. Hvis den indeholder en variabel, skal NGINX l\u00f8se det indeholdte v\u00e6rtsnavn under k\u00f8rsel, medmindre dette tilh\u00f8rer en defineret upstream-gruppe. Meddelelsen <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> p\u00e5peger derfor f\u00f8rst og fremmest, at der mangler en eller at den ikke er synlig i den relevante sammenh\u00e6ng <strong style=\"font-weight:700;color:inherit\">Resolver-konfiguration<\/strong> . Tilf\u00f8j en p\u00e5lidelig navneserver i den relevante sammenh\u00e6ng, i stedet for forhastet at erstatte v\u00e6rtsnavnet med en fast IP-adresse. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Hvis der er konfigureret en resolver, skal du herefter kontrollere dens adresse, netv\u00e6rkssti og ansvarsomr\u00e5de for den anvendte zone. En offentlig resolver kan ikke kende interne navne; en resolver, der ikke kan n\u00e5s, medf\u00f8rer derimod timeout ved navneopl\u00f8sning. Kontroller desuden, om direktivet overskrives af en mere specifik indstilling. NGINX bruger kun de udtrykkeligt angivne navneservere, ikke automatisk alle indstillinger fra <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\">Hvis en gammel destinationsadresse forbliver aktiv efter et DNS-skift, skal du kontrollere svarets TTL og se, om der er angivet en <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>. En lang override erstatter TTL-v\u00e6rdien i DNS-svaret og kan dermed forsinke gennemf\u00f8relsen af en \u00e6ndring. Den tilladte korrektion er ikke en generel, s\u00e5 kort varighed som muligt, men en v\u00e6rdi, der passer til \u00e6ndringsvinduet og DNS-infrastrukturens belastbarhed; ofte er udeladelsen af <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> den renere l\u00f8sning. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Hvis der opst\u00e5r forbindelsesproblemer efter en vellykket opl\u00f8sning, skal du adskille DNS fra backend-forbindelsen. Kontroller, om der foreligger A- og AAAA-svar, og om destinationen rent faktisk routes via IPv6 og er tilg\u00e6ngelig. <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> er kun egnet til en arkitektur, hvor det kan p\u00e5vises, at der udelukkende anvendes IPv4. En DNS-timeout vedr\u00f8rer navneopl\u00f8sningen; en forbindelsesfejl til en allerede kendt IP-adresse skyldes derimod routing, firewall, port eller applikation. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">For dynamiske upstreams skal der desuden angives versionsnummer, shared-memory-zone og <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> er kompatible. Den dokumenterede open source-underst\u00f8ttelse g\u00e6lder fra og med NGINX 1.27.3; \u00e6ldre installationer m\u00e5 ikke betragtes som \u00e6kvivalente. <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> Desuden udg\u00f8r API-baserede resolver-statistikker ikke en generel overv\u00e5gningsl\u00f8sning til NGINX Open Source, da de n\u00e6vnte funktioner vedr\u00f8rer kommerciel brug. <\/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\">V\u00e6lg en resolver-strategi til driften<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Den rigtige strategi starter ikke med en fast cache-v\u00e6rdi, men med DNS-kontrol og \u00e6ndringsfrekvens. Hvis dit team kan vedligeholde den autoritative zone, og hvis dens TTL\u2019er realistisk afspejler implementeringsvinduet, er en <strong style=\"font-weight:700;color:inherit\">TTL-styret opl\u00f8sning<\/strong> uden <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> er som regel det mest logiske udgangspunkt. DNS forbliver s\u00e5 den afg\u00f8rende kilde til, hvor l\u00e6nge et svar anvendes. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Et bevidst valgt <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> kan komme p\u00e5 tale, hvis du ikke kan p\u00e5virke TTL\u2019en og kan begrunde en afvigende cache-varighed ud fra driftsm\u00e6ssige \u00e5rsager. Husk at fastl\u00e6gge, hvilke konsekvenser af nedbrud der er acceptable: En l\u00e6ngere v\u00e6rdi reducerer antallet af mulige DNS-foresp\u00f8rgsler, men kan efter en flytning pege p\u00e5 en adresse, der ikke l\u00e6ngere er gyldig. Den er hverken en \u00f8vre gr\u00e6nse for DNS-TTL eller en generel pr\u00e6stationsregulator. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">V\u00e6lg derefter NGINX-m\u00f8nsteret ud fra routingstrukturen. En variabel <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> er egnet, n\u00e5r m\u00e5let bestemmes under k\u00f8rsel for hver foresp\u00f8rgsel eller konfiguration; dette kr\u00e6ver en resolver i det relevante omfang. For en navngivet backend-gruppe med DNS-baserede adresse\u00e6ndringer kr\u00e6ves en upstream med <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> og <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> klart, forudsat at NGINX Open Source 1.27.3 eller nyere faktisk er tilg\u00e6ngelig. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">F\u00f8rst derefter beslutter du <strong style=\"font-weight:700;color:inherit\">Timeouts og IP-familier<\/strong>. Resolver-timeoutet skal stemme overens med klient- og upstream-timeouts, s\u00e5 en udeblivet DNS-svar ikke forsinker fejlmeldinger uforholdsm\u00e6ssigt meget. IPv4 eller IPv6 skal du kun aktivere i overensstemmelse med netv\u00e6rksarkitekturen. Brug udelukkende sikre resolvere, der p\u00e5lideligt kan besvare interne zoner. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">DNS-opl\u00f8sning og upstream-keepalive l\u00f8ser forskellige opgaver. Resolveren afg\u00f8r, hvilken backend-adresse NGINX kan bruge; keepalive opretholder allerede etablerede, inaktive backend-forbindelser med henblik p\u00e5 genbrug. En \u00e6ndring af genbrug af forbindelser erstatter derfor hverken TTL-planl\u00e6gning eller resolver-kontrol. For dimensionering af dette forbindelsesniveau supplerer artiklen om <a href=\"https:\/\/webhosting.de\/da\/optimal-konfiguration-af-nginx-upstream-keepalive-reverse-proxy-netvaerk\/\">NGINX Upstream Keepalive<\/a> Resolver-strategien.<\/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\">Kilder og den aktuelle videnskabelige viden<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Status for unders\u00f8gelsen: <time datetime=\"2026-09-22\">2026-09-22<\/time><\/p><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Oplysningernes status: 22. september 2026. Eksemplerne p\u00e5 dynamiske upstreams med resolver i upstream-blokken og server \u2026 resolve henviser i NGINX Open Source til den dokumenterede underst\u00f8ttelse fra version 1.27.3 og frem; for distributionspakker er build- og producentdokumentation desuden afg\u00f8rende.<\/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>S\u00e5dan konfigurerer du NGINX-resolveren til dynamiske backends: DNS-TTL, valid, resolver_timeout, variable proxy_pass-m\u00e5l og dynamiske upstreams klart adskilt fra hinanden.<\/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":"S\u00e5dan konfigurerer du NGINX Open File Cache optimalt: S\u00e5dan f\u00e5r du mere ydeevne ud af din server","excerpt":"NGINX-cachen bliver m\u00e6rkbart hurtigere, n\u00e5r jeg indstiller Open File Cache m\u00e5lrettet: Den holder filmetadata og h\u00e5ndtag i hukommelsen og sparer dyre filsystemadgange. Med passende v\u00e6rdier for max, inactive, valid og min_uses optimerer jeg leveringen af statisk indhold til hurtige svartider og lavere I\/O-belastning. Vigtige punkter om metadatacache: gemmer eksistens, st\u00f8rrelse, tidspunkter og h\u00e5ndtere i stedet for indhold Dimensionering: Balance mellem RAM-forbrug, hitrate og \u00e6ndringshastighed Kontekster: ideel til billeder\/CSS\/JS; undg\u00e5 dynamiske stier Validering: Sikre aktualitet med open_file_cache_valid M\u00e5ling: Kontroller effekter p\u00e5 latenstider, I\/O og fejlprocent Hvad Open File Cache egentlig gemmer Med Open File Cache cacher jeg ikke filindhold, men strukturerede oplysninger: Findes en fil, hvor stor er den, hvorn\u00e5r blev den \u00e6ndret, og hvilken deskriptor er allerede \u00e5ben. Disse oplysninger ligger klar i hukommelsen og forkorter vejen til det n\u00e6ste svar. Hver undg\u00e5et harddiskforesp\u00f8rgsel s\u00e6nker I\/O-belastningen og sparer CPU-tid, hvilket is\u00e6r t\u00e6ller ved mange sm\u00e5 filer. If\u00f8lge NGINX-dokumentationen omfatter funktionen \u00e5bne deskriptorer, mappeoplysninger og lookup-fejl. Dette fremskynder mappescanninger og adgangsstier, som ellers ville skulle hentes fra harddisken p\u00e5 ny ved hver foresp\u00f8rgsel. Jeg bruger bevidst denne mekanisme til mapper med hyppig adgang, f.eks. til mediebiblioteker og build-assets. Effekten er s\u00e6rlig tydelig i projekter med mange assets, hvor filsystemet ellers bliver en flaskehals. Cachen reducerer systemkald som stat(), open() og readdir() m\u00e6rkbart. Samtidig forbliver kontrollen meget detaljeret, fordi jeg fastl\u00e6gger r\u00e6kkevidden og gyldigheden af posterne separat. P\u00e5 den m\u00e5de holder jeg dataene opdaterede uden at miste fordelen ved cachelagring. Hvorn\u00e5r Open File Cache er en fordel Jeg aktiverer cachen m\u00e5lrettet til statiske leverancer: billeder, CSS, JavaScript, skrifttyper og downloads. I dynamiske omr\u00e5der som login-sider, indk\u00f8bskurve eller personaliserede ruter undg\u00e5r jeg den, da der g\u00e6lder andre regler der. WordPress og headless-frontends drager stor fordel af den, fordi temaer, plugins og B"},"I2":{"id":"I2","post_id":21613,"url":"https:\/\/webhosting.de\/nginx-upstream-keepalive-optimal-konfigurieren-reverse-proxy-netzwerk\/","title":"Optimal konfiguration af NGINX Upstream Keepalive for maksimal ydeevne som reverse proxy","excerpt":"Jeg konfigurerer NGINX Upstream Keepalive, s\u00e5 reverse-proxyen opretter f\u00e6rre forbindelser, leverer lavere latenstider og p\u00e5lideligt afb\u00f8der belastningsspidser. I den forbindelse tilpasser jeg poolst\u00f8rrelse, tidsgr\u00e6nser og headere m\u00e5lrettet, s\u00e5 forbindelser genbruges, og datavejen forbliver slank. Vigtige punkter: H\u00e5ndh\u00e6ve HTTP\/1.1 og rense Connection-headere Dimensionere keepalive korrekt pr. worker Tilpasse timeouts til backend-v\u00e6rdier Begr\u00e6nse og genbruge anmodninger\/begr\u00e6nse og genbruge forbindelser Overv\u00e5gning af forbindelseshastighed og latenstid Hvorfor upstream-keepalive drastisk reducerer forbindelsesomkostningerne Uden genbrug \u00e5bner NGINX en ny backend-forbindelse pr. anmodning, hvilket koster ekstra handshakes, flere CPU-cyklusser og yderligere kernelressourcer; og det er netop her, Keepalive tr\u00e6der til. Jeg lader NGINX cache allerede oprettede, midlertidigt inaktive sockets og genbruge dem til efterf\u00f8lgende anmodninger, hvilket reducerer forbindelsestiderne m\u00e6rkbart. Det s\u00e6nker forbindelsesfrekvensen pr. sekund, reducerer spidsbelastninger i backloggen og bremser kontekstskift i operativsystemet. Is\u00e6r ved TLS til backend sparer jeg m\u00e6rkbart tid ved at genbruge sessioner. P\u00e5 den m\u00e5de forbliver svarek\u00e6den p\u00e5lidelig og reagerer flydende, selv ved h\u00f8j gennemstr\u00f8mning. Grundprincippet og keepalive-direktivet i upstream-blokken Direktivet keepalive i upstream-blokken begr\u00e6nser antallet af inaktive backend-forbindelser, der caches pr. worker. Denne gr\u00e6nse g\u00e6lder ikke globalt, men strengt pr. worker-proces, hvorfor jeg altid holder \u00f8je med antallet af workers. N\u00e5r puljen er fuld, lukker NGINX f\u00f8rst den forbindelse, der har v\u00e6ret ubenyttet l\u00e6ngst, s\u00e5 der er plads til nye sockets. Til genbrug kr\u00e6ver proxysiden HTTP\/1.1 og en neutraliseret Connection-header. Uden disse foruds\u00e6tninger forbliver puljen tom, selvom jeg indstiller \u201ekeepalive\u201c i upstream, hvilket overrasker mange administratorer i starten. upstream backend_pool { server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080; keepalive 32; # inaktive forbindelser pr. worker keepalive_requests 1000; # genbrug efter N anmodninger keepalive_timeout 60s; # inaktiv levetid } 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":"S\u00e5dan bruger du NGINX Cache Purge korrekt: En praktisk vejledning til hurtig og sikker cache-invalidering","excerpt":"Jeg viser dig, hvordan du m\u00e5lrettet t\u00f8mmer nginx-cachen uden at give bes\u00f8gende for\u00e6ldede svar eller risikere sikkerhedshuller. Med klare rydningsstrategier, rene cache-n\u00f8gler og en sikker automatisering opbygger jeg en arbejdsgang, der holder WordPress og PHP-FPM hurtige og opdaterede. Vigtige punkter: Planl\u00e6g cache-n\u00f8glerne omhyggeligt: host, URI, header og n\u00f8dvendige cookies. Kombiner rydningsstrategier: udl\u00f8bstider, m\u00e5lrettede n\u00f8gler, kontrolleret rydning. Prioriter sikkerhed frem for alt: interne IP-adresser, autentificering, logning, ingen \u00e5bne endepunkter. Brug automatisering: WordPress-hooks og deploy-triggere til rydninger Aktivere overv\u00e5gning: X-FastCGI-cache, logfiler, cache-st\u00f8rrelser Forst\u00e5 NGINX-caching: Grundlaget for fornuftig rydning F\u00f8r jeg rydder, forst\u00e5r jeg, hvordan NGINX lagrer. NGINX betjener HTTP-backends via proxy-cache og dynamiske PHP-svar via FastCGI-cache; derudover findes der varianter som uWSGI eller SCGI til s\u00e6rlige ops\u00e6tninger, som jeg her kun vil n\u00e6vne i forbifarten. I typiske WordPress- eller PHP-stacks er det is\u00e6r FastCGI-cachen, der giver den st\u00f8rste effekt, fordi den skriver f\u00e6rdige HTML-sider fra PHP-FPM til filsystemet og leverer dem direkte ved n\u00e6ste opkald. Det sk\u00e5ner CPU\u2019en og databasen og forkorter svartiderne, s\u00e5 l\u00e6nge indholdet er opdateret. Det er netop her, at intelligent rensning af cachen afg\u00f8r, om brugerne f\u00e5r opdaterede svar eller ser for\u00e6ldede sider. Cache-n\u00f8gler: N\u00f8glen til m\u00e5lrettet rensning Hvert hit er baseret p\u00e5 en cache-n\u00f8gle, der som regel best\u00e5r af host, request-URI, relevante headere og minimale cookie-dele. Jeg planl\u00e6gger n\u00f8glen s\u00e5ledes, at den kun tager h\u00f8jde for forskelle, der reelt \u00e6ndrer HTML-output, ellers fragmenterer jeg cachen un\u00f8digt. Jeg bruger Vary-headere, sprog eller enhedsklasser sparsomt og tester med pr\u00f8veanmodninger, om den \u00f8nskede variation virkelig er n\u00f8dvendig. En konsistent n\u00f8gle g\u00f8r det senere muligt at fjerne netop de objekter, der er ber\u00f8rt af en \u00e6ndring, i stedet for at slette store mapper. Rene n\u00f8gler sparer I\/O, holder hitraten h\u00f8j og letter purge-anmodninger enormt. Cache-n\u00f8gle-design i praksis: Normalisering og reduktion I praksis normaliserer jeg"}},"_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":"Korrekt konfiguration af NGINX-resolver-cachen","slug":"korrekt-konfiguration-af-nginx-resolver-cachen","excerpt":"S\u00e5dan konfigurerer du NGINX-resolveren til dynamiske backends: DNS-TTL, valid, resolver_timeout, variable proxy_pass-m\u00e5l og dynamiske upstreams klart adskilt fra hinanden.","status":"draft","featured_media":21661},"verify":{"content_md5":"00d4ee046c92de068b9c7a606af6b568","title":"Korrekt konfiguration af NGINX-resolver-cachen","slug":"korrekt-konfiguration-af-nginx-resolver-cachen","excerpt":"S\u00e5dan konfigurerer du NGINX-resolveren til dynamiske backends: DNS-TTL, valid, resolver_timeout, variable proxy_pass-m\u00e5l og dynamiske upstreams klart adskilt fra hinanden.","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":"Modul ngx_http_core_module"},"S2":{"id":"S2","url":"https:\/\/nginx.org\/en\/docs\/http\/ngx_http_upstream_module.html","title":"Modul ngx_http_upstream_module"},"S3":{"id":"S3","url":"https:\/\/nginx.org\/en\/docs\/http\/ngx_http_proxy_module.html?utm_source=openai","title":"Modul ngx_http_proxy_module"},"S4":{"id":"S4","url":"https:\/\/nginx.org\/en\/docs\/switches.html?utm_source=openai","title":"Kommandolinjeparametre"}},"_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":"Korrekt konfiguration af NGINX-resolver-cachen","slug":"korrekt-konfiguration-af-nginx-resolver-cachen","excerpt":"S\u00e5dan konfigurerer du NGINX-resolveren til dynamiske backends: DNS-TTL, valid, resolver_timeout, variable proxy_pass-m\u00e5l og dynamiske upstreams klart adskilt fra hinanden.","status":"draft","featured_media":0},"expected":{"content_md5":"00d4ee046c92de068b9c7a606af6b568","title":"Korrekt konfiguration af NGINX-resolver-cachen","slug":"korrekt-konfiguration-af-nginx-resolver-cachen","excerpt":"S\u00e5dan konfigurerer du NGINX-resolveren til dynamiske backends: DNS-TTL, valid, resolver_timeout, variable proxy_pass-m\u00e5l og dynamiske upstreams klart adskilt fra hinanden.","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":"Korrekt konfiguration af NGINX-resolver-cachen","slug":"korrekt-konfiguration-af-nginx-resolver-cachen","excerpt":"S\u00e5dan konfigurerer du NGINX-resolveren til dynamiske backends: DNS-TTL, valid, resolver_timeout, variable proxy_pass-m\u00e5l og dynamiske upstreams klart adskilt fra hinanden.","seo":{"title":"Korrekt konfiguration af NGINX-resolver-cachen","description":"Korrekt konfiguration af NGINX-resolver: Planl\u00e6gning af DNS-TTL, valid, resolver_timeout og dynamiske upstreams til reverse-proxyer p\u00e5 en forst\u00e5elig m\u00e5de.","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":"96","_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\/da\/wp-json\/wp\/v2\/posts\/21658","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=21658"}],"version-history":[{"count":3,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21658\/revisions"}],"predecessor-version":[{"id":21664,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21658\/revisions\/21664"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21661"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21658"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21658"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21658"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}