Como resolver problemas numa aplicação remota que funciona por IP, mas não por domínio

Se uma aplicação funciona por IP, mas não por domínio, o servidor está acessível e a falha encontra-se normalmente no DNS, no encaminhamento baseado no nome do anfitrião, no TLS ou nos redirecionamentos.

O acesso remoto por IP prova que existe algum caminho de rede até ao servidor doméstico, mas um pedido para um domínio transporta identidade adicional através do DNS, do nome do servidor TLS, do cabeçalho HTTP Host e do URL público configurado na aplicação. O diagnóstico mais rápido mantém o mesmo cliente, porta e servidor, verificando cada camada de identidade pela ordem correta, em vez de alterar simultaneamente o proxy inverso, o certificado e os registos DNS.

Confirme Que o Teste por IP Chega ao Serviço Pretendido

Registe o endereço IP, a porta, o protocolo e a resposta exatos que funcionam remotamente. Verifique se o IP abre a aplicação real, uma página predefinida do proxy inverso, a página de início de sessão do router ou outro serviço que partilhe o mesmo endereço público.

Um guia sobre proxies inversos em homelabs explica que um proxy pode alojar várias aplicações no mesmo endereço porque analisa o cabeçalho Host solicitado antes de escolher o serviço a montante.

Se o IP chegar apenas a um site predefinido, isso prova que o proxy está acessível, mas não que a rota da aplicação pretendida funciona. Mantenha um marcador de resposta conhecido, como o título de uma página ou um cabeçalho, para que os testes posteriores identifiquem o anfitrião virtual correto.

Compare o DNS Público com o Endereço IP Funcional

Consulte o domínio através de um servidor de nomes autoritativo e, pelo menos, de um resolvedor recursivo externo. Registe todas as respostas A e AAAA, o TTL e se um CNAME aponta para outro nome de anfitrião.

As orientações sobre self-hosting indicam que as respostas em cache podem permanecer até o TTL anterior expirar, pelo que uma alteração recente pode deixar alguns clientes a utilizar um destino DNS antigo depois de o registo autoritativo ser corrigido.

Se o registo A for diferente do IP funcional, corrija o registo ou o atualizador de DDNS. Se o A estiver correto, mas o AAAA apontar para um caminho IPv6 inacessível, teste cada família de endereços separadamente e remova ou corrija o registo problemático.

Ligue-se ao IP Funcional Mantendo o Domínio

Utilize um cliente que consiga ligar-se ao IP funcional conhecido, enviando simultaneamente o domínio como cabeçalho HTTP Host e nome do servidor TLS. Isto altera o destino sem eliminar a identidade esperada pelo proxy e pelo certificado.

O Server Fault explica que um proxy inverso HTTP pode utilizar o cabeçalho Host para selecionar uma rota, tal como acontece com os anfitriões virtuais baseados no nome.

Se o pedido com o domínio preservado funcionar, o DNS é a camada com problemas. Se chegar ao proxy, mas devolver o site errado ou um erro 404, verifique a correspondência dos anfitriões virtuais e a prioridade das rotas; se o TLS falhar antes do HTTP, verifique o SNI e a seleção do certificado.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verifique o SNI do TLS e a Identidade do Certificado

Compare o certificado devolvido para o domínio com o certificado devolvido para o IP sem nome de domínio. Registe os nomes do sujeito, o emissor, a validade e se o proxy apresenta um certificado predefinido.

O SNI transporta o nome do anfitrião no ClientHello do TLS, antes do pedido HTTP encriptado, permitindo ao proxy selecionar o anfitrião virtual seguro. Por isso, um pedido apenas por IP pode não incluir o nome do anfitrião utilizado durante a seleção do TLS, mesmo quando chega ao mesmo listener.

Corrija o certificado do domínio e a rota SNI, em vez de esperar que exista um certificado para um IP privado ou dinâmico. Se houver uma CDN ou um proxy TCP à frente, confirme que este encaminha ou termina o SNI para o nome do anfitrião pretendido.

Verifique se o DNS Interno e Externo Não Enviam por Caminhos Diferentes

Compare o resultado do domínio através de dados móveis, de um resolvedor público e da LAN doméstica. O DNS dividido pode devolver intencionalmente um endereço privado do proxy em casa e um endereço público remotamente, mas ambas as respostas têm de chegar à mesma rota lógica do nome do anfitrião.

Uma discussão no Level1Techs sobre homelabs mostra que o acesso local através de um proxy inverso pode exigir o seu próprio desenho de DNS quando o DNS público e o encaminhamento doméstico seguem caminhos internos e externos diferentes.

Se apenas um resolvedor devolver o endereço errado, corrija essa vista DNS. Se o endereço público funcionar por IP, mas o domínio falhar em todo o lado, concentre-se no Host, no SNI, no certificado e na identidade da aplicação, em vez de no DNS dividido.

Verifique os URLs Canónicos e os Redirecionamentos Antes de Declarar o DNS Corrigido

Inspecione todos os redirecionamentos depois de o domínio chegar à aplicação. O proxy inverso ou a aplicação pode enviar os clientes para um nome de anfitrião interno, um domínio antigo, o esquema errado, uma porta privada ou um URL de retorno obsoleto.

O artigo da ZimaSpace sobre se o DNS dividido pode resolver uma falha que ocorre apenas dentro de casa aborda o caso adjacente em que o nome do anfitrião está correto, mas a rota varia consoante a localização.

O problema só fica resolvido quando o DNS autoritativo devolve o endereço pretendido, o domínio seleciona o certificado e a rota de proxy corretos, os redirecionamentos preservam o nome do anfitrião público e todo o fluxo de trabalho remoto funciona sem substituir o domínio pelo IP.