Nginx重定向参数丢失常见原因：6种场景逐一分析

配置Nginx重定向时，很多人会遇到一个让人头疼的问题：明明URL带了参数，重定向之后参数就没了。调试半天发现，参数不是被"吃掉"了，而是Nginx的重定向机制本身就对查询字符串有选择性保留或丢弃的行为。今天就把参数丢失最常见的几种原因逐一讲清楚，方便你对号入座。

一、return指令默认不保留查询字符串

这是最常见的原因，很多新手在这里踩坑。看下面这个配置：

server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

上面这个配置看起来没问题，`$request_uri`包含了原始URI和查询字符串。但如果你写成了这样：

return 301 https://example.com$uri;

参数就没了——因为$uri只包含路径部分，不包含查询字符串。这是第一个需要排查的点。

二、rewrite规则中的"?"会覆盖原有参数

Nginx rewrite里的?符号是一个容易被忽略的陷阱。来看两种写法：

# 写法一：保留了原始查询参数（推荐）
rewrite ^/old-page /new-page? permanent;

# 写法二：会清空原始查询参数
rewrite ^/old-page /new-page?a=1 permanent;

只要rewrite目标里出现?，Nginx就会认为你指定了新的查询字符串，原始参数会被直接丢弃。即使你写的参数值是空的/new-page?，同样会清空原始参数。

正确的做法是使用$is_args$args组合：

rewrite ^/old-page /new-page$is_args$args? permanent;

如果确实要添加固定参数，同时保留原始参数，可以这样做：

rewrite ^/old-page /new-page?utm_source=nginx$is_args$args? permanent;

三、$uri和$request_uri的选择

这两个变量在重定向场景下表现不同，这是很多运维人员搞混的地方：

• $uri：只包含解码后的路径部分（不包含主机和查询字符串）
• $request_uri：包含完整路径+查询字符串（原始格式，不解码）

在return指令中，如果直接写return 301 https://example.com$uri;，参数100%丢失。正确写法应该是：

return 301 https://example.com$request_uri;

或者先处理路径再用变量拼接：

set $original_url $request_uri;
return 301 https://example.com$original_url;

四、proxy_pass和fastcgi_pass的行为差异

在代理转发场景下，查询参数的处理规则也不同：

# 有尾部斜杠：参数会传递到后端
location /api/ {
    proxy_pass http://backend;
}

# 无尾部斜杠：参数同样会传递
location /api/ {
    proxy_pass http://backend/;
}

真正出问题的地方在于：如果location匹配和proxy_pass目标之间存在rewrite，且rewrite目标中包含?，参数同样会被覆盖。另外，使用fastcgi_param手动设置QUERY_STRING时，如果覆盖了原始值，参数也会丢失。

# 这种写法会导致参数丢失
location ~ ^/api(.+)$ {
    fastcgi_pass unix:/tmp/php.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$1;
    # 如果没有传递QUERY_STRING，参数就丢了
}

# 正确做法：显式传递QUERY_STRING
location ~ ^/api(.+)$ {
    fastcgi_pass unix:/tmp/php.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$1;
    fastcgi_param QUERY_STRING $query_string;
}

五、Cloudflare/CDN层处理的影响

有时候问题不在Nginx，而在更前面的CDN或云平台。如果使用Cloudflare的"自动HTTPS重定向"，页面规则中的强制跳转可能会在Nginx处理之前就发生，参数处理逻辑由Cloudflare控制。

常见的问题场景：

• Cloudflare页面规则中配置了"始终使用HTTPS"，但查询字符串处理方式可能与你预期不同
• CDN缓存了重定向响应，后续请求直接命中缓存，不再经过Nginx
• 中间层做了URL标准化，可能修改或删除了参数

排查建议：用curl加-I参数查看重定向的响应头，确认参数是在哪一层丢失的：

curl -I "http://example.com/old-page?a=1&b=2"

六、多个重定向叠加导致参数最终丢失

有一种情况特别隐蔽：单个配置看起来没问题，但多个重定向叠加后参数丢失。例如先做HTTP到HTTPS的跳转，再做域名重定向，每次跳转都可能对参数做不同处理。

# 第一层：HTTP跳HTTPS
server {
    listen 80;
    return 301 https://example.com$request_uri;
}

# 第二层：HTTPS的server块里又有rewrite
server {
    listen 443;
    # 这个rewrite可能吃掉参数
    rewrite ^/old /new? permanent;
}

排查链式重定向时，用curl的-L参数跟随重定向，观察每一步的参数变化：

curl -Lv "http://example.com/old-page?a=1" 2>&1 | grep -E "^< |^> |^< HTTP"

七、快速排查清单

遇到参数丢失问题时，按以下顺序检查：

1. 检查变量选择：用的是$uri还是$request_uri？
2. 搜索rewrite里的?：目标URL中是否有?符号？
3. 检查return和rewrite谁生效：同一个请求是否同时匹配了多个重定向规则？
4. 看代理层配置：proxy_pass/fastcgi_pass是否有手动设置QUERY_STRING？
5. 检查CDN层：是否有Cloudflare或其他CDN在Nginx之前做了跳转？
6. 用curl验证：发送带参数的请求，逐步跟踪重定向链。

总结

Nginx重定向参数丢失的原因，总结起来就是三条主线：变量选错（$uri vs $request_uri）、查询字符串被覆盖（rewrite目标中的?符号）、代理层处理差异。搞清楚Nginx对查询字符串的处理规则，很多看似奇怪的问题其实都能快速定位。

如果你想进一步了解具体修复方法，可以参考本站其他文章：

• Nginx return和rewrite参数保留区别：两种重定向方式的核心差异与实战选择
• Nginx rewrite重定向保留查询参数：5种场景+完整配置示例
• Nginx return重定向不保留参数原因：彻底搞清楚301跳转参数丢失的本质