摘要

  • CDN-Loop 保护的是跨参与者保留的防环信号，不是禁止客户组合服务，也不是规定全球统一的访问次数上限。
  • 合规平台不能让客户通过配置改写或删除该字段，但外部客户端仍可以自行发送它。“不能改”与“可以相信”属于不同边界。
  • 同一平台重复出现，可能对应正常的内部阶段。语法拒绝、本地环路拦截与源站故障必须分开判断，供应商计数规则也不能脱离其单位使用。

一项配置自由，为什么影响别人的资源

客户购买边缘服务，往往正是为了决定下一步：让请求到某个源站、进入另一家 CDN，或者先经过自己选择的处理服务。这不是异常需求。多层缓存、边缘逻辑与备用路径，都可能依赖这种组合能力。

问题出在“下一步”最后回到了“上一步”。假设客户把第二个服务接在第一个服务后面，后来一个 DNS 或服务配置变化，使第二个服务的目标又落回第一个网络。各个界面里都只有一个看似普通的后端选择，组合起来却出现了返回。这是说明机制的假设情景，并非本文发现的新生产事故。

返回本身会让已经处理过请求的系统再次投入资源。如果请求还携带先前经过该系统的防环标记，运营者就有机会识别重复工作。如果中间一段客户可控制的变换把标记删除了，后续参与者看到的请求便失去了这一提醒。一个人的配置自由，改变了另一个人判断是否继续工作的条件。

NDSS 2016 的原始转发环路研究在受控研究中展示了这种跨平台相互作用。研究当时检查了十六家常用供应商，各家都存在某种被研究确认的转发环路弱点，其中包括借助另一平台的请求头过滤功能绕过防护的情况。这个结论有明确的历史时间与样本范围。它早于本文讨论的标准，不能被改写成这些供应商在 2026 年仍然都存在相同漏洞。

值得保留的不是对整个行业的永久指控，而是一个结构性问题：提供转发选择权的系统，如何防止客户顺便取得删除公共防护记忆的权力？答案不需要把所有路由交给中央批准，却必须说明哪一小块共享信息不能由单个租户随意清空。

客户可以选路，但不能删掉别人的提醒

官方资料将 RFC8586 列为 2019 年 4 月发布的 Proposed Standard。CDN-Loop 是 HTTP 请求字段，帮助 CDN 识别请求是否已经经过本网络。它不是浏览器跳转历史，也不是 DNS 决策的完整日志。

RFC8586 的规范正文建议合规 CDN 在生成或转发请求时添加自己的条目，必要时建立该字段。这里使用 SHOULD，不能被升级成每一家 CDN、每一条真实请求都必然执行的全球事实。文档规定了参与实现应怎样协调，不是部署普查。

对于客户配置，边界则十分明确：机制要发挥作用，CDN 就不能让客户修改或移除这个字段。有效性依赖中间参与者保留它；若某平台允许客户删改，该平台依然可能成为针对参与与不参与该机制网络的攻击入口。

这个限制的对象很小。客户选择源站、加入其他供应商、安排服务链的自由，并未因此自动消失。一般请求头转换也不是一概禁止。不能让出的，是会影响同行识别重复工作的一项共享防护表面。

因此，面对一条确实有业务理由的服务链被拒绝，“给这个客户一个删除开关”不是中性的兼容措施。它会改变链上其他参与者拥有的信息。适当的问题是：本平台究竟如何计算这条链、何时拒绝、允许什么有明确责任边界的重复经过？这属于运营者的本地策略讨论，不等于让客户把公共标记擦掉。

协调的价值，正来自其余选择依然分散。没有一个机构替所有客户画好唯一合法路径；不同运营者却可以先约定，谁都不能通过自己的租户配置破坏同行使用的共同提醒。

“平台内受保护”不等于“入口内容已认证”

RFC8586 同时指出，任何客户端都能生成 CDN-Loop，因此收到的内容不能被当作可信的路径事实。乍看之下，这似乎与“客户不能修改”冲突。其实两句话谈的是两道边界。

一道边界是商业客户在平台配置面上拥有什么权限。合规平台不能向这个客户提供改写或删除公共字段的能力。另一道边界是外部发送者在进入平台之前写了哪些字节。平台内的权限限制，并不能倒过来证明这些字节是谁产生、请求是否真的经过了所称的网络。

可以用一个假设说明区别：发送者声称请求已经访问过某 CDN，但实际没有。如果接收方把这个说法当作不可争议的历史，便可能拒绝一条本应正常处理的请求。这里是在分析可能的误拒绝机制，不能当作针对某家供应商已验证的最新攻击。RFC 本身要求注意，基于字段内容改变行为，不应反而引入拒绝服务风险。

