当前位置：首页 > 文章列表 > Golang > Go问答 > Go http.Client 的 CheckRedirect 为什么会丢失请求：重定向策略、Header 继承与错误返回

Go http.Client 的 CheckRedirect 为什么会丢失请求：重定向策略、Header 继承与错误返回

来源：17golang原创 2026-08-30 00:24:21 0浏览收藏

线上接口明明返回了 302，Go 调用方却只拿到一个“请求失败”的错误，日志里还看不到最终 URL。这个现象通常不是请求凭空消失，而是 http.Client 在自动跟随重定向时进入了 CheckRedirect，回调的返回值又改变了最终响应和错误的组合。

先记录每次回调里的 req.URL，再明确 CheckRedirect 是放行、停止并保留最后响应，还是返回真正的错误；不要只根据一条 url.Error 日志判断请求丢失。

要点速览

自动重定向时，CheckRedirect 会收到即将发出的新请求。
返回 http.ErrUseLastResponse 表示停止跟随并保留最后一个响应，而不是把它当普通网络错误。
返回其他非空错误时，客户端通常会把重定向链包装成 url.Error；是否能读到响应要看具体返回路径。
排查时要同时记录 req.URL、Location、响应状态和最终错误。

先确认重定向到底走到了哪一步

先不要急着改成“禁止重定向”。准备一个只返回 302 的测试服务，回调里记录新请求的 URL，最后让目标地址返回 200。这样能把“服务端发了跳转”和“客户端是否继续发请求”拆开观察。

func TestRedirectChain(t *testing.T) {
    var seen []string
    server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        switch r.URL.Path {
        case "/start":
            http.Redirect(w, r, "/finish", http.StatusFound)
        case "/finish":
            w.WriteHeader(http.StatusOK)
            _, _ = w.Write([]byte("done"))
        }
    }))
    defer server.Close()

    client := &http.Client{
        CheckRedirect: func(req *http.Request, via []*http.Request) error {
            seen = append(seen, req.URL.String())
            return nil
        },
    }
    resp, err := client.Get(server.URL + "/start")
    if err != nil {
        t.Fatal(err)
    }
    defer resp.Body.Close()
    if resp.StatusCode != http.StatusOK || len(seen) != 1 {
        t.Fatalf("status=%d seen=%v", resp.StatusCode, seen)
    }
}

这里的关键证据是 seen 里出现了 /finish，并且最终响应是 200。也就是说，请求并没有丢；它只是经历了一个由 http.Client 自动调度的第二跳。

Go http.Client 进入 CheckRedirect 检查 req.URL 并选择继续或返回 ErrUseLastResponse 的重定向链

用回调返回值区分停止跟随和真正报错

最容易混淆的是回调里返回一个普通错误。普通错误会让调用方得到错误结果；如果只是想拿到 302 本身，应返回 http.ErrUseLastResponse。它的语义是停止继续跟随，并把当前最后响应交给调用方处理。

client := &http.Client{
    CheckRedirect: func(req *http.Request, via []*http.Request) error {
        if req.URL.Path == "/finish" {
            return http.ErrUseLastResponse
        }
        return nil
    },
}

resp, err := client.Get(server.URL + "/start")
if err != nil {
    // 普通错误会进入这里；ErrUseLastResponse 不应按普通失败处理。
    return err
}
defer resp.Body.Close()
if resp.StatusCode == http.StatusFound {
    location := resp.Header.Get("Location")
    _ = location
}

验收时看两项：err 是否为空，以及 resp.StatusCode 是否仍是 302。若把 ErrUseLastResponse 换成 fmt.Errorf("stop")，日志里的错误就会让人误以为目标请求失败，这正是“丢失请求”的错觉来源。

Go CheckRedirect 返回 ErrUseLastResponse 后由 http.Client 保留最后响应而不是进入普通错误路径

再检查 Header 为什么看起来没有继承

重定向请求不是把上一份 *http.Request 原样复制一遍。Go 会根据重定向目标和请求方法处理部分头字段；敏感头、跨主机跳转以及自定义覆盖逻辑都不能靠猜。排查时在 CheckRedirect 里打印目标主机和需要确认的 Header 名称，注意不要打印令牌值。

client := &http.Client{
    CheckRedirect: func(req *http.Request, via []*http.Request) error {
        if len(via) == 0 {
            return nil
        }
        if req.URL.Host != via[0].URL.Host {
            req.Header.Del("Authorization")
        }
        return nil
    },
}

如果业务确实需要把某个非敏感头带到同一主机的跳转请求，应该在这个回调里按主机和协议做白名单判断，而不是无条件复制全部头。尤其是跨域重定向，保守地删除凭据类 Header 更安全。