云端服务器TCP连接未达上限却异常断开的原因排查

从你的描述和ss -s的输出来看，这个问题大概率不是单纯的网络速度或者线程数量导致的——毕竟本地能稳定建立5000个连接，说明你的代码逻辑本身是没问题的。问题的核心更可能出在云端服务器的TCP栈参数限制、云服务商的隐性配额，或者是进程级资源限制没有真正生效上。

先排除两个你怀疑的点： #

• 网络速度：网络慢只会导致连接建立延迟，最多让客户端触发超时重连，但不会直接导致连接被主动断开。你的ss输出里closed连接数高达348，而timewait为0，说明这些连接不是正常的超时关闭，更像是服务器端主动拒绝或被系统终止，所以网络速度不是主因。
• 线程过多：现代服务器轻松承载几千个线程完全不成问题——哪怕是低配的云实例，1300个线程的资源占用也远达不到系统上限。而且线程创建慢最多导致连接建立延迟，不会直接让已建立的连接断开，所以线程数量也不是问题根源。

重点排查这些云端特有的问题： #

1. 云服务商的隐性连接数限制

很多入门级云服务器实例（比如突发性能型、共享型实例）会有单IP并发连接数的隐性配额，哪怕你调了系统的ulimit也没用。比如有些服务商默认限制单IP的TCP并发连接在1000左右，超过就会被网关限流。

• 解决：去云服务商的控制台查看实例的网络配额，或者直接联系客服确认是否有连接数限制；如果是配额问题，要么升级实例规格，要么申请调整配额。

2. 内核TCP栈参数未优化

本地环境的TCP参数默认可能足够支撑5000连接，但云端服务器的默认参数往往偏保守，尤其是半连接/全连接队列的大小：

• net.core.somaxconn：控制全连接队列（已完成三次握手但未被accept的连接）的大小，默认值通常只有128。如果客户端连接发起太快，服务端的accept线程处理不及时，队列满了就会直接拒绝新连接。
  临时调整：echo 65535 > /proc/sys/net/core/somaxconn
  永久生效：在/etc/sysctl.conf里添加net.core.somaxconn = 65535，然后执行sysctl -p
• net.ipv4.tcp_max_syn_backlog：控制半连接队列（正在进行三次握手的连接）的大小，默认值可能只有几百。如果短时间内大量SYN包过来，队列满了会直接丢弃SYN，导致连接失败。
  临时调整：echo 10000 > /proc/sys/net/ipv4/tcp_max_syn_backlog
  永久生效：在/etc/sysctl.conf里添加net.ipv4.tcp_max_syn_backlog = 10000，执行sysctl -p

3. 文件描述符限制未真正生效

你用ulimit -n 65536调整了，但要确认这个限制是否真正作用于你的服务端进程：

• 临时调整的ulimit只对当前shell有效，如果你的服务端是通过systemd、supervisor等守护进程管理的，需要在对应的配置文件里设置LimitNOFILE=65536才能生效。
• 验证：找到服务端进程的PID，执行cat /proc/<pid>/limits，查看Max open files项的数值是不是65536。如果不是，说明限制没生效，需要调整启动脚本或守护进程配置。

4. 服务端的连接处理逻辑

虽然本地没问题，但云端的环境可能暴露了代码里的潜在问题：

• 检查服务端日志，有没有too many open files之类的报错——如果有，说明文件描述符限制还是没调好；
• 每个连接创建线程的逻辑是否有阻塞？比如线程初始化时做了耗时操作，导致accept调用不及时，全连接队列满了被系统拒绝。可以考虑用线程池代替每次创建线程，提升连接处理效率。

快速排查工具推荐 #

• 用tcpdump抓包：在服务端执行tcpdump -i any port <你的端口> -nn，观察连接失败时是服务器发送了RST包，还是SYN包直接被丢弃——如果是RST，可能是进程的问题；如果是SYN被丢弃，大概率是队列满了或云服务商限流。
• 查看内核日志：dmesg | grep -i tcp，看看有没有TCP: syn flood warning之类的日志，这说明半连接队列满了。

内容的提问来源于stack exchange，提问作者JianYuan Kou