Boost Beast WebSocket断网时async_write返回空error_code问题

你遇到的空错误码（system:0 即成功状态）不是Boost.Beast的bug，是TCP协议本身的语义和操作系统网络栈行为共同导致的，核心原因如下：

• TCP的write类操作（包括异步async_write）的成功定义仅为数据被成功拷贝到操作系统内核的发送缓冲区，不代表数据已经成功发送到对端、更不代表当前端到端链路连通。
• 当你通过拔网线、断开WiFi等方式断网时，操作系统内核不会立刻感知到链路故障：内核会按照TCP协议的重传规则持续尝试发送缓冲区里的数据，Linux默认配置下整个重传过程最长会持续数十分钟，这段时间内所有提交给内核的写请求都会直接返回成功，不会抛出错误。
• Boost.Beast的WebSocket实现不会在async_write中做额外的链路存活校验，只要底层TCP/SSL流的写操作返回成功，它就会直接透传成功的error_code，不会主动探测连接状态。你调试看到的Undefined error: 0本质就是操作成功的返回值，不是异常值。

很多开发者会默认「写操作返回成功=对端收到消息」，这个认知是错误的：

所有基于TCP的应用层协议，写操作成功都只代表本地内核接收了待发送数据，端到端的投递确认必须依赖应用层协议本身的ACK机制。如果断网发生在数据已经被拷贝到内核缓冲区之后，之前提交的写操作永远不会返回对应错误，直到内核重传超时判定连接失效。

不要依赖async_write的返回值判断连接存活，你需要组合使用以下机制检测断网：

• 开启WebSocket内置的Ping/Pong保活：配置固定间隔（比如30秒）发送Ping帧，同时设置Pong超时阈值（比如10秒），超时未收到Pong就主动判定连接断开，清理ws对象。这是WebSocket场景下最可靠的断网检测方式。
• 配置底层TCP Keepalive：给tcp_stream设置SO_KEEPALIVE选项，调整保活探测间隔、重试次数到业务可接受的范围（比如间隔30秒、重试3次），可以缩短内核感知链路故障的时间，但注意TCP Keepalive是传输层机制，部分NAT设备会丢弃空的Keepalive探测包，可靠性不如应用层Ping。
• 常驻异步读协程：只要连接真正发生故障（不管是断网、对端重置、超时），async_read一定会先返回对应错误，你需要在协程中同时跑读循环，一旦读操作返回非0错误码，立刻标记连接状态为不可用，停止后续写操作并清理资源。

内容的提问来源于stack exchange，提问作者Zohar81