524
中まで届いたのに、そこで黙ってしまったリクエストのための Cloudflare 独自のコードです。接続は成功し、オリジンはリクエストを受け取り、それでも 125 秒後に返せる HTTP 応答がまだ無かった、という意味です。
同じ 3 桁でも、リクエストのどちら側にいるかで別々の問題になります。自分に当てはまるブロックを読んでください。
これが出ている理由
リクエストが 2 分以上固まったあと、Cloudflare の HTML エラーページに解決します。2 分はどんな利用者の忍耐よりも長く、いくつかのモバイル回線がアイドル接続を保つ時間よりも長いので、実際にはステータスコードとしてではなく abort やネットワークエラーとして届くことがよくあります。そうなると調査はオリジンではなく自分のコードへ向かってしまいます。対象は 1 つのエンドポイントで、常に遅いほう——エクスポート、レポート、一括インポート、上限の無い検索、同期処理されるアップロード——です。
やること
すべてのリクエストに、自分で選んだ 125 秒よりずっと手前の期限を `AbortController` とタイマーで与えてください。利用者にはインフラ事業者の素っ気ないページではなく自分のメッセージが出ますし、経過時間もログに残ります。そのうえで、正当に長くかかるものは形を変えます。これは Cloudflare 自身の推奨でもあります——エンドポイントは即座にジョブ ID を返し、結果はポーリングで取る。どんなタイムアウト設定をしても、2 分のリクエストがあなたとサーバーの間のすべてのプロキシとロードバランサーとモバイル回線を生き延びることはありません。524 を自動で再試行しないこと。Cloudflare が立ち去った数秒後にオリジンが作業を終えている可能性は非常に高いので、再試行されたインポートは 2 回走ります。どうしても再試行可能にするなら、冪等キーを送ってサーバーに重複を認識させてください。
これが出ている理由
オリジンは接続を受け入れてリクエストを読みました。つまり接続まわりの問題は分類ごとすでに除外されています。ポートも bind アドレスもファイアウォールも Cloudflare の IP レンジも問題ありません。そうでなければ 521・522・523 のどれかになっていたはずです。リクエストはまだ走っているか、一度も始まっていないかのどちらかです。この 2 つが Cloudflare の挙げる原因——長時間実行プロセスと過負荷のサーバー——で、必要な対処は正反対です。前者は遅いクエリ、ロック、育ち続けるテーブルに対する上限の無いループ。後者は飽和したワーカープールで、リクエストは他の後ろで並んでいてアプリケーションはまだ触れていません。
やること
どちらなのかは自分のアクセスログが教えてくれますし、それが最初に読むべきものです。125 秒を超える所要時間でそのリクエストが記録されているなら、Cloudflare が諦めたあとにオリジンが完了したということです。作業は本当に遅く、ログには本当の所要時間が入っていて、問題はそのリクエストの中にあります。そのリクエストが一度も現れないなら、遅かったものは何もありません。アプリケーションの手前のキューに座っていただけで、これは容量の問題であり、エンドポイントをプロファイルしても何も見つかりません。そこから先、実際に取れる手は Cloudflare が文書化しているものです。長時間の作業をリクエストの経路から外して結果をポーリングする。125 秒を超えざるをえないものは DNS のみのサブドメインの裏へ置く——このタイムアウトはプロキシされたトラフィックにしか存在しません。閾値を越えるのを待つのではなく、Origin Analytics で応答時間が近づくのを監視する。タイムアウトの引き上げは Enterprise ゾーンで Cache Rules かゾーン設定の API を使う場合のみ、しかも上限 6,000 秒なので、大半の人にとってこの数字は固定で、代わりに設計を変えることになります。自分のアプリケーション側のタイムアウトも 125 秒より短く設定してください。理由をログに残せるものにリクエストを止めさせるためです。
これが出ている理由
サイトは動いていて、あなたの依頼も受け取っています。ただ答えるのに時間がかかりすぎたので、その手前にいるサービスが待つのをやめて、代わりにこのページを見せました。たいていは重い処理です——大きなエクスポート、大きなアップロード、大量のデータに対する検索、あるいは普段より混んでいるサイト。同じサイトの他の部分はたいてい完璧に動くので、外からは気まぐれな失敗に見えます。
やること
大きなものを頼んだなら、小さく頼み直してください。期間を短く、ファイルを小さく、一度の件数を少なく。リロードを何回繰り返すよりも、この 1 つの変更のほうが多くの 524 を解決します。タイムアウトは所要時間の問題で、所要時間は量に追随するからです。アップロードや送信をやり直す前に、実際には通っていないかを確認してください。タイムアウトは結果を隠しただけで、作業自体はその直後に終わっている可能性が高いので、ファイルはもう置かれていて、やり直すと重複を作るかもしれません。まず該当する一覧やフォルダーや注文履歴を見てください。サイトが混んでいるときに避けるべき唯一のことは、すぐにリロードすることです。リロードのたびに、同じ過負荷のサーバーへ同じ遅い仕事をもう一度頼むことになります。
失敗した URL に対してそのまま実行してください。エラーページを表示せずにステータスだけを出すので、ブラウザが描画したものではなくサーバーが言ったことが見えます。
curl -sS -o /dev/null -D - --max-time 300 -w '\n%{http_code} connect=%{time_connect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n' https://example.com/slow-report`--max-time 300` は curl の全体の上限で、125 秒よりゆとりをもって長くしておく必要があります。そうしないと curl が先に諦めて、測っているのが Cloudflare のタイムアウトではなく自分の忍耐力になります。出力に現れる 524 の形は見間違えようがありません。`connect` はコンマ何秒、`ttfb` と `total` はどちらも 125 秒あたり、ステータスは 524——速い接続のあとの非常に長い沈黙で、これがまさに 522（接続自体が完了しなかった場合）と分けるパターンです。次に `--resolve example.com:443:203.0.113.10` で自分のオリジンアドレスを指してエッジを経路から外し、同じリクエストをもう一度実行します。オリジンが 200 秒後に答えるなら、作業は本当にそれだけ遅く、524 は正確な報告でした。curl が出す数字が、そのリクエストに本当に必要な時間であり、設計の前提にすべき数値です。エッジを迂回するとオリジンが速く答えるなら、余計な時間はアプリケーションの手前で足されています——Worker、WAF のルール、あるいはオリジンへの HTTP/2 など——ので、見るべきはオリジンではありません。コマンドの実行中はオリジン自身のアクセスログを見ていてください。125 秒を超える所要時間でそこに現れるリクエストは、Cloudflare が聞くのをやめたあとに作業が完了した証拠です。524 のあとに書き込みを再試行するのが安全でない理由が、まさにこれです。そのログに一度も現れないリクエストは、キューに入ったまま始まっていないということで、遅いのはエンドポイントではなく、サーバーが埋まっています。
524 は IETF のステータスコードではありません。登録済みの 5xx は 511 で終わっていて、520 から 526 は Cloudflare のもの、文書化しているのも Cloudflare だけ、現れるのも実際にプロキシされたトラフィックだけです。Cloudflare の定義は珍しく精密で、二度読む価値があります。エラー 524 は、Cloudflare がオリジンのウェブサーバーへの接続には成功したが、オリジンが既定の 125 秒より前に HTTP 応答を返さなかったことを示す。最初の節が診断そのものです。接続に成功したということは、オリジンは listen していて、Cloudflare がプロキシするポートにいて、ファイアウォールも Cloudflare を通したということ。521・522・523 なら投げかけられる問いはすべてすでに答えが出ていて、どれも調べる価値がありません。残っているのはアプリケーションの中だけです。125 秒は Cloudflare の Proxy Read Timeout で、接続の制限に関するリファレンスにその値で記載されています。変更できるのは Enterprise ゾーンだけで、そこでは Cache Rules かゾーン設定の API で最大 6,000 秒まで上げられます。だからそれ以外のプランでは、この数字はいじれる設定ではなく環境の事実です。Cloudflare は原因を 2 つ——オリジンのウェブサーバー上の長時間実行プロセスと、過負荷のオリジンウェブサーバー——挙げていて、これはエッジからは同じに見えるのに本当に別の問題です。前者ではリクエストが実行中で、単にタイムアウトより長くかかっている。後者ではワーカープールが埋まっていて、まだ始まってすらいない。Cloudflare が文書化している対処も同じように分かれます。遅いプロセスはホスティング事業者と詰める。長時間の HTTP 処理はリクエストを開いたままにせず、状態をポーリングする形にする。正当に 125 秒を超えるものは DNS のみ（グレークラウド）のサブドメインの裏へ移して、そもそもプロキシを通らないようにする。そして Origin Analytics で、応答時間が閾値を越える前に近づいていくのを監視する。RFC 9110 §15.6.5 の普通の 504 から引き継がれる性質が 1 つあり、タイマーが長いぶんここではより重要です。Cloudflare が聞くのをやめた時点でもオリジンはまだ働いていたので、524 は「何も起きなかった」証拠にはなりません。
| 紛らわしいコード | 見分け方 |
|---|---|
| 504 | 504 は RFC 9110 §15.6.5 の IETF コードで、時間内に応答を受け取れなかったゲートウェイのためのもの、どのプロキシも返せます。524 は Cloudflare のもので、Cloudflare 自身の 125 秒の Proxy Read Timeout が切れたという意味です。だから Cloudflare 越しに届いた 504 は、Cloudflare の後ろの何かが生成して中継したもので、タイマーは彼らのスタックではなくあなたのスタックの中にあります。経過時間がそれを名指しします。典型的には nginx か Application Load Balancer の 60 秒です。 |
522 | どちらもタイムアウトですが、測っている段階が違います。522 は接続レベルで、Cloudflare の定義は「自分の SYN から 19 秒以内に SYN+ACK が無い」または「接続確立後 90 秒以内にリクエストへの応答が無い」です。524 は応答レベルで、それら全部が成功したあとにしか起きません。だから 524 が出ること自体が、ネットワーク経路もポートもファイアウォールも動いている証明になります。慰めではなく本物の情報です。 |
| 521 | 521 は拒否、524 は沈黙で、この 2 つは完全に排他です。Cloudflare は 521 を、オリジンが接続を拒否した状態と定義していて、止まったプロセス、間違った bind アドレス、Cloudflare のプロキシ対象外のポート、Cloudflare のレンジを弾くファイアウォールを指します。524 は接続に成功した時点でそのすべてを否定しているので、524 を見たあとにポートやファイアウォールに使う時間は、間違った問題に使う時間です。 |
520 | 520 はオリジンが Cloudflare には使えない何か——空・不明・予期しないもの、128 KB の上限を超えるヘッダーも含みます——で答えた場合、524 はそもそも時間内に答えなかった場合です。この区別を保つ価値があるのは、対処に共通点が無いからです。520 はアプリケーションが何を出力しているか（不正なヘッダーや、設定を誤ったオリジンへの HTTP/2 を含む）へ向かわせ、524 はそれにどれだけ時間がかかるかへ向かわせます。 |
Cloudflare Tunnel | トンネル経由のオリジンは、見る場所を変えますがタイマーは変えません。125 秒の Proxy Read Timeout はプロキシされた経路の性質なので、トンネル越しに処理されるリクエストも同じ上限に当たり、コネクタ自身のログがエッジとアプリケーションの間の中間層になります。オリジンのアクセスログと並べて確認してください。コネクタのログにはあってアプリケーションのログには無いリクエストは、アプリケーションに遅くされたのではなく、その手前で並んでいたということです。 |
どれもブラウザ内で完結します。アップロードは発生しません。
524 を調べているとき、ついでに読むことになりがちなコードです。
ページではなく応答ヘッダーを読んでください。curl -sS -o /dev/null -D - https://example.com/path が本文なしでヘッダーだけを出し、server・via・cf-ray の 3 つで、答えたのがどの層かが分かります。cf-ray の値があれば応答を扱ったのは Cloudflare で、その値はサポートが聞いてくる ID です。エッジを完全に外して確かめたいなら、--resolve example.com:443:203.0.113.10 を付けて同じリクエストを投げ直します。元のホスト名と SNI を送りつつ、指定したオリジンのアドレスへ接続するので、答えが変われば、エッジとオリジンの言い分が食い違っているということです。
ありません。分岐条件にしてはいけません。RFC 9112 はクライアントに理由句を無視するよう求めていますし、サーバーは自由に変えられますし、HTTP/2 と HTTP/3 にはそもそも理由句が存在しません。HTTP/1.1 では 404 Not Found として届くものが、HTTP/2 では素の 404 として届きます。このサイトが登録済みの理由句を載せているのは、それが検索される語であり HTTP/1.1 のログに出る文字列だからで、何かのソフトウェアがそれに依存しているからではありません。
5xx と 429 は再試行してよく、4xx はしないでください。次に投げても中身は同じだからです。応答に Retry-After が付いていればそれに従ってください。RFC 9110 がまさにこのために定義していて、値は秒数でも日時でも構いません。付いていなければ、ジッター付きの指数バックオフと明確な上限を使い、しかも冪等なメソッドに限ってください。再試行された POST はカードに二重で課金しかねません。すでに失敗しているサーバーへの再試行の嵐は、短い障害を長い障害に変える典型的な経路です。
変えられます。守るべき規則は 1 つだけ、そのコードが本当であること。応答を自動で読むもの——検索エンジン、監視、キャッシュ、クライアント側の再試行ロジック——はすべて数字だけで判断し、ページの中身は一切見ません。エラーページを 200 で返せば自分の監視から障害が隠れますし、無いページを 200 で返せばエラーが本文として索引されますし、単に不正なリクエストに 500 を返せば、当番の人をスタックの間違った半分へ送り込むことになります。
524 でまだ詰まっているなら、ステータスコード一覧をすべて見る。あるいは上に戻って、自分の立ち位置に向けて書かれたブロックを読んでください。