{"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":"configurare-correttamente-la-cache-del-resolver-di-nginx","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/nginx-resolver-cache-richtig-konfigurieren\/","title":{"rendered":"Configurare correttamente la cache del resolver di NGINX"},"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\">Il sito <strong style=\"font-weight:700;color:inherit\">Resolver NGINX<\/strong> risposte DNS memorizzate nella cache per i nomi dei server backend, ma non le risposte HTTP. Per una configurazione robusta del proxy inverso, utilizza un server dei nomi interno affidabile, lascia che i valori TTL DNS aggiornati abbiano effetto nella maggior parte dei casi e imposta <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> solo come override esplicito. Il resolver assume particolare importanza in caso di destinazioni variabili in <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">proxy_pass<\/code> nonch\u00e9 nel caso di upstream dinamici, le cui funzionalit\u00e0 dipendono dalla versione di NGINX installata.   <\/p>\n<nav class=\"wh-toc\" aria-label=\"Contenuto di questo articolo\" 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\">Vai direttamente alla sezione<\/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\">Comprendere il resolver NGINX e la cache DNS<\/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\">La cache DNS non \u00e8 una cache HTTP<\/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\">Quando NGINX deve risolvere nuovamente i nomi<\/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\">Impostare in modo esplicito TTL e valid<\/a><\/div>\n<div class=\"wh-toc-item\" style=\"display:block;min-width:0;margin:0;padding:0\"><a class=\"wh-toc-link\" href=\"#variabler-proxy-pass\" style=\"display:block;height:100%;padding:12px 15px;border:1px solid #dce6e8;border-radius:9px;background:#fff;color:#18575b;font-size:14px;line-height:1.5;font-weight:600;text-decoration:none;box-sizing:border-box\">Risolvere correttamente le variabili in proxy_pass<\/a><\/div>\n<div class=\"wh-toc-item\" style=\"display:block;min-width:0;margin:0;padding:0\"><a class=\"wh-toc-link\" href=\"#dynamische-upstreams\" style=\"display:block;height:100%;padding:12px 15px;border:1px solid #dce6e8;border-radius:9px;background:#fff;color:#18575b;font-size:14px;line-height:1.5;font-weight:600;text-decoration:none;box-sizing:border-box\">Configurazione degli upstream dinamici con `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\">Verificare accuratamente la configurazione e implementarla<\/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\">Individuare sistematicamente i guasti tipici del resolver<\/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\">Scegliere la strategia del resolver per il funzionamento<\/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\">Comprendere il resolver NGINX e la cache DNS<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Per un backend con nome host, un proxy inverso necessita innanzitutto di un indirizzo IP. Il <strong style=\"font-weight:700;color:inherit\">Resolver NGINX<\/strong> a tal fine interroga i server dei nomi specificati nella configurazione. La risposta DNS ricevuta viene memorizzata nella cache, in modo che NGINX non debba risolvere nuovamente il nome per ogni richiesta durante il suo periodo di validit\u00e0. Questa cache riguarda esclusivamente la risoluzione del nome verso il sistema di destinazione. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">La direttiva <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> contiene uno o pi\u00f9 indirizzi di resolver o identificatori di resolver supportati. Se non viene specificata una porta diversa, NGINX utilizza la porta 53; se sono presenti pi\u00f9 server configurati, le richieste vengono gestite secondo l\u2019algoritmo round-robin, come indicato nella documentazione. Per una configurazione bootstrap robusta, gli indirizzi IP fissi sono spesso preferibili, poich\u00e9 la loro risoluzione non dipende a sua volta dal DNS. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Per impostazione predefinita, NGINX tiene conto degli indirizzi IPv4 e IPv6 associati a un nome. Ci\u00f2 \u00e8 appropriato se la rete trasmette in modo affidabile entrambe le famiglie di protocolli fino al backend. Parametri come <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> oppure <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> escludono in modo mirato una famiglia, ma non costituiscono un\u2019ottimizzazione generale della cache. La loro necessit\u00e0 dipende dall\u2019accessibilit\u00e0 del backend specifico e non dalla semplice esistenza di un record AAAA. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Il resolver non \u00e8 n\u00e9 un server DNS ricorsivo a tutti gli effetti, n\u00e9 un sistema che importa automaticamente tutte le impostazioni da <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 utilizza i server dei nomi specificati esplicitamente. Per le zone interne e i nomi dei backend di produzione, \u00e8 opportuno che i resolver siano affidabili e adeguatamente protetti all\u2019interno della propria rete. In questo modo, la responsabilit\u00e0 per i nomi privati e la protezione dalle risposte DNS manomesse rimangono all\u2019interno di un\u2019infrastruttura controllabile. <\/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\">La cache DNS non \u00e8 una cache HTTP<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">La cache delle risposte DNS del resolver memorizza le associazioni tra nomi e risposte DNS, come gli indirizzi A o AAAA. Il suo scopo \u00e8 quello di poter raggiungere nuovamente un backend senza dover ripetere ogni volta la risoluzione del nome. Se l\u2019IP di un backend cambia, \u00e8 quindi rilevante la validit\u00e0 della risposta DNS, non il contenuto di una risposta HTTP fornita in precedenza. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Separatamente da ci\u00f2, salva <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> Risposte HTTP di un upstream. A seconda della configurazione, la chiave pu\u00f2 includere, ad esempio, l'URI, l'host o l'intestazione; una corrispondenza fornisce al client una risposta gi\u00e0 memorizzata. I problemi che possono verificarsi in questo caso sono pagine non aggiornate, varianti errate o hit della cache imprevisti. Questa funzione non determina quale indirizzo IP NGINX utilizzi quando stabilisce una nuova connessione al backend. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">La cache dei file aperti costituisce un terzo livello: memorizza le informazioni sui file e i descrittori aperti per gli accessi al file system locale, ma non le risposte DNS n\u00e9 i contenuti HTTP. Chi desidera approfondire questa distinzione per la distribuzione statica, pu\u00f2 trovare ulteriori informazioni nell'articolo dedicato a <a href=\"https:\/\/webhosting.de\/it\/finestra-di-ottimizzazione-della-cache-di-nginx\/\">Configurazione della cache dei file aperti di NGINX<\/a>. Tuttavia, non fornisce alcun criterio per la scelta del TTL del resolver.<\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Lo svuotamento, la pulizia o l\u2019aggiornamento di una cache HTTP non accelera quindi l\u2019aggiornamento del DNS. Viceversa, una nuova risoluzione DNS non corregge una risposta HTTP memorizzata in modo errato nella cache. Nel caso di un reverse proxy, il <strong style=\"font-weight:700;color:inherit\">Cache DNS<\/strong> si basa inoltre su nomi e indirizzi: non verifica n\u00e9 la correttezza di un\u2019applicazione, n\u00e9 sostituisce il bilanciamento del carico, i tentativi di riconnnessione o la corretta pianificazione dei timeout verso l\u2019upstream.  <\/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\">Quando NGINX deve risolvere nuovamente i nomi<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">NGINX pu\u00f2 gi\u00e0 conoscere un nome host al momento della lettura della configurazione. Diverso \u00e8 il caso di una destinazione variabile, ad esempio <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 cerca innanzitutto il nome risultante nei gruppi upstream definiti. Se non trova alcun nome corrispondente, ha bisogno, in fase di esecuzione, di un resolver configurato per determinare l'indirizzo di destinazione. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Il messaggio <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">no resolver defined<\/code> In questo contesto, non indica la mancanza di una cache HTTP. Significa che NGINX non conosce alcun server DNS per la risoluzione necessaria in fase di esecuzione. <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> pu\u00f2 essere utilizzato nel contesto <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> oppure <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> si trovano. Una voce fondamentale nel <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>Il blocco - \u00e8 indicato quando pi\u00f9 host virtuali utilizzano lo stesso resolver; un ambito pi\u00f9 ristretto \u00e8 appropriato solo in caso di requisiti effettivamente diversi.  <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Da questa risoluzione del tempo di esecuzione, disponibile da tempo, va distinta l\u2019aggiornamento dinamico di un classico gruppo upstream. La configurazione del resolver direttamente nel <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>-blocco e <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> Secondo la documentazione, in NGINX Open Source sono disponibili a partire dalla versione 1.27.3. Le installazioni Open Source precedenti non devono essere considerate come se supportassero automaticamente questo modello; storicamente, alcune di queste funzionalit\u00e0 erano riservate a NGINX Plus. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Prima di pianificare gli upstream dinamici, controlla le informazioni relative alla versione installata e alla compilazione. Il comando seguente mostra la versione di NGINX, la versione del compilatore e i parametri di configurazione utilizzati durante la compilazione. <\/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>Codice<\/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\">Copia il codice<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Copiato<\/span><span data-wh-copy-fallback hidden>Codice evidenziato \u2013 copiare<\/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\">Confronta lo stato visualizzato in caso di distribuzioni critiche con la documentazione del pacchetto effettivamente utilizzato e del relativo fornitore. \u00c8 determinante verificare se tale installazione documenti e fornisca la funzionalit\u00e0 richiesta. Solo allora \u00e8 possibile <strong style=\"font-weight:700;color:inherit\">upstream dinamico<\/strong> una scelta architettonica solida. <\/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\">Impostare in modo esplicito TTL e valid<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">La cache del resolver di NGINX, in assenza di ulteriori impostazioni, si basa sulla <strong style=\"font-weight:700;color:inherit\">DNS-TTL<\/strong> nella risposta del server dei nomi interpellato. Se il gestore DNS autorevole modifica l\u2019indirizzo IP di un backend, NGINX utilizza la risposta precedente fino alla scadenza del suo TTL. Solo quando in seguito \u00e8 nuovamente necessaria una risoluzione del nome, NGINX interroga nuovamente il resolver. In questo modo, la durata di validit\u00e0 rimane controllabile nel punto in cui vengono gestiti i dati relativi ai nomi. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Il parametro <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> sostituisce completamente questo TTL con il periodo configurato. Pertanto, non solo limita il TTL DNS verso l\u2019alto, ma non definisce nemmeno un aggiornamento periodico in aggiunta al TTL. Un valore pari a <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">valid=30s<\/code> pu\u00f2 ridurre un TTL DNS pi\u00f9 lungo, ma anche prolungare un TTL volutamente breve. Ci\u00f2 deve essere in linea con la pianificazione del trasferimento e della distribuzione del backend. <\/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=\"Illustrazione dell&#039;effetto dei parametri DNS-TTL e valid sulla durata della cache nel resolver NGINX.\" 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\">Il TTL DNS e un override \"valid\" determinano in modi diversi per quanto tempo vengono utilizzate le risposte.<\/figcaption><\/figure><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Se la zona viene gestita in modo affidabile, una configurazione senza override costituisce il punto di partenza pi\u00f9 logico. L\u2019indirizzo riportato nell\u2019esempio \u00e8 stato scelto in base alle reti descritte nella documentazione e non deve essere utilizzato come resolver produttivo. Inserisci invece l\u2019indirizzo di un resolver DNS raggiungibile e affidabile proveniente dalla propria rete.<\/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>Codice<\/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\">Copia il codice<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Copiato<\/span><span data-wh-copy-fallback hidden>Codice evidenziato \u2013 copiare<\/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\">Un override pu\u00f2 essere utile quando non \u00e8 possibile modificare il TTL del DNS ed esiste una politica operativa documentata. In tal caso, la deroga rende esplicitamente visibile per quanto tempo NGINX mantiene le risposte. Non si tratta di un'ottimizzazione generale delle prestazioni: tempi pi\u00f9 brevi possono generare un maggior numero di query DNS, mentre tempi pi\u00f9 lunghi possono ritardare il passaggio a nuovi indirizzi di backend. <\/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>Codice<\/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\">Copia il codice<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Copiato<\/span><span data-wh-copy-fallback hidden>Codice evidenziato \u2013 copiare<\/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=\"Decisioni iniziali relative a DNS-TTL e 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\">Decisioni iniziali relative a DNS-TTL e 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\">Situazione aziendale<\/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\">Decisione iniziale<\/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\">Motivo<\/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\">Il rischio<\/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\">Zona DNS con TTL aggiornati<\/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\">omettere \"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 rispetta la durata della cache specificata dal 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\">Il TTL deve corrispondere alla finestra di modifica.<\/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 non controllabile, sostituzioni rare<\/td><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#f4f7f9;color:#294252\">documentare in modo consapevole e accurato<\/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\">La durata di detenzione diventa pianificabile per il proxy.<\/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\">I vecchi indirizzi di destinazione possono essere utilizzati pi\u00f9 a lungo di quanto previsto dal 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\">Sostituzioni frequenti dell'assistenza o dei contenitori<\/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\">Privilegiare i TTL brevi nel DNS autorevole<\/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\">Il DNS rimane la fonte di riferimento per le notizie di attualit\u00e0.<\/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\">Un numero maggiore di richieste pu\u00f2 sovraccaricare l'infrastruttura del resolver.<\/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\">Riconoscimento dei servizi basato sul DNS<\/td><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#f4f7f9;color:#294252\">Verifica dell'upstream dinamico con 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\">I membri di Upstream possono seguire le modifiche al DNS.<\/td><td style=\"padding:15px 18px;border:0;border-bottom:1px solid #e2e9ed;text-align:start;vertical-align:top;white-space:normal;font-size:15px;line-height:1.6;background:#f4f7f9;color:#294252\">La versione e l'architettura devono supportare la funzione.<\/td><\/tr><\/tbody><\/table><\/div><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">La decisione non parte quindi da un\u2019indicazione precisa in secondi, ma dalla domanda su chi controlli i dati DNS e con quale rapidit\u00e0 debba diventare effettivo un cambio di backend. <strong style=\"font-weight:700;color:inherit\">valido<\/strong> rappresenta un intervento deliberato su questa configurazione. Non \u00e8 adatto come soluzione generica per velocizzare il reverse proxy o per mascherare problemi relativi al DNS. <\/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\">Risolvere correttamente le variabili in proxy_pass<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Contiene <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> una variabile, NGINX deve gestire il nome host risultante in fase di esecuzione. Innanzitutto, NGINX cerca un gruppo upstream corrispondente; se non lo trova, ha bisogno di un resolver configurato per quel nome. Se questo manca, viene visualizzato il tipico messaggio <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> Non si tratta di un riferimento alla cache HTTP, bens\u00ec alla mancanza di una configurazione DNS per questo percorso di esecuzione. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Il seguente esempio mette volutamente in evidenza la risoluzione del runtime. Il resolver si trova nel <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>-contesto e, di conseguenza, si applica a pi\u00f9 host virtuali, a meno che un\u2019impostazione pi\u00f9 specifica non la sovrascriva. L\u2019indirizzo di documentazione utilizzato deve essere sostituito dal resolver interno del rispettivo ambiente. <\/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>Codice<\/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\">Copia il codice<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Copiato<\/span><span data-wh-copy-fallback hidden>Codice evidenziato \u2013 copiare<\/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\">La direttiva <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> Non controlla la durata della cache. Limita il tempo che NGINX attende per la risoluzione di un nome; il valore predefinito documentato \u00e8 di 30 secondi. La scelta rientra tra gli altri \u00abmargini di errore\u00bb: un valore troppo elevato pu\u00f2 ritardare una richiesta non riuscita fino alla risposta di errore, mentre un valore troppo basso genera errori di risoluzione evitabili in caso di resolver interni temporaneamente lenti. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Per una singola sede chiaramente definita, il resolver pu\u00f2 essere impostato nel <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">location<\/code>-Block. Se pi\u00f9 location o server richiedono la stessa risoluzione, \u00e8 necessario definire uno scope comune nel <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>- o <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 richiede meno manutenzione. NGINX consente l'uso della direttiva in tutti e tre i contesti; l'ambito di applicazione dovrebbe rispecchiare l'effettiva struttura operativa, non limitarsi a risolvere temporaneamente un singolo messaggio di errore. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Anche nel caso di destinazioni variabili, il timeout DNS e la connessione al backend rimangono classi di errore distinte. Una risoluzione del nome riuscita non dimostra n\u00e9 che la porta di destinazione sia raggiungibile, n\u00e9 che l'applicazione risponda. Viceversa, un timeout upstream pi\u00f9 lungo non risolve il problema di un indirizzo del resolver irraggiungibile. <\/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\">Configurazione degli upstream dinamici con `resolve`<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Per un gruppo di backend specificato, un upstream dinamico pu\u00f2 risultare pi\u00f9 leggibile rispetto a un valore di destinazione variabile in ogni location. Questo modello separa la definizione dei membri del backend dal routing: <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">proxy_pass<\/code> si riferisce al gruppo, mentre il nome host nell'upstream pu\u00f2 essere aggiornato tramite DNS. Ci\u00f2 \u00e8 particolarmente utile quando pi\u00f9 percorsi puntano alla stessa applicazione. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Il parametro <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> per un <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>- Questa voce esiste storicamente a partire da NGINX 1.5.12. Tuttavia, secondo la documentazione, nella versione open source di NGINX \u00e8 disponibile solo a partire dalla versione 1.27.3; in precedenza questa funzione era limitata alla versione commerciale. Anche la configurazione del resolver direttamente nel <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>- Il blocco \u00e8 documentato per l'Open Source a partire dalla versione 1.27.3. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Il sito <strong style=\"font-weight:700;color:inherit\">Zona di memoria condivisa<\/strong> Non si tratta n\u00e9 di un timeout della cache n\u00e9 di un percorso dei dati DNS. Fornisce memoria condivisa all\u2019interno di NGINX, necessaria per le configurazioni upstream soggette a modifiche dinamiche. Se durante la risoluzione DNS NGINX rileva indirizzi diversi per il nome, il gruppo upstream pu\u00f2 essere adattato sulla base di questo stato gestito internamente senza necessit\u00e0 di riavvio. <\/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=\"Rappresentazione concettuale di un upstream NGINX dinamico con resolver DNS separato, stato interno in memoria condivisa e indirizzi backend.\" 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\">La zona di memoria condivisa gestisce lo stato upstream all'interno di NGINX; la risoluzione DNS e le connessioni al backend rimangono separate.<\/figcaption><\/figure><div class=\"wh-code-window\" data-wh-code style=\"margin:28px 0 34px;border:1px solid #2c4656;border-radius:12px;overflow:hidden;background:#132a3b;box-shadow:0 9px 25px -13px rgba(15,35,55,.2)\"><div class=\"wh-code-toolbar\" style=\"display:flex;flex-wrap:wrap;align-items:center;justify-content:space-between;gap:10px;padding:11px 16px;background:#223e50;color:#edf5fa;font-size:13px;line-height:1.5;font-weight:600\"><span>Codice<\/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\">Copia il codice<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Copiato<\/span><span data-wh-copy-fallback hidden>Codice evidenziato \u2013 copiare<\/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\">Come in tutti gli esempi, vale quanto segue: <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> solo per un indirizzo di documentazione. In pratica, il resolver registrato deve conoscere in modo affidabile i nomi interni, essere raggiungibile dalla rete NGINX ed essere considerato affidabile. Prima di procedere, \u00e8 inoltre necessario verificare l'effettiva funzionalit\u00e0 del pacchetto installato, anzich\u00e9 ricavare la configurazione esclusivamente da un esempio attuale. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Un servizio accessibile esclusivamente tramite IPv4 pu\u00f2 giustificare una limitazione mirata: <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> Impedisce le richieste AAAA e la selezione di un indirizzo IPv6 per questo contesto di risoluzione. Si tratta tuttavia di una scelta relativa all'architettura di rete. Se il dual stack funziona correttamente, l'IPv6 non dovrebbe essere disattivato solo per abitudine; per impostazione predefinita, NGINX risolve entrambe le famiglie di indirizzi IP. <\/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\">Verificare accuratamente la configurazione e implementarla<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Prima di apportare una modifica, verifica innanzitutto in quali punti si applicano effettivamente le direttive del resolver. A tal fine, cerca la configurazione attiva, compresi i file inclusi, e verifica se il resolver \u00e8 attivo per l\u2019intero <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>-contesto, destinato solo a un host virtuale o semplicemente a un singolo percorso. Un ambito troppo ristretto pu\u00f2 impedire a un altro percorso proxy variabile di trovare un resolver; un ambito troppo ampio, invece, rende pi\u00f9 difficile l'assegnazione successiva delle modifiche. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Dopo ogni modifica segue il <strong style=\"font-weight:700;color:inherit\">Controllo della sintassi<\/strong>. Legge la configurazione e tenta anche di aprire i file a cui si fa riferimento. In questo modo \u00e8 possibile individuare errori di scrittura, direttive non valide e problemi nei file di inclusione prima di un ricaricamento. Tuttavia, il controllo non garantisce che il server DNS specificato sia raggiungibile, che riconosca il nome previsto o che il backend associato a un indirizzo risolto accetti le connessioni. <\/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>Codice<\/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\">Copia il codice<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Copiato<\/span><span data-wh-copy-fallback hidden>Codice evidenziato \u2013 copiare<\/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\">Esegui il ricaricamento solo dopo aver verificato che tutto funzioni correttamente. <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> fa s\u00ec che NGINX avvii nuovi worker con la nuova configurazione e chiuda in modo controllato quelli vecchi. A seconda del pacchetto installato e del sistema operativo, potrebbe essere invece il gestore dei servizi previsto in quel contesto ad avviare il ricaricamento. A tal fine, utilizzare la procedura operativa documentata dell\u2019installazione, anzich\u00e9 utilizzare comandi provenienti da un ambiente esterno. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Pianifica quindi un test tecnico nella finestra di modifica prevista. Confronta il TTL DNS previsto con il momento a partire dal quale dovr\u00e0 essere utilizzato un nuovo indirizzo backend e verifica la raggiungibilit\u00e0 del servizio tramite la famiglia di indirizzi IP effettivamente consentita. Documenta inoltre l\u2019indirizzo del resolver, l\u2019ambito selezionato e un eventuale <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. In questo modo, in caso di malfunzionamento, \u00e8 possibile distinguere se la causa sia da ricercarsi nel DNS, nel routing o nell\u2019applicazione. <\/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\">Individuare sistematicamente i guasti tipici del resolver<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Inizia la ricerca degli errori nell'espressione di destinazione in <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">proxy_pass<\/code>. Se contiene una variabile, NGINX deve risolvere il nome host in essa contenuto in fase di esecuzione, a meno che questo non appartenga a un gruppo upstream definito. Il messaggio <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> sottolinea quindi innanzitutto la mancanza di un elemento o la sua invisibilit\u00e0 nel contesto operativo <strong style=\"font-weight:700;color:inherit\">Configurazione del resolver<\/strong> . Aggiungi un nameserver affidabile nel contesto appropriato, invece di sostituire frettolosamente il nome host con un indirizzo IP fisso. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Se \u00e8 configurato un resolver, verifica quindi il suo indirizzo, il percorso di rete e la competenza per la zona utilizzata. Un resolver pubblico non pu\u00f2 conoscere i nomi interni; un resolver non raggiungibile, invece, genera timeout di risoluzione. Verifica inoltre se la direttiva viene sovrascritta da un\u2019impostazione pi\u00f9 specifica. NGINX utilizza solo i server dei nomi espressamente specificati, non applica automaticamente tutte le impostazioni da <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\">Se, dopo una modifica del DNS, rimane attivo un vecchio indirizzo di destinazione, controlla il TTL della risposta e se \u00e8 impostato un <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>. Un override di lunga durata sostituisce il TTL della risposta DNS e pu\u00f2 ritardare di conseguenza l\u2019applicazione di una modifica. La correzione consentita non \u00e8 una durata forfettaria il pi\u00f9 breve possibile, bens\u00ec un valore adeguato alla finestra di modifica e alla capacit\u00e0 dell\u2019infrastruttura DNS; spesso l\u2019omissione di <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> la soluzione pi\u00f9 pulita. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">In caso di problemi di connessione dopo una risoluzione riuscita, disconnetti il DNS dalla connessione backend. Verifica se sono presenti risposte A e AAAA e se la destinazione \u00e8 effettivamente instradata e raggiungibile tramite IPv6. <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">ipv6=off<\/code> \u00c8 adatto solo a un caso di architettura in cui sia dimostrabile che si utilizza esclusivamente IPv4. Un timeout DNS riguarda la risoluzione dei nomi; un errore di connessione a un indirizzo IP gi\u00e0 noto, invece, \u00e8 riconducibile al routing, al firewall, alla porta o all\u2019applicazione. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Per gli upstream dinamici occorre inoltre specificare la versione, la zona di memoria condivisa e <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> essere compatibili. Il supporto open source documentato a tal fine \u00e8 valido a partire dalla versione NGINX 1.27.3; le installazioni precedenti non devono essere considerate equivalenti. <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> Inoltre, le statistiche dei resolver basate su API non costituiscono una soluzione di monitoraggio generica per NGINX Open Source, poich\u00e9 le funzionalit\u00e0 citate riguardano l'ambito commerciale. <\/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\">Scegliere la strategia del resolver per il funzionamento<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">La strategia giusta non parte da un valore di cache predefinito, ma dal controllo sul DNS e dalla frequenza delle modifiche. Se il tuo team \u00e8 in grado di gestire la zona autorevole e se i relativi TTL rispecchiano in modo realistico la finestra di deployment, allora una <strong style=\"font-weight:700;color:inherit\">Risoluzione controllata tramite TTL<\/strong> senza <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> di solito il punto di partenza pi\u00f9 comprensibile. Il DNS rimane quindi la fonte di riferimento per determinare per quanto tempo viene utilizzata una risposta. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Un elemento inserito intenzionalmente <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> \u00c8 una soluzione da prendere in considerazione se non puoi modificare il TTL e riesci a giustificare operativamente una durata della cache diversa. Tieni presente quale livello di inattivit\u00e0 \u00e8 accettabile: un valore pi\u00f9 lungo riduce il numero di possibili richieste DNS, ma dopo un trasferimento potrebbe puntare a un indirizzo non pi\u00f9 valido. Non costituisce n\u00e9 un limite massimo per il TTL DNS n\u00e9 un regolatore generale delle prestazioni. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Scegli quindi il modello NGINX in base alla struttura di routing. Una variabile <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> \u00c8 indicato quando la destinazione viene determinata in fase di esecuzione per ogni richiesta o configurazione; a tal fine \u00e8 necessario un resolver nell\u2019ambito appropriato. Per un gruppo di backend denominato con modifiche di indirizzo basate sul DNS, \u00e8 necessario un upstream con <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> e <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> ovviamente, a condizione che NGINX Open Source 1.27.3 o una versione pi\u00f9 recente sia effettivamente disponibile. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Solo dopo potrai decidere <strong style=\"font-weight:700;color:inherit\">Timeout e famiglie di indirizzi IP<\/strong>. Il timeout del resolver deve essere in linea con i timeout del client e dell\u2019upstream, in modo che l\u2019assenza di una risposta DNS non causi ritardi sproporzionati. IPv4 o IPv6 vanno abilitati solo in base all\u2019architettura di rete. Utilizza esclusivamente resolver sicuri, in grado di rispondere in modo affidabile alle zone interne. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">La risoluzione DNS e l\u2019upstream keepalive svolgono compiti diversi. Il resolver determina quale indirizzo backend NGINX pu\u00f2 utilizzare; il keepalive mantiene attive le connessioni backend gi\u00e0 stabilite ma inattive, in vista di un loro riutilizzo. Una modifica al riutilizzo delle connessioni non sostituisce quindi n\u00e9 la pianificazione del TTL n\u00e9 il controllo del resolver. Per il dimensionamento di questo livello di connessione, l\u2019articolo su <a href=\"https:\/\/webhosting.de\/it\/configurazione-ottimale-del-keepalive-upstream-di-nginx-proxy-inverso-rete\/\">Keepalive upstream di NGINX<\/a> la strategia del resolver.<\/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\">Fonti e stato dell'arte<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Stato della ricerca: <time datetime=\"2026-09-22\">2026-09-22<\/time><\/p><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Aggiornato al: 22 settembre 2026. Gli esempi di upstream dinamici con resolver nel blocco upstream e server \u2026 resolve si riferiscono, in NGINX Open Source, al supporto documentato a partire dalla versione 1.27.3; per i pacchetti di distribuzione sono inoltre determinanti la documentazione relativa alla compilazione e quella del produttore.<\/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>Ecco come configurare il resolver NGINX per i backend dinamici: TTL DNS, valid, resolver_timeout, destinazioni proxy_pass variabili e upstream dinamici chiaramente distinti l'uno dall'altro.<\/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":"Configurare in modo ottimale la cache dei file aperti di NGINX: ecco come ottenere maggiori prestazioni dal tuo server","excerpt":"La cache di NGINX diventa notevolmente pi\u00f9 veloce quando imposto in modo mirato la cache dei file aperti: questa mantiene in memoria i metadati dei file e gli handle, evitando costosi accessi al file system. Impostando valori adeguati per max, inactive, valid e min_uses, ottimizzo la distribuzione dei contenuti statici per ottenere tempi di risposta rapidi e un carico I\/O ridotto. Punti chiave Cache dei metadati: memorizza esistenza, dimensione, date e handle anzich\u00e9 i contenuti Dimensionamento: equilibrio tra consumo di RAM, percentuale di hit e tasso di modifica Contesti: ideale per immagini\/CSS\/JS; evitare percorsi dinamici Convalida: garantire l\u2019aggiornamento con open_file_cache_valid Misurazione: verificare gli effetti su latenze, I\/O e tasso di errore Cosa memorizza realmente la cache dei file aperti Con la cache dei file aperti non memorizzo i contenuti dei file, ma informazioni strutturate: se un file esiste, quanto \u00e8 grande, quando \u00e8 stato modificato e quale descrittore \u00e8 gi\u00e0 aperto. Queste informazioni sono disponibili in memoria e accorciano il percorso verso la risposta successiva. Ogni richiesta al disco evitata riduce il carico di I\/O e risparmia tempo di CPU, il che conta soprattutto in presenza di molti file di piccole dimensioni. Secondo la documentazione di NGINX, la funzione comprende descrittori aperti, informazioni sulle directory ed errori di ricerca. Ci\u00f2 accelera le scansioni delle directory e i percorsi di accesso, che altrimenti dovrebbero ricorrere nuovamente al disco ad ogni richiesta. Utilizzo consapevolmente questo meccanismo per le directory soggette ad accessi frequenti, come le librerie multimediali e le risorse di build. L\u2019effetto \u00e8 particolarmente evidente nei progetti con molte risorse, in cui il filesystem diventerebbe altrimenti un collo di bottiglia. La cache riduce sensibilmente le chiamate di sistema come stat(), open() e readdir(). Allo stesso tempo, il controllo rimane altamente granulare, poich\u00e9 definisco separatamente la portata e la validit\u00e0 delle voci. In questo modo mantengo i dati aggiornati senza perdere il vantaggio della memorizzazione nella cache. Quando conviene utilizzare la cache dei file aperti? Attivo la cache in modo mirato per le distribuzioni statiche: immagini, CSS, JavaScript, font e download. Nelle aree dinamiche come le pagine di login, i carrelli o i percorsi personalizzati la evito, poich\u00e9 l\u00ec valgono regole diverse. WordPress e i frontend headless ne traggono grandi vantaggi, poich\u00e9 temi, plugin e B"},"I2":{"id":"I2","post_id":21613,"url":"https:\/\/webhosting.de\/nginx-upstream-keepalive-optimal-konfigurieren-reverse-proxy-netzwerk\/","title":"Configurare in modo ottimale il keepalive upstream di NGINX per ottenere le massime prestazioni come proxy inverso","excerpt":"Configuro il Keepalive upstream di NGINX in modo che il reverse proxy stabilisca un numero minore di connessioni, garantisca latenze inferiori e gestisca in modo affidabile i picchi di carico. A tal fine, regolo in modo mirato la dimensione del pool, i timeout e le intestazioni, affinch\u00e9 le connessioni vengano riutilizzate e il percorso dei dati rimanga snello. Punti chiave: imporre HTTP\/1.1 e ripulire l\u2019header Connection; dimensionare correttamente il keepalive per ogni worker; adattare i timeout ai valori del backend; limitare e riciclare le richieste\/connessione e riciclarle Monitoraggio della frequenza di connessione e della latenza Perch\u00e9 il keepalive upstream riduce drasticamente il carico delle connessioni Senza il riutilizzo, NGINX apre una nuova connessione al backend per ogni richiesta, il che comporta handshake extra, pi\u00f9 cicli di CPU e risorse aggiuntive del kernel; ed \u00e8 proprio qui che interviene il keepalive. Faccio in modo che NGINX memorizzi temporaneamente i socket gi\u00e0 stabiliti e attualmente inattivi e li riutilizzi per le richieste successive, riducendo in modo misurabile i tempi di connessione. Ci\u00f2 abbassa la frequenza di connessione al secondo, riduce i picchi di backlog e rallenta i cambi di contesto nel sistema operativo. Soprattutto con TLS verso il backend, risparmio tempo in modo significativo grazie alle sessioni riutilizzate. In questo modo, la catena di risposte rimane affidabile e reattiva anche in caso di elevata larghezza di banda. Principio di base e la direttiva keepalive nell\u2019upstream La direttiva keepalive nel blocco upstream limita il numero di connessioni backend inattive memorizzate temporaneamente per ogni worker. Questo limite non \u00e8 globale, ma si applica rigorosamente per ogni processo worker, motivo per cui tengo sempre sotto controllo il numero di worker. Quando il pool \u00e8 pieno, NGINX chiude per prima la connessione rimasta inattiva pi\u00f9 a lungo, in modo da fare spazio a nuovi socket. Per il riutilizzo, il lato proxy richiede HTTP\/1.1 e un\u2019intestazione Connection neutralizzata. Senza questi prerequisiti, il pool rimane vuoto, anche se imposto \u201ekeepalive\u201c nell\u2019upstream, cosa che inizialmente sorprende molti amministratori. upstream backend_pool { server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080; keepalive 32; # connessioni inattive per worker keepalive_requests 1000; # riciclo dopo N richieste keepalive_timeout 60s; # durata inattiva } 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":"Come utilizzare correttamente la funzione di svuotamento della cache di NGINX: guida pratica per una invalidazione rapida e sicura della cache","excerpt":"Ti mostrer\u00f2 come svuotare in modo mirato la cache di nginx, senza che i visitatori ricevano risposte obsolete e senza correre il rischio di vulnerabilit\u00e0 di sicurezza. Grazie a chiare strategie di purge, cache key ben definite e un\u2019automazione sicura, creer\u00f2 un flusso di lavoro che mantenga WordPress e PHP-FPM veloci e aggiornati. Punti chiave: pianificare correttamente le chiavi della cache: host, URI, header e cookie necessari; combinare le strategie di purge: scadenze, chiavi mirate, purge controllato; dare sempre priorit\u00e0 alla sicurezza: IP interni, autenticazione, registrazione, nessun endpoint aperto; utilizzare l\u2019automazione: hook di WordPress e trigger di distribuzione per le operazioni di purge Attivare il monitoraggio: X-FastCGI-Cache, log, dimensioni della cache Comprendere il caching di NGINX: base per un\u2019operazione di purge efficace Prima di eseguire il purge, capisco come NGINX memorizza i dati. NGINX gestisce i backend HTTP tramite cache proxy e le risposte PHP dinamiche tramite cache FastCGI; inoltre, esistono varianti come uWSGI o SCGI per configurazioni particolari, che qui accenno solo di sfuggita. Negli stack tipici di WordPress o PHP, \u00e8 soprattutto la cache FastCGI a garantire il massimo rendimento, poich\u00e9 scrive le pagine HTML gi\u00e0 pronte da PHP-FPM nel filesystem e le fornisce direttamente alla successiva richiesta. Ci\u00f2 alleggerisce il carico sulla CPU e sul database e riduce i tempi di risposta, purch\u00e9 i contenuti siano aggiornati. \u00c8 proprio a questo punto che un\u2019operazione di purging ben pianificata determina se gli utenti riceveranno risposte aggiornate o visualizzeranno pagine obsolete. Chiavi di cache: la chiave per una pulizia mirata Ogni risultato si basa su una chiave di cache, che solitamente \u00e8 composta da host, URI della richiesta, header rilevanti e parti minime dei cookie. Progetto la chiave in modo che tenga conto solo delle differenze che modificano realmente l\u2019output HTML, altrimenti frammento inutilmente la cache. Tratto con parsimonia gli header Vary, la lingua o le classi di dispositivi e verifico con richieste di test se la variazione desiderata \u00e8 davvero necessaria. Una chiave coerente consente in seguito di rimuovere esattamente gli oggetti interessati da una modifica, anzich\u00e9 cancellare intere directory. Le chiavi pulite risparmiano operazioni di I\/O, mantengono alta la percentuale di hit e semplificano enormemente le richieste di purge. Progettazione delle chiavi di cache nella pratica: normalizzazione e riduzione Nella pratica, normalizzo la"}},"_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":"Configurare correttamente la cache del resolver di NGINX","slug":"configurare-correttamente-la-cache-del-resolver-di-nginx","excerpt":"Ecco come configurare il resolver NGINX per i backend dinamici: TTL DNS, valid, resolver_timeout, destinazioni proxy_pass variabili e upstream dinamici chiaramente distinti l'uno dall'altro.","status":"draft","featured_media":21661},"verify":{"content_md5":"00d4ee046c92de068b9c7a606af6b568","title":"Configurare correttamente la cache del resolver di NGINX","slug":"configurare-correttamente-la-cache-del-resolver-di-nginx","excerpt":"Ecco come configurare il resolver NGINX per i backend dinamici: TTL DNS, valid, resolver_timeout, destinazioni proxy_pass variabili e upstream dinamici chiaramente distinti l'uno dall'altro.","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":"Modulo ngx_http_core_module"},"S2":{"id":"S2","url":"https:\/\/nginx.org\/en\/docs\/http\/ngx_http_upstream_module.html","title":"Modulo ngx_http_upstream_module"},"S3":{"id":"S3","url":"https:\/\/nginx.org\/en\/docs\/http\/ngx_http_proxy_module.html?utm_source=openai","title":"Modulo ngx_http_proxy_module"},"S4":{"id":"S4","url":"https:\/\/nginx.org\/en\/docs\/switches.html?utm_source=openai","title":"Parametri della riga di comando"}},"_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":"Configurare correttamente la cache del resolver di NGINX","slug":"configurare-correttamente-la-cache-del-resolver-di-nginx","excerpt":"Ecco come configurare il resolver NGINX per i backend dinamici: TTL DNS, valid, resolver_timeout, destinazioni proxy_pass variabili e upstream dinamici chiaramente distinti l'uno dall'altro.","status":"draft","featured_media":0},"expected":{"content_md5":"00d4ee046c92de068b9c7a606af6b568","title":"Configurare correttamente la cache del resolver di NGINX","slug":"configurare-correttamente-la-cache-del-resolver-di-nginx","excerpt":"Ecco come configurare il resolver NGINX per i backend dinamici: TTL DNS, valid, resolver_timeout, destinazioni proxy_pass variabili e upstream dinamici chiaramente distinti l'uno dall'altro.","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":"Configurare correttamente la cache del resolver di NGINX","slug":"configurare-correttamente-la-cache-del-resolver-di-nginx","excerpt":"Ecco come configurare il resolver NGINX per i backend dinamici: TTL DNS, valid, resolver_timeout, destinazioni proxy_pass variabili e upstream dinamici chiaramente distinti l'uno dall'altro.","seo":{"title":"Configurare correttamente la cache del resolver di NGINX","description":"Configurare correttamente il resolver NGINX: pianificare in modo chiaro i parametri DNS-TTL, valid, resolver_timeout e gli upstream dinamici per i proxy inversi.","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\/it\/wp-json\/wp\/v2\/posts\/21658","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=21658"}],"version-history":[{"count":3,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21658\/revisions"}],"predecessor-version":[{"id":21664,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21658\/revisions\/21664"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/21661"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=21658"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=21658"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=21658"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}