HTTP重定向丢失自定义Header怎么办

Go 里遇到“HTTP 重定向后自定义 Header 不见了”，先不要直接给每一跳都强行补 Header。http.Client 默认会从初始请求复制普通 Header；真正容易出问题的是使用了不能设置 Header 的 http.Get、在 CheckRedirect 中覆盖了即将发送的请求、跳到了不可信主机，或把 301/302/303 后的 GET 误认为原来的请求。

最稳妥的处理顺序是：用 NewRequest 创建请求，记录每一跳的 URL 和状态码；普通业务 Header 让 Client 自动复制或在 CheckRedirect 的 req 上显式补齐；涉及跨主机的认证 Header 时停止自动跟随，校验 Location 后再按白名单重建请求。

先看清：丢的是哪一跳的 Header

一次重定向至少有“原始请求、3xx 响应、下一跳请求、最终响应”四个对象。服务端在 301 或 302 响应里看不到下一跳 Header 并不代表 Go 丢了它；只有在接收第二次请求的服务端确认 Header 不存在，才说明需要检查客户端复制策略。

另一个常见误区是直接调用 http.Get(url)。它内部使用默认客户端，无法在调用点设置自定义 Header。需要 Header 时，应显式创建 Request，再交给 Client.Do。

req, err := http.NewRequest(http.MethodGet, "https://api.example.test/start", nil)
if err != nil {
    return err
}
// X-Trace-ID 是业务链路标识，允许在受信任的重定向目标之间传递。
req.Header.Set("X-Trace-ID", traceID)
// 用 Client.Do 而不是 http.Get，才能控制 Header 和重定向策略。
resp, err := client.Do(req)
if err != nil {
    return err
}
// 读取完成后关闭响应体，避免影响 Transport 的连接复用。
defer resp.Body.Close()

默认复制 Header，但安全边界会改变结果

Go 官方 net/http 文档的规则是：跟随重定向时复制初始 Request 的 Header，但对不可信目标不会继续携带 Authorization、WWW-Authenticate、Cookie 等敏感 Header。普通的 X-Trace-ID、X-Request-Mode 一类 Header 通常会被复制，因此看到它们消失时，应优先排查自己的回调或中间层。

CheckRedirect 里的 req 是即将发送的下一跳请求，via 是已经发出的请求列表。若项目中的回调重新赋值了 req.Header，或者只从某个中间请求读取 Header，就可能把自动复制的值覆盖掉。显式处理时只恢复业务白名单：

client := &http.Client{
    CheckRedirect: func(next *http.Request, via []*http.Request) error {
        if len(via) == 0 {
            return nil
        }
        // next 是将要发送的请求；只补业务 Header，不复制整套凭据。
        traceID := via[0].Header.Get("X-Trace-ID")
        if traceID != "" {
            next.Header.Set("X-Trace-ID", traceID)
        }
        // 跨主机时不要把 Authorization 盲目带到新域名。
        if next.URL.Host != via[0].URL.Host {
            next.Header.Del("Authorization")
        }
        return nil
    },
}
_ = client

状态码变化也会让你误判 Header 丢失

301、302、303 默认可能把后续请求改为 GET，并移除与请求体相关的 Header；如果原请求是 POST，接收方看到的已经不是同一个方法和 body。307、308 则在 Request.GetBody 可用时保留原方法与请求体。于是排查时要同时记录方法、URL、状态码和 Header，不能只盯着 Header。

当认证凭据不能跨域、或者业务必须确认每个跳转目标时，可以让 Client 停在第一份 3xx 响应：

client := &http.Client{
    CheckRedirect: func(next *http.Request, via []*http.Request) error {
        // 保留 3xx 响应，调用方自行检查 Location 和目标主机。
        return http.ErrUseLastResponse
    },
}
resp, err := client.Do(req)
if err != nil {
    return err
}
defer resp.Body.Close()
if resp.StatusCode >= 300 && resp.StatusCode 

手动重建时不要把原始 Header 整体复制到陌生域名。把 X-Trace-ID、幂等键等明确允许的业务 Header 逐项设置；把 Authorization 重新绑定到经过校验的目标，必要时重新创建请求体，避免复用已读完的流。

高压场景下的排查与取舍

如果同一接口在流量升高后才出现问题，优先把排查分成三层：第一层看是否创建了统一的可复用 Client，第二层看 CheckRedirect 是否有共享状态或覆盖 Header 的逻辑，第三层看网关是否返回了跨主机 Location。不要用 Transport 全局注入认证 Header 来“修复”重定向，这会让所有目标共享凭据边界。

可以保留一条不含敏感值的诊断记录：原始 URL、下一跳 URL、状态码、请求方法、是否同主机以及业务 Header 是否存在。这样既能定位是 Go 的默认策略、业务回调还是服务端路由变化，也不会把 Token 写进日志。

常见问题

为什么 http.Get 不能带自定义 Header？

它是便捷封装，没有暴露 Request；需要自定义 Header 时使用 NewRequest 和 Client.Do。

跨域重定向能不能强行保留 Authorization？

不建议。除非目标主机经过明确白名单校验，否则应停止自动跟随并按目标重新获取或绑定凭据。

CheckRedirect 应该改 req 还是 via？

要影响下一跳就改 req；via 只是已发出的请求记录，修改它不会改变已经发送的网络请求。

归根结底，普通自定义 Header 的“丢失”通常不是重定向机制的默认行为，而是请求入口、回调覆盖、安全清理和方法变化共同造成的误判。先把跳转链路拆开，再决定自动复制、白名单补齐还是手动跟随，才能修复问题而不扩大凭据泄露面。