Docker ネットワークモード選定の実践：bridge・host・overlay の意思決定ガイド

実際の障害から始める

午前 2 時、本番環境の API サービスが突然タイムアウトした。

コンテナは起動しており、docker ps も running、ファイアウォールもオフ、ポートマッピングもきちんと設定済み。コンテナログにもエラーはない。30 分ほど調査して、途方に暮れた。原因は Docker のネットワークモードの選び方——デフォルト bridge を使っていたが、別ノードのデータベースへホスト間アクセスが必要だった。bridge は単機通信しかできず、ホストをまたげない。

この事例は、かなりよくある問題を浮き彫りにする。多くの開発者は Docker に bridge、host、overlay の三つのネットワークモードがあることは知っていても、いつどれを使うべきかわからない。正直、私も最初は同じ轍を踏んだ。

この記事を読めば、三つのネットワークモードの完全な意思決定フローと性能ベンチマーク比較表が手に入る。次にネットワーク問題に直面したら、まず「単機かホスト間か」を判断すれば、当時のように手探りで消耗しなくて済む。

---

Bridge：デフォルトの選択、単機通信の定番

Bridge は Docker のデフォルトネットワークモード。

docker run で --network を指定しなければ、コンテナは自動的にこのモードに接続される。仕組みはシンプルだ。Docker はホスト上に docker0 という仮想ブリッジを作り、各コンテナに独立した IP（通常 172.17.x.x）を割り当て、veth pair（仮想ケーブル）でブリッジに接続する。

抽象的に聞こえるかもしれないが、要するにコンテナを独立した仮想マシンのように扱い、プライベート IP を付け、NAT（ポートマッピング）で外部と通信させるイメージだ。

適用シーン

単一ホスト上のマルチコンテナデプロイなら、Bridge が第一候補。

開発・テスト環境はもちろん、ホスト間通信が不要な本番シーンでも十分使える。シンプルで安全、追加設定も不要。

設定例

デフォルトが Bridge なので、特に指定する必要はない：

# デフォルト bridge、IP 自動割り当て、-p でポートマッピングが必要
docker run -d -p 8080:80 nginx

ただし問題がある。デフォルト bridge ではコンテナ間は IP しか使えず、コンテナ名は使えない。二つのコンテナを起動して相互アクセスしたい場合、毎回 IP を手動で調べる必要があり、面倒だ。

調べ方は docker inspect：

# 二つのコンテナを起動
docker run -d --name web nginx
docker run -d --name db redis

# web コンテナの IP を確認
docker inspect web | grep IPAddress
# 出力：172.17.0.2

# db コンテナ内から web に ping（IP のみ）
docker exec db ping 172.17.0.2

毎回 IP を調べるのは手間だし、コンテナ再起動で IP が変わることもある。

おすすめはカスタム bridge を作成すること：

# カスタムネットワークを作成
docker network create --subnet=192.168.100.0/24 my-net

# コンテナをカスタムネットワークに接続して起動
docker run -d --network my-net --name web nginx
docker run -d --network my-net --name db redis

# web コンテナから db に直接 ping（DNS 自動解決）
docker exec web ping db

こうすればコンテナ名をドメインのように使える。DNS を手動設定する必要があると思っていたが、Docker 標準で対応していて驚いた。

---

Host：性能最優、隔離は最弱

Host モードはやや「荒っぽい」——コンテナがホストのネットワークスタックをそのまま使う。

独立 IP も NAT も veth pair もない。コンテナ内のネットワークインターフェースはホストのものそのもので、性能はネイティブに近く、オーバーヘッドはほぼゼロ。

こう直接的なら性能が最良に違いない——その通りだが、代償として隔離が失われる。

適用シーン

ネットワーク性能に敏感なシーンでは、Host が最適。

ゲームサーバー、リアルタイム通信（WebSocket、動画ストリーム）、高頻度取引システムなど、数十マイクロ秒のレイテンシが重要なアプリに向いている。

ネットワークデバッグにも便利。コンテナ内で tcpdump を実行すれば、ホストのトラフィックを直接キャプチャでき、追加設定不要。

設定例

さらにシンプルで、-p すら不要：

# host モード、コンテナがホストの 80 ポートを直接占有
docker run -d --network host nginx

起動後、ホストの 80 ポートにアクセスすれば、コンテナ内の nginx に届く。

リスクと注意点

いくつか落とし穴がある。

ポート競合：ホストですでに nginx が 80 ポートを占有している状態で、host モードのコンテナも 80 を使おうとすると、起動エラーになる。

エラーメッセージの例：

docker: Error response from daemon: driver failed programming external connectivity on endpoint xxx: Bind for 0.0.0.0:80 failed: port is already allocated.

確認方法はシンプル。まずホストのポート占有を調べる：

