Go 的 http.Client 默认 10 次重定向上限不可靠，因空 Location 会静默重试、307/308 可构造长链、循环跳转耗尽资源；应通过自定义 RoundTripper 安全捕获每跳 URL 和状态码，而非依赖 CheckRedirect。
为什么默认的 10 次重定向上限在大规模链路中不可靠
Go 的 http.Client 默认最多跳 10 次，看似宽松，但实际面对真实世界（尤其是 CDN、多层网关、灰度路由、A/B 测试平台）时，这个限制常被绕过或误判：比如中间某跳返回 302 + 空 Location，客户端会静默重试原 URL，算作一次跳转但没推进链路；又或者服务端用 307/308 配合动态路径拼接，人为构造长链。更危险的是，10 次不是硬隔离——若链路中存在循环（A → B → C → A），它可能在第 9 次才暴露，导致 CPU 和连接耗尽。
关键点在于：CheckRedirect 是唯一可控入口，但它的 via 参数只包含已发出的请求，不包含响应状态码和 body。你无法仅凭 req.URL 判断是否真发生了跳转，还是服务端在“假跳”。
- 别依赖
len(via) == 10做兜底——应主动记录每次跳转的req.URL.String()和上一跳的resp.StatusCode - 对同一域名连续出现 >3 次跳转，大概率是配置错误或攻击，建议直接
return http.ErrUseLastResponse - 若业务允许，把最大跳转数设为 5，并在日志里打标
"redirect_chain_too_long"，方便后续告警收敛
如何安全捕获每跳的 URL 和状态码
官方 CheckRedirect 函数拿不到状态码，因为响应体还没读。常见误区是试图在钩子里调 resp.Body.Read —— 这会消费 body，导致下游逻辑收不到数据。正确做法是：用自定义 RoundTripper 包裹标准 Transport，在 RoundTrip 返回后立即提取 resp.StatusCode 和 resp.Header.Get("Location")，再透传给原始 transport。
但注意：不要自己实现 RoundTripper 并忽略 CancelRequest（已弃用）或 context 取消逻辑。现代写法是复用 http.Transport，仅在其外层加一层拦截：
立即学习“go语言免费学习笔记（深入）”；
type LoggingTransport struct {
Base http.RoundTripper
}
func (t *LoggingTransport) RoundTrip(req *http.Request) (*http.Response, error) {
resp, err := t.Base.RoundTrip(req)
if err != nil {
return resp, err
}
// 此处可安全读 resp.StatusCode 和 Location 头
if resp.StatusCode >= 300 && resp.StatusCode < 400 {
log.Printf("Redirect hop: %s → %s (status %d)", req.URL, resp.Header.Get("Location"), resp.StatusCode)
}
return resp, nil
}
- 必须把日志或存储逻辑放在
return前，否则 resp.Body 可能被关闭 - 避免在
RoundTrip中做阻塞操作（如写 DB），可用 goroutine 异步提交，但需确保不引用已关闭的resp.Body - 如果需要完整链路（含所有中间响应头），得配合
CheckRedirect记录via，再用RoundTrip补全状态码——二者缺一不可
大规模链路下的 SSRF 与循环跳转防护
长跳转链天然放大 SSRF 风险：攻击者提交一个形如 https://attacker.com/→http://192.168.1.100/admin 的跳转链，若你的校验只检查首跳，后面几跳就失控了。同样，循环检测不能只比对 URL 字符串（http://a.com 和 https://a.com 是不同 host），而要归一化协议、host、path 后再哈希。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
推荐在 CheckRedirect 中做三件事：
- 提取
req.URL.Hostname()和req.URL.Scheme，白名单匹配（如只允许"example.com"和"api.example.com"） - 用
net.ParseIP(req.URL.Hostname())检查是否为内网地址（127.0.0.1、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、::1等） - 维护一个跳转 URL 的 SHA256 哈希集合，每次跳转前计算
req.URL.Scheme + "://" + req.URL.Host + req.URL.EscapedPath()的哈希，命中即终止
特别注意：req.URL.String() 可能带查询参数，而 SSRF 常藏在 ?url= 里，所以哈希必须基于归一化后的路径，而非原始字符串。
超时与资源泄漏必须端到端控制
默认 http.Client.Timeout 只控制单次请求，对重定向链无效——它会在第一次请求超时后就报错，根本不会走到第 2 跳。真正要控的是整条链的总耗时。可行方案是用 context.WithTimeout 包裹整个 client.Do() 调用，但前提是你的 CheckRedirect 和 RoundTripper 都尊重 context。
标准 http.Transport 支持 context 取消，但如果你用了自定义代理或 TLS 配置，务必确认：Transport.DialContext、Transport.TLSClientConfig、Transport.Proxy 都未屏蔽 cancel signal。一个典型坑是：代理 URL 写死为 "http://localhost:8080"，而该代理本身没配超时，结果整个链卡死。
- 永远显式设置
Transport.IdleConnTimeout和Transport.MaxIdleConnsPerHost，防止长链路占满连接池 - 对高并发场景，把
CheckRedirect函数做成无状态纯函数，避免闭包捕获大对象（如 logger 实例）导致内存无法释放 - 生产环境禁用
http.DefaultClient，每个业务线用独立 client 实例，便于按链路特征调参（如登录链路设 3 跳 + 5s 总超时，API 网关设 5 跳 + 15s）
大规模重定向链的核心矛盾从来不是“能不能跳”，而是“敢不敢信每一次跳”。URL 归一化、状态码补全、context 透传、哈希去重——这些不是可选项，是长链路存活的前提。漏掉任意一环，都可能让监控毛刺变成雪崩起点。
