SiteOps
トップメディアダッシュボード更新履歴
記事一覧

Cloudflare 524 A timeout occurredのとき、最初の30分でやること

Cloudflare 524 A timeout occurredが出たときに、最初の30分で「影響範囲の固定 → Cloudflare側要因の排除 → オリジン遅延（DB/外部API/負荷）特定 → 止血」を進める手順です。

著者: 川原更新: 2026-05-18障害対応RSS
Xで共有FacebookLinkedIn
料金相談

Cloudflareで 524 A timeout occurred が出たときは、まず「Cloudflare → オリジンへの接続はできているが、オリジンが時間内に応答を返せていない」として扱うのが最短です。

この記事は、524が出て「サイトが遅い/落ちた」状態になったとき、最初の30分で“止血”するチェックリストです。

関連:

  • /media/search-console-server-error-5xx-first-30-minutes
  • /media/cloudflare-1102-503-first-response
  • /media/libsql-database-is-locked-first-30-minutes

0. まず結論（先にやる順番）

最初の30分は「直す」より「遅い場所を確定する」を優先します。

  1. 524で確定（Cloudflare側のエラー番号・発生URL・発生率）
  2. 影響範囲を固定（全員/一部地域/一部URL/自分だけ）
  3. Cloudflare側の要因を先に排除（Status/設定変更直後/キャッシュ）
  4. オリジン側の遅延原因を特定（アプリ/DB/外部API/負荷/キュー）
  5. 収束後に 再発防止（タイムアウト設計/計測/劣化検知） を入れる

1. 524で確定する（推理禁止）

まず「本当に524か」を確定します（似た症状でも原因が違います）。

  • ブラウザのエラー画面に 524 が出ているか
  • Cloudflareダッシュボードで 524 が増えているか（時間帯/URL/国/デバイス）
  • 可能なら curl -I <URL> を複数回実行して 再現率 を把握する

ポイント:

  • 523/522/525 と混同しない（接続不能/SSL/TLSなど、初動が変わります）
  • 524は「接続はできるが、応答が返ってこない」寄りです

2. 影響範囲を固定する（最優先）

次を順に試して、影響範囲を固定します。

  • 別端末（スマホ/PC）で同じURLを見る
  • 別回線（モバイル回線）で見る
  • 別リージョン（VPNなどが使えるなら）で見る
  • 別URL（トップ/一覧/詳細/管理画面など）で傾向を見る

ここで分岐:

  • 特定URLだけ524: そのルートの 処理が重い/外部依存が遅い/DBが詰まっている 可能性が高い
  • 全URLで524: オリジン全体の 負荷/枯渇/ネットワーク/一斉劣化 を疑う

3. Cloudflare側の要因を先に排除する（5分）

オリジン調査に入る前に、Cloudflare側で「いま起きていること」を雑に固定します。

  • CloudflareのStatusや障害アナウンスが出ていないか（大規模障害なら先に共有して止血方針を決める）
  • 直前に WAF/Rules/キャッシュ/リダイレクト などを触っていないか（差分があるなら戻し候補）
  • キャッシュの有無（キャッシュHITなら524は出にくい。HIT率が急に落ちているなら別の事故の可能性）

※ 524自体はオリジン要因が多いので、ここは「長居しない」のがコツです。

4. オリジン側の遅延原因を特定する（最短で当てる順番）

「遅いのはどこか」を、可能な範囲で観測していきます。

4-1. まず“入口”で時間を測る

  • オリジンのログ（アクセスログ/アプリログ）で、該当リクエストの 処理時間 を見られるなら最優先
  • APMがあるなら、遅いトレース を見る（DB/外部HTTP/CPU/待ち）
  • なければ、最低でも「開始/終了」を出す（暫定でもいい）

4-2. ありがちな原因トップ5

  1. DBが詰まっている
    • ロック/遅いクエリ/コネクション枯渇/IO待ち
    • 関連: /media/libsql-database-is-locked-first-30-minutes
  2. 外部APIが遅い（または無限待ち）
    • タイムアウト未設定、リトライ暴走、同時リクエスト爆発
  3. キャッシュが効かなくなった
    • ヘッダー/キー/ルーティング変更で、急にオリジンへ全部流れる
  4. CPU/メモリ枯渇
    • GC地獄、OOM前のスワップ、コンテナのリソース制限
  5. 重いバッチ/ジョブが同居
    • 同一DBや同一インスタンスを食い潰す

5. “今すぐ復旧”のための止血レバー（最初の30分の範囲）

原因特定に時間がかかるときは、まず復旧優先で止血します（恒久対応は後）。

  • 重いルートの一時的な回避
    • 影響が大きいページだけ、軽い代替/簡易レスポンスに切り替える（可能なら）
  • 外部APIのタイムアウトを短くする
    • “待ち続ける”より“早く失敗して回復する”を優先
  • キャッシュの復旧
    • 直前差分でHIT率が落ちているなら、戻せるなら戻す
  • スロットリング
    • 同時実行数を落として雪崩を止める（DB/外部APIの保護）

6. 再発防止（30分の外）

復旧後に、次のどれかを最低1つ入れると再発率が下がります。

  • 主要な外部HTTP呼び出しに タイムアウト と 上限つきリトライ を入れる
  • 重要ルートに 処理時間の計測（p95/p99）とアラートを入れる
  • DBの 遅いクエリ検知 と コネクション枯渇検知 を入れる
  • “キャッシュが外れた瞬間に死ぬ”構成を避ける（段階的ロールアウト/フェイルセーフ）

状況が再現しない/原因が複合している場合は、相談だけ先に進めるのも有効です。

  • 料金・導入の概要を見る
  • 相談する

この記事を書いた人

川原

SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。

著者情報

関連記事

Cloudflare 502 Bad Gatewayが出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 504 Gateway Timeoutが出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 520（Web server returned an unknown error）が出たとき、最初の30分でやること障害対応更新: 2026-05-18
前の記事Cloudflare 526 Invalid SSL certificateのとき、最初の30分でやること次の記事お問い合わせフォームの通知が来ないとき、最初の30分でやること

次にやること

複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。

料金を見る相談したい / お問い合わせ