Go语言处理重定向：http.CheckRedirect使用详解

Go语言中HTTP重定向看似便捷的自动处理实则暗藏SSRF、循环跳转和敏感信息泄露等严重风险，本文深入剖析`http.CheckRedirect`这一关键控制机制——它并非简单的开关，而是每次跳转前精准拦截的策略函数，通过返回`http.ErrUseLastResponse`可安全终止跳转并保留响应体，配合跳转次数限制、内网地址拦截、同域校验等细粒度逻辑，真正实现可控、健壮的重定向管理，同时强调必须同步配置超时与Transport以避免阻塞和性能隐患。

Go 的 http.Client 默认会自动重定向，但不安全

默认情况下，http.DefaultClient 会对 301/302/307/308 响应自动发起新请求，最多 10 次。这看似省心，实则埋雷：比如重定向到内网地址（SSRF）、循环跳转、或携带敏感头泄露凭证。

真正可控的做法是显式配置 CheckRedirect 函数，由你决定“要不要跳”“跳几次”“跳到哪儿”。它不是开关，而是拦截器 —— 每次准备跳转前都会被调用一次。

• CheckRedirect 是一个函数类型：func(req *http.Request, via []*http.Request) error
• req 是即将发出的重定向请求；via 是已发出的请求链（含原始请求），可用于判断跳转深度或路径
• 返回 nil 表示允许跳转；返回非 nil 错误（如 http.ErrUseLastResponse）则中断并返回当前响应

http.ErrUseLastResponse 是终止重定向最干净的方式

很多人直接 return errors.New("stop")，结果得到 net/http: invalid redirect policy 错误。这是 Go 的校验机制在报错 —— 它只接受特定错误值来表示“别跳了，就用上一次的响应”。

正确做法是返回 http.ErrUseLastResponse。它是个预定义变量，不是字符串，也不是自定义错误。

• 返回 http.ErrUseLastResponse：停止重定向，resp.Body 是最后一次重定向响应体（比如 302 的响应）
• 返回其他错误（如 fmt.Errorf("too many hops")）：整个请求失败，resp 为 nil
• 想保留原始请求头（如 Authorization）？默认不会透传。需手动复制：req.Header = via[0].Header.Clone()

常见重定向控制场景与写法

实际项目里，重定向逻辑往往不是“全开”或“全关”，而是按目标域名、跳转次数、状态码做细粒度判断。

• 限制最多 3 次跳转：if len(via) >= 3 { return http.ErrUseLastResponse }
• 禁止跳转到内网 IP：if strings.HasPrefix(req.URL.Host, "192.168.") || req.URL.Host == "localhost" { return http.ErrUseLastResponse }
• 只允许跳转到同一域名：if req.URL.Host != via[0].URL.Host { return http.ErrUseLastResponse }
• 对 307/308 保持方法不变，但对 301/302 强制转 GET（标准行为），无需额外处理 —— Go 默认已遵循 RFC

自定义 http.Client 时别漏掉 Timeout 和 Transport

CheckRedirect 只管跳不跳，不管连不连得上、等不等得及。如果重定向链里某个中间地址响应极慢，整个请求就会卡住，直到超时（默认无超时）。

• 必须设置 Timeout（如 30 * time.Second），否则可能永久阻塞
• 若需复用连接、控制 TLS、加代理，记得配 Transport；否则会 fallback 到 http.DefaultTransport，而它的 MaxIdleConns 等参数可能不符合高并发预期
• 别把 CheckRedirect 写成闭包却意外捕获了大对象（比如整个数据库连接池），容易引发内存泄漏

重定向逻辑看着简单，但 via 切片里藏着完整请求链，req.URL 在每次回调里都已是下一个目标地址 —— 这两点最容易看反，一写错就绕进死循环或者放行恶意跳转。

好了，本文到此结束，带大家了解了《Go语言处理重定向：http.CheckRedirect使用详解》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！