当异常请求被WAF放行，第一时间要做的是切断当前攻击路径，而不是急着调全局规则。先封IP、封Session、封UA特征，把损失止住，再回头分析日志，找到放行的根因,最后针对性收紧策略。
发现异常请求放行后的第一反应
先确认这到底是不是误判
告警弹出来的时候，别急着改配置，去年某电商平台大促期间，WAF突然放行了一堆带/admin路径的请求，运维同事直接封了整个IP段，结果把自家CDN节点全堵了，线上事故持续了四十分钟，判断是不是真异常,就看三个特征：
- 请求频率是否远超该IP的历史基线
- UA、Referer、Cookie组合是否违反常规浏览逻辑
- 请求路径是否命中了后台、API、上传接口等敏感区域
如果三个条件里中了两个以上，基本可以认定是异常，只中一个，尤其是高频请求，先别动手，大概率是爬虫在扫目录,不是真正的攻击。
第一道操作：手动封禁
WAF自动放行了，说明智能检测引擎已经信任了这条请求，这时候再去调规则来不及,直接走手动通道：
- 登录WAF控制台，进入【IP黑白名单】面板
- 把异常IP复制进去，选择“永久封禁”或“24小时封禁”选项
- 如果攻击源分布比较广，在【自定义规则】里加一条：匹配
异常路径 + 非浏览器UA的请求，直接返回403
手动封禁的好处是即时生效，不需要等规则推送，也不依赖WAF的学习能力，多数WAF厂商的控制台操作路径都在1-2分钟内能完成这个动作,值得在平时就演练一遍。
封禁IP与封禁Session的区别
- 封IP：适合扫描器、爆破工具、代理池攻击，但这些攻击源IP变动快，单靠封IP不够
- 封Session：适合已登录用户的异常行为，比如越权访问、频繁提交订单而不付款
- 封UA：适合批量脚本攻击，但对方换一个UA参数就能绕过，只能作为辅助手段
行业共识认为，组合封禁比单独封任意一个维度都更有效，用IP做粗筛，用UA和Cookie做精确打击,能拦截九成以上的误放行请求。
找出WAF放行的真实原因
智能检测为什么会漏
现在的WAF产品普遍宣传“AI智能检测”，实际上大部分走的是规则引擎加机器学习双轨制，异常请求被放行,无非以下几种原因：
- 规则库里根本没有对应的攻击特征，比如新出现的0day利用方式
- 请求经过了编码、分块传输等变形处理，规则引擎没还原出原始载荷
- 源站IP在WAF的白名单或信任列表里，全部检测被跳过
- WAF的检测阈值配置过高，低频慢速攻击触发不了告警
日志回查的三个步骤
处理完当前紧急情况后，业务回到正常状态，就该去翻日志了,操作路径如下：
- 进入WAF的【防护日志】模块，筛选“放行”和“通过”状态的记录
- 按SourceIP维度聚合，找出请求量TOP20的IP列表
- 逐个点击查看详情，重点关注请求Path、Body中的Payload、响应码三个字段
看完这三步，基本就能确定放行的原因，如果发现放行的请求Payload里有SQL语句或JavaScript代码，那就说明规则粒度太粗,或者请求经过了base64编码。
基线偏移是最大的信号
单个异常请求不致命，致命的是请求模式发生了偏移，比如平时这个接口每秒5次请求，今天突然涨到每秒50次，且响应成功率从99%掉到80%，即使单个请求看起来都合法,整个趋势也是异常的。
业内专家指出，WAF的智能学习模块需要大约7天的数据建立基线，如果刚接入WAF不到一周就出现异常放行，多半是基线还没学完，此时建议手动调低全局检测阈值,等运行稳定后再恢复默认值。
快速调整策略的实操路径
核心原则：先阻断，后分析，再恢复
调整WAF策略，别一上来就改全局配置,正确的操作顺序：
- 先手动封禁可疑IP和UA特征，确保攻击无法继续
- 打开WAF的“观察模式”，让规则先记录不拦截，看看拦截率是否达标
- 根据观察数据，把检测阈值下调10%-20%
- 规则运行24小时无异常后，再逐步恢复默认配置
加高防护等级时注意“误伤”边界
部分WAF产品提供“宽松”、“标准”、“严格”三档防护等级，异常放行频发时，直接切到“严格”确实能拦住更多攻击,但代价是正常用户也可能被误杀。
比如某网站后台收到大量带的路径穿越尝试，把防护等级调到“严格”后，请求路径里只要带或%2e都会被拦，这确实挡住了攻击，但用户上传的文件名里带的话,也会一并被拦截。
实际操作建议：只对触发攻击的子目录或接口单独开严格模式,不在全站开启。
解码开关与编码容错
WAF放行编码类攻击是个高频场景，URL编码、Unicode编码、双重编码，这些是绕过WAF的常用手段,处理方式如下：
- 在WAF的【规则配置】里，找到“请求体解析”选项，打开
URL解码和Base64解码开关 - 在【高级防护】模块，增加一条“解码后匹配”规则，让WAF先解码再校验攻击特征
- 如果业务本身不用Base64传参，直接禁用Base64请求体，减少暴露面
人机验证的降级使用
有些请求明显不是人类行为，但WAF的自动拦截放过了，原因在于WAF判断为“低风险爬虫”，只做了人机验证,而攻击者通过了验证码。
调整策略时，可以把验证码的触发阈值往下调，或者对特定路径直接开启“强制验证”，页面操作路径一般是：【防护配置】→【人机验证】→【路径规则】→ 添加验证路径，不需要验证码业务的前端排查这一步也能做，但多数情况下，验证码降低到二选一的选择题级别,就能挡掉大部分脚本。
临时策略与永久策略分开管控
快速调整时，顺手创建的临时规则，事后一定要记得清理或归档，建议在WAF平台里单独建一个“紧急策略”分组，用来放短期封禁规则，设置48小时自动过期，避免策略越积越多,最后自己都搞不清楚哪条规则在生效。
调整后的验证与效果评估
封禁数据怎么看
规则调整后，48小时内需要回看数据来判断是否生效,核心指标有以下几项：
- 拦截请求占总请求量的比例是否提升
- 源站负载是否回落
- 告警数量是否减少
- 正常业务是否有波动
如果拦截率上去了，但站点的正常转化率也跌了，说明策略太激进,需要放宽。
误封检测方法
验证是否误伤正常用户，方法很简单：开启WAF的“测试模式”或“模拟拦截”，在规则做真实拦截前，先模拟计算，或者在日志里随机抽样一批封禁请求，看请求的Session是否产生了后续的浏览行为，没有后续行为的，大概率是攻击或爬虫,可以放心加严。
策略联动和兜底方案
大型业务站点，只靠WAF不够,建议做三层联动：
- 第一层：WAF做应用层检测和拦截
- 第二层：云高防IP或CDN做流量清洗，过滤掉四层DDoS
- 第三层：源站安全组仅允许WAF或高防的回源IP访问
三层都配好后，WAF策略再怎么调错，源站也有一层兜底,不至于被打穿。
WAF放行异常请求不可怕，可怕的是没有应对流程，团队内部可以把这个处理流程固化成SOP，标注出每步操作的存在位置和入口路径,方便新人也能快速上手。
常见问答：WAF异常请求放行怎么办
Q1：WAF放行了一个明显是SQL注入的请求，是不是说明WAF产品不行？
不是，任何WAF都无法保证100%拦截所有攻击，尤其是经过编码混淆的新攻击变种，放行后及时封禁、调整策略、同步规则，就能把风险控制在最小范围,真正的能力差距体现在应急响应速度和规则优化效率上。
Q2：临时加严规则后，正常用户访问量明显下滑，怎么迅速恢复？
先关闭影响面最大的那条规则，比如全站严格模式，改回标准模式，然后在【规则测试】中逐个验证剩余规则，看哪些产生了误拦截，最后把触发误拦截的规则加到白名单，仅排除特定路径,整个操作最好在30分钟内完成。
Q3：WAF策略调整到什么程度才算到位？
无论规则如何调优，都要以“业务可用性不降级”为前提，拦截率提升的同时，源站响应时间保持稳定、页面访问成功率不低于99%，才算调整到位，建议每月做一次规则有效性复盘，删除失灵的旧规则,同步最新的攻击特征库。