Como corrigir um proxy reverso que encaminha um domínio para a aplicação errada depois de adicionar uma regra abrangente
Um proxy inverso pode encaminhar um domínio para a aplicação errada quando uma nova rota abrangente corresponde de forma mais ampla ou tem prioridade sobre a regra de anfitrião pretendida.
Este caso é mais específico do que um redirecionamento genérico para o domínio errado ou um problema de DNS. O teste essencial é verificar se o domínio correto continua a chegar ao IP e certificado esperados do proxy, mas o proxy seleciona o backend errado apenas depois de a nova rota predefinida existir. Compare as correspondências e prioridades das rotas antes de alterar o DNS, os URLs base da aplicação ou os certificados.
Comprove que a regra abrangente alterou a seleção do backend
Envie o mesmo pedido de domínio antes e depois de desativar apenas a nova rota abrangente ou predefinida. Registe o registo de acesso do proxy, o router ou bloco de servidor selecionado, o endereço do backend, o marcador da resposta e o certificado.
Um guia prático sobre servidores predefinidos do Nginx alerta para o facto de as regras abrangentes poderem capturar tráfego, mesmo quando já existem vários hosts virtuais explícitos.
Se a desativação do fallback restaurar imediatamente a aplicação pretendida, mantenha o DNS e a aplicação de backend inalterados. A tarefa seguinte é fazer com que a rota específica ganhe, sem remover o comportamento de fallback seguro para nomes de anfitrião desconhecidos.
Verifique se a regra do anfitrião específico ainda corresponde exatamente
Compare o nome de anfitrião pedido com a regra de rota pretendida, carácter a carácter, incluindo o subdomínio, os limites dos curingas, os pontos finais nos testes e se a regra está a escutar no mesmo ponto de entrada HTTP ou HTTPS que a rota abrangente.
Um guia de proxy inverso para várias aplicações mostra que as regras de nome de anfitrião selecionam backends diferentes apenas quando o anfitrião recebido corresponde à regra que o proxy carregou efetivamente.
Corrija uma correspondência de anfitrião incompleta ou incorreta antes de ajustar a prioridade. Aumentar a prioridade de uma regra que nunca corresponde apenas torna a configuração mais difícil de compreender.
Compare a prioridade da rota com a rota abrangente
Nos proxies que suportam prioridades explícitas ou derivadas, verifique qual regra ganha quando tanto o anfitrião específico como o fallback abrangente podem corresponder ao mesmo pedido. Registe a regra avaliada, não apenas a ordem no ficheiro de configuração.
Um exemplo de rota abrangente do Traefik atribui deliberadamente ao fallback uma prioridade inferior às rotas reais, para que os serviços específicos sejam avaliados primeiro.
Coloque o fallback abaixo de todas as rotas de aplicações pretendidas e teste novamente. Não resolva o problema atribuindo números arbitrariamente elevados a todos os routers; mantenha um esquema de prioridades simples e documentado que suporte futuras adições de aplicações.
Inspecione o servidor predefinido em proxies do tipo Nginx
Em configurações Nginx e semelhantes, determine qual bloco de servidor se torna predefinido para esse endereço e porta de escuta quando não é encontrada nenhuma correspondência de nome de anfitrião. O primeiro bloco carregado pode tornar-se o fallback se não existir um servidor predefinido explícito.
Um artigo dedicado à resolução de problemas do Nginx explica por que motivo os anfitriões sem correspondência chegam aos servidores predefinidos em vez de serem rejeitados silenciosamente.
Utilize uma resposta predefinida neutra ou um serviço de erro, em vez de tornar uma aplicação real no fallback. Assim, um nome de anfitrião desconhecido ou escrito incorretamente não poderá expor acidentalmente outra aplicação autoalojada.
Verifique separadamente os fallbacks HTTP e HTTPS
Uma rota abrangente adicionada à porta 80 não se comporta automaticamente da mesma forma na porta 443. O encaminhamento TLS, o SNI, pontos de entrada separados ou uma segunda rota abrangente podem fazer com que apenas os pedidos HTTPS cheguem à aplicação errada.
Um caso de resolução de problemas do Caddy descreve uma rota abrangente com comportamento diferente consoante o esquema e mostra por que motivo é necessário testar diretamente a rota específica de cada esquema.
Faça pedidos HTTP e HTTPS com o mesmo nome de anfitrião e registe o handler selecionado. Corrija o fallback no ponto de entrada afetado, em vez de alterar o caminho de protocolo que está a funcionar.
Mantenha o fallback neutro e teste novamente todos os domínios conhecidos
Depois de corrigir o âmbito da correspondência ou a prioridade, faça com que o fallback devolva um erro 404, 421 ou uma página de erro controlada e neutra, em vez de encaminhar todos os nomes de anfitrião desconhecidos para uma aplicação de produção. Em seguida, teste uma vez cada domínio autoalojado conhecido.
Uma visão geral da arquitetura de proxies inversos salienta que o proxy decide o backend depois de o pedido chegar ao proxy, razão pela qual a correção do DNS, por si só, não comprova a correção do encaminhamento.
A correção está concluída quando cada nome de anfitrião conhecido chega à aplicação pretendida e um nome de anfitrião desconhecido chega apenas ao fallback neutro. O artigo relacionado da ZimaSpace sobre um proxy inverso que redireciona para outro domínio é o passo seguinte quando o proxy seleciona o backend correto, mas a aplicação altera posteriormente os domínios.
Perguntas frequentes
O DNS pode fazer com que uma rota abrangente ganhe?
O DNS pode enviar o pedido para o IP de proxy errado, mas, assim que o proxy correto recebe o nome de anfitrião pretendido, a correspondência da rota é uma decisão do proxy. Verifique ambas as camadas separadamente.
O fallback abrangente deve encaminhar para uma aplicação de painel?
Normalmente, não. Um destino de erro neutro é mais seguro, porque os erros de escrita e os nomes de anfitrião desconhecidos não poderão expor acidentalmente uma aplicação real de administração ou multimédia.
Por que motivo apenas o HTTPS chega à aplicação errada?
O HTTPS pode utilizar um listener, um caminho SNI, um site de certificado ou uma regra de fallback diferente do HTTP. Teste ambos os pontos de entrada de forma independente antes de alterar o encaminhamento global.
Produtos recomendados
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...
