$args

用 Nginx 的 return 指令做 301 重定向时，很多人会遇到查询参数丢失、URL 出现双重问号、或者参数莫名其妙被覆盖的问题。本文从原理出发，配合真实案例，讲清楚 return 301 后面怎么拼接问号和参数，以及哪些写法是错的。 一、return 301 默认行为：查询参数会丢失 先记住一个核心事实：Nginx 的 return 301 $url 默认情况下不会自动携带原请求的查询参数。 server { listen 80; server...

在Nginx配置301重定向时，很多开发者遇到过URL出现双重问号的问题，比如原本应该是https://example.com/page?param=value，结果变成了https://example.com/page??param=value。这个问题不仅影响URL美观，更会导致查询参数无法正确传递，影响网站功能。 问题现象：双重问号从哪来的？ 先看一个典型的错误配置： # 错误写法：会导致双重问号 return 301 https://example.com$ne...

引言 在Nginx配置中，重定向时保留查询参数是很多运维同学的痛点。你可能遇到过这样的情况：配置了HTTP跳转HTTPS，结果URL后面的查询参数全丢了；或者设置了301重定向，UTM追踪参数莫名其妙消失。问题的核心在于$is_args和$args这两个变量的正确拼接。本文通过实战案例，带你彻底掌握URL拼接的正确姿势。 一、先搞清楚三个核心变量 在讨论拼接之前，我们需要先理解三个关键变量的区别： $request_uri：完整的请求URI，包含路径和查询字符串，如/pa...

问题背景：为什么查询参数总是丢？ 配置 Nginx 重定向时，很多人遇到过这样的怪事：访问 /search?q=nginx，跳转后变成了 /new-search，参数 q=nginx 不见了。 或者更糟：参数被重复拼接了两次，变成 ?q=nginx?q=nginx。 根本原因是：Nginx 的 return 和 rewrite 在处理查询参数时的行为完全不同，而大多数人并不知道 $is_args 和 $args 这两个变量的存在。 核心变量：先搞懂这三个东西 在讲最佳实践之前...

为什么要搞清楚 $is_args 和 $args 的组合 做Nginx重定向的时候，查询参数丢失是最常见的坑之一。很多人知道用 $request_uri 能保留完整路径，但有些场景你只需要保留参数部分，或者要对参数做过滤、拼接、修改——这时候就得靠 $is_args 和 $args 组合出击了。 这篇文章把这两个变量怎么搭配用、什么场景用、容易踩什么坑，一次讲清楚。 $is_args 和 $args 分别是什么 $is_args：问号本身 $is_args 的值只有...