Docker Composeのportsをlocalhostに限定する：ローカル開発の公開範囲

開発中のサイト、自分のPCだけで見られればいいよねー。そんなときは、Dockerの公開先を確認しておこう。似ている2つの設定を比べるよ。

図：ローカルIPv4公開の構成例。ホストIPとコンテナ内の待受IPは別。

結論：ホスト側の公開先IPを明示する

同じPCで動かすブラウザからだけ開発サイトを見たいときは、Composeのportsでホスト側に127.0.0.1を指定します。

services:
  web:
    ports:
      - "127.0.0.1:3000:3000"

これにより、IPv4ループバックアドレスでホストの3000番を公開し、コンテナの3000番へ転送します。認証を追加する設定ではなく、ホスト側の公開インターフェースを限定する設定です。

「3000:3000」と何が違う？

ports:
  - "3000:3000"

ホストIPを省略すると、Dockerの標準動作ではすべてのホストインターフェースで公開します。実際に外部から到達できるかはOS・ファイアウォール・ネットワーク構成にも左右されます。「省略しても自分のPCだけ」とは考えず、必要な範囲を明示します。

127.0.0.1を指定した場合、通常は同じPCのブラウザからlocalhost:3000で確認できるよ。スマートフォンからLAN経由で実機確認する用途では別の公開設定が必要です。その際は、認証や一時的な公開範囲も併せて検討してね。

コンテナ内は0.0.0.0で待ち受ける

アプリの待受設定とホストのportsは別です。コンテナ内のアプリが127.0.0.1だけで待ち受けると、ホストからの転送を受けられない場合があります。

コンテナ内のアプリ：0.0.0.0:3000で待受
ホストでの公開先：127.0.0.1:3000に限定

「0.0.0.0だから即インターネットへ公開」ではなく、どのネットワーク名前空間の設定かを分けて読みます。

確認するコマンド

docker compose config --quiet
docker compose up -d
docker compose ps
curl -I http://127.0.0.1:3000

config --quietは構成の妥当性を確認します。アクセスできることまで確認するコマンドではありません。psで公開ポート、curlでHTTP応答を確かめます。データベースなどホストから直接接続しないサービスには、そもそもportsを設定しない選択もできるよ。

今回の確認と適用範囲

このサイトのローカル環境では、フロントエンドを127.0.0.1:3000、CMSを127.0.0.1:1337に設定し、Dockerの構成確認とHTTP応答を確認しました。

Docker公式資料には、28.0.0より前のバージョンでlocalhost公開に注意が必要なケースも記載されています。古い環境では、設定例だけで安全性を判断せず、バージョンと公式の注意事項を確認してね。

ダウンロードして再現する構成例

ローカル接続のComposeサンプルを保存して、空の作業ディレクトリで試せるよ。Dockerが起動していて、ホストの18347番が空いていることを確認してね。

docker compose -f compose.local.yaml up -d
curl http://127.0.0.1:18347
docker compose -f compose.local.yaml down

2026年10月15日、このファイルを使って起動し、HTTP本文が hello-local になることを確認したよ。別の独立コンテナでも、ホスト側のバインドIPが127.0.0.1であることをinspectで確認した。テスト後は作ったコンテナを削除済み。別端末から到達できないことや、あらゆるOSのファイアウォールを検証した結果ではないよ。

検証記録JSONも確認できるよ。