靠规则引擎、行为基线、速率限制与人机验证四层机制叠加，先观察业务基线再灰度上线，才能在不误杀正常用户的前提下拦住异常流量。 下面从异常请求的伪装方式讲起，拆解配置和调优的具体路径，并回答预算、误杀、地域部署等实际问题。
异常请求不只靠IP黑名单：先看清对手的伪装
高频请求、扫描器和伪造UA是三大来源
异常请求并不总是“看起来就很坏”，多数情况下，它们混在正常流量里,表现为：
- 高频访问：短时间内对登录页、搜索接口、验证码接口发起大量请求,试图撞库或消耗资源。
- 路径扫描：反复请求
/admin、/.env、/phpmyadmin等敏感路径,寻找未关闭的入口。 - 参数污染：在URL或表单里塞入超长参数、特殊字符、SQL片段,试探后端过滤能力。
- 伪造身份：User-Agent为空或伪装成常见浏览器，Referer随意拼接,Cookie结构异常。
- 代理池轮换：同一攻击源不断更换出口IP,让传统黑名单很快失效。
传统IP封禁为什么容易失效
很多站长第一反应是“封IP”，但秒拨IP、代理池和云函数调度让攻击者可以低成本换地址，今天封掉一个C段，明天流量从另一个地域进来，行业共识认为，单纯依赖IP黑名单的防护方式，在面对分布式异常请求时拦截效率会明显下降，所以网页防火墙要把判断维度从“地址是谁”扩展到“请求像不像正常用户”。
网页防火墙过滤异常请求的四层核心机制
规则引擎：用特征匹配拦住已知恶意请求
规则引擎是WAF最基础的一层，它把请求拆成URI、请求方法、Header、Body、参数等字段,再用预置规则和自定义规则匹配。
- 预置规则覆盖常见Web攻击特征，例如SQL注入、XSS、路径穿越、命令注入。
- 自定义规则适合业务侧的特殊拦截，URI包含
/api/v1/login且请求方法为POST且Body长度超过2KB”时触发人机验证。 - 规则动作一般分为放行、观察、挑战、拦截，新规则先选观察，看日志确认误报率,再逐步收紧。
在Nginx配合ModSecurity的场景里,一条基础规则可以这样写：
SecRule REQUEST_URI "@contains /admin" \ "id:1001,phase:1,deny,status:403,log,msg:'block admin scan'"
这条规则的动作很直接：请求URI里出现 /admin 就返回403，实际业务中不建议一上来就deny，先改成 pass,log 观察一段时间更稳妥。
行为基线：识别偏离正常模式的访问
行为基线解决的是“请求字段都合法，但行为不像人”的问题,网页防火墙会记录一段时间内的访问序列，
- 同一会话在10秒内连续访问登录页、下单页、支付页,跳过了正常浏览路径。
- 同一IP对同一接口的请求间隔高度均匀,像脚本定时器。
- 同一User-Agent在短时间内出现在大量不同IP上。
- 会话Cookie刚生成就立刻发起高频请求,没有正常页面加载和静态资源请求。
这些特征单独看未必异常，叠加起来就很容易区分人和机器，配置时可以先按业务高峰期的正常访问序列做基线，再设置偏离阈值，阈值不要拍脑袋,拉一周日志算一下P95请求间隔更靠谱。
速率限制：把突发流量控制在业务承受范围内
速率限制是成本最低、见效最快的一层，它不追求识别每个请求的恶意特征，只控制单位时间内的请求数量,常见做法：
- 按IP限速：单IP每秒请求数超过阈值后排队或拒绝。
- 按接口限速：登录、短信、支付回调等敏感接口单独设更低的阈值。
- 按会话限速：同一Cookie或Token的并发请求数设上限。
- 按地域限速：对异常请求集中来源地域临时收紧阈值。
Nginx的限速配置示例：
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/s;
location /api/login {
limit_req zone=login_limit burst=10 nodelay;
}
这段配置表示单IP对登录接口的请求速率限制为每秒5个，允许10个突发请求，阈值要结合业务实际调整,别把正常用户的连续点击也拦掉。
人机验证：对可疑会话加一道挑战
当规则引擎和行为基线给出“可疑”判断后，不一定立刻拦截，可以返回人机验证,常见形式包括：
- JS挑战：浏览器执行一段JS后拿到通行凭证,脚本请求往往无法完成。
- 无感验证：采集鼠标轨迹、页面停留时间等特征,正常用户几乎无感知。
- 验证码：对高风险会话弹出图形或行为验证码。
人机验证适合放在登录、注册、评论、领券等接口前面，它的好处是降低误杀：真实用户完成挑战后继续访问,攻击脚本则被挡在门外。
WAF怎么拦截异常请求：从配置到调优的实操路径
第一步：梳理业务请求基线
别急着开拦截，先拉最近7天到30天的访问日志,重点看：
- 各接口的QPS峰值和平均值。
- 正常用户的请求间隔分布。
- 登录、支付、搜索等敏感接口的调用来源。
- 静态资源和动态接口的请求比例。
把这些数据整理成一张表,后面设阈值时才有依据。
第二步：启用预置规则集并观察误报
在WAF控制台进入“防护配置”→“Web攻击防护”，先启用预置规则集，模式选“观察”,观察期间重点看：
- 哪些正常业务请求被规则命中。
- 命中规则集中在哪些URI和参数。
- 误报请求的共同特征，例如JSON Body里包含特殊字符但业务本身允许。
观察3到7天后，把确认无害的规则加入白名单,再切换为拦截模式。
第三步：自定义规则精准拦截异常请求
预置规则覆盖通用攻击，业务侧的特殊异常要靠自定义规则，操作路径通常是“防护配置”→“自定义规则”→“新建规则”,配置时注意：
- 匹配条件尽量具体，URI等于
/api/sms/send且请求方法为POST且Referer为空”。 - 动作优先选“人机验证”而不是直接“拦截”,给正常用户留通道。
- 规则命名带业务前缀，
login_rate_limit,方便后续排查。 - 每条规则单独观察，不要一次上线十几条,否则误杀时很难定位。
第四步：灰度上线与误杀回滚
规则上线按灰度节奏走：
- 先对10%流量生效,观察24小时。
- 误杀率可接受后扩大到50%。
- 全量前确认回滚路径：一键关闭规则、切换观察模式、把误杀URI加入白名单。
同时保留“误杀申诉”入口或日志标记,方便运营侧反馈。
网站防火墙过滤异常请求价格与云WAF、硬件WAF对比
云WAF按量付费更适合中小站点
云WAF通常按请求量、带宽或防护域名数计费，开通快、无需改动机房架构，对于访问量波动大的站点，按量付费可以避免闲置成本，多数情况下，基础防护套餐每月几十到几百元,高防或定制规则场景会更高。
硬件WAF与私有化部署的成本结构
硬件WAF或私有化部署适合对数据不出机房、低延迟有硬性要求的场景，成本不只是设备采购，还包括部署实施、规则维护、带宽扩容和运维人力，预算有限的团队要算总拥有成本,不能只看设备报价。
| 对比项 | 云WAF | 硬件WAF/私有化 |
|---|---|---|
| 部署方式 | 接入DNS或CNAME，开通快 | 机房部署，实施周期较长 |
| 计费方式 | 按量或套餐，弹性扩容 | 设备采购加运维，前期投入高 |
| 适用场景 | 中小站点、业务波动大、缺少专职安全运维 | 数据合规要求高、流量稳定、有运维团队 |
| 规则调优 | 控制台操作，厂商规则更新 | 需自行维护或购买服务 |
| 延迟影响 | 取决于清洗节点位置 | 通常本地处理，延迟可控 |
选型时先明确防护目标：是扛CC攻击，还是防SQL注入，还是满足等保合规，目标不同,预算分配差别很大。
北京网页防火墙过滤异常请求方案的地域部署要点
清洗节点与回源链路延迟
如果业务用户集中在北京及周边，选择靠近华北的清洗节点可以减少转发延迟，部署前用测速工具对比不同节点的回源耗时，别只看厂商宣传的“全网加速”，对延迟敏感的API接口，可以配置分线路解析，让静态资源走CDN,动态接口走WAF清洗。
日志留存与合规要求
北京地区部分行业对网络日志留存有明确要求，上线WAF时确认日志保存周期、字段完整性和导出方式，至少保留请求时间、源IP、URI、命中规则、动作结果，日志不要只存本地，建议同步到对象存储或日志服务,方便事后追溯。
网页防火墙过滤异常请求误杀正常用户怎么办
误杀常见原因
误杀通常来自三类配置：
- 规则匹配范围过宽，例如把包含“select”的正常搜索词当成SQL注入。
- 速率阈值设得过低,正常用户连续刷新页面就触发限速。
- 人机验证弹得太频繁,低版本浏览器或特殊网络环境无法完成挑战。
白名单与观察模式
处理误杀先看日志：命中哪条规则、请求长什么样、用户后续行为是否正常,确认是误杀后：
- 把具体URI或参数加入规则白名单,不要整站放行。
- 对已知业务IP段或合作方回调地址设独立白名单。
- 新规则统一先跑观察模式,积累误报样本后再收紧。
- 保留一键回滚开关,误杀集中爆发时先关规则再排查。
Q&A：网页防火墙过滤异常请求常见问题
网页防火墙能100%过滤异常请求吗？
不能，WAF的核心价值是提高攻击成本、降低异常请求到达后端的比例，规则总有覆盖不到的新变种，业务逻辑漏洞也不完全靠WAF兜底，合理目标是拦住绝大多数已知和可疑请求,同时把误杀控制在可接受范围。
网页防火墙过滤异常请求一般需要多少预算？
预算跨度较大，云WAF基础套餐每年几千元起步，按量付费适合流量波动大的站点；硬件WAF加实施服务通常数万元起，实际支出取决于防护域名数、带宽峰值、是否需要定制规则和日志留存，建议先按业务峰值估算请求量,再对比套餐包含的防护能力和超量计费单价。
网页防火墙过滤异常请求会影响正常用户访问速度吗？
会有一定影响，但通常可控，云WAF的延迟主要来自清洗节点转发和规则检测耗时，选择就近节点、把静态资源交给CDN、对高频规则做缓存或异步检测，都能降低感知延迟，真正影响体验的往往不是WAF本身，而是规则过严导致正常请求被反复挑战，上线前用真实用户路径做一轮压测，比只看单次请求耗时更有参考意义，目前没有哪家WAF能保证100%拦截异常请求,实际拦截效果取决于规则配置与攻击特征的覆盖程度。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/785009.html
