跳转到内容
搜索文档

Logpush 中带有源站状态 0 的 504 响应

最后更新 查看 MarkdownAgent 设置

❮ 返回常见问题

为什么我会在 Logpush 中看到 OriginResponseStatus=0 的 504 响应,但仪表板中没有?

如果您将 Cloudflare Logpush 接入 Splunk、Datadog 或其他 SIEM,可能会看到 EdgeResponseStatus=504OriginResponseStatus=0 的日志条目,而这些条目不会出现在 Cloudflare 仪表板的任何位置。

在大多数情况下,这些是 Cloudflare 内部子请求,而不是真实的最终用户错误。最常见的来源是 Early Hints 缓存 MISS 查找,以及 Workers Cache APIcache.match() MISS 返回。这些子请求永远不会到达您的源站,因此您的网站对最终用户仍可正常工作。

Cache Analytics 和仪表板会按设计过滤掉这些子请求。Logpush 会发送边缘产生的每一行日志,包括内部子请求,因此相同的数据会以两种不同的默认过滤条件出现在两处。请在您的 SIEM 中使用 RequestSource 字段过滤掉子请求。

匹配的日志条目是什么样的

您在 SIEM 中的典型条目如下所示:

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

您的应用程序运行正常,源站健康,且该 zone 的仪表板中未出现 504 响应。您的 SIEM 仪表板仍可能每天显示数万条此类条目。

这些字段的含义

来自 HTTP 请求数据集参考

字段 定义
EdgeResponseStatus Cloudflare 返回给客户端的 HTTP 状态码。
OriginResponseStatus 上游服务器返回的状态。值 0 表示未从源服务器收到响应,响应由 Cloudflare 边缘提供。如果该 zone 上运行了 Worker,0 也可能是向源站发起的 Workers 子请求的结果。

单独的 OriginResponseStatus=0 并不是错误信号。它表示 Cloudflare 未为该日志行成功进行源站获取。对于缓存命中、Worker 响应、WAF 拦截、重定向和内部子请求,这都是正常的。

为何会出现这种组合

错误 502/504 页面指出了日志中 504 条目的两种已记录、无害的原因:来自 Early Hints 的缓存 MISS 响应,以及返回缓存 MISS 的 Workers Cache API cache.match 操作。

原因 1:Early Hints 缓存 MISS

来自 Early Hints 文档

启用 Early Hints 时,您可能会在 Cloudflare Logs 中看到大量 RequestSourceearlyHintsCache504 响应,这是预期且无害的。来自 earlyHintsCache 的请求是针对已缓存 Early Hints 的内部子请求,它们既不是最终用户请求,也不会到达您的源站。

其响应状态仅指示请求 URI 是否存在已缓存的 Early Hints:缓存 HIT 时为 200,缓存 MISS 时为 504

当 zone 上启用了 Early Hints,且 Cloudflare 正在查找是否有任何已缓存的 Link: <...>; rel=preloadrel=preconnect 标头可在主响应之前发送给浏览器时,就会发生这种情况。缓存 MISS 表示该 URL 没有已缓存的 Link 标头,因此查找在内部返回 504

如果您的源站不发出 Link preload 或 preconnect 标头,则每次 Early Hints 查找都是 MISS,该 zone 上的每个请求都会产生一条此类内部 504 日志行。在规模上,这可能是每天数百万条条目。

原因 2:Workers Cache API cache.match MISS

来自 Workers Cache API 文档

当请求的内容缺失或已过期时,cache.match 会生成 504 错误响应。Cache API 不会将此 504 直接暴露给 Worker 脚本,而是返回 undefined。尽管如此,底层的 504 在 Cloudflare Logs 中仍然可见。如果您使用 Cloudflare Logs,可能会看到这些 RequestSourceedgeWorkerCacheAPI504 响应。

当 zone 上的 Worker 调用 caches.default.match(request)(或类似调用)且内容不在缓存中或已过期时,就会发生这种情况。API 向 Worker 返回 undefined,但内部的 504 仍会出现在您的日志中。

为何仪表板不显示这些条目

Cloudflare 仪表板对每个分析视图(Cache Analytics、HTTP Analytics 和 Security Analytics)都应用 requestSource = "eyeball" 过滤器。该过滤器会按设计去除内部子请求。

Logpush 是没有此类过滤器的原始日志流。它会发送边缘产生的每一行日志,包括内部子请求。相同的数据以两种不同的默认过滤条件出现在两处,因此仪表板会隐藏这些条目,而您的 SIEM 不会。

要在 GraphQL Analytics API 中复制仪表板的过滤器,请参阅过滤最终用户

确认您看到的内容

RequestSource 字段添加到 Logpush 作业的 output_options.field_names。根据 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 条目:

RequestSource 含义 操作
earlyHintsCache Early Hints 内部子请求(无害) 过滤掉
edgeWorkerCacheAPI Workers Cache API MISS(无害) 过滤掉
eyeball 或为空 真实的最终用户请求 作为真正的 504 进行调查

在 SIEM 中过滤

在您的 SIEM 仪表板、提醒和查询中添加等效于以下内容的过滤器。这会复制 Cloudflare 仪表板对其分析视图应用的过滤器。

Splunk:

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

Datadog:

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

Sumo Logic 或通用:

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

何时 504 且源站状态为 0 是真正的问题

并非每个带有 OriginResponseStatus=0504 都是内部子请求。真正的源站侧故障会产生相同的字段组合:

  • 源站超时 — Cloudflare 已打开连接(或尝试打开),但未收到响应。由于未收到状态,OriginResponseStatus 保持为 0
  • Cloudflare Tunnel 无法到达源站cloudflared 已连接但无法到达已配置的服务。请参阅 Tunnel 常见错误
  • Worker 向源站的 fetch() 失败或超时 — 根据 OriginResponseStatus 字段定义,如果 zone 上运行了 Worker,值 0 可能是向源站发起的 Workers 子请求的结果。

RequestSource 字段可将这些情况与内部子请求区分开。如果 RequestSourceeyeball 或为空,且边缘返回了 504,请调查源站健康状况、Tunnel 连接性或 Worker 可靠性。

从源头停止噪声

如果您不从 Early Hints 中受益——例如,您的源站不发出 Link preload 或 preconnect 标头——您可以完全关闭 Early Hints:

  1. 在 Cloudflare 仪表板中,前往 Speed(速度) > Optimization(优化) > Content Optimization(内容优化)
  2. 关闭 Early Hints(早期提示)

这会在源头消除 earlyHintsCache 子请求,而不是在下游过滤它们。要检查 Early Hints 是否对您的 zone 有实际作用,请查询 GraphQL Analytics API 中向客户端提供的 103 状态码。如果该计数为零而 earlyHintsCache 活动很高,则 Early Hints 已开启但未提供任何内容。

对于 Workers Cache API 情况,504 MISS 行为是 cache.match 表示未命中的固有方式。在 SIEM 中过滤是适当的修复方法。

摘要

  1. RequestSource 添加到 Logpush 作业的 field_names
  2. 等待大约 15 分钟,以便更改传播。
  3. 检查 504 / 0 条目上的 RequestSource 值。
  4. 在 SIEM 中过滤掉 earlyHintsCacheedgeWorkerCacheAPI
  5. 如果您所有的 504 / 0 条目都是 earlyHintsCache,且您不提供 Link preload 标头,请考虑在 Speed 设置中关闭 Early Hints。
  6. 仅将 RequestSourceeyeball 或为空的条目作为真正的源站问题进行调查。

相关资源

这篇文档对您有帮助吗?