Cloudflare网络日志新增来源与副本标识：Worker流量更易辨认，旧部署仍需更新

10-01 3阅读

Cloudflare于2026年9月29日更新网络日志，可区分Mesh与Workers VPC流量，并标识接收会话的隧道或Mesh副本。Worker来源名称与标识字段仅对9月29日之后部署的Worker填充，已有Worker需重新部署；不能据此假定历史记录也会补齐。

AI生成概念示意图，非真实产品照片或软件界面。

独立分析：识别来源之后，先确认分类是否完整

日志中增加新的来源类别，可以减少依靠名称习惯猜测身份的工作。不过，下游报表若仍然只认识旧类别，新记录可能被放进“其他”，甚至被过滤掉。采集端出现信息，与分析端真正使用信息，需要分别检查。

以下是虚构的验证场景，不是产品实测。团队安排一台测试电脑、一个测试Worker与一个Mesh节点分别访问同一项测试服务，记录预期路径，再检查日志中的来源、出口与目标副本是否对应实际安排。

同样的目标地址并不代表同样的访问过程。一个请求可能来自用户设备，另一个来自后台任务。调查异常时，先区分这些路径，再讨论是否属于同一问题，能减少把不同来源混成一条时间线的误判。

如果旧部署的来源字段为空，不应直接把它解释成匿名攻击或不存在的任务。本文建议在报表中保留“尚未提供来源信息”的状态，并把部署时间和采集配置作为排查条件。未知有时意味着材料不足，而不是对象异常。

更新部署之后，可以用同一测试请求再次验证。比较时保留更新前后时间点，避免把新旧记录混在一起统计。测试报告应说明哪些字段开始出现，以及原有查询是否能够正确接收这些值。

还要检查自动解析规则是否只允许固定枚举。新增来源类别进入系统后，解析失败可能表现为计数突然下降。此时总流量未必减少，可能只是报表没有接住新记录。抽查原始日志能帮助区分这两种情况。

当多个副本共同提供服务时，知道某次会话落到哪一个副本，可以为进一步检查提供入口。它并不单独证明该副本有故障。还需结合当时的请求、返回状态和服务记录，建立可复查的关联。

可在演练中只让一个测试副本返回特定错误，再检查调查者能否从会话记录找到它。随后恢复正常，确认报表也能观察到变化。这种小范围样本比只展示更多日志列更能说明新字段是否真正有用。

这次更新让网络路径的身份信息更清楚。采用者可以把部署核验、日志解析和调查演练串成一次完整验收，让每个新增字段都对应一个明确问题。数据采到了、被正确解释了，才更可能帮助团队缩短定位过程。

本文于北京时间2026年10月1日核验公开一手资料。后续分析与虚构场景为原创讨论，不代表产品实测或厂商承诺。