WordPressの「データベース接続確立エラー」の原因と直し方

WordPressで「データベース接続確立エラー」と表示されても、記事が消えたと決まったわけではありません。WordPressがMySQLまたはMariaDBへ接続できず、保存された投稿や設定を読み出せない状態です。DBサーバーの一時停止、wp-config.phpの接続情報、ユーザー権限、接続上限、テーブル破損などを順に調べます。

最初からデータベースを作り直すと、復旧できるデータまで失うおそれがあります。サーバー稼働状況と変更履歴を確認し、現在のファイルとDBを保全してから、影響の小さい確認へ進んでください。ほかのエラーとの見分け方は「エラーまとめ」、保存先の基本は「wordpressのデータベースの仕組み」で確認できます。

「データベース接続確立エラー」とは

WordPressは、PHPで動くファイル群と、投稿、固定ページ、ユーザー、設定などを保存するデータベースを組み合わせてページを生成します。PHPがDBへ接続できないと必要な情報を取得できず、このエラーを返します。

接続にはwp-config.phpの次の値が使われます。

• DB_NAME：データベース名
• DB_USER：接続ユーザー名
• DB_PASSWORD：接続パスワード
• DB_HOST：DBサーバーのホスト名。環境によってポートやソケットを含む

エラーは公開側と管理画面の両方に出ることも、片方だけに出ることもあります。断続的なら負荷や接続上限、移行・パスワード変更直後なら接続情報、管理画面に修復を促す別メッセージが出るならテーブル破損を優先して調べます。

最初に確認すること

安全な初動は、変更を増やさず、サーバー全体の問題かWordPress固有の問題かを分けることです。次の順で確認します。

1. エラーが出たURL、時刻、公開側・管理画面の範囲を記録する
2. ホスティングの障害・メンテナンス情報を見る
3. 同じ契約内の別サイトやDB管理画面が動くか確認する
4. 直前の移行、DBパスワード変更、復元、サーバー更新を確認する
5. PHP、Webサーバー、DBのログを同じ時刻で保存する
6. 現在のwp-config.phpと取得可能なDBをバックアップする

一時的な障害情報が出ている場合は、設定を書き換えず復旧を待ちます。接続情報を何度も変更すると、ホスティング側の復旧後もつながらない状態を作ることがあります。

EC、予約、会員サイトでは、障害前後の書き込みがどこまで成功したかを確認します。DBを古いバックアップへ戻す前に、現在のDBを退避し、注文や登録の差分を保全してください。

wp-config.phpの接続情報を確認する

サーバーが稼働しているなら、wp-config.phpの4項目をホスティング管理画面の値と照合します。思い出した値や別サイトの設定を流用せず、対象DBの現在値を確認してください。

define( 'DB_NAME', 'database_name' );
define( 'DB_USER', 'database_user' );
define( 'DB_PASSWORD', 'database_password' );
define( 'DB_HOST', 'database_host' );

確認時の注意点は次のとおりです。

• 引用符や括弧が全角になっていないか
• パスワードの記号を含め、値が完全一致するか
• DB_HOSTがlocalhostとは限らないことを理解する
• ポート、Unixソケット、ホスティング固有ホスト名が必要か
• 移行先でDB名やユーザー名の接頭辞が変わっていないか
• 編集したwp-config.phpが実際に読み込まれる場所にあるか

DBパスワードを管理画面で再発行した場合は、wp-config.php側も同じ値へ更新します。古いパスワードがキャッシュされて自然に直ることはありません。

ファイルを編集するときは、Wordやオンライン文書ではなくプレーンテキスト対応エディターを使います。公開ディレクトリへwp-config.phpのコピーを「wp-config-old.php」などの名前で放置すると、サーバー設定によっては秘密情報が漏れるため、安全な保存場所へ置きます。

データベースユーザーの権限を確認する

接続情報が正しくても、DBユーザーが対象データベースへ割り当てられていない、必要な権限を失った、接続元ホストが許可されていない場合は接続できません。ホスティングのDB管理画面で、ユーザーとDBの対応を確認します。

移行やアカウント複製では、DBだけ作成され、ユーザー割当てが抜けることがあります。名前が似た別DBへユーザーを割り当てないよう、wp-config.phpのDB_NAMEと照合してください。

確認する項目は次のとおりです。