# ポート占有を確認
netstat -tuln | grep :80
# または
ss -tuln | grep :80

# プロセスを確認
lsof -i :80

占有プロセスがあれば停止するか、コンテナ側のポートを変更する。Host モードでは -p が使えないので、コンテナ内でアプリ設定を変更する（例：nginx の待ち受けを 8080 に変更）。

セキュリティ：コンテナからホストのすべてのネットワークインターフェース（社内網、インターネット、VPN 接続を含む）が見える。コンテナが侵害されると、攻撃者はホストのすべてのネットワークリソースにアクセスできる。本番環境では慎重に検討すること。

Host モードは使う機会は少ない。大半のシーンでは Bridge で十分だ。性能ボトルネックや低レイテンシが本当に必要なときだけ、隔離の代償を受け入れて Host を検討する価値がある。

---

Overlay：ホスト間通信の正解

Bridge は単機通信のみ、Host は性能が良くてもホストをまたげない。複数サーバー上のコンテナを相互アクセスさせるには Overlay が必要だ。

Overlay ネットワークは VXLAN トンネル技術に基づき、異なるホスト上のコンテナを仮想 LAN にまとめ、同一マシン上にあるかのように通信させる。

コア原理

VXLAN が Overlay の鍵。

コンテナトラフィックの外側にカプセル化を重ね、トンネル経由で別ホストに送り、解カプセル化して対象コンテナに渡す。この処理は VTEP（VXLAN Tunnel Endpoint）が担当し、Docker Swarm では自動管理される。

例えるなら、東京から大阪へ荷物を送るとき、宅配業者が荷物を大きな箱に入れ、物流網で運び、大阪で箱を開けて受取人に渡す。VXLAN が「大きな箱」、コンテナトラフィックが「荷物」、VTEP が梱包・開梱の工程だ。

VXLAN の利点は、物理ネットワークの構成に関わらず、コンテナからは同一仮想 LAN に見え、IP が統一され通信がシンプルになること。

前提がある。Overlay ネットワークには Swarm クラスタ、または外部 KV ストア（Consul など）が必要。単機 Docker では不可で、複数ノードの協調が必須。

Swarm が必要な理由は、Overlay が複数ホストのコンテナ IP、VTEP 接続、ルーティング情報を管理するためで、中心化された調整者が必要だから。Swarm を使わない場合は Consul や Etcd を KV ストアとして使えるが、設定はより複雑になる。

適用シーン

Docker Swarm クラスタでは、Overlay が唯一の選択肢。

Web サービスがノード A、データベースがノード B にあるようなホスト間マイクロサービスデプロイで、Overlay が仮想ネットワークにまとめ、コンテナ名で通信できる。IP 設定は不要。

Kubernetes にも類似の概念（CNI ネットワーク）があるが、設定方法は異なる。主に K8s を使う場合でも、この記事の Overlay 概念は K8s ネットワーク理解の助けになる。

設定例（完全フロー）

Overlay の設定は Bridge や Host より複雑で、先に Swarm を初期化する必要がある：

# 1. 最初のホストで Swarm を初期化
docker swarm init --advertise-addr 192.168.1.10

# join token が出力される、例：
# docker swarm join --token SWMTKN-xxx 192.168.1.10:2377

# 2. 他のホストで Swarm に参加（上記コマンドをコピー）
docker swarm join --token SWMTKN-xxx 192.168.1.10:2377

# 3. Overlay ネットワークを作成
docker network create --driver overlay --subnet=10.0.1.0/24 my-overlay

# 4. 異なるホストでコンテナを起動し、同一 Overlay に参加
# ノード A
docker run -d --network my-overlay --name web nginx

# ノード B
docker run -d --network my-overlay --name db redis

# 5. 通信テスト（web から db に ping、ホスト間！）
docker exec web ping db

初めて Overlay を設定したとき、Swarm 初期化を忘れて overlay ネットワークを作ろうとして “This node is not a swarm manager” エラーになった。Overlay は Swarm 依存だと理解するまで時間がかかった。

もう一つのポイント：--subnet=10.0.1.0/24 は /24 サブネット（256 IP）を推奨。他ネットワークとの競合を避けやすい。大規模クラスタでは /16 も使えるが、IP 範囲は事前に計画すること。

---

性能ベンチマーク比較：データで見る

三つのネットワークモードの性能差はどのくらいか。実測データを整理して直感的に比較する。

コアデータ（72 時間ストレステスト）

CSDN の本番環境実測レポートによると、ストレステストでの各モードの結果は以下のとおり：

主な発見

いくつかの数字が示唆に富む：

Host は Bridge よりかなり速い。平均レイテンシが 128μs から 32μs へ、96μs の差、約 14% の性能向上。スループット面では Host はネイティブに近く、Bridge はおおよそ 80%。秒間数千リクエストを処理するアプリなら、この差は顕著になる。

