{"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":"konfigurera-nginx-resolver-cachen-korrekt","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/nginx-resolver-cache-richtig-konfigurieren\/","title":{"rendered":"Konfigurera NGINX Resolver-cachen korrekt"},"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> Cachelagrade DNS-svar f\u00f6r backend-namn, men inte HTTP-svar. F\u00f6r en robust konfiguration av en omv\u00e4nd proxy anv\u00e4nder du en p\u00e5litlig intern namnserver, l\u00e5ter v\u00e4lsk\u00f6tta DNS-TTL-v\u00e4rden i regel g\u00e4lla och st\u00e4ller in <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> endast som en medveten \u00f6verskrivning. Resolver blir s\u00e4rskilt viktigt vid variabla 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 vid dynamiska uppstr\u00f6msfunktioner, vars funktionsomf\u00e5ng beror p\u00e5 vilken version av NGINX som \u00e4r installerad.   <\/p>\n<nav class=\"wh-toc\" aria-label=\"Inneh\u00e5ll i denna 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 direkt till avsnittet<\/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\">Att f\u00f6rst\u00e5 NGINX-resolver och 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-cache \u00e4r inte samma sak som 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\">N\u00e4r NGINX m\u00e5ste l\u00f6sa upp namn p\u00e5 nytt<\/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\">Ange TTL och valid medvetet<\/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\">L\u00f6sa upp variabler i proxy_pass korrekt<\/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\">Konfigurera dynamiska uppstr\u00f6ms 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\">Kontrollera konfigurationen noggrant och rulla ut 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\">Systematiskt avgr\u00e4nsa typiska resolverfel<\/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\u00e4lj driftsstrategi f\u00f6r resolvern<\/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\">Att f\u00f6rst\u00e5 NGINX-resolver och DNS-cache<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">En omv\u00e4nd proxy beh\u00f6ver f\u00f6rst och fr\u00e4mst en IP-adress f\u00f6r ett backend med v\u00e4rdnamn. Den <strong style=\"font-weight:700;color:inherit\">NGINX-resolver<\/strong> f\u00f6r detta \u00e4ndam\u00e5l g\u00f6r NGINX en f\u00f6rfr\u00e5gan till de namnservrar som anges i konfigurationen. Det mottagna DNS-svaret lagras i cachen s\u00e5 att NGINX inte beh\u00f6ver l\u00f6sa namnet p\u00e5 nytt f\u00f6r varje f\u00f6rfr\u00e5gan under dess giltighetstid. Denna cache g\u00e4ller uteslutande namnuppl\u00f6sningen till 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> inneh\u00e5ller en eller flera resolveradresser respektive resolveridentifierare som st\u00f6ds. Om ingen annan port anges anv\u00e4nder NGINX port 53; om flera servrar \u00e4r angivna sker f\u00f6rfr\u00e5gningarna enligt dokumentationen enligt round-robin-metoden. F\u00f6r en robust bootstrap-konfiguration \u00e4r fasta IP-adresser ofta att f\u00f6redra, eftersom deras uppl\u00f6sning inte i sig \u00e4r beroende av DNS. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Som standard tar NGINX h\u00e4nsyn till b\u00e5de IPv4- och IPv6-adresser f\u00f6r ett namn. Detta \u00e4r l\u00e4mpligt om n\u00e4tverket p\u00e5 ett tillf\u00f6rlitligt s\u00e4tt vidarebefordrar b\u00e5da protokollfamiljerna till backend. Parametrar 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> utesluter specifikt en viss familj, men utg\u00f6r ingen allm\u00e4n cacheoptimering. Huruvida de \u00e4r n\u00f6dv\u00e4ndiga avg\u00f6rs av tillg\u00e4ngligheten till just det aktuella backend-systemet, och inte av att det enbart finns en AAAA-post. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Resolver \u00e4r varken en fullfj\u00e4drad rekursiv DNS-server eller en automatisk \u00f6vertagning av alla inst\u00e4llningar fr\u00e5n <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 anv\u00e4nder de uttryckligen angivna namnservrarna. F\u00f6r interna zoner och produktiva backend-namn b\u00f6r de p\u00e5litliga, tillr\u00e4ckligt s\u00e4kra resolverna finnas i det egna n\u00e4tverket. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir ansvaret f\u00f6r privata namn och skyddet mot manipulerade DNS-svar inom en infrastruktur som g\u00e5r att kontrollera. <\/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-cache \u00e4r inte samma sak som HTTP-cache<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Resolverns DNS-svar-cache lagrar kopplingar mellan namn och DNS-svar, till exempel A- eller AAAA-adresser. Syftet \u00e4r att kunna n\u00e5 en backend igen utan att beh\u00f6va upprepa varje namnuppl\u00f6sning. Om en backend-IP \u00e4ndras \u00e4r det d\u00e4rf\u00f6r DNS-svarets giltighet som \u00e4r relevant \u2013 inte inneh\u00e5llet i ett tidigare levererat HTTP-svar. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Detta lagras separat <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 fr\u00e5n en uppstr\u00f6ms. Beroende p\u00e5 konfigurationen omfattar nyckeln till exempel URI, v\u00e4rd eller rubrik; en tr\u00e4ff levererar ett redan lagrat svar till klienten. Problem uppst\u00e5r h\u00e4r i form av f\u00f6r\u00e5ldrade sidor, felaktiga varianter eller ov\u00e4ntade cachetr\u00e4ffar. Denna funktion avg\u00f6r inte vilken IP-adress NGINX anv\u00e4nder n\u00e4r en ny backend-anslutning uppr\u00e4ttas. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Open-File-Cache \u00e4r en tredje niv\u00e5: den lagrar filinformation och \u00f6ppna deskriptorer f\u00f6r lokala filsystem\u00e5tkomster, men varken DNS-svar eller HTTP-inneh\u00e5ll. Den som vill f\u00f6rdjupa sig i denna avgr\u00e4nsning f\u00f6r statisk leverans kan l\u00e4sa mer i artikeln om <a href=\"https:\/\/webhosting.de\/sv\/foenster-foer-optimering-av-nginx-cachen\/\">Konfiguration av NGINX Open File Cache<\/a>. Han ger dock ingen grund f\u00f6r att v\u00e4lja en resolver-TTL.<\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Att t\u00f6mma, rensa eller uppdatera en HTTP-cache p\u00e5skyndar d\u00e4rf\u00f6r inte en DNS-\u00e4ndring. Omv\u00e4nt \u00e5tg\u00e4rdar en ny DNS-uppl\u00f6sning inte ett felaktigt cachat HTTP-svar. Vid en omv\u00e4nd proxy begr\u00e4nsar <strong style=\"font-weight:700;color:inherit\">DNS-cache<\/strong> Dessutom baseras den p\u00e5 namn och adresser: Den kontrollerar varken en applikations stabilitet och ers\u00e4tter inte heller lastbalansering, \u00e5terf\u00f6rs\u00f6k eller korrekt tidsgr\u00e4nsplanering mot uppstr\u00f6ms.  <\/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\">N\u00e4r NGINX m\u00e5ste l\u00f6sa upp namn p\u00e5 nytt<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Ett v\u00e4rdnamn kan redan vara k\u00e4nt f\u00f6r NGINX n\u00e4r konfigurationen l\u00e4ses in. Det \u00e4r annorlunda n\u00e4r det g\u00e4ller ett variabelt m\u00e5l, till exempel <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\u00f6ker f\u00f6rst efter det resulterande namnet i definierade uppstr\u00f6msgrupper. Om det inte hittar n\u00e5got passande namn d\u00e4r beh\u00f6ver det en konfigurerad resolver under k\u00f6rning f\u00f6r att fastst\u00e4lla m\u00e5ladressen. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Anm\u00e4lan <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> Detta tyder inte p\u00e5 att det saknas en HTTP-cache. Det inneb\u00e4r att NGINX inte k\u00e4nner till n\u00e5gon DNS-server f\u00f6r den n\u00f6dv\u00e4ndiga uppl\u00f6sningen vid k\u00f6rning. <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> f\u00e5r i sammanhanget <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 \u00e4r l\u00e4mpligt n\u00e4r flera virtuella v\u00e4rdar anv\u00e4nder samma resolver; ett sn\u00e4vare till\u00e4mpningsomr\u00e5de \u00e4r endast l\u00e4mpligt om kraven faktiskt skiljer sig \u00e5t.  <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Denna k\u00f6rtidsuppl\u00f6sning, som l\u00e4nge funnits tillg\u00e4nglig, ska skiljas fr\u00e5n den dynamiska uppdateringen av en klassisk uppstr\u00f6msgrupp. Resolverkonfigurationen direkt 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>-blocket 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> Enligt dokumentationen i NGINX Open Source \u00e4r dessa tillg\u00e4ngliga fr\u00e5n och med version 1.27.3. \u00c4ldre Open Source-installationer f\u00e5r inte behandlas som om de automatiskt st\u00f6der detta m\u00f6nster; historiskt sett var s\u00e5dana funktioner delvis f\u00f6rbeh\u00e5llna NGINX Plus. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Innan du planerar dynamiska uppstr\u00f6msfl\u00f6den b\u00f6r du kontrollera den installerade utg\u00e5van och bygginformationen. F\u00f6ljande kommando visar NGINX-versionen, kompilatorversionen och de Configure-parametrar som anv\u00e4ndes vid byggningen. <\/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>Kod<\/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\">Kopiera koden<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Kopierat<\/span><span data-wh-copy-fallback hidden>Koden \u00e4r markerad \u2013 kopiera den<\/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\">J\u00e4mf\u00f6r den visade statusen vid kritiska distributioner med dokumentationen f\u00f6r det specifika paket som anv\u00e4nds och dess leverant\u00f6r. Det avg\u00f6rande \u00e4r om denna installation dokumenterar och tillhandah\u00e5ller den n\u00f6dv\u00e4ndiga funktionen. F\u00f6rst d\u00e4refter \u00e4r en <strong style=\"font-weight:700;color:inherit\">dynamisk uppstr\u00f6ms<\/strong> ett h\u00e5llbart arkitektoniskt val. <\/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\">Ange TTL och valid medvetet<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">NGINX:s resolver-cache f\u00f6ljer, utan n\u00e5gon ytterligare inst\u00e4llning, <strong style=\"font-weight:700;color:inherit\">DNS-TTL<\/strong> i svaret fr\u00e5n den tillfr\u00e5gade namnservern. Om den auktoritativa DNS-operat\u00f6ren \u00e4ndrar IP-adressen f\u00f6r en backend anv\u00e4nder NGINX det tidigare svaret fram till dess att dess TTL l\u00f6per ut. F\u00f6rst n\u00e4r en namnuppl\u00f6sning \u00e5terigen kr\u00e4vs efter detta skickar NGINX en ny f\u00f6rfr\u00e5gan till resolveren. P\u00e5 s\u00e5 s\u00e4tt kan giltighetstiden styras d\u00e4r namndata underh\u00e5lls. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Parametern <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> ers\u00e4tter denna TTL helt med den konfigurerade tidsperioden. Den begr\u00e4nsar allts\u00e5 inte bara DNS-TTL:s \u00f6vre gr\u00e4ns och definierar inte heller n\u00e5gon regelbunden uppdatering ut\u00f6ver TTL. Ett v\u00e4rde 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 f\u00f6rkorta en l\u00e4ngre DNS-TTL, men ocks\u00e5 f\u00f6rl\u00e4nga en medvetet kort TTL. Detta m\u00e5ste st\u00e4mma \u00f6verens med planeringen av flytt och drifts\u00e4ttning av 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 som visar hur DNS-TTL och valid p\u00e5verkar cachelagringstiden i NGINX-resolvern.\" 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 och en \u201dvalid\u201d-\u00f6verskrivning avg\u00f6r p\u00e5 olika s\u00e4tt hur l\u00e4nge svaren ska anv\u00e4ndas.<\/figcaption><\/figure><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Om zonen underh\u00e5lls p\u00e5 ett tillf\u00f6rlitligt s\u00e4tt \u00e4r en konfiguration utan \u00f6verskrivning den rimliga utg\u00e5ngspunkten. Adressen i exemplet har valts i enlighet med dokumentationsn\u00e4tverken och f\u00e5r inte anv\u00e4ndas som en produktiv resolver. Ange ist\u00e4llet adressen till en tillg\u00e4nglig och p\u00e5litlig DNS-resolver fr\u00e5n ditt eget n\u00e4tverk.<\/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>Kod<\/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\">Kopiera koden<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Kopierat<\/span><span data-wh-copy-fallback hidden>Koden \u00e4r markerad \u2013 kopiera den<\/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 \u00f6verskrivning kan vara l\u00e4mplig om DNS-TTL inte g\u00e5r att p\u00e5verka och det finns en dokumenterad driftsriktlinje. D\u00e5 visar avvikelsen tydligt hur l\u00e4nge NGINX beh\u00e5ller svaren. Det \u00e4r ingen allm\u00e4n prestandaoptimering: kortare tider kan utl\u00f6sa fler DNS-f\u00f6rfr\u00e5gningar, medan l\u00e4ngre tider kan f\u00f6rdr\u00f6ja \u00f6verg\u00e5ngen till nya 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>Kod<\/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\">Kopiera koden<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Kopierat<\/span><span data-wh-copy-fallback hidden>Koden \u00e4r markerad \u2013 kopiera den<\/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=\"Utg\u00e5ngsbeslut f\u00f6r DNS-TTL och 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\">Utg\u00e5ngsbeslut f\u00f6r DNS-TTL och 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\">Driftsituationen<\/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\">Inledande beslut<\/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\">Anledning<\/th><th scope=\"col\" style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#19394d;color:#fff\">Risk<\/th><\/tr><\/thead><tbody><tr><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#fff;color:#294252\">DNS-zon med uppdaterade TTL-v\u00e4rden<\/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\">utl\u00e4mna valid<\/td><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#fff;color:#294252\">NGINX f\u00f6ljer den cachelagringstid som anges av 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 m\u00e5ste st\u00e4mma \u00f6verens med \u00e4ndringsf\u00f6nstret.<\/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 inte styras, byten sker s\u00e4llan<\/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\">dokumentera valid p\u00e5 ett medvetet s\u00e4tt<\/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\">H\u00e5lltiden kan planeras f\u00f6r proxyn.<\/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\">Gamla m\u00e5ladresser kan anv\u00e4ndas l\u00e4ngre \u00e4n vad som \u00e4r avsett enligt 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\">Ofta f\u00f6rekommande service- eller beh\u00e5llarbyten<\/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\">Prioritera korta TTL-v\u00e4rden i den auktoritativa DNS-servern<\/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 \u00e4r fortfarande den viktigaste k\u00e4llan f\u00f6r aktuell information.<\/td><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#fff;color:#294252\">Fler f\u00f6rfr\u00e5gningar kan belasta 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-baserad tj\u00e4nsteidentifiering<\/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\">Kontrollera dynamisk uppstr\u00f6ms 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-medlemmarna kan f\u00f6lja DNS-\u00e4ndringar.<\/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 och arkitekturen m\u00e5ste st\u00f6dja funktionen.<\/td><\/tr><\/tbody><\/table><\/div><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Beslutet utg\u00e5r d\u00e4rf\u00f6r inte fr\u00e5n en fast angiven tid i sekunder, utan fr\u00e5n fr\u00e5gan om vem som kontrollerar DNS-uppgifterna och hur snabbt ett byte av backend m\u00e5ste tr\u00e4da i kraft. <strong style=\"font-weight:700;color:inherit\">giltig<\/strong> \u00e4r ett medvetet ingrepp i denna regel. Det l\u00e4mpar sig inte som en generell l\u00f6sning f\u00f6r att g\u00f6ra omv\u00e4nda proxyservrar snabbare eller f\u00f6r att d\u00f6lja DNS-problem. <\/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\">L\u00f6sa upp variabler i proxy_pass korrekt<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Inneh\u00e5ller <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 m\u00e5ste NGINX hantera det resulterande v\u00e4rdnamnet under k\u00f6rning. F\u00f6rst s\u00f6ker NGINX efter en l\u00e4mplig uppstr\u00f6msgrupp; om den inte hittar n\u00e5gon beh\u00f6ver den en konfigurerad resolver f\u00f6r namnet. Om denna saknas \u00e4r det vanliga meddelandet <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> Inget tecken p\u00e5 en HTTP-cache, utan p\u00e5 att DNS-konfigurationen saknas f\u00f6r denna k\u00f6rningsv\u00e4g. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">F\u00f6ljande exempel visar medvetet uppl\u00f6sningen av k\u00f6rningstiden. Resolvern finns 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>-kontexten och g\u00e4ller d\u00e4rmed f\u00f6r flera virtuella v\u00e4rdar, s\u00e5vida inte en mer specifik inst\u00e4llning \u00e5sidos\u00e4tter den. Den anv\u00e4nda dokumentationsadressen m\u00e5ste ers\u00e4ttas med den interna resolveren f\u00f6r respektive milj\u00f6. <\/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>Kod<\/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\">Kopiera koden<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Kopierat<\/span><span data-wh-copy-fallback hidden>Koden \u00e4r markerad \u2013 kopiera den<\/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> styr inte cachelagringstiden. Den begr\u00e4nsar hur l\u00e4nge NGINX v\u00e4ntar p\u00e5 en namnuppl\u00f6sning; det dokumenterade standardv\u00e4rdet \u00e4r 30 sekunder. Valet ing\u00e5r i de \u00f6vriga felbudgetarna: ett f\u00f6r h\u00f6gt v\u00e4rde kan f\u00f6rdr\u00f6ja en misslyckad f\u00f6rfr\u00e5gan \u00e4nda fram till felmeddelandet, medan ett f\u00f6r l\u00e5gt v\u00e4rde orsakar on\u00f6diga uppl\u00f6sningsfel vid tillf\u00e4lligt l\u00e5ngsamma interna uppl\u00f6sare. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">F\u00f6r en enskild, tydligt avgr\u00e4nsad plats 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>-blocket. Om flera platser eller servrar kr\u00e4ver samma uppl\u00f6sning, kr\u00e4vs ett gemensamt till\u00e4mpningsomr\u00e5de 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>-Block kr\u00e4ver mindre underh\u00e5ll. NGINX till\u00e5ter direktiven i alla tre sammanhangen; till\u00e4mpningsomr\u00e5det b\u00f6r \u00e5terspegla den faktiska driftsstrukturen, inte bara \u00e5tg\u00e4rda ett enskilt felmeddelande p\u00e5 kort sikt. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">\u00c4ven vid variabla m\u00e5l f\u00f6rblir DNS-timeout och anslutningen till backend separata felkategorier. En lyckad namnuppl\u00f6sning bevisar varken att m\u00e5lporten \u00e4r tillg\u00e4nglig eller att applikationen svarar. Omv\u00e4nt l\u00f6ser en l\u00e4ngre uppstr\u00f6ms-timeout inte problemet med en o\u00e5tkomlig resolveradress. <\/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\">Konfigurera dynamiska uppstr\u00f6ms med resolve<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">F\u00f6r en namngiven backend-grupp kan en dynamisk uppstr\u00f6ms vara l\u00e4ttare att l\u00e4sa \u00e4n ett variabelt m\u00e5lv\u00e4rde p\u00e5 varje plats. M\u00f6nstret skiljer definitionen av backend-medlemmarna fr\u00e5n routningen: <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> h\u00e4nvisar till gruppen, medan v\u00e4rdnamnet i uppstr\u00f6msn\u00e4tverket kan uppdateras via DNS. Detta \u00e4r s\u00e4rskilt l\u00e4mpligt n\u00e4r flera rutter pekar mot samma applikation. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Parametern <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> f\u00f6r 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>-Denna inst\u00e4llning har funnits sedan NGINX 1.5.12. Enligt dokumentationen finns den dock i NGINX Open Source f\u00f6rst fr\u00e5n och med version 1.27.3; tidigare var denna funktion begr\u00e4nsad till den kommersiella versionen. \u00c4ven resolver-konfigurationen direkt 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>-Blocket \u00e4r dokumenterat f\u00f6r \u00f6ppen k\u00e4llkod fr\u00e5n och med 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\">Delad minneszon<\/strong> Det handlar varken om en cache-timeout eller en DNS-datav\u00e4g. Den tillhandah\u00e5ller gemensamt minne inom NGINX som kr\u00e4vs f\u00f6r dynamiskt \u00e4ndrade uppstr\u00f6ms-konfigurationer. Om NGINX vid DNS-uppl\u00f6sningen identifierar andra adresser f\u00f6r namnet kan uppstr\u00f6msgruppen anpassas utifr\u00e5n detta internt hanterade tillst\u00e5nd utan omstart. <\/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=\"Konceptuell illustration av en dynamisk NGINX-upstream med separat DNS-resolver, internt delat minne och 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 hanterar uppstr\u00f6msstatusen inom NGINX; DNS-uppl\u00f6sning och backend-anslutningar hanteras separat.<\/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>Kod<\/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\">Kopiera koden<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Kopierat<\/span><span data-wh-copy-fallback hidden>Koden \u00e4r markerad \u2013 kopiera den<\/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\">Precis som i alla exempel g\u00e4ller att <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> endast f\u00f6r en dokumentationsadress. I praktiken m\u00e5ste den registrerade resolveren k\u00e4nna till interna namn p\u00e5 ett tillf\u00f6rlitligt s\u00e4tt, vara tillg\u00e4nglig fr\u00e5n NGINX-n\u00e4tverket och anses vara p\u00e5litlig. Innan konfigurationen tas \u00f6ver b\u00f6r dessutom den faktiska funktionsomfattningen f\u00f6r det installerade paketet kontrolleras, ist\u00e4llet f\u00f6r att enbart basera konfigurationen p\u00e5 ett aktuellt exempel. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">En tj\u00e4nst som endast \u00e4r tillg\u00e4nglig via IPv4 kan motivera en m\u00e5linriktad begr\u00e4nsning: <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> f\u00f6rhindrar AAAA-f\u00f6rfr\u00e5gningar och val av en IPv6-adress f\u00f6r detta resolver-sammanhang. Detta \u00e4r dock ett val som r\u00f6r n\u00e4tverksarkitekturen. Om dual stack fungerar b\u00f6r IPv6 inte inaktiveras enbart av vana; som standard l\u00f6ser NGINX b\u00e5da IP-familjerna. <\/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\">Kontrollera konfigurationen noggrant och rulla ut den<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Innan du g\u00f6r en \u00e4ndring b\u00f6r du f\u00f6rst kontrollera var Resolver-direktiven faktiskt g\u00e4ller. F\u00f6r att g\u00f6ra detta s\u00f6ker du upp den aktiva konfigurationen, inklusive inkluderade filer, och klarg\u00f6r om Resolver g\u00e4ller f\u00f6r hela <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>-kontext, som endast \u00e4r avsedd f\u00f6r en virtuell v\u00e4rd eller endast f\u00f6r en enskild s\u00f6kv\u00e4g. Ett f\u00f6r sn\u00e4vt till\u00e4mpningsomr\u00e5de kan leda till att en annan variabel proxys\u00f6kv\u00e4g inte hittar n\u00e5gon resolver; ett f\u00f6r brett till\u00e4mpningsomr\u00e5de f\u00f6rsv\u00e5rar d\u00e4remot den senare tilldelningen av \u00e4ndringar. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Efter varje justering f\u00f6ljer <strong style=\"font-weight:700;color:inherit\">Syntaxkontroll<\/strong>. Den l\u00e4ser in konfigurationen och f\u00f6rs\u00f6ker \u00e4ven \u00f6ppna de filer som refereras till. P\u00e5 s\u00e5 s\u00e4tt kan stavfel, ogiltiga direktiv och problem i inkluderade filer uppt\u00e4ckas innan en omladdning. Kontrollen bevisar dock inte att den angivna DNS-servern \u00e4r tillg\u00e4nglig, k\u00e4nner till det f\u00f6rv\u00e4ntade namnet eller att backend-servern bakom en uppl\u00f6st adress accepterar anslutningar. <\/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>Kod<\/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\">Kopiera koden<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Kopierat<\/span><span data-wh-copy-fallback hidden>Koden \u00e4r markerad \u2013 kopiera den<\/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\">Utf\u00f6r omladningen f\u00f6rst efter att kontrollen har genomf\u00f6rts med gott 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 att starta nya worker-processer med den nya konfigurationen och avsluta gamla worker-processer p\u00e5 ett kontrollerat s\u00e4tt. Beroende p\u00e5 vilket paket som \u00e4r installerat och vilket operativsystem som anv\u00e4nds kan ist\u00e4llet den tj\u00e4nstehanterare som finns d\u00e4r utl\u00f6sa omladdningen. Anv\u00e4nd d\u00e4rf\u00f6r den dokumenterade driftsv\u00e4gen f\u00f6r installationen ist\u00e4llet f\u00f6r att anv\u00e4nda kommandon fr\u00e5n en fr\u00e4mmande milj\u00f6. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Planera d\u00e4refter en teknisk testk\u00f6rning inom det avsedda \u00e4ndringsf\u00f6nstret. J\u00e4mf\u00f6r den f\u00f6rv\u00e4ntade DNS-TTL-tiden med den tidpunkt fr\u00e5n och med vilken en ny backend-adress ska anv\u00e4ndas, och kontrollera att tj\u00e4nsten \u00e4r tillg\u00e4nglig via den faktiskt till\u00e5tna IP-familjen. Dokumentera dessutom resolveradressen, det valda omf\u00e5nget och en eventuell <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 s\u00e5 s\u00e4tt g\u00e5r det att avg\u00f6ra vid ett fel om orsaken ligger i DNS, routningen 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\">Systematiskt avgr\u00e4nsa typiska resolverfel<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">B\u00f6rja fels\u00f6kningen med m\u00e5luttrycket 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>. Om den inneh\u00e5ller en variabel m\u00e5ste NGINX l\u00f6sa upp det v\u00e4rdnamn som finns i den vid k\u00f6rning, f\u00f6rutsatt att det inte tillh\u00f6r en definierad uppstr\u00f6msgrupp. Meddelandet <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\u00e5pekar d\u00e4rf\u00f6r inledningsvis att det saknas eller inte syns i det relevanta sammanhanget <strong style=\"font-weight:700;color:inherit\">Resolver-konfiguration<\/strong> . L\u00e4gg till en p\u00e5litlig namnserver i r\u00e4tt sammanhang, ist\u00e4llet f\u00f6r att f\u00f6rhastat ers\u00e4tta v\u00e4rdnamnet med en fast IP-adress. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Om en resolver \u00e4r konfigurerad ska du d\u00e4refter kontrollera dess adress, n\u00e4tv\u00e4g och ansvarsomr\u00e5de f\u00f6r den zon som anv\u00e4nds. En offentlig resolver kan inte k\u00e4nna till interna namn; en resolver som inte g\u00e5r att n\u00e5 orsakar d\u00e4remot tids\u00f6verskridningar vid namnuppl\u00f6sning. Kontrollera dessutom om direktivet \u00e5sidos\u00e4tts av en mer specifik inst\u00e4llning. NGINX anv\u00e4nder endast de namnservrar som uttryckligen anges, inte automatiskt alla inst\u00e4llningar fr\u00e5n <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\">Om en gammal m\u00e5ladress fortfarande \u00e4r aktiv efter ett DNS-byte, kontrollera svarets TTL och om 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 l\u00e5ng \u00f6verskrivning ers\u00e4tter TTL-v\u00e4rdet i DNS-svaret och kan d\u00e4rmed f\u00f6rdr\u00f6ja inf\u00f6randet av en \u00e4ndring. Den till\u00e5tna korrigeringen \u00e4r inte en generellt sett s\u00e5 kort varaktighet som m\u00f6jligt, utan ett v\u00e4rde som passar \u00e4ndringsf\u00f6nstret och DNS-infrastrukturens kapacitet; ofta inneb\u00e4r utel\u00e4mnandet av <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 renare l\u00f6sningen. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Om det uppst\u00e5r anslutningsproblem efter en lyckad uppl\u00f6sning ska du koppla bort DNS fr\u00e5n backend-anslutningen. Kontrollera om det finns A- och AAAA-svar och om m\u00e5let faktiskt routas via IPv6 och \u00e4r n\u00e5bart. <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> \u00e4r endast l\u00e4mpligt f\u00f6r en arkitektur d\u00e4r det bevisligen endast anv\u00e4nds IPv4. En DNS-timeout p\u00e5verkar namnuppl\u00f6sningen; ett anslutningsfel till en redan k\u00e4nd IP-adress tyder d\u00e4remot p\u00e5 problem med routning, brandv\u00e4gg, port eller applikation. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">F\u00f6r dynamiska uppstr\u00f6mmar m\u00e5ste dessutom versionsstatus, delat minnesomr\u00e5de och <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> \u00e4r kompatibla. Det dokumenterade st\u00f6det f\u00f6r \u00f6ppen k\u00e4llkod g\u00e4ller fr\u00e5n och med NGINX 1.27.3; \u00e4ldre installationer f\u00e5r inte betraktas som likv\u00e4rdiga. <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> Dessutom utg\u00f6r API-baserade resolver-statistikuppgifter ingen allm\u00e4n \u00f6vervakningsl\u00f6sning f\u00f6r NGINX Open Source, eftersom de n\u00e4mnda funktionerna avser kommersiell anv\u00e4ndning. <\/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\u00e4lj driftsstrategi f\u00f6r resolvern<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">En l\u00e4mplig strategi utg\u00e5r inte fr\u00e5n ett generellt cachev\u00e4rde, utan fr\u00e5n DNS-kontroll och \u00e4ndringsfrekvens. Om ditt team kan underh\u00e5lla den auktoritativa zonen och om dess TTL-v\u00e4rden p\u00e5 ett realistiskt s\u00e4tt \u00e5terspeglar drifts\u00e4ttningsf\u00f6nstret, \u00e4r en <strong style=\"font-weight:700;color:inherit\">TTL-styrd uppl\u00f6sning<\/strong> utan <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> oftast den mest begripliga utg\u00e5ngspunkten. DNS f\u00f6rblir d\u00e5 den avg\u00f6rande k\u00e4llan f\u00f6r hur l\u00e4nge ett svar anv\u00e4nds. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Ett medvetet placerat <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> \u00e4r ett alternativ om du inte kan p\u00e5verka TTL och kan motivera en avvikande cachel\u00e4ngd ur driftssynpunkt. Notera samtidigt vilka konsekvenser av avbrott som \u00e4r acceptabla: Ett l\u00e4ngre v\u00e4rde minskar antalet m\u00f6jliga DNS-f\u00f6rfr\u00e5gningar, men kan efter en flytt peka p\u00e5 en adress som inte l\u00e4ngre \u00e4r giltig. Det \u00e4r varken en \u00f6vre gr\u00e4ns f\u00f6r DNS-TTL eller en allm\u00e4n prestandaknapp. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">V\u00e4lj sedan NGINX-m\u00f6nstret utifr\u00e5n 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> \u00e4r l\u00e4mpligt n\u00e4r m\u00e5let best\u00e4ms vid k\u00f6rning, f\u00f6r varje f\u00f6rfr\u00e5gan eller konfiguration; f\u00f6r detta kr\u00e4vs en resolver inom r\u00e4tt omfattning. F\u00f6r en namngiven backend-grupp med DNS-baserade adress\u00e4ndringar kr\u00e4vs en uppstr\u00f6ms 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> och <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> tydligare, f\u00f6rutsatt att NGINX Open Source 1.27.3 eller senare faktiskt \u00e4r tillg\u00e4nglig. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">F\u00f6rst d\u00e4refter best\u00e4mmer du <strong style=\"font-weight:700;color:inherit\">Timeouts och IP-familjer<\/strong>. Resolver-timeouten m\u00e5ste st\u00e4mma \u00f6verens med klient- och uppstr\u00f6ms-timeouterna, s\u00e5 att ett uteblivet DNS-svar inte orsakar oproportionerligt l\u00e5nga f\u00f6rdr\u00f6jningar. Du aktiverar endast IPv4 eller IPv6 i enlighet med n\u00e4tverksarkitekturen. Anv\u00e4nd uteslutande s\u00e4kra resolver som p\u00e5 ett tillf\u00f6rlitligt s\u00e4tt kan besvara interna zoner. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">DNS-uppl\u00f6sning och Upstream-Keepalive fyller olika syften. Resolver avg\u00f6r vilken backend-adress NGINX kan anv\u00e4nda; Keepalive beh\u00e5ller redan uppr\u00e4ttade, inaktiva backend-anslutningar f\u00f6r \u00e5teranv\u00e4ndning. En \u00e4ndring av \u00e5teranv\u00e4ndningen av anslutningar ers\u00e4tter d\u00e4rf\u00f6r varken TTL-planering eller resolver-kontroll. F\u00f6r dimensioneringen av denna anslutningsniv\u00e5 kompletterar artikeln om <a href=\"https:\/\/webhosting.de\/sv\/konfigurera-nginx-upstream-keepalive-optimalt-omvaend-proxy-i-naetverket\/\">NGINX Upstream Keepalive<\/a> Resolver-strategin.<\/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\">K\u00e4llor och aktuell kunskapsniv\u00e5<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Forskningsl\u00e4get: <time datetime=\"2026-09-22\">2026-09-22<\/time><\/p><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">S\u00f6kresultat: 22 september 2026. Exemplen p\u00e5 dynamiska upstream-inst\u00e4llningar med resolver i upstream-blocket och server \u2026 resolve avser i NGINX Open Source det dokumenterade st\u00f6det fr\u00e5n och med version 1.27.3; f\u00f6r distributionspaket \u00e4r dessutom bygg- och tillverkardokumentationen avg\u00f6rande.<\/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\u00e5 h\u00e4r konfigurerar du NGINX-resolvern f\u00f6r dynamiska backend-tj\u00e4nster: DNS-TTL, valid, resolver_timeout, variabla proxy_pass-m\u00e5l och dynamiska uppstr\u00f6ms-tj\u00e4nster tydligt \u00e5tskilda fr\u00e5n varandra.<\/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":"Optimera inst\u00e4llningarna f\u00f6r NGINX Open File Cache: S\u00e5 h\u00e4r f\u00e5r du ut b\u00e4ttre prestanda ur din server","excerpt":"NGINX Cache blir m\u00e4rkbart snabbare n\u00e4r jag st\u00e4ller in Open File Cache p\u00e5 r\u00e4tt s\u00e4tt: Den lagrar filmetadata och handlar i minnet och sparar in kostsamma filsystem\u00e5tkomster. Med l\u00e4mpliga v\u00e4rden f\u00f6r max, inactive, valid och min_uses optimerar jag leveransen av statiskt inneh\u00e5ll f\u00f6r snabba svarstider och l\u00e4gre I\/O-belastning. Viktiga punkter f\u00f6r metadatacachen: lagrar f\u00f6rekomst, storlek, tider och handtag ist\u00e4llet f\u00f6r inneh\u00e5ll Dimensionering: balans mellan RAM-anv\u00e4ndning, tr\u00e4fffrekvens och \u00e4ndringshastighet Sammanhang: idealisk f\u00f6r bilder\/CSS\/JS; undvik dynamiska s\u00f6kv\u00e4gar Validering: s\u00e4kerst\u00e4ll aktualitet med open_file_cache_valid M\u00e4tning: Kontrollera effekterna p\u00e5 latens, I\/O och felfrekvens Vad Open File Cache egentligen lagrar Med Open File Cache cachelagrar jag inte filinneh\u00e5ll, utan strukturerad information: Finns en fil, hur stor \u00e4r den, n\u00e4r \u00e4ndrades den och vilken deskriptor \u00e4r redan \u00f6ppen? Denna information finns tillg\u00e4nglig i minnet och f\u00f6rkortar v\u00e4gen till n\u00e4sta svar. Varje undviket h\u00e5rddisk\u00e5tkomstf\u00f6rfr\u00e5gan minskar I\/O-belastningen och sparar CPU-tid, vilket framf\u00f6r allt \u00e4r viktigt vid m\u00e5nga sm\u00e5 filer. Enligt NGINX-dokumentationen omfattar funktionen \u00f6ppna deskriptorer, kataloginformation och uppslagsfel. Detta p\u00e5skyndar kataloggenomg\u00e5ngar och \u00e5tkomstv\u00e4gar som annars skulle beh\u00f6va l\u00e4sas in fr\u00e5n h\u00e5rddisken p\u00e5 nytt vid varje f\u00f6rfr\u00e5gan. Jag anv\u00e4nder medvetet denna mekanism f\u00f6r kataloger som anv\u00e4nds ofta, till exempel mediebibliotek och byggresurser. Effekten m\u00e4rks tydligt i projekt med m\u00e5nga resurser, d\u00e4r filsystemet annars skulle bli en flaskhals. Cachen minskar systemanrop som stat(), open() och readdir() m\u00e4rkbart. Samtidigt f\u00f6rblir kontrollen mycket detaljerad, eftersom jag separat anger r\u00e4ckvidd och giltighetstid f\u00f6r posterna. P\u00e5 s\u00e5 s\u00e4tt h\u00e5ller jag data uppdaterade utan att f\u00f6rlora f\u00f6rdelen med cachelagring. N\u00e4r det l\u00f6nar sig att anv\u00e4nda Open File Cache Jag aktiverar cachen specifikt f\u00f6r statiska leveranser: bilder, CSS, JavaScript, teckensnitt och nedladdningar. I dynamiska omr\u00e5den som inloggningssidor, varukorgar eller personaliserade fl\u00f6den undviker jag den, d\u00e4r g\u00e4ller andra regler. WordPress och headless-frontends drar stor nytta av den, eftersom teman, plugins och B"},"I2":{"id":"I2","post_id":21613,"url":"https:\/\/webhosting.de\/nginx-upstream-keepalive-optimal-konfigurieren-reverse-proxy-netzwerk\/","title":"Optimera inst\u00e4llningarna f\u00f6r NGINX Upstream Keepalive f\u00f6r maximal prestanda som omv\u00e4nd proxy","excerpt":"Jag konfigurerar NGINX Upstream Keepalive s\u00e5 att omv\u00e4nda proxyservern uppr\u00e4ttar f\u00e4rre anslutningar, ger l\u00e4gre latens och p\u00e5 ett tillf\u00f6rlitligt s\u00e4tt hanterar belastningstoppar. Samtidigt anpassar jag poolstorlek, tidsgr\u00e4nser och rubriker p\u00e5 ett m\u00e5linriktat s\u00e4tt s\u00e5 att anslutningar \u00e5teranv\u00e4nds och datav\u00e4gen f\u00f6rblir smidig. Viktiga punkter Tvinga HTTP\/1.1 och rensa Connection-rubriker Dimensionera keepalive korrekt per arbetare Anpassa tidsgr\u00e4nser till backend-v\u00e4rden Begr\u00e4nsa och \u00e5teranv\u00e4nda f\u00f6rfr\u00e5gningar\/anslutningar och \u00e5teranv\u00e4nda dem \u00d6vervaka anslutningshastighet och latens Varf\u00f6r Upstream Keepalive drastiskt minskar anslutningsbelastningen Utan \u00e5teranv\u00e4ndning \u00f6ppnar NGINX en ny backend-anslutning per beg\u00e4ran, vilket kostar extra handskakningar, fler CPU-cykler och ytterligare k\u00e4rnresurser; det \u00e4r just h\u00e4r som Keepalive kommer in i bilden. Jag l\u00e5ter NGINX cacha redan uppr\u00e4ttade, tillf\u00e4lligt vilande socklar och anv\u00e4nda dem f\u00f6r efterf\u00f6ljande f\u00f6rfr\u00e5gningar, vilket m\u00e4tbart minskar anslutningstiderna. Detta s\u00e4nker anslutningshastigheten per sekund, minskar toppar i backloggen och bromsar kontextbyten i operativsystemet. S\u00e4rskilt vid TLS-anslutningar till backend sparar jag m\u00e4rkbart tid genom \u00e5teranv\u00e4nda sessioner. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir svarskedjan tillf\u00f6rlitlig och reagerar smidigt \u00e4ven vid h\u00f6g genomstr\u00f6mning. Grundprincipen och keepalive-direktivet i upstream Direktivet keepalive i upstream-blocket begr\u00e4nsar antalet inaktiva backend-anslutningar som cachelagras per arbetare. Denna gr\u00e4ns g\u00e4ller inte globalt, utan strikt per arbetarprocess, vilket \u00e4r anledningen till att jag alltid h\u00e5ller koll p\u00e5 antalet arbetare. N\u00e4r poolen \u00e4r full st\u00e4nger NGINX f\u00f6rst den anslutning som varit oanv\u00e4nd l\u00e4ngst, s\u00e5 att det finns plats f\u00f6r nya socklar. F\u00f6r \u00e5teranv\u00e4ndning kr\u00e4ver proxysidan HTTP\/1.1 och en neutraliserad Connection-header. Utan dessa f\u00f6ruts\u00e4ttningar f\u00f6rblir poolen tom, \u00e4ven om jag st\u00e4ller in \u201ekeepalive\u201c i uppstr\u00f6msinst\u00e4llningarna, vilket \u00f6verraskar m\u00e5nga administrat\u00f6rer i b\u00f6rjan. upstream backend_pool { server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080; keepalive 32; # inaktiva anslutningar per arbetare keepalive_requests 1000; # \u00e5teranv\u00e4ndning efter N f\u00f6rfr\u00e5gningar keepalive_timeout 60s; # livsl\u00e4ngd vid inaktivitet } 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":"Att anv\u00e4nda NGINX Cache Purge p\u00e5 r\u00e4tt s\u00e4tt: En praktisk guide till snabb och s\u00e4ker cache-ogiltigf\u00f6rklaring","excerpt":"Jag visar dig hur du t\u00f6mmer nginx-cachen p\u00e5 ett m\u00e5linriktat s\u00e4tt utan att bes\u00f6kare f\u00e5r f\u00f6r\u00e5ldrade svar eller att du riskerar s\u00e4kerhetsbrister. Med tydliga rensningsstrategier, tydliga cache-nycklar och en s\u00e4ker automatisering bygger jag upp ett arbetsfl\u00f6de som h\u00e5ller WordPress och PHP-FPM snabba och uppdaterade. Viktiga punkter Planera cache-nycklarna noggrant: v\u00e4rd, URI, rubriker och n\u00f6dv\u00e4ndiga cookies Kombinera rensningsstrategier: utg\u00e5ngstider, specifika nycklar, kontrollerad rensning S\u00e4tt s\u00e4kerheten i f\u00f6rsta rummet: interna IP-adresser, autentisering, loggning, inga \u00f6ppna slutpunkter Utnyttja automatisering: WordPress-hooks och deploy-triggers f\u00f6r rensningar Aktivera \u00f6vervakning: X-FastCGI-cache, loggar, cache-storlekar F\u00f6rst\u00e5 NGINX-caching: grunden f\u00f6r meningsfull rensning Innan jag rensar f\u00f6rst\u00e5r jag hur NGINX lagrar. NGINX betj\u00e4nar HTTP-backends via proxycache och dynamiska PHP-svar via FastCGI-cache. Dessutom finns varianter som uWSGI eller SCGI f\u00f6r speciella konfigurationer, som jag h\u00e4r endast ber\u00f6r i f\u00f6rbig\u00e5ende. I typiska WordPress- eller PHP-stackar ger framf\u00f6r allt FastCGI-cachen den st\u00f6rsta effekten, eftersom den skriver f\u00e4rdiga HTML-sidor fr\u00e5n PHP-FPM till filsystemet och levererar dem direkt vid n\u00e4sta anrop. Detta avlastar CPU och databas och f\u00f6rkortar svarstiderna, s\u00e5 l\u00e4nge inneh\u00e5llet \u00e4r aktuellt. Det \u00e4r just h\u00e4r som smart rensning avg\u00f6r om anv\u00e4ndarna f\u00e5r f\u00e4rska svar eller ser f\u00f6r\u00e5ldrade sidor. Cache-nycklar: Nyckeln till m\u00e5linriktad rensning Varje tr\u00e4ff baseras p\u00e5 en cache-nyckel, som oftast best\u00e5r av v\u00e4rd, beg\u00e4ran-URI, relevanta rubriker och minimala cookie-delar. Jag utformar nyckeln s\u00e5 att den endast tar h\u00e4nsyn till skillnader som verkligen f\u00f6r\u00e4ndrar HTML-utdata, annars fragmenterar jag cachen i on\u00f6dan. Jag hanterar Vary-headers, spr\u00e5k eller enhetsklasser sparsamt och kontrollerar med testf\u00f6rfr\u00e5gningar om den \u00f6nskade variationen verkligen beh\u00f6vs. En konsekvent nyckel g\u00f6r det senare m\u00f6jligt att ta bort just de objekt som ber\u00f6rs av en \u00e4ndring, ist\u00e4llet f\u00f6r att radera stora kataloger. Rena nycklar sparar I\/O, h\u00e5ller tr\u00e4fffrekvensen h\u00f6g och underl\u00e4ttar purge-f\u00f6rfr\u00e5gningar avsev\u00e4rt. Utformning av cache-nycklar i praktiken: normalisering och reduktion I praktiken normaliserar jag"}},"_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":"Konfigurera NGINX Resolver-cachen korrekt","slug":"konfigurera-nginx-resolver-cachen-korrekt","excerpt":"S\u00e5 h\u00e4r konfigurerar du NGINX-resolvern f\u00f6r dynamiska backend-tj\u00e4nster: DNS-TTL, valid, resolver_timeout, variabla proxy_pass-m\u00e5l och dynamiska uppstr\u00f6ms-tj\u00e4nster tydligt \u00e5tskilda fr\u00e5n varandra.","status":"draft","featured_media":21661},"verify":{"content_md5":"00d4ee046c92de068b9c7a606af6b568","title":"Konfigurera NGINX Resolver-cachen korrekt","slug":"konfigurera-nginx-resolver-cachen-korrekt","excerpt":"S\u00e5 h\u00e4r konfigurerar du NGINX-resolvern f\u00f6r dynamiska backend-tj\u00e4nster: DNS-TTL, valid, resolver_timeout, variabla proxy_pass-m\u00e5l och dynamiska uppstr\u00f6ms-tj\u00e4nster tydligt \u00e5tskilda fr\u00e5n varandra.","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":"Kommandoradsparametrar"}},"_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":"Konfigurera NGINX Resolver-cachen korrekt","slug":"konfigurera-nginx-resolver-cachen-korrekt","excerpt":"S\u00e5 h\u00e4r konfigurerar du NGINX-resolvern f\u00f6r dynamiska backend-tj\u00e4nster: DNS-TTL, valid, resolver_timeout, variabla proxy_pass-m\u00e5l och dynamiska uppstr\u00f6ms-tj\u00e4nster tydligt \u00e5tskilda fr\u00e5n varandra.","status":"draft","featured_media":0},"expected":{"content_md5":"00d4ee046c92de068b9c7a606af6b568","title":"Konfigurera NGINX Resolver-cachen korrekt","slug":"konfigurera-nginx-resolver-cachen-korrekt","excerpt":"S\u00e5 h\u00e4r konfigurerar du NGINX-resolvern f\u00f6r dynamiska backend-tj\u00e4nster: DNS-TTL, valid, resolver_timeout, variabla proxy_pass-m\u00e5l och dynamiska uppstr\u00f6ms-tj\u00e4nster tydligt \u00e5tskilda fr\u00e5n varandra.","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":"Konfigurera NGINX Resolver-cachen korrekt","slug":"konfigurera-nginx-resolver-cachen-korrekt","excerpt":"S\u00e5 h\u00e4r konfigurerar du NGINX-resolvern f\u00f6r dynamiska backend-tj\u00e4nster: DNS-TTL, valid, resolver_timeout, variabla proxy_pass-m\u00e5l och dynamiska uppstr\u00f6ms-tj\u00e4nster tydligt \u00e5tskilda fr\u00e5n varandra.","seo":{"title":"Konfigurera NGINX Resolver-cachen korrekt","description":"Konfigurera NGINX Resolver korrekt: Planera DNS-TTL, valid, resolver_timeout och dynamiska uppstr\u00f6msanslutningar f\u00f6r omv\u00e4nda proxyservrar p\u00e5 ett \u00f6versk\u00e5dligt s\u00e4tt.","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":"97","_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\/sv\/wp-json\/wp\/v2\/posts\/21658","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/comments?post=21658"}],"version-history":[{"count":3,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/21658\/revisions"}],"predecessor-version":[{"id":21664,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/21658\/revisions\/21664"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/21661"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=21658"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=21658"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=21658"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}