Logpush で origin status が 0 の 504 レスポンス

❮ FAQ に戻る

Cloudflare Logpush を Splunk、Datadog、その他の SIEM に取り込んでいると、EdgeResponseStatus=504 かつ OriginResponseStatus=0 のログ行が、Cloudflare ダッシュボードのどこにも出ないのに見えることがあります。

ほとんどの場合、これは実際のエンドユーザーエラーではなく、Cloudflare の内部サブリクエストです。よくある発生源は、Early Hints のキャッシュ MISS 参照と、Workers の Cache API で cache.match() が MISS を返すケースです。これらのサブリクエストはオリジンに届かないため、エンドユーザー向けのサイトは通常どおり動作します。

Cache Analytics とダッシュボードは、設計上これらのサブリクエストを除外します。Logpush はエッジが生成するすべてのログ行を送るため、内部サブリクエストも含まれます。同じデータが、既定のフィルターが異なる 2 か所に現れます。SIEM では RequestSource フィールドを使ってサブリクエストを除外します。

SIEM では、典型的なエントリは次のように見えます。

EdgeResponseStatus: 504
OriginResponseStatus: 0
ClientRequestHost: www.example.com
EdgeStartTimestamp: 2026-04-15T10:23:17Z

アプリケーションは通常どおり動作し、オリジンも健全で、このゾーンのダッシュボードには 504 レスポンスは出ません。それでも SIEM のダッシュボードでは、こうしたエントリが 1 日あたり数万件出ることがあります。

HTTP requests データセットのリファレンス より:

OriginResponseStatus=0 だけではエラーの合図ではありません。そのログ行について、Cloudflare がオリジンへの取得に成功していないことを意味します。キャッシュヒット、Worker のレスポンス、WAF ブロック、リダイレクト、内部サブリクエストでは普通です。

Error 502/504 のページ では、ログ上の 504 について文書化された無害な原因が 2 つあります。Early Hints のキャッシュ MISS レスポンスと、Workers Cache API の cache.match がキャッシュ MISS を返す操作です。

Early Hints のドキュメント より:

Early Hints を有効にしていると、Cloudflare Logs で RequestSource が earlyHintsCache の 504 レスポンスが増えることがあります。これは想定どおりで無害です。earlyHintsCache からのリクエストは、キャッシュされた Early Hints を探す内部サブリクエストであり、エンドユーザーのリクエストでもなく、オリジンにも行きません。

レスポンスステータスは、そのリクエスト URI にキャッシュされた Early Hints があるかどうかだけを示します。キャッシュ HIT なら 200、キャッシュ MISS なら 504 です。

これは、ゾーンで Early Hints が有効で、Cloudflare がメインレスポンスより先にブラウザーへ送るキャッシュ済みの Link: <...>; rel=preload または rel=preconnect ヘッダーがあるかを調べているときに起きます。キャッシュ MISS は、その URL にキャッシュされた Link ヘッダーがないことを意味し、参照は内部的に 504 を返します。

オリジンが Link の preload または preconnect ヘッダーを出していない場合、Early Hints の参照はすべて MISS になり、ゾーン上のリクエストごとにこうした内部 504 のログ行が 1 本出ます。規模が大きいと、1 日あたり数百万件になることがあります。

Workers Cache API のドキュメント より:

cache.match は、要求したコンテンツがない、または期限切れのときに 504 エラーレスポンスを生成します。Cache API はこの 504 を Worker スクリプトに直接は見せず、代わりに undefined を返します。それでも、背後の 504 は Cloudflare Logs に残ります。Cloudflare Logs を使っていると、RequestSource が edgeWorkerCacheAPI のこうした 504 レスポンスが見えることがあります。

これは、ゾーン上の Worker が caches.default.match(request)（または同等の呼び出し）を実行し、コンテンツがキャッシュにない、または期限切れのときに起きます。API は Worker に undefined を返しますが、内部の 504 はログに残ります。

Cloudflare ダッシュボードは、Cache Analytics、HTTP Analytics、Security Analytics など、すべての分析ビューに requestSource = "eyeball" フィルターを適用します。このフィルターは、設計上内部サブリクエストを取り除きます。

