Por que motivo um proxy inverso devolve o erro 502 depois de recriar um contentor?

Um proxy inverso devolve um erro 502 depois de uma reconstrução de um contentor quando já não consegue abrir uma ligação válida ao upstream reconstruído.

A reconstrução pode substituir o contentor, atribuir-lhe um novo endereço, desligar ou mudar o nome de uma rede Docker, alterar a porta exposta, restaurar uma configuração incompleta ou iniciar o proxy antes de a aplicação estar pronta. O diagnóstico correto começa pelo registo de erros do proxy e segue o endereço exato do upstream, do proxy ao contentor, em vez de reiniciar ambos os serviços até o erro desaparecer temporariamente.

Confirme que o erro 502 é causado por uma falha de ligação ao upstream

Faça um pedido uma vez ao domínio afetado e registe o carimbo de data/hora, o estado do proxy, o endereço do upstream e a mensagem de erro completa. Distinga entre ligação recusada, anfitrião não encontrado, tempo limite excedido, ligação reiniciada, falha no handshake TLS e resposta inválida.

Um erro 502 significa que o proxy não recebeu uma resposta utilizável do upstream, mas os detalhes do erro determinam se o destino estava ausente, inacessível, sem nenhuma aplicação à escuta ou a utilizar o protocolo errado. Um guia atual de resolução de problemas do NGINX observa que um contentor reconstruído pode deixar o proxy a utilizar um endereço de backend antigo até a resolução de nomes ou a configuração ser atualizada.

Teste diretamente a aplicação a partir do anfitrião do proxy ou do contentor do proxy, utilizando o nome, endereço, porta e protocolo do upstream registados. Se esse pedido direto falhar da mesma forma, mantenha a investigação entre o proxy e o contentor, em vez de alterar o DNS público ou os certificados.

Compare o destino do upstream antes e depois da reconstrução

Inspecione o nome do contentor reconstruído, o nome do serviço, o IP interno, a porta exposta, a porta publicada, os aliases de rede e as redes associadas. Compare-os com a configuração do proxy e com o último destino que funcionou.

Um problema do nginx-proxy descreve uma reconstrução que alterou o IP do contentor da aplicação, enquanto o proxy continuou a enviar pedidos para o upstream de contentor inacessível. O domínio público continuava correto, tendo mudado apenas a identidade do upstream privado.

Prefira um nome de serviço Compose estável ou um alias de rede em vez de um IP de contentor. Se utilizar intencionalmente um IP fixo, confirme que o serviço reconstruído o recebeu efetivamente e que nenhum outro contentor utiliza agora esse endereço.

Verifique se o proxy e a aplicação continuam na mesma rede Docker

Liste as redes associadas ao proxy e à aplicação e confirme que partilham pelo menos uma rede definida pelo utilizador. Uma porta publicada no anfitrião não torna automaticamente o nome do contentor acessível a partir de outra rede Docker isolada.

Um caso de utilização de redes Docker concluiu que mover um serviço dependente para a rede adequada eliminou imediatamente as respostas 502 recorrentes, demonstrando como um caminho de upstream inacessível pode ocorrer mesmo quando todos os contentores continuam em execução.

Ligue os serviços através do Compose, em vez de utilizar comandos isolados, para que a relação sobreviva às reconstruções. Teste a resolução DNS e a porta do upstream a partir do interior do contentor do proxy depois de recriar a stack.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verifique a porta interna de escuta e o endereço de ligação

Confirme que a aplicação está à escuta na porta utilizada pelo proxy e num endereço acessível a partir da rede dos contentores. Não confunda uma porta publicada no anfitrião com a porta interna de escuta do contentor.

Um proxy só consegue estabelecer ligação depois de a aplicação aceitar ligações para além do loopback. Um serviço à escuta em 127.0.0.1 dentro do seu próprio contentor não está disponível para o proxy, mesmo quando um comando de verificação local é bem-sucedido.

Inspecione o registo da aplicação, a lista de sockets e um pedido direto a partir do contentor do proxy. Se a porta recusar ligações, corrija o listener ou a configuração da aplicação antes de adicionar novas tentativas ou tempos limite mais longos no proxy.

Aguarde pela prontidão da aplicação em vez de apenas pelo arranque do contentor

Um contentor reconstruído pode estar em execução enquanto as migrações, a recuperação da base de dados, o aquecimento da cache ou a geração da configuração ainda impedem a aplicação de aceitar pedidos. Compare o carimbo de data/hora do primeiro erro 502 com os registos de estado e de arranque.

Uma discussão sobre resolução de problemas do Grist mostra como a arquitetura Docker, as definições do ambiente e a prontidão do upstream podem combinar-se e causar falhas 502 persistentes no lado do contentor depois de uma reconstrução.

Adicione uma verificação de estado significativa e faça com que o proxy ou os serviços dependentes aguardem pela operação de que os clientes precisam, não apenas pela existência de um processo. Mantenha as tentativas limitadas para que uma aplicação que falhou permanentemente não pareça estar apenas a arrancar lentamente.

Atualize a resolução do proxy e reconstrua o caminho estável

Recarregue ou recrie o proxy depois de o nome do serviço, a rede, a porta e o estado de saúde estarem corretos. Se o proxy resolver os nomes apenas no arranque, configure a resolução em tempo de execução suportada ou uma ordem de reinício previsível.

O fluxo de trabalho da ZimaSpace para isolar uma dependência de contentor com falhas fornece o diagnóstico complementar quando o upstream sai repetidamente em vez de permanecer saudável.

A reparação só está concluída quando o proxy resolve o nome do serviço depois de outra reconstrução, alcança a porta interna pretendida, aguarda durante o arranque e disponibiliza o domínio sem edições manuais de IP. Remova os destinos temporários de IP direto e as associações de rede não documentadas após a validação.