不能。负载均衡器默认不解析SQL语义，仅协议转发或简单正则匹配，易漏报误杀；真正有效的是嵌入WAF（如mod_security或AWS WAF），但需手动配置调优，且仍难防编码变形绕过；根本防御在于应用层使用PreparedStatement等参数化查询。
负载均衡层真能拦住 SQL 注入？
不能。主流负载均衡器（如 Nginx、AWS ALB、Cloudflare）默认不解析 HTTP 请求体中的 SQL 语义，只做协议层转发或简单正则匹配——这意味着靠它“过滤 SQL 注入”极易漏报、误杀，还可能破坏合法 JSON 或参数编码。
真正能起作用的，是把 mod_security 这类 WAF 模块嵌入 Nginx，或在 ALB 后接 AWS WAF 并启用托管规则集（如 AWSManagedRulesSQLiRuleSet）。但注意：WAF 规则本质是启发式匹配，对 Base64 编码、Unicode 变形、注释绕过等手法防御力有限。
Nginx + mod_security 拦截 SQLi 的实操要点
这是目前在负载均衡层最接近“可行”的方案，但必须手动配置并持续调优：
-
SecRequestBodyAccess On必须开启，否则 POST body 不进检测流程 - 默认的
OWASP-CRS规则集会拦截SELECT * FROM、UNION SELECT等典型模式，但也会误杀含user_id=123; DROP TABLE这种合法分号分隔参数的请求 - 遇到
403 Forbidden且日志里出现Matched "SQL Injection Attack"，先别急着加白名单——先用SecDebugLog查看具体哪条规则触发，再针对性SecRuleRemoveById - 不要把
SecResponseBodyAccess On打开，它会拖慢所有响应，且对防注入无意义
为什么不该依赖 ALB 或 CLB 自带的“请求过滤”功能
AWS ALB 的“Listener Rule”和腾讯云 CLB 的“七层转发策略”只支持 Host、Path、Header、Query String 的精确/前缀匹配，不支持正则或内容扫描。你无法用它们识别 id=1' OR '1'='1 这类 payload。
常见错误操作包括：
- 在 ALB Listener Rule 中写
path-pattern /api/*然后以为“已隔离风险接口”——其实攻击者直接打/api/user?id=1%27%20UNION%20SELECT%20...就绕过了 - 试图用 Cloudflare 的 WAF “Security Level”设为 High 来替代应用层防护——它只对已知公开 exploit 有效，对定制化盲注无效
- 把
sqlmap -u "https://site.com/api?id=1"测试结果当成“WAF 挡住了”，没验证是否只是返回了 503 而非真实拦截
真正有效的防线顺序不能乱
SQL 注入的防御必须按纵深顺序落地，负载均衡层只是最外一层纸糊的盾：
- 最内层：所有数据库访问必须用
PreparedStatement（Java）、pg_query_params（PHP/PgSQL）、query方法带参数对象（Node.js pg）——拼接字符串就是留后门 - 中间层：API 入口做输入校验，比如
user_id字段只接受正整数，直接parseInt()并检查isNaN()，比任何 WAF 都快且准 - 最外层：WAF 规则仅用于兜底，且要定期更新规则集、监控
block日志里的 FP（误报）率，超过 5% 就得调参
绕过 WAF 的 SQL 注入 PoC 一年比一年多，而参数化查询几乎无法绕过——这点容易被忽略，但恰恰是最该花时间确认的。
