Nginx层SQL注入过滤在phpEnv中仅能轻量拦截URL和$args，因旧版Nginx不支持$request_body读取、PCRE兼容性差、规则位置不当易失效；真正有效的是PHP层PDO预处理、数据库降权和禁用危险函数。
Nginx 层加 SQL 注入过滤规则，在 phpEnv 这类集成环境里能起作用，但极易误杀、且治标不治本。phpEnv 默认用的是 Windows 下的 Nginx + PHP + MySQL 组合，配置文件路径固定、模块有限，直接照搬 Linux 服务器上的 WAF 规则大概率会出问题。
为什么 phpEnv 的 nginx.conf 里加 if+return 容易失效
phpEnv 自带的 Nginx 版本通常较旧（如 1.16 或 1.18），默认不启用 ngx_http_rewrite_module 的全部能力，更关键的是：$request_body 在普通配置中根本不可读——你试图匹配 POST 请求体里的 union select，实际压根拿不到内容。
常见错误现象：
- 规则写在
http块顶层，没加break或放在location内，导致重写后又进 proxy_pass，白拦 - 正则里用了
（单词边界），Windows 版 Nginx 的 PCRE 库版本低，不支持或行为异常 - 把规则塞进
location ~ .php$里，但攻击请求走的是/index.php?id=1%20or%201=1，$args已被 decode，而你的正则却按 raw 匹配，漏掉
phpEnv 可安全使用的最小可行规则（只匹配 URL 和 args）
只对 $request_uri 和 $args 做轻量拦截，避开 $request_body 和复杂正则。以下规则可直接贴进 phpEnv 的站点配置（如 C:phpEnv
ginx hostsyour-site.conf 的 server 块内）：
立即学习“PHP免费学习笔记（深入）”；
if ($args ~* "(%27)|(')|(--)|(%23)|(#)|((SELECT|UNION|INSERT|UPDATE|DELETE|DROP|EXEC|DECLARE))") {
return 403;
}
if ($request_uri ~* "(%20OR%20)|(%20AND%20)|(/\*|\*/)|(;\s*select\s+from|;\s*union\s+select)") {
return 403;
}说明与限制：
- 用
~*而非~，避免大小写漏判（如UnIoN） - 不匹配
order by、limit、group by—— 这些合法关键词一拦就挂后台 -
%20OR%20比OR更可靠，因为 URL 编码后空格变%20，原样空格可能被 Nginx 自动 trim - 别加
rewrite ... break，只用return 403，防止重定向绕过
phpEnv 环境下真正该优先做的三件事
在 Nginx 层折腾规则前，这些动作对防 SQL 注入效果高得多，且不依赖 Nginx 版本：
-
PHP 层强制用 PDO 预处理：检查所有
mysql_query()、mysqli_query()调用，全部替换成PDO::prepare()+bindValue()；数字型参数必须用FILTER_VALIDATE_INT校验 -
数据库账号降权：phpEnv 的 MySQL 默认是
root@localhost，立刻新建一个账号，只给SELECT, INSERT, UPDATE权限，禁用DROP、CREATE、FILE -
关掉危险函数：在 phpEnv 的
php.ini里加disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source，重启 PHP
Nginx 规则在 phpEnv 里只是“锦上添花”，不是“雪中送炭”。真正容易被忽略的是：你改了 nginx.conf，但没重启 Nginx 服务（phpEnv 托盘图标右键 → “Restart Nginx”），或者改的是错的 conf 文件（比如改了全局 nginx.conf 却在 vhosts 下配了独立站点）。先确认规则是否真实加载，再谈效果。
