Go http.Transport.OnProxyConnectResponse 怎样判断代理 CONNECT 是否成功

我第一次给 Go 的 HTTPS 代理请求加诊断时，最容易误判的一点是：OnProxyConnectResponse 被调用，或者回调返回 nil，都不等于 CONNECT 隧道已经成功。这个回调拿到的是代理对 CONNECT 请求的响应，发生在 Transport 检查 200 OK 之前；真正的连接还可能继续经历 TLS 握手和上层请求。

官方文档：https://pkg.go.dev/net/http#Transport.OnProxyConnectResponse

判断代理 CONNECT 是否成功时，先在回调里观察 connectRes.StatusCode，但最终以 Transport 的 200 OK 检查和后续请求结果为准。回调返回错误只表示这次请求应立即失败，不是把响应改成成功。

回调到底发生在 CONNECT 的哪一刻

对 HTTPS 目标使用 HTTP 代理时，Transport 先向代理发送 CONNECT，请求里包含目标主机和端口。代理返回响应后，标准库才调用 OnProxyConnectResponse。因此回调适合做观测、策略判断和错误补充，但不能把它理解为“隧道已可用”的通知。

当前标准库实现会先调用回调；如果回调返回错误，请求立即失败并关闭连接。只有回调没有返回错误，Transport 才继续检查响应状态；源码中的成功条件是状态码为 200。即使这一关通过，HTTPS 目标还要进行 TLS 握手，握手失败时，最终的 Client.Do 仍然会返回错误。

回调里应该看哪些字段

我通常只保留四类诊断信息：代理的 Host、CONNECT 的目标主机、响应状态码和状态文本。代理 URL 可能包含认证信息，日志中不要直接打印完整 URL；请求头也不应为了排错全部输出。

用返回 error 的策略提前终止异常代理

如果项目只允许固定代理，或者希望把代理返回的状态统一成更易检索的错误，可以在回调里返回自定义错误。这个错误会让当前请求失败；它不会修改 connectRes，也不会绕过 Transport 后面的状态检查。

package main

import (
    "context"
    "errors"
    "fmt"
    "log"
    "net/http"
    "net/url"
)

func newClient(proxyURL *url.URL) *http.Client {
    transport := &http.Transport{
        Proxy: http.ProxyURL(proxyURL),
        OnProxyConnectResponse: func(ctx context.Context, proxyURL *url.URL, connectReq *http.Request, connectRes *http.Response) error {
            target := ""
            if connectReq != nil && connectReq.URL != nil {
                target = connectReq.URL.Host
            }

            // 只记录代理主机、目标主机和状态，不打印认证信息或完整请求头。
            proxyHost := ""
            if proxyURL != nil {
                proxyHost = proxyURL.Host
            }
            if connectRes == nil {
                return errors.New("proxy CONNECT response is nil")
            }
            log.Printf("proxy_connect proxy=%s target=%s status=%d text=%q",
                proxyHost, target, connectRes.StatusCode, connectRes.Status)

            // 这里的错误用于补充业务语义，Transport 仍会检查 200 OK。
            if connectRes.StatusCode != http.StatusOK {
                return fmt.Errorf("proxy CONNECT rejected: %s", connectRes.Status)
            }
            return nil
        },
    }
    return &http.Client{Transport: transport}
}

这段回调的关键不是“自己实现 CONNECT”，而是把诊断点放在标准库已经读到响应之后。对于非 200 响应，返回错误可以让日志包含统一前缀；对于 200，返回 nil 只代表回调接受该响应，不能代替后续握手。

为什么看到 200 仍然可能请求失败

排查时我会把错误分成三层：第一层是代理没有返回可接受的 CONNECT 响应；第二层是 CONNECT 通过后，目标 TLS 握手失败；第三层是握手完成后，目标服务器返回了 HTTP 错误或读取响应体失败。回调只能直接观察第一层，不能把三层错误混在一个“代理成功”日志里。

resp, err := newClient(proxyURL).Get("https://example.com/")
if err != nil {
    // 这里的错误可能来自代理、TLS 握手或请求建立阶段，不能只看回调日志。
    log.Printf("request failed: %v", err)
    return
}
defer resp.Body.Close() // 读取完响应后关闭 Body，便于连接复用。
log.Printf("request completed status=%s", resp.Status)

如果回调记录的是 status=200，但最终 Get 失败，应继续查看返回错误是否属于 TLS 或目标连接，而不是重复改写回调判断。若代理响应不是 200，优先检查代理地址、认证头、目标主机和代理策略；认证头可通过 ProxyConnectHeader 或 GetProxyConnectHeader 提供，但不要把它写进日志。

常见问题

回调返回 nil 后，是否就能认为代理连接成功？

不能。它只表示回调没有主动终止请求；Transport 还会检查 200，HTTPS 请求还可能失败在 TLS 握手或后续读取阶段。

为什么回调里不应该直接打印 proxyURL.String？

代理 URL 可能带有 Userinfo，直接打印会把认证信息带进日志。通常记录 proxyURL.Host 就足够定位代理节点。

非 200 响应应该只依赖回调判断吗？

不应该。回调可以补充更清晰的错误，但最终失败语义仍由 Transport 的 200 检查决定；业务代码还要处理 Client.Do 返回的最终错误。