/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 都调高了，连接仍可能卡住，原因常在这两个地方：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
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 完全不同。
