Nginx Rewrite 参数丢失主因是未显式保留查询参数，需用 $is_args$args 拼接并配 last 终止匹配；proxy_pass 结尾斜杠会丢参，应优先用 proxy_pass http://backend; 配合 rewrite 显式传参。
排查 Nginx Rewrite 规则中参数丢失，核心是确认请求 URI 在重写过程中是否被意外截断、覆盖或未正确传递。关键点在于：Nginx 默认不自动携带原始查询参数（?a=1&b=2）进入重写后的 URI，除非显式保留。
检查 rewrite 指令是否遗漏了 last 或 break 导致后续处理异常
rewrite 执行后若未明确终止匹配流程，可能触发 location 重新匹配，而新 location 中若无 try_files 或 proxy_pass 显式传参，原始参数极易丢失。
- 用
rewrite ... last;：结束当前 location 匹配，发起内部重定向，此时 原始查询字符串默认保留 - 用
rewrite ... break;：停止 rewrite 执行，但仍在当前 location 内继续处理，不会自动带参进入 proxy_pass 或 fastcgi_pass - 错误示例：
rewrite ^/old/(.*)$ /new/$1 break;+proxy_pass http://backend;→ 参数会丢失，因为 proxy_pass 拼接的是/new/xxx，不含原始 query
确认是否显式传递查询参数（$args 或 $is_args$args）
Nginx 不会自动把原始参数追加到 rewrite 目标 URI 后，必须手动拼接。
- 安全写法（保留原参数）：
rewrite ^/a/(.*)$ /b/$1?$args last; - 更健壮写法（避免末尾多问号）：
rewrite ^/a/(.*)$ /b/$1$is_args$args last;（$is_args在有参数时输出?，否则为空） - 若重写目标本身带固定参数（如
?t=1），需手动合并：rewrite ^/x/(.*)$ /y/$1?t=1&$args last;，并注意空参数导致&开头的问题（可用 map 或 if 预处理）
排查 location 块中 proxy_pass 或 fastcgi_pass 是否隐式丢参
即使 rewrite 正确，下游代理也可能因配置方式不同而丢参：
-
proxy_pass http://backend;（无 URI 路径）→ 会将完整原始请求 URI（含 path + args）转发 -
proxy_pass http://backend/;（结尾有/）→ 会替换掉匹配的 location prefix，并只转发重写后的 path，不带原始 query（除非 rewrite 已拼好 $args） - 推荐统一用
proxy_pass http://backend;+ rewrite 显式拼参，避免歧义
开启调试日志快速定位实际处理路径
在 nginx.conf 的 events 或 http 块中临时启用：
error_log /var/log/nginx/rewrite.log notice;-
rewrite_log on;（需编译时含 --with-debug） - 然后访问触发 rewrite 的 URL，查看日志中每一步 rewrite 是否执行、目标 URI 是什么、最终进入哪个 location
- 配合
curl -v "http://host/xxx?a=1&b=2"观察响应头和后端收到的实际请求
不复杂但容易忽略：参数丢失往往不是 rewrite 本身写错，而是 rewrite 和 proxy_pass 的协作方式没对齐。重点盯住 $args 是否被显式使用、last/break 是否选对、proxy_pass 结尾斜杠是否存在。
