net.listentcp在内网穿透中常被误用，因其被错误用于监听公网ip或0.0.0.0，而穿透本质是客户端主动连服务器再转发至内网服务；正确做法是服务器监听固定端口接收客户端连接，内网服务端不监听，客户端不调用net.listentcp监听本地端口。
为什么 net.ListenTCP 在内网穿透中常被误用
因为很多人直接拿它监听公网 IP 或 0.0.0.0，却忘了内网穿透本质是「反向代理」：客户端主动连服务器，服务器再把连接转给内网服务。监听本地端口不是错，但监听位置和时机错了就卡死。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 服务器端用
net.ListenTCP监听一个固定端口（如:8080），只收「穿透客户端」的连接请求，不暴露给外网服务 - 内网服务端不监听任何 TCP 端口，由穿透客户端主动建立隧道连接后，再把本地
127.0.0.1:3000的流量通过该隧道转发出去 - 别在客户端代码里写
net.ListenTCP("0.0.0.0:3000")—— 这会让客户端自己开服务，违背穿透逻辑
如何让 io.Copy 不丢包、不断流
io.Copy 看似简单，但在双向隧道中直接套用会导致一端关闭后另一端还卡着读，连接假死。根本原因是没处理 EOF 和 close 信号的时序。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要只写
io.Copy(dst, src)一次 —— 必须对 client→server 和 server→client 两个方向分别起 goroutine，并用sync.WaitGroup等待双方结束 - 任一方向复制完成（
io.Copy返回非 nil error 或 EOF），立刻调用dst.CloseWrite()（如果 dst 是net.Conn，需先转成net.Conn再调CloseWrite） - 避免用
io.Copy处理含心跳或长连接保活的协议；HTTP/1.1 的 keep-alive 可能导致连接迟迟不关闭，建议加超时控制
为什么 http.Transport 的 Proxy 字段对穿透无效
有人想复用 Go 标准库的 HTTP 客户端走穿透隧道，于是设 http.DefaultTransport.Proxy = http.ProxyURL(...)，结果发现请求还是直连 —— 因为 Proxy 只影响 outbound HTTP 请求的「第一跳」，而穿透需要的是底层 TCP 连接劫持。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- HTTP 场景下，穿透客户端应实现一个自定义
RoundTripper，在RoundTrip中手动建立隧道连接，再把*http.Request序列化发过去 - 更轻量的做法是改用
http.ServeMux+ReverseProxy：服务器端收到隧道数据后，解析出目标地址，用httputil.NewSingleHostReverseProxy转发到内网服务 - 别依赖
HTTP_PROXY环境变量 —— 它只对 go toolchain 或部分 stdlib 函数生效，对自定义连接无作用
调试时 connection refused 到底来自哪一层
这个错误最常出现在客户端已连上服务器，但服务器无法连通内网服务时。不是网络不通，而是穿透链路中间某段没打通：可能是客户端没正确把本地端口传给服务器、服务器 DNS 解析失败、或内网服务根本没起来。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在服务器日志里打全路径：收到客户端请求时，记录它声称要代理的目标地址（如
"127.0.0.1:3000"），再记录net.Dial的返回 error - 用
telnet 127.0.0.1 3000在服务器本机测试能否直连内网服务 —— 注意：必须在服务器机器上执行，不能在你本地 - 客户端发起连接前，检查本地
127.0.0.1:3000是否真有进程监听：lsof -i :3000（macOS/Linux）或netstat -ano | findstr :3000（Windows）
穿透最难的从来不是编码，而是确认每一跳的「谁连谁、连什么、有没有权限连」—— 日志里少打一行目标地址，排查就得绕半天。
