WordPressサイトを開いたとき、「504 Gateway Timeout」と表示されることがあります。管理画面や記事の保存中に出ると、WordPressが壊れたように見えますが、504だけで記事やデータベースが失われたとは判断できません。
504は、CDNやリバースプロキシなどの中継役が、処理に必要な上流サーバーから時間内に応答を受け取れなかった状態です。WordPressでは、Webサーバー、PHP、データベース、外部API、バックアップやインポートなどの重い処理が関係します。
保存、注文、フォーム送信、更新、インポートを連打しないでください。画面は504でも、上流では処理が完了している場合があります。再送信すると、投稿や注文、メール、データ登録が重複するおそれがあります。
この記事では、画面・URL・時刻を残し、504を返した場所と遅い経路を切り分け、原因を一つずつ安全に直す順番を解説します。
先に結論：504エラーは7段階で確認する
| 順番 | 確認すること | 目的 |
|---|---|---|
| 1 | 再送信を止め、画面・URL・時刻・操作を記録する | 重複処理を防ぎ、ログへつなぐ |
| 2 | サイト全体か特定画面かを一度ずつ比較する | 遅い経路を絞る |
| 3 | サーバー会社・CDNの障害情報を見る | 待つべき障害で設定を変えない |
| 4 | 発行元、応答ヘッダー、識別IDを確認する | CDN・Webサーバー・上流を分ける |
| 5 | 同時刻の負荷・遅い処理・ログを照合する | 推測ではなく証拠で原因を絞る |
| 6 | 原因候補を一つだけ停止・切り戻す | 変更の効果を判定できるようにする |
| 7 | 200応答と保存・送信結果を確認する | 部分復旧と重複処理を見逃さない |
最初からタイムアウト値を延ばすのは避けます。処理の詰まりが残ったまま待ち時間だけを長くすると、PHPワーカーや接続枠が長時間使われ、別のアクセスまで遅くなる場合があります。
504 Gateway Timeoutとは？
RFC 9110の504 Gateway Timeoutは、ゲートウェイまたはプロキシとして動くサーバーが、要求を完了するために必要な上流サーバーから適時の応答を得られなかった状態です。
ブラウザから見るとWordPressは一つのサイトですが、実際の要求はCDN、ロードバランサー、Webサーバー、PHP、データベース、外部サービスを通ることがあります。途中の中継役が待てる時間を超えると、最終的な処理が動いていても504が返ることがあります。
したがって、504の画面だけで「PHPが原因」「CDNが故障」「サーバー性能不足」とは断定できません。どのURLで、どの操作中に、何秒ほどで発生し、静的画像や別画面は開くかを比較して、遅延箇所を絞ります。
502・503・504の違い
| 表示 | 意味 | 最初に見る場所 |
|---|---|---|
| 502 Bad Gateway | 中継役が上流から正常な応答を受け取れない | CDN・プロキシ・Webサーバー・PHP間の接続と応答 |
| 503 Service Unavailable | サーバーが過負荷やメンテナンスで現在は処理できない | 障害情報、負荷、メンテナンス、制限 |
| 504 Gateway Timeout | 中継役が上流の応答を時間内に受け取れない | 遅いURL、処理時間、PHP・DB・外部API、各層のタイムアウト |
502ならWordPress 502 Bad Gatewayの直し方、503ならWordPress 503 Service Unavailableの直し方が対象です。表示が変化する場合は、同じ原因が別の層で異なるコードとして現れている可能性もあるため、コードと時刻を両方記録します。
最初の10分で行う安全な初動
1．送信を止めて証拠を残す
エラー画面全体、完全なURL、発生時刻とタイムゾーン、直前の操作を記録します。「閲覧」「ログイン」「記事保存」「注文」「フォーム送信」「更新」「バックアップ」「インポート」のどれかで、見るべきログが変わります。
応答ヘッダーを確認できる場合は、HTTPステータス、`Server`、CDNのリクエストID、`Retry-After`も保存します。開発者ツールに慣れていなければ、無理に操作せず、スクリーンショットと時刻をサポートへ渡すだけでも役立ちます。
2．発生範囲を一度ずつ比べる
トップページ、別の記事、管理画面、既知の静的画像を各一度だけ確認します。静的画像は開くのにWordPress画面だけ遅いなら、PHPやデータベースなど動的処理が候補です。特定の保存・検索・書き出しだけで出るなら、その処理や外部APIを優先して調べます。
別端末や別回線でも一度だけ比較します。ただし、自分の環境だけで直ってもサイト全体の復旧とは限りません。サーバー側の監視、外形監視、アクセスログも合わせます。
3．障害情報と直前変更を確認する
サーバー会社、CDN、利用中の外部サービスの公式ステータスと契約画面の通知を確認します。同じ時間に障害が公表されているなら、WordPress設定を変えずに記録して待ちます。
同時に、プラグイン更新、テーマ変更、PHP変更、バックアップ、データ移行、商品同期、API連携など、直前に始めた処理を一覧にします。記憶だけでなく、更新履歴、ジョブログ、管理メールも確認してください。
症状から遅い場所を絞る
| 症状 | 考えられる範囲 | 確認する証拠 |
|---|---|---|
| すべてのURLが同時に504 | CDN、Webサーバー、ホスト全体、共通の上流 | 公式障害情報、リソース履歴、Webログ |
| 静的画像は開き動的ページだけ504 | PHP、WordPress、データベース | PHP slow log、DB遅延、ワーカー使用状況 |
| 検索・管理画面・特定記事だけ504 | 重いクエリ、個別プラグイン、肥大データ | 遅いURL、クエリ、PHPログ |
| 保存・送信・同期だけ504 | 外部API、メール、決済、Webhook、REST API | 処理結果、連携先の状態、通信ログ |
| 決まった時刻だけ504 | cron、バックアップ、集計、ボット巡回 | ジョブ履歴、アクセス量、CPU・メモリ |
| CDN経由だけ504 | CDNと配信元の経路または配信元の遅延 | CDN識別ID、配信元応答、CDN分析 |
Cloudflareの502・504公式資料も、配信元サーバー由来かCloudflare由来かを切り分け、URL、発生時刻、タイムゾーンなどを記録するよう案内しています。CDNのブランド表示だけで原因を断定せず、配信元ログと照合します。
原因別の安全な復旧順
1．サーバー障害・ネットワーク障害
公式障害や計画メンテナンスが一致する場合は、WordPress、PHP、DNS、CDNの設定を変更しません。復旧予定、影響範囲、識別IDを保存し、長引く場合はサポートへURLと時刻を伝えます。
2．CPU・メモリ・PHPワーカー・接続枠の不足
発生時刻のCPU、メモリ、同時処理、ディスクI/O、データベース接続、アクセス数を確認します。バックアップ、画像生成、インポート、集計、cron、ボットが重なっていれば、原因と確認できた処理だけを停止または時間変更します。
単にメモリやワーカー数を増やすと、データベースやI/Oへ負荷が移ることがあります。まずWordPressが重い原因と改善順で遅い処理を特定し、キャッシュ変更はWordPressキャッシュ設定の安全な確認手順に沿って一つずつ行います。
3．遅いPHP処理・プラグイン・テーマ
PHP slow log、エラーログ、APM、WordPressのデバッグログを同じ時刻で照合します。特定のプラグインや処理が示された場合だけ、テスト環境または影響を限定できる方法で停止し、同じ操作を一度検証します。
全プラグイン停止は最後の診断です。本番で行うなら、有効だった一覧と設定を記録し、フォーム、キャッシュ、セキュリティ、決済への影響を先に確認します。不要プラグインの整理はWordPressプラグインを安全に減らす方法を参照してください。
4．遅いデータベース処理
検索、集計、管理画面一覧、関連商品、アクセス解析など特定機能で出る場合は、スロークエリ、ロック、接続数、テーブル容量を確認します。いきなりテーブルを削除したり、最適化プラグインを重ねたりせず、バックアップと復元手段を確認してから対象を限定します。
「データベース接続確立エラー」という固有表示に変わった場合は、WordPressのデータベース接続エラーを直す手順へ進みます。
5．外部API・メール・決済・Webhookの待ち時間
外部サービスの応答を待つ同期処理は、相手側の遅延でPHP処理全体が長引くことがあります。連携先の公式ステータス、API応答時間、タイムアウト、再試行設定を確認します。保存や注文の結果を先に照合し、同じ要求を再送しません。
長時間処理は、可能なら小分け、非同期化、バックグラウンドジョブ化を検討します。ただし、プラグインやサービスの仕様で実装方法が違うため、提供元または制作者へ確認してください。
6．CDN・プロキシと上流のタイムアウト不整合
CDN、Webサーバー、PHP、外部HTTP通信には別々のタイムアウトがあります。WordPress公式のPHP最適化資料も、複数のタイムアウト層を整合させる必要があり、下流の短い制限が先に処理を止めれば一つの値だけを上げても効果がないと説明しています。
先に「正常なら何秒で終わる処理か」「どの層が先に打ち切ったか」を確認します。処理自体が異常に遅いなら最適化を優先し、正当な長時間処理なら設計変更または各サービスの仕様範囲で値を揃えます。
ログは同じ時刻で突き合わせる
優先するのは、CDN・Webサーバーのアクセス／エラーログ、PHPエラーログとslow log、データベースの遅い処理、外部APIの通信記録、サーバーのリソース履歴です。504の発生時刻を軸に、同じ要求がどこまで到達したかを追います。
WordPress側の確認が必要なら、WordPress公式のデバッグ手順に沿います。`WP_DEBUG_DISPLAY`で詳細を公開画面へ出さず、ログへ記録し、調査後は一時設定を戻します。
ログにはIP、Cookie、パス、メールアドレス、注文情報、認証情報が含まれる場合があります。サポートへ共有する前に伏せ字にし、公開フォーラムへ全文を貼らないでください。
やってはいけない対処
- 記事保存、注文、フォーム送信、更新を連打する
- 全プラグイン停止、PHP変更、キャッシュ削除、復元を同時に行う
- 原因を確認せず、各層のタイムアウト値だけを大きくする
- 負荷が高い最中に重いフルバックアップを新規実行する
- データベースのテーブルやオプションを直接削除する
- CDNやWAFを長時間全面停止する
- 本番でエラー詳細を表示し、ログ全文を公開する
- 一度の504だけで高額なプランへ変更する
- エラーページを正常な200応答に置き換える
変更前にバックアップの有無、復元方法、元の設定値を確認し、一つ変更して一つ検証する原則を守ります。
復旧後に確認すること
- トップページ、問題のURL、管理画面がHTTP 200で安定して開く
- 投稿保存、フォーム、注文、メールなど重要機能が一度ずつ成功する
- 504直前の操作が重複登録されていない
- CDNと配信元でエラー率が戻っている
- CPU、メモリ、ワーカー、DB接続、応答時間が通常範囲へ戻っている
- PHP・DB・外部APIに同じ遅延が再発していない
- 一時的に止めたジョブや防御機能を安全な設定へ戻した
- スマートフォンとPC、ログイン中と未ログインで表示を確認した
WordPress公式の監視資料では、稼働監視だけでなく、ページ読み込み、遅いトランザクション、PHPやデータベースの記録を継続的に確認する考え方が案内されています。復旧した一瞬だけで完了にせず、通常のアクセスが戻った時間帯まで監視します。
サーバー会社へ伝える情報
- 対象URLと504画面のスクリーンショット
- 発生時刻とタイムゾーン
- 閲覧・保存・送信・更新など直前の操作
- サイト全体か特定URL・特定操作だけか
- HTTPステータス、Server、CDN識別ID
- 直前の更新、バックアップ、インポート、設定変更
- 発生時刻のリソースグラフと伏せ字済みログ
- 最後に正常だった時刻
- 実施済みの確認と、その結果
「504を直してください」だけでなく、「2026年○月○日14時10分ごろ、管理画面の商品書き出しで発生。公開ページと静的画像は表示でき、同時刻にCPU上昇。再送信はしていない」のように伝えると、調査対象を絞りやすくなります。
よくある質問
待てば自然に直りますか？
一時的な負荷や障害なら戻ることがあります。ただし、遅い処理、定期ジョブ、外部API停止、上限不足が続けば再発します。待つ場合も、画面と時刻を記録し、公式障害情報と負荷履歴を確認してください。
再読み込みしてもよいですか？
通常の閲覧は、間隔を空けて一度確認します。投稿保存、注文、フォーム、決済、インポートなど状態を変更する操作は、結果を確認するまで再送信しません。
タイムアウト値を延ばせば直りますか？
正当な長時間処理で、どの層が先に打ち切るかを確認できている場合は選択肢になります。しかし、異常に遅いPHPやDBを残したまま延長すると悪化する場合があります。最初に処理時間とボトルネックを確認します。
サーバープランを上げるべきですか？
継続的なリソース不足が記録で確認でき、キャッシュ、重い処理、ボット、設定を見直しても必要容量が足りない場合に検討します。一度の504だけでは判断しません。見直し基準はレンタルサーバーを見直すタイミングで確認できます。
まとめ
WordPressの504 Gateway Timeoutは、中継役が上流から時間内に応答を受け取れなかった状態です。最初に送信操作を止め、URL・時刻・操作を記録し、障害情報、発生範囲、ログ、負荷の順に確認します。
タイムアウト値を先に延ばさず、遅い処理を証拠で特定し、一つずつ直すことが安全な近道です。自分で発行元やログを確認できない場合は、画面、時刻、URL、直前操作をそろえてサーバー会社や制作者へ相談してください。