Nginx重定向问号自动处理技巧：3个细节让查询参数不再莫名消失

在Nginx配置中，问号（?）是一个特殊字符，它在rewrite规则中有着独特的含义。很多开发者在配置重定向时，因为不了解问号的处理机制，导致查询参数莫名消失。本文将深入解析Nginx重定向中问号的自动处理技巧，帮助你彻底搞懂参数保留的底层逻辑。

一、问号在rewrite中的特殊含义

在Nginx的rewrite指令中，问号（?）是一个分隔符，用于区分URI和新的查询字符串。这个设计导致了两种完全不同的行为：

1. rewrite不带问号：自动追加原参数

rewrite ^/old-path$ /new-path permanent;

如果原始请求是 /old-path?utm_source=google，重定向后会自动变成：

/new-path?utm_source=google

原理：rewrite不带问号时，Nginx会自动把原始查询参数追加到目标URL后面。

2. rewrite带问号：清空或覆盖原参数

rewrite ^/old-path$ /new-path? permanent;

注意目标URL末尾有个问号。这个配置会把所有查询参数清空：

# 原始请求
/old-path?utm_source=google&user_id=123

# 重定向后（参数全部丢失）
/new-path

原理：问号后面是空字符串，相当于把查询参数替换成空。

二、三种问号处理技巧

技巧1：清空所有查询参数

场景：需要重定向到一个干净的URL，不保留任何参数。

location /legacy-page {
    rewrite ^ /new-page? permanent;
}

注意事项：末尾的问号不能省略，否则参数会自动追加。

技巧2：替换查询参数

场景：保留部分参数，或替换成新的参数。

location /track {
    # 替换utm_source，保留其他参数
    if ($args ~* "(.*)utm_source=[^&]*(.*)") {
        set $args $1utm_source=new_channel$2;
    }
    rewrite ^ /landing-page permanent;
}

进阶写法：使用map指令选择性保留参数

map $args $filtered_args {
    ~^(.*&)?(utm_source|utm_medium)=[^&]*(&.*)?$  $args;
    default  "";
}

location /filter {
    rewrite ^ /clean-url?$filtered_args permanent;
}

技巧3：追加新参数并保留原参数

场景：在重定向时添加新的追踪参数，同时保留原有参数。

location /campaign {
    rewrite ^(.*)$ $1?new_param=value&$args? break;
}

关键点：

• $args 变量包含原始查询参数（不含问号）
• 末尾的问号告诉Nginx不要自动追加参数（因为已经手动拼接了）

三、常见陷阱与解决方案

陷阱1：双重问号导致参数丢失

错误配置：

rewrite ^/old$ /new?param=value permanent;

如果原始请求是 /old?utm=1，重定向后变成：

/new?param=value?utm=1

问题：出现了两个问号，第二个问号变成了普通字符，参数丢失。

解决方案：使用 $is_args 变量智能判断

rewrite ^/old$ /new?param=value$is_args$args permanent;

$is_args 变量的值：

• 如果原始请求有查询参数：值为 ?
• 如果没有查询参数：值为空字符串

陷阱2：return指令的参数保留问题

return指令和rewrite的参数处理机制不同：

# 方式1：return 301 - 不会自动追加参数
return 301 https://example.com/new-path;

# 方式2：return 301 + $request_uri - 保留完整URI（含参数）
return 301 https://example.com/new-path$request_uri;

# 方式3：return 301 + $uri$is_args$args - 更灵活
return 301 https://example.com/new-uri$is_args$args;

推荐：使用 $uri$is_args$args 而不是 $request_uri，因为前者不会重复域名。

陷阱3：proxy_pass的参数传递

当使用proxy_pass时，URL末尾带不带斜杠会影响参数传递：

# 带斜杠：参数会传递
location /api/ {
    proxy_pass http://backend/;
}

# 不带斜杠：完整URI会追加（含参数）
location /api {
    proxy_pass http://backend;
}

四、实战案例

案例1：HTTP跳转HTTPS保留UTM参数

server {
    listen 80;
    server_name example.com;
    
    # 正确：保留所有查询参数
    return 301 https://$host$uri$is_args$args;
    
    # 错误：参数会丢失
    # return 301 https://$host$request_uri;
    # 因为$request_uri包含原始路径，可能导致双重路径
}

案例2：多条件重定向

location /redirect {
    # 根据参数值选择不同的重定向目标
    if ($arg_channel = "wechat") {
        return 301 https://m.example.com/wechat$uri$is_args$args;
    }
    if ($arg_channel = "app") {
        return 301 https://app.example.com$uri$is_args$args;
    }
    # 默认重定向
    return 301 https://example.com$uri$is_args$args;
}

案例3：清理追踪参数

# 使用map删除特定的追踪参数
map $args $clean_args {
    ~^(.*)fbclid=[^&]*&?(.*)$ $1$2;
    ~^(.*)gclid=[^&]*&?(.*)$ $1$2;
    default $args;
}

location / {
    # 重定向时移除fbclid和gclid参数
    rewrite ^(.*)$ $uri$is_args$clean_args? break;
}

五、调试技巧

如何验证重定向后的URL是否正确？

1. 使用curl -L跟踪重定向

curl -I -L "http://example.com/old?utm_source=test"

查看Location响应头，确认参数是否保留。

2. 开启Nginx rewrite日志

error_log /var/log/nginx/error.log notice;
rewrite_log on;

日志中会显示rewrite的执行过程。

3. 使用echo模块打印变量

location /debug {
    echo "uri: $uri";
    echo "args: $args";
    echo "is_args: $is_args";
    echo "request_uri: $request_uri";
}

访问 /debug?test=1 可以看到各变量的实际值。

总结

Nginx重定向中的问号处理有三大核心规则：

1. rewrite不带问号：自动追加原参数（默认行为）
2. rewrite带问号：清空或替换参数
3. return指令：需要手动使用 $uri$is_args$args 保留参数

掌握这三个规则，再配合 $args、$is_args、$request_uri 等变量，你就能精准控制重定向时的参数传递行为了。

记住：永远不要凭直觉写rewrite规则，一定要用curl测试验证，确保参数传递符合预期。

---

相关文章

• Nginx rewrite问号含义解析：为什么你的查询参数总是莫名消失？
• Nginx $is_args和$args组合用法详解：重定向保留查询参数的正确姿势
• Nginx rewrite问号后如何保留原参数