如何把 Nginx 的 worker 进程和连接数调到更适合高并发的状态？这不是简单地把参数拉到最大，而是要把 CPU 核心数、单个 worker 能处理的连接数、Linux 文件描述符上限和真实流量模型放在一起看。很多站点一到峰值就出现连接排队、502、too many open files 或者“CPU 没跑满但响应已经变慢”的情况，根源往往不是 Nginx 不够快，而是参数之间没有配平。
如果你想先理解 Nginx 在反向代理场景里是怎么承担请求入口的，可以先看这篇 Web 服务器配置实战指南。本文会把重点放在 worker 进程、连接数和系统限制这三层，给你一套更适合实战的调优顺序。为了避免只会改配置不会验证，文中也会直接给出检查命令和回滚思路。这里的 DNS（域名系统）也不能忽略，因为域名解析慢、解析错误或切换记录未生效，都会让你误以为是 Nginx 连接数不够。
如果你正是在 Hostease 的 [VPS](https://cn.hostease.com/vps/)（[虚拟专用服务器](https://cn.hostease.com/vps/)）上做这类调优，可以把本文当成一份排查清单：先看 worker，再看连接，再看系统上限，最后再压测验证。这样更容易判断问题到底出在入口层、应用层还是网络层。
先看清楚：worker_processes 和 worker_connections 不是一回事
Nginx 官方文档里，worker_processes 和 worker_connections 属于两个不同层级的参数。前者决定启动多少个 worker 进程，后者决定每个 worker 最多同时处理多少连接。很多人把这两个参数混在一起，结果就是看到“连接数上去了”就觉得问题解决了，但真正的瓶颈可能还卡在 CPU、系统文件描述符或者上游应用响应速度上。
更实用的理解方式是：worker_processes 负责让多少个 CPU 核心一起干活，worker_connections 负责单个 worker 的并发承载上限。假设一台机器有 4 个核心，worker_processes auto; 通常比手工写死 1 更合理，因为它会让 Nginx 自动按可用核心数启动 worker。至于 worker_connections，它不是“越大越好”，而是要和系统级限制、长连接数量、反向代理方式一起评估。
如果你在做站点性能侧的整体梳理，也可以参考这篇 Nginx 请求限流配置。限流并不是和连接数调优互相替代的，它更多是帮你把突发流量削平，避免连接数刚放大就把上游应用一起压垮。
推荐的调优顺序：先 worker，再连接，再系统限制
真正可落地的顺序，通常是先把 worker 进程配到合理值，再把单 worker 的连接数放到合适区间，最后再检查系统上限。这样做的好处是，你能明确知道每一步到底改善了什么，而不是改完一堆参数后连问题来自哪一层都分不清。
一个常见的起点可以写成下面这样：
worker_processes auto;
worker_rlimit_nofile 65535;
events {
worker_connections 4096;
multi_accept on;
use epoll;
}
这里最关键的不是数字本身，而是逻辑。worker_processes auto 让 worker 数量跟着 CPU 核心走；worker_rlimit_nofile 把单个 worker 能打开的文件描述符上限抬高；worker_connections 则给单 worker 留出足够连接空间。实际生产环境里，你还要同时检查系统级的 ulimit -n，否则 Nginx 配置再大，也会被系统上限卡住。
如果你的站点已经有静态资源缓存和反代链路，可以再看看 Nginx 缓存清理与回源机制。缓存命中高的时候，请求并不会全部落到后端应用上，这会直接影响你该把连接数调到多少；反过来，缓存失效后，后端压力又会迅速上升，所以连接数配置不能脱离缓存策略单独判断。
判断参数是否够用，要看三类信号
第一类信号来自 Nginx 自己。你可以查看 error log 里有没有 worker_connections are not enough、too many open files 或者类似的警告。如果这些日志开始出现，说明不是“流量太大所以正常慢”，而是参数已经碰到边界。
第二类信号来自系统。执行 ulimit -n 看当前进程可打开的文件数，再用 ss -s 或 netstat -an 看现有连接规模。如果 worker 连接数看起来很高，但系统文件描述符离上限还很远，瓶颈可能在上游应用、磁盘 IO 或者 DNS 解析，而不在 Nginx 本身。
第三类信号来自压测。用 wrk、ab 或者你自己的压测脚本，观察 QPS、延迟分位数和错误率是否稳定。很多站点在低并发时看不出问题，一旦并发拉高，响应时间会突然抖动，这通常意味着 worker 数量、连接数和上游吞吐之间没有对齐。
如果你正在做服务器迁移或者准备重构整套环境，别忘了把配置变更同步做备份。Restic 增量备份实践 这类方案适合把 Nginx 配置、应用配置和关键数据一起保住，出了问题也方便快速回滚。
一套更稳的排查方法，比“盲调大数值”更重要
先确认 Nginx 是否真的需要更高的并发承载，再决定是否提高参数。比如，如果你的站点大部分流量都被缓存命中，实际打到后端的请求并不多，过高的 worker_connections 反而会让你误判问题；如果你的站点是动态内容为主，后端响应慢、长连接多，那就要优先看上游应用和数据库，而不是先怪 Nginx。
一个实用的检查流程可以这样走：先用 nginx -t 确认配置语法，再用 nginx -T 查看完整生效配置，然后观察运行中的连接数和错误日志。若发现当前 worker 还没有跑满，但系统已经频繁报错，可以优先提升 worker_rlimit_nofile 和系统层文件描述符；若 CPU 已经接近满载，再继续加 worker 才更有意义。
对于跑在 VPS（虚拟[专用服务器](https://cn.hostease.com/dedicated-server/)）上的中小站点，这种分层排查尤其重要。VPS 的资源虽然是独立分配的，但它的性能上限仍然要结合业务请求模式来看，而不是只看机器规格表。换句话说，配置不是越高越好，而是要和你的真实流量、缓存命中率和后端处理能力匹配。
实战里最容易忽略的几个点
第一，worker_processes 设得比 CPU 核心数还高，通常不会带来正收益，反而可能增加上下文切换。第二，worker_connections 只代表单个 worker 的上限，不等于整台机器的总上限。第三，如果上游应用慢，Nginx 的连接数再高也只是把等待队列变长。
第四，调优时不要只看平均值。平均 QPS 上去了，不代表尾延迟也改善了；平均 CPU 没满，也不代表不会在某个瞬间打爆连接池。第五，改配置后一定要在流量相近的时段复测，最好保留一份旧配置，这样一旦新参数不稳定，可以马上切回。
如果你还想进一步优化整体站点架构，可以把本文的连接数调优和反向代理、缓存、限流放在一起看。这样你就不会只盯着单个参数，而是能从入口层、缓存层和应用层同时找出瓶颈，避免“调了半天，问题还在原地”。
如果你希望把这套方法迁移到自己的生产环境，建议先保存当前配置，再按小步修改的方式逐项验证。我们更推荐先从 worker_processes auto、合理的 worker_connections 和系统级 ulimit 三个点入手，再逐步扩大压测范围。
总结
Nginx worker 调优的核心，不是把数字调到最大，而是让 worker 数量、连接数上限和系统文件描述符彼此匹配。最稳的思路永远是：先确认有没有真实瓶颈，再逐层调参数，最后用日志和压测结果验证。
如果你准备把这套方法用到生产环境，建议先在测试机上完成一轮小流量验证，再逐步放大到正式环境；如果当前站点已经频繁出现连接报错或响应抖动，推荐先从 worker_processes auto、合理的 worker_connections 和系统级 ulimit 三个点入手，再继续做更细的压测和回滚预案。建议你这样推进。