Go正向代理必须显式处理CONNECT方法，因为它是HTTPS隧道建立的唯一方式，不走HTTP解析流程而直接透传TCP流；http.ServeHTTP默认对CONNECT返回405，导致ERR_TUNNEL_CONNECTION_FAILED。
Go 正向代理为什么必须显式处理 CONNECT 方法
因为 CONNECT 是 HTTPS 建立隧道的唯一方式，它不走 HTTP 报文解析流程，而是直接透传原始 TCP 流。Go 的 http.ServeHTTP 默认只处理 GET/POST 等标准方法，遇到 CONNECT 会直接返回 405，导致浏览器无法建立 TLS 隧道——你看到的“ERR_TUNNEL_CONNECTION_FAILED”基本都源于此。
关键点在于：不能把 CONNECT 当作普通请求交给 http.Transport 转发；必须自己建立上游 TCP 连接，然后双向拷贝字节流。
- 浏览器发起
CONNECT example.com:443 HTTP/1.1，代理需解析 Host 和端口 - 代理主动向
example.com:443拨号（用net.Dial，不是http.Transport） - 拨号成功后，先给客户端返回
HTTP/1.1 200 Connection Established（注意换行和空行） - 之后调用
io.Copy双向转发clientConn↔upstreamConn
如何安全地实现 CONNECT 隧道并避免阻塞
最常见错误是直接在 handler 里写 io.Copy，这会导致 goroutine 永久阻塞、连接无法释放。必须用两个并发的 io.Copy 并加超时控制，否则一个方向卡死，整个隧道就挂了。
还要注意：io.Copy 不会自动关闭连接，必须确保任意一端断开时，另一端也立即关闭。
立即学习“go语言免费学习笔记（深入）”；
- 使用
context.WithTimeout控制拨号和拷贝时间（例如 10 秒） - 用
sync.WaitGroup或errgroup.Group同步两个io.Copy的完成 - 在
defer中显式关闭upstreamConn，防止 fd 泄漏 - 不要忽略
io.Copy的返回 err —— 它可能来自读端 EOF 或写端 broken pipe
func handleConnect(w http.ResponseWriter, r *http.Request) {
conn, _, err := w.(http.Hijacker).Hijack()
if err != nil { return }
defer conn.Close()
upstream, err := net.DialTimeout("tcp", r.Host, 10*time.Second)
if err != nil {
http.Error(w, "Upstream dial failed", http.StatusServiceUnavailable)
return
}
defer upstream.Close()
// 发送 200 OK
fmt.Fprintf(conn, "HTTP/1.1 200 Connection Established\r\n\r\n")
// 双向拷贝，带 cancel 控制
ctx, cancel := context.WithCancel(context.Background())
defer cancel()
var wg sync.WaitGroup
wg.Add(2)
go func() { io.Copy(upstream, conn); wg.Done() }()
go func() { io.Copy(conn, upstream); wg.Done() }()
wg.Wait()
}
为什么 http.Transport 不能直接用于 CONNECT 转发
因为 http.Transport 的 RoundTrip 接口只接受 *http.Request，而 CONNECT 请求体为空、没有标准 header 解析上下文，且后续流量是 raw TCP，不是 HTTP 报文。强行塞进去会 panic 或静默失败。
更隐蔽的问题是：即使你 hack 出一个伪造的 *http.Request，Transport 内部仍会尝试做 HTTP/2 协商、gzip 解包、header 重写等动作，彻底破坏 TLS 握手数据流。
-
Transport设计目标是「发 HTTP 请求 → 收 HTTP 响应」，不是「建 TCP 隧道」 - 所有基于
http.DefaultTransport的代理库（如goproxy）都得在CONNECT上单独分支处理 - 如果你需要复用连接池或 TLS 配置，应提取
net.DialContext和tls.Config到自定义拨号器，而不是复用Transport
真实场景下必须检查的三个边界条件
本地测试通不代表线上可用。HTTPS 代理在生产环境常因这几个点失败：
-
r.Host可能含端口（如example.com:443），但某些客户端会省略端口，需 fallback 到默认 443；而 HTTP 代理对 80 端口也要兼容 - 客户端可能发送
Proxy-Authorizationheader，若代理要求鉴权，需在CONNECT前校验，否则隧道建立后无法拦截 - 某些 CDN 或企业防火墙会主动 reset
CONNECT后的长连接，需在io.Copy外层加心跳检测（比如每 30 秒发一个空字节）
这些细节不写进日志，问题就很难定位。建议在 handleConnect 开头打一条结构化日志：connect to %s from %s，包含 r.Host 和 r.RemoteAddr。
