Webhook误拦应从服务商投递记录和WAF事件对照，针对确认的路径、方法和误触参数处理。放行请求不等于验证发送者，接口仍需签名、时间或幂等检查，不能用整站白名单替代业务认证。
关联同一次请求的证据
保存事件时间、目标路径、HTTP方法、返回码与服务商任务标识，在WAF记录中找到对应项。正文和认证头可能包含订单或密钥，分享时只保留必要摘要。别把浏览器手动打开回调地址的结果当作服务商POST投递结果。
确认是误报而非无效请求
检查签名校验、内容类型及必需参数，确认业务端期望接收的请求结构。WAF拦截与应用拒绝可以先后发生，不能只看到403就认定某条规则错误。对不符合服务商规则的请求，应保留应用拒绝而非全部放行。
将例外限制到具体条件
按当前WAF能力设置最小路径、方法及参数范围，确有可靠来源限制时再配合使用。不要仅依赖自报User-Agent或任意来源头。更不能为一个回调放宽整个wp-json或所有管理接口的防护。
复测投递和业务幂等
在服务商授权测试模式重发可控事件，核对WAF通过、应用认证和最终业务状态。重复回调不应重复扣款、记账或发送通知。确认正常与无效请求表现不同，再记录例外的理由、负责人和移除条件。
关键区别
WAF通过：允许进入应用；不代表身份可信。
签名检查：核实事件真实性；不能因放行取消。
重复回调：同一事件重投；业务应避免重复。
怎样确认处理到位
真实测试事件完成一次预期处理，无效签名仍被拒绝，例外仅覆盖确认范围，投递记录与业务结果能够对应。
容易误判的边界
临时关闭整个WAF，不能证明最终的例外规则正确。应分别核对回调投递、应用认证和业务结果。
