Docker publiceerde de poort. Luistert de proxy daar?
Controleer de listener in een proxycontainer en de host-poorttoewijzing van Docker wanneer verbindingen worden geweigerd of gereset.
Een gepubliceerde Docker-poort biedt een pad naar een eindpunt in de container. Hij start de proxy niet en verandert niet het adres waarop dat proces luistert.
Vergelijk voor een typische bridge-netwerktoewijzing deze drie waarden:
| Deel van het pad | Te inspecteren waarde |
|---|---|
| Klantingang | Het hostadres en de gepubliceerde poort die de client benadert |
| Doorstuurdoel | Het containeradres en de poort die de toewijzing kiest |
| Dienst | Het adres en de poort die de proxy daadwerkelijk in de container bindt |
Een proxy die in de container alleen aan 127.0.0.1 is gebonden, ontvangt mogelijk geen verkeer dat naar zijn netwerkadres wordt doorgestuurd. Dit verschilt van het publiceren van een hostpoort alleen op de loopback van de host: dat beperkt wie de toewijzing kan bereiken, terwijl container-loopback kan verhinderen dat de toewijzing de dienst bereikt.
Kies de interne listener voor de beoogde uitrol en behoud beperkte hostpublicatie en proxytoegang. De declaratie van een blootgestelde poort in een Dockerfile start geen dienst, en een geslaagde containerstart bewijst niet dat het proces op het doorstuurdoel luistert.
Volg hoe ver een mislukte verbinding komt. Weigeringen en resets verschillen per platform en doorstuurimplementatie, dus geen van beide identificeert een instelling eenduidig. Zodra deze de dienst bereikt, zoek naar een geldige proxybegroeting en pas de vereiste SOCKS-versie, authenticatie en bestemmingsbeleid toe. Een alleen bereikbare hostpoort kan die mogelijkheden niet vaststellen.