本文详解 go 反向代理场景下连接复用的常见误区,强调“连接不可复用”原则,并提供基于 `io.copy` 与优雅关闭的健壮代理实现方案。
在构建 NAT 穿透或反向代理服务(如远程终端、SOCKS 中继)时,一个典型模式是:一台内网设备主动连接公网中转服务器(建立 dstNet 连接),外部客户端再连接该服务器另一端口(srcNet),由服务器桥接二者流量。此时,开发者常误以为可“复用”已断开的内网连接(例
如等待其重连后继续写入),但这是根本性错误——TCP 连接一旦发生非临时性错误(如对端崩溃、网络中断、RST 包、超时关闭),其底层状态即不可预测,任何尝试向已关闭或半关闭的 net.Conn 写入数据,都会触发 "use of closed network connection" 或零字节拷贝(如 [DEBUG] socks: Copied 0 bytes to client),导致代理失效。
原代码中使用全局 channel lrCh 缓存单个 dstConn,并在每个 srcConn 处理 goroutine 中
? 核心原则:TCP 连接是“一次性资源”,不可复用。发生任何非 Temporary() 错误(如 EOF, broken pipe, connection reset)后,必须彻底丢弃并重建整条链路。
参考简化版代理模式(源自 jbardin/gist),关键改进如下:
以下是重构后的核心代理函数(适配原场景):
func proxyBridge(srcConn, dstConn net.Conn) {
// 创建两个关闭通知通道
srcDone := make(chan struct{}, 1)
dstDone := make(chan struct{}, 1)
// 并发启动双向数据转发
go broker(dstConn, srcConn, srcDone) // src → dst
go broker(srcConn, dstConn, dstDone) // dst → src
// 等待任一方向关闭,触发优雅终止
select {
case <-srcDone:
// 客户端先断开:通知目标端停止读取,加速资源回收
if c, ok := dstConn.(*net.TCPConn); ok {
c.SetLinger(0) // 立即释放端口
}
dstConn.CloseRead()
<-dstDone // 等待目标端也完成
case <-dstDone:
srcConn.CloseRead()
<-srcDone
}
}
// broker 负责单向数据拷贝,并在结束后通知
func broker(dst, src net.Conn, done chan struct{}) {
_, err := io.Copy(dst, src)
if err != nil && err != io.EOF {
log.Errorf("proxy copy error: %v", err)
}
// 主动关闭读端,让对端 io.Copy 检测到 EOF 并退出
if err := src.Close(); err != nil {
log.Warningf("close src error: %v", err)
}
done <- struct{}{}
}总结:Go 网络编程中,“连接复用”是伪命题。真正的复用应体现在监听器复用(net.Listener 可长期 Accept)和goroutine 复用(通过 channel 控制工作流),而非已关闭的 net.Conn。坚持“一连接一代理、错即弃、关则协”的原则,才能构建出稳定、可观测、易维护的代理服务。