504エラー（504 Gateway Timeout）の原因と対処法

今朝、自分の別ブログにログインしようとしたら、表示されませんでした。真っ黒。

かなりの時間を要して、「504」という数字が表示されました😱😱😱

その際に試したことや見られた症状は、以下です。

• アクセスしたら画面が真っ黒のまま表示されない
• ログイン画面もブログのホーム画面も表示されない
• PCを再起動しても表示できない
• ルーターをリセットしても表示できない
• 同じサーバー上のほかのブログは閲覧可能
• 数分ののち、504エラーが出た

この記事は、504が出る原因と、今回の場合の対処法をメモするものです。

• 今回の原因
• 原因の除去方法とクリーンアップ
• 原因究明のやり方

の順でお送りします。

結論：「Broken Link Checker」が悪さをしていた

504エラー（504 Gateway Timeout）は、サーバーが応答処理に時間をかけすぎてタイムアウトしている状態です。

今回の結論としては、リンク切れを知らせてくれるプラグイン「Broken Link Checker」が原因でした。

データベースを更新しようとした際に発生している処理の停止・競合によってページが表示できなくなっていたのです。

「Broken Link Checker」は便利なプラグインですが、頻繁にブログ内を徘徊してリンク切れを探す性質上、ページが重くなる原因にもなりかねません。

でも、参考URLなどを多く表示しているブログのため、リンク切れは問題かなと思い設置していました。

プラグインなら、WordPressのダッシュボードに常に表示されるので、面倒がないんですよね。

でも今回は、常駐していたそれがなんらかの原因で古いデータと衝突して、ページの表示自体をできなくさせていました。

エラーログの見方などは記事の最後のほうでやってます。
＞＞原因究明：エラーの原因を見つける

処置①「Broken Link Checker」の稼働を停止させる

ダッシュボードにログインできない状態なので、サーバーでなんとかします。

この方法は、プラグインが原因で504になっている場合の対処法です。ほかのプラグインが原因の場合にも流用できると思います。

また、エックスサーバーでの処理ですが、プラグインの無効化（強制停止）のやり方はほかのサーバーでも参考にできると思います。

プラグインを無効化する

今回は管理画面も開けないので、FTPツールまたはサーバーのファイルマネージャーから強制無効化します。

ツールは消してしまったので、エックスサーバーのファイルマネージャーから処理します。

①サーバーのファイルマネージャーに入る

エックスサーバーにログイン　＞　サーバー管理　＞　FTPアカウント設定　＞　管理

②プラグインが入っているフォルダに移動する

/example.com/public_html/wp-content/plugins

へ移動します。

③プラグインの名前を変更する

broken-link-checker というフォルダ名を、一時的に _broken-link-checker などに変更（名前変更）します。

④アクセスできるかを確認する

これでプラグインが強制停止されるので、ブログにアクセスして504エラーが解消されたか確認してください。

処置②「Broken Link Checker」を削除する

サイトが開くようになったら、問題の根本原因をクリアします。

フォルダ名を変更して強制停止した状態だと思うので、管理画面の「プラグイン」ページを開くと上部に赤っぽく「プラグインファイルが存在しないため無効化されました」といったメッセージが出ていると思います。

でも実際には名前を変更した状態のプラグインが残っています。

_broken-link-checker

などのように「 _ 」を頭につけた場合は、一番上にあるはず。

最初にそれを削除しましょう。

Broken Link Checker「ローカル版」を使い続ける場合

プラグインを一度削除し、新規検索・再インストールします。

「ローカル版」の使用を開始すると、データベースのテーブルが綺麗に再生成されます。

ただし、Broken Link Checkerのローカル版はデータベースに強い負荷をかけるため、504エラーの原因になりやすいプラグインです。

もし使い続ける場合は、クラウド版にしたほうが安心かもしれません。

Broken Link Checker「クラウド版」を使い続ける場合

プラグインを一度削除し、新規検索・再インストールします。

デフォルトで「クラウド版」になっています。

リンクエラーの数は見ることができますが、細かな情報は外部サイトでのみ閲覧できます。

VIEW FULL REPORT　というボタンを押すと、外部サイトへ移動しますので、そこで確認しましょう。

なぜクラウド版では今回のようなトラブルが起こらないのか？

今回のトラブルの直接の原因は、「自分のサーバーのデータベース内（wp_blc_links テーブル）でデータが重複してエラーになり、それを解決しようと処理が暴走したこと」でした。

クラウド版（WPMU DEVが提供する新しいBroken Link Checker）では、仕組みが以下のように変わります。

• CPU・メモリを消費しない
  • サイト内の全ページを巡回してリンクが切れていないか調べる「重い計算処理」は、すべて外部のクラウド側で行われます。自分のサーバーは「結果を受け取るだけ」になるため、504 Gateway Timeout（サーバー応答なし）を引き起こすような負荷がかかりません。
• データベースを使わない
  • リンクのチェック結果やデータは、すべてWPMU DEV側の外部クラウドサーバーに保存されます。自分のデータベース内にテーブルを作らないため、今回のようなDBエラーや重複エラーは構造上発生しません。

結果として、今回のようなトラブルが起こらず、ページ読み込みへの負荷もほぼなくなるようです。

クリーンアップはどうする？

クラウド版ではテーブル（データ領域）の上書きのようなことは起こらないため、データベースの残りカスみたいなものはそのままになります。

