Docker のネットワークは「ドライバー」と呼ばれる種類ごとに、コンテナ同士やホスト・外部との通信の仕方が決まります。この記事では、既定で作られるネットワークの仕組み、bridge・host・none・overlay・macvlan などの違いと使い分け、コンテナ名で通信するための条件、ポート公開とファイアウォールの注意点、通信できないときの確認手順を説明します。Linux 上の Docker Engine を前提にし、Docker Desktop で挙動が異なる点はその都度補足します。
Dockerネットワークの基本的な仕組み
Docker をインストールすると、bridge・host・none という3つのネットワークが最初から作られています。docker network ls で確認できます。
docker network ls
docker network inspect bridgeLinux では、既定の bridge ネットワークはホスト上の仮想ブリッジ docker0 に対応しています。コンテナは起動時に仮想的な NIC を割り当てられ、172.17.0.0/16 のようなプライベートアドレスを受け取ります。外部への通信は、ホストの iptables（環境によっては nftables）による NAT（アドレス変換）を通って出ていきます。外部からコンテナへ入るには、後述するポート公開が必要です。
ネットワークを何も指定せずに docker run すると、コンテナはこの既定の bridge に接続されます。
ネットワークドライバーの種類
bridge（ブリッジ）
単一のホスト上でコンテナ同士をつなぐ、最もよく使う種類です。既定の bridge とは別に、自分で作るユーザー定義ブリッジがあり、実運用ではこちらを使うのが基本です。
docker network create appnet
docker run -d --name db --network appnet -e MYSQL_ROOT_PASSWORD=change-me mysql:8.4
docker run -d --name web --network appnet -p 8080:80 nginx:1.27ユーザー定義ブリッジには次の利点があります。
- コンテナ名で名前解決できる:
webからdbという名前で接続できます。Docker が内蔵する DNS（コンテナ内からは127.0.0.11に見えます）が名前を IP アドレスに変換します。既定のbridgeではこの名前解決が働かず、古い--linkオプションに頼ることになりますが、--linkは非推奨です。 - 分離できる: 別のユーザー定義ブリッジにいるコンテナとは、既定では通信できません。アプリごとにネットワークを分けると、影響範囲を絞れます。
- 後から付け外しできる:
docker network connect/disconnectで、実行中のコンテナを別のネットワークにつなげます。
host（ホスト）
コンテナがホストのネットワークをそのまま使います。ネットワークの分離もアドレス変換も無いため、コンテナ内で 80 番を待ち受けると、ホストの 80 番で直接受けることになります。-p の指定は意味を持たなくなります。
変換を挟まない分、大量の通信を扱う場面では有利なことがありますが、ポートの衝突やセキュリティ上の分離の弱さと引き換えです。Docker Desktop（Mac・Windows）ではコンテナが仮想マシン内で動くため、host ネットワークの対応状況や挙動は Linux と異なり、バージョンによっても変わります（2026年10月現在）。
none（なし）
ループバック以外のネットワークを持たせません。外部と通信する必要のない一括処理や、検証用の隔離環境に使います。
overlay（オーバーレイ）
複数のホストにまたがってコンテナをつなぐ種類で、Docker Swarm で使います。docker swarm init で Swarm を有効にしたうえで作成します。単一サーバーで WordPress を動かす程度であれば、通常は使いません。
macvlan / ipvlan
コンテナに物理ネットワーク上の IP アドレスを直接持たせる種類です。LAN 内の他の機器から、コンテナが1台のマシンのように見えます。ただし macvlan では、既定ではホスト自身とそのコンテナが直接通信できない、スイッチやクラウド環境によっては使えない、といった制約があります。VPS やクラウドでは、事業者のネットワーク仕様を確認してから検討してください。
Docker Composeが作るネットワーク
Docker Compose で起動すると、プロジェクトごとに <プロジェクト名>_default というユーザー定義ブリッジが自動で作られ、全サービスがそこに接続されます。そのため、Compose のサービス同士はサービス名で通信できます。networks: キーで独自のネットワークを定義し、「フロント用」と「データベース用」に分けることもできます。
ポート公開とファイアウォールの注意
外部からコンテナへアクセスさせるには -p ホスト側:コンテナ側 でポートを公開します。ここで見落としやすいのが次の2点です。
- 既定では全てのインターフェースで待ち受ける:
-p 8080:80はホストの全 IP アドレスの 8080 番を開けます。管理画面やデータベースなど、外部に見せる必要のないものは-p 127.0.0.1:8080:80のようにループバックに限定します。 - ufw などの設定を通らないことがある: Docker はポート公開のために iptables のルールを直接追加するため、Ubuntu の ufw で拒否しているつもりでも、公開したポートに外部から届いてしまうことがあります。対策は、公開範囲を
127.0.0.1に絞る、Docker 用のチェーン（DOCKER-USER）にルールを足す、クラウド側のファイアウォール（セキュリティグループ）で制限する、などです。
公開状況は docker ps の PORTS 列や ss -tlnp で確認し、外部の別マシンからポートが開いていないことも確かめておくと安心です。
データベースのコンテナは、そもそもポートを公開せず、同じネットワーク上のアプリからだけ接続させるのが基本です。docker network create --internal で作ったネットワークは外部への出口を持たないため、データベース専用の内側のネットワークとして使えます。
アドレス帯の衝突を避ける
Docker が使う 172.17.0.0/16 などのアドレス帯が、社内ネットワークや VPN のアドレス帯と重なると、コンテナを起動した途端にホストから社内のサーバーへ届かなくなることがあります。この場合は、Docker デーモンの設定ファイル /etc/docker/daemon.json で既定のアドレス帯を変更します。
{
"bip": "10.200.0.1/24",
"default-address-pools": [
{ "base": "10.201.0.0/16", "size": 24 }
]
}bip は既定の bridge のアドレス、default-address-pools はユーザー定義ネットワークに割り当てるアドレス帯です。変更後は Docker の再起動が必要で、既存のネットワークは作り直すまで古いアドレスのままです。本番サーバーで変える前に、検証用の環境で影響を確認してください。
通信できないときの確認手順
コンテナ同士がつながらないときは、外側から順に確認すると原因を絞り込めます。
- 同じネットワークにいるか:
docker network inspect appnetのContainersに両方が表示されるかを見ます。最も多い原因は、片方だけが既定のbridgeにいるケースです。 - 名前解決できるか:
docker exec web getent hosts dbで IP アドレスが返るかを確認します。イメージによってはnslookupやpingが入っていないため、getentが手軽です。 - 相手が待ち受けているか: 接続先のコンテナで、アプリが
127.0.0.1ではなく0.0.0.0で待ち受けているかを確認します。コンテナ内の127.0.0.1はそのコンテナ自身だけを指すため、他のコンテナからは届きません。 - ポート番号の取り違え: コンテナ同士の通信では、
-pで公開したホスト側のポートではなく、コンテナ側のポート（MySQL なら 3306）を使います。
まとめ
- Docker のネットワークはドライバーで種類が決まる。既定で
bridge・host・noneがある - 実運用ではユーザー定義ブリッジを作る。コンテナ名での名前解決と分離が使える
hostは分離が無く高速だが、ポート衝突と分離の弱さに注意。Docker Desktop では挙動が異なる- 複数ホストは
overlay、物理 LAN のアドレスを持たせるならmacvlan・ipvlan -pは既定で全インターフェースに公開され、ufw を通らないことがある。127.0.0.1に絞るか外側で制限する- アドレス帯の衝突は
daemon.jsonで変更し、つながらないときはネットワーク・名前解決・待ち受け・ポートの順に確認する