Inilathala ng Docker ang port. Nakikinig ba ang proxy doon?
Suriin ang listener sa loob ng proxy container at ang host port mapping ng Docker kapag tinatanggihan o nire-reset ang mga koneksyon.
Ang inilathalang Docker port ay nagbibigay ng daan patungo sa endpoint sa loob ng container. Hindi nito sinisimulan ang proxy at hindi binabago ang address kung saan nakikinig ang prosesong iyon.
Para sa karaniwang bridge-network mapping, ihambing ang tatlong value na ito:
| Bahagi ng daan | Value na susuriin |
|---|---|
| Pasukan ng kliyente | Ang host address at inilathalang port na kinokontak ng kliyente |
| Puntahan ng pagpapasa | Ang container address at port na pinipili ng mapping |
| Serbisyo | Ang address at port na aktuwal na iginagapos ng proxy sa loob ng container |
Ang proxy na nakagapos lamang sa 127.0.0.1 sa loob ng container ay maaaring hindi makatanggap ng trapikong ipinapasa sa address ng network nito. Iba ito sa paglalathala ng host port sa loopback lamang ng host: nililimitahan nito kung sino ang makakaabot sa mapping, samantalang ang loopback ng container ay maaaring humadlang sa mapping na maabot ang serbisyo.
Piliin ang panloob na listener para sa inilaan na deployment habang pinapanatili ang limitadong paglalathala ng host at pag-access sa proxy. Ang deklarasyon ng nakalantad na port sa Dockerfile ay hindi nagsisimula ng serbisyo, at ang matagumpay na paglunsad ng container ay hindi nagpapatunay na nakikinig ang proseso sa puntahan ng pagpapasa.
Sundan kung gaano kalayo ang naaabot ng nabigong koneksyon. Nag-iiba ang mga pagtanggi at pag-reset ayon sa platform at implementasyon ng pagpapasa, kaya wala sa dalawa ang natatanging tumutukoy sa isang setting. Kapag naabot nito ang serbisyo, maghanap ng wastong pagbati ng proxy at ilapat ang kinakailangang bersyon ng SOCKS, pagpapatotoo at patakaran sa destinasyon. Ang isang maaabot na host port lamang ay hindi makapagpapatunay ng mga kakayahang iyon.