Cloudflare Traces进入公开测试：平台请求链路可追踪，采样与上下文信任要分开配置
2026年10月2日，Cloudflare宣布Traces进入公开测试，将自动追踪从Workers扩展到请求经过的其他平台环节。官方列举的可见内容包括受支持的安全规则、请求改写、缓存判断、路由、Worker执行和源站处理。每个span记录某一步的耗时、结果及相关属性，帮助运维人员沿同一请求分析异常。
配图为AI生成的概念插图，表现一条请求路径被分解成可观察的阶段，不是Cloudflare控制台或真实生产追踪数据。
让边缘与应用之间的空白更可见
源站日志往往只看到已经到达应用的请求。如果请求在前面被规则挑战、改写地址或命中缓存，单看应用日志无法还原这些决定。按官方文档，Traces可以围绕Ray ID筛选具体请求，并按层级展开操作；调查者由此能把“未到源站”和“源站处理慢”放在不同的证据路径上。
这项能力的实际价值，是减少拼接零散日志和推测配置效果的过程。一个缓存未命中的慢请求，可以继续查看源站连接和处理阶段；一个路由不符的请求，则优先检查匹配到的路由或改写规则。这里的“全链路”仍依赖受支持的span与应用侧埋点，不能把产品名称理解为平台每个内部步骤都已开放。
采样规则的顺序会改变调查结果
Traces按域名单独启用。配置文档说明，默认采样率决定常态记录比例，Trace Rules可覆盖匹配请求的采样率，并采用第一条匹配规则。因此，规则顺序本身就是配置的一部分。排障时可以只提高特定路径或临时调试请求的采样率，避免整个域名都切到高比例。
基于这一机制，团队应把“没有找到trace”和“该请求没有发生”区分开来。若基线采样较低、规则未命中或规则尚处于草稿状态，缺少样本不能证明服务正常。较可靠的验证是在部署规则后发出一条可识别测试请求，核对其Ray ID和实际span，再开始收集故障样本。
接上上下文，还要审查信任边界
Cloudflare支持W3C Trace Context，可接收入站traceparent并向源站转发上下文，也可将span通过OTLP导出。官方特别说明，入站上下文默认Reject；允许接收时，不会验证调用者是否可信，应把连接起来的追踪视为不可信输入。源站转发也不会自动完成源站埋点，需要应用自身继续产生span。
如果希望在第三方平台查看同一条完整追踪，需要把Cloudflare与应用的span送到同一个兼容目的地。由此带来的工程要求是统一标识传播和采样策略，同时避免把追踪标识当作认证依据。看到同一个trace ID，能够帮助关联事件，却不能证明请求由某个可信用户发起。
计费时间表与未来能力别混在一起
官方计划从2026年12月1日起采用按摄入数据量和存储量计费的统一方案；定价页另注明Enterprise按合同续期迁移。公告与当前定价页的付费存储赠送额度分别出现10和12 GB-month，做预算时应复核最新定价及合同，不能直接照抄公告示例。
更广泛的Access、DDoS及Workers相关埋点、经过认证的上下文传播，以及最长365天留存，均列在后续计划中。当前评估应以已可采集的请求路径为基础，先证明它能解释一类实际故障，再决定采样和留存投入。
官方资料
资料核对：2026年10月3日（北京时间）。产品状态、价格与支持范围以官方后续更新为准。
