Nginx $is_args变量：让重定向参数处理不再头疼
你是不是在配置Nginx重定向的时候，经常被查询参数搞得一头雾水？明明想保留原始请求的URL参数，结果跳转之后参数全丢了。或者反过来，想去掉参数却怎么也去不干净。
这个问题的关键，往往就在$is_args这个变量上。今天咱们把这个变量彻底讲清楚，让你以后再也不踩参数处理的坑。
什么是$is_args变量？
$is_args是Nginx内置的一个变量，它的值很简答：
- 如果当前请求的URL包含查询参数（就是问号?后面的部分），
$is_args的值是? - 如果没有查询参数，
$is_args的值是空字符串""
就这么简单。但它的妙用，在于配合$args变量一起使用，实现灵活的参数拼接。
$is_args和$args的配合用法
最常见的场景是：你想做重定向，并且希望保留原始的查询参数。这时候就需要用到$is_args$args这个组合。
基础示例：保留原始参数做重定向
location /old-page {
return 301 https://www.youres.cn/new-page$is_args$args;
}
这个配置的意思是：
- 如果用户访问
/old-page?id=123，重定向到/new-page?id=123 - 如果用户访问
/old-page（没有参数），重定向到/new-page（不会多出一个没用的问号）
这里$is_args的作用就是：有参数就自动加上问号，没参数就不加。这样就避免了手动拼接时可能出现的多余问号问题。
为什么不能用硬编码的问号？
有些同学可能会这么写：
return 301 https://www.youres.cn/new-page?$args;
这种写法有什么问题？当$args为空的时候，重定向地址会变成 /new-page?，末尾多了一个无用的问号。虽然大多数浏览器能正常处理，但对SEO不友好，而且看起来也不专业。
用$is_args$args就能完美解决这个问题。
实战场景1：HTTP跳转HTTPS并保留参数
server {
listen 80;
server_name www.youres.cn;
return 301 https://www.youres.cn$request_uri;
}
这个配置用了$request_uri（包含完整路径和参数），其实已经自动保留了参数。但如果你需要单独处理路径和参数，可以这样写：
server {
listen 80;
server_name www.youres.cn;
return 301 https://www.youres.cn$uri$is_args$args;
}
实战场景2：重写URL并保留参数
location /product {
rewrite ^/product/([0-9]+)$ /item.php?id=$1$is_args$args last;
}
这个规则把 /product/123 重写到 /item.php?id=123，并且保留原始请求中的所有查询参数。
实战场景3：反向用法——强制去掉参数
有时候你反而想去掉所有参数，只保留路径。这时候就不能用$is_args$args了：
location / {
rewrite ^(.*)$ $1? permanent;
}
注意末尾的问号?，它的作用是清空现有参数，不进行参数拼接。
$is_args和$query_string的区别
这两个变量的值其实是一样的，都是问号?或者空字符串。Nginx官方文档里，$is_args和$query_string是等价的。
但习惯上，大家更常用$is_args，因为它名字里就有"is"这个词，读起来更直观地表达"是否有参数"这个含义。
调试技巧：用add_header查看变量值
不确定$is_args的值到底是什么？可以用add_header临时输出到响应头里：
location /test {
add_header X-Debug-Is-Args "$is_args";
add_header X-Debug-Args "$args";
return 200 "Check response headers\n";
default_type text/plain;
}
然后用curl查看：
curl -I https://www.youres.cn/test?id=123
响应头里会看到 X-Debug-Is-Args: ? 和 X-Debug-Args: id=123。
常见错误1：忘记加$is_args导致参数丢失
# 错误写法
return 301 /new-path$args;
# 正确写法
return 301 /new-path$is_args$args;
错误写法在有参数的时候也能工作（因为$args本身就包含参数内容），但如果你在$args前面手动加了问号，就可能出现双问号的问题。用$is_args$args是最稳妥的写法。
常见错误2：在rewrite中用了$request_uri但还想加参数
$request_uri已经包含了原始参数，如果你再手动拼接$args，就会导致参数重复。
# 错误：参数会重复
rewrite ^/a$ /b$is_args$args?$request_uri;
# 正确：直接用$request_uri即可
rewrite ^/a$ $request_uri? permanent;
性能考虑
$is_args是Nginx内置变量，读取开销极小，几乎可以忽略不计。不用担心用了会影响性能。
真正影响性能的是正则表达式匹配（rewrite里的正则），所以能不用正则就不用正则，优先用return做重定向。
总结
$is_args的值：有参数为?，无参数为空字符串- 标准用法：
$is_args$args组合，自动处理问号拼接 - 保留参数用：
return 301 /new-path$is_args$args; - 去掉参数用：
rewrite ^(.*)$ $1? permanent;（末尾加问号） - 调试用：
add_header输出变量值到响应头
掌握了$is_args，Nginx重定向里的参数处理就再也不是问题了。
相关文章：
版权声明
本文仅代表个人观点。
本文系AI辅助作者原创，未经许可，转载请保留原文链接。
发表评论