O que faz com que o DNS local devolva o IP certo, mas o serviço errado?

O DNS local pode devolver o IP correto do NAS e, ainda assim, abrir o serviço errado quando o proxy inverso partilhado encaminha o nome de anfitrião para outro anfitrião virtual.

Num servidor doméstico ZimaSpace, várias aplicações podem partilhar um único endereço LAN por detrás do Nginx, Traefik, Caddy ou de outro proxy inverso. O DNS apenas escolhe o IP de destino. O navegador continua a enviar um nome de anfitrião através do SNI do TLS e do cabeçalho HTTP Host, e o proxy decide qual o contentor que recebe o pedido.

Verifique se a resposta do DNS dividido é realmente a pretendida

Compare o registo local com o registo público e confirme que ambos os nomes de anfitrião devem terminar no mesmo proxy inverso.

Um artigo focado sobre DNS dividido em homelabs em o DNS dividido pode devolver um caminho privado ajuda a isolar esta hipótese, porque aborda o mesmo microproblema em vez de apenas definir o protocolo subjacente.

Mantenha o nome de anfitrião do navegador inalterado, alterando apenas o endereço devolvido pelo DNS interno.

Comprove que o proxy encaminha pelo nome de anfitrião

Envie pedidos com o nome de anfitrião esperado e compare-os com o acesso direto por IP ao mesmo NAS.

Um guia focado sobre proxies inversos em homelabs em o cabeçalho Host seleciona o backend ajuda a isolar esta hipótese, porque aborda o mesmo microproblema em vez de apenas definir o protocolo subjacente.

Se o IP direto abrir uma aplicação predefinida enquanto o nome de anfitrião abrir a aplicação correta, o DNS não é o problema; o encaminhamento do anfitrião virtual está a funcionar conforme previsto.

Verifique se o cabeçalho Host está a ser reescrito

Inspecione os cabeçalhos Host e forwarded-host no proxy e no backend.

Um artigo focado sobre segurança e HTTP em as alterações ao cabeçalho Host podem alterar o encaminhamento ajuda a isolar esta hipótese, porque aborda o mesmo microproblema em vez de apenas definir o protocolo subjacente.

Corrija apenas a camada que reescreve o nome de anfitrião. Não adicione registos DNS duplicados para compensar um erro de encaminhamento HTTP.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifique o SNI do TLS antes do encaminhamento HTTP

Várias aplicações HTTPS num único IP têm, ainda assim, de apresentar o nome de anfitrião necessário para selecionar o certificado e o anfitrião virtual pretendidos.

Um guia prático focado sobre SNI em o SNI seleciona entre sites HTTPS num único IP ajuda a isolar esta hipótese, porque aborda o mesmo microproblema em vez de apenas definir o protocolo subjacente.

Compare o nome do certificado com o encaminhamento do backend. Um certificado de outra aplicação é indício de que a seleção falhou antes de o pedido chegar ao serviço pretendido.

Inspecione o anfitrião virtual predefinido

Se nenhuma regra de nome de anfitrião corresponder, muitos proxies devolvem um servidor predefinido que pode pertencer a outra aplicação.

Um artigo focado sobre resolução de problemas do Nginx em um nome de anfitrião sem correspondência pode chegar ao servidor predefinido ajuda a isolar esta hipótese, porque aborda o mesmo microproblema em vez de apenas definir o protocolo subjacente.

Crie regras explícitas para os anfitriões e uma resposta predefinida neutra, em vez de permitir que uma aplicação se torne a opção geral para todos os domínios desconhecidos.

Mantenha o encaminhamento DNS separado do encaminhamento do proxy

Considere o DNS como a seleção do endereço e o proxy inverso como a seleção da aplicação.

Um artigo focado sobre DNS versus proxy inverso em o DNS e os proxies inversos resolvem camadas de encaminhamento diferentes ajuda a isolar esta hipótese, porque aborda o mesmo microproblema em vez de apenas definir o protocolo subjacente.

Volte a testar com o nome de anfitrião exato da aplicação a partir de um cliente LAN. O resultado correto é o certificado esperado, a rota do proxy e o backend corretos, sem marcadores de acesso direto por IP.

Volte a testar o caminho exato do servidor doméstico

Depois de alterar uma variável, repita o mesmo fluxo de trabalho do NAS ou do serviço autoalojado a partir do mesmo cliente, em vez de mudar para um teste diferente que possa utilizar outro caminho.

O guia relacionado da ZimaSpace em o caminho de rede adjacente do servidor doméstico ajuda a manter a verificação final associada ao mesmo ambiente autoalojado.

A correção só está concluída quando o sintoma original continua resolvido após voltar a ligar, reiniciar o serviço e realizar uma segunda transferência ou pedido controlado.