/proc/sys/fs/file-max和ulimit -n是决定系统总连接池上限与单进程连接数的实际门槛，前者为内核级总文件描述符上限，后者为当前shell软限制，二者共同约束真实并发连接能力。
直接看 /proc/sys/fs/file-max 和 ulimit -n，这两个才是决定“当前能建多少连接”的实际门槛，不是理论值也不是配置项名。
查系统级最大文件描述符数（即总连接池上限）
Linux 中每个 TCP 连接、socket、打开的文件都消耗一个文件描述符（file descriptor），所以系统最大并发连接数直接受 fs.file-max 约束。
- 执行
cat /proc/sys/fs/file-max查当前内核允许的最大文件描述符总数 - 这个值默认约等于内存页数 × 0.1，4GB 内存机器常见为 786432 左右；若业务需支撑 50 万连接，建议设为
2097152 - 注意它和
pid_max无关，但若file-max> 内存能支撑的句柄数，内核会静默降级——不是报错，而是后续accept()或socket()开始随机失败 - 别只信
sysctl fs.file-max输出：某些发行版（如 RHEL 8+）用 systemd-sysctl 管理，sysctl显示的是缓存值，真实值以/proc/sys/fs/file-max为准
查当前进程/用户能用多少连接（常被忽略的瓶颈）
即使 file-max 很大，单个进程仍受 ulimit -n 限制，Java、Nginx、Node.js 启动后继承 shell 的该值，超了就报 Too many open files。
- 运行
ulimit -n查当前 shell 的软限制（soft nofile） - 运行
ulimit -Hn查硬限制（hard nofile），软限制不能超过它 - 容器内进程默认继承宿主机
ulimit，Docker 要显式加--ulimit nofile=65536:65536才生效 - systemd 服务不读
/etc/security/limits.conf，必须在 service 文件里写LimitNOFILE=65536，或全局设DefaultLimitNOFILE=65536在/etc/systemd/system.conf
改内核参数让连接数真正提上去
只调 file-max 不够，还得配齐配套参数，否则连接卡在握手、端口耗尽或状态跟踪表满。
- 临时改：用
echo 2097152 | sudo tee /proc/sys/fs/file-max（立即生效，重启失效） - 永久改：往
/etc/sysctl.d/99-file-limit.conf写入fs.file-max = 2097152，再跑sudo sysctl --system - 顺手调这几个关键配套项：
net.core.somaxconn = 65535（listen 队列长度）、net.ipv4.ip_local_port_range = 1024 65535（客户端可用端口范围）、net.netfilter.nf_conntrack_max = 1048576（仅当用了 iptables/NAT 时才起作用） - 改完立刻验证：用
ss -s看当前 socket 统计，cat /proc/sys/fs/file-nr看已分配/未使用/最大值三元组，第二项长期接近第一项就说明快满了
为什么改了还是连不上？重点检查这三处
多数“明明调高了却连不上”的问题，不是参数没生效，而是卡在更底层或应用侧。
- 应用自身限制：Nginx 默认
worker_connections 512，Tomcat 的maxConnections默认 200，这些必须同步调高 - 端口复用未开：
net.ipv4.tcp_tw_reuse = 1必须设，否则 TIME_WAIT 连接占满端口后新连接阻塞 - 内存真不够：每条 ESTABLISHED 连接内核至少占 3.3KB，100 万连接 ≈ 3.3GB 内存纯给连接状态用，
file-max设太高但物理内存不足，会导致accept()返回ENOMEM
最易被忽略的是：修改 /etc/security/limits.conf 后，旧进程不会自动继承新限制，必须新开登录会话或重启服务；而 systemd 服务还要额外确认 pam_limits.so 是否启用、LimitNOFILE 是否覆盖了全局设置。参数调得再高，漏掉其中一环，连接数就卡在 1024。
