Docker publicerade porten. Lyssnar proxyn där?
Kontrollera lyssnaren inuti en proxycontainer samt Dockers värdportsmappning när anslutningar nekas eller återställs.
En publicerad Docker-port ger en väg till en slutpunkt i containern. Den startar inte proxyn och ändrar inte adressen som processen lyssnar på.
För en typisk bryggnätverksmappning, jämför dessa tre värden:
| Del av vägen | Värde att undersöka |
|---|---|
| Klientens ingång | Värdadressen och den publicerade porten som klienten kontaktar |
| Vidarebefordringsmål | Containeradressen och porten som mappningen väljer |
| Tjänst | Adressen och porten som proxyn faktiskt binder inuti containern |
En proxy som bara är bunden till 127.0.0.1 inuti containern tar kanske inte emot trafik som vidarebefordras till dess nätverksadress. Det skiljer sig från att publicera en värdport bara på värdens loopback: det begränsar vem som kan nå mappningen, medan container-loopback kan hindra mappningen från att nå tjänsten.
Välj den interna lyssnaren för den avsedda driftsättningen och behåll begränsad värdpublicering och proxyåtkomst. En Dockerfile-deklaration om exponerad port startar ingen tjänst, och en lyckad containerstart bevisar inte att processen lyssnar på vidarebefordringsmålet.
Följ hur långt en misslyckad anslutning kommer. Avvisanden och återställningar varierar med plattformen och vidarebefordringsimplementationen, så ingen av dem identifierar en inställning entydigt. När den når tjänsten, leta efter en giltig proxyhälsning och tillämpa den SOCKS-version, autentisering och destinationspolicy som krävs. Enbart en nåbar värdport kan inte fastställa dessa förmågor.