Nginx rewrite中问号导致参数丢失，因显式写?会禁用自动追加$args；正确做法是省略?依赖默认行为，或显式拼接?$args，或用map指令安全处理query参数。
当 Nginx 的 rewrite 规则中涉及带问号（?）的 URL 参数时，常见故障是重写后参数“莫名消失”或被错误拼接（比如多出 ?、变成 &、或整个 query string 被丢弃）。这通常不是 bug，而是对 Nginx rewrite 机制中 query string 处理逻辑 不熟悉导致的。
理解 rewrite 默认行为：自动追加原始 query string
Nginx 的 rewrite 指令在不显式控制 query string 时，会默认保留并追加原始请求的 $args（即 ? 后面的所有内容）。例如：
原始请求：/old?name=alice&v=1
配置：rewrite ^/old$ /new permanent;
实际跳转：/new?name=alice&v=1 ✅（自动拼接）
但一旦你在 rewrite 目标中**手动写了问号**，Nginx 就认为你“已接管 query string”，不再自动追加原始参数——这是丢失的根源。
避免问号引发的参数丢失：三种典型写法对比
假设想把 /user/123?tab=profile 重写为 /u/123?tab=profile，注意以下写法差异：
-
❌ 错误写法（显式带 ?，但没传 $args）：
rewrite ^/user/(\d+)$ /u/$1? permanent;
→ 结果：/u/123?（原始tab=profile彻底丢失，且结尾多一个空 ?） -
✅ 正确写法①（不写 ?，依赖自动追加）：
rewrite ^/user/(\d+)$ /u/$1 permanent;
→ 结果：/u/123?tab=profile（原始参数完整保留） -
✅ 正确写法②（显式构造 query，用 $args 补全）：
rewrite ^/user/(\d+)$ /u/$1?$args permanent;
→ 结果：/u/123?tab=profile（显式拼接，可控性强） -
✅ 正确写法③（覆盖 query，只留指定参数）：
rewrite ^/user/(\d+)\?tab=(\w+)$ /u/$1?tab=$2 permanent;
→ 注意：这种写法需开启rewrite_log on;并配合error_log /path/debug.log notice;查看是否匹配成功，因为含 ? 的正则需匹配整个 URI（包括 query），而默认 location 匹配的是$uri（不含 query）
调试 rewrite 的关键命令和日志配置
光靠猜容易踩坑，必须打开 Nginx 的 rewrite 调试日志：
- 在
http或server块中添加：rewrite_log on; - 确保 error_log 级别 ≥
notice（debug最佳）：error_log /var/log/nginx/rewrite-debug.log notice; - 重启 Nginx 后，发起请求，查看日志中类似：
rewrite phase: 2<br>using configuration "/user/(\d+)\"<br>matched location "/user/(\d+)\"<br>rewriting /user/123?tab=profile -> /u/123<br>rewritten data: /u/123?tab=profile
- 若看到
no regex match或not matched，说明正则未覆盖 query 部分——记住：rewrite 正则默认只匹配 $uri（不含 ? 及之后）；如需匹配 query，得用if ($args ~ ...)或改用map指令
更健壮的替代方案：用 map 替代复杂 rewrite
当 rewrite 涉及 query 判断、条件拼接或多个参数组合时，map 指令比嵌套 if + rewrite 更清晰、性能更好：
例如，统一处理带 tab 参数的用户页：
map $args $new_uri {
default "";
~^tab=([^&]+) "/u/$1?tab=$1";
}
server {
location /user/ {
if ($new_uri) {
return 301 $new_uri;
}
}
}
注意：map 中的正则匹配的是 $args（纯 query string），无需担心 URI 分割问题，逻辑隔离，易于测试和维护。
