curl -w格式化输出重定向信息：5个实战技巧让你精准诊断跳转链路

什么是curl -w格式化输出重定向信息

当你用curl调试重定向链路时，光看最终页面是不够的——你需要知道每一次跳转的状态码、跳转次数、最终URL是什么。curl -w（write-out）参数就是干这个的，它能在请求结束后输出自定义格式的重定向信息，让你一眼看清整个跳转链路的全貌。

简单来说，-w允许你定义一个输出模板，curl在请求完成后按照模板把各类变量替换成实际值。结合-L（跟随重定向）和-s（静默模式），你可以精确抓取重定向链中的每一个关键数据点。

curl -w与重定向相关的核心变量

curl -w提供了十几个输出变量，但和重定向直接相关的就这几个：

• num_redirects — 本次请求经历的重定向次数
• redirect_url — 最后一次重定向的目标URL
• url_effective — 最终落地URL（可能经过多次跳转）
• http_code — 最终响应的HTTP状态码
• response_code — 等同于http_code
• size_download — 最终响应体的下载大小
• time_total — 整个请求（含所有跳转）的总耗时
• time_redirect — 所有重定向花费的时间

5个实战技巧：用curl -w诊断重定向问题

技巧1：一行命令查看重定向次数和最终URL

curl -s -o /dev/null -w "重定向次数: %{num_redirects}\n最终URL: %{url_effective}\n状态码: %{http_code}\n总耗时: %{time_total}s\n" -L https://example.com

这个命令的含义：-s关闭进度条，-o /dev/null丢弃响应体，-w输出模板，-L跟随所有重定向。执行后你会看到类似这样的结果：

重定向次数: 2
最终URL: https://www.example.com/
状态码: 200
总耗时: 0.342s

如果重定向次数为0但你预期应该有跳转，说明重定向没有生效；如果次数异常高（比如超过5次），很可能存在重定向循环。

技巧2：计算重定向耗时占比

curl -s -o /dev/null -w "总耗时: %{time_total}s\n重定向耗时: %{time_redirect}s\n重定向占比: %{time_redirect}%{time_total}\n" -L https://example.com

这里%{time_redirect}%{time_total}不是除法，只是字符串拼接。要算百分比需要配合awk：

curl -s -o /dev/null -w "%{time_redirect} %{time_total}\n" -L https://example.com | awk '{printf "重定向耗时占比: %.1f%%\n", $1/$2*100}'

如果重定向耗时占总耗时的30%以上，说明跳转链路过长，需要优化。通常2次以内的跳转是合理的，超过3次就应该考虑合并或减少跳转层级。

技巧3：批量检查多个URL的重定向情况

for url in https://a.com https://b.com https://c.com; do
  result=$(curl -s -o /dev/null -w "%{url_effective}|%{num_redirects}|%{http_code}|%{time_total}" -L --max-time 10 "$url" 2>&1)
  echo "$url|$result"
done

输出格式用竖线分隔，方便后续导入Excel或用awk处理。每行格式为：原始URL|最终URL|跳转次数|状态码|总耗时。

这个脚本适合批量排查短链服务是否正常、CDN跳转是否异常、HTTPS重定向是否生效等场景。

技巧4：检测重定向后URL是否保留了查询参数

curl -s -o /dev/null -w "原始: https://example.com/page?utm_source=google&utm_medium=cpc\n最终: %{url_effective}\n跳转次数: %{num_redirects}\n" -L "https://example.com/page?utm_source=google&utm_medium=cpc"

通过对比原始URL和url_effective中的查询参数，一眼就能判断UTM参数在跳转过程中是否丢失。这是排查流量追踪失效最快的手段之一，比手动在浏览器里一步步点快得多。

技巧5：用-w模板文件复用复杂格式

当你的输出格式比较复杂时，可以写进模板文件，用-w @文件引用：

# 创建模板文件 redirect.tpl
cat > redirect.tpl << 'EOF'
=== 重定向检测报告 ===
原始请求: %{url_effective}
重定向次数: %{num_redirects}
最终状态码: %{http_code}
总耗时: %{time_total}s
DNS解析: %{time_namelookup}s
TCP连接: %{time_connect}s
TLS握手: %{time_appconnect}s
重定向耗时: %{time_redirect}s
下载大小: %{size_download} bytes
==========================
EOF

# 使用模板
curl -s -o /dev/null -w @redirect.tpl -L https://example.com

模板文件的好处是可以团队共享、版本管理，不用每次都敲一长串格式字符串。

curl -w变量与-v/--verbose的区别

很多人会问：-v（verbose）也能看到重定向信息，为什么还要用-w？区别很明显：

• -v输出所有请求细节（请求头、响应头、SSL握手过程），信息量大但噪音多，不适合批量处理
• -w只输出你关心的变量，干净精准，可以定制格式，适合脚本化批量处理
• -v无法精确提取某个字段值做逻辑判断
• -w可以直接和awk、grep、jq配合做数据分析

简单说：-v适合交互式调试，-w适合自动化监控和批量检测。

curl -w格式化输出重定向信息的常见问题

num_redirects始终为0怎么办

检查是否加了-L参数。没有-L时curl默认不跟随重定向，num_redirects自然为0。另外，如果是内部重定向（Nginx rewrite last/break），curl可能看不到——它只统计HTTP层面（301/302/307/308）的重定向。

time_redirect比time_total大

正常情况下time_redirect应该小于等于time_total。如果出现异常值，可能是curl版本bug或网络波动。建议升级curl到最新版本，或在命令末尾加2>&1检查是否有错误输出。

windows下%号需要转义吗

在Windows PowerShell中，%{variable}会被PowerShell解析，需要用反引号或单引号包裹：

curl -s -o NUL -w '重定向次数: %{num_redirects}' -L https://example.com

用单引号可以避免PowerShell把%当特殊字符处理。在CMD中也需要注意百分号转义。

总结

curl -w格式化输出重定向信息是日常运维和网络调试中非常实用的技巧。记住几个关键点：

• 配合-L跟随重定向，-s -o /dev/null静默丢弃响应体
• 核心变量：num_redirects、url_effective、http_code、time_redirect
• 复杂格式用模板文件-w @file复用
• 和awk/grep配合实现批量自动化检测

掌握了这些，排查重定向问题、检查参数保留、分析跳转性能都能一步到位。