使用 curl 查看重定向路径与最终 URL —— 追踪 301/302

关于本文
本文是通过利用生成式 AI 的自动化流程创建的。在查阅了 RFC 9110 与 curl 官方资料后，梳理了将 301/302 等重定向拆分为“初始响应”、“中间路径”和“最终 URL”进行确认的方法。

验证状态：📘 已确认 RFC/curl 官方文档・执行未验证

由于浏览器会自动追踪重定向，因此有时很难看出“最初是否是 HTTP”、“是否被转发到了带 www 的网址”或“究竟重定向了多少次”。

如果使用 curl，则可以分别确认转发前的 Location 以及最终到达的 URL。

首先查看初始响应

curl -I https://example.com/

当返回 301、302、307、308 等状态码时，请检查 Location。

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/

在此情况下，curl -I如果只使用该参数，是不会自动跳转到下一个 URL 的。

使用 -L 追踪重定向

curl -I -L https://example.com/

-L / --location加上该参数后，就会顺着 Location 继续追踪。

如果存在多级重定向，响应的 header 会按顺序显示。

sequenceDiagram
  participant C as curl
  participant A as URL A
  participant B as URL B
  participant C2 as URL C
  C->>A: Request
  A-->>C: 301 Location: B
  C->>B: Request
  B-->>C: 302 Location: C
  C->>C2: Request
  C2-->>C: 200 OK

只想知道最终的 URL

使用 curl 的 write-out 功能可以显示最终的 URL。

curl -sS -L -o /dev/null   -w 'HTTP=%{http_code}nFINAL=%{url_effective}n'   https://example.com/

需要确认的是以下两点：

• http_code: 最终响应的 status

• url_effective: 最后到达的 URL

有什么用

在实际工作中，它对于确认以下内容非常有用：

• HTTP 到 HTTPS 的转发

• 带或不带 www 的统一

• 旧 URL 到新 URL 的 301 重定向

• WordPress 的 canonical URL 更改

• 反向代理设置

• 引入 CDN 后的转发

• 认证前 URL 到登录 URL

在 SEO 和网站迁移中，不仅要知道“会被转发”，还要知道经过了多少层级也很重要。不必要的过多重定向是重新审视架构的线索。

还可以排查无限循环

在 A→B→A 这样的配置错误中，浏览器有时只会显示“重定向次数过多”。

而在 curl 中，可以明确指定最大次数。

curl -I -L --max-redirs 5 https://example.com/

如果超过 5 次就会报错，从而可以怀疑存在循环或过度转发。

带有认证信息的 URL 需注意

当重定向目标是其他主机时，需要谨慎确认认证信息和 Cookie 的处理方式。

特别是 --location-trusted可能会将凭据发送到其他主机，因此在不理解其含义的情况下最好不要使用。

在分享故障排查结果时，也要注意不要直接贴出：

• Cookie

• Authorization

• 内部 URL

• 会话信息

不要止步于“301 和 302 的区别”

实际工作中需要的不是死记硬背状态码，而是确认：

1. 最初被返回到了哪里

2. 接下来去了哪里

3. 最终的 URL 是什么

4. 最终的状态码是什么

5. 是否为预期的路径

总结

• -I 可以确认最初的 Location

• -L 可以追踪重定向

• %{url_effective} 可以确认最终的 URL

• --max-redirs 可用于排查循环问题

• 谨慎处理伴随认证信息的重定向

官方信息与一手资料

• RFC 9110: HTTP 语义

• curl 手册页