{"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":"configurar-corretamente-a-cache-do-resolver-do-nginx","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/nginx-resolver-cache-richtig-konfigurieren\/","title":{"rendered":"Configurar corretamente a cache do resolver do 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\">O <strong style=\"font-weight:700;color:inherit\">Resolver NGINX<\/strong> respostas DNS armazenadas em cache para nomes de back-end, mas n\u00e3o respostas HTTP. Para uma configura\u00e7\u00e3o robusta de proxy inverso, deve utilizar um servidor de nomes interno fi\u00e1vel, deixar que os TTLs de DNS bem geridos surtam efeito na maioria dos casos e definir <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> apenas como uma substitui\u00e7\u00e3o deliberada. O resolvedor torna-se particularmente importante no caso de destinos vari\u00e1veis em <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> bem como no caso de upstreams din\u00e2micos, cujas funcionalidades dependem da vers\u00e3o do NGINX instalada.   <\/p>\n<nav class=\"wh-toc\" aria-label=\"Conte\u00fado deste artigo\" 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\">Ir diretamente para a sec\u00e7\u00e3o<\/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\">Compreender o Resolver do NGINX e a cache de 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\">A cache DNS n\u00e3o \u00e9 uma 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 \u00e9 que o NGINX tem de resolver novamente os nomes<\/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\">Definir o TTL e o valid de forma deliberada<\/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\">Resolver corretamente as vari\u00e1veis em 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\">Configurar upstreams din\u00e2micos com o `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\">Verificar cuidadosamente a configura\u00e7\u00e3o e implement\u00e1-la<\/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\">Identificar sistematicamente os erros t\u00edpicos do 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\">Selecionar a estrat\u00e9gia do resolver para a opera\u00e7\u00e3o<\/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\">Compreender o Resolver do NGINX e a cache de DNS<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Um proxy reverso necessita, inicialmente, de um endere\u00e7o IP para um backend com nome de anfitri\u00e3o. O <strong style=\"font-weight:700;color:inherit\">Resolver NGINX<\/strong> para tal, consulta os servidores de nomes definidos na configura\u00e7\u00e3o. A resposta DNS recebida \u00e9 armazenada em cache, para que o NGINX n\u00e3o tenha de resolver novamente o nome para cada pedido durante o seu per\u00edodo de validade. Este cache diz respeito exclusivamente \u00e0 resolu\u00e7\u00e3o do nome para o sistema de destino. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">A diretiva <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> cont\u00e9m um ou mais endere\u00e7os de resolutor ou identificadores de resolutor suportados. Se n\u00e3o for especificada uma porta diferente, o NGINX utiliza a porta 53; caso existam v\u00e1rios servidores registados, as consultas s\u00e3o processadas, de acordo com a documenta\u00e7\u00e3o, atrav\u00e9s do m\u00e9todo Round Robin. Para uma configura\u00e7\u00e3o de inicializa\u00e7\u00e3o robusta, os endere\u00e7os IP fixos s\u00e3o frequentemente prefer\u00edveis, uma vez que a sua resolu\u00e7\u00e3o n\u00e3o depende, por sua vez, do DNS. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Por predefini\u00e7\u00e3o, o NGINX tem em conta os endere\u00e7os IPv4 e IPv6 de um nome. Isto \u00e9 adequado quando a rede transmite de forma fi\u00e1vel ambas as fam\u00edlias de protocolos at\u00e9 ao backend. Par\u00e2metros como <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> ou <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> excluem especificamente uma fam\u00edlia, mas n\u00e3o constituem uma otimiza\u00e7\u00e3o geral da cache. A sua necessidade depende da acessibilidade do backend espec\u00edfico e n\u00e3o da mera exist\u00eancia de um registo AAAA. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">O Resolver n\u00e3o \u00e9 nem um servidor DNS recursivo completo nem uma transfer\u00eancia autom\u00e1tica de todas as defini\u00e7\u00f5es a partir de <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>. O NGINX utiliza os servidores de nomes explicitamente especificados. No caso de zonas internas e nomes de back-end em produ\u00e7\u00e3o, estes devem ser resolvidos por um resolvedor fi\u00e1vel e devidamente protegido, localizado na pr\u00f3pria rede. Desta forma, a responsabilidade pelos nomes privados e a prote\u00e7\u00e3o contra respostas DNS manipuladas permanecem numa infraestrutura control\u00e1vel. <\/p>\n<\/section><section class=\"wh-section\" aria-labelledby=\"cache-arten-abgrenzen\" style=\"display:block;margin:0 0 36px;min-width:0\"><h2 id=\"cache-arten-abgrenzen\" style=\"margin:38px 0 18px;color:#172f41;font-size:clamp(24px,1.25rem + 1vw,30px);font-weight:700;line-height:1.3;scroll-margin-top:115px\">A cache DNS n\u00e3o \u00e9 uma cache HTTP<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">A cache de respostas DNS do resolvedor armazena as correspond\u00eancias entre nomes e respostas DNS, como endere\u00e7os A ou AAAA. O seu objetivo \u00e9 permitir aceder novamente a um backend sem ter de repetir cada resolu\u00e7\u00e3o de nome. Se o endere\u00e7o IP de um servidor de destino mudar, \u00e9 por isso que a validade da resposta DNS \u00e9 relevante \u2013 e n\u00e3o o conte\u00fado de uma resposta HTTP enviada anteriormente. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Separadamente, guarda <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> Respostas HTTP de um servidor a montante. A chave inclui, dependendo da configura\u00e7\u00e3o, por exemplo, o URI, o host ou o cabe\u00e7alho; uma correspond\u00eancia fornece ao cliente uma resposta j\u00e1 armazenada. Os problemas que podem surgir aqui incluem p\u00e1ginas desatualizadas, variantes incorretas ou acertos inesperados na cache. Esta fun\u00e7\u00e3o n\u00e3o determina qual o endere\u00e7o IP que o NGINX utiliza ao estabelecer uma nova liga\u00e7\u00e3o com o backend. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">A cache de ficheiros abertos constitui um terceiro n\u00edvel: armazena informa\u00e7\u00f5es sobre ficheiros e descritores abertos para acessos ao sistema de ficheiros local, mas n\u00e3o armazena respostas DNS nem conte\u00fados HTTP. Quem pretender aprofundar esta distin\u00e7\u00e3o no contexto da entrega est\u00e1tica, poder\u00e1 encontr\u00e1-la no artigo sobre a <a href=\"https:\/\/webhosting.de\/pt\/janela-de-otimizacao-da-cache-do-nginx\/\">Configura\u00e7\u00e3o do Open File Cache do NGINX<\/a>. No entanto, n\u00e3o fornece qualquer base para a escolha do TTL do resolver.<\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Por conseguinte, esvaziar, limpar ou atualizar uma cache HTTP n\u00e3o acelera uma altera\u00e7\u00e3o no DNS. Por outro lado, uma nova resolu\u00e7\u00e3o de DNS n\u00e3o corrige uma resposta HTTP armazenada incorretamente na cache. No caso de um proxy reverso, o <strong style=\"font-weight:700;color:inherit\">Cache de DNS<\/strong> basear-se, al\u00e9m disso, em nomes e endere\u00e7os: n\u00e3o verifica o estado de funcionamento de uma aplica\u00e7\u00e3o nem substitui o equil\u00edbrio de carga, as tentativas repetidas ou o planeamento correto dos tempos de espera para o upstream.  <\/p>\n<\/section><section class=\"wh-section\" aria-labelledby=\"laufzeitauflosung-und-versionen\" style=\"display:block;margin:0 0 36px;min-width:0\"><h2 id=\"laufzeitauflosung-und-versionen\" style=\"margin:38px 0 18px;color:#172f41;font-size:clamp(24px,1.25rem + 1vw,30px);font-weight:700;line-height:1.3;scroll-margin-top:115px\">Quando \u00e9 que o NGINX tem de resolver novamente os nomes<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Um nome de anfitri\u00e3o pode j\u00e1 ser conhecido pelo NGINX no momento em que a configura\u00e7\u00e3o \u00e9 lida. O caso \u00e9 diferente quando se trata de um destino vari\u00e1vel, como, por exemplo, <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>. O NGINX procura primeiro o nome resultante nos grupos upstream definidos. Se n\u00e3o encontrar l\u00e1 nenhum nome adequado, necessita, em tempo de execu\u00e7\u00e3o, de um resolvedor configurado para determinar o endere\u00e7o de destino. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">A notifica\u00e7\u00e3o <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> Neste contexto, n\u00e3o indica a aus\u00eancia de uma cache HTTP. Significa que o NGINX n\u00e3o conhece nenhum servidor DNS para a resolu\u00e7\u00e3o necess\u00e1ria em tempo de execu\u00e7\u00e3o. <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> pode, neste contexto <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> ou <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> est\u00e1. Uma entrada central no <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>O bloco -Block \u00e9 adequado quando v\u00e1rios anfitri\u00f5es virtuais utilizam o mesmo resolvedor; um \u00e2mbito mais restrito s\u00f3 se justifica quando os requisitos s\u00e3o efetivamente diferentes.  <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">\u00c9 necess\u00e1rio distinguir esta resolu\u00e7\u00e3o de tempo de execu\u00e7\u00e3o, dispon\u00edvel h\u00e1 muito tempo, da atualiza\u00e7\u00e3o din\u00e2mica de um grupo upstream cl\u00e1ssico. A configura\u00e7\u00e3o do resolutor diretamente no <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>-Bloco, bem como <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> De acordo com a documenta\u00e7\u00e3o do NGINX, est\u00e3o dispon\u00edveis em c\u00f3digo aberto a partir da vers\u00e3o 1.27.3. As instala\u00e7\u00f5es de c\u00f3digo aberto mais antigas n\u00e3o devem ser consideradas como suportando este padr\u00e3o automaticamente; historicamente, algumas das funcionalidades correspondentes estavam reservadas ao NGINX Plus. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Antes de planear fluxos din\u00e2micos a montante, verifica a sa\u00edda instalada e as informa\u00e7\u00f5es de compila\u00e7\u00e3o. O comando seguinte apresenta a vers\u00e3o do NGINX, a vers\u00e3o do compilador e os par\u00e2metros do `configure` utilizados na compila\u00e7\u00e3o. <\/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>C\u00f3digo<\/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\">Copiar c\u00f3digo<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Copiado<\/span><span data-wh-copy-fallback hidden>C\u00f3digo destacado \u2013 por favor, copie<\/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\">Compare o estado apresentado em implementa\u00e7\u00f5es cr\u00edticas com a documenta\u00e7\u00e3o do pacote concretamente utilizado e do seu fornecedor. O que \u00e9 determinante \u00e9 se essa instala\u00e7\u00e3o documenta e disponibiliza a funcionalidade necess\u00e1ria. S\u00f3 depois disso \u00e9 que um <strong style=\"font-weight:700;color:inherit\">upstream din\u00e2mico<\/strong> uma escolha arquitet\u00f3nica robusta. <\/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\">Definir o TTL e o valid de forma deliberada<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Sem qualquer configura\u00e7\u00e3o adicional, a cache do resolver do NGINX segue a <strong style=\"font-weight:700;color:inherit\">DNS-TTL<\/strong> na resposta do servidor de nomes consultado. Se o operador de DNS autorit\u00e1rio alterar o endere\u00e7o IP de um backend, o NGINX utiliza a resposta anterior at\u00e9 ao termo do seu TTL. S\u00f3 quando for necess\u00e1ria uma nova resolu\u00e7\u00e3o de nomes \u00e9 que o NGINX volta a consultar o resolvedor. Desta forma, o per\u00edodo de validade continua a ser control\u00e1vel no local onde os dados dos nomes s\u00e3o geridos. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">O par\u00e2metro <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> substitui totalmente este TTL pelo per\u00edodo configurado. Assim, n\u00e3o s\u00f3 limita o TTL do DNS a um valor m\u00e1ximo, como tamb\u00e9m n\u00e3o define uma atualiza\u00e7\u00e3o peri\u00f3dica para al\u00e9m do TTL. Um valor de <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> pode encurtar um TTL de DNS mais longo, mas tamb\u00e9m prolongar um TTL deliberadamente curto. Isso tem de se enquadrar no planeamento da migra\u00e7\u00e3o e da implementa\u00e7\u00e3o do 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=\"Ilustra\u00e7\u00e3o do efeito do DNS-TTL e do par\u00e2metro \u00abvalid\u00bb na dura\u00e7\u00e3o da cache no resolvedor do 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\">O TTL do DNS e uma substitui\u00e7\u00e3o \u00abvalid\u00bb determinam, de formas diferentes, durante quanto tempo as respostas s\u00e3o utilizadas.<\/figcaption><\/figure><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Se a zona for mantida de forma fi\u00e1vel, uma configura\u00e7\u00e3o sem substitui\u00e7\u00e3o constitui o ponto de partida l\u00f3gico. O endere\u00e7o apresentado no exemplo foi escolhido de acordo com as redes descritas na documenta\u00e7\u00e3o e n\u00e3o deve ser utilizado como resolutor em produ\u00e7\u00e3o. Em vez disso, introduza o endere\u00e7o de um resolutor DNS acess\u00edvel e fi\u00e1vel da sua pr\u00f3pria rede.<\/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>C\u00f3digo<\/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\">Copiar c\u00f3digo<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Copiado<\/span><span data-wh-copy-fallback hidden>C\u00f3digo destacado \u2013 por favor, copie<\/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\">Uma substitui\u00e7\u00e3o pode ser \u00fatil quando o TTL do DNS n\u00e3o pode ser alterado e existe uma diretriz operacional documentada. Nesse caso, o desvio torna explicitamente vis\u00edvel durante quanto tempo o NGINX mant\u00e9m as respostas. N\u00e3o se trata de uma otimiza\u00e7\u00e3o geral de desempenho: tempos mais curtos podem gerar mais consultas DNS, enquanto tempos mais longos podem atrasar a transi\u00e7\u00e3o para novos endere\u00e7os de 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>C\u00f3digo<\/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\">Copiar c\u00f3digo<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Copiado<\/span><span data-wh-copy-fallback hidden>C\u00f3digo destacado \u2013 por favor, copie<\/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=\"Decis\u00f5es iniciais relativas ao TTL do DNS e \u00e0 valida\u00e7\u00e3o\" 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\">Decis\u00f5es iniciais relativas ao TTL do DNS e \u00e0 valida\u00e7\u00e3o<\/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\">Situa\u00e7\u00e3o operacional<\/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\">Decis\u00e3o inicial<\/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\">Risco<\/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 com TTLs atualizados<\/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\">omitir \u00abvalid\u00bb<\/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\">O NGINX segue o tempo de cache definido pelo 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\">O TTL tem de corresponder \u00e0 janela de altera\u00e7\u00e3o.<\/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 n\u00e3o control\u00e1vel, substitui\u00e7\u00e3o rara<\/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\">documentar de forma consciente e v\u00e1lida<\/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\">O per\u00edodo de reten\u00e7\u00e3o passa a ser program\u00e1vel para o 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\">Os endere\u00e7os de destino antigos podem ser utilizados por mais tempo do que o previsto pelo 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\">Manuten\u00e7\u00f5es frequentes ou trocas de contentores<\/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\">Dar prefer\u00eancia a TTL curtos no DNS autoritativo<\/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\">O DNS continua a ser a fonte de refer\u00eancia para as \u00faltimas not\u00edcias.<\/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\">Um maior n\u00famero de consultas pode sobrecarregar a infraestrutura do 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\">Detec\u00e7\u00e3o de servi\u00e7os baseada em 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\">Verificar o upstream din\u00e2mico com o 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\">Os membros do Upstream podem acompanhar as altera\u00e7\u00f5es no 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\">A vers\u00e3o e a arquitetura t\u00eam de ser compat\u00edveis com a fun\u00e7\u00e3o.<\/td><\/tr><\/tbody><\/table><\/div><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">A decis\u00e3o n\u00e3o come\u00e7a, portanto, com uma indica\u00e7\u00e3o fixa em segundos, mas sim com a quest\u00e3o de saber quem controla os dados do DNS e com que rapidez uma mudan\u00e7a no backend deve entrar em vigor. <strong style=\"font-weight:700;color:inherit\">v\u00e1lido<\/strong> trata-se de uma interven\u00e7\u00e3o deliberada nesta regra. N\u00e3o se adequa como uma solu\u00e7\u00e3o gen\u00e9rica para tornar o proxy reverso mais r\u00e1pido ou para encobrir problemas de 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\">Resolver corretamente as vari\u00e1veis em proxy_pass<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Cont\u00e9m <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> uma vari\u00e1vel, o NGINX tem de processar o nome de host resultante em tempo de execu\u00e7\u00e3o. Primeiro, o NGINX procura um grupo upstream adequado; se n\u00e3o o encontrar, necessita de um resolvedor configurado para esse nome. Se este n\u00e3o existir, a mensagem t\u00edpica \u00e9 <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> N\u00e3o se trata de uma refer\u00eancia a uma cache HTTP, mas sim \u00e0 falta de configura\u00e7\u00e3o do DNS para este caminho de execu\u00e7\u00e3o. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">O exemplo seguinte torna a resolu\u00e7\u00e3o em tempo de execu\u00e7\u00e3o deliberadamente vis\u00edvel. O resolutor encontra-se no <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>-contexto e, por isso, aplica-se a v\u00e1rios anfitri\u00f5es virtuais, desde que nenhuma configura\u00e7\u00e3o mais espec\u00edfica o substitua. O endere\u00e7o de documenta\u00e7\u00e3o utilizado deve ser substitu\u00eddo pelo resolvedor interno do respetivo 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>C\u00f3digo<\/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\">Copiar c\u00f3digo<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Copiado<\/span><span data-wh-copy-fallback hidden>C\u00f3digo destacado \u2013 por favor, copie<\/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\">A diretiva <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> n\u00e3o controla a dura\u00e7\u00e3o da cache. Limita o tempo que o NGINX aguarda pela resolu\u00e7\u00e3o de um nome; o valor padr\u00e3o documentado \u00e9 de 30 segundos. A escolha faz parte dos restantes par\u00e2metros de toler\u00e2ncia a erros: um valor demasiado elevado pode atrasar uma solicita\u00e7\u00e3o com falha at\u00e9 \u00e0 resposta de erro; um valor demasiado baixo gera erros de resolu\u00e7\u00e3o evit\u00e1veis quando os resolutores internos est\u00e3o temporariamente lentos. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Para uma localiza\u00e7\u00e3o \u00fanica e claramente delimitada, o Resolver pode, no <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>-Bloco. Se v\u00e1rias localiza\u00e7\u00f5es ou servidores necessitarem da mesma resolu\u00e7\u00e3o, \u00e9 necess\u00e1rio definir um \u00e2mbito comum no <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>- ou <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>- O bloco requer menos manuten\u00e7\u00e3o. O NGINX permite a diretiva nos tr\u00eas contextos; o \u00e2mbito de aplica\u00e7\u00e3o deve refletir a estrutura operacional real, e n\u00e3o apenas resolver uma mensagem de erro isolada a curto prazo. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Mesmo no caso de destinos vari\u00e1veis, o tempo limite do DNS e a liga\u00e7\u00e3o ao backend continuam a ser classes de erros distintas. Uma resolu\u00e7\u00e3o de nome bem-sucedida n\u00e3o prova que a porta de destino esteja acess\u00edvel, nem que a aplica\u00e7\u00e3o esteja a responder. Por outro lado, um tempo limite de upstream mais elevado n\u00e3o resolve o problema de um endere\u00e7o de resolutor inacess\u00edvel. <\/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\">Configurar upstreams din\u00e2micos com o `resolve`<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Para um grupo de back-end espec\u00edfico, um upstream din\u00e2mico pode ser mais f\u00e1cil de compreender do que um valor de destino vari\u00e1vel em cada localiza\u00e7\u00e3o. Este padr\u00e3o separa a defini\u00e7\u00e3o dos membros do back-end do encaminhamento: <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> refere-se ao grupo, enquanto o nome do anfitri\u00e3o no upstream pode ser atualizado atrav\u00e9s do DNS. Isto \u00e9 particularmente adequado quando v\u00e1rias rotas apontam para a mesma aplica\u00e7\u00e3o. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">O par\u00e2metro <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> para um <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>-Esta entrada existe historicamente desde o NGINX 1.5.12. No NGINX de c\u00f3digo aberto, por\u00e9m, de acordo com a documenta\u00e7\u00e3o, s\u00f3 est\u00e1 dispon\u00edvel a partir da vers\u00e3o 1.27.3; anteriormente, esta funcionalidade estava limitada \u00e0 vers\u00e3o comercial. A configura\u00e7\u00e3o do resolvedor diretamente no <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>- O bloco est\u00e1 documentado para o Open Source a partir da vers\u00e3o 1.27.3. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">O <strong style=\"font-weight:700;color:inherit\">Zona de mem\u00f3ria partilhada<\/strong> N\u00e3o se trata de um tempo limite de cache nem de um caminho de dados DNS. Esta funcionalidade disponibiliza, no \u00e2mbito do NGINX, mem\u00f3ria partilhada necess\u00e1ria para as configura\u00e7\u00f5es de upstream que sofrem altera\u00e7\u00f5es din\u00e2micas. Se, durante a resolu\u00e7\u00e3o do DNS, o NGINX detetar outros endere\u00e7os para o nome, o grupo de upstream pode ser ajustado com base neste estado gerido internamente, sem necessidade de reiniciar o sistema. <\/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=\"Representa\u00e7\u00e3o conceptual de um upstream din\u00e2mico do NGINX com um resolvedor DNS separado, estado de mem\u00f3ria partilhada interna e endere\u00e7os de 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\">A zona de mem\u00f3ria partilhada gere o estado do upstream no interior do NGINX; a resolu\u00e7\u00e3o de DNS e as liga\u00e7\u00f5es ao backend seguem caminhos separados.<\/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>C\u00f3digo<\/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\">Copiar c\u00f3digo<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Copiado<\/span><span data-wh-copy-fallback hidden>C\u00f3digo destacado \u2013 por favor, copie<\/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\">Tal como em todos os exemplos, aplica-se <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> apenas para um endere\u00e7o de documenta\u00e7\u00e3o. Na pr\u00e1tica, o resolvedor registado deve conhecer de forma fi\u00e1vel os nomes internos, estar acess\u00edvel a partir da rede NGINX e ser considerado de confian\u00e7a. Al\u00e9m disso, antes da implementa\u00e7\u00e3o, \u00e9 necess\u00e1rio verificar o \u00e2mbito real de funcionalidades do pacote instalado, em vez de basear a configura\u00e7\u00e3o apenas num exemplo atual. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Um servi\u00e7o que s\u00f3 \u00e9 acess\u00edvel atrav\u00e9s de IPv4 pode justificar uma restri\u00e7\u00e3o espec\u00edfica: <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> Impede as consultas AAAA e a sele\u00e7\u00e3o de um endere\u00e7o IPv6 para este contexto de resolu\u00e7\u00e3o. No entanto, trata-se de uma decis\u00e3o relativa \u00e0 arquitetura de rede. Quando o Dual Stack estiver a funcionar corretamente, o IPv6 n\u00e3o deve ser desativado apenas por h\u00e1bito; por predefini\u00e7\u00e3o, o NGINX resolve ambas as fam\u00edlias de 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\">Verificar cuidadosamente a configura\u00e7\u00e3o e implement\u00e1-la<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Antes de efetuar uma altera\u00e7\u00e3o, verifica primeiro em que pontos as diretivas do resolver se aplicam efetivamente. Para tal, procura a configura\u00e7\u00e3o ativa, incluindo os ficheiros incorporados, e verifica se o resolver se aplica a todo 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>-Contexto, destinado apenas a um anfitri\u00e3o virtual ou apenas a um \u00fanico caminho. Um \u00e2mbito demasiado restrito pode fazer com que outro caminho de proxy vari\u00e1vel n\u00e3o encontre um resolvedor; por outro lado, um \u00e2mbito demasiado amplo dificulta a atribui\u00e7\u00e3o posterior de altera\u00e7\u00f5es. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Ap\u00f3s cada ajuste, segue-se o <strong style=\"font-weight:700;color:inherit\">Verifica\u00e7\u00e3o da sintaxe<\/strong>. Ele l\u00ea a configura\u00e7\u00e3o e tenta tamb\u00e9m abrir os ficheiros referenciados. Isto permite detetar erros de escrita, diretivas inv\u00e1lidas e problemas nos ficheiros \u00abinclude\u00bb antes de uma recarga. No entanto, esta verifica\u00e7\u00e3o n\u00e3o comprova que o servidor DNS indicado esteja acess\u00edvel, que reconhe\u00e7a o nome esperado ou que o backend, por tr\u00e1s de um endere\u00e7o resolvido, aceite liga\u00e7\u00f5es. <\/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>C\u00f3digo<\/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\">Copiar c\u00f3digo<\/button><span class=\"wh-copy-status\" aria-live=\"polite\"><\/span><span data-wh-copy-success hidden>Copiado<\/span><span data-wh-copy-fallback hidden>C\u00f3digo destacado \u2013 por favor, copie<\/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\">S\u00f3 execute a recarga ap\u00f3s a verifica\u00e7\u00e3o ter sido bem-sucedida. <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> faz com que o NGINX inicie novos workers com a nova configura\u00e7\u00e3o e encerre os antigos de forma controlada. Dependendo do pacote instalado e do sistema operativo, o gestor de servi\u00e7os previsto para esse ambiente pode, em vez disso, desencadear a recarga. Para tal, utilize o procedimento de opera\u00e7\u00e3o documentado da instala\u00e7\u00e3o, em vez de utilizar comandos provenientes de um ambiente externo. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Em seguida, planeie um teste t\u00e9cnico na janela de altera\u00e7\u00f5es prevista. Compare o TTL do DNS esperado com o momento a partir do qual um novo endere\u00e7o de backend dever\u00e1 ser utilizado e verifique a acessibilidade do servi\u00e7o atrav\u00e9s da fam\u00edlia de IPs efetivamente autorizada. Documente tamb\u00e9m o endere\u00e7o do resolvedor, o \u00e2mbito selecionado e um poss\u00edvel <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. Desta forma, em caso de falha, \u00e9 poss\u00edvel distinguir se a causa est\u00e1 no DNS, no encaminhamento ou na aplica\u00e7\u00e3o. <\/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\">Identificar sistematicamente os erros t\u00edpicos do resolver<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Come\u00e7a a procura de erros na express\u00e3o de destino em <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 contiver uma vari\u00e1vel, o NGINX ter\u00e1 de resolver o nome de host nela contido em tempo de execu\u00e7\u00e3o, desde que este n\u00e3o perten\u00e7a a um grupo upstream definido. A mensagem <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> aponta, por isso, em primeiro lugar, para a aus\u00eancia de um elemento ou para um elemento que n\u00e3o \u00e9 vis\u00edvel no contexto em quest\u00e3o <strong style=\"font-weight:700;color:inherit\">Configura\u00e7\u00e3o do resolutor<\/strong> . Adicione um servidor de nomes fi\u00e1vel no contexto adequado, em vez de substituir precipitadamente o nome do anfitri\u00e3o por um endere\u00e7o IP fixo. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Se estiver configurado um resolvedor, verifica-se, em seguida, o seu endere\u00e7o, o caminho de rede e a compet\u00eancia para a zona utilizada. Um resolver p\u00fablico n\u00e3o pode conhecer nomes internos; por outro lado, um resolver inacess\u00edvel provoca tempos de espera na resolu\u00e7\u00e3o. Verifica tamb\u00e9m se a diretiva est\u00e1 a ser substitu\u00edda por uma configura\u00e7\u00e3o mais espec\u00edfica. O NGINX utiliza apenas os servidores de nomes explicitamente indicados, n\u00e3o aplicando automaticamente todas as configura\u00e7\u00f5es de <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, ap\u00f3s uma altera\u00e7\u00e3o do DNS, um endere\u00e7o de destino antigo continuar ativo, verifica o TTL da resposta e se est\u00e1 definido um <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>. Uma substitui\u00e7\u00e3o prolongada substitui o TTL da resposta DNS e pode atrasar a aplica\u00e7\u00e3o de uma altera\u00e7\u00e3o em conformidade. A corre\u00e7\u00e3o admiss\u00edvel n\u00e3o \u00e9 uma dura\u00e7\u00e3o globalmente t\u00e3o curta quanto poss\u00edvel, mas sim um valor que se adapte \u00e0 janela de altera\u00e7\u00e3o e \u00e0 capacidade de carga da infraestrutura DNS; muitas vezes, a omiss\u00e3o de <code data-no-translation style=\"font:600 .87em\/1.5 ui-monospace,monospace;color:#235063;background:#edf3f5;border-radius:4px;padding:.1em .3em\">valid<\/code> a solu\u00e7\u00e3o mais limpa. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Em caso de problemas de liga\u00e7\u00e3o ap\u00f3s uma resolu\u00e7\u00e3o bem-sucedida, separa o DNS da liga\u00e7\u00e3o ao backend. Verifica se existem respostas A e AAAA e se o destino \u00e9 efetivamente encaminhado e acess\u00edvel atrav\u00e9s do 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> \u00c9 adequado apenas para um caso de arquitetura comprovadamente operado exclusivamente com IPv4. Um timeout do DNS afeta a resolu\u00e7\u00e3o de nomes; por outro lado, um erro de liga\u00e7\u00e3o a um endere\u00e7o IP j\u00e1 conhecido aponta para problemas de encaminhamento, firewall, porta ou aplica\u00e7\u00e3o. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">No caso de \u00abupstreams\u00bb din\u00e2micos, \u00e9 necess\u00e1rio indicar ainda o n\u00famero da vers\u00e3o, a zona de mem\u00f3ria partilhada 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> s\u00e3o compat\u00edveis. O suporte de c\u00f3digo aberto documentado para este fim aplica-se a partir do NGINX 1.27.3; as instala\u00e7\u00f5es mais antigas n\u00e3o devem ser consideradas equivalentes. <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> Al\u00e9m disso, as estat\u00edsticas do Resolver baseadas na API n\u00e3o constituem uma solu\u00e7\u00e3o de monitoriza\u00e7\u00e3o geral para o NGINX Open Source, uma vez que as funcionalidades referidas dizem respeito ao \u00e2mbito comercial. <\/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\">Selecionar a estrat\u00e9gia do resolver para a opera\u00e7\u00e3o<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">A estrat\u00e9gia adequada n\u00e3o come\u00e7a com um valor de cache gen\u00e9rico, mas sim com a soberania do DNS e a taxa de altera\u00e7\u00f5es. Se a tua equipa conseguir manter a zona autoritativa e se os TTLs desta refletirem de forma realista a janela de implementa\u00e7\u00e3o, ent\u00e3o uma <strong style=\"font-weight:700;color:inherit\">Resolu\u00e7\u00e3o controlada por TTL<\/strong> sem <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> \u00e9, na maioria das vezes, o ponto de partida mais compreens\u00edvel. O DNS continua a ser, ent\u00e3o, a fonte determinante para saber durante quanto tempo uma resposta \u00e9 utilizada. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Um acento colocado deliberadamente <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> \u00c9 uma op\u00e7\u00e3o a considerar se n\u00e3o puderes alterar o TTL e se conseguires justificar, do ponto de vista operacional, um per\u00edodo de cache diferente. Ao faz\u00ea-lo, define qual a consequ\u00eancia de uma falha que \u00e9 aceit\u00e1vel: um valor mais elevado reduz o n\u00famero de poss\u00edveis consultas DNS, mas pode, ap\u00f3s uma mudan\u00e7a, apontar para um endere\u00e7o que j\u00e1 n\u00e3o \u00e9 v\u00e1lido. N\u00e3o se trata nem de um limite m\u00e1ximo para o TTL do DNS nem de um regulador geral de desempenho. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Seleciona o padr\u00e3o NGINX com base na estrutura de encaminhamento. Uma vari\u00e1vel <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> \u00e9 adequado quando o destino \u00e9 determinado em tempo de execu\u00e7\u00e3o, por cada pedido ou configura\u00e7\u00e3o; para tal, \u00e9 necess\u00e1rio um resolutor no \u00e2mbito adequado. Para um grupo de backends nomeado com altera\u00e7\u00f5es de endere\u00e7o baseadas em DNS, \u00e9 necess\u00e1rio um upstream com <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> \u00c9 claro, desde que o NGINX Open Source 1.27.3 ou uma vers\u00e3o mais recente esteja efetivamente dispon\u00edvel. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">S\u00f3 depois \u00e9 que decides <strong style=\"font-weight:700;color:inherit\">Timeouts e fam\u00edlias de IP<\/strong>. O tempo limite do resolver deve corresponder aos tempos limite do cliente e do upstream, para que a aus\u00eancia de uma resposta DNS n\u00e3o provoque atrasos desproporcionados. O IPv4 ou o IPv6 s\u00f3 devem ser ativados de acordo com a arquitetura da rede. Utilize exclusivamente resolvers seguros, capazes de responder de forma fi\u00e1vel \u00e0s zonas internas. <\/p>\n<p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">A resolu\u00e7\u00e3o de DNS e o Keepalive upstream desempenham fun\u00e7\u00f5es diferentes. O Resolver determina qual a morada de backend que o NGINX pode utilizar; o Keepalive mant\u00e9m as liga\u00e7\u00f5es de backend j\u00e1 estabelecidas, mas inativas, para que possam ser reutilizadas. Uma altera\u00e7\u00e3o na reutiliza\u00e7\u00e3o de liga\u00e7\u00f5es n\u00e3o substitui, portanto, nem o planeamento do TTL nem a verifica\u00e7\u00e3o do resolvedor. Para o dimensionamento deste n\u00edvel de liga\u00e7\u00e3o, o artigo sobre <a href=\"https:\/\/webhosting.de\/pt\/configurar-de-forma-ideal-o-keepalive-do-upstream-do-nginx-em-rede-de-proxy-reverso\/\">Keepalive do Upstream do NGINX<\/a> a estrat\u00e9gia do resolutor.<\/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\">Fontes e estado atual dos conhecimentos<\/h2><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Estado da pesquisa: <time datetime=\"2026-09-22\">2026-09-22<\/time><\/p><p style=\"margin:0 0 1.1em;font-size:inherit;line-height:inherit\">Data da pesquisa: 22 de setembro de 2026. Os exemplos de upstreams din\u00e2micos com o \u00abresolver\u00bb no bloco \u00abupstream\u00bb e \u00abserver \u2026 resolve\u00bb referem-se, no NGINX Open Source, ao suporte documentado a partir da vers\u00e3o 1.27.3; no caso dos pacotes de distribui\u00e7\u00e3o, a documenta\u00e7\u00e3o da compila\u00e7\u00e3o e do fabricante tamb\u00e9m \u00e9 determinante.<\/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>Como configurar o resolvedor NGINX para backends din\u00e2micos: TTL do DNS, valid, resolver_timeout, destinos proxy_pass vari\u00e1veis e upstreams din\u00e2micos claramente separados uns dos outros.<\/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":"Configurar o Open File Cache do NGINX de forma ideal: como tirar o m\u00e1ximo partido do desempenho do teu servidor","excerpt":"O cache do NGINX ganha visivelmente em velocidade quando configuro o Open File Cache de forma espec\u00edfica: este mant\u00e9m os metadados dos ficheiros e os identificadores na mem\u00f3ria, poupando acessos dispendiosos ao sistema de ficheiros. Com valores adequados para max, inactive, valid e min_uses, otimizo a entrega de conte\u00fados est\u00e1ticos para tempos de resposta r\u00e1pidos e uma menor carga de E\/S. Pontos-chave do cache de metadados: armazena exist\u00eancia, tamanho, datas e identificadores (handles) em vez de conte\u00fados Dimensionamento: equil\u00edbrio entre consumo de RAM, taxa de acertos e taxa de altera\u00e7\u00f5es Contextos: ideal para imagens\/CSS\/JS; evitar caminhos din\u00e2micos Valida\u00e7\u00e3o: garantir a atualidade com open_file_cache_valid Medi\u00e7\u00e3o: verificar os efeitos em termos de lat\u00eancias, E\/S e taxa de erros O que o Open File Cache realmente armazena Com o Open File Cache, n\u00e3o armazeno conte\u00fados de ficheiros na cache, mas sim informa\u00e7\u00f5es estruturadas: se um ficheiro existe, qual \u00e9 o seu tamanho, quando foi alterado e qual o descritor que j\u00e1 est\u00e1 aberto. Esta informa\u00e7\u00e3o est\u00e1 dispon\u00edvel na mem\u00f3ria e encurta o caminho at\u00e9 \u00e0 pr\u00f3xima resposta. Cada consulta ao disco evitada reduz a carga de E\/S e poupa tempo de CPU, o que \u00e9 especialmente importante quando h\u00e1 muitos ficheiros pequenos. De acordo com a documenta\u00e7\u00e3o da NGINX, a fun\u00e7\u00e3o inclui descritores abertos, informa\u00e7\u00f5es de diret\u00f3rio e erros de pesquisa. Isto acelera as varreduras de diret\u00f3rio e os caminhos de acesso, que, de outra forma, teriam de recorrer novamente ao disco em cada pedido. Utilizo este mecanismo deliberadamente para diret\u00f3rios com acessos frequentes, como bibliotecas de multim\u00e9dia e recursos de compila\u00e7\u00e3o. O efeito \u00e9 particularmente not\u00e1vel em projetos com muitos recursos, nos quais o sistema de ficheiros se tornaria, de outra forma, um gargalo. O cache reduz sensivelmente as chamadas de sistema como stat(), open() e readdir(). Ao mesmo tempo, o controlo mant\u00e9m-se altamente granular, uma vez que defino separadamente o \u00e2mbito e a validade das entradas. Desta forma, mantenho os dados atualizados sem perder a vantagem do armazenamento em cache. Quando vale a pena utilizar o Open File Cache? Ativo o cache especificamente para entregas est\u00e1ticas: imagens, CSS, JavaScript, tipos de letra e downloads. Em \u00e1reas din\u00e2micas, como p\u00e1ginas de in\u00edcio de sess\u00e3o, carrinhos de compras ou percursos personalizados, evito utiliz\u00e1-lo, pois a\u00ed aplicam-se outras regras. O WordPress e as interfaces \u00abheadless\u00bb beneficiam significativamente, uma vez que os temas, os plugins e o B"},"I2":{"id":"I2","post_id":21613,"url":"https:\/\/webhosting.de\/nginx-upstream-keepalive-optimal-konfigurieren-reverse-proxy-netzwerk\/","title":"Configurar o Keepalive do Upstream do NGINX de forma ideal para obter o m\u00e1ximo desempenho como proxy inverso","excerpt":"Configurei o Keepalive do upstream do NGINX de forma a que o proxy inverso estabele\u00e7a menos liga\u00e7\u00f5es, ofere\u00e7a menores lat\u00eancias e absorva de forma fi\u00e1vel os picos de carga. Para tal, ajusto de forma espec\u00edfica o tamanho do pool, os limites de tempo e os cabe\u00e7alhos, para que as liga\u00e7\u00f5es sejam reutilizadas e o percurso dos dados se mantenha otimizado. Pontos-chave: Impor HTTP\/1.1 e limpar os cabe\u00e7alhos de liga\u00e7\u00e3o; dimensionar corretamente o keepalive por worker; ajustar os tempos de espera aos valores do backend; limitar e reciclar as liga\u00e7\u00f5es de pedidos;liga\u00e7\u00e3o e recicl\u00e1-las Monitorizar a taxa de liga\u00e7\u00f5es e a lat\u00eancia Por que raz\u00e3o o Keepalive upstream reduz drasticamente o esfor\u00e7o de liga\u00e7\u00e3o Sem reutiliza\u00e7\u00e3o, o NGINX abre uma nova liga\u00e7\u00e3o ao backend por cada pedido, o que implica handshakes adicionais, mais ciclos de CPU e recursos adicionais do kernel; \u00e9 precisamente aqui que o Keepalive entra em a\u00e7\u00e3o. Fa\u00e7o com que o NGINX armazene em cache sockets j\u00e1 estabelecidos, mas atualmente inativos, e os utilize para pedidos subsequentes, o que reduz significativamente os tempos de liga\u00e7\u00e3o. Isto diminui a taxa de liga\u00e7\u00f5es por segundo, reduz os picos de backlog e diminui as mudan\u00e7as de contexto no sistema operativo. Especialmente no caso de liga\u00e7\u00f5es TLS ao backend, poupo tempo de forma significativa atrav\u00e9s da reutiliza\u00e7\u00e3o de sess\u00f5es. Assim, a cadeia de respostas mant\u00e9m-se fi\u00e1vel e reage de forma fluida, mesmo com um elevado d\u00e9bito. Princ\u00edpio b\u00e1sico e a diretiva \u201ekeepalive\u201c no \u00abupstream\u00bb A diretiva \u00abkeepalive\u00bb no bloco \u00abupstream\u00bb limita o n\u00famero de liga\u00e7\u00f5es de backend inativas armazenadas em cache por cada \u00abworker\u00bb. Este limite n\u00e3o se aplica globalmente, mas sim estritamente a cada processo \u00abworker\u00bb, raz\u00e3o pela qual mantenho sempre o n\u00famero de \u00abworkers\u00bb sob vigil\u00e2ncia. Quando o pool estiver cheio, o NGINX encerra primeiro a liga\u00e7\u00e3o que est\u00e1 inativa h\u00e1 mais tempo, para que haja espa\u00e7o para novos sockets. Para a reutiliza\u00e7\u00e3o, o lado do proxy necessita de HTTP\/1.1 e de um cabe\u00e7alho de liga\u00e7\u00e3o neutralizado. Sem estes pr\u00e9-requisitos, o pool permanece vazio, apesar de eu definir \u00abkeepalive\u00bb no upstream, o que surpreende muitos administradores no in\u00edcio. upstream backend_pool { server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080; keepalive 32; # liga\u00e7\u00f5es inativas por worker keepalive_requests 1000; # Reciclagem ap\u00f3s N pedidos keepalive_timeout 60s; # Tempo de inatividade } 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":"Como utilizar corretamente a limpeza da cache do NGINX: guia pr\u00e1tico para uma invalida\u00e7\u00e3o r\u00e1pida e segura da cache","excerpt":"Vou mostrar-te como esvaziar o cache do nginx de forma seletiva, sem que os visitantes recebam respostas desatualizadas nem se corra o risco de falhas de seguran\u00e7a. Com estrat\u00e9gias de purga claras, chaves de cache bem definidas e uma automatiza\u00e7\u00e3o segura, vou criar um fluxo de trabalho que mant\u00e9m o WordPress e o PHP-FPM r\u00e1pidos e atualizados. Pontos-chave: Planear chaves de cache de forma organizada: host, URI, cabe\u00e7alhos e cookies necess\u00e1rios; Combinar estrat\u00e9gias de purga: tempos de expira\u00e7\u00e3o, chaves espec\u00edficas, purga controlada; Priorizar sempre a seguran\u00e7a: IPs internas, autentica\u00e7\u00e3o, registo de atividades, sem pontos de extremidade abertos; Utilizar a automatiza\u00e7\u00e3o: hooks do WordPress e gatilhos de implementa\u00e7\u00e3o para limpezas Ativar a monitoriza\u00e7\u00e3o: X-FastCGI-Cache, registos, tamanhos do cache Compreender o cache do NGINX: base para uma limpeza eficaz Antes de efetuar a limpeza, compreendo como o NGINX armazena os dados. O NGINX serve back-ends HTTP atrav\u00e9s do cache de proxy e respostas PHP din\u00e2micas atrav\u00e9s do cache FastCGI; al\u00e9m disso, existem variantes como o uWSGI ou o SCGI para configura\u00e7\u00f5es espec\u00edficas, que aqui apenas menciono de passagem. Em pilhas t\u00edpicas de WordPress ou PHP, \u00e9 sobretudo o cache FastCGI que proporciona o maior efeito, porque grava p\u00e1ginas HTML prontas do PHP-FPM no sistema de ficheiros e as fornece diretamente na pr\u00f3xima chamada. Isto poupa a CPU e a base de dados e reduz os tempos de resposta, desde que os conte\u00fados estejam atualizados. \u00c9 precisamente neste ponto que uma purga inteligente determina se os utilizadores recebem respostas atualizadas ou se visualizam p\u00e1ginas desatualizadas. Chaves de cache: a chave para uma purga precisa Cada resultado baseia-se numa chave de cache, que geralmente \u00e9 composta pelo host, pelo URI da solicita\u00e7\u00e3o, pelos cabe\u00e7alhos relevantes e por partes m\u00ednimas de cookies. Planeio a chave de forma a que esta tenha em conta apenas as diferen\u00e7as que alteram efetivamente a sa\u00edda HTML; caso contr\u00e1rio, fragmento o cache desnecessariamente. Trato os cabe\u00e7alhos Vary, o idioma ou as classes de dispositivos com modera\u00e7\u00e3o e verifico, atrav\u00e9s de chamadas de teste, se a varia\u00e7\u00e3o pretendida \u00e9 realmente necess\u00e1ria. Uma chave consistente permite, posteriormente, remover exatamente os objetos afetados por uma altera\u00e7\u00e3o, em vez de apagar grandes diret\u00f3rios. Chaves bem definidas poupam E\/S, mant\u00eam a taxa de acertos elevada e facilitam imensamente os pedidos de purga. Conce\u00e7\u00e3o da chave de cache na pr\u00e1tica: normaliza\u00e7\u00e3o e redu\u00e7\u00e3o Na pr\u00e1tica, normalizo a"}},"_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":"Configurar corretamente a cache do resolver do NGINX","slug":"configurar-corretamente-a-cache-do-resolver-do-nginx","excerpt":"Como configurar o resolvedor NGINX para backends din\u00e2micos: TTL do DNS, valid, resolver_timeout, destinos proxy_pass vari\u00e1veis e upstreams din\u00e2micos claramente separados uns dos outros.","status":"draft","featured_media":21661},"verify":{"content_md5":"00d4ee046c92de068b9c7a606af6b568","title":"Configurar corretamente a cache do resolver do NGINX","slug":"configurar-corretamente-a-cache-do-resolver-do-nginx","excerpt":"Como configurar o resolvedor NGINX para backends din\u00e2micos: TTL do DNS, valid, resolver_timeout, destinos proxy_pass vari\u00e1veis e upstreams din\u00e2micos claramente separados uns dos outros.","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":"M\u00f3dulo ngx_http_core_module"},"S2":{"id":"S2","url":"https:\/\/nginx.org\/en\/docs\/http\/ngx_http_upstream_module.html","title":"M\u00f3dulo ngx_http_upstream_module"},"S3":{"id":"S3","url":"https:\/\/nginx.org\/en\/docs\/http\/ngx_http_proxy_module.html?utm_source=openai","title":"M\u00f3dulo ngx_http_proxy_module"},"S4":{"id":"S4","url":"https:\/\/nginx.org\/en\/docs\/switches.html?utm_source=openai","title":"Par\u00e2metros da linha de comandos"}},"_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":"Configurar corretamente a cache do resolver do NGINX","slug":"configurar-corretamente-a-cache-do-resolver-do-nginx","excerpt":"Como configurar o resolvedor NGINX para backends din\u00e2micos: TTL do DNS, valid, resolver_timeout, destinos proxy_pass vari\u00e1veis e upstreams din\u00e2micos claramente separados uns dos outros.","status":"draft","featured_media":0},"expected":{"content_md5":"00d4ee046c92de068b9c7a606af6b568","title":"Configurar corretamente a cache do resolver do NGINX","slug":"configurar-corretamente-a-cache-do-resolver-do-nginx","excerpt":"Como configurar o resolvedor NGINX para backends din\u00e2micos: TTL do DNS, valid, resolver_timeout, destinos proxy_pass vari\u00e1veis e upstreams din\u00e2micos claramente separados uns dos outros.","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":"Configurar corretamente a cache do resolver do NGINX","slug":"configurar-corretamente-a-cache-do-resolver-do-nginx","excerpt":"Como configurar o resolvedor NGINX para backends din\u00e2micos: TTL do DNS, valid, resolver_timeout, destinos proxy_pass vari\u00e1veis e upstreams din\u00e2micos claramente separados uns dos outros.","seo":{"title":"Configurar corretamente a cache do resolver do NGINX","description":"Configurar corretamente o NGINX Resolver: planear de forma clara o TTL do DNS, o \u00abvalid\u00bb, o \u00abresolver_timeout\u00bb e os upstreams din\u00e2micos para proxies reversos.","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":"90","_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\/pt\/wp-json\/wp\/v2\/posts\/21658","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=21658"}],"version-history":[{"count":3,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21658\/revisions"}],"predecessor-version":[{"id":21664,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21658\/revisions\/21664"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21661"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21658"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21658"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21658"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}