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

WordPressの504 Gateway Timeout対処法 WordPress
2026年9月13日
FIX CONSOLE / 504

遅い処理を繰り返さず、
時刻・範囲・直前操作を残す。

この記事は、WordPressで504 Gateway Timeoutが出たときに「何の処理が時間切れになったか」を切り分ける記事です。原因はWordPress本体に限らず、PHP、データベース、外部API、バックアップ、Cron、CDN、ホスティング環境など複数あります。500・502・503との違いが分からない場合はWordPressトラブル解決ロードマップへ戻ります。

YOHAKU 60-SECOND CHECK

504が出たら、まず3つだけ記録

  1. 時刻：何時ごろ発生したか
  2. 範囲：特定ページ・管理画面・サイト全体のどこか
  3. 直前：更新・バックアップ・大量処理・外部連携を使ったか

処理を何度も再実行したり、タイムアウト値を先に延ばしたりせず、発生条件を残してからログ確認へ進みます。

最初の確認順

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

504 Gateway Timeoutとは

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

発生パターン 最初に見る場所
バックアップ・一括処理中だけ 実行履歴、PHP、サーバー負荷
特定ページだけ そのページの処理、外部API、DBクエリ
管理画面だけ プラグイン、Cron、外部通信
サイト全体で断続的 ホスティング障害、プロキシ/CDN、リソース

再読込を繰り返す前に、発生時刻と直前操作を残すと、サーバーログと照合しやすくなります。

サーバー会社や制作担当へ相談するときは、発生時刻／対象URL／全体か特定画面か／直前にしていた操作／再現するか／表示されたエラー文の6点を渡します。これだけで「再現待ち」や「何をしたか分からない」状態を減らせます。

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 Gateway、503 Service Unavailable、500 Internal Server Errorもあわせて確認してください。エラーコードが違う、または原因をまだ絞れていない場合は、WordPressトラブル解決ロードマップから症状を選べます。

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

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

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

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

再発防止で確認する3点

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

サポートへ伝える情報

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

YOHAKU 504 TIMER

504は「どの処理が長いか」を分けて見る

操作 結果
通常ページ表示 速い / 遅い
管理画面保存 通る / タイムアウト
バックアップ・インポート 通る / タイムアウト
外部API通信 通る / タイムアウト

タイムアウト値を延ばす前に、時間がかかっている処理そのものを特定します。

YOHAKU 504 TRACE

時間がかかる処理を1つずつ分ける

  • 通常ページ表示
  • 管理画面保存
  • バックアップ
  • インポート・エクスポート
  • 外部API通信

全部が遅いのか、特定処理だけが止まるのかで確認先が変わります。タイムアウト値を延ばす前に、止まる処理を特定します。

OFFICIAL DEFAULT EXAMPLES｜設定変更の推奨値ではありません

30秒・60秒は「原因を考える手がかり」であって、延長目標ではない

層 公式ドキュメントの例 使い方
PHP max_execution_time のPHP既定値は30秒 処理がPHP側で打ち切られていないか、ログと実行時間を照合
Nginxプロキシ proxy_read_timeout の既定値は60秒 上流からデータが返らない時間が続いていないかを確認

重要：レンタルサーバー、Apache、PHP-FPM、CDN、WAFなど構成により実際の上限は違います。504が出たから30→300秒へ延ばす、といった変更はしません。まず「どの操作だけ」「何秒前後」「同時刻のログ」で切れた層を絞ります。

504が重い処理の直後だけ出るなら、容量・メモリも確認する

バックアップ、画像変換、大量更新など特定処理の直後だけ504になる場合は、サーバー容量不足やPHPメモリ不足も候補です。単発の504と、同じ操作で毎回再現する504を分けて記録します。

参考情報

NEXT / RELATED

次に確認するなら、この3つ。