在云服务器上部署网站时，Nginx 几乎是最常见的 Web 服务之一。它以高并发、低资源占用而著称，但很多新手站长在实际使用过程中却发现一个问题：服务器配置看起来并不低，访问量一上来却容易卡顿，CPU 忽高忽低，甚至偶尔出现 502 或连接超时。这种情况往往并不是云服务器性能不足，而是 Nginx 的 worker 参数没有进行合理调优。

　　默认安装的 Nginx 更偏向“通用场景”，而不是针对具体服务器环境优化。对于云服务器来说，CPU 核心数、内存大小、网络带宽、访问并发差异都很大，如果直接使用默认配置，很容易无法充分利用资源，或者反过来把系统拖垮。因此，对 Nginx worker 相关参数进行针对性调整，是云服务器性能优化中非常重要的一步。

　　在开始修改配置之前，先简单理解 Nginx 的工作模型。Nginx 采用的是多进程事件驱动架构，其中最核心的两个参数就是 worker_processes 和 worker_connections。前者决定开启多少个工作进程，后者决定每个进程最多能处理多少连接。理论最大并发数大致等于这两个参数的乘积。

　　先来看 worker_processes。这个参数直接关系到 CPU 的利用效率。常见写法有两种：

worker_processes auto;

　　或者：

worker_processes 4;

　　在云服务器环境中，最推荐的做法是使用 auto。这样 Nginx 会自动识别 CPU 核心数量，并为每个核心分配一个 worker 进程。例如 4 核服务器就会启动 4 个 worker。这种方式既简单又安全，基本不会出错。只有在非常特殊的场景下，才需要手动指定具体数值。

　　可以通过以下命令查看当前服务器 CPU 核心数：

nproc

　　如果你坚持手动设置，一般原则是不要超过 CPU 核心数，否则多个 worker 会争抢同一核心，反而降低效率。

　　接下来是 worker_connections。它表示单个 worker 进程允许的最大连接数。默认值通常是 1024，这对很多云服务器来说偏小。你可以在 nginx.conf 中找到类似配置：

events {
    worker_connections 1024;
}

　　对于普通网站，建议至少提升到 4096：

events {
    worker_connections 4096;
}

　　如果是高并发场景，可以设置为 8192 或更高。但要注意，系统本身也有文件句柄限制，如果只改 Nginx 而不改系统限制，很容易遇到“too many open files”的错误。

　　因此在调整 worker_connections 的同时，建议同步提升系统文件描述符上限。可以编辑：

nano /etc/security/limits.conf

　　加入：

* soft nofile 65535
* hard nofile 65535

　　然后在 Nginx 配置中补充：

worker_rlimit_nofile 65535;

　　这样才能保证 Nginx 真正用得上更高的连接数。

　　仅仅设置 worker 数量还不够，事件模型同样重要。Linux 云服务器推荐使用 epoll：

events {
    use epoll;
    worker_connections 4096;
}

　　epoll 在大量并发连接下效率明显高于 select 和 poll，是现代 Linux 的最佳选择。

　　接下来是 accept_mutex。这个参数决定多个 worker 是否轮流接收新连接。一般情况下保持开启即可：

accept_mutex on;

　　如果是高并发短连接场景，可以尝试关闭：

accept_mutex off;

　　但对新手来说，默认开启更稳妥。

　　另一个经常被忽略的参数是 multi_accept，它控制 worker 是否一次性接收所有等待连接：

multi_accept on;

　　开启后在流量突增时可以更快建立连接，但会带来瞬时 CPU 压力。中小规模网站可以开启，大型站点建议结合实际负载测试。

　　完成 worker 层面的基础调优后，还需要结合 keepalive 参数，否则大量短连接会迅速消耗 worker 资源。推荐设置：

keepalive_timeout 30;
keepalive_requests 1000;

　　这样可以复用连接，减少频繁握手带来的性能损耗，尤其对 HTTPS 网站帮助明显。

　　在云服务器环境中，还建议开启 sendfile 和 tcp_nopush：

sendfile on;
tcp_nopush on;
tcp_nodelay on;

　　这组参数能减少内核拷贝次数，提高静态资源传输效率。

　　修改完成后，不要直接重启 Nginx，先测试配置是否正确：

nginx -t

　　确认无报错，再执行：

systemctl reload nginx

　　使用 reload 可以平滑加载新配置，不会中断当前连接。

　　调优完成后，建议通过以下方式观察效果：

nginx -V

　　确认模块支持情况，同时配合top、ss -s查看 CPU 使用率和连接状态。如果发现连接数明显提升而 CPU 仍保持稳定，说明 worker 参数已经发挥作用。

　　很多站长还会问：worker 参数是不是越大越好?答案是否定的。worker_processes 超过 CPU 核心会增加上下文切换，worker_connections 过高会占用大量内存。合理的调优永远是“刚好够用”，而不是一味拉满。

　　一个比较稳妥的通用组合是：

worker_processes auto;
worker_rlimit_nofile 65535;

events {
    use epoll;
    worker_connections 4096;
    multi_accept on;
}

　　然后根据实际访问量再逐步调整。

　　从实践来看，很多云服务器性能问题并不是硬件不足，而是 Nginx 默认配置限制了并发能力。当你真正理解 worker_processes 决定并行度、worker_connections 决定容量上限之后，就能有针对性地释放服务器潜力。

　　对于新手站长来说，只要记住几个关键点即可：worker 跟随 CPU 核心、连接数配合系统限制、开启 epoll、合理使用 keepalive。这套组合已经能覆盖绝大多数中小网站和独立站场景。