1. Dockerコンテナのネットワーク設定:IPアドレスとポートの基本理解
    1. Dockerネットワークの基本構造とコンテナIP
    2. ポート公開の仕組みとマッピングの必要性
    3. バインドアドレスの役割:0.0.0.0と127.0.0.1の違い
  2. IPアドレスとポートマッピングの具体的な設定手順
    1. docker run -p コマンドによるポートマッピング
    2. 特定のホストIPアドレスへのバインド設定
    3. Docker Composeでのポートマッピング設定例
  3. よく使うポートとIPアドレスのパターン別設定例
    1. Webサーバー(HTTP/HTTPS)の公開設定
    2. データベースサーバーのアクセス設定
    3. 複数のコンテナを連携させる場合のネットワーク設定
  4. Dockerコンテナアクセスで陥りやすいトラブルとその解決策
    1. 「localhost」の混同とアクセス先の間違い
    2. ホストOSのファイアウォール設定の問題
    3. コンテナ内のアプリケーションがリッスンしていない、または設定ミス
  5. 【ケース】外部からコンテナに繋がらない場合の確認ポイント
    1. ポートマッピングとIPアドレスの再確認
    2. ホストとコンテナのネットワーク疎通確認コマンド
    3. アプリケーション側のリッスンアドレスとログ確認
  6. まとめ
  7. よくある質問
    1. Q: Dockerで0.0.0.0と127.0.0.1の使い分けは?
    2. Q: Dockerでポートにアクセスできない主な原因は?
    3. Q: Dockerの172.17.0.0/16ネットワークとは何ですか?
    4. Q: Dockerで2375や7946ポートは何に使われますか?
    5. Q: docker run -pコマンドでのポート指定方法は?

Dockerコンテナのネットワーク設定:IPアドレスとポートの基本理解

Dockerネットワークの基本構造とコンテナIP

Dockerコンテナは、デフォルトで「ブリッジ(bridge)ネットワーク」と呼ばれる仮想ネットワークに接続されます。これは、ホストマシンとコンテナ間、およびコンテナ同士のネットワークを分離するための仕組みです。各コンテナにはこのブリッジネットワーク内で一意のプライベートIPアドレスが割り当てられ、他のコンテナやホストマシンとは異なるネットワーク空間で動作します。この分離によって、セキュリティが確保され、アプリケーション間の依存関係が減少し、環境のポータビリティが高まります。

例えば、同じホスト上で複数のWebサーバーコンテナを動かす場合、それぞれが独立したIPアドレスを持つため、ポートの衝突を気にすることなく開発を進めることができます。このデフォルトのネットワーク設定を理解することが、コンテナへのアクセス問題を解決する第一歩となります。

出典:Docker コンテナ・ネットワークの理解(Docker ドキュメント / 2024年10月19日更新)

ポート公開の仕組みとマッピングの必要性

コンテナは独自のネットワーク空間を持つため、コンテナ内部で起動したサービス(Webサーバーなど)のポートは、デフォルトではホストマシンや外部ネットワークから直接アクセスできません。外部からアクセス可能にするためには、ホストのポートとコンテナのポートを紐付ける「ポートマッピング」を行う必要があります。これは-p(または--publish)オプションを使用して設定します。

具体的なコマンドはdocker run -p ホストポート:コンテナポート イメージ名の形式です。例えば、ホストの8080番ポートを、コンテナ内部の80番ポートにマッピングする場合、-p 8080:80と指定します。この設定により、ホストの8080番ポートへの通信は、Dockerによって自動的にコンテナの80番ポートへ転送されるようになります。この仕組みは、Linuxのiptablesのようなファイアウォールルールによって実現されています。

出典:コンテナーのネットワーク(Docker ドキュメント / 2024年10月19日更新)

バインドアドレスの役割:0.0.0.0と127.0.0.1の違い

