去年夏天帮一家做跨境电商的应用防朋友处理服务器迁移，上线第二天就挨了波CC攻击，火墙F环带宽瞬间跑满。境部运维群里有人甩了句“套个WAF啊”，应用防结果折腾一宿才把ModSecurity规则跑通。火墙F环这事让我意识到，境部WAF部署不是应用防装个软件就完事，环境适配的火墙F环坑比想象中多。

先搞清楚WAF到底拦什么。境部SQL注入、应用防XSS跨站、火墙F环文件包含、境部CC攻击——这些流量特征跟正常请求混在一起，应用防WAF要做的火墙F环是在七层把脏东西挑出来。挑的境部方式分两种：基于规则匹配和基于行为分析。规则匹配靠正则库，比如OWASP Core Rule Set，行为分析看请求频率、参数异常度。大部分开源方案走规则路线，云WAF厂商则混合着来。

部署位置决定防护效果

把WAF放在哪，直接关系到它能看见什么。云WAF（比如Cloudflare、阿里云WAF）走DNS解析切换，流量先到厂商节点清洗再回源。好处是隐藏真实IP、自带CDN，坏处是延迟增加、敏感数据经过第三方。我当时给朋友选的是云WAF，因为他的源站IP已经暴露过，自建WAF反而容易被绕过直接打源站。

自建方案常见的是Nginx+ModSecurity或OpenResty+Lua脚本。这种部署在反向代理层，跟业务服务器同一内网。优点是数据不出自己机房，规则随便改；缺点也明显——你得自己扛DDoS，WAF机器本身可能成为瓶颈。有个做在线教育的客户，自建WAF跑在2核4G的虚机上，结果规则一开全量，正常请求的延迟从80ms飙到600ms。后来换成4核8G独享才稳住。

规则调优比安装更磨人

ModSecurity默认的CRS规则集有几百条，全开等于自杀。误报率高得离谱，用户传个带“select”字样的商品描述都被拦。我习惯先设DetectionOnly模式跑一周，把日志里的误报URL和参数抓出来，写白名单。比如后台的富文本编辑器提交内容，XSS规则会疯狂触发，得针对特定路径关掉对应规则ID。

CC防护的阈值也别拍脑袋定。有个客户设了“单IP每分钟超过60次请求就封”，结果他们自己员工用公司出口IP访问后台，全被误杀。后来改成基于URI的细粒度限速，登录接口严格，静态资源放宽，才算合理。

日志和应急通道别忽视

WAF日志量大得惊人，一天几个G很正常。不接ELK或类似系统，排查攻击时只能grep到天亮。另外一定要留个后门——当WAF规则把正常业务拦死时，能快速切到“透明模式”或临时加白名单。有次周五晚上规则更新，把支付回调接口拦了，订单全部失败。幸亏Nginx配置里留了条bypass路径，改完五分钟恢复。

最后说个反直觉的点：WAF不是越严格越好。它本质是业务和攻击之间的平衡器。规则太松等于没装，太紧影响转化率。我见过最离谱的配置是连User-Agent里带“python”都封，结果自家数据同步脚本全挂。部署完先跑一周观察日志，比任何理论都管用。