Workerman连接数超1024后响应延迟或拒绝连接，根本原因是Linux内核参数不匹配：文件描述符耗尽、连接队列溢出、TIME_WAIT堆积导致监听线程卡死；需检查并永久提升进程fd限制（limits.conf+systemd配置）、调大内核网络队列（somaxconn等）、启用tcp_tw_reuse（非NAT环境）、增大系统级file-max。
Workerman连接数突破1024后出现响应延迟、新连接超时或直接拒绝，根本原因是Linux内核默认参数与高并发场景严重不匹配——文件描述符耗尽、连接队列溢出、TIME_WAIT堆积会立刻卡死监听线程，导致worker进程空转却无法接收新连接。
确认当前系统限制是否真实生效
先查Workerman主进程实际可用的文件描述符上限：用ps aux | grep workerman拿到主进程PID，再执行cat /proc/<pid>/limits | grep "Max open files"</pid>。这个值才是Workerman真正能用的上限，不是ulimit -n在终端里显示的值——后者只影响你当前shell启动的进程，对systemd或supervisord托管的服务无效。
如果输出显示soft limit仍是1024，说明系统级配置没穿透到Workerman进程，后续所有内核调优都白做。
永久提升单进程文件描述符上限
方法一：修改/etc/security/limits.conf
追加两行（假设Workerman以www-data用户运行）：
www-data soft nofile 65535
www-data hard nofile 65535
方法二：systemd服务必须额外声明
编辑/etc/systemd/system/workerman.service，在[Service]段落里添加：
LimitNOFILE=65535
【改完必须执行systemctl daemon-reload && systemctl restart workerman】，reload不是reload，是彻底重启进程才能重新读取fd限制。
调整内核网络连接队列参数
第一步：编辑/etc/sysctl.conf，追加以下四行
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_fin_timeout = 30
第二步：执行sysctl -p立即生效
第三步：同步修改Apache或Nginx反向代理配置（如有）
若Workerman前端挂了Nginx，需在nginx.conf的events块中加multi_accept on;和use epoll;；若直连，跳过此步。
注意：somaxconn控制全连接队列长度，tcp_max_syn_backlog控制半连接队列。Worker模式下监听线程是单点，这两个值必须≥Workerman设置的$maxConnections，否则SYN包直接被内核丢弃，客户端看到的是“Connection refused”而非超时。
释放TIME_WAIT连接加速端口复用
执行命令临时启用：
sysctl -w net.ipv4.tcp_tw_reuse=1
然后写入/etc/sysctl.conf固化：
net.ipv4.tcp_tw_reuse = 1
这能让处于TIME_WAIT状态的socket在安全前提下快速复用，避免端口耗尽。但【严禁在NAT环境或客户端位于同一出口IP的场景开启】，否则会导致连接混乱或重置。
增大系统级文件句柄总量
编辑/etc/sysctl.conf，追加：
fs.file-max = 6815744
该值应≥所有Workerman进程fd上限之和×1.5（预留日志、定时器等开销）。例如启4个worker进程，每个设65535，则最低需4×65535×1.5≈39万，6815744足够覆盖百级并发规模。
执行sysctl -p生效。
