摘要

  • 同一字段可以既必须被保留，又不能被当作可信证据。CDN-Loop 的协作价值与其内容的真实性，是两件不同的事。
  • 一个供应商名称出现多次，可能对应合法的内部处理层次。采购合同中的供应商数量，不能直接换算成防护规则应容忍的重复次数。
  • 本地拦截、实际经过的路径以及发起者的身份和意图，需要分别举证。把拦截记录直接升级为责任认定，会制造防护之外的第二种风险。

合同分开了，请求没有

一家公司为了业务连续性，把内容分发交给不止一家供应商。采购表上，这可以表现为两份合同、两个服务等级承诺、两个责任窗口。但一个请求不会因为跨过合同边界，就自动摆脱前一段配置留下的影响。

设想一种没有指向真实客户的情形：请求按设计从一家 CDN 进入另一家，随后某次配置变更让它重新回到较早的处理阶段。接收方依据循环防护规则将其拒绝。应用团队发现源站没有收到请求，供应商则能出示一次本地保护动作。双方都可能在准确描述自己的观察，却仍未回答同一个问题：这次返回到底属于设计中的处理，还是不该继续的循环？

本文没有对生产网络做这种实验。这个假设只是把一个容易被采购语言遮住的边界展开：交付链条中的配置权、防护权和解释责任，并不天然属于同一个主体。

CDN-Loop 提供的不是一张跨供应商通行证明。它更像一个必须随请求继续携带的警示线索。下一家可以用它决定是否停止处理，但不能仅凭线索存在，就声称已经核实其记载的整个过程。

客户能编程，不等于能改写全部信号

2019 年 4 月发布的 RFC 8586 定义了这一请求头字段。规范建议参与者在生成或转发请求时追加自己的标识；机制能否起作用，依赖中间方保留已有内容，并禁止客户通过配置修改或删除该字段。规范也建议不要把它挪作其他用途。

这里限制的不是客户对应用的所有控制，而是一项会影响后续参与者的具体操作。删除一个字段的便利，可能出现在本地配置界面；丢失检测线索的代价，却可能由下一家承担。这是对激励结构的分析，不是对某家供应商现有功能的指控。

因此，“我们支持这个请求头”还不是完整的交付承诺。至少还要解释三个不同的决定：客户允许改哪些内容，转发环节如何保留已有标记，接收环节怎样解释重复。它们可以由不同团队实现，也需要在变更时重新接上。

普通的责任切分往往按产品划线。故障却会沿着请求继续向前。一个团队在自己的边界内完成了修改，并不意味着它已验证修改对下一段防护的影响。跨供应商协作的成本，恰恰藏在这种局部正确之间。

RFC 的官方状态记录将其列为拟议标准。这个身份不等于所有供应商都已部署，也不证明任何指定客户组合已经兼容。已核实的技术勘误修正的是语法规则引用，并没有替运营方解决这些责任问题。

两个供应商，未必只有两次处理

如果只看供应商名称，重复似乎是一个简单问题：同一个名字又出现了，请求大概在打转。但供应商内部的处理阶段，比采购表上的一行名称更细。

截至 2026 年 9 月 8 日查阅的 Fastly 文档说明，视集群和 shielding 配置而定，可能出现最多四个 Fastly 标记。这个数值只描述该文档限定的实现情境，不能拿去作为其他网络通用的安全阈值。

值得关注的不是“四”这个数字，而是它否定了一个过度简化的对应关系：同名标记再次出现，不必然等于商业链路重新绕回起点。内部处理层、缓存保护层和对外供应商，是不同尺度的对象。

Cloudflare 当前请求头文档说明，CDN-Loop 可用于限制请求进入其网络的次数；页面标注的更新时间为 2026 年 5 月 5 日。2019 年 3 月 20 日的厂商文章还讨论了子请求等合法重复处理情形。前者是现行文档，后者是历史叙述；二者都不是对本文假设客户的实际配置审计。

这些材料不能排出哪家更安全，却可以改进验收问题。问题不应只是“有没有这个字段”，而应是：这条被支持的路径中，一次正常完成本来就会经过哪些阶段？防护规则识别的单位与这些阶段是否一致？

加一层服务后，采购对象可能没有变，重复的含义却变了。仍沿用旧的计数解释，未必还能描述新的交付过程。把服务图画得简洁，有利于沟通；把简化图当成防护规则的全部依据，则会遗漏真正需要判断的部分。

保留不等于背书

RFC 8586 同时明确指出，任意客户端都能生成这个字段，因此其内容不可信；依据它改变行为时，还要避免引入新的拒绝服务风险。规范允许设想签名，但并未定义或要求签名方案。字段及系统对它的反应，也可能暴露供应商存在或内部结构。

这并不推出“既然不可信，就应删除”。删除会破坏协作机制本身。更合理的边界是保留其防护用途，同时限制由它能够支持的结论。

一条可靠的本地日志可以证明：某项规则在当时触发了某种动作。它不能自动证明列表里的每一段路径真实发生，更不能直接证明某家组织、某个客户或某个人怀有恶意。后面的结论可以继续调查，但需要其他证据。

这也是为什么可读性和可信性不能混用。一个标识看起来像熟悉的机构名称，便于值班人员识别；这种熟悉感并没有让它变成那家机构的声明。使用受控主机名可以减少某些命名碰撞问题，也不会独自认证携带它的请求经历。

防护系统无须先完成全部归因调查，才有资格做本地保护。反过来，它做了保护，也不能被写成已经完成全部调查。若组织把这两步合并，技术上可以恢复流量，管理上却可能留下未经证实的责任结论。

源站没看到，不代表问题已经解释

请求在前面被停止，源站可能根本没有对应的到达记录。这个缺失对定位有用，但它不足以告诉源站团队，哪一段采取了什么决定，更不足以判断该决定是否适合当时的路径。

一个有用的解释，应把局部规则、相关配置版本和设计中的处理阶段联系起来。本文提出的是运营记录建议，而非 RFC 新增的字段要求。其目的不是积累一切数据，而是让人员能够区分“路径变了”和“规则对同一路径的解释变了”。

记录也不必变成公开的全网拓扑。更多内部名称未必带来更强证明，却可能增加披露成本。谁能看、为何保存、何时失效，应与需要回答的问题相称。

同样，某次调整后业务恢复，支持的是这次调整与服务恢复之间的运营解释。它不会倒过来使旧请求头中的全部内容都成为事实。恢复结论可以明确，归因结论仍然保留不确定性；这不是报告不完整，而是证据边界完整。

方法的约束，比立场更重要

现有来源包括标准文本、官方勘误和厂商文档。它们没有提供当前攻击频率、全面采用情况、供应商比较成绩，也没有说明某一客户此刻实际执行的策略。本文未生成测试循环，也未修改任何客户服务。

Lu Heng 在互联网治理代理问题的文章中追问权力与风险承担的分离。本文借用的是这个分析问题，不是把针对地址注册治理的论断迁移到 CDN。关于 BTW Media 以现实而非倡导为产品的文章则提供了另一条方法约束：先把具体机制和限制解释清楚，再讨论评价。

这里的现实不是“多供应商必然更复杂”，也不是“所有保护都值得信任”。它更具体：一个参与者可能必须继续传递某项信息，却无权替信息的全部含义背书。能否守住这一区别，决定了协作防护会不会被误用成未经核实的裁决。