num_redirects 和 url_effective 各自是干什么的？
先把两个变量搞清楚，不然后面用起来总感觉迷迷糊糊。
num_redirects：跳转了几次
这个变量告诉你：这次请求一共经历了几次重定向。注意是"次数"，不是"层数"。举个例子：
- A → B → C，num_redirects = 2（两次跳转，最终到达C）
- A → A → A → A，num_redirects = 3（三次跳转，哪怕是在循环）
值为 0 表示没有发生重定向，你拿到的就是原始请求的响应。
url_effective：最终落在了哪个URL
这个变量给出的是：经过所有重定向之后，实际产生响应的那个URL。它解决的是"我最终到了哪里"的问题。
这两个变量配合起来用，一个回答"跳了几次"，一个回答"最后在哪里"，正好是完整跳转链路诊断的两个核心问题。
基础用法：一行命令看清跳转次数和最终URL
最简单的用法，直接在两个变量之间加个分隔符输出：
curl -L -w "\n跳转次数: %{num_redirects}\n最终URL: %{url_effective}\n" -o /dev/null -s https://example.com参数说明：
-L：跟随重定向，不加这个 num_redirects 永远是 0-w：请求完成后输出格式化信息-o /dev/null：不显示响应体，只要跳转信息-s：静默模式，不显示进度条
Windows PowerShell 用户注意：/dev/null 要改成 NUL，或者用 -o NUL。
实战场景一：短链参数丢失诊断
这是最常见的问题场景。你发了一个带 UTM 参数的短链，用户点击后 GA4 里显示 direct，说明参数在跳转过程中丢了。
用 num_redirects + url_effective 可以这样排查：
curl -L -w "\n=== 跳转诊断 ===\n跳转次数: %{num_redirects}\n最终URL: %{url_effective}\n最终状态码: %{http_code}\n" -o NUL -s "https://your-short.link/abc?utm_source=wechat&utm_medium=social"重点看最终URL里还有没有 utm_source 和 utm_medium 参数。如果最终URL里参数消失了，说明重定向过程中没有保留查询字符串，需要去检查 Nginx/Cloudflare 的重定向配置。
实战场景二：CDN/多层代理跳转链路追踪
网站前面有 CDN（Cloudflare、阿里云CDN 等），后面有 Nginx，再后面有后端应用。一层层跳转，参数在哪一层丢的？
配合 -v 参数可以看到每一次跳转的响应头：
curl -L -v -w "\n跳转次数: %{num_redirects}\n最终URL: %{url_effective}\n" -o NUL "https://youres.cn/test?utm_campaign=summer" 2>&1 | findstr /i "Location:"Windows 下用 findstr 过滤 Location 头，能看到每一次跳转的目标地址。结合最终URL，就能判断参数是在哪一层丢失的。
实战场景三：用 @ 模板文件做批量跳转巡检
如果你要监控多个域名的跳转行为（比如确认 HTTPS 跳转后参数是否保留），用 -w @模板文件 的方式最高效。
先创建一个模板文件 redirect_check.txt：
URL: %{url_effective}
跳转次数: %{num_redirects}
最终状态码: %{http_code}
总时间: %{time_total}s
然后批量检测：
for url in "https://domain1.com?utm=test" "https://domain2.com?utm=test"; do
curl -L -w "@redirect_check.txt" -o /dev/null -s "$url"
echo "---"
donePowerShell 版本：
$urls = @("https://domain1.com?utm=test","https://domain2.com?utm=test")
foreach ($url in $urls) {
curl -L -w "`n跳转次数: %{num_redirects}`n最终URL: %{url_effective}`n" -o NUL -s $url
Write-Output "---"
}常见问题：num_redirects 输出 0 但明明发生了跳转？
这是新手最容易踩的坑。原因只有一个：-L 参数没加。
num_redirects 统计的是 curl 实际跟随的重定向次数。如果你没有加 -L，curl 遇到 301/302 不会跟随，num_redirects 自然是 0。
另一个可能：某些网站的重定向是通过 JavaScript 或 Meta Refresh 实现的，curl 的 -L 只能处理 HTTP 301/302/303/307/308 重定向，对 JS 跳转无能为力。遇到这种情况，最终URL会和原始URL一样，num_redirects 也是 0。
进阶组合：同时输出跳转耗时
跳转次数和最终URL搞清楚之后，还有一个问题：跳转慢不慢？
配合 time_redirect 变量（注意：这个变量需要较新版本的 curl）：
curl -L -w "\n跳转次数: %{num_redirects}\n最终URL: %{url_effective}\n重定向耗时: %{time_redirect}s\n总耗时: %{time_total}s\n" -o NUL -s https://example.com如果 time_redirect 在你的 curl 版本里不可用（老版本会报错），可以改用 time_total 对比加 -L 和不加 -L 的耗时差异，间接判断重定向的性能影响。
相关文章
版权声明
本文仅代表个人观点。
本文系AI辅助作者原创，未经许可，转载请保留原文链接。
发表评论