コンテナ内でサーバーアプリケーションを起動する際、そのアプリケーションがどのIPアドレスからの接続を受け入れるかを指定する「バインドアドレス」が重要になります。よく使われるのは127.0.0.10.0.0.0です。

  • 127.0.0.1(ループバックアドレス): これは「コンテナ自身」を指すアドレスです。アプリケーションが127.0.0.1でリッスンしている場合、そのコンテナ内からのアクセスのみを受け入れます。この設定だと、ホストマシンや外部からのポートマッピング経由のアクセスは到達しません。
  • 0.0.0.0(すべてのインターフェース): これは「すべてのネットワークインターフェース」からの接続を受け入れるアドレスです。アプリケーションが0.0.0.0でリッスンしている場合、コンテナ内部だけでなく、ポートマッピングを設定していればホストマシンや外部からのアクセスも受け入れ可能になります。

外部からのアクセスを想定している場合は、コンテナ内のアプリケーションが必ず0.0.0.0でリッスンするように設定されているか確認することが重要です。

出典:Docker環境で学ぶ 0.0.0.0 と 127.0.0.1 の違いと確認方法(Zenn / 2025年9月24日更新)

IPアドレスとポートマッピングの具体的な設定手順

docker run -p コマンドによるポートマッピング

Dockerコンテナを起動する際に最もよく利用されるポートマッピングの方法は、docker runコマンドの-pオプションを使用することです。このオプションは、ホストマシンとコンテナ間のポートを紐付けます。

基本構文は docker run -p [ホストIP]:<ホストポート>:<コンテナポート> <イメージ名> です。

  • -p 8080:80 nginx: ホストの全てのIPアドレスの8080番ポートを、nginxコンテナの80番ポートにマッピングします。
  • -p 127.0.0.1:80:80 nginx: ホストのループバックアドレス(127.0.0.1)の80番ポートのみを、nginxコンテナの80番ポートにマッピングします。これにより、ホストマシンからしかアクセスできなくなります。
  • -p 80:80/udp my_udp_app: UDPプロトコルを使用する場合、ポート番号の後に/udpを追加します。

この-pオプションは複数回指定することで、複数のポートマッピングを設定することも可能です。

特定のホストIPアドレスへのバインド設定

ポートマッピングを行う際、ホストの特定のIPアドレスにのみバインドさせたい場合があります。これは、同じホストマシンに複数のネットワークインターフェースがあり、特定のインターフェース経由でのみアクセスを許可したい場合や、セキュリティ上の理由からアクセス元を制限したい場合に有効です。この設定も-pオプションの拡張機能として利用できます。

構文は -p <ホストIPアドレス>:<ホストポート>:<コンテナポート> です。例えば、ホストマシンが192.168.1.100というIPアドレスを持つネットワークインターフェースを持っており、そのIPの80番ポートをコンテナの80番ポートにマッピングしたい場合、docker run -p 192.168.1.100:80:80 my_web_app と指定します。これにより、192.168.1.100以外のIPアドレスを経由したホストの80番ポートへのアクセスは、コンテナに転送されなくなります。これは、仮想ホスト環境などで特定のサービスを限定的に公開したい場合に役立ちます。

Docker Composeでのポートマッピング設定例

複数のコンテナを連携させてアプリケーションを構築する場合、Docker Composeを使用するのが一般的です。Docker Composeでは、YAMLファイル(通常docker-compose.yml)にサービスの設定を記述し、その中でポートマッピングも定義できます。これにより、複雑な設定もコードとして管理しやすくなります。

docker-compose.ymlでのポート設定はportsセクションで行います。以下に基本的な例を示します。

version: '3.8'
services:
  web:
    image: nginx
    ports:
      - "8080:80"  # ホストの8080ポートをコンテナの80ポートにマッピング
      - "127.0.0.1:443:443" # ホストの127.0.0.1の443ポートをコンテナの443ポートにマッピング

