Go 跟随重定向后 Authorization 为什么消失

调用 Go 的 http.Client 访问接口时，如果第一跳返回 301、302 或 307，调试日志里常会出现一个反直觉现象：原始请求明明带着 Authorization，跟随重定向后的请求却没有。通常这不是请求头被网络“吃掉”，而是客户端在生成下一跳请求时主动保护敏感信息。

Go 默认不会把 Authorization 无条件转发给新的域名。重定向到原主机或其子域名时通常会保留，跨到不可信域名时会被忽略；需要改变行为，应在 CheckRedirect 中写清允许的目标和错误返回，而不是盲目复制上一跳的全部请求头。

先把重定向拆成两次请求看

排查时不要只打印最终响应。一次调用至少包含原始请求、重定向响应和下一跳请求三个观察点。Authorization 属于客户端发送的请求头，服务器返回的 Location 只负责告诉客户端下一步去哪，并不会自动把认证头“传回”给新请求。

下面的辅助函数只记录请求链，不连接外部服务。把它放进自测或日志钩子中，重点看 req.URL.Host 是否越过了信任边界：

func logRedirect(req *http.Request, via []*http.Request) error {
    // req 是准备发送的下一跳，via 的最后一项是上一跳请求。
    previousHost := ""
    if len(via) > 0 {
        previousHost = via[len(via)-1].URL.Host
    }
    log.Printf("redirect previous=%s next=%s auth=%t",
        previousHost,
        req.URL.Host,
        req.Header.Get("Authorization") != "") // 只记录是否存在，不打印凭据。
    return nil
}

如果上一跳的 auth=true、下一跳变成 false，同时目标 Host 已变化，基本可以把问题定位到 net/http.Client 的敏感头转发规则。若 Host 没变却仍为空，再检查是否在自定义 CheckRedirect、RoundTripper 或中间件里重建了请求。

默认规则为什么会移除 Authorization

http.Client 的默认策略会跟随常见的 301、302、303、307 和 308。对于 Authorization、WWW-Authenticate、Cookie 这类敏感头，Go 会判断新目标是否仍属于原请求的可信范围。原主机和子域名通常属于可转发范围，完全不同的域名则不会继续带上这些头。

这里有一个容易混淆的点：重定向是否继续和请求头是否转发是两件事。CheckRedirect 返回 nil 只表示允许继续，并不承诺敏感头一定存在；而 301/302/303 还可能把方法改为 GET，307/308 才在满足条件时保留原方法和请求体。

用 CheckRedirect 固定信任边界

如果业务确实需要在同一认证域内继续携带凭据，建议只对白名单目标补回 Authorization。示例把原始 API 主机写死为 api.example.com，跨域时返回 http.ErrUseLastResponse，让调用方拿到 3xx 响应自行处理：

client := &http.Client{
    CheckRedirect: func(req *http.Request, via []*http.Request) error {
        if len(via) == 0 {
            return nil
        }
        previous := via[len(via)-1]
        sameTrustedHost := req.URL.Scheme == "https" &&
            req.URL.Host == "api.example.com" &&
            previous.URL.Host == "api.example.com"
        if !sameTrustedHost {
            // 不把凭据送到未经允许的目标，保留重定向响应给上层判断。
            return http.ErrUseLastResponse
        }
        if value := previous.Header.Get("Authorization"); value != "" {
            // 只恢复明确允许的认证头，不复制 Cookie 等其他敏感头。
            req.Header.Set("Authorization", value)
        }
        return nil
    },
}

生产代码中应把允许列表放进配置，并比较规范化后的 scheme、hostname 和端口；不要用“包含字符串”判断域名，例如 api.example.com.attacker.test 不应被当成可信子域。若认证系统会为新 Host 签发新令牌，更稳妥的做法是停止自动跟随，在业务层完成一次明确的重新认证。

错误返回和方法变化要一起核对

当 CheckRedirect 返回 http.ErrUseLastResponse 时，客户端不会发送下一跳请求，而是把最近的重定向响应交给调用方，响应体保持未关闭。调用方应读取 Location、记录状态码并关闭响应体；不要把这个结果误判成“接口返回 401”。如果返回其他错误，通常会得到包装后的 *url.Error，可以用 errors.Is 或类型断言判断原因。

另外，301、302、303 的下一跳通常改成 GET；307、308 尝试保留原方法和请求体。即使 Authorization 被正确补回，POST 重定向后的方法变化也可能让服务端表现为未认证或参数缺失。因此验证时至少记录方法、目标 Host、状态码和是否发送凭据这四项。

常见问题

为什么服务端返回 302 后，Go 没有报错？

非 2xx 状态本身不会让 Client.Do 返回错误；只要重定向策略允许，客户端会继续请求。要观察 302，应主动停止自动跟随或在 CheckRedirect 中记录链路。

把上一跳所有 Header 复制到下一跳可以吗？

不建议。Cookie、Authorization 等头都可能跨越新的信任边界，复制全部 Header 还会带来 Host、Content-Length 等不应手工迁移的字段。只对明确允许的认证头做最小复制。

同域名仍然丢失 Authorization 怎么查？

先确认比较的是规范化后的 Host 和端口，再检查自定义 CheckRedirect 是否重建了 Header、RoundTripper 是否替换请求，以及是否是 301/302/303 改方法后触发了服务端另一套认证路径。