Nginx rewrite 重定向参数重复问题解决：5个实战案例让查询字符串不再翻倍

# Nginx rewrite 重定向参数重复问题解决：5个实战案例让查询字符串不再翻倍 ## 问题描述 在配置Nginx rewrite重定向时，一个常见但容易被忽视的问题：**重定向后URL中的查询参数出现重复**，例如原始请求是 `/test?a=1`，重定向后变成 `/test?a=1&a=1` 或 `/target?a=1&a=1&b=2`。 这个问题会导致后端应用解析参数出错、业务逻辑异常，甚至引发安全问题（如重复扣款、重复提交等）。 ## 问题现象：重定向后URL变成 ?a=1&a=1 典型现象： - 原始URL：`https://example.com/search?keyword=nginx` - 重定向后：`https://example.com/search?keyword=nginx&keyword=nginx` 或者： - 原始URL：`https://example.com/list?page=2&size=10` - 重定向后：`https://example.com/list?page=2&size=10&page=2&size=10` ## 根本原因：rewrite自动附加参数机制 Nginx的rewrite指令有一个**默认行为**：当替换字符串中**不包含问号**时，Nginx会自动将原始请求的查询参数（$args）附加到替换后的URL末尾。 ```nginx # 危险写法：会导致参数重复 rewrite ^/old-path$ /new-path last; ``` 当请求 `/old-path?a=1` 时，Nginx会将 `$args`（即 `a=1`）自动附加到 `/new-path` 后面，变成 `/new-path?a=1`。 但如果你在替换字符串中**手动拼接了参数**，同时又没有用问号告诉Nginx"我已经处理了参数"，就会导致参数被附加两次： ```nginx # 错误写法：参数会重复 rewrite ^/old-path$ /new-path?a=1 last; # 请求 /old-path?b=2 会变成 /new-path?a=1&b=2 # 但如果你原本想保留原参数，又手动拼了一次，就会重复 ``` 更常见的错误是： ```nginx # 错误写法：原参数被附加两次 rewrite ^/old-path$ /new-path?$args last; # 如果原请求是 /old-path?a=1 # Nginx先替换成 /new-path?a=1 # 然后又因为替换字符串中没有问号，自动附加 $args # 最终变成 /new-path?a=1&a=1 ``` **关键规则**： - 替换字符串中**有问号**：Nginx认为你已经处理了查询参数，不会自动附加 `$args` - 替换字符串中**无问号**：Nginx会自动将原始 `$args` 附加到结果URL末尾 ## 方法一：问号清空原参数（正确示例） 如果你**不希望保留原查询参数**，需要在替换字符串中加问号（可以是空问号）： ```nginx # 正确：不保留任何原参数 rewrite ^/old-path$ /new-path? last; # 正确：只保留指定参数，不附加原参数 rewrite ^/old-path$ /new-path?utm_source=redirect last; ``` 问号告诉Nginx："查询字符串我已经处理完了，不用再附加原始参数。" ## 方法二：$is_args$args 条件拼接 如果你**希望保留原查询参数**，但不希望重复，需要用 `$is_args$args` 配合问号： ```nginx # 正确：保留原参数，不重复 rewrite ^/old-path$ /new-path?$is_args$args last; ``` - `$is_args`：如果原始请求有查询参数，值为 `?`；否则为空字符串 - `$args`：原始查询参数字符串 这样，当原始请求有参数时，结果是 `/new-path?a=1`；当原始请求没有参数时，结果是 `/new-path`（不会多出一个多余的问号）。 **常见错误对比**： ```nginx # 错误：会重复附加参数 rewrite ^/old-path$ /new-path?$args last; # 正确：用 $is_args$args 而不是 ?$args rewrite ^/old-path$ /new-path?$is_args$args last; ``` 等等，`?$args` 其实也能工作，因为问号已经告诉Nginx不要自动附加参数了。但问题在于：当 `$args` 为空时，URL会变成 `/new-path?`（末尾多一个问号），而 `$is_args$args` 在 `$args` 为空时不会产生多余的问号。 ## 方法三：map指令按需保留 如果你需要**有选择地保留部分参数**（例如只保留utm_*参数，去掉fbclid、gclid等追踪参数），可以用map指令： ```nginx http { map $args $filtered_args { default ""; "~*(?:^|&)utm_(source|medium|campaign|term|content)=[^&]*" $0; } # 或者更精确地提取 map $arg_utm_source $keep_utm_source { "" ""; default "utm_source=$arg_utm_source"; } # ... 其他utm参数类似 } ``` 然后rewrite时只拼入选中的参数。这种方法更灵活，但需要Nginx支持map指令（通常都支持）。 更简单的方法是在rewrite中直接用条件判断： ```nginx # 只保留utm_source和utm_medium set $new_args ""; if ($arg_utm_source) { set $new_args "utm_source=$arg_utm_source"; } if ($arg_utm_medium) { set $new_args "${new_args}&utm_medium=$arg_utm_medium"; } rewrite ^/old-path$ /new-path?$new_args? last; ``` 注意末尾的 `?` 用来防止Nginx自动附加原参数。 ## 方法四：break标记终止后续rewrite 有时候参数重复不是因为rewrite本身的规则，而是因为**多个rewrite规则被依次执行**，每次都附加一次参数。 ```nginx # 危险：多个rewrite都会执行 rewrite ^/path-a$ /path-b last; rewrite ^/path-b$ /path-c last; # 这次重定向又会附加参数 ``` 使用 `break` 标记可以终止当前层级后续的rewrite执行： ```nginx rewrite ^/old-path$ /new-path?$is_args$args break; # break后，当前location内的后续rewrite不会执行 # 但注意：break不会终止location查找，只是不执行后续rewrite规则 ``` 或者使用 `last` 标记让Nginx重新查找location（通常更安全）： ```nginx rewrite ^/old-path$ /new-path?$is_args$args last; ``` ## 调试技巧：rewrite_log开启方法 当你无法确定参数重复的原因时，开启rewrite_log是最直接的调试方法： ```nginx http { rewrite_log on; # 开启rewrite日志 error_log /var/log/nginx/error.log notice; # 日志级别设为notice } ``` 然后发送请求，查看error.log： ```bash tail -f /var/log/nginx/error.log ``` rewrite_log会记录每条rewrite规则的匹配结果和最终重定向URL，让你清楚地看到参数是在哪一步被重复的。 ## 总结：4种方法对比表 | 方法 | 适用场景 | 优点 | 缺点 | |------|---------|------|------| | 问号清空原参数 | 不保留原参数 | 简单直接 | 会丢失所有原参数 | | $is_args$args | 保留全部原参数 | 标准写法，无多余字符 | 不能选择性保留 | | map指令按需保留 | 选择性保留参数 | 灵活，可过滤垃圾参数 | 配置稍复杂 | | break/last标记 | 防止多次rewrite叠加 | 控制执行流程 | 需要理解Nginx执行顺序 | ## 内链推荐 如果你正在排查Nginx重定向参数问题，这些文章也可能帮到你： - [Nginx rewrite参数保留4种方法对比：保留、追加、删除、选择性处理实战指南](https://youres.cn/xxx)（待替换为真实URL） - [Nginx $is_args $args $request_uri三个变量对比详解：搞懂它们，重定向再也不踩坑](https://youres.cn/xxx)（待替换为真实URL） - [Nginx return 301 保留所有参数不丢失：3种实战配置详解](https://youres.cn/xxx)（待替换为真实URL） ## 附录：完整配置示例 ```nginx server { listen 80; server_name example.com; # 开启rewrite日志（调试用） rewrite_log on; location /old-section { # 方法一：不保留原参数 rewrite ^/old-section/(.*)$ /new-section/$1? permanent; } location /keep-params { # 方法二：保留原参数 rewrite ^/keep-params/(.*)$ /target/$1?$is_args$args last; } location /filter-params { # 方法三：只保留utm_*参数（简化版，生产环境建议用map） set $filtered ""; if ($arg_utm_source) { set $filtered "utm_source=$arg_utm_source"; } rewrite ^/filter-params/(.*)$ /target/$1?$filtered? last; } } ``` ## 最后 Nginx rewrite参数重复问题的根本原因是**对Nginx自动附加参数机制理解不深**。记住这个核心规则： > **替换字符串中有问号 = 我已经处理了参数，不用再附加；没有问号 = 帮我保留原参数。** 掌握这个规则，再配合 `$is_args$args` 和条件判断，就能彻底解决参数重复问题。