この設定により、docker-compose up -dコマンドを実行するだけで、指定されたポートマッピングを持つnginxコンテナが起動します。Docker Composeを使うことで、開発環境や本番環境でのコンテナ設定の一貫性を保ちやすくなります。

よく使うポートとIPアドレスのパターン別設定例

Webサーバー(HTTP/HTTPS)の公開設定

Webサーバーコンテナ(NginxやApacheなど)をDockerで動かす場合、通常はHTTP(80番ポート)とHTTPS(443番ポート)を公開します。これらのポートをホストマシンからアクセスできるようにマッピングする設定は非常に一般的です。

例えば、Nginxコンテナをホストの80番ポートと8080番ポート、443番ポートにそれぞれマッピングする場合、以下のようになります。

docker run -d \
  -p 80:80 \    # ホストの80番ポートをコンテナの80番ポートにマッピング
  -p 8080:80 \  # ホストの8080番ポートもコンテナの80番ポートにマッピング(別アクセス経路)
  -p 443:443 \  # ホストの443番ポートをコンテナの443番ポートにマッピング (HTTPS)
  --name my-nginx nginx

この設定により、http://localhost/(またはホストのIP)とhttp://localhost:8080/の両方でNginxコンテナにアクセスできるようになります。HTTPSの場合も同様にhttps://localhost/でアクセス可能です。本番環境では、ホストのIPアドレスを限定してバインドする-p 192.168.1.10:80:80のような設定も検討されることがあります。

データベースサーバーのアクセス設定

MySQLやPostgreSQLなどのデータベースサーバーをコンテナで運用する場合、通常はアプリケーションコンテナからのみアクセスできるように内部ネットワークに公開し、外部(ホストマシンや他の外部サーバー)からは限定的にアクセスできるように設定します。

開発環境などでホストマシンから直接データベースに接続したい場合は、以下のようにポートマッピングを設定します。

docker run -d \
  -p 3306:3306 \ # MySQLの場合:ホストの3306ポートをコンテナの3306ポートにマッピング
  --name my-mysql \
  -e MYSQL_ROOT_PASSWORD=mysecretpassword \
  mysql

またはPostgreSQLの場合:

docker run -d \
  -p 5432:5432 \ # PostgreSQLの場合:ホストの5432ポートをコンテナの5432ポートにマッピング
  --name my-postgres \
  -e POSTGRES_PASSWORD=mysecretpassword \
  postgres

本番環境では、セキュリティを考慮し、データベースポートをホストのループバックアドレス127.0.0.1にのみバインドするか、Docker Composeの内部ネットワーク機能を利用して、データベースポートをホストに公開しないでアプリケーションコンテナからのみアクセスさせるのが一般的です。

複数のコンテナを連携させる場合のネットワーク設定

Webアプリケーション開発では、Webサーバー、アプリケーションサーバー、データベースサーバーなど、複数のコンテナを組み合わせてサービスを構築することがよくあります。このような場合、コンテナ間での通信設定が重要になります。Docker Composeを使用すると、これらの連携を効率的に管理できます。

Docker Composeは、デフォルトでサービスごとに独自の内部ネットワークを作成し、そのネットワーク内で名前解決を行います。これにより、コンテナ同士はIPアドレスではなく、サービス名(docker-compose.ymlで定義したサービス名)で相互にアクセスできます。

version: '3.8'
services:
  web:
    image: nginx
    ports:
      - "80:80"
  app:
    image: my_flask_app
    environment:
      DATABASE_HOST: db # dbサービス名でアクセス可能
  db:
    image: postgres
    environment:
      POSTGRES_PASSWORD: password

この例では、appコンテナは環境変数DATABASE_HOSTの値としてdbを指定することで、dbコンテナにアクセスできます。dbコンテナのポートはホストに公開されていないため、外部からの直接アクセスはできませんが、appコンテナからはdb:5432でアクセス可能です。これにより、セキュアなコンテナ間通信を実現できます。

