Документы · Инструкция
Host network или bridge в Docker: чем отличаются сетевые режимы
Host network и bridge в Docker решают одну задачу подключения контейнера к сети, но дают разную модель изоляции.
Короткий ответ
Bridge оставляет контейнер в отдельном сетевом пространстве и обычно открывает нужные порты через `-p`. Host network делит сетевой namespace с хостом: отдельного container IP в этом режиме нет, а публикация портов игнорируется, поэтому host стоит выбирать только при конкретной технической необходимости.
Что даёт bridge mode
В bridge-сети контейнер получает отдельное сетевое пространство относительно хоста. Для внешнего доступа обычно используется `-p hostPort:containerPort`; это позволяет приложению слушать привычный порт внутри контейнера, а на хосте выбрать другой. Пользовательские bridge networks также дают DNS-разрешение имён контейнеров между участниками одной сети. Такая модель удобна для большинства веб-приложений и БД, потому что граница экспозиции видна в конфигурации: внутренний сервис может остаться вообще без опубликованного порта, а публичный — открыть только то, что действительно нужно.
Совет: Для локального сервиса публикуйте порт на `127.0.0.1`, а не на все интерфейсы, если внешний доступ не требуется.
Что меняется при `--network host`
В host mode контейнер использует сетевой namespace хоста и не получает отдельный IP так, как в bridge-сети. Docker прямо указывает, что `-p`, `--publish` и `-P` в этом режиме игнорируются: если процесс внутри контейнера слушает 80/tcp, он занимает порт 80 самого хоста. Это уменьшает необходимость NAT и может быть полезно для приложений, которые работают с большим диапазоном портов, но одновременно повышает риск конфликтов. Второй процесс на том же адресе и порту уже не запустится.
Предупреждение: Не добавляйте `-p` к host mode «для безопасности»: mapping не создаётся и не переназначает порт.
Изоляция и безопасность
Bridge не является абсолютной security boundary сам по себе, но он даёт более явное сетевое разделение и контроль опубликованных портов. Host mode эту границу уменьшает: приложение контейнера взаимодействует с сетевым стеком хоста напрямую, поэтому особенно важно проверить firewall, listening sockets и права самого процесса. Если контейнер запускает неожиданный listener, он появляется на хосте без привычного port mapping. Перед переходом на host mode нужно точно знать, какие порты открывает приложение и на каких интерфейсах оно bindится.
Важно: Host networking следует выбирать по измеримой необходимости, а не просто «чтобы было быстрее».
Docker Desktop и переносимость
Docker указывает поддержку host networking в Docker Desktop 4.34+ при включении соответствующей функции, но переносимость конфигурации между Desktop, CI и Linux Engine всё равно нужно проверять. Bridge обычно даёт более предсказуемую разработческую среду, потому что port mapping одинаково виден в Compose и документации. Если проект действительно зависит от host mode, зафиксируйте эту причину рядом с конфигурацией и добавьте тест занятых портов. Иначе следующий разработчик может случайно заменить host на bridge или наоборот и получить труднообъяснимые сетевые ошибки.
Диагностика сетевых проблем после смены bridge на host
После перехода на host mode часто кажется, что контейнер «потерял порт mapping», хотя Docker работает именно так, как описано в документации: `-p` больше не участвует. Начните с `ss` или аналогичного инструмента на хосте и проверьте, на каком адресе реально слушает процесс — `127.0.0.1`, конкретном интерфейсе или `0.0.0.0`. Затем сопоставьте это с firewall и маршрутизацией. Если сервис внезапно недоступен извне, проблема может быть не в Docker, а в том, что приложение bindится только на loopback. Если контейнер не запускается, проверьте конфликт порта с системным nginx, другим контейнером или локальной БД. При возврате к bridge не забудьте снова описать опубликованные порты и зависимости между контейнерами через пользовательскую сеть. Для сервисов, которые должны общаться по DNS-имени внутри Compose, bridge обычно удобнее: host mode переносит больше сетевой логики на хост и снижает переносимость конфигурации между машинами. Отдельно документируйте открытые порты на самом хосте: в host mode граница между сетевой экспозицией контейнера и операционной системы становится менее заметной при аудите.
Как выбрать режим по реальным требованиям сервиса
Для большинства web-приложений безопаснее начинать с user-defined bridge: контейнер получает отдельную Docker-сеть, сервисы в ней могут разрешать друг друга по имени, а наружу публикуются только необходимые порты. Host mode оправдан, когда процессу действительно нужен сетевой стек хоста или большой диапазон портов и вы понимаете цену такой модели. У host networking публикация `-p/--publish` не действует: Docker прямо предупреждает, что published ports отбрасываются, потому что контейнер использует сеть хоста. Отсюда следует практический тест перед миграцией: выпишите все `ports:` в Compose, проверьте, какие процессы уже слушают те же host-порты, и заранее решите конфликт. На Docker Desktop учитывайте отдельное условие — host networking поддерживается с версии 4.34 и включается как opt-in функция; также поддерживаются только Linux containers. Если приложение должно одинаково работать на Linux-сервере, ноутбуке разработчика и CI, bridge обычно даёт меньше платформенных сюрпризов. Если же вы выбираете host из-за производительности, измерьте latency/throughput до и после: сам факт отсутствия NAT ещё не доказывает, что именно сеть была узким местом. Для сервисов, которым нужно общаться друг с другом по именам, user-defined bridge даёт встроенное DNS-разрешение между контейнерами. В host mode этот слой Docker-сети исчезает, поэтому зависимости, которые раньше обращались к соседнему контейнеру по service name, нужно проверить отдельно. Особенно это заметно при переносе Compose-стека: сетевой режим меняет не только входящие порты, но и способ адресации соседних компонентов.
Пошаговый порядок действий
- Опишите входящие/исходящие соединения и нужные порты.
- Если хватает нескольких опубликованных портов, начните с bridge.
- Переходите к host только ради конкретной причины: широкий диапазон портов, low-level networking или измеримый overhead.
- Проверьте занятые порты и firewall хоста.
- После запуска проверьте фактические listening sockets, а не только `docker ps`.
Краткая таблица
- Сетевой namespace. отдельный. общий с хостом
- Отдельный IP. есть внутри Docker-сети. нет отдельного IP host mode
- `-p` mapping. работает. игнорируется
- Конфликт портов. можно переназначать. прямая конкуренция за порт хоста
- Типичный сценарий. большинство приложений. специальные networking-задачи
Контрольный список
- не ожидать port mapping в host mode
- проверить firewall
- исключить конфликт портов
- измерить необходимость host
- проверить переносимость Desktop/Linux
Что учитывать
Условия меняются. Страница отражает состояние на 2026-09-20; при расхождении с официальной документацией приоритет у первоисточника.
Источники и проверка
Фактическая часть сверена по первичным источникам (в т.ч. Host network driver). Пример и формулировки — редакция N1RO на 2026-09-20.