Porque é que um proxy inverso redireciona uma aplicação para o domínio de outra aplicação?

Um proxy inverso pode enviar uma aplicação para o domínio de outra aplicação quando o backend ou middleware cria redirecionamentos a partir do nome de anfitrião público errado.

Numa infraestrutura autoalojada ZimaSpace, várias aplicações podem partilhar o mesmo proxy, embora cada uma espere o seu próprio URL base público. Se Host, X-Forwarded-Host, o esquema, o middleware ou um URL canónico ao nível da aplicação apontar para outro serviço, a primeira página pode carregar corretamente e o redirecionamento 301, 302 ou o callback de início de sessão seguinte pode mudar de domínio.

Verifique o Host e o esquema enviados para o backend

Capture os cabeçalhos do pedido no proxy e no backend enquanto reproduz o redirecionamento.

Um guia focado de implementação de proxy inverso sobre o encaminhamento do host e do esquema até ao backend ajuda a isolar este ramo, porque aborda o mesmo microproblema em vez de apenas definir o protocolo subjacente.

Corrija os cabeçalhos do proxy antes de alterar os URLs da aplicação. Um backend não consegue criar o redirecionamento absoluto correto quando acredita que o pedido utilizou outro host.

Inspecione especificamente o X-Forwarded-Host

Algumas frameworks utilizam X-Forwarded-Host em vez do cabeçalho Host bruto ao gerar URLs absolutos.

Um explicador focado de cabeçalhos HTTP sobre a preservação do nome de anfitrião público pelo X-Forwarded-Host ajuda a isolar este ramo, porque aborda o mesmo microproblema em vez de apenas definir o protocolo subjacente.

Compare este cabeçalho entre a aplicação funcional e a aplicação redirecionada incorretamente. Remova as substituições globais que obrigam todos os backends a utilizar um único domínio.

Verifique se a aplicação gera URLs absolutos

Procure definições da framework que confiem nos cabeçalhos do proxy e construam ligações canónicas ou redirecionamentos.

Um artigo focado e prático de depuração de proxy sobre URLs absolutos que podem estar errados atrás de um proxy ajuda a isolar este ramo, porque aborda o mesmo microproblema em vez de apenas definir o protocolo subjacente.

Corrija a confiança da framework nos cabeçalhos do proxy ou a definição do URL público, em vez de reescrever todos os redirecionamentos na periferia.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Confirme o URL base ou o domínio canónico da aplicação

Muitas aplicações autoalojadas armazenam um URL do site independentemente da regra do proxy.

Um estudo de caso focado e prático sobre uma aplicação atrás de um proxy em o URL base da aplicação pode substituir o nome de anfitrião do proxy ajuda a isolar este ramo, porque aborda o mesmo microproblema em vez de apenas definir o protocolo subjacente.

Compare os valores do URL da aplicação armazenados após migrações ou restauros. Uma base de dados copiada pode transportar o nome de anfitrião canónico do ambiente de outra aplicação.

Audite o middleware de redirecionamento antes do backend

Uma regra do proxy pode reescrever intencionalmente o esquema ou o host antes de o pedido chegar à aplicação.

Um guia prático focado em Traefik para homelabs sobre o middleware de redirecionamento pode substituir o host ajuda a isolar este ramo, porque aborda o mesmo microproblema em vez de apenas definir o protocolo subjacente.

Desative apenas o middleware de redirecionamento suspeito num router de teste. Mantenha a imposição de HTTPS separada dos redirecionamentos entre domínios.

Verifique os URLs de callback OAuth e OIDC

Os fluxos de autenticação expõem frequentemente um nome de anfitrião público incorreto, porque o fornecedor valida um URI de redirecionamento exato.

Um artigo focado de resolução de problemas de OIDC sobre os callbacks OIDC dependem do URL público do proxy ajuda a isolar este ramo, porque aborda o mesmo microproblema em vez de apenas definir o protocolo subjacente.

Compare em conjunto o emissor, o callback, os cabeçalhos encaminhados e o URL base da aplicação. O carregamento normal de uma página não prova que o caminho do callback de início de sessão esteja correto.

Teste novamente o caminho exato do servidor doméstico

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

O guia relacionado da ZimaSpace sobre o caminho de rede adjacente do servidor doméstico ajuda a manter a verificação final ligada 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 efetuar uma segunda transferência ou pedido controlado.

Perguntas frequentes

O DNS pode causar um HTTP 301 ou 302?

O DNS apenas devolve um endereço. O redirecionamento é gerado pelo proxy, pela camada de autenticação ou pela aplicação.

Porque é que a aplicação correta carrega antes de o navegador mudar de domínio?

A rota inicial do proxy pode estar correta, enquanto o backend gera mais tarde um redirecionamento absoluto a partir de um URL base ou host encaminhado incorreto.

Devo reescrever todos os cabeçalhos Location no proxy?

Não. Corrija primeiro a origem do nome de anfitrião incorreto; uma reescrita ampla das respostas pode ocultar erros de configuração da aplicação.