Docker publicerede porten. Lytter proxyen der?
Kontroller lytteren inde i en proxy-container samt Dockers værtsportmapping, når forbindelser afvises eller nulstilles.
En publiceret Docker-port giver en vej til et endepunkt i containeren. Den starter ikke proxyen og ændrer ikke den adresse, som processen lytter på.
For en typisk bro-netværksmapping skal du sammenligne disse tre værdier:
| Del af vejen | Værdi at undersøge |
|---|---|
| Klientindgang | Værtsadressen og den publicerede port, som klienten kontakter |
| Videresendelsesmål | Containeradressen og porten, som mappingen vælger |
| Tjeneste | Den adresse og port, som proxyen faktisk binder inde i containeren |
En proxy, der kun er bundet til 127.0.0.1 inde i containeren, modtager muligvis ikke trafik videresendt til dens netværksadresse. Det adskiller sig fra at publicere en værtsport kun på værts-loopback: det begrænser, hvem der kan nå mappingen, mens container-loopback kan forhindre mappingen i at nå tjenesten.
Vælg den interne lytter til den tilsigtede udrulning, mens begrænset værtspublicering og proxyadgang bevares. En Dockerfile-erklæring om eksponeret port starter ikke en tjeneste, og en vellykket containerstart beviser ikke, at processen lytter på videresendelsesmålet.
Følg, hvor langt en mislykket forbindelse når. Afvisninger og nulstillinger varierer med platformen og videresendelsesimplementeringen, så ingen af dem identificerer en indstilling entydigt. Når den når tjenesten, skal du lede efter en gyldig proxy-hilsen og anvende den krævede SOCKS-version, godkendelse og destinationspolitik. En tilgængelig værtsport alene kan ikke fastslå disse egenskaber.