RockCloud-基石云安全-官方博客
先给结论：支付回调被 WAF 拦下来，正确的做法不是把域名整体加白，也不是关掉 WAF，而是三步——在拦截日志里找到具体是哪个模块、哪条规则拦的；只对回调接口这一个路径、只对支付平台的官方 IP 段、只跳过命中的那个模块配置放行；然后在支付平台后台重发一次通知，看日志确认放行生效。整个过程通常十几分钟能做完，下面按这个顺序展开。
先确认是不是 WAF 拦的
典型症状是：用户已经付款成功，但系统里订单状态没更新；微信支付商户平台或支付宝后台显示“通知失败”“商户返回非 200”，重试若干次仍失败；而你的应用日志里根本没有收到这条回调请求。请求没到应用层却在边界消失，边界上又刚接了 WAF，那基本可以把方向定在 WAF 上。
再看支付平台记录的响应码能进一步缩小范围：返回 403 常见于规则拦截或 IP、地域封禁；返回 405 或一个带 JavaScript 的 HTML 页面，多半是 Bot 防护在向回调方下发浏览器挑战——支付机构的服务器不是浏览器，跑不了 JS，自然过不去。
第一步：查日志，拿到模块和规则ID
进入 WAF 控制台的安全事件、攻击日志或拦截报表，用三个条件过滤：回调失败的时间段、回调接口的 URL（例如 /api/pay/notify）、以及支付平台的来源 IP。你需要记下三样东西：
- 动作是拦截（Block）还是挑战（Challenge）；
- 命中的防护模块是哪一个：Web 基础防护（SQL 注入、XSS、WebShell 这类规则）、Bot 管理/JS 挑战、CC 防护/频率限制，还是地域封禁；
- 具体的规则 ID。
这一步不能省。支付回调被拦的原因就那么几类，但对应的处理方式不同，不看日志只能靠猜，猜错了要么放不开，要么放得太宽。
四类常见原因和对应模块：
- 回调请求体是 XML 或 JSON，里面带签名密文、Base64 串、转义字符，被基础防护规则误判为注入或 WebShell 特征。
- 开了 Bot 防护或浏览器完整性校验，回调方无法完成 JS 挑战。
- 大促、批量退款时回调在短时间内并发很高，触发了 CC 频控。
- 跨境支付网关从境外 IP 发起回调，撞上地域封禁策略。
第二步：按最小范围配置白名单
白名单要遵守两条原则：条件之间是“且”的关系，放行动作只针对命中的模块。整站加白或者只填一个域名不加任何限定，等于给攻击者留了一条绕过 WAF 的通道，这是绝对要避免的。
匹配条件建议同时满足这三项：
- 请求方法 = POST（支付回调几乎都是 POST）；
- URL 路径精确匹配或前缀匹配回调接口，如
/api/pay/notify/*，不要写成/api/*； - 客户端 IP 属于支付平台公布的回调 IP 段。微信支付在官方接入文档里明确要求商户在防火墙和 WAF 上放开其公布的回调网段，支付宝等其他渠道以各自官方文档公布的 IP 为准。
如果某个渠道不提供固定 IP 或 IP 会动态变化，就把 IP 条件换成双方约定的特定请求头（Header）作为标识，比如渠道固定带的某个头字段和值，同样和方法、路径组合使用。
放行动作按模块对号入座：
- 基础防护规则误报：优先选“对该路径跳过指定规则 ID”，只有多条规则轮流误报时才退一步选“跳过 Web 基础防护”这一整个模块；
- Bot 挑战拦截：对回调路径跳过 Bot 管理/JS 挑战/浏览器校验；
- CC 频控拦截：对回调路径跳过频率限制或 CC 防护，或者单独给这个路径设一个更高的阈值；
- 地域封禁：把支付网关所在地区的 IP 段列为例外，而不是解除整个地域策略。
不同厂商控制台的叫法不一样：有的叫“白名单模板”“误报屏蔽”，Cloudflare 一类叫 Skip 规则，还有的分成“Web 入侵防护白名单”“Bot 白名单”多个入口。名字不重要，看它跳过的到底是整条链路还是某一个模块——只跳过你在日志里看到的那个。
如果你的站点是通过 RockCloud 这类加速与防护在同一链路上的服务接入的，WAF 的规则、拦截日志和 CDN 是同一个面板，路径、IP 和模块条件在一处配置即可，具体规则项可以参考 RockCloud WAF 页面的说明，拿不准时让技术支持一起看日志比自己反复试更快。
第三步：重发通知验证，再补回业务层验签
规则保存后，不要等下一笔真实订单。到支付平台商户后台找到失败的那条通知手动重发，或者用测试订单再走一遍支付流程，然后回到 WAF 日志确认这次请求的动作已经变成“放行”，应用日志里也收到了回调。如果还是被拦，回到第一步看新的日志——有时一条规则放开后会暴露出后面另一条规则，逐条处理即可。
最后一点非常重要：白名单只是让请求能进来，不代表进来的请求可信。放开 IP 段之后，你的回调处理逻辑仍然必须对每一条通知做签名验证，验签失败一律不更新订单。微信支付的接入规范把这一点写得很明确，原因就是 IP 可以被伪造，白名单本身就是一个敞口，验签是最后一道防线。跳过 WAF 检测的路径，等于把这部分安全责任交回给了应用代码。
来不及查日志时的临时处理
如果订单积压严重，一时半会儿找不到具体规则，可以先做一个临时规则：仅针对回调路径、仅针对支付平台 IP 段，跳过命中的那个模块（不确定的话跳过 Web 基础防护和 Bot 挑战两项），先把订单通道恢复。等流量稳定后再回日志里定位具体规则 ID，把临时规则收窄到规则级别。临时规则记得加备注和处理时限，避免半年后没人知道它为什么存在、还该不该留。
上线新的支付渠道或者 WAF 升级规则库之后，回调路径值得列入例行检查项：用测试订单跑一遍，看一次拦截日志，比等客户投诉“付了钱没到账”要省事得多。
评论(0)