必须调稳linux系统级参数才能突破十万并发:fs.file-max=2097152、fs.nr_open=2097152、net.core.somaxconn=65535、tcp_max_syn_backlog=65535、tcp_tw_reuse=1、tcp_fin_timeout=30、tcp_max_tw_buckets=5000、ip_local_port_range="1024 65000",并配合limits.conf与systemd的nofile限制。

单靠改 nginx.conf 无法真正突破十万并发,关键瓶颈往往卡在 Linux 内核层——连接队列溢出、文件描述符耗尽、TIME_WAIT 堆积、端口不够用,这些问题都得靠系统级参数来解。
必须调的文件描述符与监听队列参数
这是高并发的“地基”,不调稳,Nginx 启动都可能报 too many open files 或 accept() failed (24: Too many open files):
- fs.file-max = 2097152:系统级最大文件描述符总数,写入 /etc/sysctl.conf,执行 sysctl -p 生效
- fs.nr_open = 2097152:确保单个进程能突破默认 65535 限制(尤其对 nginx 主进程和 worker 进程)
- net.core.somaxconn = 65535:监听 socket 的全连接队列长度,防止新连接被内核直接丢弃
- net.ipv4.tcp_max_syn_backlog = 65535:SYN 半连接队列大小,应对瞬时建连高峰或 SYN Flood
- net.core.netdev_max_backlog = 65535:网卡接收缓冲队列,避免突发流量下数据包在驱动层就被丢弃
TIME_WAIT 状态必须治理
短连接场景下,大量 TIME_WAIT 会快速占满端口、拖慢新建连接。光靠 Nginx 的 keepalive 压不住:
Linux系统管理专家,覆盖12大模块:用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词:useradd、sudo、sshd_config、chmod、SEL...
- net.ipv4.tcp_tw_reuse = 1:允许内核将处于 TIME_WAIT 的 socket 重用于新连接(客户端有效,服务端需配合 net.ipv4.tcp_timestamps = 1)
- net.ipv4.tcp_fin_timeout = 30:缩短 FIN_WAIT_2 超时,加快被动关闭连接的清理速度
- net.ipv4.tcp_max_tw_buckets = 5000:硬性限制 TIME_WAIT 数量上限,防内核因堆积过多而抖动甚至拒绝新连接
- net.ipv4.ip_local_port_range = "1024 65000":把可用临时端口从默认约 28K 扩展到近 64K,缓解端口枯竭
TCP 缓冲区与 keepalive 协同配置
缓冲区太小,小包延迟高;太大又浪费内存。需匹配 Nginx 的 sendfile、tcp_nopush 等机制:
- net.core.rmem_max = 12582912 和 net.core.wmem_max = 12582912(即 12MB):收发缓冲最大值,支撑万级连接下的带宽利用率
- net.ipv4.tcp_rmem = "4096 65536 12582912" 和 net.ipv4.tcp_wmem = "4096 65536 12582912":三元组设置,让内核根据连接动态扩缩缓冲区
- 搭配 Nginx 的 keepalive_timeout 65 和 keepalive_requests 1000,形成端到端的长连接优化闭环
配套的用户级与运行时限制
内核参数调了,但 nginx 进程本身没权限用,照样白搭:
- 在 /etc/security/limits.conf 中添加:
* soft nofile 1000000
* hard nofile 1000000
(或针对 nginx 用户单独设,如 nginx soft nofile 1000000) - 确保 systemd 服务未覆盖限制:检查 /etc/systemd/system/nginx.service.d/override.conf 是否含 LimitNOFILE=1000000
- 重启 nginx 前,先验证:ulimit -n 应显示 ≥1000000,cat /proc/sys/fs/file-max 应为 2097152