可也不能因此简单删除所有入口值。那样做会一起删掉上游真实参与者留下的标记，重新破坏共同防护。保留与解释，必须同时考虑，又不能混成同一个动作。运营者需要明确，自己能够安全地据此推断什么，哪些内容只是发送者的主张。

规范提到可以签名，但既没有定义，也没有要求一套签名方案。不能因为两家供应商都识别 CDN-Loop，就假定它们共享密钥、理解彼此的专有哈希，或者已经能认证整个经过顺序。单段连接的传输保护，也不是全程路径证明。

标记不宜被顺势包装成计费依据、访问授权、位置证明或责任归属的最终裁决。防护信号可以很有用，而不具备这些更强用途所需的证据能力。对其限制保持诚实，不是在削弱合作，而是在阻止一项小工具承受无法履行的承诺。

一个共享名字，不是一个全球身份机关

当前 IANA HTTP 字段登记表让 CDN-Loop 的名称与 RFC8586 引用可被不同实现一致识别。登记的作用是统一引用，不是认证每个参与端点，也不是证明某条客户链始终完整保留了字段。

规范允许标识符使用 CDN 控制的主机名，可附带端口，也允许符合语法的假名。优先使用主机名，可以减少偶然碰撞。但发送者在请求里写出一个受控主机名，不等于发送者已经证明自己控制那个名字，更不等于证明请求之前真的经过了该网络。

可选参数给 CDN 留下记录自身所需信息的空间。参数存在，不会让每家平台的计数器自动拥有同一种含义。共享语法没有变成全球共享计数状态，更没有产生统一裁判每次访问是否合法的机构。

同样，条目既可以用逗号分隔放在同一字段行，也可以分成多行。数物理行数，不能代替正确识别条目。把每个重复出现的名字都算成一家公司，也会误读包含内部多阶段的实际产品结构。

最小共同协议的价值是让信号跨边界留存并被识别。它并未承诺一个全球真实、完整、可认证的路径账本。承认前者，并不需要虚构后者；拒绝后者，也不应抹掉前者的实际价值。

重复进入，可能正是正常架构

“请求第二次出现就一定有问题”，不是 RFC8586 的统一政策。一个网络可能包含多层缓存、多个服务，或者会生成子请求的边缘计算。客户有正当理由让请求再次经过同一平台，运营者也有正当理由给这种重复工作设置本地界限。

Cloudflare 当前请求头文档将 CDN-Loop 描述为限定请求进入其网络多少次后被当作环路阻止的机制，同时列出其他与防环有关的字段。它证明的是产品功能，不是所有供应商共用一套计数器，也没有为每类当前客户给出统一数字。

Cloudflare 在 2019 年 3 月的实现说明解释了为什么需要更细的处理：包括 Workers 子请求在内的某些合法流程，会多次穿过边缘。那篇文章讨论的是正式 RFC 发布前的草案与当时实践，不能替代最终规范，也不能当作今天所有账户的完整策略。

本地策略决定的，是所识别的经过属于什么阶段，以及平台愿意承担多少重复工作。缺少这个上下文，看到同一个品牌再次出现，就宣告客户配置恶意或错误，是把标记当成了它并不提供的裁决。

数字必须带着“此前”和单位一起读

Fastly 当前 CDN-Loop 参考文档说明其在网络转交时添加该字段，并将其与专有的 Fastly-FF 区分。根据内部聚合与保护缓存配置，文档示例中可能出现最多四个 Fastly 条目。这不是四家公司，也不是 RFC 要求每条请求包含四次经过。

Fastly 当前错误说明进一步公开了若干本地限制：针对这个服务、在这个 POP 的先前访问最多三次；先前执行过的不同 Fastly 服务最多六个；先前总跳数最多二十，其中一跳指两个 Fastly 服务之间的交接。

这些数字有三个不同单位，“先前”也是定义的一部分。它们不能被压缩成“全球 CDN 最多访问三次”，不能把同一 POP、特定服务与不同服务数量抹平，更不是 RFC8586 为全行业规定的阈值。购买对比表只摘数字、不带单位，会制造一种不存在的统一规则。

该文档也讨论了有意的服务链，以及后端第三方本身也是 Fastly 客户的情形。业务意图正常，与平台规则实际拒绝，可以同时成立。需要厘清的是本地服务构成和拒绝点，而不是让客户隐藏这段构成。

这些是当前供应商文档中的行为说明，不是所有产品都会写出相同条目数量的证明，也不是永远不变的产品保证。准确的表述，既不贬低文档提供的细节，也不把细节扩张为全球承诺。

