Linux怎么查看具体的系统最大连接限制

/proc/sys/fs/file-max和ulimit -n是决定系统总连接池上限与单进程连接数的实际门槛，前者为内核级总文件描述符上限，后者为当前shell软限制，二者共同约束真实并发连接能力。

直接看 /proc/sys/fs/file-max 和 ulimit -n，这两个才是真实起作用的值

系统的最大连接数，从来都不是某一个“配置项名”单独拍板决定的，它本质上受两层约束：一层是内核级限制，另一层是进程级限制。光去查 sysctl fs.file-max 或者翻配置文件，其实并不能说明最终结果——真正起作用的，是 /proc/sys/fs/file-max 当下的实际值；同样，一个服务究竟能建立多少连接，关键看的是它启动那一刻继承到的 ulimit -n，而不是 /etc/security/limits.conf 里写了什么就必然会生效。

ulimit -n 查不到真实值？先确认 shell 是否已加载新限制

很多人改完 /etc/security/limits.conf 就跑 ulimit -n，发现还是 1024。这是因为：

• 普通用户改 limits 后，必须新开一个登录 session（比如 su - $USER 或重新 ssh 登录），ulimit -n 才会更新
• systemd 服务完全不读 limits.conf，得在 service 文件里写 LimitNOFILE=65536，或全局设 DefaultLimitNOFILE=65536 在 /etc/systemd/system.conf
• Docker 容器默认继承宿主机的 ulimit，要用 --ulimit nofile=65536:65536 显式传入

别漏掉 ip_local_port_range 和 nf_conntrack_max 这两个隐性瓶颈

即使 file-max 和 ulimit -n 都调高了，连接仍可能卡住，原因常在这两个地方：

• sysctl net.ipv4.ip_local_port_range：决定 outbound 连接可用端口数量。默认是 32768 65535（约 32K 端口），单机发起大量 client 连接时会先耗尽这里
• sysctl net.netfilter.nf_conntrack_max：只在用了 iptables/NAT/firewalld 时才生效。如果开了防火墙但没调这个值，连接到几千就 conntrack full 报错
• 注意：nf_conntrack_max 和 file-max 完全不重叠，但都会拦连接——前者卡状态跟踪，后者卡 socket 句柄分配

验证是否真生效，用 ss -s 和 cat /proc/sys/fs/file-nr

改完参数不能只信“命令执行成功”，要立刻验证运行时状态：

• ss -s 输出里的 sockets: 行，显示当前 ESTABLISHED、TIME-WAIT 等总数，是实际连接水平
• cat /proc/sys/fs/file-nr 返回三个数：allocated、unused、max。重点看第二项 unused：如果长期接近 0，说明 file-max 已逼近上限
• 硬限制 ulimit -Hn 必须 ≥ 软限制 ulimit -Sn，否则 ulimit -n 显示的是软限制，但进程实际受硬限制约束

真正卡连接的，往往不是你没改的参数，而是你改了却没验证、或者改了但服务没重启加载的那一个。尤其注意 systemd 服务和容器环境，它们对 ulimit 的加载逻辑和交互式 shell 完全不同。