同一个可疑请求，可能被应用拒绝，也可能真的拿到了敏感数据。只看请求特征，往往分不清这两种结果。
Cloudflare 在 2026 年 10 月 21 日发布完整事务检测与响应规则，将同一次 HTTP 请求和源站响应关联分析。相关能力已面向包括 Free 在内的所有套餐正式可用。它增加了判断利用是否成功的线索，也能在规则命中时阻止源站响应返回给请求者。但有一条边界必须先说清：响应被拦住，不代表源站没有执行过操作。
请求特征说明意图，响应补充结果
传统请求阶段的 WAF 可以根据路径、参数、请求头和请求体等信息识别攻击特征，在流量到达源站之前阻止它。对于已知且容易识别的攻击，这仍然是重要的防线。
难点在于有些输入存在歧义。过宽的请求特征容易误伤正常业务，过于保守又可能放过真正的攻击。即使识别出一次探测，也不能仅凭输入确认它造成了影响。
完整事务检测把源站返回的信息纳入判断。以公告中的文件下载场景为例，可疑的文件访问参数之后，若紧接着返回了具有私有配置文件特征的内容，二者结合能提供更强的数据暴露证据。单独的配置示例文本可能只是正常文档，单独的异常参数也可能已经被应用安全拒绝。
这不是说某个 HTTP 状态码就能证明攻击成功。200 可能对应业务错误页，异常状态也不保证响应里没有敏感内容。有效判断来自同一事务中多个信号的关联，而不是把状态码直接当成安全结论。
官方首批托管检测用于近期披露的 php2shell 漏洞，并表示会继续扩展其他数据暴露与外传场景。这里应区分已上线能力和后续覆盖计划，不能把发布公告理解为已经覆盖所有漏洞及所有泄露形式。
检测结果和处置动作分开
Cloudflare 的设计将检测与缓解分开。检测负责分析并附加元数据，规则再决定记录还是阻止。
| 环节 | 可以提供什么 | 不能据此推断什么 |
|---|---|---|
| 请求阶段检查 | 识别输入特征，提前阻止部分请求 | 每次命中都已造成真实损害 |
| 完整事务检测 | 关联输入与源站输出，增加利用结果的证据 | 没有命中就一定不存在漏洞 |
| 响应阶段规则 | 阻止匹配的源站响应交付给请求者 | 已回滚源站执行或消除了漏洞 |
公告新增了 cf.waf.signature.response.confidence、cf.waf.signature.response.categories 和 cf.waf.signature.response.ref 等检测字段，分别表示匹配签名的置信信息、分类和引用标识。付费客户可以把检测结果与路径、主机名等应用条件组合，制定更细的响应策略；这些字段仍在逐步开放到账号，具体可见性应以实际账号为准。
这种分离也给上线验证留出空间。团队可以先理解自己的流量中哪些接口、哪些签名产生事件，再决定适用范围。把一条检测结果直接翻译成全站阻止规则，仍然需要承担业务误伤风险。
“面向所有套餐”不等于没有功能差别
官方说明，所有客户都可以使用托管响应保护，也可以创建最多三条支持 Log 和 Block 动作的自定义响应规则。规则可以组合请求字段和响应字段，可使用的字段及函数受套餐已有权限影响。
托管入口名为 Cloudflare Managed Response Firewall Default。php2shell 保护公告称，该托管响应规则集已自动部署到所有套餐客户，并建议到控制台核对是否生效。不能只凭这段公告，就假定自己的所有域名和所有流量路径都已受到检查；完整事务检测的适用前提是流量由 Cloudflare 代理。
Free 用户可以获得托管保护，但这与付费客户在自定义响应规则中直接使用检测字段不是同一项权限。官方还说明，未来免费套餐的托管检测会侧重高影响漏洞，付费套餐会有更丰富的检测目录。
另一个容易误读的地方是响应正文。平台的托管检测可以利用响应内容信号，但公告明确指出，用户目前还不能直接针对响应正文创建自定义规则。因此，这次发布不能被描述成向所有用户开放了一套任意正文匹配引擎。
响应被替换，源站副作用不会消失
规则命中时，Cloudflare 可以用 WAF 阻止页或自定义响应替换源站响应；公告中的示例返回 HTTP 403。这个动作发生在向请求者交付响应的阶段。
如果攻击的目标是通过该响应拿走敏感内容，阻断交付有直接价值。但如果源站已经执行命令、修改数据或完成权限变更，替换响应无法撤销这些动作。即便攻击者没有拿到页面，事故排查也不能就此结束。
所以，响应阶段保护适合作为补充防线，不能替代应用鉴权、输入处理和漏洞修复。Cloudflare 在 php2shell 保护公告中也要求客户更新 PHP，而不是把 WAF 当成永久不打补丁的理由。
同理，应用正常的异步操作、对外请求和其他副作用，需要应用自身的授权与隔离机制约束。不要让“浏览器收到阻止页”成为判断源站是否安全的唯一依据。
自定义规则里的身份信号必须可信
公告举了一个组合路径、内部用户标记和响应属性的管理页面防护例子。这种规则的价值，是在源站意外返回成功的管理页面时再加一道检查。
不过，响应是 HTML、状态是成功、路径以管理目录开头，都只是业务线索，不足以构成可靠鉴权。若规则依赖某个“内部用户”请求头，团队必须确认它由可信网关设置，并且外部同名输入会被清理或覆盖。不能让用户可以自行填写的请求头决定自己是否属于内部用户。
这部分是部署时的信任边界检查，不是新增功能会自动完成的事情。可以先在测试环境使用不含敏感数据的模拟页面，分别验证正常登录、拒绝访问、跳转及异常成功响应，确认规则没有把正常路径一起拦掉。本文没有对任何生产应用执行漏洞测试。
事件能帮助定位，但日志也要控制范围
托管或自定义响应规则产生记录或阻止动作时，事件可在 Security Events 中查看。当前请求阶段与完整事务规则仍显示在同一个分析页面，响应事件归在 Managed Rules 或 Custom Rules 服务中，可以按具体规则 ID 筛选。
这对排查提出了一个实际要求：看到阻止事件时，要分清动作发生在请求到达源站之前，还是源站已经处理之后。两类事件对事故影响的含义不同。关联源站日志时，应核对时间、请求标识、路径和实际处理结果，而不只统计阻止次数。
调查敏感响应也不意味着要把完整正文复制到工单或聊天里。尽量使用规则 ID、必要元数据和脱敏片段；确需留存证据时，明确权限与保留期限，避免防护排查又制造一份新的敏感数据副本。
落地时可以从一小部分接口开始核对：流量是否经过代理、托管规则是否启用、现有排除范围是什么，以及自定义规则是否支持需要的字段。再结合正常业务样本评估误伤，逐步调整策略。公告没有给出可直接套用到所有应用的误报率或延迟数据，团队仍需在自己的流量上验证。
结语
完整事务检测补充了请求检查看不到的一部分结果信息，响应规则则提供了在交付阶段继续阻止风险内容的机会。这让“出现攻击特征”与“出现影响证据”更容易分开讨论。
但这道防线有明确时序。被阻止的是响应交付，源站可能已经处理了请求。把它与请求阶段防护、应用修复和源站日志一起使用，才不会因为看到一张阻止页，就过早结束调查。
参考来源
- Cloudflare：Introducing full transaction detection for Cloudflare WAF，发布于 UTC 2026 年 10 月 21 日 14:10，北京时间 10 月 21 日 22:10。用于核对正式可用范围、检测字段、自定义规则数量、动作和正文限制。
- Cloudflare：Cloudflare deploys protections against php2shell vulnerability，发布于 UTC 2026 年 10 月 21 日 13:56。用于交叉核对首批托管响应保护、部署说明及仍需更新 PHP 的建议。本文聚焦防护机制，不提供漏洞利用步骤。
资料核对日期为 2026 年 10 月 23 日；功能权限、检测目录和控制台入口可能随产品更新调整。