【最短5分】WordPress「データベース接続確立エラー」の直し方｜wp-config設定・サーバー別復旧ガイド

WordPressのサイトを閲覧しようとしたり管理画面にログインしようとした際、突然画面に「データベース接続確立エラー（Error establishing a database connection）」とだけ表示され、サイトが完全に停止してしまってパニックになっていませんか？

このエラーは、WordPressのシステム（PHP）が記事データや設定情報が保存されているMySQL / MariaDBデータベースと通信・接続できなくなったときに発生する非常に重大な障害です。サイト全体が真っ白またはシンプルなエラー画面になり、訪問者も管理者も一切アクセスできなくなります。

「データが消えてしまったのでは…？」と不安になるかもしれませんが、適切な手順で原因を切り分ければ、データを失うことなく最短5分程度で安全に復旧可能です。主な原因は「wp-config.phpの認証ミス」「サーバー別DB_HOSTの指定違い」「テーブルの破損」「アクセス急増による接続数上限（Too many connections）」などに絞られます。

本ガイドでは、画面の前で困っている方が即座にサイトを復旧できるよう、原因を特定する最短切り分けフローから、エックスサーバー/ConoHa WING/さくら等のサーバー別DB_HOST設定一覧、phpMyAdminやWP_ALLOW_REPAIRによるDB自動修復、Too many connectionsの緊急緩和策まで図解・コード付きで徹底解説します。

【最短5分】データベース接続確立エラーの原因特定フローチャート＆即時診断

データベース接続確立エラーが発生したときは、やみくもにファイルをいじるのではなく、「直前に何をしたか」「管理画面とフロント画面のどちらで起きているか」によって原因を絞り込むのが最短復旧の鉄則です。

原因1：wp-config.php の認証情報ミスを確認・修正する

WordPressがデータベースに接続する際のログイン情報（データベース名、ユーザー名、パスワード、ホスト名）は、WordPressルートディレクトリ直下にある wp-config.php にすべて記述されています。この4項目のうち1文字でも間違っていると接続エラーになります。

wp-config.php の重要4項目と設定コード例

FTPソフト（FileZilla等）またはサーバーのファイルマネージャーから wp-config.php を開き、以下の定義箇所（MySQL設定部分）を確認します。

// ** MySQL 設定 - この情報はホスティング先から入手してください。 ** //
/** WordPress のためのデータベース名 */
define( 'DB_NAME', 'database_name_here' );

/** MySQL データベースのユーザー名 */
define( 'DB_USER', 'username_here' );

/** MySQL データベースのパスワード */
define( 'DB_PASSWORD', 'password_here' );

/** MySQL のホスト名 */
define( 'DB_HOST', 'localhost' );

/** データベースのテーブルを作成する際のデータベースの文字セット */
define( 'DB_CHARSET', 'utf8mb4' );

/** データベースの照合順序 (ほとんどの場合は空のまま) */
define( 'DB_COLLATE', '' );

よくある入力ミスと4つのチェックポイント

1. 前後に不要な半角スペースや改行が混入している
   パスワードやユーザー名をコピー＆ペーストした際、末尾に目に見えない空白が含まれてしまうケースが多発しています。シングルクォーテーションの内側を慎重に確認してください。
2. 全角文字や全角スペースが紛れ込んでいる
   クォーテーション記号が全角（’ や ”）になっていないか、行末のセミコロン（;）が抜けていないか確認します。
3. ユーザーに対するデータベース権限が付与されていない
   データベースユーザーを作成しただけで、対象のデータベースに対する「全権限（ALL PRIVILEGES）」を結びつけていないとアクセスが拒否されます。サーバー管理画面のDB設定でユーザーの権限設定を確認してください。
4. プレフィックス（接頭辞）付きのDB名・ユーザー名になっていない
   共有レンタルサーバーでは、DB名やユーザー名に アカウント名_wp1 のようにプレフィックスが自動付与される仕様が一般的です。指定漏れがないか確認しましょう。

【サーバー別】wp-config.php の「DB_HOST」設定一覧と確認手順

初心者が最もつまずきやすいのが DB_HOST の設定です。「データベースサーバー＝localhost」と思い込みがちですが、多くの国内主要レンタルサーバーではデータベース専用サーバーが別ホストに分離されており、専用のホスト名（またはIPアドレス）を指定する必要があります。

