asyncio sock_accept仅支持单连接：多客户端连接失败排查

结合你的场景，导致第二个客户端连接失败、connect_ex阻塞和服务端sock_accept无限等待的核心原因主要有以下几点：

1. 未配置Socket复用选项 #

工作进程的监听Socket如果没有设置SO_REUSEADDR和SO_REUSEPORT选项，当进程1与工作进程的连接断开后，该连接会进入TIME_WAIT状态（TCP协议默认行为，用于处理残留报文）。此时若监听Socket未开启复用，内核会拒绝将新的连接请求转发给服务端的accept逻辑，最终导致客户端connect_ex无限阻塞，服务端持续等待。

2. Asyncio事件循环被阻塞或终止 #

• 进程1终止时，工作进程中处理该连接的协程可能未正确处理连接关闭事件（比如未捕获EOFError、未取消关联任务），导致协程陷入无限等待或抛出未处理异常，直接阻塞事件循环，使得sock_accept协程无法被调度执行。
• 若工作进程由进程1 fork创建，进程1终止后，工作进程可能因依赖资源（如标准输入输出、信号处理）异常，导致asyncio事件循环意外停止，此时监听Socket虽存在，但已无逻辑处理新连接。

3. 第一个连接关闭时的资源泄漏 #

当进程1断开连接后，工作进程中与该连接关联的Socket对象、读写任务未被正确清理（比如未调用close()、未取消异步读写任务），这些残留任务会持续占用事件循环资源，导致sock_accept无法获得执行机会，最终表现为服务端无限等待新连接。

4. 客户端connect_ex的使用方式问题 #

你提到第一个客户端需要多次循环connect_ex才成功，说明客户端可能在同步上下文调用connect_ex而非异步方式。如果第二个客户端仍采用同步调用，当服务端事件循环卡住无法响应请求时，同步调用会一直阻塞（直到系统级TCP超时，通常耗时极长），而非异步方式的非阻塞等待。

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