一个需要同时维持 5 万条 WebSocket 长连接的在线系统，监控上看着连接数稳定，业务侧却开始出现消息延迟、发送失败和周期性断线。问题往往不在“服务器还能不能再加连接”，而在每条连接究竟占用多少内存、事件循环是否已经排队，以及反向代理是否先于应用层触发限制。只看 CPU 和连接总数，容易把容量估算做得很乐观。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：sixtynet（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
WebSocket 连接的常驻成本，不只是套接字缓冲区。还要计入用户态对象、订阅关系、待发送队列、TLS 状态以及心跳定时器。经验上，连接数不能直接乘以单条消息大小，因为消息大多按需分配；真正稳定的是每条连接的基础结构和队列上限。可以先按“基础连接开销 + 预留消息缓存”计算，例如基础开销取 8KB，每条连接预留 4KB 缓冲，则 10 万条连接约需 1.2GB，再给进程、代理和内核网络栈留出 30% 余量。
估算时必须把最大消息数、慢客户端比例和重连风暴纳入模型。若客户端网络差，发送队列不断堆积，内存占用会从可控变成突发峰值。压测不能只测握手完成率，还要模拟上行、下行不均衡，并观察 P95 消息延迟和进程 RSS，而不是仅看平均响应时间。心跳能够清理失联连接，但过短会放大无效唤醒，过长则让僵死连接长期占用槽位。
当消息频率上升，CPU 可能尚未满载，事件循环延迟却已明显增加。此时应重点观察单核事件循环占用、回调执行时间和队列等待时间，而不是继续增加连接。判断方法是把目标并发分成稳态连接、突发重连和故障保留三部分，再分别压测：稳态确认可持续运行，突发场景确认代理与应用不会同时耗尽资源，故障保留用于容纳节点切换期间的重复登录。
代理层连接限制是另一条容易忽略的边界。每条 WebSocket 通常对应一条 TCP 连接，还可能占用文件描述符、连接跟踪表项和后端 upstream 槽位。代理的空闲超时若小于应用心跳间隔，会在连接仍被判定为活跃时提前断开；反过来，心跳超时判定过宽，又会让大量半开连接占满代理资源。应将“心跳间隔、两次未响应后的清理时间、代理空闲超时”按从小到大的顺序设计，并预留至少一轮检测余量。
可用 ServLlama 汇总节点连接数、事件循环延迟、内存峰值和断线原因，辅助找出代理先拒绝、消息积压还是心跳误杀。扩容阈值不能只看理论上限，建议把事件循环延迟持续升高、连接队列接近 80%、重连请求超过正常基线三倍设为过载保护阈值；达到任意一项，就暂停非核心握手、限制重连并优先保留已有业务连接。
长连接内存预算不能只计算 socket 对象。每条连接还占用应用缓冲区、待写队列、TLS 状态、定时器，以及内核收发缓冲；大消息和广播会产生额外副本。预算应采用压测得到的 P95 单连接占用，乘以目标连接数后再预留连接池、突发队列和进程余量。
事件循环饱和度往往比 CPU 使用率更早暴露问题。持续采集事件循环延迟 P99、就绪队列深度和回调耗时；当延迟 P99 上升且队列积压时，即使总 CPU 未满，单机吞吐也可能已经下降。容量应按最差节点计算，并预留约 30% 的 CPU、内存和文件描述符余量。
心跳超时判定要区分业务静默与链路死亡。ping/pong 只能证明当前可达，TCP Keepalive 也不能替代应用心跳；代理静默删除映射后，socket 仍可能显示正常。发送心跳的周期应短于代理空闲回收时间，连续多个周期收不到有效响应才判死，同时加入随机抖动，避免连接集中超时。
代理层连接限制常比应用先触发，包括单 worker 上限、源站并发、文件描述符、临时端口、TLS 握手队列，以及 Upgrade 头和空闲超时不一致。需要逐跳核对参数；“客户端在线”不代表源站连接仍存在，尤其要检查代理是否缓冲心跳或延迟转发响应。
过载保护阈值应按压测拐点分级，而不是只盯内存或连接总数。过载时停止接受新连接，限制队列、拒绝慢客户端，并降级非关键功能。例如事件循环延迟 P99 超过 50ms、队列连续占满 80% 可用容量或文件描述符达到 85% 时进入保护；恢复设置滞回，避免在阈值附近反复抖动。
容易踩的坑包括全局锁、同步日志、每包定时器及无界发送队列，它们会把轻量连接放大成阻塞事件循环。风暴来临时还要对重连施加指数退避和随机抖动，否则断开与重连会形成自激峰值。
最终检查：①压测并记录每连接 P95 内存、文件描述符和带宽，确认峰值余量；②监控各节点事件循环延迟 P99、队列深度、握手耗时及超时比例；③逐跳核对连接、空闲、TLS 与缓冲限制；④验证连续丢失三次心跳后的清理时延；⑤演练代理满载、断连风暴和慢读客户端；⑥为重连设置退避上限，确认过载时新连接被快速拒绝且在线连接可有序清理。