1. エックスサーバー・ConoHa WING・さくら・ロリポップの設定値

主要レンタルサーバー各社の DB_HOST の仕様と、サーバー管理画面での確認場所は以下の通りです。

レンタルサーバー名	DB_HOSTの指定値例	管理画面での確認手順・注意事項
エックスサーバー (Xserver)	mysqlXXXX.xserver.jp	サーバーパネル ＞「データベース」＞「MySQL設定」画面の最下部にある「MySQL5.7/8.0 ホスト名」を確認。localhost では接続できません。
ConoHa WING	localhost または dbXXXX.conoha.ne.jp	コントロールパネル ＞「サイト管理」＞「データベース」＞ 対象DBを選択 ＞「接続先サーバー」を確認。プランや環境により localhost または専用ホスト名になります。
さくらのレンタルサーバ	mysqlXXXX.db.sakura.ne.jp	サーバコントロールパネル ＞「Webサイト/データ」＞「データベース」＞ データベース一覧の「サーバ」欄に記載されたホスト名を指定。
ロリポップ！ (LOLIPOP!)	mysqlXXX.phy.lolipop.lan または mysqlXXX.phy.lolipop.jp	ユーザー専用ページ ＞「サーバーの管理・設定」＞「データベース」＞ データベース一覧の「サーバー」欄を確認。
mixhost	localhost	cPanel採用のサーバーでは通常 localhost で動作します。
シン・レンタルサーバー	mysqlXXXX.shin-server.jp	サーバーパネル ＞「MySQL設定」最下部のホスト名を確認。

2. localhost と 127.0.0.1 の違いによる接続エラーの回避

ローカル開発環境（Docker, Local by Flywheel, XAMPP, MAMP）や自作VPS/クラウド環境で構築している場合、localhost と 127.0.0.1 の通信方式の違いが原因で接続エラーが発生することがあります。

• localhost を指定した場合：PHPはMySQLとの通信にUNIXドメインソケット（例：/var/run/mysqld/mysqld.sock または /tmp/mysql.sock）を使用します。ソケットファイルのパスが一致していないと接続に失敗します。
• 127.0.0.1 を指定した場合：PHPはTCP/IPループバック通信（ポート3306）を経由してMySQLに接続します。

// ソケット不一致でエラーになる場合、127.0.0.1 に切り替える
define( 'DB_HOST', '127.0.0.1' );

// カスタムポート（例：3307ポート）を使用している場合
define( 'DB_HOST', '127.0.0.1:3307' );

// ソケットパスを直接指定する場合
define( 'DB_HOST', 'localhost:/path/to/mysql.sock' );

「localhostでどうしても繋がらない」「Docker環境でDBコンテナとWebコンテナが別れている」という場合は、DB_HOST を 127.0.0.1 またはコンテナサービス名（db など）に書き換えることで即座に解決することが多々あります。

【テスト用コード】PHP単体でのDB接続確認（test-db.php）

WordPressの読み込みを介さずに、サーバー上のPHPからMySQLへ正しくログインできるかを直接テストするスクリプトです。以下のコードを test-db.php としてWordPressの公開フォルダにアップロードし、ブラウザから https://example.com/test-db.php にアクセスしてください。

<?php
/**
 * データベース接続テスト用スクリプト (test-db.php)
 * ※確認後は必ずサーバーから削除してください！
 */
error_reporting(E_ALL);
ini_set('display_errors', 1);

// wp-config.php と同じ値を入力してテスト
$db_host = 'localhost'; // またはサーバーのDBホスト名
$db_name = 'database_name';
$db_user = 'database_user';
$db_pass = 'database_password';

echo "<h2>MySQL接続テスト実行中...</h2>";

try {
    $dsn = "mysql:host={$db_host};dbname={$db_name};charset=utf8mb4";
    $pdo = new PDO($dsn, $db_user, $db_pass, [
        PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
        PDO::ATTR_TIMEOUT => 5,
    ]);
    echo "<p style='color:green;font-weight:bold;'>【成功】データベースに正常に接続できました！</p>";
    echo "<p>MySQLサーバーバージョン: " . $pdo->getAttribute(PDO::ATTR_SERVER_VERSION) . "</p>";
} catch (PDOException $e) {
    echo "<p style='color:red;font-weight:bold;'>【失敗】接続できませんでした。</p>";
    echo "<p>エラーコード: " . $e->getCode() . "</p>";
    echo "<p>エラー詳細: " . htmlspecialchars($e->getMessage(), ENT_QUOTES, 'UTF-8') . "</p>";
}
?>

