DB接続エラーの直し方：WordPressで「データベースに接続できない」ときの確認手順
WordPress や Web アプリで「Cannot connect to database」「Error establishing a database connection」のような表示が出たとき、最初に見るべき場所はコード本体ではなく、接続情報・DBサーバーの起動状態・権限です。
このエラーは、PHP や WordPress がデータベースへ問い合わせる前の段階で止まっている状態です。投稿データや設定が消えたとは限りません。慌てて再インストールする前に、接続経路を順番に切り分けます。
この記事では、WordPress を例にしながら、DB接続エラーで最低限確認するポイントを実務向けに整理します。
- まず
wp-config.phpの DB名・ユーザー名・パスワード・ホスト名を確認する - 次に MySQL / MariaDB が起動しているか、サーバー側から接続できるかを見る
- 最後にユーザー権限、ホスト指定、ポート、ログを確認する
- 認証情報は画面共有・チャット・ログにそのまま貼らない
前提環境：この記事で扱う範囲
この記事は、WordPress を中心に、PHP アプリや管理画面つき CMS でよく見る DB 接続エラーを対象にします。
想定する環境は次の通りです。
- WordPress サイト
- MySQL または MariaDB を使うレンタルサーバー、VPS、ローカル開発環境
wp-config.phpを確認できる権限がある- SSH、サーバーパネル、phpMyAdmin など、いずれかの確認手段がある
WordPress 公式ドキュメントでは、wp-config.php は WordPress の基本設定を持つ重要なファイルで、データベース接続情報もここに含まれると説明されています。つまり WordPress の DB 接続エラーでは、まずこのファイルが起点になります。
ここがポイント: DB接続エラーは「WordPressの投稿が壊れた」という意味ではありません。多くの場合、WordPress から DB サーバーへ入るための住所、鍵、権限のどこかが合っていません。
まず見るべき4つの接続情報
DB接続エラーの初動では、原因を広げすぎず、wp-config.php の4項目を確認します。
WordPress では、代表的に次のような定義があります。
/** The name of the database for WordPress */
define( 'DB_NAME', 'example_db' );
/** Database username */
define( 'DB_USER', 'example_user' );
/** Database password */
define( 'DB_PASSWORD', 'example_password' );
/** Database hostname */
define( 'DB_HOST', 'localhost' );
それぞれの意味は単純です。
DB_NAME: 接続先のデータベース名DB_USER: データベースに入るユーザー名DB_PASSWORD: そのユーザーのパスワードDB_HOST: データベースサーバーの場所
よくある間違い
特に多いのは、移行や複製のあとに古い接続情報が残るケースです。
- 本番サーバーへ移したのに、ローカル環境の DB 名が残っている
- サーバーパネルで作った DB ユーザーと、
wp-config.phpのユーザー名が違う - パスワード再発行後に WordPress 側だけ更新していない
localhostではなく、レンタルサーバー指定の DB ホスト名が必要DB_HOSTにポート番号が必要な環境なのに省略している
DB_HOST は環境差が出やすい項目です。一般的には localhost が使われますが、レンタルサーバーでは mysql.example.ne.jp のような専用ホスト名を指定することがあります。サーバーパネルの「MySQL設定」「データベース情報」に表示される値と照合してください。
接続確認はサーバー側から試す
設定ファイルを見ても原因が分からない場合は、WordPress を経由せずに DB へ直接接続できるかを確認します。
SSH が使える環境なら、次のように MySQL クライアントで試せます。
mysql -h localhost -u example_user -p example_db
-p の後にパスワードを直接書かず、プロンプトが出てから入力します。履歴やログにパスワードを残しにくくするためです。
接続できる場合は、次のようなプロンプトに入ります。
mysql>
接続できない場合は、エラーメッセージが切り分けの材料になります。
ERROR 1045 (28000): Access denied for user 'example_user'@'localhost'
この場合は、ユーザー名、パスワード、接続元ホスト、権限のどれかが合っていない可能性が高いです。
ERROR 2002 (HY000): Can't connect to local MySQL server through socket
この場合は、MySQL サーバーが起動していない、ソケットやホスト指定が違う、コンテナや仮想環境の接続先が違う、といった方向で確認します。
ポートだけ確認したい場合
VPS や Docker 構成では、DB サーバーのポートに到達できるかを見るだけでも有効です。
nc -vz 127.0.0.1 3306
成功例は環境によって表示が違いますが、接続できれば succeeded や open に近い結果になります。失敗する場合は、DB が起動していない、ポートが違う、ファイアウォールで止まっている、別コンテナ名を指定すべき、などを疑います。
原因別の見分け方
DB接続エラーは、表示だけ見ると同じに見えます。実務では「どこまで届いているか」で分けると早くなります。
| 症状 | よくある原因 | 最初に見る場所 |
|---|---|---|
| パスワード変更後に急に表示 | WordPress 側のパスワード未更新 | DB_PASSWORD |
| 移行直後だけ表示 | DB名、ユーザー名、ホスト名の移行漏れ | wp-config.php とサーバーパネル |
| 全サイトで同時に表示 | DBサーバー停止、メンテナンス、障害 | サーバー状態、ホスティングのお知らせ |
| 一部の環境だけ表示 | 接続元ホストの権限不足 | DBユーザーの権限、許可ホスト |
| Dockerやローカルだけ表示 | localhost の指す先が違う | コンテナ名、ネットワーク設定 |
特に見落としやすいのは、localhost の意味です。WordPress が動いている場所から見た localhost は、その WordPress が動くサーバー自身を指します。Docker で PHP コンテナと MySQL コンテナが分かれている場合、localhost ではなく db のようなサービス名を指定する構成があります。
WordPressで確認する手順
ここでは、作業順を実務向けに並べます。重要なのは、変更する前に現在値を控えることです。
1. 画面のエラー文を確認する
まず、表示されているエラー文をそのまま確認します。
WordPress では、代表的に「Error establishing a database connection」と表示されます。日本語環境では「データベース接続確立エラー」のような表示になることもあります。
この時点で、プラグインやテーマを疑う前に DB 接続を見ます。テーマの PHP エラーなら別のメッセージやログになることが多いためです。
2. wp-config.php とサーバーパネルを照合する
wp-config.php の4項目を、サーバーパネルのデータベース設定と照合します。
確認する順番は次の通りです。
- DB名が完全一致しているか
- DBユーザー名が完全一致しているか
- パスワードを変更した履歴がないか
- DBホスト名がサーバー指定の値になっているか
- 必要なら
localhost:3306のようにポート指定が必要か
パスワードは画面に表示されないこともあります。その場合は、既存値を推測せず、必要に応じてサーバーパネルで再設定し、wp-config.php 側も同じ値にそろえます。
3. DBサーバーの起動状態を見る
VPS などで管理者権限がある場合は、DB サーバーが起動しているかを確認します。
systemctl status mysql
MariaDB の場合は次の名前になっていることがあります。
systemctl status mariadb
レンタルサーバーでは systemctl を使えないことが多いため、サーバーパネルの障害情報やデータベース管理画面に入れるかを見ます。phpMyAdmin にも入れないなら、WordPress だけの問題ではなく DB 側の問題に近づきます。
4. ログを見る
WordPress 側のデバッグログやサーバーのエラーログも手がかりになります。
ただし、本番サイトでエラーを画面に表示する設定は避けます。WordPress 公式ドキュメントでも、公開環境ではエラーを画面に出すのではなくログへ送る考え方が示されています。
調査用に設定する場合の例です。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
調査が終わったら、公開環境では設定を戻す、ログファイルの公開範囲を確認する、不要なログを削除する、といった後始末も必要です。ログにはパスや SQL、プラグイン名など、外部に見せたくない情報が含まれる場合があります。
NG例と改善例
DB接続エラーでは、急いでいるほど危ない対応をしがちです。よくある NG と、より安全な進め方を分けておきます。
NG例：WordPressを再インストールする
接続できないだけの状態で再インストールすると、既存データとの対応関係を壊すおそれがあります。
改善例は、先に wp-config.php と DB の存在を確認することです。DB に投稿テーブルが残っているなら、復旧すべき対象は「WordPress本体」ではなく「接続設定」です。
NG例：パスワードをチャットに貼る
認証情報をそのまま共有すると、後から履歴に残ります。
改善例は、伏せ字にして共有することです。
DB_USER: wp_example
DB_PASSWORD: 先頭2文字と末尾2文字だけ確認済み
DB_HOST: mysql.example.ne.jp
チームで作業する場合は、パスワードそのものではなく「サーバーパネルで再発行した」「設定ファイルへ反映した」「接続テストに成功した」という作業結果を共有します。
NG例：localhost を決め打ちする
localhost は便利ですが、すべての環境で正解ではありません。
改善例は、DB がどこで動いているかを見ることです。
- 同一サーバーの MySQL:
localhostの可能性が高い - レンタルサーバー指定の DB: 専用ホスト名を使うことがある
- Docker Compose: MySQL サービス名を使うことがある
- 外部DB: ホスト名、ポート、接続許可IPが必要になる
代替手段と関連ツール
接続情報の確認方法は、環境によって変わります。SSH が使えないから調査できない、というわけではありません。
- サーバーパネル: DB名、ユーザー、ホスト名、パスワード再設定を確認しやすい
- phpMyAdmin: DBが存在するか、ユーザーでログインできるかを確認しやすい
- SSH +
mysqlコマンド: WordPress を通さず接続確認できる - WP-CLI: WordPress 側の設定や状態をコマンドで確認しやすい
- Docker Compose: サービス名、ネットワーク、環境変数の確認が重要になる
初心者向けには、まずサーバーパネルと wp-config.php の照合が現実的です。SSH が使えるなら、mysql コマンドで WordPress の外側から接続確認すると、原因の場所をかなり絞れます。
復旧前に確認するチェックリスト
最後に、実際の作業で使える形にまとめます。
wp-config.phpのバックアップを取ったかDB_NAMEはサーバーパネルの DB 名と一致しているかDB_USERはその DB に権限を持つユーザーかDB_PASSWORDは最新の値かDB_HOSTは環境に合っているか- MySQL / MariaDB は起動しているか
- phpMyAdmin や
mysqlコマンドで直接接続できるか - ログを確認したあと、公開環境向けの設定に戻したか
- パスワードやログを外部に貼っていないか
DB接続エラーで次に見るべき分岐点は、「WordPress だけが接続できないのか」「DB サーバー自体に入れないのか」です。前者なら wp-config.php と権限、後者なら DB の起動状態やサーバー側の障害を優先して確認します。