cURL 如何处理 HTTP 重定向？

cURL 处理 HTTP 重定向是日常开发和面试中的高频考点。理解 cURL 重定向机制，核心在于掌握三个层面：跟随重定向的开关控制、不同状态码下的方法切换行为、以及跨域重定向的安全边界。

面试核心答案

cURL 默认不跟随重定向，需加 -L（或 --location）才会自动追踪 3xx 响应。重定向时，301/302/303 会将 POST 请求降级为 GET，而 307/308 会保持原始方法。通过 --post301/--post302 可以覆盖默认行为。跨域重定向时，cURL 默认不转发 Authorization 等敏感头，需 --location-trusted 显式允许。

重定向的基本控制

cURL 遇到 3xx 响应时，默认只返回重定向响应头，不会自动跳转到新地址。使用 -L 开启跟随重定向：

bash
# 默认：不跟随，只返回 301/302 响应
curl http://example.com

# 跟随重定向到最终地址
curl -L http://example.com
curl --location http://example.com

用 -v 可以看到完整的重定向过程，包括每一跳的 Location 头和状态码，排查问题时非常实用：

bash
curl -L -v http://example.com

为什么 301/302 会把 POST 变成 GET

这是面试中最常追问的点。原因在于 HTTP 规范的历史演进：

• 301 Moved Permanently 和 302 Found 在 RFC 1945（HTTP/1.0）时代就定义了，当时的客户端实现普遍把重定向后的 POST 改为 GET。后来 RFC 7231 将这个行为正式标准化——301/302 重定向后，客户端"可以"将方法改为 GET。
• 303 See Other 是 HTTP/1.1 新增的，明确要求重定向后必须使用 GET，典型场景是 POST 表单提交后跳转到结果页。
• 307 Temporary Redirect 和 308 Permanent Redirect 是后来补充的状态码，设计动机就是解决 301/302 方法降级的问题。307/308 明确要求保持原始请求方法不变。

状态码	含义	方法变化	适用场景
301	永久重定向	POST → GET	网址永久迁移
302	临时重定向	POST → GET	临时跳转（旧规范）
303	另见其他	POST → GET	POST 后跳结果页
307	临时重定向	保持不变	API 临时切换地址
308	永久重定向	保持不变	API 永久迁移

在 cURL 中控制 POST 重定向行为：

bash
# 默认：301/302 重定向后 POST 变 GET
curl -L -X POST -d "data=test" http://example.com/submit

# 301 重定向时保持 POST（遵循 RFC 7231）
curl -L --post301 -X POST -d "data=test" http://example.com/submit

# 302 重定向时保持 POST
curl -L --post302 -X POST -d "data=test" http://example.com/submit

# 303 重定向时保持 POST
curl -L --post303 -X POST -d "data=test" http://example.com/submit

重定向次数限制

cURL 默认最多跟随 50 次重定向，超过则报错。生产环境中应主动设置合理上限，防止重定向循环：

bash
# 限制最多 5 次重定向
curl -L --max-redirs 5 http://example.com

# 允许无限重定向（有循环风险，不建议）
curl -L --max-redirs -1 http://example.com

查看重定向链

调试重定向问题时，需要知道中间经历了哪些跳转。cURL 提供了 -w 格式化输出来获取关键信息：

bash
# 查看最终到达的 URL
curl -L -w "Final URL: %{url_effective}\n" -o /dev/null -s http://example.com

# 查看总重定向次数
curl -L -w "Redirects: %{num_redirects}\n" -o /dev/null -s http://example.com

# 同时获取最终 URL、重定向次数和状态码
curl -L -w "\n最终URL: %{url_effective}\n重定向次数: %{num_redirects}\nHTTP状态: %{http_code}\n" \
     -o /dev/null -s http://example.com

用 -v 配合 grep 可以查看每一跳的 Location 头：

bash
curl -L -v http://example.com 2>&1 | grep -E "(< HTTP|< Location)"

跨域重定向与安全

cURL 在跨域重定向时的安全行为容易被忽视，也是面试加分项：

敏感头不自动转发。 当重定向到不同域名时，cURL 默认不会转发 Authorization、Cookie 等敏感请求头。这是安全设计——防止凭据意外泄露给第三方域名。

bash
# 跨域重定向时，Authorization 不会发给新域名
curl -L -H "Authorization: Bearer token123" http://api.example.com/old

# 显式允许转发敏感头（仅在信任目标域名时使用）
curl -L --location-trusted -H "Authorization: Bearer token123" \
     http://api.example.com/old

Cookie 的 SameSite 限制。 现代浏览器的 SameSite 策略会影响跨站重定向时的 Cookie 携带，但 cURL 作为命令行工具不受此限制。cURL 中 Cookie 的跨域行为完全由 -c（写入 cookie jar）和 -b（发送 cookie）参数控制：

bash
# 手动管理跨域重定向的 Cookie
curl -L -c cookies.txt -b cookies.txt -v http://example.com

限制重定向协议。 安全场景下，可以阻止 HTTP→HTTPS 之外的重定向，防止降级攻击：

bash
# 只允许重定向到 HTTPS
curl -L --proto-redir =https http://example.com

常见问题与排查

重定向循环。 服务端配置错误可能导致 A→B→A 的无限循环。用 --max-redirs 设置上限，观察 -v 输出中的循环跳转即可定位。

POST 数据丢失。 301/302 重定向后 POST 变 GET，请求体丢失。解决方案：使用 --post301/--post302，或让服务端返回 307/308。

HTTPS 证书错误导致重定向失败。 从 HTTP 重定向到 HTTPS 时，如果目标证书有问题会中断。开发环境可用 -k 跳过验证，生产环境必须修复证书。

bash
# 开发环境临时跳过 SSL 验证
curl -L -k https://example.com

实战：完整的重定向感知请求

将关键参数组合使用，构建一个对重定向行为完全可控的请求：

bash
curl -L --max-redirs 5 \
     --post302 \
     --proto-redir =https \
     -X POST \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer token123" \
     -d '{"action":"submit"}' \
     -w "\n最终URL: %{url_effective}\n重定向次数: %{num_redirects}\nHTTP状态: %{http_code}\n" \
     http://api.example.com/submit

这段命令同时控制了：跟随重定向（-L）、次数上限（--max-redirs 5）、POST 方法保持（--post302）、只允许重定向到 HTTPS（--proto-redir =https）、以及最终结果的格式化输出。

追问方向

• cURL 能处理 HTML meta 重定向或 JavaScript 重定向吗？ 不能。cURL 只处理 HTTP 层的 3xx 响应，不解析 HTML 也不执行 JS。
• --location-trusted 有什么安全风险？ 会将 Authorization 等敏感头转发给重定向目标域名，如果目标不可信（如开放重定向漏洞），凭据会被窃取。
• 重定向链中如何逐跳传递自定义头？ cURL 默认只对首次请求添加自定义头，重定向后的请求不保留。需要用 -H 配合 --location-trusted 或通过重定向后 URL 的路径判断手动处理。