curl url_effective不跟随重定向原因：5个实战场景彻底搞懂默认行为差异

用 curl 检测重定向时，很多人习惯性加上 -L 参数让它自动跟随跳转。但有时候 url_effective 的输出结果并不是你想要的最终地址，问题往往就出在「curl 默认不跟随重定向」这个行为上。今天这篇文章，用5个实战场景把这个问题彻底讲清楚。

一、url_effective 为什么不跟随重定向？

先搞清楚一个基本事实：curl 在不做任何特殊配置的情况下，是不会跟随 HTTP 重定向的。url_effective 这个 -w 变量输出的，是「curl 实际请求的那个 URL」，而不是「服务器希望你最终访问的 URL」。

举个例子，你请求 http://example.com，服务器返回 302 跳转到 https://www.example.com。不加 -L 时，url_effective 输出的仍然是 http://example.com，而不是跳转后的目标地址。

这看起来是缺点，但其实是设计上的优势——它让你可以单独查看每一跳的响应，不被跳转链路掩盖真相。

二、5个实战场景解析 url_effective 不跟随的原因

场景1：不带 -L 参数，url_effective 显示的是第一跳 URL

curl -s -w '
url_effective: %{url_effective}
' http://httpbin.org/redirect/1

这个命令不带 -L，请求一个会产生一次重定向的地址。结果中 url_effective 显示的是第一跳的 URL，而不是跳转后的目标地址。配合 http_code 一起看，你会看到状态码是 302，但 curl 在拿到这个响应后就停住了。

如果你想同时看到状态码和 url_effective 的关系：

curl -s -w '状态码: %{http_code} | url_effective: %{url_effective}
' -o /dev/null http://httpbin.org/redirect/1

输出类似：状态码: 302 | url_effective: http://httpbin.org/redirect/1，第一跳 URL 清晰可见。

场景2：-L 参数跟随重定向后，url_effective 行为发生变化

加上 -L 之后，curl 会跟随跳转直到最终响应。此时 url_effective 输出的就是最后一次请求的 URL，也就是重定向链路的终点。

curl -sL -w 'url_effective: %{url_effective}
' http://httpbin.org/redirect/1

加了 -L 之后，输出就变成了最终的目标地址。所以「不跟随」的原因很简单：没有加 -L，curl 就不会去拿后面的地址。

场景3：max-redirs 参数限制了跟随次数，导致 url_effective 停在中间

即使你加了 -L，如果重定向次数超过了 --max-redirs 的限制，curl 会在达到上限时停下来。此时 url_effective 显示的是「curl 最后一次实际请求的 URL」，而不是最终目标。

curl -sL --max-redirs 0 -w 'url_effective: %{url_effective} | 状态码: %{http_code}
' http://httpbin.org/redirect/1

--max-redirs 0 意味着禁止跟随重定向。此时效果等同于不带 -L，url_effective 停留在第一跳。如果你的重定向链路很长，记得检查 max-redirs 的值。

场景4：POST 请求跟随重定向时，url_effective 的特殊性

POST 请求在跟随 302 或 301 重定向时，浏览器行为是将 POST 转成 GET。但 curl 的 -L 行为稍有不同——默认情况下 curl 会把 POST 转成 GET 再发请求。这会导致 url_effective 显示的是 GET 请求后的 URL，而不是 POST 请求的目标。

curl -sL -X POST -d 'name=test' -w 'url_effective: %{url_effective}
' http://httpbin.org/post

如果目标返回 302 重定向到另一个地址，curl 跟随后会以 GET 方式请求最终地址。如果需要保持 POST 方法，应该用 --post303 或手动处理重定向逻辑。

场景5：协议跳转（HTTPS → HTTP）导致 url_effective 显示不安全地址

有些老旧站点的重定向链路是 HTTPS → HTTP。在不加 -L 的情况下，url_effective 显示的是第一跳的 HTTPS 地址。一旦跟随跳转后，url_effective 可能显示成 HTTP 地址。

curl -sL -w 'url_effective: %{url_effective} | 协议: %{url_effective}
' https://example.com

如果服务器将 HTTPS 请求重定向到 HTTP，curl 跟随后会请求 HTTP 地址，此时 url_effective 就会显示 HTTP URL。这个行为本身没问题，但如果你在脚本中判断 url_effective 的协议，要注意这种情况。

三、实战验证：如何判断你的 url_effective 是否跟随了重定向

最简单的方法是把 url_effective 和 http_code 一起输出：

curl -sL -w '状态码: %{http_code} | url_effective: %{url_effective} | 重定向次数: %{num_redirects}
' -o /dev/null https://httpbin.org/redirect/2

如果 num_redirects 大于 0，而 url_effective 指向的是最终地址，说明 -L 正在工作。如果 num_redirects 显示数字，但 url_effective 停在中间，说明 --max-redirs 限制了跟随。

另一个实用技巧：用 -v 配合 -L，可以看到完整的重定向链路：

curl -svL http://httpbin.org/redirect/1 2>&1 | grep -E '< Location:|> url_effective'

这样可以同时看到 Location 头（每一跳的目标）和最终的 url_effective 输出。

四、总结：搞懂默认行为才能用好 url_effective

curl 的 url_effective 默认不跟随重定向，这不是 bug，是设计选择。理解了这个前提，你就知道：

• 不加 -L，url_effective 显示第一跳地址
• 加 -L，url_effective 显示最终请求地址
• --max-redirs 控制跟随次数上限，可能让 url_effective 停在中间
• POST 请求跟随重定向会被转成 GET，影响 url_effective 的含义
• 协议跳转（HTTPS→HTTP）会导致 url_effective 显示不安全的地址

根据你的实际需求选择合适的参数组合，才能让 url_effective 给出你想要的信息。