golang如何排查tcp异常关闭_golang排查tcp异常关闭方法

先说几个核心判断：Go 中 TCP 异常断开，本质上就是通过读写错误、超时设置和心跳机制来发现并处理。`Read()` 返回 `io.EOF` 代表对端正常关闭，而 `Write()` 出现 `broken pipe` 则说明连接已经断了。

tcp.Close() 后立即 write 会触发 broken pipe

有意思的是，Go 的 `net.Conn` 调用 `Close()` 后，底层的 socket 可能还没来得及完成四次挥手。这时候如果另一端还傻乎乎地往上面写数据，就会立刻撞上 `write: broken pipe` 或 `use of closed network connection` 这种错误。这其实不是网络出了大问题，而是连接状态没同步导致的时序误判。 应对策略其实就几个： * 用 `conn.SetDeadline()` 把写操作包裹起来，避免在已关闭的连接上无限阻塞下去。 * 写之前，可以检查一下 `conn.RemoteAddr() != nil`，虽然不绝对可靠，但能过滤掉一些明显已经断开的连接。 * 千万别把 `err == io.EOF` 当成判断连接是否断开的唯一标准。`io.EOF` 只表示对端发起了关闭，本端理论上还可能成功写一次数据。

如何捕获 FIN/RST 到达的瞬间

Go 标准库没有直接暴露 TCP 状态机的事件，我们只能通过读操作来间接感知。当对端发送 FIN 后，本端的 `Read()` 会返回 `0, io.EOF`；如果收到的是 RST，那通常返回的是 `read: connection reset by peer`。 这里有几个关键点需要注意： * 所有读逻辑必须统一处理 `err != nil` 的分支，千万别只盯着 `err == io.EOF` 看。 * 对于关键连接，建议启用 `SetReadDeadline(time.Now().Add(30 * time.Second))`，防止因为 FIN 延迟抵达而导致连接假死。 * 如果想主动探测对端是否还活着，可以用 `conn.Write([]byte{})` 配合 `conn.SetWriteDeadline()`，这一套组合拳比专门的心跳包更轻量。

netstat 和 ss 要看哪些字段才能定位异常关闭方

排查问题，工具得上。运行 `ss -tlnp | grep :your_port` 看监听状态；对活跃连接，用 `ss -tinp state established '( dport = :your_port )'`，重点盯着这几个字段： * `st` 列：`01` 表示 ESTABLISHED，`06` 是 TIME-WAIT，`07` 是 CLOSE-WAIT。如果发现大量 CLOSE-WAIT，基本可以断定你的程序没调用 `conn.Close()`。 * `timer` 列：显示重传或保活计时器。如果看到 `keepalive` 且持续倒计时，说明连接虽然空闲，但还没断开。 * `retrans` 字段：这个值非零，大概率是中间设备（比如 NAT 网关、防火墙）静默丢弃了 ACK，问题往往不在代码本身。

使用 net/http.Server 时为什么连接突然消失

`http.Server` 默认启用了 HTTP/1.1 的 keep-alive，但客户端可能提前关闭了连接，而 Go 不会立即通知你的 handler。你在日志里看到的 `context.DeadlineExceeded` 或 `http.ErrHandlerTimeout`，很多时候是超时机制掩盖了真实的断连时间。 正确的做法是： * 在 handler 里，用 `req.Context().Done()` 来监听请求中断，这比依赖内部字段可靠得多。 * 设置 `Server.ReadTimeout` 和 `Server.IdleTimeout` 时，必须确保它们小于负载均衡器的空闲超时（比如 ALB 默认是 60s），否则连接会被 LB 先一步断开。 * 如果日志里出现 `http: TLS handshake error` 或 `http: server ga ve HTTP response to HTTPS client`，说明连接被中间设备重定向或协议错配了，这属于配置问题，不是应用层的 TCP 异常。 真正棘手的，是半开连接（half-open）。表现形式是：一端认为连接好好的，另一端其实已经崩溃或断网了。这种状态下，`Write()` 可能成功好几次，直到内核的重传机制耗尽耐心才报错。所以，别指望一次检测就能覆盖所有场景。正确的思路是：连接生命周期管理 + 主动探测 + 网络工具交叉验证，三者结合起来，才能把问题彻底钉死。