Go 的 http.Client 默认会自动跟随重定向，但不会在跳转后的请求中保留 Authorization 头（包括 Basic Auth），导致 HTTPS 重定向后返回 401 而非预期的 301 或成功响应。
go 的 `http.client` 默认会自动跟随重定向，但不会在跳转后的请求中保留 `authorization` 头（包括 basic auth），导致 https 重定向后返回 401 而非预期的 301 或成功响应。
在 Go 中使用 http.Client 发起带 Basic Auth 的 HTTP 请求时，若目标服务（如 http://aerolith.org/files）返回 301 重定向至 HTTPS 地址（如 https://aerolith.org/files），客户端会自动跟进该跳转；而第二次跳转（如到 https://aerolith.org/files/）后，原始请求中通过 req.SetBasicAuth() 设置的 Authorization 请求头不会被自动携带到后续重定向请求中——这是 Go 标准库的明确安全策略：为防止凭据意外泄露至第三方域名或非加密通道，net/http 在重定向时默认清空敏感头（如 Authorization, Cookie 等）。
这与 curl 行为有本质区别：curl --user user:pass 默认不自动跟随重定向（除非显式加 -L），因此你看到的是首次响应的 301；而 Go 的 http.Client 默认启用重定向（CheckRedirect 使用 defaultCheckRedirect），且不传递认证头，最终抵达终端 URL 时因缺失凭证返回 401。
✅ 正确解决方案
方案一：在 CheckRedirect 中手动恢复 Basic Auth（推荐）
适用于需自动跟随重定向并保持认证的场景：
package main
import (
"errors"
"log"
"net/http"
)
func main() {
url := "http://aerolith.org/files"
username := "cesar"
password := "password"
req, err := http.NewRequest("GET", url, nil)
if err != nil {
log.Fatal("failed to create request:", err)
}
// 初始设置 Basic Auth（对首请求有效）
req.SetBasicAuth(username, password)
client := &http.Client{
CheckRedirect: func(req *http.Request, via []*http.Request) error {
// 防止无限重定向
if len(via) >= 10 {
return errors.New("stopped after 10 redirects")
}
// 关键：为每个重定向请求重新设置 Basic Auth
req.SetBasicAuth(username, password)
return nil
},
}
resp, err := client.Do(req)
if err != nil {
log.Fatal("request failed:", err)
}
defer resp.Body.Close()
log.Printf("Final status code: %d", resp.StatusCode) // 应输出 200
}⚠️ 注意：req.SetBasicAuth() 在 CheckRedirect 回调中调用是安全的，它会覆盖当前重定向请求的 Authorization 头，且仅作用于即将发出的下一次请求。
方案二：禁用自动重定向，手动控制跳转（类 cURL 行为）
若只需获取首次响应（如调试重定向链），可绕过 Client，直接使用 http.Transport：
resp, err := http.DefaultTransport.RoundTrip(req)
if err != nil {
log.Fatal(err)
}
log.Printf("First response status: %d", resp.StatusCode) // 输出 301方案三：用自定义 CheckRedirect 拦截跳转（模拟无重定向）
若需 Client 接口但禁止跳转，可返回特定错误并捕获：
redirectBlocked := errors.New("redirect blocked")
client := &http.Client{
CheckRedirect: func(req *http.Request, via []*http.Request) error {
return redirectBlocked
},
}
resp, err := client.Do(req)
if urlErr, ok := err.(*url.Error); ok && urlErr.Err == redirectBlocked {
// 成功拦截：resp 即为首次 301 响应
log.Printf("Intercepted redirect, status: %d", resp.StatusCode)
} else if err != nil {
log.Fatal(err)
}? 关键总结
- Go 的 http.Client 不会跨重定向传播 Authorization 头，这是设计使然，非 bug；
- curl 默认不跳转 → 显示 301；Go 默认跳转 → 最终请求无认证 → 返回 401；
- 生产环境推荐 方案一（CheckRedirect 中重设认证），兼顾安全性与可用性；
- 所有重定向操作均发生在客户端内存中，敏感凭据不会持久化或日志明文输出（前提是代码未主动打印 req.Header）；
- 若重定向涉及跨域（如 http://→https://other-domain.com），即使手动设置 Authorization，也需服务端明确允许（CORS Access-Control-Allow-Headers: Authorization），否则浏览器环境会失败（本例为纯 Go 后端，不受此限）。
通过合理配置 CheckRedirect，即可让 Go HTTP 客户端在保持自动重定向能力的同时，安全、可靠地完成带认证的跨协议跳转。
