waf集群规则不同步、无法解析sql语义、东西向流量绕过、日志无法关联是导致sql注入防护失效的四大根本原因，需通过统一规则分发、增强应用层防御、覆盖服务间流量及打通全链路追踪来系统性解决。
WAF集群规则不同步导致同一payload在不同节点判断不一致
分布式WAF不是“一装就灵”，各节点若规则版本、加载时机、解析逻辑不统一，攻击请求就能在A节点被放行、B节点被拦截——这不叫防护，叫随机丢包。常见错误是手动改某个边缘节点的本地规则文件，或CI/CD发布后没验证rule_version是否全量生效。
必须做到：
- 所有节点启动时主动上报rule_version和md5(rule_set)到中心元数据服务
- 每5分钟自动比对，发现差异立即告警并切断该节点流量转发
- 禁止直接编辑/etc/nginx/modsec/rules.conf这类本地路径，所有变更走签名流水线统一下发
WAF无法解析应用层SQL语义，只做字符串匹配
WAF看到的是GET /search?q=admin%27%20OR%201%3D1，它只能按正则找OR 1=1或%27，但完全不知道这段参数最终会不会被拼进WHERE name = '...'里。而真正的SQL执行发生在PHP的mysqli_query()或Java的Statement.execute()中，WAF根本看不到那条拼出来的完整语句。
这就导致：
- id=1/*!UNION*/SELECT这种注释分割写法绕过关键词匹配
- 0x554e494f4e（UNION十六进制）在WAF解码前就是一串合法数字
- JSON body里{"filter": "status='active' OR 1=1"}若未开启JSON解析器，WAF压根不拆包
云原生东西向流量绕过WAF检测点
WAF部署在南北向入口，但微服务之间调用走Service Mesh（如Istio+Envoy），SQL请求根本不经过它。比如user-service直连MySQL、report-service通过gRPC把SQL片段传给db-proxy，这些流量WAF日志里一条都看不到。
更麻烦的是：
- ORM的prepare() + execute()调用，在网络层表现为固定协议包，WAF无法区分是预编译还是动态拼接
- 连接池复用TCP连接，WAF难以关联多次请求的上下文（比如第一次SET @a=1，第二次SELECT @a）
- Sidecar代理若没配置with_request_body，连POST body里的SQL载荷都拿不到
WAF日志与应用日志无法关联，漏网请求难定位
当WAF日志显示ALLOW /api/v2/orders?sort=created_at，而应用日志却爆出MySQL Error: You have an error in your SQL syntax，你根本分不清是WAF没拦住，还是开发在ORDER BY子句里硬拼了变量——因为两者没有trace_id串联。
必须强制：
- WAF节点收到请求时生成X-Trace-ID并透传
- 应用代码在打数据库日志时带上同一trace_id
- 所有SQL异常堆栈必须包含原始HTTP参数名（如sort字段值），否则你永远找不到那个没做白名单校验的ORDER BY拼接点
真正卡住注入链路的，从来不是WAF能不能多拦一个SLEEP(5)，而是你敢不敢把所有mysql_query($sql)替换成mysqli_prepare()，以及有没有勇气把DB账号权限从root@%降到app_readonly@10.0.0.%。WAF只是探照灯，光打不到的地方，得靠代码自己亮。
