Sim, o DNS dividido pode corrigir uma falha interna quando o nome público deve resolver para um endereço local diferente em casa.
Uma aplicação auto-hospedada pode funcionar com dados móveis porque o DNS público aponta para o endereço WAN doméstico, enquanto os dispositivos dentro da LAN falham porque o router não consegue fazer hairpin nessa ligação através da regra NAT pública. O DNS dividido evita esse ciclo ao devolver o endereço local do reverse-proxy ou da aplicação aos clientes domésticos, mas só tem sucesso quando o mesmo nome de host, certificado, rota do proxy e URL base da aplicação permanecem válidos em ambos os caminhos.
Comprove Primeiro Que o Nome Público Funciona Externamente
Teste o URL exato da aplicação a partir de dados móveis ou outra rede externa. Confirme a resolução DNS, TLS, roteamento do reverse-proxy, login, redirecionamentos e a funcionalidade da aplicação que atualmente falha dentro de casa.
A Tailscale descreve o DNS dividido como uma forma de dar aos clientes respostas DNS diferentes conforme o contexto em vez de forçar utilizadores internos e externos a passar por uma rota idêntica.
Se a aplicação também falhar externamente, o DNS dividido não é a primeira reparação. Corrija o DNS público, o túnel ou o encaminhamento de porta, o roteamento do proxy, TLS ou a configuração da aplicação antes de criar uma segunda resposta que possa ocultar a falha original.
Verifique Se a Falha Interna É Hairpin NAT
De um cliente doméstico, consulte o nome público e registe o endereço retornado. Se resolver para o IP público doméstico, verifique se o router suporta NAT loopback ou hairpin NAT para esse serviço encaminhado.
Um tópico de resolução de problemas do Level1Techs recomenda uma substituição local de DNS que aponta o domínio para o endereço interno do servidor quando o hairpin NAT é pouco fiável.
Compare a falha do nome público com o acesso direto ao endereço local do reverse-proxy. Se o acesso local direto alcançar o proxy ou aplicação pretendidos, enquanto o IP público falha apenas internamente, o DNS dividido é uma solução adequada.
Aponte a Resposta Interna Para o Mesmo Ponto de Entrada Lógico
Crie um registo DNS interno para o nome público existente, mas aponte-o para o endereço LAN do reverse proxy ou ponto de entrada local controlado. Evite apontar diretamente para um backend quando os utilizadores externos normalmente passam pelo proxy.
Uma comparação de DNS dividido explica que os clientes locais podem resolver o mesmo domínio para um endereço interno privado enquanto os clientes externos continuam a receber o endereço público.
Manter ambos os caminhos no mesmo proxy preserva o roteamento baseado no nome de host, políticas de acesso, cabeçalhos e certificados. Contornar o proxy para os clientes domésticos pode carregar a página, mas quebrar a autenticação, callbacks, WebSockets ou controlos de segurança que existem apenas no proxy.
Verifique Que Todos os Clientes Necessários Usam o Resolvedor Interno
Verifique o servidor DNS usado por telemóveis, portáteis, TVs, contentores e clientes VPN que devem receber a resposta interna. DNS seguro do navegador, DNS Privado móvel, um resolvedor VPN ou um servidor DNS público codificado podem ignorar o resolvedor doméstico.
A orientação para auto-hospedagem sobre DNS dividido alerta que as falhas ocorrem frequentemente quando a VPN ou o cliente continua a usar o contexto de resolvedor errado apesar de estarem na rede interna.
Consulte diretamente o servidor DNS interno e depois compare essa resposta com a pesquisa normal do cliente. Se o servidor devolver o endereço local mas o cliente não, corrija a distribuição DNS do DHCP, DNS encriptado, política VPN ou substituições do cliente antes de editar novamente o registo.
Mantenha o Mesmo Nome de Host Para TLS e Callbacks da Aplicação
Aceda à aplicação pelo seu domínio normal depois do registo interno estar ativo. Não o substitua por um marcador para o IP privado, porque os certificados HTTPS e as rotas do reverse-proxy estão normalmente ligados ao nome de host.
O caminho interno deve também preservar a URL base pública da aplicação, URI de redirecionamento OAuth, endereço do webhook e cabeçalhos encaminhados. O DNS dividido altera o endereço de destino, não o nome de host que o navegador ou fornecedor deve usar.
Se a aplicação redirecionar para o IP público, gerar um nome interno ou rejeitar o cabeçalho host, corrija as definições do proxy e da URL da aplicação. O DNS sozinho não pode reparar um serviço configurado com identidades inconsistentes.
Mantenha o DNS Dividido Apenas Quando Ambos os Caminhos Forem Previsíveis
Teste a partir do Wi-Fi doméstico, Wi-Fi de convidados, VPN, dados móveis e um dispositivo a usar DNS Privado. Confirme que cada cliente recebe o endereço pretendido e acede à mesma identidade da aplicação.
O guia ZimaSpace sobre porque uma cloud privada funciona apenas numa rede fornece o sintoma inverso e ajuda a verificar que as duas visões DNS permanecem intencionalmente diferentes.
O DNS dividido é a correção certa quando elimina um ciclo público quebrado enquanto preserva o mesmo domínio, certificado TLS, rota do proxy e comportamento da aplicação. Use hairpin NAT em vez disso quando o router o suportar de forma fiável e manter duas visões DNS acrescentaria mais risco do que valor.
Suporte e Dicas
Mais para Ler

O Plex pode partilhar uma GPU com outro contentor Docker?
O Plex e outro contentor conseguem frequentemente aceder à mesma GPU, mas é necessário testar o suporte dos controladores, o mapeamento de dispositivos, a...

Como saber se um erro do Plex vem do cliente ou do servidor
Reproduza o mesmo item noutro cliente, compare o percurso da sessão e, em seguida, recolha provas do servidor apenas depois de o âmbito lhe...

Como configurar a cache do Plex e o armazenamento temporário de transcodificação
Proteja o estado persistente do Plex enquanto coloca os ficheiros temporários de transcodificação num armazenamento local adequado e, em seguida, verifique a limpeza, o...

