切勿盲目追踪重定向：使用 curl 观察 Location 的链式跳转

关于本文
本文采用生成式 AI 辅助的自动化流程编写。我们参考了 curl 官方手册和 HTTP 规范，重点从响应头观察重定向的入口，将其整理为用于初步排查 SSO、短链接及链接故障的方法。

验证状态：📘 已确认 curl 与 HTTP 官方规范・未经验证的外部通信

当 URL 跳转到另一个 URL 时，与其一开始就用-L去追查所有内容，不如先查看状态码和Location，这样就能明白发生了什么。特别是对于 SSO、短链接、HTTP 转 HTTPS、CDN 或公开 URL 更改，只需将“跳转到了哪里”可视化，就能大大推进调查进度。

本次成功的条件

确认第一个响应中包含的3xx和Location:，并且在使用-L时，能够观察到 curl 会自动追踪其去向，即为成功。

首先尝试

curl -sS -D - -o /dev/null https://httpbin.org/redirect/1

查看此处

3xx如果输出了状态码和Location:，则说明响应本身指示了下一个去向。

需要关注的三个要点是：

• 状态码是什么

• Location:是相对 URL 还是绝对 URL

• 主机名是否发生了变化

你可以将“打开链接时跳到其他页面”这一现象，作为 HTTP 响应来进行确认，而不仅仅是看浏览器的表象。

修改一个地方

curl -sS -L -D - -o /dev/null https://httpbin.org/redirect/1

-L加上参数后，curl 就会追踪 Location。如果显示多段响应头，请同时观察中间的状态码。

接下来更改重定向的次数。

curl -sS -L -D - -o /dev/null https://httpbin.org/redirect/3

通过确认 1 段跳转和 3 段跳转时响应头数量的增加，你就能明白“仅查看最终 URL”与“查看中间路径”的区别。

原理是什么

HTTP 重定向是指服务器返回 3xx 状态码和Location，然后客户端决定发送下一个请求的机制。

这里重要的是，重定向不仅仅是简单的 URL 替换。在 301/302/303/307/308 中，客户端在下一个请求中如何处理请求方法并不是完全相同的。如果只看 GET 请求，可能很难注意到这种差异，但在表单提交或 API 的 POST 请求中，这一点非常重要。

此外，如果在重定向后主机名发生了变化，还可能涉及认证信息、Cookie、代理、证书或网络控制等其他条件。

graph LR
A[元URL] -->|3xx + Location| B[次のURL]
B -->|3xx + Location| C[さらに次のURL]
C -->|200など| D[最終応答]

观察失败与边界条件

调查时不应假定一定存在重定向。

curl -sS -D - -o /dev/null https://example.com/

Location:如果没有该字段，这本身就是一个结果。此外，DNS 失败、TLS 错误或代理拒绝等情况会在 3xx 之前就停止，因此仅怀疑重定向是无法解决问题的。

-L如果一开始就加上该参数，人们往往容易只关注最终结果，从而忽视中途异常的跳转目标或多余的重定向。

在文职与日常工作中的应用场景

1. 确认内网门户链接

当“点击旧 URL 会跳转到新网站”时，可以确认原 URL 究竟跳转到了哪里。在整理部门操作手册或 Excel 表格中残留的旧链接时，这不仅能判断链接是否打得开，还能作为确定正式新 URL 的依据。

2. SSO 咨询的初步排查

对于“登录页面反复跳转”、“认证后未返回原页面”这类咨询，这可以作为排查重定向链是否过长、或者是否被转移到意料之外的主机上的切入点。

但是，请切勿轻易分享包含认证 Cookie 或 Token 的实际请求。请首先在公开 URL 或认证前的入口进行确认。

3. 确认邮件或资料中的短链接

在浏览器中直接打开短链接之前，仅确认Location即可掌握最初的跳转目标。虽然这不能保证安全性，但作为检查“它打算去哪里”的第一步非常有效。

4. 向网页维护人员反馈时的素材

与其只说“打不开”，不如整理出：

• 初始 URL

• 初始状态码

• Location

• 重定向次数

• 最终状态码

这样可以更具体地向网页管理人员或供应商反馈情况。

工作中的实用建议

该方法适用于排查 SSO、短链接、HTTP 转 HTTPS、CDN 切换以及旧内链。为避免将带有认证头或 Cookie 的请求无条件发送到未知的重定向目标，请务必先确认去向。

作为业务操作流程，首先在不使用-L的情况下查看入口 → 必要时使用该参数查看链式跳转 → 确认主机名发生变化的地点-L这样的顺序是安全的。

curl 手册：https://curl.se/docs/manpage.html

RFC 9110：https://www.rfc-editor.org/rfc/rfc9110