Logpush は、そうしたフィルターのない生のログストリームです。エッジが生成するすべてのログ行を送り、内部サブリクエストも含みます。同じデータが、既定のフィルターが異なる 2 か所に現れるため、ダッシュボードはこれらのエントリを隠し、SIEM は隠しません。

GraphQL Analytics API でダッシュボードと同じフィルターを再現するには、エンドユーザーで絞り込む を参照してください。

Logpush ジョブの output_options.field_names に RequestSource フィールドを追加します。フィールドの変更は、API 構成リファレンス のとおり、およそ 10〜15 分で反映されます。

curl -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/logpush/jobs/$JOB_ID" \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "output_options": {
      "field_names": ["...existing fields...", "RequestSource"]
    }
  }'

フィールドが流れてきたら、504 / 0 のエントリを再確認します。

SIEM のダッシュボード、アラート、クエリに、次と同等のフィルターを追加します。Cloudflare ダッシュボードが分析ビューにかけているフィルターを再現します。

Splunk:

NOT RequestSource IN ("earlyHintsCache", "edgeWorkerCacheAPI")

Datadog:

NOT @RequestSource:("earlyHintsCache" OR "edgeWorkerCacheAPI")

Sumo Logic または汎用:

!(RequestSource = "earlyHintsCache" OR RequestSource = "edgeWorkerCacheAPI")

OriginResponseStatus=0 の 504 が、すべて内部サブリクエストであるとは限りません。オリジン側の実際の障害も、同じフィールドの組み合わせになります。

• オリジンのタイムアウト — Cloudflare は接続を開いた（または開こうとした）が、レスポンスを受け取れませんでした。ステータスを受け取っていないため、OriginResponseStatus は 0 のままです。
• Cloudflare Tunnel がオリジンに到達できない — cloudflared は接続していますが、設定したサービスに到達できません。Tunnel のよくあるエラー を参照してください。
• オリジンへの Worker fetch() が失敗またはタイムアウトする — OriginResponseStatus のフィールド定義のとおり、ゾーンで Worker が動作している場合、値 0 はオリジンへの Workers サブリクエストの結果になることがあります。

RequestSource フィールドで、内部サブリクエストとこれらを区別します。RequestSource が eyeball または空で、エッジが 504 を返している場合は、オリジンの健全性、Tunnel の接続、または Worker の信頼性を調査します。

Early Hints の恩恵がない場合（たとえば、オリジンが Link の preload または preconnect ヘッダーを出していない場合）、Early Hints を完全にオフにできます。

1. Cloudflare ダッシュボードで Speed > Optimization > Content Optimization に移動します。
2. Early Hints をオフにします。

これで earlyHintsCache のサブリクエストを、下流で除外するのではなく発生源で止めます。ゾーンで Early Hints が実際に役立っているかは、GraphQL Analytics API でクライアントに返した 103 ステータスコードを照会します。その件数がゼロなのに earlyHintsCache の活動が多い場合、Early Hints はオンですが何も配信していません。

Workers Cache API の場合、504 の MISS 動作は cache.match がミスを伝える仕組みそのものです。SIEM で除外するのが適切な対処です。

1. Logpush ジョブの field_names に RequestSource を追加します。
2. 変更が反映されるまで、およそ 15 分待ちます。
3. 504 / 0 のエントリで RequestSource の値を確認します。
4. SIEM で earlyHintsCache と edgeWorkerCacheAPI を除外します。
5. 504 / 0 のエントリがすべて earlyHintsCache で、Link の preload ヘッダーを配信していない場合は、Speed 設定で Early Hints をオフにすることを検討します。
6. RequestSource が eyeball または空のエントリだけを、実際のオリジン問題として調査します。

• HTTP requests データセット — フィールドリファレンス
• Early Hints — Early Hints を送る
• Workers Cache API — エラー
• Error 502 または 504
• GraphQL Analytics API — エンドユーザーで絞り込む
• Logpush API 構成
• Cloudflare Tunnel — よくあるエラー
• Worker サブリクエスト — Worker サブリクエストのログ行にオリジンフィールドが出る理由