phpMyAdminを使ったデータベーステーブルの修復・最適化手順

「管理画面（/wp-admin/）にアクセスしたときだけ『1つ以上のデータベーステーブルが利用できません』と表示される」「突然記事の投稿や保存ができなくなった」という場合は、データベース内の特定テーブル（wp_posts や wp_options など）が異常終了や強制停止によって破損している可能性が高いです。

1. GUIから破損テーブルをチェックしてワンクリック修復する方法

サーバー各社のコントロールパネルから「phpMyAdmin」にログインし、GUI（管理画面）から安全にテーブルを修復・最適化する手順です。

1. phpMyAdminにログイン：レンタルサーバーの管理画面（エックスサーバーならサーバーパネル、ConoHaならコントロールパネル）からphpMyAdminを起動します。
2. 対象データベースを選択：画面左側のツリー一覧から、該当のWordPressデータベース名をクリックします。
3. 全テーブルを選択：右側にテーブル一覧（wp_posts, wp_options, wp_comments 等）が表示されたら、下部にある「すべてチェックする（Check all）」にチェックを入れます。
4. 修復を実行：ドロップダウンメニュー（「チェックしたものを:」）から「テーブルを修復する（Repair table）」を選択します。
5. 結果を確認：各テーブルの実行ステータスが表示され、「OK」または「Table is already up to date」となれば修復成功です。
6. （推奨）最適化を実行：続けてドロップダウンから「テーブルを最適化する（Optimize table）」を実行すると、無駄なオーバーヘッド領域が解放されクエリ速度が改善します。

2. 「WP_ALLOW_REPAIR」を使った自動修復の手順と作業後の必須削除処理

phpMyAdminにログインできない場合や、FTPしか操作権限がない環境では、WordPress標準搭載の自動データベース修復機能（WP_ALLOW_REPAIR）を利用するのが最も手軽で強力です。

【手順1】wp-config.php に修復フラグを追記する
FTPで wp-config.php を開き、/* 編集が必要なのはここまでです ! */（または /* That's all, stop editing! Happy publishing. */）という行の直前に次の1行を追加します。

/** WordPress標準データベース自動修復モードの有効化 */
define( 'WP_ALLOW_REPAIR', true );

【手順2】修復用URLにブラウザからアクセスする
ファイルを保存・アップロードしたら、Webブラウザで次のURLにアクセスします。

https://あなたのサイトのドメイン/wp-admin/maint/repair.php

画面に「データベースの修復（Repair Database）」ボタンと「データベースの修復と最適化（Repair and Optimize Database）」ボタンが表示されます。通常は「データベースの修復と最適化」をクリックすれば、WordPressが破損したテーブルを自動検出して一括修復してくれます。

アクセス急増・サーバー高負荷による「Too many connections」の緊急対処法

WebサイトがSNSでバズった時、テレビや大手メディアに掲載された時、あるいは悪質なボットによるスクレイピング攻撃を受けた時に発生するのが、MySQLの同時接続数上限オーバー（Too many connections）によるデータベース接続確立エラーです。

MySQLサーバーは設定された同時接続数の上限（デフォルトで100〜151程度）に達すると、それ以上の新規接続リクエストを拒否してエラーを返します。この状態を緊急で打破し、再発を防止する手順を解説します。

1. スリープ接続の強制終了とプロセスリスト確認

VPSやクラウド環境（SSH接続可能）では、MySQLにログインして溜まっているスリーププロセスや遅延クエリを強制終了（KILL）して接続枠を即時解放します。

-- 現在の接続プロセスを確認
SHOW FULL PROCESSLIST;

-- 滞留しているプロセスを強制終了（IDは上記一覧で確認）
KILL 12345;

2. max_connections の一時引き上げ

MySQLの設定ファイル（/etc/my.cnf または /etc/mysql/my.cnf）で同時接続数の最大値を引き上げます。サーバーの搭載メモリ量に応じて適切な値を設定します（メモリ1GBあたり100〜150接続が目安）。

[mysqld]
# 同時接続上限を300に引き上げ
max_connections = 300

