phpEnv 的 Nginx 是精简编译版，未内置 ModSecurity、Lua 模块或脚本能力，仅支持基础 if+return 关键词拦截，且无法读取 $request_body，故无法开箱即用防 SQL 注入。
phpEnv 自带的 Nginx 无法直接启用 WAF 功能，必须手动集成规则或模块——它不包含 ModSecurity、Lua 模块或预置防火墙逻辑，所谓“简单 WAF”只能靠 if + return 做关键词拦截，且仅对 $args 和 $request_uri 有效。
为什么 phpEnv 的 Nginx 不能开箱即用防 SQL 注入
phpEnv 是 Windows 下的 PHP 集成环境，其内置 Nginx 是精简编译版：默认不加载 ngx_http_rewrite_module 以外的高级模块，更不含 modsecurity、lua-nginx-module 或任何运行时脚本能力。你看到的“WAF 开关”基本是伪界面，背后没对应模块支撑。
- 执行
nginx -V 2>&1 | grep -o 'modsecurity\|lua\|luajit'，结果为空 → 确认无相关模块 - 尝试在
server块里写ModSecurityEnabled on或access_by_lua_file→ 启动失败，报 unknown directive - phpEnv 控制面板里所谓“启用 WAF”选项，实际只是改了个 ini 标志位，不触发任何 Nginx 配置变更
用 if + return 在 phpEnv 中做最简 SQL 注入拦截
这是唯一无需重编译、不依赖外部模块的可行方式，但只拦显性攻击，且极易被大小写、编码、注释绕过。
- 把规则加在站点配置的
server块内（如C:\phpEnv\nginx\conf\vhost\your-site.conf），别放在http全局块——否则if作用域失效 - 必须用
~*（忽略大小写）匹配，否则UnIoN SeLeCt直接漏掉 - 只检查
$args（查询参数）和$request_uri；$request_body在 phpEnv 的 Nginx 里不可读，别写if ($request_body ~* ...)—— 这行永远不生效 - 示例规则（放 server 块里）：
if ($args ~* "(%27)|(\')|(--)|(%23)|(#)|(\b(SELECT|UNION|INSERT|UPDATE|DELETE|DROP|EXEC|CAST|CONVERT)\b)") { return 403; } if ($request_uri ~* "(%27)|(\')|(--)|(%23)|(#)|(\b(SELECT|UNION|INSERT|UPDATE|DELETE|DROP|EXEC|CAST|CONVERT)\b)") { return 403; }
常见失效原因和绕过点
你加了规则却没拦截成功？大概率掉进这几个坑：
立即学习“PHP免费学习笔记（深入）”；
-
if写在location /外但没加break或后续有rewrite→ 请求被重写后再次进入匹配，导致规则失效或循环 - 正则里没转义特殊字符：比如写
select * from，其中*和.未转义成\*和\.，实际匹配的是任意字符而非字面量 - 攻击 payload 用了 URL 编码绕过：如
%20OR%201%3D1（空格和等号编码），而你的正则只写了OR 1=1→ 必须显式覆盖%20、%3D、%2F等常见编码 - 误以为能拦 POST body：phpEnv 的 Nginx 默认不解析请求体，
$request_body变量为空，所有基于它的判断都无效
真正要防住，得换思路
在 phpEnv 环境下硬靠 Nginx 做深度防护，成本远高于收益。更务实的做法是：
- 把 SQL 防护重心移到 PHP 层：确认
pdo_mysql已启用，所有查询强制用prepare()+execute()，别拼字符串 - 用
mysqli_real_escape_string()仅作为兜底，且必须配合正确字符集（set_charset('utf8mb4')），否则宽字节注入仍存在 - 数据库账号权限最小化：Web 应用账号禁止
DROP、CREATE、FILE权限，连SELECT都按表限制 - 如果真需要 WAF 层，换 OpenResty（Windows 版可用）或直接上云 WAF，别在 phpEnv 里死磕
最后提醒一句：你在 phpEnv 里写的每条 if 规则，都可能被 /**/、+、%0a、JSON 嵌套等方式绕过——这不是配置问题，是技术边界问题。