もろもろを完全にクリーンにしたい場合は、次の項目「データベースのクリーンアップ（アクセス復旧後）」の手順を踏む必要があります。

データベースのクリーンアップ（アクセス復旧後）

プラグインを削除（アンインストール）しただけでは、データベースのゴミ（テーブル）は残ったままになることが多いです。

• Broken Link Checkerの「クラウド版」を使う
• Broken Link Checkerの使用をやめる

上記の場合で完全にクリーンな状態にしたい場合は、もう少しだけ作業が必要になります。

データベース管理ツール（phpMyAdmin）から直接消す

もし「もうプラグインを有効化したくない」「手動で消したい」という場合は、サーバーの管理画面にある phpMyAdmin から直接消すことができます。

エックスサーバーの場合の手順を説明します。

※データベースを直接触る場合は、念のため事前にバックアップを取ってから行うのが安全です。

なぜゴミが残ってしまうの？

WordPressのプラグイン（特にBroken Link Checkerのような大型プラグイン）は、安全のために「誤ってプラグインを消してしまってもデータが消えないようにする」仕組みになっています。

そのため、管理画面から「無効化 ➔ 削除」としても、データベースの中に作られた wp_blc_links などの専用テーブル（データ領域）はそのまま残り続けてしまいます。

そのままでも大丈夫？

「残ったまま放置したらどうなるの？」と思うかもしれませんが、プラグイン自体を削除（またはフォルダ名変更で強制停止）していれば、プログラムは実行されないので504エラーが再発することはもうありません。

ただ、使わないデータがデータベースに数MB〜数十MB残ったままになるだけです。

もし「完全にスッキリさせたい！」ということであれば、上記の手順でキレイさっぱりクリーンアップしておくのが一番安心でカンタンです！

原因究明：エラーの原因を見つける

エラーログの確認・ダウンロード手順

エックスサーバーでの確認方法です。

1. エックスサーバーの「サーバーパネル」にログインする
   • 管理画面（共通アカウント管理）から対象サーバーの「サーバーパネル」を開きます。
2. 「エラーログ」メニューを開く
   • 画面内の 「アクセス解析」 項目にある 「エラーログ」 をクリックします。
3. ドメインを選択する
   • エラーが発生しているサイトのドメイン（例: example.com）の横にある 「選択する」 をクリックします。
4. ログをダウンロードする
   • 「エラーログのダウンロード」 ボタンをクリックすると、テキストファイル（.log）がパソコンに保存されます。

ダウンロードしたファイルをメモ帳などで開き、直近のエラー情報を確認します。

①エラーログ

今回のエラーログの最新の部分は以下の通り。

[Thu Aug 06 10:11:49.XXXXXX 2026] [proxy_fcgi:error] [pid XXXXXX:tid XXXXXX] [client xxx.xxx.xxx.xxx:xxxxx] AH01071: Got error 'PHP message: WordPress database error Duplicate entry '' for key 'url_hash' for query ALTER TABLE `wp_blc_links` ADD UNIQUE KEY `url_hash` (`url_hash`) made by require('wp-blog-header.php'), require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('init'), WP_Hook->do_action, WP_Hook->apply_filters, blc_init, blcDatabaseUpgrader::upgrade_database, blcDatabaseUpgrader::make_schema_current, blcTableDelta::delta', referer: https://example.com/xxx

②エラーログから原因を特定する

今回発生した504エラーのログから、原因がプラグイン「Broken Link Checker」だと特定できた理由は、1行のエラーログに含まれる3つのキーワードにあります。

プラグインの略称「blc」

blc_init, blcDatabaseUpgrader::upgrade_database, blcTableDelta::delta

WordPressのプラグインは、プログラム内部で自分の略称を使うことが多く、ログの後半にある blc は Broken Link Checker の頭文字です。この記述から「Broken Link Checkerが動こうとして失敗している」ことが分かります。

専用テーブル名「wp_blc_links」

ALTER TABLE `wp_blc_links` ADD UNIQUE KEY...

ALTER TABLE はデータベースの構造を変更する命令です。その対象になっている wp_blc_links は、Broken Link Checkerがリンク一覧を保存するために作成した専用テーブルです。このテーブルの調整処理でつまずいていることが判明します。

重複エラーを示す「Duplicate entry」

Duplicate entry '' for key 'url_hash'

データベース側に「すでに同じデータが存在するため、追加・更新ができない」というエラーが発生しています。

504エラーが発生していたメカニズム

今回のエラーのメカニズムは以下です。

1. ブログにアクセスがあるたびに、Broken Link Checkerがデータベースのテーブル構造を自動更新しようとする
2. 重複データがあるためエラー（Duplicate entry）になり、処理が完了しない
3. ページの読み込みのたびにこの重い失敗処理が繰り返され、サーバーの応答が追いつかなくなってタイムアウト（504 Gateway Timeout）が発生した

まとめ

さあ今日もブログを書こう！　とはりきってアクセスしたらずーーーっとグルグルで表示されず、最終的には504エラーを吐いたおそろしい出来事でした。

でも、落ち着いて一つ一つ対処することで、なんとか解決できました。

phpMyAdminに初めてログインしたり、その中のテーブルを消したりと、またいろいろできるようになったので、結果的によかったです。

504はアクセスに時間がかかってる状態。

まずは落ち着いて、エラーログを見てみましょう。