短链参数为啥会丢？先搞懂重定向的基本机制
短链的本质是一个重定向跳转，用户访问 https://t.co/xxx 后，服务器返回301或302状态码，浏览器自动跳转到真实目标URL。问题就出在这个跳转过程中——如果配置不当，URL后面的查询参数（?utm_source=xxx&utm_medium=xxx）就会在某一跳被吃掉。
常见的参数丢失场景：
- Nginx return 301不保留参数：默认
return 301 https://target.com;会丢掉原始请求的查询参数 - CDN层跳转未配置保留查询字符串：Cloudflare、阿里云CDN的默认HTTPS跳转经常不保留UTM参数
- 多次重定向链路中某一跳未传递参数：A跳B保留了，B跳C丢了，问题隐蔽难查
实战排查第1步：用curl -L -v看完整重定向链路
排查短链参数丢失，第一步是用curl把整个重定向链路"拆"开看。-L 让curl跟随重定向，-v 输出详细过程（包括请求头、响应头、重定向URL）。
# 基础用法：查看短链的重定向链路
curl -L -v "https://t.co/xxx?utm_source=wechat&utm_medium=social"
# 只看响应头，不下载内容（更快）
curl -L -I "https://t.co/xxx?utm_source=wechat&utm_medium=social"
关键看什么？盯着每一跳的 Location 响应头——如果Location URL里没有? 后面的参数，说明这一跳就把参数弄丢了。
实战技巧：如果短链有多层跳转（A→B→C→目标），用 -v 能看到每一跳的完整Request URL和Response Headers，逐段对比参数是否还在。
实战排查第2步：用--max-redirs限制跳转次数防死循环
有些短链配置错误会导致无限重定向（跳来跳去跳不出来），用 --max-redirs 可以限制最大跳转次数，避免curl卡死。
# 限制最多跟3次重定向
curl -L --max-redirs 3 -v "https://short.url/xxx?utm_source=test"
# 设置为0禁止跟随重定向（只看第一跳）
curl -L --max-redirs 0 -v "https://short.url/xxx"
如果curl报错 maximum redirect followed，说明重定向链超过了你设的阈值，要么调大 --max-redirs，要么说明短链配置有死循环问题。
实战排查第3步：用-D保存响应头逐段分析
-D 参数把响应头保存到文件，适合离线分析复杂的多跳重定向。
# 保存响应头到文件
curl -L -D response_headers.txt "https://short.url/xxx?utm_source=wechat"
# 查看每一跳的Location头
grep -i "Location:" response_headers.txt
更进阶的用法：配合 -w 输出重定向次数和最终URL：
# 输出重定向次数和最终到达的URL
curl -L -w "\n重定向次数: %{num_redirects}\n最终URL: %{url_effective}\n" "https://short.url/xxx?utm_source=test"
实战排查第4步：区分301/302/307/308的参数行为差异
不同重定向状态码对参数的处理行为不同，这是很多人忽略的关键点：
- 301/302：浏览器可能把POST请求改成GET，请求体（包括参数）会丢失
- 307/308：严格保持原请求方法和请求体，POST参数不丢失
- 301永久重定向：浏览器会缓存，下次直接跳，参数问题可能被"缓存"住
用curl验证的实际命令：
# 查看短链返回的状态码（是301/302还是307/308）
curl -I "https://short.url/xxx"
# 模拟POST请求，看重定向后参数是否保留
curl -X POST -L "https://short.url/xxx" -d "param1=value1¶m2=value2"
实战排查第5步：用curl模拟不同场景验证修复方案
找到参数丢失的原因后，用curl验证修复方案是否生效。
场景1：Nginx return 301丢参数
修复前用curl测试：
# 修复前：参数会丢失
curl -L "http://example.com/short?utm_source=wechat"
# 修复后：参数保留
curl -L "http://example.com/short?utm_source=wechat"
正确的Nginx配置（保留参数）：
return 301 https://example.com$request_uri;
场景2：Cloudflare HTTPS跳转丢UTM参数
用curl对比Cloudflare开启"始终使用HTTPS"前后的参数保留情况：
# 测试HTTP跳HTTPS后UTM参数是否还在
curl -L "http://example.com?utm_source=wechat"
如果参数丢失，需要在Cloudflare配置Transform Rules来保留查询字符串。
推荐阅读
总结
curl排查短链参数丢失的核心思路：用 -L -v 看完整重定向链路，用 --max-redirs 防死循环，用 -D 保存响应头离线分析，用 -w 输出重定向次数和最终URL。搞清楚301/302和307/308的参数行为差异，才能对症下药。
短链参数丢失的本质是"重定向配置不当"，不是curl的问题。curl只是帮你把问题"看"清楚的工具。真正要修的是Nginx、CDN、后端的重定向配置。
最后提醒：不要用浏览器的开发者工具排查短链参数丢失，浏览器会缓存301跳转，第一次看到的错误可能第二次就被"缓存"覆盖了。用curl每次都是"干净"的请求，结果更可靠。
版权声明
本文仅代表个人观点。
本文系AI辅助作者原创，未经许可，转载请保留原文链接。
发表评论