Nginx return与rewrite参数行为实测对比：保留查询字符串的正确姿势与性能分析

为什么需要关注return和rewrite的参数行为差异

做过Nginx重定向配置的人，大概率踩过查询参数丢失的坑。同一个需求，有人用return，有人用rewrite，结果行为完全不同——有的参数完整保留，有的直接被丢弃，有的还偷偷附加了重复参数。

这篇文章不抄文档，用实际测试数据说话，把return和rewrite在参数处理上的差异讲清楚，帮你选对指令、少踩坑。

测试环境与方法

测试环境：Nginx 1.24，后端为一个简单的echo服务器，用于打印接收到的请求URI和参数。

测试方法：分别对return和rewrite的多种写法发起带查询参数的请求，观察最终转发到后端的URI是否完整保留?a=1&b=2这样的原始参数。

每次测试都用curl -L -v追踪完整重定向链路，确保看到的是浏览器真实行为，而不是只看Nginx配置自以为对了。

return指令的参数行为实测

写法一：return 301

这是最常见的写法，也是坑最多的写法。

location /old/ {
    return 301 https://www.youres.cn/new/$request_uri;
}

实测结果：$request_uri 包含原始查询参数，所以/old/page?a=1&b=2会被重定向到/new/page?a=1&b=2，参数完整保留。

但有一个隐藏陷阱：$request_uri已经包含了参数，如果新手在拼接URL时又手动加了$is_args$args，就会变成双重问号：/new/page?a=1&b=2?a=1&b=2。

写法二：return 301

location /old/ {
    return 301 https://www.youres.cn/new/$uri$is_args$args;
}

实测结果：$uri 不包含参数，$is_args在原始请求有参数时自动变成?，无参数时变成空字符串。这是最安全的写法，不会重复、不会丢失。

推荐指数：★★★★★

写法三：手动拼接问号

location /old/ {
    return 301 https://www.youres.cn/new/$uri?$args;
}

实测结果：强制加了问号，即使原始请求没有参数，重定向后的URL也会带一个多余的?，虽然大多数服务器能正确处理，但不规范，不推荐。

rewrite指令的参数行为实测

写法一：rewrite不带问号（自动追加参数）

rewrite ^/old/(.*)$ /new/$1 permanent;

实测结果：Nginx会自动把原始请求的查询参数追加到替换后的URI后面。如果原始请求是/old/page?a=1，重定向目标是/new/page?a=1，参数保留。

这是rewrite最优雅的地方：你不用显式处理参数，Nginx帮你搞定。

写法二：rewrite替换字符串带问号（覆盖参数）

rewrite ^/old/(.*)$ /new/$1?x=1 permanent;

实测结果：替换字符串中出现问号后，Nginx会用问号后面的内容覆盖原始参数，原始?a=1直接丢失，只剩下?x=1。

这是rewrite参数丢失的最常见原因，很多人不知道问号在rewrite替换字符串里有"覆盖"语义。

写法三：rewrite问号后加空值（清空参数）

rewrite ^/old/(.*)$ /new/$1? permanent;

实测结果：问号后面什么都不写，等价于主动清空所有查询参数。如果你确实想丢弃参数，这是正确写法；如果想保留却写成这样，就是bug。

return vs rewrite：参数行为对比表

场景	return行为	rewrite行为
默认不处理参数	$request_uri含参数，需注意重复	自动追加原始参数
替换字符串出现问号	按字面拼接	问号后内容覆盖原始参数
想保留原始参数	用$uri$is_args$args	替换字符串不加问号即可
想丢弃原始参数	手动拼接时不加$args	替换字符串加?或?空值
双重问号风险	中等（$request_uri+$args时）	低（默认自动处理）

性能实测：return更快

用wrk对两种写法做简单压测（1000并发，30秒），测试场景：将/old/*重定向到/new/*，带参数?a=1&b=2。

• return 301 $uri$is_args$args：QPS约 3.2万，平均延迟 3.1ms
• rewrite ^(.*)$ /new$1 permanent：QPS约 2.7万，平均延迟 3.7ms

return比rewrite快约18%，原因是return是Nginx的核心指令，执行路径更短；rewrite需要走正则匹配和替换流程，开销更大。

对于高并发场景，优先用return；对于复杂的URL重写逻辑（需要正则捕获组），rewrite更灵活，性能差距可以接受。

实战推荐：到底该用哪个

我的个人经验：

• 简单的域名跳转、HTTP→HTTPS：用return，性能好，配置清晰
• 需要正则匹配、路径重写：用rewrite，灵活性不可替代
• 需要保留查询参数：return用$uri$is_args$args；rewrite替换字符串不要加问号
• 需要丢弃或替换参数：rewrite用问号覆盖更直观

内链相关文章

• 深入解析Nginx $is_args和$args的组合用法：Nginx
• rewrite问号覆盖参数的底层原理：Nginx rewrite问号含义解析
• return 301参数丢失的3个隐藏陷阱：Nginx return 301 $request_uri参数丢失排查

原创内容，转载请注明出处。如有Nginx重定向参数相关的具体问题，欢迎留言讨论。