Dockerコンテナアクセスで陥りやすいトラブルとその解決策

「localhost」の混同とアクセス先の間違い

Dockerで最もよくあるトラブルの一つが「localhost」の認識に関する混同です。ホストマシン上でブラウザから「localhost:8080」と入力してアクセスしようとしたとき、コンテナに繋がらないというケースです。

  • ホストマシンの「localhost」: これはホストマシン自身を指します。ポートマッピング-p 8080:80を設定した場合、ホストマシンからコンテナにアクセスするには、http://localhost:8080と指定する必要があります。
  • コンテナ内の「localhost」: これはコンテナ自身を指します。もしコンテナ内のアプリケーションが127.0.0.1でリッスンしている場合、コンテナ外(ホストや外部)からはポートマッピングしていてもアクセスできません。アプリケーションは0.0.0.0でリッスンさせる必要があります。

この違いを理解し、アクセスする側(ブラウザ、別のコンテナ、ホスト)とアクセスされる側(コンテナ内のアプリケーション)で適切なアドレスとポートが指定されているか確認することが解決の鍵となります。

ホストOSのファイアウォール設定の問題

Dockerコンテナのポートマッピングを正しく設定したにもかかわらず、外部からコンテナにアクセスできない場合、ホストOSのファイアウォール設定が原因である可能性があります。Dockerはポートマッピング時にiptablesルールを自動的に設定しますが、ホストOSに元々設定されているファイアウォール(例: Linuxのufwfirewalld、Windows Defender Firewallなど)が、そのポートへの外部からのアクセスをブロックしている場合があります。

解決策としては、以下の確認と設定変更が考えられます。

  • ファイアウォール状況の確認:
    • Linux (Ubuntuなど): sudo ufw status
    • Linux (CentOSなど): sudo firewall-cmd --list-all
    • Windows: Windows Defender Firewallの設定を確認
  • 必要なポートの開放: ホストマシンでポートマッピングに使用しているポート(例: 8080)が、ファイアウォールによって許可されているか確認し、必要であれば開放します。例えば、sudo ufw allow 8080/tcpのようなコマンドを使用します。

セキュリティのためにも、全てのポートを開放するのではなく、必要なポートのみを開放するように注意しましょう。

コンテナ内のアプリケーションがリッスンしていない、または設定ミス

ポートマッピングもファイアウォール設定も問題ないのにアクセスできない場合、コンテナ内部で実行されているアプリケーション自体に原因があるかもしれません。具体的には、アプリケーションが正しく起動していない、あるいは正しいIPアドレス(0.0.0.0)でリッスンしていないという状況が考えられます。

以下の手順で確認・対処します。

  1. コンテナのログを確認: docker logs <コンテナ名またはID>コマンドを実行し、アプリケーションの起動ログやエラーメッセージを確認します。アプリケーションが正常に起動しているか、ポートの競合エラーが発生していないかなどを確認します。
  2. アプリケーションのリッスンアドレスを確認: コンテナ内でシェルにアクセスし(docker exec -it <コンテナ名> bash)、netstat -tulnss -tulnなどのコマンドで、アプリケーションがどのIPアドレスとポートでリッスンしているかを確認します。もし127.0.0.1でしかリッスンしていない場合は、アプリケーションの設定ファイルや起動スクリプトを変更し、0.0.0.0でリッスンするように修正する必要があります。

多くのWebフレームワークやサーバーでは、環境変数や設定ファイルでバインドアドレスを変更できます。例えばFlaskではapp.run(host='0.0.0.0', port=5000)のように設定します。

トラブルシューティングチェックリスト

  • ポートマッピング(-pオプション)は正しく設定されているか?
  • コンテナ内のアプリケーションは0.0.0.0でリッスンしているか?
  • ホストOSのファイアウォールは対象ポートをブロックしていないか?
  • docker logs <コンテナ名>でエラーログを確認したか?
  • ホストからcurl http://localhost:<ホストポート>でアクセスしてみたか?