# スリープ状態のアイドル接続タイムアウトを短縮（デフォルト28800秒→60秒）
wait_timeout = 60
interactive_timeout = 60

設定変更後、データベースサービスを再起動します。

sudo systemctl restart mysqld
# または MariaDBの場合
sudo systemctl restart mariadb

3. ページキャッシュとCDN導入によるDB負荷の95%削減

共有レンタルサーバーでは my.cnf の設定変更ができないため、「そもそもリクエストがデータベースまで到達しない仕組み」を構築することが唯一にして最強の解決策です。

• ページキャッシュプラグインの導入：WP Super Cache や LiteSpeed Cache を有効化し、HTMLを静的ファイルとしてキャッシュします。これによりアクセス急増時もDBへのクエリ発生を激減させます。
• CloudflareなどのCDNの活用：エッジサーバーで静的HTML・画像をキャッシュして配信することで、オリジンサーバーのCPU/メモリ負荷を90%以上カットします。
• WAF（Web Application Firewall）による海外ボット遮断：サーバー付属のWAF設定をONにし、悪意のあるブルートフォース攻撃やスクレイピングボットの不正リクエストをWebサーバー到達前に遮断します。

原因4：DBサーバーの停止・ホスティング障害の切り分け手順

設定ミスでも負荷急増でもない場合、物理的なDBサーバー自体のダウンやホスティング事業者側の障害が疑われます。

1. 共有レンタルサーバーでの確認手順

1. ホスティング会社の障害・メンテナンス情報を確認：エックスサーバー、さくらインターネット、ConoHa等の「障害・メンテナンス情報」ページを開き、自分が収容されているサーバー番号で障害が発生していないか確認します。
2. サーバーパネルからDBにアクセスできるか確認：サーバー管理画面の「phpMyAdmin」にログインできるか試します。phpMyAdminすらログインできない場合はサーバー側でDBデーモンが完全にダウンしています。
3. ディスク容量の残量確認：サーバーのディスク容量が100%に達していると、MySQLが一時ファイルやトランザクションログを書き込めず緊急停止します。不要なバックアップファイルを削除して容量を確保してください。

2. VPS / 専用サーバー / クラウドでのDB再起動手順

自社管理のVPS（KUSANAGI、ConoHa VPS、AWS EC2/RDSなど）の場合は、SSHからエラーログを確認し、サービスを再起動します。

# MySQL/MariaDBの稼働ステータス確認
sudo systemctl status mysqld

# エラーログの末尾を確認
sudo tail -n 50 /var/log/mysql/error.log
# または
sudo tail -n 50 /var/log/mysqld.log

# サービス再起動
sudo systemctl restart mysqld

原因5：WordPressコア破損やプラグイン競合への対処

極めて稀ですが、データベースを直接操作する最適化プラグインやセキュリティプラグインの更新失敗、またはWordPressコアファイルの不完全な更新によって接続機能が破損することがあります。

1. FTP経由での全プラグイン一時無効化

FTPソフトで /wp-content/ ディレクトリを開き、plugins フォルダの名前を plugins_old に一時的にリネームします。これで全プラグインが強制停止します。この状態でサイトを再読み込みし、接続エラーが解消されればプラグインの競合が原因です。

2. WordPressコアファイルの再配置

WordPress公式サイトから最新バージョンのZIPファイルをダウンロードして解凍し、wp-config.php と wp-content フォルダ以外のコアファイル（wp-admin, wp-includes, ルート直下のPHPファイル）を上書きアップロードします。これにより壊れたコアファイルがクリーンに修復されます。

シナリオ別：よくあるシチュエーションごとの対処法

発生シチュエーション	最も疑われる原因	最短解決アクション
サーバー移行・ドメイン変更の直後	新サーバーのDB_HOST指定違い、DBユーザーへの権限付与忘れ	新サーバーのMySQLホスト名を確認し、wp-config.php を更新。サーバーパネルでDBユーザーにアクセス権限を付与。
プラグインや本体の自動更新直後	更新処理中のタイムアウトによるテーブル破損、古いキャッシュプラグインの競合	WP_ALLOW_REPAIR によるテーブル修復を実行。FTPでプラグインフォルダを一時リネーム。
SNSバズ・アクセス急増時	MySQLの同時接続数上限（Too many connections）超過	MySQLのプロセスKILL・再起動。ページキャッシュプラグインおよびCDN（Cloudflare）を即時有効化。
ローカル開発環境（Docker, Local）	ポート競合（3306）、ソケット通信の不一致	DB_HOST を localhost から 127.0.0.1 または 127.0.0.1:3307 に変更。コンテナ再起動。

