必须启用语义引擎+正则初筛的两段式检测，因单纯正则无法识别空格替换（%09、/**/）、大小写混淆、内联注释及JSON/POST体绕过，且易误杀正常含SELECT的业务请求。
不能只靠正则匹配关键字，必须让WAF先做语义分析再决策拦截。 否则像 SEL/**/ECT、UnIoN%09SeLeCt、' OR 1=1 --+ 这类变体几乎必漏，而正常业务含 SELECT 的请求（如论坛搜索）又容易被误杀。
为什么简单正则规则在真实场景中大概率失效
多数人配置的规则类似 args contains "union|select|sleep"，但实际攻击中：
- 空格常被替换成 %09、%a0、/**/，而 \s 不覆盖这些；
- 大小写混淆、内联注释（/*!50000union*/）、嵌套括号都会绕过基础模式；
- WAF 默认通常只扫描 $_GET 和 $_COOKIE，而现代 API 请求大量走 POST body 或 JSON，若未显式开启 scan_post_data 和 scan_raw_body，等于形同虚设；
- 规则文件路径写错、权限不足、日志里报 failed to open stream 却没查，导致规则根本没加载。
必须启用语义引擎 + 正则初筛的两段式检测
真正有效的做法是把规则拆成两个阶段：
- 第一阶段用轻量正则快速初筛，比如 args matches "[\'\"`][^&\n\r]{0,50}(?:union|select|sleep|benchmark|information_schema)"，只抓带引号+疑似关键词的请求，减少性能开销；
- 第二阶段交由语义引擎（如 Libinjection 或内置 AI 引擎）判断该片段是否构成有效 SQL 注入上下文；
- 宝塔、腾讯云、华为云等主流 WAF 都支持 libinjection_is_sqli 这类函数调用，高危路径可直接加条件：request_uri matches "/api/.*user.*" and libinjection_is_sqli == true；
- 自定义规则动作建议设为“记录+放行”或“挑战”，而非直接拦截，避免误伤——语义引擎误报率仍存在，需结合日志人工复核。
绕过常见陷阱的实操要点
部署时务必验证以下几项：
- 检查 WAF 日志是否出现 loading rule file success，而不是只看界面“已保存”；
- 用 curl -v "https://yoursite.com/?id=1' AND SLEEP(1)--+" 测试，同时抓包确认请求 body 是否被解码（URL 编码、十六进制、Unicode 都要还原后再匹配）；
- 对 JSON 接口，必须确认 WAF 开启了 raw body 解析，否则 {"id":"1' OR 1=1--"} 这种 payload 完全不进检测流程；
- 不要用 .* 匹配长字段，改用 [^&\n\r]{0,100} 限制长度，防止回溯爆炸拖慢整条规则链；
- 避免在规则里写 match args contains "OR 1=1" 这种宽泛表达——它会拦住所有含 OR 的合法参数（如产品筛选 ?filter=ORANGE）。
最常被忽略的一点：语义引擎不是开个开关就自动生效的。它依赖底层库（如 Libinjection）的版本和编译选项，有些 WAF 版本默认禁用或仅对特定参数名（如 id、q）启用。不查文档、不读日志、不测 raw body，等于防护层只搭了一半。