【ケース】外部からコンテナに繋がらない場合の確認ポイント

ポートマッピングとIPアドレスの再確認

外部からDockerコンテナにアクセスできない場合、まずは設定の基本に戻り、ポートマッピングとIPアドレスの指定が正しいか再確認することが重要です。

  1. docker psコマンドでポートマッピングを確認: 実行中のコンテナ一覧を表示し、PORTS列で目的のポートマッピングが正しく表示されているかを確認します。例えば、0.0.0.0:8080->80/tcpのように表示されていれば、ホストの全IPアドレスの8080番ポートがコンテナの80番ポートにマッピングされていることを意味します。もし127.0.0.1:8080->80/tcpとなっていれば、ホストのループバックアドレスからしかアクセスできません。
  2. コンテナの内部IPアドレスを確認: docker inspect <コンテナ名またはID>コマンドを実行し、出力されるJSONデータの中からNetworksセクションにあるIPAddressの項目を探します。このIPアドレスは、ホストから直接アクセスを試みる際に役立つ場合があります(ただし通常はポートマッピング経由が推奨)。

これらの情報をもとに、想定通りの設定になっているかを慎重にチェックしてください。特に、ホストポートとコンテナポートの数字の入れ間違いや、ホストIPアドレスの誤指定はよくあるミスです。

ホストとコンテナのネットワーク疎通確認コマンド

設定に問題がないように見えてもアクセスできない場合、ネットワークの疎通状況を確認することが次のステップです。

  1. ホストからコンテナのポートへcurl:

    ホストマシンから、マッピングしたポートに対してcurlコマンドでアクセスを試みます。
    curl http://localhost:<ホストポート> または curl http://<ホストIP>:<ホストポート>
    これにより、ホストのネットワーク層からコンテナへの通信が確立されているかを確認できます。もしここで応答がない場合、ファイアウォールやポートマッピングに問題がある可能性が高いです。

  2. コンテナ内から外部への疎通確認:

    コンテナ内でシェルに入り(docker exec -it <コンテナ名> bash)、外部への通信が可能か確認します。
    ping google.comcurl http://example.com
    コンテナがインターネットに接続できない場合、DNS設定やDockerのネットワーク設定に問題がある可能性があります。

これらのコマンドを実行することで、問題がホスト側にあるのか、コンテナ側にあるのか、またはネットワーク経路にあるのかを切り分けるヒントが得られます。

アプリケーション側のリッスンアドレスとログ確認

最終的な確認ポイントとして、コンテナ内部で動作しているアプリケーション自体の設定と状態を深く掘り下げます。これは、ネットワーク設定がすべて正しくても、アプリケーション側の問題でアクセスできないケースが多いためです。

  1. アプリケーションのリッスンアドレスを再確認:

    コンテナ内で実行されているサーバーアプリケーションが、本当に0.0.0.0で指定されたポートをリッスンしているかを確認します。前述のdocker exec -it <コンテナ名> bashでコンテナに入り、netstat -tuln | grep <コンテナポート>を実行します。
    出力例: tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN のように表示されていればOKです。もし127.0.0.1:80となっていたら、アプリケーションの設定変更が必要です。

  2. アプリケーションのログを詳細に分析:

    docker logs <コンテナ名>で取得したログをもう一度詳しく確認します。特に、アプリケーションが起動時にエラーを出していないか、ポートのバインドに失敗していないか、設定ファイルが見つからないといった警告がないかを探します。また、アクセス時にログが出力されているか(到達しているか)も確認します。

これらの確認により、アプリケーションが期待通りに動作しているか、または特定の理由でアクセスを受け付けていないかを特定し、適切な対策を講じることができます。多くの場合、アプリケーションの設定ファイル(例: Apacheのhttpd.conf、Node.jsのコード、Pythonのフレームワーク設定など)を見直すことで解決します。