ホスティング会社への問い合わせ手順とコピペ用テンプレート

上記の手順をすべて試しても復旧せず、サーバーパネルのphpMyAdminにも接続できない場合は、サーバー事業者側のハードウェア障害や内部プロセスのハングアップが原因です。以下のテンプレートをコピーしてサポート窓口に問い合わせてください。

件名：【至急】データベース接続確立エラー発生に伴うサーバー稼働状況の確認依頼

お世話になっております。貴社サーバーを利用している [ご契約者名 / アカウント名] です。

現在、管理しているWordPressサイトにおいて「データベース接続確立エラー（Error establishing a database connection）」が発生し、サイトおよび管理画面が完全に停止しております。

■ 発生状況
・対象ドメイン：https://example.com/
・サーバー番号：svXXXX.xserver.jp（またはアカウントID）
・発生確認日時：202X年X月X日 XX:XX頃
・表示エラー：「データベース接続確立エラー」

■ こちらで確認済みの事項
1. wp-config.php のDB名、DBユーザー名、DBパスワード、DBホスト名に誤りがないことを確認
2. テスト用PHPスクリプトによるDB接続を試みましたが接続不能
3. コントロールパネルからのphpMyAdminログインも接続エラー（またはタイムアウト）となる状態

恐れ入りますが、該当データベースサーバーの稼働状態、障害発生の有無、またはプロセスのハングアップ等が発生していないか至急ご確認いただけますでしょうか。
何卒よろしくお願い申し上げます。

二度とエラーを起こさないための再発防止・恒久対策

1. 自動バックアップ体制の二重化：プラグイン（UpdraftPlus等）による日次クラウドバックアップに加え、サーバー標準の自動バックアップ（エックスサーバーやConoHaの過去14日間復元機能など）を必ず有効にしておきます。
2. 定期的なDBテーブル最適化と不要データ削除：リビジョンデータ、自動保存下書き、期限切れのTransient（一時データ）、スパムコメントを定期的にクリーンアップし、データベースの肥大化を防ぎます。
3. wp-config.php のアクセス権限（パーミッション）厳格化：wp-config.php のパーミッションを 400 または 440（さくら等の環境では 600）に設定し、第三者からの閲覧・改ざんを防御します。
4. サイト死活監視とリソースアラートの導入：UptimeRobotやサーバー監視ツールを活用し、ダウン発生時に即座にメールやSlackへ通知が届く体制を整えます。

まとめ：焦らずチェックリスト順に特定すれば必ず直る

「データベース接続確立エラー」は突然画面全体が非表示になるためショックが大きいトラブルですが、データベースそのものが消去されているケースは極めて稀です。焦らず以下の優先順位で原因を特定していきましょう。

1. 直前の作業確認：設定変更や移転直後なら wp-config.php の4大項目（特にサーバー別 DB_HOST）を再確認。
2. 管理画面のみのエラー：WP_ALLOW_REPAIR または phpMyAdmin でテーブル破損を自動修復。
3. アクセス集中時：MySQLプロセスの解放とキャッシュ/CDNの導入。
4. 突然のダウン：サーバー障害情報の確認またはホスティングサポートへの連絡。

トラブルを速やかに解消し、万全のバックアップとセキュリティ対策を施して安定したWordPress運用を続けましょう！

📚 あわせて読みたい関連記事

• 【図解】WordPressの500エラー（Internal Server Error）原因と直し方｜突然の白画面を最短復旧する手順
• WordPressの403 Forbiddenエラー原因と直し方完全ガイド｜管理画面・記事保存時のWAF解除から.htaccess・パーミッション復旧まで
• 【即時復旧】WordPressにログインできない原因と解決策｜4大障害別切り分けフローチャート
• WordPressが突然真っ白に…よくある原因とすぐできる対処法
• WordPress バックアップと復元の方法｜トラブル時に最速で戻すコツ
• WordPressの推奨パーミッション設定完全ガイド｜ファイル・ディレクトリ別の適切な権限と変更手順・セキュリティ対策
• WordPressの定期更新チェックリスト｜放置リスクを防ぐ5つの習慣