CDN 下如何验证升级暂存目录已阻断

源站加了拒绝规则，并不等于公网上就打不开。在带 CDN 的站点上，wp-content/upgrade/ 是否可达，由边缘缓存、边缘规则和回源策略共同决定；任何一段放行，源站那一层的 403 就失去作用。而升级窗口只有几分钟，验证必须在升级之前完成，事后补做只能算排查，不能算防护。考虑到该漏洞已被列入已知被利用漏洞目录，这项验证值得按“需要证据的验收”来做，而不只是改一次配置。

验证入口要选公网域名

常见的错判是直接在服务器上请求本地地址，看到拒绝响应就认为完成。这只证明源站规则存在，证明不了边缘节点没有把旧的可达响应留在缓存里。正确的验证对象是站点的公网域名，走与外部请求完全相同的路径，最好再换一到两个网络出口重复一次，排除单节点或本地 DNS 带来的偶然结果。

把缓存和路径变体分开测

缓存是 CDN 场景下最主要的误判来源。如果该路径在配置规则之前被边缘缓存过，源站新加的拒绝不会立刻改写边缘已经持有的响应。验证时用带一次性查询串的请求绕开缓存，观察真实回源结果；再用不带参数的干净请求，确认边缘对其同样返回拒绝，而不是旧内容，也不是被重写规则兜底后的首页。两者都拒绝，才说明规则和缓存两侧都到位。

路径覆盖同样要逐个测，不能只测暂存目录本身：

• 目录带结尾斜杠与不带斜杠的两种形式
• 大小写不同的等价写法
• 经过编码的等价形式
• 暂存目录下的具体安装器入口文件，如 setup-config.php

这一类变体是前缀规则最容易漏掉的地方。全部返回拒绝，才算覆盖完整。

还有生效时间的问题。CDN 的规则下发与缓存失效都需要时间，改完立刻测很可能测到旧状态。比较稳妥的安排是把阻断配置提前到升级窗口之前，留出间隔再验证，通过后才执行核心更新。这一步不能省，因为从未修复版本升级到修复版本时，执行解包的仍是旧升级器代码，窗口在更新开始那一刻就已经打开。

验证通过后还有两件事。一是确认升级流程本身不依赖该路径的 HTTP 访问，升级器走的是 PHP 文件系统操作，阻断通常不会影响更新；二是在升级窗口内保留边缘与源站日志，事后检索该路径的访问记录。只有拒绝响应是规则生效的证明，出现一次成功响应则是需要取证的信号，两者性质完全不同，不能混在一起看。