O Docker publicou a porta. O proxy está à escuta ali?
Verifique o ouvinte dentro de um contêiner de proxy e o mapeamento de porta do host no Docker quando as conexões são recusadas ou redefinidas.
Uma porta Docker publicada fornece um caminho até um endpoint no contêiner. Ela não inicia o proxy nem altera o endereço em que esse processo escuta.
Para um mapeamento típico em rede bridge, compare estes três valores:
| Parte do caminho | Valor a inspecionar |
|---|---|
| Entrada do cliente | O endereço do host e a porta publicada que o cliente contata |
| Destino do encaminhamento | O endereço do contêiner e a porta selecionados pelo mapeamento |
| Serviço | O endereço e a porta que o proxy realmente associa dentro do contêiner |
Um proxy associado apenas a 127.0.0.1 dentro do contêiner pode não receber o tráfego encaminhado para o seu endereço de rede. Isso difere de publicar uma porta do host apenas no loopback do host: isso restringe quem pode alcançar o mapeamento, enquanto o loopback do contêiner pode impedir que o mapeamento alcance o serviço.
Escolha o ouvinte interno para a implantação pretendida, preservando a publicação restrita do host e o acesso ao proxy. A declaração de porta exposta de um Dockerfile não inicia um serviço, e uma inicialização bem-sucedida do contêiner não estabelece que o processo está à escuta no destino do encaminhamento.
Acompanhe até onde chega uma conexão com falha. Recusas e redefinições variam conforme a plataforma e a implementação do encaminhamento, portanto nenhuma das duas identifica sozinha um ajuste. Ao chegar ao serviço, procure uma saudação de proxy válida e aplique a versão de SOCKS, a autenticação e a política de destino exigidas. Só uma porta do host acessível não pode estabelecer essas capacidades.