Docker ComposeでWordPressを起動したのに、ブラウザーで開けない、コンテナがすぐ停止する、「データベース接続確立エラー」が表示されることがあります。原因を確認せずにコンテナやボリュームを削除すると、WordPressの投稿や設定まで失うおそれがあります。本記事では、データを残したまま、状態確認、ログ、設定、ポート、データベースの順に原因を切り分ける方法を解説します。
最初に確認すること：ボリュームを削除しない
トラブル対応を始める前に、WordPressやデータベースのデータがどこへ保存されているか確認します。Composeでは、データベースを名前付きボリュームへ保存する構成がよく使われます。
services:
db:
image: mariadb:11.4
volumes:
- db-data:/var/lib/mysql
volumes:
db-data:この例のdb-dataには、投稿、ユーザー、WordPress設定などが入ります。通常のdocker compose downはコンテナとネットワークを削除しますが、名前付きボリュームは残ります。一方、次のコマンドはボリュームも削除します。
docker compose down -v-vまたは--volumesは、初期化して最初から作り直す場合に使うオプションです。投稿を残したいトラブル対応では実行しません。実行前にデータベースのバックアップを取得できるなら、先にエクスポートしておくと安全です。
手順1：Dockerとコンテナの状態を確認する
最初に、Docker本体とComposeが利用できる状態か確認します。
docker version
docker compose versionDocker Engineへ接続できないエラーが出る場合は、Docker DesktopまたはDockerサービスが起動しているか確認します。次に、compose.yamlまたはdocker-compose.ymlがあるディレクトリへ移動して、コンテナ一覧を表示します。
docker compose ps -a-aを付けると、起動中のコンテナだけでなく停止したコンテナも確認できます。見る項目はSTATUSとPORTSです。
Upまたはrunning：コンテナは動いているExited：エラーまたは処理完了により停止しているRestarting：起動と失敗を繰り返している0.0.0.0:8083->80/tcp：パソコンの8083番からコンテナの80番へ接続する
一覧が空の場合は、別のディレクトリでコマンドを実行している可能性があります。Composeは現在のディレクトリと親ディレクトリから設定ファイルを探すため、対象サイトのフォルダで実行します。
手順2：設定とログから停止原因を探す
Compose設定を検証する
環境変数を反映した最終的なCompose設定は、次のコマンドで検証できます。
docker compose config -q問題がなければ何も表示されず終了します。YAMLのインデント、未定義の変数、サービス設定に問題がある場合はエラーが表示されます。実際に適用される設定を確認したい場合は、-qを外します。
docker compose configこの出力には、環境変数から展開されたパスワードが含まれる場合があります。画面共有や質問サイトへ貼り付けるときは、パスワードや秘密鍵を必ず伏せてください。
直近のログを確認する
コンテナが停止する理由はログへ記録されます。まず全サービスの直近100行を確認します。
docker compose logs --tail=100WordPressとデータベースを個別に調べる場合は、Composeファイルに書かれたサービス名を指定します。
docker compose logs --tail=100 wordpress
docker compose logs --tail=100 dbリアルタイムに確認したい場合は-fを使い、終了するときはCtrl+Cを押します。
docker compose logs -f wordpress dbログでは、port is already allocated、Access denied、Connection refused、Permission denied、No space left on deviceなど、最初に出た具体的なエラーを探します。
よくある原因と安全な解決方法
原因1：使用するポートが重複している
「port is already allocated」や「address already in use」と表示される場合は、指定したホスト側ポートを別のコンテナやアプリが使用しています。
docker ps --format "table {{.Names}}\t{{.Ports}}"WordPressを2サイト起動するなら、左側のホストポートを別々にします。右側の80はコンテナ内部のApacheが使用するため、そのままです。
services:
wordpress:
ports:
- "8084:80"変更後は設定を反映して起動します。
docker compose up -dこの場合はhttp://localhost:8084へアクセスします。公開範囲をローカルマシンだけに限定したい場合は、127.0.0.1:8084:80のようにホストIPも指定できます。
原因2：WordPressとデータベースの設定が一致していない
WordPress公式Dockerイメージでは、データベース接続にWORDPRESS_DB_HOST、WORDPRESS_DB_USER、WORDPRESS_DB_PASSWORD、WORDPRESS_DB_NAMEを使います。MariaDB側のデータベース名、ユーザー名、パスワードと一致させます。
services:
db:
image: mariadb:11.4
environment:
MARIADB_DATABASE: wordpress
MARIADB_USER: wordpress
MARIADB_PASSWORD: change-this-password
MARIADB_ROOT_PASSWORD: change-root-password
wordpress:
image: wordpress:php8.3-apache
depends_on:
- db
ports:
- "8084:80"
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_NAME: wordpress
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: change-this-passwordWORDPRESS_DB_HOSTにはlocalhostではなく、Composeのデータベースサービス名であるdbを指定します。同じComposeネットワーク内のコンテナは、サービス名で通信できるためです。
既存のデータボリュームがある状態で環境変数のパスワードだけ変更しても、作成済みデータベースのユーザー情報は自動的には変わりません。変更前の値へ戻すか、データベース側のパスワードも正しい手順で更新してください。
原因3：データベースの準備が終わる前にWordPressが接続した
depends_onは起動順を制御しますが、通常の短い書き方ではデータベースが接続可能になるまで待つことを保証しません。初回起動ではデータベースの初期化に時間がかかることがあります。
docker compose logs -f dbデータベースが接続待ちになったことを確認してから、WordPressを再起動します。
docker compose restart wordpress繰り返し発生する場合は、データベースへhealthcheckを設定し、WordPress側のdepends_onでcondition: service_healthyを使用する方法を検討します。ヘルスチェックのコマンドは、利用するデータベースイメージと認証設定に合わせる必要があります。
原因4：変更した設定やイメージが反映されていない
ComposeファイルやDockerfileを変更した場合は、必要に応じてビルドして起動します。
docker compose up -d --buildコンテナを作り直して設定を確実に反映したい場合は、ボリュームを削除しない次の方法があります。
docker compose up -d --force-recreateイメージを取得できない場合は、ネットワーク接続、プロキシ、イメージ名やタグを確認し、個別に取得してエラーを確認します。
docker compose pull原因5：ディスク容量やファイル権限が不足している
No space left on deviceならホスト側の空き容量を確認します。Permission deniedなら、バインドマウントしているテーマ、プラグイン、アップロードフォルダの所有者と権限を確認します。
docker system df容量不足でも、原因確認前にボリュームを削除しないでください。不要なイメージやビルドキャッシュを整理する場合も、何が削除されるか確認し、WordPressのバックアップを取得してから実行します。
起動から表示確認までのチェックリスト
原因を修正したら、次の順番で確認します。
docker compose config -qで設定エラーがないdocker compose up -dがエラーなく完了するdocker compose ps -aでWordPressとDBが起動しているdocker compose logs --tail=100に致命的なエラーがないPORTSに表示されたホスト側ポートへアクセスしている- WordPressとデータベースの接続情報が一致している
docker compose config -q
docker compose up -d
docker compose ps -a
docker compose logs --tail=100ブラウザーで開けない場合は、curlでHTTP応答だけを確認すると、ブラウザーキャッシュの問題とサーバー側の問題を分けられます。
curl -I http://localhost:8084200や301、302が返ればWebサーバーは応答しています。接続拒否なら、コンテナの状態とポート割り当てをもう一度確認します。
まとめ
Docker ComposeのWordPressが起動しないときは、ボリュームを削除せず、ps -a、config、logsの順に確認します。ポート競合、データベース接続情報、初期化待ち、設定の未反映を切り分ければ、多くの問題はデータを残したまま解決できます。特にdocker compose down -vはデータ削除につながるため、初期化が目的でない限り実行しないようにしましょう。