• 対象DBが存在する
• DBユーザーが存在する
• ユーザーが対象DBへ割り当てられている
• WordPressの通常動作に必要な権限がある
• 接続元ホストの制限に一致する
• パスワード変更がwp-config.phpへ反映されている

権限不足を直すために、無関係なデータベースやサーバー全体へ過剰な権限を与えないでください。共有ホスティングでは提供画面の推奨設定を使い、VPSではDB管理者が最小限の権限を設定します。

接続テスト用PHPファイルへ資格情報を書いて公開する方法は、秘密情報を露出させる危険があります。ホスティングが用意する接続確認、DBクライアント、WP-CLIなど、外部公開しない経路を優先します。

データベースサーバーの負荷・接続上限を確認する

エラーが断続的、アクセス増加時だけ発生、更新やバックアップ中に出る場合は、DBサーバーの負荷または接続上限が疑われます。設定値が間違っている場合は通常継続して失敗しますが、資源不足は時間帯で変わります。

ホスティングまたは管理者へ、発生時刻を添えて次を確認します。

• DBサービスの停止・再起動履歴
• 同時接続数と上限到達の記録
• CPU、メモリ、ディスクI/O、空き容量
• 遅いクエリとロック待ち
• バックアップ、cron、集計処理の実行時刻
• 同一サーバー上の障害範囲

キャッシュを導入すればDBアクセスを減らせる場合がありますが、原因となる重いクエリや接続リークを直す代わりにはなりません。発生URL、実行処理、該当プラグインをログで特定します。

公開停止が続き、事業上の影響が大きい場合は「緊急対応サービス」へ、エラー時刻、ログ、直前変更、試した操作をまとめて相談します。負荷の根拠がないまま上位プランへ変える前に、ボトルネックを確認してください。

破損したデータベースを修復する

接続自体はできるものの、テーブルが利用できない、管理画面で修復を求める文言が出る場合は、DB破損を検討します。通常の「接続確立エラー」だけを根拠に、すぐ修復機能を実行しません。

作業前にDBをバックアップします。WordPressには、wp-config.phpへ次の定数を追加して修復画面を有効にする機能があります。

define( 'WP_ALLOW_REPAIR', true );

有効化後、対象サイトの「/wp-admin/maint/repair.php」を開き、修復または修復と最適化を選びます。最適化は処理時間やロックの影響が増えることがあるため、まず修復だけで足りるか判断します。

重要なのは、作業が終わったらWP_ALLOW_REPAIRを必ず削除することです。WordPress公式文書は、DB破損時にログインできないことを想定し、この修復ページが未ログインでも開けると説明しています。定数を残すと第三者が処理を実行できる状態になります。

修復が失敗する、破損が繰り返す、DBサービスが停止する場合は、ストレージ、DBログ、テーブルエンジンを管理者へ確認します。エラーを繰り返し修復して運用を続けず、根本原因を調べます。

WordPressファイルの破損を確認する

DB接続情報とサーバーが正常でもエラーが続く場合、WordPressコア、DBドロップイン、キャッシュ関連ファイル、改ざんを調べます。wp-content内のdb.phpは、DB処理を置き換えるドロップインとして使われることがあり、導入したプラグインやホスティング機能と関係します。

確認する対象は次のとおりです。

• wp-config.phpが途中で切れていないか
• wp-includes内のDB関連ファイルが公式版と一致するか
• wp-content/db.phpの提供元と必要性
• 高度なキャッシュやMUプラグインの構成
• 更新中断で不足したコアファイル
• 不審な管理者、ファイル、cron、外部通信

コアを入れ直す場合も、wp-contentとwp-config.phpを上書きしません。現在版に対応するWordPress公式パッケージを使い、ファイルとDBを先に保存します。完全性の確認と更新手順は「WordPressのバックアップ」、改ざんが疑われる場合の初動は「WordPressのセキュリティ対策」で確認できます。

テーマや通常のプラグインが直接このエラー文言を起こしているとは限りませんが、過剰なDB接続や重いクエリによって断続的な障害を誘発することはあります。停止テストはステージングまたは影響を管理できる時間に行います。

ローカル環境でMySQLが停止している場合

