很多站长在做HTTP跳转HTTPS的时候，都会遇到一个让人头疼的问题：原本URL后面带的搜索参数、分页参数、跟踪参数（比如UTM参数），跳转之后就没了。比如用户访问 http://example.com/search?q=nginx，跳转到HTTPS之后变成了 https://example.com/search，搜索词直接消失。
这个问题看起来小，实际影响很大——搜索功能废了、分页失效、广告投放的跟踪数据全丢了、SEO也受影响。今天这篇文章就把这个问题彻底讲清楚，给你几种靠谱的修复方法。
一、为什么HTTP跳转HTTPS会丢参数？
问题的根源在于Nginx的重定向配置方式。最常见的一种"错误写法"是这样的：
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}这个配置看起来没问题，$request_uri 确实会携带查询参数，所以在纯Nginx层面参数其实是保留的。但很多时候参数丢失是以下原因导致的：
1. 反向代理层的二次重定向
如果你的架构是 Nginx → 后端应用（比如PHP、Java），后端自己又做了一次重定向，那后端重定向的时候如果没有把查询参数带上，参数就丢了。这种情况在WordPress、Laravel等框架中特别常见。
2. CDN或负载均衡器重写了URL
使用Cloudflare、阿里云CDN等时，CDN层可能会对URL进行改写。比如开启了"自动HTTPS重定向"功能，CDN自己做跳转时没带参数。
3. return语句写法不当
有些写法确实会丢参数，比如：
# 错误：丢失查询参数
return 301 https://$host$uri;
# 正确：保留查询参数
return 301 https://$host$request_uri;$uri 只包含路径部分（不含参数），$request_uri 才包含完整的原始请求URI（含参数）。一字之差，结果天壤之别。
二、4种修复方法
方法1：用 $request_uri 替代 $uri（最简单）
如果你当前用的是 $uri，直接改成 $request_uri 就行：
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}这是最直接的修复方式，一行配置搞定。建议把 $request_uri 作为重定向的标准写法。
方法2：使用 rewrite + $is_args$args
server {
listen 80;
server_name example.com;
rewrite ^ https://$host$uri$is_args$args permanent;
}这种写法更灵活。$is_args 在有查询参数时输出 ?，没有时输出空字符串。$args 是查询参数字符串。两个配合使用，无论有没有参数都能正确拼接。
方法3：检查并修复后端应用的重定向
如果问题出在后端，需要在应用层修复：
- PHP：确保
header("Location: https://...")时拼接了$_SERVER['QUERY_STRING'] - WordPress：检查插件是否有重定向逻辑，检查
wp-config.php中的站点地址设置 - Laravel：检查
app/Providers/AppServiceProvider.php中是否强制了HTTPS并丢失了参数 - Java Spring：检查安全配置中的HTTPS重定向规则，确保使用了
request.getQueryString()
方法4：CDN层的配置调整
如果使用了CDN：
- Cloudflare：进入 SSL/TLS → Edge Certificates，关闭 "Always Use HTTPS"，改用页面规则或Nginx层控制跳转
- 阿里云CDN：检查"强制跳转"设置，确认是否保留了原始查询参数
- Nginx + CDN架构：建议在CDN层关闭自动跳转，统一由源站Nginx处理，这样更容易控制参数保留行为
三、如何验证参数是否正确保留？
用curl命令验证，加上 -v 参数可以看到重定向的完整过程：
curl -v http://example.com/search?q=nginx 2>&1 | grep -i location看返回的 Location 头中是否包含 ?q=nginx。如果没有，说明参数确实丢了。
也可以用 -L 跟随重定向查看最终页面：
curl -L -v http://example.com/search?q=nginx 2>&1 | grep "GET "四、$uri、$request_uri、$args 变量速查
这三个变量是解决重定向参数问题的核心，搞清楚它们各自的含义，排查起来事半功倍：
| 变量 | 含义 | 示例（请求 /search?q=nginx） |
|---|---|---|
$uri | 当前请求的URI路径 | /search |
$request_uri | 原始完整请求URI（含参数） | /search?q=nginx |
$args | 查询参数字符串 | q=nginx |
$is_args | 有参数时为?，无参数时为空 | ? |
$query_string | 同 $args | q=nginx |
五、总结与最佳实践
- 首选方案：
return 301 https://$host$request_uri;，简单、可靠、参数完整保留 - 灵活方案：
rewrite ^ https://$host$uri$is_args$args permanent;，适合需要额外处理参数的场景 - 排查思路：先确认丢参发生在哪一层（Nginx / CDN / 后端），再针对性修复
- 验证方法：用curl -v查看Location头，确认参数是否携带
- 永远不要用：
return 301 https://$host$uri;，这个写法100%丢参数
HTTP跳转HTTPS参数丢失是个经典问题，但搞清楚原理之后其实很好解决。核心就记住一点：重定向URL里要包含查询参数，用 $request_uri 或 $is_args$args 拼上去就完事了。
相关阅读：
版权声明
本文仅代表个人观点。
本文系AI辅助作者原创，未经许可，转载请保留原文链接。
发表评论