Por que é que um proxy reverso funciona por domínio mas falha por IP local?

Eva Wong

IceWhale author

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

Why Does a Reverse Proxy Work by Domain but Fail by Local IP?

Um proxy reverso funciona por domínio porque as suas regras de encaminhamento e TLS dependem frequentemente do nome de anfitrião solicitado, e não apenas do IP de destino.

Quando um cliente doméstico abre https://app.example.com, o DNS fornece um IP, mas o navegador ainda envia o domínio durante o handshake TLS e no cabeçalho HTTP Host. Abrir https://192.168.1.20 altera esses identificadores, pelo que o proxy pode selecionar um site padrão, rejeitar o certificado, não encontrar a rota da aplicação ou redirecionar de volta para o URL público configurado. O teste correto preserva o nome de anfitrião pretendido, alterando apenas o destino da rede.

Compare o Pedido pelo Nome de Anfitrião com o Pedido pelo IP Direto

Envie um pedido para o domínio e outro para o IP local, depois compare o código de estado, certificado, cabeçalhos de resposta, localização do redirecionamento e o registo de acesso do proxy reverso. Não presuma que ambos os pedidos são equivalentes só porque chegam à mesma interface Ethernet.

Um guia de proxy reverso para homelab explica que o proxy inspeciona o cabeçalho HTTP Host para encaminhar vários serviços através de um único IP e porta.

Se o pedido pelo domínio corresponder a uma rota de aplicação enquanto o pedido pelo IP atingir uma página padrão ou 404, o proxy está a funcionar conforme configurado. A decisão seguinte é se o acesso direto por IP é realmente necessário ou se o DNS local deve preservar o domínio.

Teste o IP Local Preservando o Cabeçalho Host Pretendido

Use uma ferramenta cliente que se ligue ao IP local do proxy enquanto envia o domínio da aplicação como cabeçalho Host. Para HTTPS, preserve também o domínio como nome do servidor TLS em vez de o substituir pelo IP.

O Server Fault descreve como um proxy reverso HTTP pode usar o cabeçalho Host para escolher a rota da mesma forma que hosts virtuais baseados em nome.

Se o pedido com host forçado tiver sucesso, a rota do proxy e o backend estão saudáveis; a falha no IP direto é uma incompatibilidade de identidade. Se ainda falhar, inspecione o ouvinte, firewall local, ponto de entrada do proxy e prioridade da rota antes de alterar o DNS.

Verifique o TLS SNI e a Correspondência do Certificado

O HTTPS adiciona uma decisão de nome de anfitrião antes do pedido HTTP. O cliente normalmente envia a Indicação de Nome do Servidor (SNI) durante o handshake TLS para que o proxy possa selecionar o certificado correto e o host virtual seguro.

Uma implementação de proxy reverso com SNI nota que os backends HTTPS são selecionados usando o nome SNI do cliente antes que os cabeçalhos HTTP ordinários possam ser examinados.

O acesso direto por IP pode apresentar um certificado padrão ou falhar na validação do nome de anfitrião mesmo quando o proxy está acessível. Use o domínio com DNS local ou implemente um certificado gerido deliberadamente contendo o IP apenas quando o HTTPS por IP direto for um requisito operacional real.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

Inspecione o Site Padrão e a Prioridade da Rota

Verifique qual host virtual trata os pedidos que não correspondem a um domínio configurado. Um site padrão pode devolver um painel, redirecionar para outro nome de anfitrião, fechar a ligação ou mostrar um erro genérico.

Uma discussão sobre Caddy mostra que um pedido pode chegar ao IP correto do proxy enquanto o cabeçalho Host e o nome TLS ainda determinam se o upstream pretendido é escolhido.

Mantenha a rota padrão explícita e segura. Não adicione um proxy catch-all amplo para um backend apenas para fazer o acesso por IP funcionar, pois isso pode encaminhar nomes de anfitrião desconhecidos ou tráfego de varredura para uma aplicação que deveria estar restrita ao domínio.

Verifique se a Aplicação Redireciona para o Seu URL Canónico

Mesmo quando o proxy aceita o pedido por IP, o backend pode impor um URL base público configurado e redirecionar o navegador para o domínio. Cookies de autenticação, callbacks OAuth, origens WebSocket e verificações CSRF também podem depender desse anfitrião canónico.

Compare o registo do proxy com o registo da aplicação e inspecione o cabeçalho Location. Um redirecionamento para o domínio não é uma falha de encaminhamento; é uma evidência de que a aplicação espera uma identidade pública única.

Corrija os cabeçalhos de host e protocolo encaminhados quando a aplicação gerar o URL externo errado. Não substitua o domínio canónico por um IP privado apenas para evitar o redirecionamento, pois isso pode quebrar certificados e o acesso remoto.

Use DNS Local Quando o Domínio For a Interface Pretendida

Crie um registo DNS interno que resolva o domínio da aplicação para o endereço local do proxy reverso. O navegador usa então o caminho eficiente da LAN enquanto preserva o mesmo cabeçalho Host, nome SNI, certificado, cookies e URL da aplicação.

A comparação da ZimaSpace de proxies reversos e caminhos de acesso privados ajuda a decidir se o domínio deve permanecer um ponto de entrada local e público ou ficar atrás de uma rede privada.

O problema fica resolvido quando o domínio funciona tanto dentro como fora através de respostas DNS intencionais, enquanto o IP direto ou alcança um site padrão documentado ou é deliberadamente rejeitado. Um proxy encaminhado por domínio não precisa comportar-se como um servidor de site único endereçado por IP.