Как диагностировать, что контейнер не может установить соединение с внешним сервисом, если проблема не в самом приложении, а в сетевой настройке Docker (DNS, firewall, MTU)?

Короткий ответ

Диагностику ведут последовательно: сначала проверяют DNS-резолв внутри контейнера и конфигурацию встроенного Docker DNS (127.0.0.11), затем правила iptables на хосте (цепочка DOCKER), и отдельно — параметр MTU сети, который часто является причиной обрывов соединений именно в overlay/VPN-окружениях.

Как это работает подробнее

контейнер по умолчанию использует встроенный DNS-резолвер Docker, который проксирует запросы либо к DNS-серверам хоста, либо резолвит имена других контейнеров в той же пользовательской сети; сбой на этом уровне проявляется как ошибка резолва конкретного имени при рабочей сети в целом. Отдельно от DNS, Docker управляет сетевой связностью через динамически создаваемые правила iptables (цепочки DOCKER, DOCKER-USER и др.) — их конфликт с другими правилами файрвола хоста может блокировать исходящий или входящий трафик контейнера. Третий слой — несовпадение MTU между виртуальным сетевым интерфейсом контейнера/сети Docker и реальным сетевым путём (особенно при VPN или overlay-сетях между хостами), что проявляется как успешное установление соединения, но обрывы на крупных пакетах.

Пример кода

Пример конфигурацииКопировать

$ docker exec -it app sh -c "cat /etc/resolv.conf; nslookup api.example.com"
nameserver 127.0.0.11
Name:      api.example.com
Address 1: 93.184.216.34
$ docker exec -it app sh -c "curl -v --max-time 5 https://api.example.com"
* Connected to api.example.com (93.184.216.34) port 443
* TLS handshake failed: timeout

Что использовать на практике

• Практика. диагностику начинают с внутренней проверки (nslookup/getent hosts, curl -v), затем переходят на хост (iptables -L -n, tcpdump на соответствующем bridge-интерфейсе), и только затем проверяют MTU (ip link show docker0, тестовые пакеты большого размера через ping -M do -s SIZE).

Подводные камни

• Риск. сразу подозревают код приложения при сетевых проблемах, хотя симптом ("connection refused"/таймаут только для определённых размеров пакетов") явно сетевой; меняют правила iptables вручную без понимания, что Docker сам управляет значительной частью своих цепочек и может перезаписать изменения при перезапуске демона.