Cloudflareを利用しているWordPressで「524 A Timeout Occurred」が表示され、記事の保存、データの書き出し、バックアップ、検索、フォーム送信などが完了しないことがあります。普段のページは開くのに重い操作だけ失敗する、アクセスが集中した時間だけ再現する、といった症状もあります。
524は、Cloudflareがオリジンサーバーへ接続できなかったエラーではありません。接続と要求の受け付けは進んだものの、オリジンからHTTP応答が規定時間内に返らない状態です。そのため、DNSや接続入口だけでなく、WordPress・PHP・データベース・外部サービスで長く動いている処理を調べます。
524が出た操作を、結果確認前に何度も実行しないでください。画面へ応答できなかっただけで、注文、メール送信、記事公開、バックアップ作成などがオリジン側で進んでいる場合があります。重複処理を防ぐため、最初に結果とログを確認します。
先に結論：524エラーは8段階で確認する
- URL、操作、発生時刻、タイムゾーン、Ray IDを保存する
- 注文・保存・送信・書き出しなどの処理結果を確認する
- 通常ページと重い操作のどちらで再現するか分ける
- Cloudflare・ホスティングの障害情報とオリジン負荷を確認する
- 同時刻のWebサーバー、PHP、データベース、WordPressログを照合する
- 遅いURL、クエリ、外部API、バックアップ、WP-Cronを特定する
- 処理の分割・非同期化・負荷低減を一つずつ実施する
- 公開ページ、管理画面、重複処理、検索クロールを再確認する
接続確立または要求確認の段階で止まる場合はWordPressの522エラーを直す確認順、Cloudflare以外の中継層が上流応答を待つ場合はWordPressの504 Gateway Timeoutを直す手順へ切り替えてください。
524エラーとは？
Cloudflare公式のError 524では、Cloudflareがオリジンへ正常に接続したものの、既定のProxy Read TimeoutまでにHTTP応答を受け取れない状態と説明されています。2026年7月時点の既定値は125秒です。
また、Cloudflareがオリジンへデータを書き込む処理が30秒以内に完了しない場合にも524になることがあります。Cloudflare Imagesでは書き込み側の時間が6.5秒とされています。読み取り側と書き込み側で意味が違うため、閲覧、保存、アップロード、書き出しのどの操作で起きたかを記録します。
「125秒より少し長く待てばよい」とは限りません。時間のかかるクエリ、停止に近い高負荷、外部APIの待ち、巨大なバックアップなどを放置したまま上限だけを広げると、同時処理が積み上がり、サイト全体の503やデータベース障害へ広がるおそれがあります。
504・522・524の違い
| 表示 | 止まっている主な段階 | 最初に見るもの |
|---|---|---|
| 504 Gateway Timeout | 中継層が上流の応答を待っている | どのプロキシが返したか、上流処理 |
| 522 Connection Timed Out | Cloudflareとオリジンの接続・要求確認 | IP遮断、負荷、DNS、通信経路 |
| 524 A Timeout Occurred | 接続後にオリジンのHTTP応答または書き込み完了を待っている | 遅いURL、PHP、DB、外部API、長時間処理 |
524は「WordPressが壊れた」と断定する番号ではありません。Cloudflareとオリジンの間で観測された待ち時間です。ただし、WordPressのプラグイン、テーマ、データベース処理、WP-Cronが遅延の引き金になることはあります。
WordPressで524が出る主な原因
1．データベースの検索・集計・更新が長い
大量の商品、注文、アクセスログ、投稿メタを検索・集計する処理は、通常ページより長時間になりやすいです。インデックスが使われないクエリ、肥大化したオプション、複数テーブルの結合、同時更新のロック待ちが重なると、PHPが応答を返せないまま待ち続けます。
2．バックアップ・書き出し・画像処理が同期実行されている
管理画面を開いた一つのHTTP要求の中で、サイト全体の圧縮、データベース書き出し、画像の一括変換、大量CSV生成を完了させようとすると、524の時間に達しやすくなります。処理が完了してもダウンロード応答だけ返せなかったケースがあるため、生成済みファイルを先に確認します。
3．外部APIやメール・決済サービスの応答待ち
外部APIへ同期接続し、相手の応答が返るまでWordPressのページ生成を止めている場合があります。タイムアウト、再試行回数、接続先障害を確認し、注文や決済では「画面が524だから未処理」と決めつけません。
4．PHPワーカー・CPU・メモリ・接続数が不足している
個々の処理は短くても、PHPワーカーやデータベース接続が埋まると待ち行列が伸びます。バックアップ、セキュリティスキャン、検索ボット、画像生成、wp-cronが同時刻に重なっていないか確認します。サイト全体が重い場合はWordPressが重い原因を安全な順番で直す手順も使えます。
5．WP-Cronの重い処理が閲覧時に起動している
WordPress公式のWP-Cron資料では、WP-Cronは常時動く仕組みではなく、ページ読み込みをきっかけに期限到来タスクを確認します。長時間実行のタスクや重複登録があると、特定のアクセス時だけ負荷が跳ね上がることがあります。
6．キャッシュ対象外のURLへアクセスが集中している
ログイン中ページ、カート、検索、管理画面、APIはキャッシュされにくく、アクセスがそのままオリジンへ届きます。公開記事が速いのに特定の動的URLだけ524なら、キャッシュ全削除ではなく、そのURLの処理時間と同時実行数を見ます。
最初に保存する情報
- 524が出た完全なURL
- 日時、タイムゾーン、Ray ID
- 実行した操作と入力件数・ファイル容量
- ボタンを押してからエラーまでのおおよその時間
- 処理結果、生成ファイル、注文・公開・通知の有無
- 同じ時刻のCPU、メモリ、PHPワーカー、DB接続数
- 直前のプラグイン更新、バックアップ、Cron、外部API変更
- 全体・特定URL・ログイン時だけのどれか
Cloudflareの画面だけでなく、ホスティング側のアクセスログとエラーログを同じタイムゾーンでそろえます。Ray ID、Cookie、Authorization、注文情報などを公開の場所へ貼らず、サポート共有時は秘密値を削除してください。
どの処理が遅いか特定する
原因調査では「524が出た」という結果より、どのURLが何秒使い、どの処理を待ったかが重要です。一度に全プラグインを停止すると再現条件が消えるため、証拠を保存してから段階的に確認します。
| 確認層 | 見るもの | 判断の手がかり |
|---|---|---|
| Cloudflare | Ray ID、Edge status、Origin Analytics、対象URL | 524の集中URLと時刻 |
| Webサーバー | request time、upstream time、接続数 | どの要求が長く開いたか |
| PHP | slow log、ワーカー、メモリ、外部通信 | 実行中の関数・プラグイン |
| データベース | slow query、ロック、接続、テーブル容量 | 遅い検索・集計・更新 |
| WordPress | 直前更新、WP-Cron、バックアップ、REST API | 特定操作で再現するか |
| 外部サービス | API応答時間、タイムアウト、再試行 | 相手待ちで止まっていないか |
WordPress公式のデバッグ資料は、変更前のバックアップまたはテスト環境を推奨しています。ログを有効にする場合は本番画面へエラーを表示せず、調査後に不要なデバッグとSAVEQUERIESを戻します。SAVEQUERIESには性能負荷があるため、常時有効にしません。
原因別の安全な直し方
1．重い処理を小分け・非同期・進捗確認型へ変える
大量書き出しや画像処理は、一回のHTTP要求で完了させず、ジョブを登録してすぐ受付応答を返し、別処理で実行して進捗を確認する形が基本です。Cloudflare公式も、大きなHTTP処理にはステータスポーリングを実装する方法を案内しています。
2．遅いクエリとデータ構造を見直す
遅いSQL、ロック待ち、肥大化したテーブル、不要な全件取得を特定し、開発者やホスティングへ改善を依頼します。データベースの最適化や削除はバックアップ後に対象を限定し、用途不明のテーブルやオプションを一括削除しません。
3．バックアップ・スキャン・Cronの時間を分散する
バックアップ、セキュリティスキャン、画像最適化、集計、メール送信が同時に始まらないようスケジュールをずらします。不要な重複Cronを整理し、必要ならホスティングのシステムCronへ移す判断をします。バックアップの安全な確認はWordPress更新前のバックアップ手順も参照してください。
4．PHP・DB・サーバー容量は原因確認後に調整する
PHPワーカー、CPU、メモリ、データベース接続が実際に上限へ達している場合は、処理の効率化と合わせてホスティングへ調整を依頼します。数値を一斉に増やすのではなく、再現時の利用率と待ち行列を根拠にします。
5．外部APIの待ちと再試行を制御する
適切な接続・読み取りタイムアウトを設定し、失敗時は画面要求を長く止めず、安全な再試行キューへ渡します。注文や決済は冪等キー、処理ID、照会APIなど提供元の仕組みを使い、利用者の連打で重複しないようにします。
6．タイムアウト変更は最後に必要性を判断する
Cloudflare EnterpriseではProxy Read Timeoutを最大6,000秒まで調整できる案内がありますが、長時間処理の設計を直さなくてよいという意味ではありません。Cloudflare公式は、125秒を恒常的に超える処理をDNS-onlyの専用サブドメインへ分ける選択肢も示しています。オリジンIP露出、防御、SSL、認証、アクセス制限への影響を確認し、安易に切り替えません。
やってはいけない対処
- 結果を確認せず保存・注文・送信を連打する
- タイムアウト値だけを大きくして原因を放置する
- 全プラグイン停止、キャッシュ全削除、PHP変更を同時に行う
- 本番でSAVEQUERIESや詳細エラー表示を常時有効にする
- 用途不明のデータベーステーブルやCronを一括削除する
- Cloudflareを恒久停止して解決扱いにする
- 負荷確認なしでCPU・メモリ・ワーカー上限を一斉に増やす
- Ray ID、認証値、顧客情報を公開の相談場所へ貼る
復旧後の確認チェックリスト
- 主要な公開URLが200を返す
- 524が出た操作が適切な時間で完了する
- 注文、記事、メール、バックアップに重複がない
- PHP・DB・Webサーバーの長時間ログが減っている
- CPU、メモリ、ワーカー、接続数が正常範囲である
- WP-Cronとバックアップの実行時間が重なっていない
- 外部API障害時も画面全体が長時間停止しない
- 一時的なデバッグ、許可、DNS変更を元へ戻した
- 管理画面、REST API、フォーム、検索が正常である
- 監視とバックアップが正常に動く
ホスティングへ伝える情報
ホスティングへは、524が出たURL、時刻、Ray ID、操作、入力件数、エラーまでの時間、処理結果、同時刻の負荷、直前変更を伝えます。「サイトが重い」だけでなく、Webサーバーのrequest time、PHP slow log、データベースのslow query、接続上限を調べてほしいと依頼すると切り分けやすくなります。
Cloudflareへ相談する場合も、先にオリジン側の調査結果をそろえます。CloudflareのError AnalyticsやOrigin Analyticsで特定URLへ524が集中しているか確認し、オリジンの同時刻ログと対応させます。
524エラーのよくある質問
しばらく待てば直りますか？
一時的な負荷なら戻る場合がありますが、遅いクエリ、同期バックアップ、外部API待ち、重複Cronは残ります。表示が戻っても発生時刻のログを確認し、再発条件を特定してください。
PHPのmax_execution_timeを増やせば直りますか？
必ずではありません。PHPが途中で終了している場合には関係しますが、524はCloudflareがHTTP応答を待つ時間、データベース、外部API、ワーカー不足なども関係します。PHPだけを増やすと、重い処理が長く資源を占有する場合があります。
キャッシュを削除すれば直りますか？
古いキャッシュが原因の限定的な不具合には役立ちますが、動的処理の遅延は直りません。全削除直後は再生成が集中して負荷が増えることもあるため、対象URLと原因を確認してから更新します。
524はSEOへ影響しますか？
GoogleのHTTPステータス資料では、5xxが増えるとクロールが一時的に遅くなり、長期間続くURLはインデックスから外れる可能性があると説明されています。復旧後は主要URLの200応答を確認し、Search Consoleでクロール状況を見ます。
まとめ
524 A Timeout Occurredは、Cloudflareがオリジンへ接続した後、HTTP応答または書き込み完了を規定時間内に確認できない状態です。接続前の522とは確認する段階が異なります。
- 結果不明の操作を連打せず、Ray ID・時刻・処理結果を保存する
- 遅いURL、PHP、DB、外部API、バックアップ、WP-Cronを分ける
- 重い処理は小分け・非同期・進捗確認型へ変える
- 上限変更より先に処理時間と資源不足の原因を直す
- 復旧後は重複処理、5xx、検索クロールまで確認する