Docker bridge MTU: настройка сети контейнеров

Что важно понять до начала

Пользовательские bridge-сети поддерживают driver options, включая MTU интерфейсов контейнеров. MTU должен учитывать накладные расходы VPN/overlay-туннеля ниже по пути. Изменение MTU действует на созданную сеть; существующие сети обычно проще пересоздать после плановой остановки сервисов. Проверка должна включать реальный проблемный маршрут, а не только localhost.

Совет: Практический ориентир: Характерный признак — часть соединений работает, а передача больших пакетов или TLS-сессии зависают. Подтверждайте тестами path MTU.

Пошаговый порядок действий

1. 1. Зафиксируйте симптомы и сравните работу маленьких и крупных пакетов/ответов.
2. 2. Определите рабочий MTU для внешнего пути или VPN.
3. 3. Создайте тестовую user-defined bridge-сеть с соответствующей driver option MTU.
4. 4. Подключите один тестовый контейнер и повторите проблемный запрос.
5. 5. Только после подтверждения перенесите сервисы на новую сеть в контролируемое окно.

Важно: Критично для этой задачи: Не ставьте произвольно очень маленький MTU: это увеличивает накладные расходы и может лишь замаскировать ошибку сетевого дизайна.

Ошибки и пограничные случаи

Не ставьте произвольно очень маленький MTU: это увеличивает накладные расходы и может лишь замаскировать ошибку сетевого дизайна. При Docker Desktop, корпоративном VPN и облачных туннелях путь может включать несколько уровней encapsulation; ищите минимальный MTU именно по фактическому маршруту.

Предупреждение: Пограничный случай: Не обязательно: разные user-defined networks могут обслуживать разные маршруты и требования.

Проверка перед завершением

• Зафиксируйте симптомы и сравните работу маленьких и крупных пакетов/ответов.
• Создайте тестовую user-defined bridge-сеть с соответствующей driver option MTU.
• Только после подтверждения перенесите сервисы на новую сеть в контролируемое окно.
• Проверено отдельно: Характерный признак — часть соединений работает, а передача больших пакетов или TLS-сессии зависают. Подтверждайте тестами path MTU.

Практический сценарий и контроль результата

MTU меняйте только после воспроизводимого сетевого симптома. Для path‑MTU проблемы характерно, что короткие запросы проходят, а крупные ответы, TLS или загрузка зависают на одном и том же маршруте. Создайте отдельную тестовую bridge‑сеть с новым значением и подключите один контейнер, не меняя всю инфраструктуру сразу. Если проблема исчезла, переносите сервисы планово. Если нет — верните исходный MTU и ищите firewall, VPN или маршрутизацию: слишком маленькое значение само по себе не исправляет неверный сетевой путь.

Дополнительные нюансы и проверка

После выбора тестового MTU повторите именно тот запрос, который раньше ломался: загрузку большого файла, TLS‑соединение или обращение через VPN. Успешный ping маленького размера недостаточен. Если проблема исчезает только при сильно уменьшенном MTU, проверьте, не скрывается ли ниже неправильная настройка туннеля. Значение должно соответствовать реальному пути, а не быть «чем меньше, тем надёжнее». Для нескольких сетей Docker допустимо использовать разные значения, если маршруты действительно отличаются. Зафиксируйте исходный MTU и рабочий тест до переноса сервисов. Тогда возврат на старую сеть займёт один контролируемый шаг.

Что учитывать

Пользовательские bridge-сети поддерживают driver options, включая MTU интерфейсов контейнеров. MTU должен учитывать накладные расходы VPN/overlay-туннеля ниже по пути. Изменение MTU действует на созданную сеть; существующие сети обычно проще пересоздать после плановой остановки сервисов. Проверка должна включать реальный проблемный маршрут, а не только localhost.

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Bridge network driver). Пример и формулировки — редакция N1RO на 2026-09-22.

• Bridge network driver