当请求命中带有 Worker 的 zone 时，初始 HTTP 请求日志表示最终用户到 Worker 的请求。如果该 Worker 随后对你的源站发出 fetch() 请求，Cloudflare 会为该 Worker 子请求写入第二条 HTTP 请求日志。
因为初始日志条目仅涵盖从客户端到 Worker 的请求，所以该条目上的 OriginResponseStatus 为 0，OriginIP 为空。这些字段会在第二条日志条目上填充，该条目表示 Worker 到源站的 fetch。有关 OriginResponseStatus=0 在不同上下文中的含义，请参阅 Logpush 中带有源站状态 0 的 504 响应。
| 日志条目 | 典型的 ClientRequestSource 值 |
表示内容 | 源站字段 |
|---|---|---|---|
| 初始请求 | eyeball |
最终用户到 Worker 的请求 | OriginResponseStatus 为 0，OriginIP 为空 |
| Worker 子请求 | edgeWorkerFetch |
Worker 到源站的 fetch() 请求 |
在联系到源站时设置 |
请参阅 ClientRequestSource 字段，了解可能的 ClientRequestSource 值的完整列表。
每条日志条目都有自己的 RayID。Worker 子请求还包含 ParentRayID，即触发它的请求的 RayID — 其直接父请求。
| 字段 | 初始请求 | Worker 子请求 |
|---|---|---|
RayID |
最终用户请求的唯一请求 ID | 子请求的唯一请求 ID |
ParentRayID |
空 | 触发它的请求的 RayID |
要关联这两条记录：
- 找到初始请求并记下其
RayID。 - 搜索
ParentRayID等于该RayID的日志条目。 - 查看匹配的子请求日志条目中的
OriginIP、OriginResponseStatus和其他源站字段。
一个最终用户请求可以产生多条 Worker 子请求日志条目。每个子请求都有自己的 RayID，且这些日志条目各自将触发请求的 RayID 用作其 ParentRayID。
ParentRayID 是单层的 — 它指向直接父请求，而不是原始最终用户请求。在单 Worker 设置中，这一区别无关紧要，因为父请求就是最终用户请求。当 Workers 被链式调用时（例如，Worker A 调用 Worker B，Worker B 再调用源站），Worker B 的子请求日志将 Worker A 的 RayID 作为其 ParentRayID，而不是最终用户的。要完整追溯到最终用户请求，请逐级跟随每个 ParentRayID。
将初始请求与匹配的子请求条目结合使用，可以重建从客户端到 Worker 再到源站的完整请求路径。
# Initial request
ClientRequestSource: eyeball
RayID: 7b52f2c4f9f64c1a
ParentRayID:
OriginResponseStatus: 0
# Worker subrequest
ClientRequestSource: edgeWorkerFetch
RayID: 7b52f2c4f9f64c1b
ParentRayID: 7b52f2c4f9f64c1a
OriginResponseStatus: 200
OriginIP: 192.0.2.10如果 Worker 未对源站发出 fetch() 请求，则没有可关联的 Worker 到源站日志条目。例如，Worker 可能直接返回响应而不联系源站。
为更轻松地调查 Worker 子请求，请在 HTTP 请求日志中包含这些字段：
RayIDParentRayIDClientRequestSourceOriginIPOriginResponseStatus