如何在Golang中编写端口转发工具Port Forwarder Go语言io.Copy流量代理

io.copy 单向阻塞导致双向 tcp 连接卡死或丢数据，必须用 errgroup.group 并发启动两个 io.copy 并统一管控生命周期，配合 setdeadline 和局部缓冲区确保安全高效转发。

为什么 io.Copy 直接用在端口转发里会卡住或丢数据

因为 io.Copy 是单向阻塞复制，而 TCP 连接是双向的。只调一个 io.Copy（比如从 client 到 server），另一头没人在读，对端发来的数据就堆积在内核缓冲区，最终触发 TCP 窗口关闭、连接假死，甚至被中间设备断连。

常见现象：curl 能发请求但收不到响应；http 返回 200 但 body 空；ssh 登录后立刻断开。

• 必须同时启动两个 io.Copy goroutine，分别处理 client→remote 和 remote→client
• 两个 io.Copy 要共用同一个 sync.WaitGroup 或 errgroup.Group 控制生命周期
• 任一方向出错（如 EOF、timeout、read: connection reset）不能直接 return，得通知另一方也退出，否则 goroutine 泄漏

如何安全地关闭双向 io.Copy 连接

很多人用 defer conn.Close() 就以为万事大吉，但实际中 client 或 remote 可能已提前断开，goroutine 卡在 io.Copy 的 Read 上，永远等不到 EOF。

关键不是“怎么关”，而是“谁来触发关”和“关得是否干净”：

立即学习“go语言免费学习笔记（深入）”；

• 用 errgroup.Group 启动两个 io.Copy，它天然支持任意一个出错就 cancel 其余任务
• 不要依赖 conn.Close() 触发读端退出 —— io.Copy 在已关闭的 conn 上会立即返回 Error，但你要确保 close 发生在 copy 结束之后，否则可能 panic
• 给底层连接加 SetDeadline（比如 30 秒），避免因网络抖动无限 hang 住
• 示例核心逻辑：

  g, _ := errgroup.WithContext(ctx) g.Go(func() error { return io.Copy(remote, client) }) g.Go(func() error { return io.Copy(client, remote) }) _ = g.Wait() // 任一 copy 出错，另一个也会被 cancel

net.Conn 复用时为什么会出现 “use of closed network connection”

错误信息：write tcp 127.0.0.1:8080->127.0.0.1:54322: use of closed network connection。这不是 bug，是典型的竞态：一个 goroutine 已 close conn，另一个还在往它写。

根本原因在于没做连接状态同步：

• 别在多个 goroutine 里裸调 conn.Write —— 即使用了 errgroup，也要确保所有写操作都在 copy goroutine 内部完成
• 如果要加日志或统计，用 io.TeeReader/io.TeeWriter 包一层，别自己另起 goroutine 读写原 conn
• 连接池？别在这类代理场景里用 http.Transport 那套复用逻辑 —— 端口转发是 1:1 生命周期绑定，复用只会放大状态混乱
• 最简方案：每个连接独占一对 goroutine + 一个 errgroup.Group，结束后统一 close

要不要加 buffer 或换用 io.CopyBuffer

默认 io.Copy 用 32KB 缓冲区，在大多数内网转发场景够用。但如果你代理的是高频小包（比如 websocket ping/pong、redis 请求），默认 buffer 会导致 syscall 过多，CPU 毛刺明显。

这时可以换 io.CopyBuffer，但注意两点：

• buffer 大小不是越大越好 —— 超过 64KB 容易触发 linux 的 copy_to_user 分页开销，实测 16KB~32KB 平衡点最佳
• buffer 必须是局部变量或 sync.Pool 获取，绝不能全局复用 —— 否则并发时内容被覆盖，出现乱码或协议解析失败
• 示例：

  buf := make([]byte, 32*1024) _, err := io.CopyBuffer(dst, src, buf)

真正影响吞吐的往往不是 buffer，而是连接建立延迟和 TLS 握手 —— 如果你转发 https 流量，别优化 io.Copy，先确认是否真需要透传（而不是用 httputil.NewSingleHostReverseProxy）