Bridge の NAT オーバーヘッドは小さくない。CPU 使用率が 0.9 コアから 1.8 コアへ、ほぼ倍増。外部リクエストごとに NAT 変換が入るため、処理が一段増える。

Overlay の VXLAN カプセル化はさらに重い。ホスト間通信でカプセル化・解カプセル化が必要で、レイテンシは Bridge より高く、CPU 使用率も大きい。分散シーン向きで、高性能単機向きではない。

実際への影響

数字だけでは抽象的だが、実シーンでは差が大きい。

高頻度取引ではマイクロ秒単位が勝敗を分ける。Host の 32μs と Bridge の 128μs は、注文が約定するかどうかに直結しうる。一方、通常の Web アプリではユーザー往復レイテンシが数百 ms あるため、数十 μs の差はほぼ無感。

数字だけで判断せず、シーンに合わせること。性能重視なら Host、安全優先なら Bridge、ホスト間必須なら Overlay——性能の代償を受け入れる。

自環境でのテスト方法

自環境で性能差を測りたい場合、いくつかの簡単な方法がある：

レイテンシテスト：ping または iperf3

# コンテナ A からコンテナ B に ping（bridge モード）
docker exec container-a ping container-b

# iperf3 でスループットテスト（先に iperf3 をインストール）
docker exec container-a iperf3 -c container-b

CPU 使用率監視：docker stats

# コンテナの CPU 使用率を確認
docker stats --no-stream

ネットワークトラフィック監視：tcpdump でキャプチャ分析

# ホストのネットワークトラフィックをキャプチャ（host モードは直接キャプチャ）
docker exec -it container-host tcpdump -i eth0

# bridge ネットワークのトラフィックをキャプチャ（ブリッジを指定）
tcpdump -i docker0

本番投入前にストレステストを回し、選んだネットワークモードがトラフィックに耐えられるか確認することをおすすめする。投入後に問題が判明するのは避けたい。

---

意思決定フロー：シーンからモードへ

結局どう選ぶか。シンプルな判断ロジックを示す。

3 ステップの判断フロー

ネットワーク設定に直面したら、このフローに沿って進む：

ステップ 1：ホスト間通信は必要か？

複数コンテナが異なるサーバーに分散し、相互アクセスが必要（Web がノード A、DB がノード B など）なら、ホスト間通信が必須。

• YES → ステップ 2 へ
• NO → ステップ 3 へ

ステップ 2：Swarm を使うか？

ホスト間通信には二つの道がある：Docker Swarm（Overlay）または手動ルーティング設定（Host + iptables）。

• YES → Overlay ネットワーク（最もシンプル、Swarm が自動管理）
• NO → Macvlan または Host + ルーティング設定を検討（複雑、特殊シーン向け）

ステップ 3：ネットワーク性能に敏感か？

アプリがレイテンシ・スループットに敏感（高頻度取引、リアルタイム通信、ゲーム）なら、性能優先。

• YES → Host モード（ただしセキュリティリスクを評価）
• NO → Bridge モード（デフォルトの安全な選択）

シーン別推奨表

より直感的に、よくあるシーンの推奨：

シーン	推奨モード	理由
単機 Web アプリ	Bridge	安全・シンプル、デフォルトで十分
高頻度取引サービス	Host	レイテンシ敏感、性能最優
Swarm マイクロサービスクラスタ	Overlay	ホスト間通信必須
開発・デバッグ環境	Bridge（カスタム）	DNS 対応、コンテナ名通信
完全隔離テスト	None	ネットワークなし、完全隔離

ひとつのアドバイス

最初から「どのモードが最適か」にこだわらないこと。

大半のシーンでは Bridge で足りる。問題が出てから調整すればよい：

• サービスディスカバリが面倒 → カスタム Bridge に切り替え
• 性能が本当に不足 → Host を検討、セキュリティの代償を評価
• ホスト間が必要 → Overlay、VXLAN の性能オーバーヘッドを受け入れる

最初から Host を設定してポート競合やセキュリティホールが出るチームをよく見る。Bridge デフォルトで 90% のシーンは解決できる。過剰最適化は不要。

---

本番環境のベストプラクティス

三つのモードそれぞれに長所短所がある。本番で安定運用するための実践知をまとめる。

Bridge：カスタムネットワーク + DNS

デフォルト bridge の大きな問題は、コンテナ間が IP しか使えず名称で通信できないこと。

本番ではカスタム bridge を推奨：

# カスタムネットワークを作成、サブネット指定（競合回避）
docker network create --subnet=192.168.100.0/24 --name my-app-net

# サービスを起動、カスタムネットワークに接続
docker run -d --network my-app-net --name web-server nginx
docker run -d --network my-app-net --name redis-cache redis