都是失败，却不是同一种失败

Fastly Compute 错误参考把 CDN-Loop 语法无效与直接环路或无效服务链区分开。前者可以是带有错误字段诊断的 400 拒绝，后者描述为 503 的环路检测结果，并涵盖 Compute 与 CDN 服务间的阶段转换。

语法拒绝说明入口字段无法按预期处理；环路拒绝说明平台依据本地规则阻止了识别出的服务链；源站故障则是另一个问题。若在可用性报表里全部记成“源站返回失败”，便把真正决定拒绝的边界藏了起来。

例如，新增请求头规范化环节后，语法拒绝增多，与新接入一个服务阶段后累计经过触发拒绝，值得调查的是不同位置。这里只给出条件性调查方向，不是在报告本文测得的线上指标。一条字段内容，更不能被视为无需关联证据的确定原因。

Fastly-FF 参考文档有一个很好的对照：该专有字段在 VCL 中受保护，不允许修改，但外部请求仍可携带它。文档还区分 Compute 在 CDN-Loop 中使用哈希等产品行为。专有内部验证可能对本平台有用，却不能据此称为 RFC8586 定义的跨 CDN 签名。

证据的有效范围应与证据一起保留。当地诊断对当地调查有意义，不会因为转发到了另一家公司，就自动取得给全程归责的权力。

Via 的历史教训，并未取消 Via

Cloudflare 2016 年 1 月的实现文章曾主张借助 Via 建立共同防环保护。2019 年的回顾则讨论了实际困难，包括当时部分 HTTP 功能与压缩行为的相互影响。一个理论上可以复用的字段，可能已经承担其他语义，因而新用途需要付出额外兼容代价。

这不是“今天所有服务器看到 Via 都会禁用压缩”的证据，也不是“有 CDN-Loop 就不需要 Via”的许可。当前 HTTP 语义规范 RFC9110仍独立规定 Via 的协议与中间参与者信息，以及代理和网关的相关义务。

Via 对某些可选注释、同控制域内特定条目组合的规则，也不能借给 CDN-Loop 当作删减身份的理由。两者都在 HTTP 中，不意味着权限合同相同。避免一个新功能完全依赖旧字段的副作用，不等于宣布其余旧义务作废。

这是规范化中容易被营销口号遮住的一层：新协议可以缩小一个问题，而不是把所有历史复杂性一次清空。参与者需要知道共同表面究竟承担什么，也需要知道旁边那些表面依然承担什么。

中间那台转换器，可能不在采购问题里

请求不只经过 CDN。API 网关、通用清理规则或规范化服务，都可能在两个运营者之间处理请求头。即使主 CDN 的客户界面没有删除开关，也不能据此证明每条备用路径都保存字段。

Oracle 当前受保护字段清单列明，API Gateway 的头部转换策略不能改变请求中的 cdn-loop。它证明该产品的这一限制，不能单独证明环路算法、RFC 实现或客户架构端到端正确。指出遗忘中间转换步骤的风险，是集成分析，不是宣告 Oracle 存在已观察到的新漏洞。

真正有用的购买问题应当具体：哪些阶段有能力改变该字段？本平台把什么当成一次经过？哪个环节在什么时候拒绝？谁负责查看一条合法服务链的例外？一句“支持标准”无法替代这些问题，反而可能隐藏决定实际可组合性的本地解释。

观察也有代价。字段可能暴露另一个 CDN 的存在，或透露内部主机和阶段。使用假名能减少字面主机名暴露，不等于保证路径匿名或不可关联。为解释事故而把原始值广泛交给客户日志，可能造成事后无法收回的信息披露。

不把证据拼成过强的结论

NDSS 2016 的论文收录记录与原始论文，确认研究的出处与历史范围。RFC 说明机制，供应商资料说明产品，登记表统一引用。它们不能拼成一项最新漏洞普查，不能证明防环字段已经防住所有资源放大，也不能证明每条请求都有完整经过记录。

卢恒关于最小初始规范、本地后续决定与自愿采用的文章提供一个治理视角：《The Policy Mirror》所帮助区分的，是共同协调与看似统一的行政控制。本文借此分析 CDN-Loop，不代表 IETF 或供应商赞同该文章。

共同防护可以很窄，而仍然有价值。参与者先明确某个标记不能被单个客户擦除，之后各自决定如何计算与拒绝。这个安排保留了同行采取本地决定的条件，却没有假装标记能认证整段旅程。既看到它保护什么，也看到它不证明什么，才是可持续合作的边界。