workerman单机连接数无固定上限，取决于应用配置、php扩展、系统文件描述符和内核参数四层调优；漏任一层（如ulimit -n仅1024）将导致连接卡在syn_recv且无日志；需装event扩展启用epoll、调高net.core.somaxconn等内核参数，并设maxconnections为fd上限的70%～80%。
Workerman单机连接数没有固定“最高值”，它取决于你是否把四层瓶颈全调通：应用配置、PHP扩展、系统文件描述符、内核网络参数。随便漏一层，1000都跑不满。
Worker::$maxConnections设了但没用？先看系统fd限制
这是最常踩的坑——Worker::$maxConnections = 100000写得再漂亮，ulimit -n还是1024，Workerman连到第1024个连接就会静默拒绝新请求，日志里甚至不报错，只卡在SYN_RECV状态。
- 查真实限制：
cat /proc/<pid>/limits | grep "Max open files"</pid>（用ps aux | grep start.php找主进程PID） - 临时生效：
ulimit -n 65535 && php start.php start -d - 永久生效要改两处：
/etc/security/limits.conf（加www-data soft nofile 65535）和systemd服务Unit里加LimitNOFILE=65535 -
$worker->maxConnections建议设为系统fd上限的70%～80%，留余量给定时器、日志、DNS等其他fd开销
Linux下必须装event扩展，否则连接数卡死在2000以内
Workerman默认用PHP的stream_select()，在Linux上性能极差，连接数一过2000就明显延迟上升、丢包率升高。这不是代码问题，是I/O模型缺陷。
- 装
event扩展后，Workerman自动切换到epoll，吞吐翻3～5倍 - 验证是否生效：
php --ri event有输出，且启动日志出现Using event extension - 没装扩展时，即使开了
Worker::$daemonize = true，也扛不住长连接压测
Windows下别谈高并发，200+就是天花板
Windows原生Workerman是单进程+select()轮询，根本不存在“调优”空间。你设Worker::$processCount = 16，日志只会打Starting worker in single process mode，关掉CMD窗口服务立刻挂。
- 并发超200后，CPU飙升但连接建立缓慢，大量连接卡在
TCP_SYN_SENT - workerman-for-win是第三方补丁，依赖特定PHP版本，无守护、无信号处理，正式环境禁用
- 开发阶段可用，但压测结果不能作为上线依据
别忘了内核参数，net.core.somaxconn才是最后一道闸门
哪怕fd和maxConnections全调到位，net.core.somaxconn太小也会让新连接在内核队列就丢弃——表现为客户端偶发Connection refused或超时，而Workerman日志完全安静。
- 查当前值：
sysctl net.core.somaxconn，默认常为128 - 调高：
sysctl -w net.core.somaxconn=65535，并写入/etc/sysctl.conf持久化 - 顺手检查：
net.ipv4.ip_local_port_range（决定可用端口范围）、net.ipv4.tcp_fin_timeout（影响TIME_WAIT回收速度） - 这些参数改完必须重启Workerman进程，不是reload
真正跑出10万连接的机器，/proc/<pid>/fd/</pid>目录下实际打开的fd数会接近你设的maxConnections×0.75，而不是刚好相等——因为每个连接背后还有心跳定时器、日志句柄、Redis连接等隐式开销。盯着lsof -p <pid> | wc -l</pid>和ss -s两个命令看实时数据，比任何配置文档都管用。
