max_connection必须显式设置，否则swoole默认仅支持1024连接；需结合ulimit -n调高文件描述符限制，并注意think-swoole等框架使用max_conn而非max_connection。
max_connection 参数必须显式设置
不设 max_connection，Swoole 就按系统 ulimit -n 值自动取最小值（通常是 1024），根本撑不住真实并发。它不是“默认足够”，而是“默认极低”。必须在 $server->set() 中明确写死：
$server = new Swoole\Http\Server('0.0.0.0', 9501);
$server->set([
'worker_num' => 8,
'max_connection' => 60000, // 必须大于你预期的峰值连接数
]);
这个值不能拍脑袋定：它要 ≤ 系统允许的最大文件描述符数，且需预留约 10% 给日志、Redis 连接、协程 HTTP 客户端等其他 fd 消耗。
ulimit -n 是硬门槛，不调就必报 "Too many open files"
哪怕 max_connection 设成 10 万，ulimit -n 只有 1024，新连接一来就直接被内核拒绝，错误日志里只看到 accept(): Too many open files。
- 临时生效：
ulimit -n 65535（仅当前 shell 有效） - 永久生效：编辑
/etc/security/limits.conf，加两行（把your_user换成实际运行用户）：your_user soft nofile 65535 your_user hard nofile 65535
- 如果是 systemd 服务，还要在
.service文件的[Service]段加：LimitNOFILE=65535
改完别忘了重启终端或重载 systemd，并用 ps -eo pid,rlimit | grep $(pgrep your-swoole) 确认进程实际生效值。
max_connection 和 max_conn 别混用，Think-Swoole 用的是后者
原生 Swoole Server 用 max_connection；但 Think-Swoole（如 4.1）封装后，在配置文件里对应的是 max_conn，写错字段等于没配：
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
// config/swoole.php
'http' => [
'options' => [
'max_conn' => 50000, // 注意：这里是 max_conn，不是 max_connection
'worker_num' => 8,
],
],
同理，WebSocket server 的配置项名也一样。如果用的是 Think-Swoole 或 laravel-swoole 这类封装，翻源码确认字段名比查文档更快——它们往往不完全兼容原生 key 名。
连接数快到上限时，靠 connection_list() 实时盯住
光设参数不监控，等于闭眼开车。上线后必须定期采样当前连接数，否则等用户投诉“连不上”才反应过来就晚了：
在定时回调或管理接口里加一句：
echo "active connections: " . count($server->connection_list(0, 1000)) . "\n";
connection_list() 第二个参数是分页大小，设太小会漏数；建议用 0（起始 fd）和足够大的值（比如 10000）确保扫全。再配合 $server->stats() 看 accept 数、close 数趋势，才能判断是真扛不住，还是连接泄漏没关干净。
真正容易被忽略的点是：max_connection 控制的是“已建立但未关闭”的 TCP 连接总数，不是每秒请求数；而连接泄漏（比如没 close WebSocket 或没释放 Redis 协程连接）会让这个数缓慢爬升直至卡死——所以必须代码层配合 defer / try-finally，不能只靠配置兜底。
