Go net/http 客户端跟随重定向时怎么保留必要请求头

Go 的 http.Client 会自动处理重定向，但“自动跟随”不等于“无条件复制所有请求头”。普通 Header 通常从初始请求带到后续请求；Authorization、Cookie 等敏感头遇到不可信目标会被保护。要保留必要请求头，做法是把目标主机列入明确的允许范围，在 CheckRedirect 中检查 req.URL 后，再为即将发送的请求补回需要的 Header。

最稳妥的规则是：普通业务 Header 交给客户端默认复制；令牌类 Header 不从旧请求“抄回来”，而是只对经过 HTTPS 和主机白名单校验的目标重新设置。Cookie 则优先交给 Cookie Jar 管理。

这能同时解决“重定向后接口返回未登录”和“令牌被转发到错误域名”两类问题。

默认复制规则：哪些 Header 会被带上

重定向前，CheckRedirect 收到的 req 是下一跳请求，via 保存已经发出的请求，顺序是从旧到新。Go 会从最初的 Request 复制请求头，但会单独处理敏感字段。跳到同一域名或其子域时，Authorization、WWW-Authenticate、Cookie 等可能继续保留；跳到不相关域名时，敏感头会被移除。普通的 X-Trace-ID、Accept 等业务头则通常会继续复制。

这里不要把“同域”理解成“同源安全策略已经替你完成”。Go 的客户端重定向行为与浏览器 Fetch 标准并不完全相同，同一主机换协议或跳到子域时，敏感头可能仍被保留。生产代码应按自己的信任边界决定是否允许，而不是只依赖默认行为。

在 CheckRedirect 中恢复必要 Header

如果业务确实允许从 api.example.com 跳到 files.api.example.com，可以把令牌放在闭包变量中，并在回调里重新设置。这样做的好处是：即使 Go 为跨域安全移除了旧的 Authorization，你仍能在目标通过校验后恢复它；而不可信目标会直接停止跟随。

package main

import (
    "errors"
    "net/http"
    "strings"
)

func trustedHost(host string) bool {
    // 点号边界避免把 api.example.com.evil.test 误判为可信子域。
    return host == "api.example.com" || strings.HasSuffix(host, ".api.example.com")
}

func newClient(token string) *http.Client {
    return &http.Client{
        CheckRedirect: func(req *http.Request, via []*http.Request) error {
            // 只允许 HTTPS 的明确可信目标，避免令牌跟到外部站点。
            if req.URL.Scheme != "https" || !trustedHost(req.URL.Hostname()) {
                return http.ErrUseLastResponse
            }
            if len(via) >= 5 {
                // 限制业务允许的连续跳转次数，避免异常跳转链。
                return errors.New("redirect chain is too long")
            }

            // 只在目标通过校验后恢复必要 Header。
            req.Header.Set("Authorization", "Bearer "+token)
            req.Header.Set("X-Client-Mode", "download")
            return nil
        },
    }
}

回调里的 req.Header 只影响这一跳即将发送的请求；via 不应被修改。示例把自定义 Header 与令牌放在同一个信任判断之后，避免只恢复业务头却漏掉安全边界。若跳转目标不可信，ErrUseLastResponse 会返回最近一次响应而不继续发送下一请求；如果希望把它视为业务错误，也可以返回自定义 error。

Cookie 交给 Cookie Jar，不要在回调里硬拷贝

登录态 Cookie 与令牌 Header 的处理方式不同。创建 cookiejar.Jar 后，Client 会在每次重定向前后咨询 Jar，并用响应中的 Set-Cookie 更新状态。手工写死 req.Header.Set("Cookie", ...) 容易忽略域名、路径和服务端更新。

jar, err := cookiejar.New(nil)
if err != nil {
    // 初始化失败时不要继续发送可能缺少会话保护的请求。
    return err
}

client := &http.Client{
    Jar: jar,
    CheckRedirect: func(req *http.Request, via []*http.Request) error {
        // Cookie 由 Jar 按目标地址决定；这里只校验跳转范围。
        if req.URL.Scheme != "https" || !trustedHost(req.URL.Hostname()) {
            return http.ErrUseLastResponse
        }
        return nil
    },
}

如果没有设置 Jar，初始请求中显式写入的 Cookie 会按客户端规则继续处理，但客户端不会替你维护后续响应的 Cookie 状态。需要会话连续性时，Jar 通常比保存一串 Cookie 字符串更可靠。

别只看 Header：重定向状态码还会改变请求语义

301、302、303 在允许跟随后，通常会把后续请求改成 GET（原请求为 HEAD 时保持 HEAD），并移除请求体；与请求体相关的 Content-Type 等 Header 也可能失去意义。307、308 则保留原方法和请求体，但前提是 Request.GetBody 可用，http.NewRequest 对常见的 bytes.Buffer、bytes.Reader 和 strings.Reader 会自动设置它。

因此排查“重定向后 Header 不见了”时，先记录目标 URL、方法、状态码和 len(via)，再判断是敏感头被保护、Cookie Jar 更新，还是 301/302/303 已经把 POST 变成了 GET。恢复 Authorization 并不能让一个没有可重放 Body 的 307 请求变得可重放。

常见问题

为什么自定义 Header 还在，Authorization 却没了？
普通 Header 通常会复制，Authorization 属于敏感头；目标域名不满足 Go 的安全转发条件时，它会被移除。使用白名单和 CheckRedirect 在可信目标上重新设置。

能不能在每次 CheckRedirect 里无条件设置 Bearer Token？
不建议。无条件恢复会把凭据带到恶意或配置错误的跳转目标，至少要同时校验 HTTPS、精确主机或带点号边界的可信子域。

为什么 POST 重定向后服务端收到了 GET？
301、302、303 的客户端重定向语义通常会改用 GET；需要保留方法和请求体时，应确认服务端使用 307 或 308，并确保请求具备可用的 GetBody。

资料来源

• Go net/http 包文档：Client.Do、CheckRedirect、Cookie Jar 与状态码行为。
• Go net/http/client.go 源码：初始 Header 复制和敏感 Header 处理。