“Connection reset by peer”是因对端主动关闭连接导致的TCP层错误，常见于客户端异常断开、服务端向已关闭连接写数据、心跳缺失致中间件断连等情况，需通过$server->exist检查连接状态、实现心跳机制及try-catch捕获异常来预防和处理。

“Connection reset by peer” 是 Swoole 编程中常见的网络错误，表示对端（客户端或服务端）主动关闭了连接，而当前进程还在尝试读取或写入数据。这个错误本质上是 TCP 层的 RST 包触发的系统级提示，不是 Swoole 特有的问题，但在 Swoole 的高并发场景下更容易暴露。

客户端异常断开连接

最常见的原因是客户端在未正常关闭连接的情况下突然断开，比如：

• 用户强制关闭浏览器或 App
• 网络中断、设备重启
• 客户端超时主动 reset 连接

当服务端仍在向该连接发送数据时，会收到 RST 包，Swoole 抛出 “Connection reset by peer” 错误。这类情况属于正常网络波动，无需过度处理，但需做好异常捕获。

Swoole 服务端向已关闭的连接写数据

即使连接曾经有效，也可能在两次操作之间被对端关闭。例如：

• 客户端发送请求后立即断开，但服务端还在处理逻辑
• 异步任务延迟响应，连接已超时

此时调用 $server->push() 或 $server->send() 就可能触发该错误。建议在发送前通过 $server->exist($fd) 判断连接是否仍然存活。

心跳机制缺失导致连接被中间件关闭

很多代理、负载均衡器或防火墙会设置空闲超时（如 Nginx 默认 60 秒），长时间无数据交互的连接会被强制断开。

解决方法是实现心跳机制：

• 客户端定期发送 ping 消息
• 服务端使用定时器检查最近一次通信时间，超时则 close 连接

这样可以避免向已被中间设备关闭的连接写数据。

程序未正确捕获和处理异常

Swoole 在协程模式下（如使用 Swoole\Coroutine\Http\Server 或 Redis/MySQL 协程客户端），网络异常会以 PHP 异常形式抛出。若未用 try-catch 包裹 send/push 操作，会导致进程崩溃或日志刷屏。

正确做法：

try {
    $server->push($fd, 'data');
} catch (Throwable $e) {
    // 记录日志或清理资源
    $server->close($fd);
}

基本上就这些常见原因。关键是理解：这个错误表示“对方已经不认这个连接了”，重点在于预防和优雅处理，而不是完全避免。只要做好连接状态管理与异常捕获，就不会影响服务稳定性。