Docker のトラブルは、エラーメッセージと終了コードを読めば、原因の候補をかなり絞り込めます。この記事では、よく出会う症状を「デーモンにつながらない」「コンテナがすぐ止まる」「ポートやネットワークの問題」「イメージ・ビルド・ディスクの問題」に分け、それぞれ起こりやすい原因の順に、確かめるコマンドと直し方を説明します。
コマンドは Docker Engine と Docker Compose v2 を前提にしています（2026年10月現在）。Docker Desktop を使っている場合は、エンジンが仮想マシンの中で動いているため、一部の確認方法が異なります。
最初に集める情報
どの症状でも、まず次の4つを見ると状況がつかめます。
docker ps -a # 停止したコンテナも含めて状態と終了コードを見る
docker logs --tail 100 <コンテナ名> # コンテナの標準出力・標準エラー
docker inspect <コンテナ名> # 設定・状態・ネットワーク・マウントの詳細
docker info # エンジン自体の状態、ストレージ、警告Compose で起動している場合は、docker compose ps -a と docker compose logs <サービス名> が同じ役割です。
デーモンにつながらない
Cannot connect to the Docker daemon
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? は、docker コマンドがエンジン（dockerd）に接続できないという意味です。
- エンジンが止まっている：Linux では
sudo systemctl status dockerで状態を確認し、止まっていればsudo systemctl start dockerで起動します。起動に失敗する場合はsudo journalctl -u docker --no-pager -n 100で理由を読みます。/etc/docker/daemon.jsonの書式誤り（JSON のカンマ抜けなど）は起動失敗の典型的な原因です。 - Docker Desktop が起動していない：Windows/macOS ではアプリ自体が起動しているか確認します。
- 接続先の設定が違う：
docker context lsで現在のコンテキストを確認します。環境変数DOCKER_HOSTが残っていると、意図しない接続先を見に行きます。
permission denied（docker.sock）
permission denied while trying to connect to the Docker daemon socket は、エンジンは動いているものの、実行ユーザーにソケットへの権限がない状態です。一般ユーザーで使うなら docker グループに追加する方法が知られていますが、docker グループのユーザーはホストの root と同等の操作ができる点に注意してください。共有サーバーでは、rootless モードの利用や、sudo での実行にとどめることも検討します。グループに追加した後は、ログインし直すまで反映されません。
コンテナがすぐ止まる・再起動を繰り返す
docker ps -a の STATUS が Exited (数字) になっていれば、その数字が手がかりです。
- 0：正常終了。メインのプロセスが処理を終えて終わっただけです。バックグラウンドで動くデーモンをフォアグラウンドで実行していない（
nginxをdaemon offなしで動かす、など）ことが多い原因です。 - 1 など：アプリケーションのエラー。
docker logsに理由が出ていることがほとんどです。設定ファイルの誤り、必要な環境変数の不足、DB への接続失敗が上位の原因です。 - 125：docker run 自体の失敗。オプションの誤りなど、コンテナが作られる前の問題です。
- 126：コマンドは見つかったが実行できない。スクリプトに実行権限がない、改行コードが CRLF になっている、などを疑います。
- 127：コマンドが見つからない。
CMDやENTRYPOINTのパスの誤り、イメージにそのツールが入っていない、などです。 - 137：SIGKILL で強制終了。メモリ不足で OOM キラーに止められた可能性が高く、
docker inspect --format '{{.State.OOMKilled}}' <コンテナ名>がtrueなら確定です。メモリ制限を見直すか、アプリのメモリ使用量を下げます。docker stopの猶予時間を過ぎて強制終了された場合も 137 になります。 - 143：SIGTERM で終了。
docker stopでの通常の停止です。
ログに何も出ないまま止まる場合は、同じイメージをシェルで起動して手で実行してみると原因が見えます（sh が入っていない最小構成のイメージでは使えません）。
docker run --rm -it --entrypoint sh <イメージ名>ポートとネットワークの問題
port is already allocated
Bind for 0.0.0.0:8080 failed: port is already allocated は、ホスト側のポートがすでに使われているという意味です。docker ps で同じポートを公開している別のコンテナがないか確かめ、なければ sudo ss -ltnp | grep 8080（Linux）でホスト上のプロセスを調べます。止めてよいものなら止め、そうでなければ -p 8081:80 のようにホスト側の番号を変えます。
ホストからアクセスできない
コンテナは動いているのにブラウザから開けない場合、起こりやすい順に次を確かめます。
- ポートを公開していない：
docker psの PORTS 列に0.0.0.0:8080->80/tcpのような表示があるか確認します。 - アプリが 127.0.0.1 で待ち受けている：コンテナ内のアプリが
localhostだけで待ち受けていると、ポートを公開しても外から届きません。開発用サーバーの多くは、待ち受けアドレスを0.0.0.0にする設定が必要です。 - ファイアウォール：クラウドのセキュリティグループやホストのファイアウォールを確認します。
コンテナ同士がつながらない
同じユーザー定義ネットワーク（Compose なら同じプロジェクトの既定ネットワーク）にいるコンテナは、サービス名やコンテナ名で名前解決できます。既定の bridge ネットワークでは名前解決が使えない点はつまずきやすいところです。docker network inspect <ネットワーク名> で両方のコンテナが参加しているか確かめ、片方のコンテナから getent hosts db などで名前が引けるか試します。接続先に localhost を指定していると、それはコンテナ自身を指すため、相手のサービス名に直します。
イメージ・ビルド・ディスクの問題
イメージを取得できない
- manifest unknown / not found：タグ名の誤り、またはそのタグが存在しない、あるいは手元の CPU アーキテクチャ（amd64 / arm64）向けのイメージがないことが原因です。
docker manifest inspect <イメージ名:タグ>で対応アーキテクチャを確認できます。 - toomanyrequests：Docker Hub の取得回数の制限に達しています。制限の内容はプランやログイン状態で変わるため、公式の案内を確認し、
docker loginするか、自前のレジストリやミラーを使います。 - unauthorized：非公開リポジトリへのログインが切れているか、権限がありません。
ビルドが失敗する
ビルドのログが短くて原因が分からない場合は、docker build --progress=plain . で各ステップの出力を表示します。キャッシュが原因で古い状態のまま進んでいる疑いがあれば --no-cache を付けて再ビルドします。COPY failed: file not found は、ファイルがビルドコンテキストの外にあるか、.dockerignore で除外されていることが多い原因です。
no space left on device
ディスクの空きがなくなると、ビルドやコンテナの書き込みが失敗します。docker system df で、イメージ・コンテナ・ボリューム・ビルドキャッシュのどれが容量を使っているかを確認します。不要なものは docker image prune や docker builder prune で削除できます。docker system prune --volumes のようにボリュームを含めて削除すると、DB のデータも消えるおそれがあるため、ボリュームを削除する前にバックアップと対象の確認を行ってください。コンテナのログが肥大化している場合は、ログドライバーのローテーション設定を見直します。
バインドマウントの権限エラー
ホストのディレクトリをマウントしたときの Permission denied は、ホスト側のファイルの所有者（UID）と、コンテナ内でプロセスを動かしているユーザーの UID が一致していないことが主な原因です。ls -ln で数値の UID を比べ、コンテナの実行ユーザーを合わせるか、必要な範囲だけ所有者を変えます。chmod 777 で回避するのは、ほかのユーザーからも書き込める状態になるため避けてください。SELinux が有効なホストでは、マウント指定に :z などのラベルが必要な場合があります。
それでも分からないとき
docker events を別の端末で実行したまま問題を再現すると、コンテナの作成・起動・停止・ヘルスチェックの結果が時系列で流れ、どこで止まっているかが見えます。原因が分かったら、同じ構成をステージングで再現して直し方を確かめてから、本番に反映してください。
まとめ
- まず
docker ps -a、docker logs、docker inspect、docker infoで状況を集める - デーモンにつながらないときは、エンジンの起動状態、
journalctlのログ、コンテキストの順に確かめる - コンテナが止まるときは終了コードを読む。137 は OOM を疑い
OOMKilledを確認する - ポートの競合は
ssで、コンテナ間通信はネットワークへの参加と名前解決で切り分ける - ディスク不足は
docker system dfで内訳を見てから削除する。ボリュームの削除はバックアップ後に - マウントの権限エラーは UID の不一致を確かめ、
chmod 777で逃げない