Docker го објави портот. Дали проксито слуша таму?
Проверете го слушателот внатре во контејнерот на проксито и мапирањето на хост портот во Docker кога врските се одбиваат или ресетираат.
Објавениот Docker порт обезбедува пат до крајната точка во контејнерот. Тој не го стартува проксито и не ја менува адресата на која слуша тој процес.
За типично мапирање на мостова мрежа, споредете ги овие три вредности:
| Дел од патот | Вредност за проверка |
|---|---|
| Влез на клиентот | Адресата на хостот и објавениот порт што ги контактира клиентот |
| Цел на препраќање | Адресата на контејнерот и портот што ги избира мапирањето |
| Услуга | Адресата и портот што проксито всушност ги врзува внатре во контејнерот |
Прокси врзано само на 127.0.0.1 внатре во контејнерот може да не прима сообраќај препратен до неговата мрежна адреса. Ова се разликува од објавување на хост порт само на loopback на хостот: тоа ограничува кој може да стигне до мапирањето, додека loopback на контејнерот може да спречи мапирањето да стигне до услугата.
Изберете го внатрешниот слушател за предвиденото распоредување, задржувајќи го ограниченото објавување на хостот и пристапот до проксито. Декларацијата за отворен порт во Dockerfile не стартува услуга, а успешното стартување на контејнерот не докажува дека процесот слуша на целта на препраќањето.
Следете колку далеку стигнува неуспешна врска. Одбивањата и ресетирањата се разликуваат според платформата и имплементацијата на препраќањето, така што ниту едно не идентификува поставка единствено. Кога ќе стигне до услугата, побарајте валиден поздрав од прокси и примените ја потребната SOCKS верзија, автентикација и политика на дестинација. Само достапен хост порт не може да ги докаже тие можности.