Docker a publié le port. Le proxy y écoute-t-il ?
Vérifiez l'écouteur dans un conteneur proxy ainsi que le mappage de port hôte de Docker lorsque les connexions sont refusées ou réinitialisées.
Un port Docker publié fournit un chemin vers un point de terminaison dans le conteneur. Il ne démarre pas le proxy et ne change pas l'adresse sur laquelle ce processus écoute.
Pour un mappage typique en réseau pont, comparez ces trois valeurs :
| Partie du chemin | Valeur à inspecter |
|---|---|
| Entrée client | L'adresse de l'hôte et le port publié que le client contacte |
| Cible de transfert | L'adresse du conteneur et le port choisis par le mappage |
| Service | L'adresse et le port que le proxy lie réellement dans le conteneur |
Un proxy lié uniquement à 127.0.0.1 dans le conteneur peut ne pas recevoir le trafic transféré vers son adresse réseau. Cela diffère de la publication d'un port hôte uniquement sur la loopback de l'hôte : celle-ci limite qui peut atteindre le mappage, tandis que la loopback du conteneur peut empêcher le mappage d'atteindre le service.
Choisissez l'écouteur interne adapté au déploiement prévu tout en préservant une publication d'hôte restreinte et l'accès au proxy. La déclaration de port exposé d'un Dockerfile ne démarre aucun service, et un démarrage réussi du conteneur n'établit pas que le processus écoute à la cible de transfert.
Suivez jusqu'où va une connexion échouée. Les refus et les réinitialisations varient selon la plateforme et l'implémentation du transfert, donc aucun des deux n'identifie à lui seul un réglage. Une fois qu'elle atteint le service, recherchez un salut de proxy valide et appliquez la version SOCKS, l'authentification et la politique de destination requises. Un port hôte accessible ne suffit pas à établir ces capacités.