Docker Error: net/http: TLS handshake timeout — Устранение сбоя сети
Сетевой стек демона Docker и причины сбоя TLS Handshake
Ошибка Error response from daemon: net/http: TLS handshake timeout генерируется сетевым клиентом Golang внутри демона dockerd при попытке установить защищенное соединение с реестром. Сбой возникает на фазе согласования параметров шифрования TLS (Client Hello -> Server Hello). Основные технические причины: несоответствие размера MTU (Path MTU Discovery failure), фрагментация пакетов, блокировки DPI/фаервола, нестабильные DNS-серверы хоста или сетевые задержки при прохождении корпоративного прокси.
Бизнес-риски:
Полная изоляция хоста от реестров образов, невозможность обновления критических патчей безопасности контейнеров, деградация деплойментов.
Таблица параметров сетевой диагностики TLS
| Параметр | Рекомендуемое значение | Диагностируемая проблема |
|---|---|---|
MTU (dockerd) | 1450 или 1400 (при VPN/VXLAN) | Дроп фрагментированных пакетов TCP/TLS при оверхеде инкапсуляции. |
DNS Nameservers | 8.8.8.8, 1.1.1.1, локальный DNS | Медленный резолв CNAME записей CDN-серверов Docker Hub (Cloudflare). |
HTTP_PROXY / HTTPS_PROXY | Корректный URL прокси | Зависание сессии при попытке прямого выхода в изолированных сетях. |
Пошаговое восстановление сетевого соединения с реестром
Сценарий 1: Коррекция размера MTU в конфигурации Docker
Если хост находится за VPN (WireGuard, IPsec) или в облаке с оверлеем (OpenStack/VxLAN), стандартный MTU 1500 приводит к потере пакетов:
# Конфигурация MTU и DNS в /etc/docker/daemon.json
{
'mtu': 1400,
'dns': ['1.1.1.1', '8.8.8.8']
}
# Применение настроек демона
systemctl restart dockerСценарий 2: Настройка корпоративного HTTP/HTTPS Proxy для Systemd
Демон Docker управляется через systemd и игнорирует стандартные переменные окружения пользователя:
# Создание каталога конфигурации systemd drop-in
mkdir -p /etc/systemd/system/docker.service.d
# Добавление параметров прокси в /etc/systemd/system/docker.service.d/http-proxy.conf
[Service]
Environment='HTTP_PROXY=http://proxy.company.local:3128'
Environment='HTTPS_PROXY=http://proxy.company.local:3128'
Environment='NO_PROXY=localhost,127.0.0.1,*.internal.domain,10.0.0.0/8'
# Перезагрузка демона systemd и перезапуск Docker
systemctl daemon-reload
systemctl restart dockerСценарий 3: Проверка сквозной доступности через OpenSSL
Протестируйте фазу TLS Handshake вручную без участия Docker:
# Тест прямого TLS-подключения к Docker Hub
openssl s_client -connect registry-1.docker.io:443 -servername registry-1.docker.io -tls1_2
# Трассировка маршрута с фиксацией MTU
traceroute -F registry-1.docker.io 1472Типовые ошибки администраторов
- Прописывание proxy в ~/.bashrc вместо systemd: Команда
docker pullвыполняется демоном dockerd от root через systemd, поэтому пользовательские export PROXY не работают. - Игнорирование корневых сертификатов (CA): При использовании SSL-инспекции (DPI/Zscaler) необходимо добавить корпоративный сертификат в
/etc/docker/certs.d/.
Специалисты ITSTM настроят сетевую инфраструктуру, оптимизируют MTU/BGP-маршрутизацию и обеспечат стабильную связь с реестрами.
Частые вопросы (FAQ)
Почему curl к registry-1.docker.io работает, а docker pull падает по таймауту?
Curl отправляет небольшие пакеты данных. Docker при загрузке слоев передает максимальный размер TLS-пакета (16KB), который фрагментируется и отбрасывается при завышенном MTU.
Как временно проверить работу через другое DNS?
Запустите команду с флагом DNS: docker run --dns 8.8.8.8 alpine ping -c 2 google.com.
Влияет ли системное время сервера на TLS Handshake?
Да, рассинхронизация времени (NTP drift) более чем на несколько минут приводит к невалидности SSL-сертификатов и сбросу TLS-сессии.
Что делать при блокировке Cloudflare IP-адресов провайдером?
Настройте локальное зеркало (registry-mirrors) или используйте корпоративный VPN/прокси с корректной маршрутизацией.