CDN 切换源站，是一项常见的运维操作。
旧源站需要维护、流量要迁移到新机房、进行蓝绿迁移或故障恢复，或者把内容交付切换到新版上游处理链路。在这些变更中，客户端使用的 URL 可以保持不变：同一个地址，需要开始返回预期的新版本内容。
假设现在就有这样一次变更。对于某个交付地址，我们需要从旧源站 O_A 切换到新源站 O_B，并开始返回新版本清单文件（manifest）M_B，而不是旧版本 M_A。
控制器生成配置 c1——也就是把上游切换到新源站 O_B 的配置——并发送给边缘节点。边缘节点应用配置后，返回执行报告：
applied(c1)=true
这份报告的含义是：对这个执行节点而言，要求的配置已经被接受并生效。
随后，探测客户端沿着同一条交付路径发起普通请求。HTTP 状态码是 200，但响应体仍然是旧版本 M_A。
边缘节点的报告完全可能是正确的：c1 的确已经应用。问题出现在下一步——系统把“配置已经应用”解释成了另一个结论：
客户端已经拿到了预期的新版本 M_B。
那么，真正完成的到底是哪一步？谁又有权宣布这次金丝雀验证步骤（canary step）已经成功？
下面沿着这条链路继续分析：从确定期望状态，到实际观测，再到允许执行的修正动作，以及修正后的再次验证。
这是一个有明确前提的工程场景，用来说明职责边界；它不是实际测试记录或事故日志，也不是某个具体 NGINX 部署的复盘。
1. 配置已经变了，缓存里的响应却没有变
我们已经知道两份点播（VOD）清单文件的内容：M_A 是旧版本，M_B 是变更后预期的新版本。两者的完整响应体不同。
重要的是，期望值 M_B 在验证之前就已由发布任务确定，而不是从缓存节点自己的报告里推导出来。
这次只检查一条隔离的金丝雀验证路径：一个边缘缓存节点 E、一个 URL U、一套普通请求配置 H，以及选定媒体输出版本（rendition）R0 所对应的清单文件。客户端观测点 P 位于边缘节点的缓存之后。
这里的金丝雀验证只表示一个受限的检查步骤，并不意味着已经允许把变更扩展到整个网络。
服务所有者要求返回 M_B，由新源站 O_B 替代旧源站 O_A。URL 和请求配置保持不变。
但缓存中已经存在旧版本 M_A。切换上游以后，旧响应仍可被查找到，响应选择规则没有变化，缓存依然可以把它返回给客户端。
边缘节点已经应用 c1（切换到新源站 O_B 的配置），但客户端仍然拿到 M_A——旧版本清单文件。
偏差正是在这里出现的。
这个请求配置对应的缓存键没有错误。这里没有再叠加语言变体混用、配置实际应用失败或其他故障，也不是上游根本没有切换成功。我们只讨论一个机制：
配置已经生效，但旧的可复用响应仍然能够被交付。
还要注意，相对于发布目标而言的“旧版本”，不一定已经在 HTTP 语义上过期（stale）。
RFC 9111 对已存储响应的复用规定了相应条件：目标 URI、请求方法、Vary 指定的请求字段以及其他适用约束都需要满足。满足这些条件时，仍处于 HTTP 新鲜期（fresh）的响应可以不经过重新验证而继续复用；但新鲜度不会覆盖 no-cache 等其他限制。[1, §§4–4.2]
为什么只检查“文件还在不在”不够
NGINX 官方文档给出的默认代理缓存键是：
proxy_cache_key $scheme$proxy_host$request_uri;
其中，$proxy_host 与 proxy_pass 所确定的被代理服务器名称和端口有关。
如果改变的是 $proxy_host 的值，而表达式其他部分不变，计算出的缓存键也会改变。旧文件即使仍在磁盘上，也不代表新的请求还能命中它。[2, proxy_cache_key; $proxy_host]
这并不意味着“任何后端切换都会改变 $proxy_host”。它说明的是：没有检查具体配置，就不能把本文的场景说成 NGINX 的“默认行为”。
本文需要的不是单纯的“旧文件还在”，而是：
旧响应仍然能够被当前查找规则选中并复用。
到这里，推理中缺少的依据就很清楚了。c1 已应用 回答的是配置执行问题；客户端拿到 M_B 回答的是实际交付问题。即使配置与当前任务的关联完全正确，第一个事实也不会自动变成第二个事实。
配置已生效，不等于交付正确。
Config applied ≠ delivery correct.
这只是控制契约的开始，不是结束。系统还需要取得决策依据，并确定下一步允许执行什么动作。
2. 三个平面，不是三个进程，而是三类责任
在这里，划分控制平面、数据与交付平面、验证平面，不是按“有几个服务”来分，而是看：谁负责回答什么问题。
| 平面 | 在本文场景中的责任 | 产出 |
|---|---|---|
| 控制平面（control plane） | 授权变更目标，将目标与配置、验证关联起来；根据依据单独授权修正动作，并决定是否通过金丝雀步骤的验收。 | 变更意图、期望状态和控制决策。 |
| 数据与交付平面（data / delivery plane） | 应用 c1，通过边缘节点和缓存处理普通客户端请求。 | 执行报告与实际 HTTP 响应；二者不是同一个结果。 |
| 验证平面（verification plane） | 获取指定路径上的响应，检查观测结果是否适用，并将响应体与期望值比较。 | 对这次交付的有限评估，不是修改基础设施的授权。 |
在控制平面内，服务所有者给出 I_g（已授权的变更意图），其中 g 是意图的版本。控制器据此形成 D_g（期望交付状态）：预期的 M_B、目标源站 O_B、检查范围，以及观测、动作和验收的条件。
c1 只是执行这个目标时使用的一个配置制品，不等于整个 D_g。
边缘节点返回的执行报告必须关联到具体的 c1、节点和任务版本。否则，即使看到“应用成功”，也不能确定报告属于当前变更。但即便关联正确，它仍然只是执行层面的报告。
验证时，控制器提供预期结果，并指定一个普通客户端请求。探测客户端（probe）不会只去问边缘节点“现在是不是正确”，而是沿着交付路径获取缓存之后的实际响应体。
随后，由评估责任方（assessment authority）这一逻辑角色，将适用的观测结果与预期结果比较。这里区分观测结果（observation）、评估（assessment）和决策（decision）：观测记录实际得到了什么，评估说明它支持什么结论，决策则确定下一步允许做什么。
评估结论返回控制器，但结论本身不授权缓存清理、回滚或扩大部署范围。动作授权和当前步骤的验收仍由控制器在自身权限内决定。
验证比较“看到的结果”和“应该得到的结果”；状态协调（reconciliation）则结合当前变更意图、执行状态与评估结论，确定下一步允许执行的动作。 评估返回控制器，动作执行后再次观测，反馈才形成闭环。
还记得 Kubernetes 吗？它的控制器模式（controller pattern）也有类似思路：先观测当前状态，再与期望状态比较，然后决定下一步动作。
这里只使用一个有限类比。Kubernetes 没有定义本文的三个 CDN 平面，没有替我们规定验收条件，也不能证明某个 CDN 项目已经实现了这套控制结构。[4, Controller pattern]
这些逻辑角色可以运行在同一个进程中。职责分开，也不意味着基础设施故障一定彼此独立。
本文要求的独立性更窄：期望值来自权威任务所确定的期望状态，实际响应体来自客户端交付路径；比较的两边不能都取自同一份节点自报信息。
但这里马上出现下一个问题：什么样的观测结果，才有资格代表我们真正要检查的交付状态？
边缘节点的 applied=true 已经被证明不足以回答这个问题。在比较实际结果与期望结果之前，必须先确定观测应满足哪些条件。
什么样的观测结果可以用于评估
S 是这次的检查对象：选定资源、请求配置、媒体输出版本，以及通过边缘节点 E 到客户端观测点 P 的路径。
要验证的属性 Q_delivery 很窄：指定的普通 GET 请求得到完整的 HTTP 200 响应，响应体与预先确定的 M_B 精确相等。
参考内容 M_B 与实际获得的响应体，必须以同一种预先约定的表示形式（representation）进行比较。 请求配置 H 固定必要的请求头和内容编码（content encoding）。
我们不使用 Range，不发送条件请求，也不对响应做额外转换。探测客户端发起普通 GET，将完整响应体与预先确定的 M_B 比较。
观测范围只覆盖这个指定请求、它的完整响应体，以及实际接收响应的时间区间。t_obs 表示这次观测完成的时刻。这里检查的是清单文件的交付，不是清单中所有媒体分片的获取或播放。
HTTP 200 也不能替代响应体比较。RFC 9110 分别规定了请求与响应的关联，以及消息的完整性。GET 返回 200 时，响应内容表示目标资源，但这个语义本身不会替我们完成与外部参考 M_B 的一致性检查。[3, §§6.1, 7.5, 15.3.1]
C_check 规定观测结果在什么条件下可以用于评估。 观测必须属于当前 g / D_g / S，响应完整，请求发生在相应配置应用或修正动作之后，且从 t_obs 计算的观测年龄处于允许范围内；还必须确认，没有变更使这份观测失去适用性。
时间戳很新，并不自动意味着依据充分。重复发送旧报告，也不会刷新原始观测时间。
这里涉及的时钟可相互比较。任务当前有效，且不存在会使观测失效的变更，这两点都已得到确认，而不是从系统没有报告变化推断出来。从获得支持正向评估的观测结果到作出决策，相关上下文保持不变。 本文不设定适用于所有系统的统一有效期。
请求是否确实经过目标边缘节点，也需要单独建立依据。相同的响应体或某个任意响应头，不能证明请求经过了指定路径。直接请求新源站 O_B，或只为探测客户端绕过缓存，检查的都是另一条路径。
对于满足 C_check 的观测，如果实际得到的是 M_A（旧版本）而不是 M_B（预期的新版本），就可以对这个响应给出 MISMATCH（不匹配）。
如果响应属于另一个任务、另一条路径，或者缺少必要的绑定信息，这份观测就不适用于当前检查。在没有其他充分依据的情况下，评估结果才是 UNKNOWN（未知），而不是 MISMATCH。
现在，我们有了比 applied=true 更具体的事实：客户端实际拿到 M_A，而预期的是 M_B。在上述适用条件下，这足以确认交付不匹配，却仍不足以自动修改 CDN。
接下来的问题是：谁有权根据这个 MISMATCH 授权动作？动作完成后，又需要什么新的依据，才能通过这一步的验收？
3. 从 MISMATCH 到允许执行的动作，再到新的结果
先区分三个环节。
客户端拿到 M_A，是一个观测事实。 确认这份观测适用于当前检查，再将响应体与预期 M_B 比较，才得到交付评估；在这里，评估结论是 MISMATCH。至于为什么返回旧版本，则需要单独诊断。
在本文场景中，另有诊断依据确认：旧缓存条目的复用正是这次不匹配的原因。比较说明交付是否符合预期，诊断支持修正动作的选择，二者不能互相替代。
将 a1（定向修正动作）定义为：
在边缘节点
E上，仅使旧的U/H缓存条目不再被复用；U/H对应前面选定的 URL 和请求配置。
这是对动作所需效果的描述，不是某个厂商 API 的名称。
允许执行 a1 之前，控制器需要确认当前 I_g 仍然有效，自己拥有修改这条记录的权限，所有者没有批准保留旧结果的例外，缓存复用这一原因已经建立，且动作影响范围明确。
同时，配置 c1 继续有效，目标源站仍是 O_B。这条隔离的金丝雀路径允许进行新的缓存填充（fill）。全局清理、修改 URL、单纯等待 TTL 到期，或只让探测客户端绕过缓存，都不是同一个 a1。
如果权限不存在、原因不确定，或影响范围不清楚，一个 MISMATCH 本身不能授权自动清理。验收关口保持未通过状态，问题交回所有者处理。停止交付、回滚或向全网扩散修正动作，也不能由这个评估自动推出。
不能藏在“清理缓存”背后的条件
在选定的执行序列中，不存在来自旧源站 O_A 的尚未完成的旧填充，能在 a1 之后重新让 M_A 进入可复用状态。
这是本次序列的条件，不是通用保证，更不是说缓存清理（purge）天生就能阻止所有并发的旧填充。
甚至“使缓存失效”（invalidate），也不一定意味着物理删除文件。RFC 9111 允许删除已存储响应，或要求下次复用前必须重新验证。但相关章节讨论的是修改资源的 HTTP 请求所引起的失效处理，没有规定本文管理动作 a1 的产品语义。[1, §4.4]
对于真实产品，仍需单独确认：哪个机制实现所需效果，适用哪些并发条件，对旧填充有什么具体保证。本文没有建立这样的通用产品保证。
后来看到一次正确的 M_B，也不能反过来证明旧填充永远不会恢复旧对象。 客户端实际得到了什么，与动作条件是否满足，是两个不同的依据问题。
在下面的正向序列中，a1 已经实现规定的效果。这是该场景中单独给定的事实，不是从任意执行确认消息推导出的结果。即使动作已经完成，仍需要一个新的普通客户端请求和新的评估。
清掉缓存就立刻宣布成功，就像重启服务后，仅仅因为命令执行成功，就直接把故障单关闭。
动作完成，不等于结果已经被验证。
到这里，三种责任已经分开：applied=true 不证明交付正确；MISMATCH 表明偏差，却不自行授权修正；修正完成后，还需要新的观测结果。
现在转向实际决策：系统到底要满足哪些条件，才能通过这个金丝雀步骤的验收？
什么条件允许通过金丝雀步骤的验收
C_canary（金丝雀步骤的验收规则）在验收之前确定。在本次序列中，它要求当前任务有效，配置 c1 确实完成应用，动作 a1 按规定完成，指定的修正后请求所产生的观测通过 C_check 并支持正向评估，以及控制器当前仍有通过该步骤验收的权限。
C_canary 的范围比完整实现 I_g（整个变更意图）更窄：它只验收这一个选定的交付检查步骤。
它不证明实际请求必定经过 O_B，不表示所有边缘节点或媒体分片都已验证，也不允许立即扩大部署范围。这是本文对有限场景设定的验收契约，不是 HTTP 或 Kubernetes 给出的通用规则。
现在展开所有九个步骤。任务版本、检查对象和预期 M_B 在序列中保持一致。下表描述的是有明确前提的场景，不是已执行网络实验的结果。
| 步骤 | 发生了什么 | 当前能够得出的结论 |
|---|---|---|
| T0 | 边缘节点 E 中已有旧版本 M_A。当前 I_g / D_g、C_check、C_canary 以及定向动作的权限已经确定。 | 预期是 M_B，但确定目标并不证明交付。 |
| T1 | 边缘节点确实应用 c1，上游切到 O_B；旧条目仍可复用。节点返回 applied(c1)=true。 | 配置确实应用，金丝雀步骤尚未通过验收。 |
| T2 | 普通请求 q_-（修正前的检查请求）按指定路径和请求配置取得 HTTP 200 与完整 M_A，形成观测结果 E_-。 | 通过 C_check 后，评估结论为 A_- = MISMATCH。 |
| T3 | 控制器检查当前任务和范围；单独的诊断确认缓存复用是原因。 | 验收尚未通过；不匹配本身不授权修正。 |
| T4 | 定向修正动作的条件全部满足。 | 控制器授权 a1；原来的负向评估不变。 |
| T5 | 边缘节点按规定完成 a1，并报告完成。c1 继续有效，目标源站仍为 O_B。 | 动作已完成，但尚无新的客户端响应依据。 |
| T6 | 新的普通请求 q_+（修正后的检查请求）走同一路径。在本次序列中，新的填充提供 M_B，客户端取得 HTTP 200 与完整响应体。 | 形成独立的观测结果 E_+，保留自身的请求和观测时间。 |
| T7 | 评估责任方按 C_check 检查 E_+ 的适用性，再与同一个 M_B 比较。 | A_+ = MATCH（匹配）；该评估可用于当前决策。 |
| T8 | 控制器再次检查意图版本 g 的当前有效性、验收权限和全部 C_canary 条件。 | 通过这一个金丝雀步骤的验收，依据包括执行情况和新的 E_+ / A_+。 |
正向结论不是从“清理完成，所以应该好了”推出来的。T6 中实际取得 M_B 是一个新的观测事实；E_+ 通过 C_check 检查，与同一参考 M_B 比较，才支持 A_+ = MATCH。控制器还要把这份评估与其他验收条件一起检查。
正确的结果声明需要保留这个范围，例如：
对当前
I_g，依据C_canary通过一个金丝雀步骤的验收：在c1已应用、a1已获授权并按规定完成后，新的普通请求q_+沿指定交付路径取得完整M_B。决策依据包括E_+ / A_+，并保留其实际范围和观测时间。
这不表示所有边缘请求都拿到了 M_B、所有媒体分片都已验证或整个 CDN 已验证，也不表示仅凭响应体一致就证明实际使用了 O_B。关于路由或源站身份的断言，需要单独的支持依据。
后续成功不会改写 E_-（修正前的观测结果）；此前的不匹配仍是历史事实。已经发生的验收也保留为历史决策。
但要继续用旧的正向观测支持“当前交付仍然正确”，它就必须继续满足 C_check。重复转发报告不会延长依据的有效期；反过来，有效期结束也不会追溯撤销过去的验收。
4. 两个可以直接检查控制闭环的方法
我们已经明确了金丝雀步骤的验收条件。接下来，把这些规则落到两项系统检查上。
第一项检查：系统有没有把“配置已应用”误当成“客户端已拿到正确内容”？
第二项检查：系统有没有把“修正动作已完成”误当成“修正结果已验证”？
检查一：从变更意图一直追到客户端响应
取当前 I_g / D_g（已授权的意图与期望状态）、真实应用的 c1，以及仍可复用的旧版本 M_A。
顺着链路检查参考 M_B 的来源、执行报告关联的配置制品与节点和任务版本，以及普通请求 q_- 的完整响应体从哪里取得、对应观测是否满足 C_check。
预期结果是：applied(c1)=true，但这个响应的评估是 MISMATCH，金丝雀步骤不通过验收。
不要只看内部记录，还要检查主要界面状态（UI）和 API 响应。“配置已应用”不能在另一个层面变成“M_B 已成功交付”。
再做负向替换：用直接请求源站、另一套请求配置或另一个任务版本取得的响应，替换当前观测。这份观测不能支持对当前检查对象 S 的 MISMATCH。在没有其他充分依据的情况下，评估结果应保持 UNKNOWN。
检查的重点不只是能否比较响应体，而是评估有没有绑定到正确的对象、范围和交付路径。
检查二：从授权动作一直追到新的验收依据
沿用同一序列，从 A_- = MISMATCH 开始。先检查诊断是否成立、动作权限当前是否有效，以及 a1 影响的缓存条目是否明确。
动作完成后，继续追踪新的普通请求 q_+、新的观测结果 E_+、新的评估 A_+，以及控制器单独作出的验收决策。
满足 C_canary 时，预期结果是：新响应得到 MATCH，随后才有单独的金丝雀验收决策。 API 和界面仍应保留对同一任务及决策依据的关联。
“缓存已清理完成”的执行报告不能替代 E_+。同样，“响应体已正确”也不能替代动作权限、任务当前有效性或验收权限的检查。
撤销执行 a1 的权限，系统就不应自动清理。用旧执行报告或绕过缓存的响应替代 E_+，也不应据此通过本次验收。这些是检查契约的方法，不是本文已经完成的运行时测试。
这两项检查给出了实际的职责划分标准：执行报告说明执行，客户端响应体支持对指定交付属性的评估，诊断支持原因判断，控制决策则授权下一步或通过验收。
如果平台把这些不同依据压缩成一个无条件的绿色“成功”，丢失的就不只是一个字段，而是控制语义。
标题里的“不是一组 NGINX”，不是否定 NGINX 作为执行组件。真正的问题是：平台在执行器周围定义了哪些控制责任。
软件定义 CDN 的变更闭环，不应停在“配置已下发”或“一次探测看起来正常”。在本文的有限场景中，系统需要把当前变更意图、执行、独立观测、范围明确的评估，以及单独获得授权的动作和决策连接起来。
这样，“配置已生效”才不会被错误地等同于“交付结果符合预期”。
参考资料
资料截点为 2026 年 10 月 1 日。本文沿用这些资料所支持的有限表述；产品文档不等于对某个具体二进制版本、配置或运行场景的验证。
[1] R. Fielding, M. Nottingham, J. Reschke. HTTP Caching. RFC 9111, STD 98, June 2022. §§4–4.2; §4.4.
[2] NGINX. ngx_http_proxy_module. proxy_cache_key; $proxy_host.
[3] R. Fielding, M. Nottingham, J. Reschke. HTTP Semantics. RFC 9110, STD 97, June 2022. §6.1; §7.5; §15.3.1.
[4] Kubernetes Documentation. Controllers. Controller pattern.
1456
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
