伪静态规则在nginx中执行早于waf，rewrite重写后的uri被php-waf读取，导致原始攻击特征丢失；云waf因位于nginx前可捕获原始uri，而php-waf需通过$_server['redirect_url']或未修改的原始字段检测攻击。
伪静态规则在 Nginx 中的执行顺序早于 WAF
ThinkPHP 的伪静态规则本质是 Nginx 的 rewrite 指令，它在请求进入 PHP 之前就已完成 URL 重写；而 WAF（无论是云 WAF 还是 PHP-WAF 扩展）介入时机晚于该阶段。这意味着：若伪静态规则把恶意 URL 改写成“看似合法”的路径，WAF 可能收不到原始攻击特征。
常见错误现象：curl "http://example.com/index.php?s=/index/test&id=1%20union%20select" 被伪静态规则重写为 /index/test?id=1 union select 后，PHP-WAF 若只检查 $_SERVER['REQUEST_URI']（已被重写），就可能漏掉原始 SQL 片段。
- Nginx 伪静态发生在
location块内，属于 HTTP 请求处理的早期阶段 - 云 WAF 通常部署在负载均衡器之后、Nginx 之前，所以它看到的是原始 URI，不受伪静态影响
- PHP-WAF 扩展运行在 SAPI 层，看到的是 PHP 解析后的
$_SERVER['REQUEST_URI']，即重写后的值 - 若用入口文件
waf.php方式，必须在index.php最顶端引入，且应读取$_SERVER['REDIRECT_URL']或原始$_SERVER['REQUEST_URI']（未被 rewrite 修改前的值）
ThinkPHP 中间件的 IP 白名单不拦截静态资源请求
中间件注册后默认对所有匹配路由生效，但 ThinkPHP 的静态资源（如 /static/js/app.js）若由 Nginx 直接服务（未走 PHP），中间件根本不会触发——此时 WAF 和中间件都失效，仅依赖 Nginx 配置或系统防火墙。
使用场景：后台管理接口加了 IpWhitelist 中间件，但攻击者绕过接口，直接请求上传目录下的 /uploads/shell.php，若该路径被 Nginx 配置为直接响应，则中间件完全不生效。
- 确认 Nginx 是否启用
try_files或if (!-e $request_filename)规则：只有未命中真实文件时才转发给 PHP - 静态资源建议统一放在
public/下，并由 Nginx 显式配置location /static { alias /path/to/public/static; } - 若需对静态资源也做 IP 控制，必须在 Nginx 层用
allow/deny或geo+map实现，不能依赖 ThinkPHP 中间件 - CDN 回源请求会携带真实客户端 IP，但需确保 Nginx 设置了
real_ip_header X-Forwarded-For;和set_real_ip_from指定 CDN 网段
PHP-WAF 扩展与 ThinkPHP 路由解析存在时间差
PHP-WAF 在 SAPI 接收请求后立即扫描 $_GET、$_POST、php://input 等原始数据，而 ThinkPHP 的路由解析（如解析 s=/admin/user/edit）发生在框架初始化之后。这意味着 WAF 拦截的是“裸参数”，不是框架最终识别出的控制器/方法名。
性能影响：PHP-WAF 默认开启全部规则扫描，若业务大量使用 JSON POST 提交，且规则中含正则回溯风险项（如 .* 配合长文本），可能引发 CPU 尖峰；ThinkPHP 中间件则无此问题，但防护粒度更粗。
- PHP-WAF 规则文件中避免使用贪婪匹配，例如用
select\s+[\w\.\*]+\s+from替代select.*from - ThinkPHP 中间件适合做粗粒度控制（如整个后台路由组白名单），不适合检测 XSS 载荷变形
- 两者可共存：PHP-WAF 做底层载荷过滤，中间件做业务层访问控制，但注意不要重复返回 403 导致日志混乱
- 验证 PHP-WAF 是否生效，用
curl -v "http://localhost/?id=1%20and%201=1"并观察响应头是否有X-PHP-WAF: blocked（取决于扩展配置）
云 WAF 的域名策略对伪静态无感知，但影响重定向行为
云 WAF 以 Host 头和完整原始 URI 为匹配依据，不关心后端是否做了伪静态重写。但它会影响 301/302 重定向响应：若 WAF 配置了“仅记录”模式，而 ThinkPHP 在控制器里做了 redirect('/login')，这个跳转会正常发出；但若 WAF 开启“拦截”并匹配到跳转目标 URL 中的关键词，可能直接阻断而非放行重定向。
容易踩的坑：ThinkPHP 的 url() 生成的链接带 .html 后缀，而云 WAF 自定义规则若写成 match: /login\.html，可能因大小写或 trailing slash 差异漏匹配。
- 云 WAF 规则匹配字段应选
URI或Full URL，避免只匹配Path忽略查询参数 - 若 ThinkPHP 开启了
URL_HTML_SUFFIX，WAF 规则中需明确包含\.html，且注意转义 - WAF 的“观察模式”必须开启至少 48 小时再切“拦截”，否则伪静态生成的非常规路径（如
/user/profile_123.html）可能被误杀 - 测试时用
curl -H "Host: example.com" http://waf-ip//index.php?s=/test绕过 DNS，直击 WAF 入口验证规则逻辑
实际部署时，最易被忽略的是 Nginx 是否真正透传原始请求 URI 给 PHP-WAF —— 很多用户改了伪静态却没意识到 rewrite 指令已覆盖 $_SERVER['REQUEST_URI']，导致自定义规则形同虚设。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
