内容摘要：凌晨三点，攻击者的自动化脚本撞上WAF的规则引擎，像潮水拍在防波堤上。日志里刷过几千条403，偶尔夹着几串200——那是被放行的正常流量。没有警报声，没有值班人员，一切都在沉默中完成。 WAF这东西，

凌晨三点，应用程攻击者的序防自动化脚本撞上WAF的规则引擎，像潮水拍在防波堤上。火墙日志里刷过几千条403，应用程偶尔夹着几串200——那是序防被放行的正常流量。没有警报声，火墙没有值班人员，应用程一切都在沉默中完成。序防

WAF这东西，火墙本质上是应用程给Web应用戴的口罩。它不修漏洞，序防不治根本，火墙只负责在HTTP请求到达服务器之前，应用程把可疑的序防东西拦下来。SQL注入、火墙XSS跨站脚本、文件包含攻击，这些老掉牙的手法至今仍在肆虐，因为总有新上线的站点裸奔在公网。

我见过最典型的误判案例：某电商平台促销期间，WAF把正常用户的抢购请求当成CC攻击封了IP。技术团队半夜爬起来调阈值，一边挨骂一边改规则。第二天复盘发现，问题出在某个正则表达式过于激进，把包含"coupon"的URL全给匹配了。规则太严误伤用户，太松又防不住攻击，这就是WAF的宿命。

真正的攻防往往发生在规则之外。攻击者会尝试编码绕过——把union select写成uni%6Fn sel%65ct，或者用注释符切割关键词。WAF的解析器得能识别各种变形，还得跟上新的攻击手法。云厂商的WAF产品更新快，因为有庞大的流量样本喂给机器学习模型；开源方案像ModSecurity，靠社区维护规则库，总慢半拍。

有个细节常被忽略：WAF部署位置直接决定防护效果。放在CDN节点上，能过滤掉大部分流量，但HTTPS加密流量需要先解密才能检测，这就成了性能瓶颈。放在源站前面，倒是能拿到完整上下文，可一旦WAF本身被打瘫，后端就彻底暴露。所以现在流行多层部署，边缘层挡粗粒度攻击，近源层做精细检测。

也别把WAF神话了。它防不住业务逻辑漏洞——比如优惠券可以重复领取，或者越权访问他人订单。这类攻击看起来完全像正常请求，WAF再聪明也识别不了。要堵住这些口子，得靠代码审计和渗透测试。

话说回来，大部分中小企业连个像样的安全团队都没有，WAF几乎是唯一能自动挡子弹的东西。托管式WAF服务商甚至提供7×24小时人工研判，把误报率压到极低。这算是一种"安全外包"，花钱买省心，总比自己硬扛强。

说到底，WAF的价值在于把攻击挡在门外，而不是等打进内部再亡羊补牢。它像门口那盏常亮的灯，不声不响，但半夜路过时，你会觉得踏实。