促销前一天，WAF 把结账请求拦了：安全服务商怎么接这单

判断时关注的线索

促销或上线时间已经确定，合法请求正在被拦截
客户能提供 WAF 规则编号、请求路径和事件日志
对方不想关闭整套防护，正在找可验证的小范围例外

促销开始前 18 个小时，群里出现一张红色拦截页面，后面跟着一句：

“正常客户在 Checkout 提交地址就被 WAF 拦，关掉托管规则就恢复。明晚活动，谁能帮忙把规则调好，但不能整套关掉？”

这是安全服务商销售应该马上看的消息。时间明确，业务路径明确，对方已经做过一次对照测试，还主动说不能关闭整套防护。它不是“想了解 WAF”，而是一件需要在变更窗口内解决的线上问题。

如果消息来自 Telegram 安全群，先把截图前后几条关于发生时间、浏览器和请求路径的讨论一起保存。孤立的一张拦截页，到了工程师手里往往还要重新问一遍。

不过，销售此时最不该说的是“把那个规则关了”。截图只能证明有请求被拦，不能证明是哪条规则、什么字段触发，也不能证明所有结账请求都受影响。

Telegram 群里的截图还缺哪些证据

Cloudflare 对误报的定义很直接：合法请求被识别并处置为恶意请求。它建议先在 Security Events（安全事件）中用时间和条件过滤，找出导致合法请求被拦的具体托管规则。

因此第一轮只需要客户导出或截图四项，不需要把管理权限交给陌生服务商：

事件发生时间和时区；
请求路径，例如 /checkout/address；
触发的规则编号与描述；
WAF 最终动作，是 Block、Challenge 还是其他处置。

如果能再提供一条脱敏请求样本，保留参数名称、HTTP 方法和 Content-Type，技术人员通常就能开始复现。手机号、地址、Cookie 和支付信息必须删掉。

Count 模式为什么比“先关了再说”稳

AWS WAF 的调优流程建议先监控流量和规则命中，再反复调整。测试规则可以使用 Count 动作：记录命中，但不拦截请求。日志里，Count 规则会出现在 nonTerminatingMatchingRules，真正执行 Allow 或 Block 的规则会记录为 terminatingRule。

这些字段听起来很技术，销售只要理解一件事：Count 模式能让团队观察“如果这条规则开启，会命中多少正常请求”，避免一改就影响全部流量。

群里可以追问：“现在有灰度环境吗？没有的话，能否只对这条规则、这个路径先改成 Count，观察 15 到 30 分钟？”

具体观察多久取决于流量，不能机械规定。但活动前至少要看到几次正常结账请求走完，而不是只刷新一次首页就宣布修复。

例外要小到能说清楚

Cloudflare 提供的处理方向包括给特定请求添加例外、调整 OWASP 托管规则，或只关闭造成问题的单条规则。文档特别提醒：关闭规则会降低防护能力；如果只有一条规则误报，不要关闭整个规则集。

AWS 也给出类似做法：可以在问题规则之前增加一个更具体的放行规则，或用逻辑条件把已知合法请求从检查范围中排除。

“结账全部放行”不是好例外。更合理的条件可能同时限制请求路径、HTTP 方法、参数特征和可信来源。例外越宽，攻击者越容易沿着被放开的路径绕过防护。

销售需要问：误报是否只发生在地址提交接口？只有 POST 请求吗？是某个 JSON 字段触发，还是所有请求都触发？回答越具体，项目越接近可执行。

什么情况值得立刻安排工程师

满足下面三项，优先级就很高：

客户能给出规则编号和至少一条脱敏日志；
有明确活动时间和可用的变更窗口；
客户同意先做单规则、单路径或 Count 模式测试，而不是要求关闭全部 WAF。

如果只有一张用户截图，没有事件日志，也没人能批准变更，销售可以先给排查清单，不必承诺当天修完。

改完以后，下一步谁来证明结账真的恢复

规则改成 Count 或加入例外后，不能只让一个员工刷新一次页面。至少准备两类样本：已知会被误拦的正常结账请求，以及原规则过去确实拦住的可疑请求。前者要完整走到下一步，后者仍应被其他条件拦截或留下明确告警。

验证时把时间、规则动作、订单是否创建和页面结果记在同一张表里。例如 21:10 的正常 POST 请求从 Block 变成 Count，订单系统成功进入待支付；21:13 的异常扫描仍被另一条规则 Block。这样活动开始后再出问题，团队能判断是 WAF、应用还是支付环节。

回滚条件也要在改动前写好。若例外上线后同一路径的异常请求突然增加，或结账接口出现新的 5xx 错误，谁有权在几分钟内撤回配置？Cloudflare 和 AWS 的具体操作界面不同，但销售都应确认变更人、观察人和回滚人不是一个联系不到的名字。

活动开始后的前 30 分钟还要有人看事件日志和真实订单。不是因为 30 分钟适合所有网站，而是高流量刚出现时最容易暴露未覆盖的参数组合。没有值班安排的“修好”，只是测试环境里暂时没再复现。

一条稳妥的群内回复是：

“可以先做紧急误报排查，不需要先给后台权限。请发事件时间、请求路径、规则编号、动作和一条脱敏请求样本。我们会先确认是否只命中单条托管规则，再决定用 Count 观察、路径级例外或规则调整；不建议关闭整个规则集。也请告诉我今晚哪个时段能做变更和回滚测试。”

安全群里每天都有“被拦了”的截图，但带规则编号、业务路径和活动时间的消息少得多。TOP Prospect 可以帮助销售及时看到这种组合；真正专业的第一步，是把例外缩小到可以复现、可以回滚。