Почему прокси-контейнер не использует DNS-контейнер автоматически

Запуск прокси и DNS-сервера на одном хосте Docker не связывает их DNS-пути. Важны три отдельные связи:

• Сетевая доступность. Отдельные проекты Compose обычно имеют отдельные сети по умолчанию. Разместите сервисы в подходящей общей сети — либо внутри одного проекта, либо через сеть, явно общую для проектов.
• Обнаружение сервисов. Встроенный DNS пользовательской сети Docker умеет разрешать имена контейнеров. Это позволяет приложению обнаружить соседа; но не выбирает этого соседа автоматически в качестве своего DNS-резолвера.
• Выбор резолвера. Определите резолвер, используемый внутри прокси-контейнера. Поле dns в Compose принимает адреса DNS-серверов. Имя вроде dns.local, разрешаемое в приложении, не делает его допустимым значением для этого поля.

Проследите запрос от прокси-контейнера до настроенного адреса резолвера. Подтвердите, что по этому адресу есть маршрут и слушатель DNS. Публикация порта 53 хоста создаёт путь доступа со стороны хоста; но не сообщает контейнерам, что его нужно использовать. Контейнеры, разделяющие сеть, могут вместо этого общаться напрямую.

Если конфигурация ссылается на адрес DNS-контейнера, держите его стабильным при совместимой конфигурации IPAM. Динамически выданный адрес, скопированный из вчерашнего контейнера, может не сработать при пересоздании. Проверьте и вышестоящий путь резолвера: пересылка неотвеченных запросов обратно ему самому создаёт отказ, отличный от недоступного резолвера.

Наконец, определите, кто разрешает адрес назначения. HTTP-прокси, разрешающий имя CONNECT, может использовать этот путь через контейнер; SOCKS-клиент, разрешающий локально, возможно, нет. Поиск на хосте доказывает маршрут хоста, а не процесса прокси.