Docker опубликовал порт. Слушает ли прокси там?
Проверьте слушателя внутри контейнера прокси и сопоставление порта хоста в Docker, когда соединения отклоняются или сбрасываются.
Опубликованный порт Docker даёт путь к конечной точке в контейнере. Он не запускает прокси и не меняет адрес, на котором слушает этот процесс.
Для типичного сопоставления в сети bridge сравните эти три значения:
| Часть пути | Проверяемое значение |
|---|---|
| Вход клиента | Адрес хоста и опубликованный порт, к которым обращается клиент |
| Цель перенаправления | Адрес контейнера и порт, выбираемые сопоставлением |
| Служба | Адрес и порт, которые прокси фактически привязывает внутри контейнера |
Прокси, привязанный внутри контейнера только к 127.0.0.1, может не получать трафик, перенаправленный на его сетевой адрес. Это отличается от публикации порта хоста только на loopback хоста: то ограничивает, кто может достичь сопоставления, а loopback контейнера может помешать сопоставлению достичь службы.
Выберите внутренний слушатель для предполагаемого развёртывания, сохранив ограниченную публикацию хоста и доступ к прокси. Объявление открытого порта в Dockerfile не запускает службу, а успешный запуск контейнера не доказывает, что процесс слушает на цели перенаправления.
Проследите, как далеко доходит неудачное соединение. Отказы и сбросы зависят от платформы и реализации перенаправления, поэтому ни один из них однозначно не указывает на настройку. Когда оно доходит до службы, ищите корректное приветствие прокси и применяйте требуемую версию SOCKS, аутентификацию и политику назначения. Один лишь доступный порт хоста не может подтвердить эти возможности.