连接数升高时，先判断瓶颈究竟是应用程序、文件描述符、内核队列，还是临时端口。高并发业务的主机连接数与文件描述符调优不能靠单纯调大参数完成：连接可能占用文件描述符，也会消耗内存、端口和内核资源。合理做法是先测量，再按负载逐项调整。
先弄清连接数和文件描述符的关系
在 Linux 中，TCP 套接字通常由文件描述符引用。一个进程若持有大量客户端连接、日志文件、管道或其他文件，都会共同消耗该进程的描述符上限。因此，连接数增加不代表系统一定缺少描述符；反过来，描述符耗尽也可能先表现为新连接失败或日志无法打开。
还要区分已建立连接与等待队列。监听队列中的请求受应用监听设置和内核队列参数影响；大量处于 TIME_WAIT 的连接则可能反映短连接模式或连接关闭节奏。它们的处理方法不同，不宜一概提高文件描述符上限。
按顺序定位实际瓶颈
记录业务高峰时的并发连接、请求速率、错误日志和进程资源情况，确认问题是否在固定时段重复出现。关注“Too many open files”等错误，以及连接建立失败、响应超时等现象。
检查进程限制：读取 /proc/<进程号>/limits，查看 Max open files；用 ls /proc/<进程号>/fd | wc -l 统计该进程当前打开的描述符数。可结合 lsof -p <进程号> 区分套接字、日志和其他文件。
检查系统整体资源：查看 /proc/sys/fs/file-nr，了解已分配文件句柄与系统上限的关系；查看 /proc/net/sockstat，观察 TCP 套接字使用情况。若只有某个进程接近上限，优先检查该服务；若系统资源整体紧张，再评估主机级参数。
确认应用是否真的需要更多长连接，并核对连接池上限、空闲连接回收时间及客户端重试策略。连接数异常增长时，先排查连接未释放或重试风暴，不要用提高上限掩盖程序问题。
根据负载调整，而不是照抄参数
服务进程的 nofile 限制
如果进程描述符数逼近软限制，可先在服务管理器中提高该服务的 LimitNOFILE，并重启服务使新限制生效。修改前后分别核对进程的 /proc/<进程号>/limits。交互式 shell 的 ulimit -n 只影响当前 shell 及其后代进程，通常不会自动改变由 systemd 启动的服务限制。
常见服务可从数万级描述符上限开始评估；连接规模更大时，可能需要更高上限，但应结合内存、进程数量和服务本身的资源消耗核算。进程上限不能超过系统可用范围，设置过高也不会自动提升业务承载能力。
系统句柄与连接队列
当多个进程合计接近系统文件句柄容量时，再评估 fs.file-max；单个服务触及限制则优先调整该服务的 nofile。新连接突发导致监听队列溢出时，可检查应用的 listen backlog 与 net.core.somaxconn，并按内核实际取值和应用配置协调调整。TCP SYN 队列相关参数只针对相应握手阶段的拥塞，不能替代应用队列优化。
短连接客户端还需检查临时端口范围和连接复用。端口范围受系统配置、连接目标及连接状态影响；启用 HTTP 持久连接或合适的连接池，往往比盲目扩大端口范围更直接。调整 TCP 回收相关设置前应核对内核版本和业务行为，避免套用过时建议。
变更后验证与回退
一次只改一类参数，记录原值、修改时间和对应服务，避免同时变更多项后无法定位效果。
在与生产相近的压测或流量观察窗口中，比较连接数、描述符占用、错误率、延迟和内存。上限应留出余量，但余量大小要按峰值波动与进程规模决定。
若错误没有改善，或内存、延迟等指标恶化，恢复原值并继续检查应用连接管理、队列和端口使用情况。
归根结底，高并发业务的主机连接数与文件描述符调优应以观测到的限制为依据：进程碰到 nofile，调服务限制；系统句柄吃紧，评估全局容量；连接队列或端口成为瓶颈，则针对对应环节处理。
常见问题
提高 nofile 后连接数一定会上升吗？
不一定。它只放宽进程可打开描述符的数量，内存、端口、应用配置或内核队列仍可能限制连接规模。
nofile 应该设置为多少？
没有适用于所有主机的固定值。先测高峰描述符数量，再结合预期增长、进程数量和内存评估；常见服务可从数万级起步验证。
TIME_WAIT 很多是否代表描述符耗尽？
不能据此判断。应分别检查活动连接、进程描述符及错误日志，并评估短连接比例与连接复用情况。