# web-server から redis-cache に直接アクセス（DNS 自動解決）
docker exec web-server ping redis-cache

サービスディスカバリで IP を手動設定する必要がなく、コンテナ名をドメインのように使える。

サブネット計画も重要。デフォルトの 172.17.x.x は社内網と競合しやすい。192.168.100.0/24 や 10.10.10.0/24 を推奨し、事前に運用チームと IP 範囲を調整すること。

Host：セキュリティ強化は必須

Host モードは性能が良い反面、セキュリティが弱い。コンテナからホストのすべてのネットワークインターフェース（社内網、インターネット、VPN）が見える。

本番で Host を使うなら、最低限これを実施：

第一：コンテナ権限を制限。--cap-drop で不要な Linux capabilities を削除。例：CAP_NET_RAW（任意のパケットキャプチャ防止）：

docker run -d --network host --cap-drop NET_RAW nginx

第二：異常トラフィックを監視。突然の大量外部接続や社内敏感インターフェースへのアクセスなど、コンテナのネットワーク行動を監視しアラートを出す。Prometheus + Grafana や専用セキュリティツールが使える。

Host モードは本番で使う機会は少ない。性能ボトルネックが本当にある場合を除き、Bridge + カスタムネットワークで十分なことが多い。

Overlay：サブネットサイズ + Swarm の安定性

Overlay ネットワークの鍵は VXLAN カプセル化で、オーバーヘッドは無視できない。

いくつかの最適化ポイント：

サブネットサイズを制御：/24（256 IP）を推奨。大規模クラスタでは /16（約 6 万 IP）も使えるが、事前計画で競合を避ける。

# 推奨：/24 サブネット
docker network create --driver overlay --subnet=10.0.1.0/24 my-overlay

CPU 使用率を監視：VXLAN カプセル化は CPU オーバーヘッドを増やす。高トラフィックでは特に。docker stats や Prometheus で監視し、CPU が高すぎる場合は MTU 調整やホスト間通信の削減を検討。

Swarm ノード間ネットワークの安定性を優先：Overlay は Swarm に依存し、ノード間ネットワークが不安定だと Overlay も不安定になる。本番で Overlay を使うなら、Swarm ノード間のレイテンシが低くパケットロスが少ないことを確認。社内専用線が理想。

---

まとめ：三つの原則を覚える

結局のところ、三つの原則に集約される：

1. 単機はデフォルト Bridge

90% のシーンでは Bridge で十分。安全・シンプル・すぐ使える。サービスディスカバリが面倒ならカスタム Bridge に切り替え、コンテナ名で通信できる。

2. 性能重視なら Host

レイテンシ・スループットが重要なシーンでは Host が最適。ただし性能最高＝隔離最弱。本番で Host を使うならセキュリティ強化を忘れないこと。

3. ホスト間は Overlay 必須

複数サーバー上のコンテナが相互アクセスするなら、Overlay が正解。Swarm クラスタが前提で、Bridge や Host より設定は複雑だが、ホスト間通信には不可欠。

実践アドバイス

次に Docker ネットワーク問題に直面したら、まず一つ自問する：単機か、ホスト間か？

単機ならデフォルト Bridge。性能不足なら Host を検討、セキュリティの代償を評価。ホスト間なら Overlay、VXLAN の性能オーバーヘッドを受け入れる。

最初から「最適モード」を探さず、Bridge から始めて問題に応じて調整する。私は逆に、先に Overlay を設定して単機シーンでは使い道がなく、無駄に時間を使った。

bridge/host/none/container の基礎原理にまだ慣れていないなら、シリーズ第 11 回「Docker ネットワークモード詳解」を先に読み、基礎を固めてからこの記事の応用編に進むとスムーズだ。

---

参考資料

"Docker には bridge、host、overlay、macvlan など複数のネットワークドライバがあり、各モードは異なるシーンに適している。公式ドキュメントに各モードの設定方法と適用シーンが詳述されている。"

"Overlay ネットワークは VXLAN トンネル技術に基づき、Swarm クラスタまたは外部 KV ストアが必要。ホスト間コンテナ通信に適している。公式ドキュメントに完全な設定フローがある。"

"Swarm ネットワーク管理ガイド。overlay ネットワークの作成、サービスネットワークの管理、ホスト間通信のベストプラクティスを含む。"

"Docker ネットワーク設定ベストプラクティス（本番環境ゼロパケットロス実測レポート）。72 時間ストレステストデータで、Host・Bridge・Overlay のレイテンシ、スループット、パケットロス率を比較。"

"Docker Network Tests under Host/Bridge Mode。Host と Bridge モードの性能差を詳細比較し、レイテンシテスト方法と実験データを提供。"