去年秋天，防服务我帮一家做跨境电商的火墙何保护朋友看服务器日志。凌晨三点，防服务一个IP在十秒内发起了两百多次请求，火墙何保护路径全是防服务 `/admin/` 和 `/wp-login.php`。服务器负载飙升，火墙何保护正常用户下单页面卡在转圈。防服务这不是火墙何保护什么高级攻击，就是防服务最基础的暴力破解加CC（Challenge Collapsar）洪水。但如果没有WAF，火墙何保护这波流量就能让他们的防服务业务停摆半小时。

WAF（Web应用防火墙）干的火墙何保护事，说白了就是防服务站在Web服务器前面当门卫。它不像传统防火墙只看IP和端口，火墙何保护它要拆开HTTP请求的防服务每一个字节——URL、参数、Cookie、Header、Body——然后判断：这玩意是人发的，还是工具发的？是正常业务，还是想偷数据？

我见过最直观的对比：一台裸奔的Nginx，面对SQL注入测试工具sqlmap，第一发请求就返回了数据库报错信息，等于告诉攻击者“我这儿有洞，快来挖”。而挂了WAF之后，sqlmap收到的全是403，偶尔夹杂几个200，但返回内容是WAF伪造的假页面。攻击者拿不到有效反馈，只能换目标。

WAF的规则库是它的核心资产。比如ModSecurity的OWASP核心规则集，里面有一条专门盯 `union select` 这种组合。但规则不是死的——我调过一条自定义规则，拦截所有参数里带 `../` 的请求，因为那家电商的图片路径从来不用相对目录。结果上线第一天就拦掉了一次目录遍历扫描。代价是误杀了一个老后台的导出功能，后来加了白名单才解决。

除了规则匹配，现代WAF还会做行为分析。Cloudflare的WAF会统计每个IP的请求频率、UA（User-Agent）一致性、JS挑战完成度。一个Python脚本用 `requests` 库发请求，UA写着Chrome，但不会执行JS，也不会加载CSS——这种特征太明显了。我观察过，Cloudflare在挑战失败三次后直接封IP段，干净利落。

反向代理模式是WAF最常见的部署方式。流量先到WAF，清洗一遍再转发给后端Nginx或Apache。好处是隐藏了真实服务器IP，坏处是WAF本身成了瓶颈。我测过一台4核8G的机器跑Nginx+ModSecurity，QPS（每秒查询率）从裸机的12000掉到3500左右。所以大厂会用硬件WAF或者云WAF集群，把规则匹配拆到多台机器上并行处理。

嵌入式模式则是把WAF模块编译进Web服务器，比如Nginx的ModSecurity模块。性能损耗小，但升级规则要重启服务。我自己的博客用的是OpenResty+Lua写的简易WAF，只拦特定路径的异常参数，QPS几乎没变化。这适合小站点，但扛不住大规模CC。

有个细节容易被忽略：WAF的日志比服务器日志更有价值。服务器日志只记录谁访问了什么，WAF日志会记录“为什么拦截”。我翻过一周的WAF日志，发现某个IP每天凌晨两点准时扫描 `/api/v1/users` 的id参数，从1递增到5000。这是典型的越权遍历。拿到这个证据后，我直接封了那个C段，顺便给API加了频率限制。

但WAF不是银弹。去年某金融客户被绕过，攻击者用分块传输编码（Transfer-Encoding: chunked）把SQL注入拆成多个TCP包，WAF的规则引擎没做流重组，直接放行了。后来升级到支持流检测的版本才堵住。这说明WAF的解析能力必须跟得上HTTP协议的边角特性。

另一个坑是误报。某次我上线一条新规则，拦截所有包含 `sleep(` 的请求。结果一个正常业务接口的参数名就叫 `sleep_duration`，被拦了三天才发现。WAF调优是个持续活，不是配好规则就完事。你得看拦截日志，看误报率，看业务反馈。

说到底，WAF保护Web服务器的逻辑就三层：第一层，把已知攻击特征挡在外面；第二层，用行为分析识别异常流量；第三层，给运维争取时间——哪怕只挡住五分钟，也够你上服务器改配置或者切流量了。没有WAF的Web服务器，就像没锁门的仓库，能不能丢东西全看运气。