Workerman设置硬性连接上限需同步配置应用层Worker::$maxConnections和系统级ulimit（如systemd的LimitNOFILE），并建议按端口分Worker或在onConnect中动态拦截，以实现精准限流与全局防护。
Workerman服务在公网暴露后，突然遭遇恶意扫描或流量洪峰，连接数瞬间冲到上万导致进程崩溃、CPU飙高、响应卡死，必须立刻设置硬性连接上限来保护服务稳定运行。
修改Worker::$maxConnections应用层限制
这是最直接的代码级控制手段，在Workerman启动脚本顶部或Worker实例创建前设置全局最大连接数。
打开你的start.php或主入口文件，在use Workerman\Worker;之后、new Worker()之前插入这一行：
Worker::$maxConnections = 5000;
这个值代表所有Worker进程加起来的总连接上限，不是单个进程的限制。设为5000意味着哪怕你开了8个Worker，整个服务最多只接受5000个并发TCP连接，超出的连接请求会被内核直接拒绝（SYN丢弃），不会进入PHP逻辑层。
注意：该配置必须放在Worker类初始化之前，否则无效；若你用的是多个Worker实例（如HttpWorker、WebSocketWorker并存），这个值是它们共享的总配额。
同步调整系统文件描述符限制
只改PHP代码远远不够——如果操作系统只允许单进程打开1024个文件描述符（fd），那就算你把maxConnections设成10万，实际撑到1024就会报Too many open files，新连接静默失败，客户端卡在三次握手阶段，毫无日志提示。
第一步：确认当前生效的软限制
用ps aux | grep php找到Workerman主进程PID，再执行：cat /proc/<pid>/limits | grep "Max open files"</pid>。这个输出才是真实限制，别信ulimit -n在当前shell里的返回值。
第二步：永久提升限制（以systemd托管为例）
编辑服务文件/etc/systemd/system/workerman.service，在[Service]段落里添加：
LimitNOFILE=65535
然后执行systemctl daemon-reload && systemctl restart workerman。这一步必须做，否则改了/etc/security/limits.conf也无效——因为systemd绕过了PAM limits加载流程。
第三步：验证是否生效
重启后再次用cat /proc/<pid>/limits</pid>检查，确保<code>Max open files的Soft Limit和Hard Limit都已变成65535。若仍是1024，说明服务没走systemd重启，或者配置没reload。
按业务类型分层设限
单一全局上限无法应对混合业务场景：WebSocket长连接需持久占位，HTTP短连接应快速释放，而管理后台接口必须保底可用。
方法一：用不同Worker监听不同端口+独立maxConnections
为WebSocket服务单独起一个Worker监听9502端口，设置$ws_worker->count = 4; $ws_worker->maxConnections = 3000;；HTTP API另起Worker监听8080端口，设$http_worker->maxConnections = 2000;。两者互不干扰，防止单一入口打爆全站。
方法二：连接建立时动态拦截（推荐）
在onConnect回调中加入判断逻辑：
if (ConnectionManager::getTotalConnections() > 4500) {<br> $connection->close();<br> return;<br>}
这比全局maxConnections更灵活——你可以结合IP频次、Token有效性、请求头特征做白名单放行，比如运维IP永远不限，未登录用户限100连接，VIP用户限500连接。
【关键前提】必须用Redis或APCu实现跨进程的连接总数统计，否则每个Worker进程看到的只是自己管辖的连接数，起不到全局防护作用。
