WordPressの504 Gateway Timeout対処法|原因・ログ・安全な復旧手順

WordPressの504 Gateway Timeout対処法 WordPress

WordPressで504 Gateway Timeoutが表示された場合、サーバー間の処理や応答が一定時間内に終わらず、手前のサーバーやプロキシが待ち切れなかった可能性があります。原因はWordPress本体に限らず、PHP、データベース、外部API、バックアップ、Cron、CDN、ホスティング環境など複数あります。

最初の確認順

  1. 一時的な障害か確認する
  2. 特定ページだけかサイト全体かを切り分ける
  3. 直前の更新・バックアップ・大量処理を確認する
  4. サーバーとWordPressのログを見る
  5. 原因が分からなければホスティング会社へ相談する

504 Gateway Timeoutとは

504は、ゲートウェイやプロキシとして動くサーバーが、上流のサーバーから時間内に応答を受け取れなかったときに返されるHTTPステータスコードです。表示だけでは、どの処理が遅れているかまでは分かりません。

502・503・504の違い

コード 大まかな意味 最初に見ること
502 上流から不正・不完全な応答 PHP・サーバー・プロキシ
503 一時的に処理できない 負荷・メンテナンス・リソース
504 上流の応答待ちがタイムアウト 重い処理・外部通信・DB・PHP

よくある原因

重いプラグイン処理やバックアップ

バックアップ、画像最適化、一括インポート、検索置換、大量メール送信など、時間のかかる処理と発生時刻が重なる場合は候補になります。処理を何度も再実行せず、まずログと実行履歴を確認します。

PHPやデータベースの処理遅延

PHPプロセスの枯渇、遅いデータベースクエリ、メモリ不足などで応答が返らない場合があります。WordPressのデバッグログだけでなく、ホスティング側のエラーログやリソース状況も確認します。

外部API・連携サービスの待ち時間

決済、地図、外部在庫、AI、メール、SNSなど外部サービスとの通信待ちで処理が止まることがあります。特定機能を使ったときだけ504になる場合は、連携先の障害情報やタイムアウトも確認します。サイトヘルス等で「cURL error 28」や接続タイムアウトが表示されている場合は、cURL error 28の確認手順で外部通信・DNS・WAFの切り分けを確認できます。

CDN・リバースプロキシ

CDNやプロキシを使っている場合、WordPress自体が動いていても途中の層で504が返ることがあります。オリジンサーバーとCDNの両方のログを確認します。

安全な復旧手順

  1. 発生時刻とURLを記録:トップ、管理画面、特定記事など再現範囲を確認します。
  2. 時間を置いて再確認:一時的な負荷なら自然復旧することがあります。
  3. 直前の処理を確認:更新、バックアップ、Cron、一括処理などを洗い出します。
  4. ログを確認:PHP、Webサーバー、WordPress、CDNのログを同じ時刻で見ます。
  5. 1項目ずつ切り分け:必要なら原因候補のプラグインや処理を停止・延期し、主要機能を確認します。

タイムアウト値をむやみに延ばさない

タイムアウト時間を長くすれば一時的に通る場合がありますが、根本原因が重い処理や外部サービス遅延なら問題を隠すだけになることがあります。まず原因を確認し、必要な場合だけホスティング会社や開発者の案内に従って調整します。

復旧後チェック

  • トップページと主要記事が開く
  • WordPress管理画面に入れる
  • 投稿保存・画像アップロードができる
  • 問い合わせフォームなど主要機能が動く
  • バックアップやCronが異常ループしていない
  • 同じ時刻帯で504が再発していない

近い症状は、502 Bad Gateway503 Service Unavailable500 Internal Server Errorもあわせて確認してください。エラーコードが違う、または原因をまだ絞れていない場合は、WordPressトラブル解決ロードマップから症状を選べます。

発生パターンから原因候補を絞る

発生パターン 確認しやすい原因候補 最初の行動
管理画面の保存時だけ 重いプラグイン処理・外部API 直前の操作とログを確認
毎日同じ時間帯 Cron・自動バックアップ・定期処理 実行時刻を照合
アクセス増加時だけ PHPプロセス・DB・サーバー負荷 リソース状況とエラーログを確認
特定機能だけ 外部API・決済・メール・AI連携 連携先の障害情報と待ち時間を確認

ログは同じ時刻で照合する

WordPressのデバッグログだけで判断せず、同じ発生時刻を基準にPHP、Webサーバー、データベース、CDNやプロキシの記録を見比べます。時刻がずれていると別のエラーを原因と誤認しやすいため、サーバーのタイムゾーンも確認します。

再発防止で確認する3点

  • 重い定期処理を同じ時間帯へ集中させていないか
  • 外部APIの失敗時に短時間で再試行を繰り返していないか
  • バックアップ・画像最適化・一括処理を本番アクセスの多い時間に実行していないか

サポートへ伝える情報

発生時刻、対象URL、エラー画面、再現頻度、直前の変更、バックアップやCronの実行有無、確認できたログをまとめると切り分けしやすくなります。

参考情報