单个进程TCP连接数无固定上限，受限于ulimit -n（文件描述符）、ip_local_port_range（客户端端口范围）、tcp_mem（内存）及somaxconn（监听队列）等系统参数。
单个进程最多能建立多少 TCP 连接，取决于系统级限制和进程级资源，不是某个固定数字；默认值通常远低于理论上限，且极易被 ulimit -n 卡死。
为什么 ulimit -n 是第一道坎
Linux 进程打开文件描述符（fd）数量受 ulimit -n 限制，而每个 TCP 连接至少占用 1 个 fd（客户端）或 2 个（服务端：监听 fd + 已连接 fd）。一旦达到上限，accept() 或 connect() 会直接失败，报错 EMFILE（Too many open files）。
- 查看当前限制：
ulimit -n - 临时调高（仅当前 shell 及子进程）：
ulimit -n 65536 - 永久生效需改
/etc/security/limits.conf，例如：* soft nofile 65536和* hard nofile 65536，并确保 PAM 加载了pam_limits.so - 注意：修改后需重新登录或重启服务进程，仅 reload 不生效
net.ipv4.ip_local_port_range 决定客户端连接上限
作为客户端时，每个连接需分配一个本地临时端口。内核用 /proc/sys/net/ipv4/ip_local_port_range 控制可用端口范围，默认常为 32768 65535（约 32K 端口），意味着单 IP 最多约 32K 并发出向连接。
- 扩大范围可提升并发能力：
echo "1024 65535" > /proc/sys/net/ipv4/ip_local_port_range - 但端口复用（
SO_REUSEADDR）不能绕过 TIME_WAIT 占用——大量短连接下，net.ipv4.tcp_tw_reuse和net.ipv4.tcp_fin_timeout才是关键调节项 - 服务端不依赖此参数，因监听端口固定，连接由四元组（源IP:源Port+目的IP:目的Port）唯一标识
服务端真正瓶颈常在内存与 TIME_WAIT 积压
即使 ulimit 和端口范围都调高，每条连接仍消耗内核内存（socket 结构、接收/发送缓冲区等）。当连接数达数万时，net.ipv4.tcp_mem 和 net.core.somaxconn 就成硬约束。
-
net.core.somaxconn控制listen()的 backlog 队列长度，默认常为 128，高并发下应设为 4096 或更高 -
net.ipv4.tcp_mem是三元组（low, pressure, high），单位为页；若实际内存使用超pressure，内核开始主动回收 socket 缓冲区，影响吞吐 - 大量
CLOSE_WAIT说明应用没正确close()对端 socket；大量TIME_WAIT则需确认是否真有必要调低tcp_fin_timeout，盲目缩短可能引发丢包
实际能跑满多少连接，得看具体协议行为（长连/短连）、数据吞吐量、缓冲区大小、以及是否启用了 epoll 或 io_uring 等高效 I/O 多路复用机制——这些细节比单纯调大 ulimit 更影响上限。
