这种情况我之前排查过好几次，真的挺挠头——明明服务器是严格照着epoll手册示例写的，结果批量连的时候总有几个客户端进程“石沉大海”，完全触发不了服务器的epoll事件。结合你说的客户端是主进程fork出n个进程连接的场景，大概率是客户端这边踩了几个常见的坑，给你列几个优先级最高的排查点：

1. 客户端socket的创建时机错误 #

这是最常见的问题：如果你的客户端主进程是先调用socket()创建套接字，再fork子进程，那所有子进程都会继承这个同一个socket文件描述符。但一个socket fd不能同时发起多个connect()调用，只有第一个子进程的连接可能成功，后续子进程的connect()会直接失败，服务器自然收不到这些连接请求。

正确的做法是：在每个子进程内部单独调用socket()创建新的套接字，再执行connect()。每个子进程用自己独立的socket fd去发起连接，避免资源冲突。

2. 客户端缺少connect()的错误处理 #

很多时候开发者默认connect()一定能成功，但批量创建进程时很容易遇到系统资源限制：

• 比如进程打开的文件描述符数达到上限（errno为EMFILE），导致无法创建新socket；
• 或者客户端本地端口耗尽（errno为EADDRNOTAVAIL），无法发起新的连接。

给每个子进程的connect()调用加上完整的错误处理，打印errno值和对应的错误信息（可以用strerror(errno)），就能快速定位是不是连接本身就失败了，而不是服务器的问题。

3. 服务器的accept()处理是否完整（针对边缘触发场景） #

虽然你说服务器是照着手册写的，但再确认下：如果服务器用的是**边缘触发（EPOLLET）**模式，处理监听套接字的EPOLLIN事件时，必须循环调用accept()直到返回EAGAIN或EWOULDBLOCK。因为边缘触发只会通知一次有新连接，如果只调用一次accept()，队列里剩下的连接不会触发新的epoll事件，这些客户端就会看起来“失联”了。

如果是水平触发模式，这个问题会少一些，但也建议循环处理到accept()返回错误，避免遗漏。

4. 系统连接队列的资源限制 #

服务器调用listen()时的backlog参数如果设置得太小（比如默认的128），当客户端一次性发起大量连接时，TCP的半连接队列或全连接队列会被占满，后续的连接请求会被内核直接拒绝，服务器也不会收到epoll事件。

可以把backlog参数设置为SOMAXCONN（定义在<sys/socket.h>中，一般是1024或更大），同时检查系统内核参数net.core.somaxconn，确保它的值足够大（可以用sysctl net.core.somaxconn查看，必要时临时调整：sysctl -w net.core.somaxconn=4096）。

5. 父进程未正确回收子进程资源 #

如果客户端主进程fork后没有处理子进程的退出状态，子进程会变成僵尸进程，积累到一定数量后会占用系统PID资源，间接影响新进程的创建和连接。

建议在父进程中注册SIGCHLD信号处理函数，用waitpid(-1, NULL, WNOHANG)批量回收僵尸进程，或者在fork后直接用waitpid()等待子进程退出（如果不需要父进程继续运行的话）。

先从前面两个点入手排查，大概率能找到问题所在！

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