Local、XAMPP、Dockerなどのローカル環境では、WordPressより先にDBサービスが起動しているか確認します。パソコンの再起動後、Webサーバーだけ起動し、MySQLやMariaDBが停止したままになることがあります。

ツール別の確認点は次のとおりです。

• XAMPP：コントロールパネルでMySQLの状態と起動ログを見る
• Docker：DBコンテナの状態、ログ、ネットワーク、永続ボリュームを見る
• 専用ローカルアプリ：対象サイト全体がStart状態か確認する
• 手動構築：mysqldまたはMariaDBサービスの状態とポートを見る

ポート3306を別のDBが使っている場合は、起動失敗や別インスタンスへの接続が起こります。DB_HOSTのホスト名とポートを、ツールが生成した設定と照合します。Dockerでは、WordPressコンテナから見たDBホストは通常サービス名であり、ホストPCのlocalhostではありません。

DBが起動しないからといって、データディレクトリやボリュームを削除しないでください。初期化につながる操作の前にコピーを取得し、ログで権限、容量、破損、バージョン不一致を調べます。

攻撃・改ざんが疑われる場合

接続エラー単独では侵害の証拠になりません。ただし、wp-config.phpが知らない値へ変わった、不審な管理者がいる、未知のPHPファイルが増えた、外部通信や大量アクセスと同時に障害が起きた場合は、通常障害と分けてインシデント対応を行います。

初動では次を行います。

1. 現在のファイル、DB、ログを保全する
2. 影響するサイトとアカウントを特定する
3. 管理端末を含めて資格情報の漏えい経路を調べる
4. クリーンな端末からサーバー、DB、WordPressの認証情報を更新する
5. 公式版とのファイル差分、不審なユーザー、タスクを確認する
6. 正常性を確認したバックアップまたは再構築環境へ復旧する

侵害された環境内だけでパスワードを変えると、新しい値も盗まれる可能性があります。ログを消すプラグイン削除や全面上書きの前に証拠を保存し、必要に応じてホスティング、保守担当、法務・個人情報担当へ連絡します。

バックアップから復元する判断基準

復元が適するのは、正常だった日時と復元範囲が分かり、手作業修正より確実に整合性を戻せる場合です。DB接続情報の一文字ミスなら、サイト全体を復元する必要はありません。

状況	優先する対応
DBパスワード変更後	wp-config.phpを正しい値へ更新
ホスティング障害	事業者の復旧を待ち、設定を保つ
テーブル一部破損	バックアップ後に修復または該当DBを復元
更新中断でファイル不整合	正常なコアファイルまたはファイルバックアップを使用
広範な改ざん	正常性を確認した世代から隔離環境へ復旧

復元前に、障害後に増えた注文、投稿、ユーザー、問い合わせを確認します。ファイルだけ戻す、DBだけ戻す、両方を同時点へ戻すのどれが必要かを決め、ステージングで整合性を確認します。

自分で直せない場合にサーバーへ伝える情報

ホスティングへは、接続パスワードそのものではなく、調査に必要な状況を伝えます。サポートが本人確認後に安全な入力欄を案内した場合だけ、その手順に従います。

問い合わせに含める情報は次のとおりです。

• 対象ドメインと契約・サーバー識別情報
• 初回発生日時と断続的か継続的か
• 公開側、管理画面、別サイトの影響範囲
• 直前のDBパスワード変更、移行、更新、復元
• DB_NAMEとDB_HOSTの確認結果。パスワード本文は送らない
• 該当時刻のPHP、Web、DBログ
• 接続上限、DB停止、容量を確認してほしい旨
• 実施済みの操作と結果

「一度直った」「再読み込みで戻る」といった変化も重要です。発生時刻と頻度が分かれば、DB再起動、バックアップ処理、接続上限のログと照合できます。

よくある質問

まとめ

WordPressの「データベース接続確立エラー」は、DBデータの消失ではなく、WordPressがDBへ接続できない状態を示します。まず障害情報と発生範囲を確認し、次にwp-config.phpの4項目、DBユーザーの割当て、負荷・接続上限、テーブル破損の順で調べます。

修復機能を使う場合はDBをバックアップし、終了後にWP_ALLOW_REPAIRを必ず削除してください。初期化や古いバックアップの全面復元へ進む前に、現在のファイル、DB、ログと障害後の差分を保全すると、安全に原因調査と復旧を進められます。