为什么需要逐层查看重定向参数变化
短链服务、CDN跳转、Nginx多层rewrite，任何一个环节都可能悄悄吃掉你的查询参数。只盯最终URL，你永远不知道UTM参数在哪个环节丢了。
curl -I 配合 -L 和 -v，可以逐层打印每一跳的响应头，精准定位参数是在哪一层消失的。
核心命令：curl -I逐层查看重定向参数变化
方法一：-I + -L 查看每一跳的Location头
curl -I -L "https://short.url/abc?utm_source=test&utm_medium=email"输出中每个HTTP/1.1 301或302后面都会跟着Location:头，逐行对比Location里的URL，参数的变化一目了然。
方法二：-v 参数打印完整请求响应细节
curl -v -L "https://short.url/abc?utm_source=test" 2>&1 | grep -i "Location:\|> GET\|< HTTP"-v会打印每次跳转的请求行（> GET /path?params...）和响应头（< HTTP/1.1 301、< Location: ...），对照看请求带了什么参数、响应跳去哪里，参数有没有被丢弃，一清二楚。
方法三：-w 输出最终url_effective做交叉验证
curl -s -o /dev/null -w "最终URL: %{url_effective}\n跳转次数: %{num_redirects}\n" -L "https://short.url/abc?utm_source=test"先用-I -L逐层看每一跳，再用-w url_effective确认最终URL，两边对得上，参数才算全程保留。
实战案例：UTM参数在第三跳丢了
有一次排查一个短链，最终页面GA4报告里UTM参数全丢了。用curl逐层查看：
curl -I -L "https://t.co/xxxxx?utm_source=wechat&utm_medium=social"输出大致如下：
HTTP/1.1 301
Location: https://link.example.com/abc?utm_source=wechat&utm_medium=social
HTTP/1.1 302
Location: https://www.example.com/abc
第二跳的Location里UTM参数没了！问题定位在link.example.com的302跳转配置，Nginx的return指令没有带$is_args$args，参数直接被丢弃。
逐层诊断参数丢失的排查清单
- 第一跳Location就丢了参数：短链服务本身配置问题，检查生成短链时是否保留了原始查询字符串
- 中间某跳突然没了参数：那一跳的Nginx/Apache配置用了
return 301 https://target.com/path而不是return 301 https://target.com$request_uri - 最终URL有参数但GA4收不到：参数可能在前端路由（SPA）被前端框架吃掉了，不是服务端问题
- HTTPS跳转后参数丢失：Nginx的HTTPS跳转配置没有带
$is_args$args
进阶技巧：-I -X GET强制用GET方法查看
curl -I -X GET -L "https://api.example.com/redirect?token=abc123"某些API在301/302响应中会切换方法（POST变GET），用-X GET强制指定方法，可以避免方法切换带来的干扰，专注看参数变化。
写成脚本：批量逐层检查多个短链
while read url; do
echo "=== $url ==="
curl -s -I -L "$url" | grep -i "HTTP/\|Location:"
done < url_list.txt
把需要检查的URL放进url_list.txt，跑一遍脚本，哪个URL在哪一层丢了参数，全部打印出来。
小结
重定向参数丢失的排查核心就是一句话：逐层看Location头，对比每一跳的URL，参数在哪一层消失，问题就在哪一层。curl -I -L是最直接的方法，配合-v和-w url_effective交叉验证，99%的参数丢失问题都能定位到具体配置行。
下一篇会讲如何用curl -w num_redirects配合url_effective做自动化批量巡检，把这套排查方法变成定时脚本，感兴趣可以继续关注。
相关文章
版权声明
本文仅代表个人观点。
本文系AI辅助作者原创，未经许可，转载请保留原文链接。
发表评论