Nginx配置参数的核心在于合理调整worker进程数、事件模型和缓冲区大小，这三个维度直接决定了服务器的并发处理能力和响应速度。
核心配置参数详解
要玩转Nginx，首先得把几个基础参数吃透，它们就像房子的地基,后面所有优化都建立在这之上。
worker_processes：进程数怎么定？
这个参数控制Nginx启动的worker进程数量，行业共识认为，通常设置为服务器的CPU核心数即可，比如你的服务器是4核，那就设置为4，如果服务器同时承担其他任务，可以适当减少，比如设置为3或2，但不要超过核心数,否则进程切换反而降低效率。
实操建议：先用lscpu或grep ^processor /proc/cpuinfo | wc -l查看核心数，然后直接写到配置里，如果你的服务器是I/O密集型场景，比如大量反向代理，可以适当增加1到2个进程,但经验表明超过核心数两倍后性能提升微乎其微。
worker_connections：每个进程能扛多少连接？
这个参数设置每个worker进程能同时打开的最大连接数，它和worker_processes共同决定了总并发量：总并发 = worker_processes × worker_connections，比如4个进程，每个1024连接,总并发就是4096。
关键点：这个值不是越大越好，Linux系统默认一个进程最多打开1024个文件句柄，如果你设置太高，系统会报错，你需要同时调整系统的ulimit -n，worker_connections设置为1024就够用，对于高并发场景，可以提升到2048或4096,但必须同步加大系统文件描述符限制。
操作路径：修改/etc/security/limits.conf，添加 soft nofile 65535和 hard nofile 65535，然后重启shell或系统，Nginx配置里再设置worker_connections 4096,两者配合才能生效。
事件模型：选对模型事半功倍
Nginx支持多种事件处理模型，比如select、poll、epoll（Linux）、kqueue（FreeBSD）等，在Linux系统上，epoll是默认且最高效的模型，它能处理大量并发连接,并且不会随连接数增加而线性降低性能。
配置示例：
events {
use epoll;
worker_connections 1024;
}大多数情况下你不需要显式指定use epoll，因为Nginx会自动选择当前系统最合适的模型，但如果你明确知道系统支持epoll,写上也没问题。
多核绑定：让进程跑在固定核心上
通过worker_cpu_affinity参数，可以把每个worker进程绑定到特定CPU核心，减少缓存失效和进程切换开销，比如4核CPU，配置worker_cpu_affinity 0001 0010 0100 1000;,让每个进程独占一个核心。
注意：这个参数只在CPU密集型场景下有明显效果，如果服务器主要做I/O转发，绑定与否差别不大，配置前最好用top或htop观察现有CPU负载,再决定是否绑定。
性能调优：让Nginx跑得更快
基础参数设好后，接下来针对性能做微调，这部分主要解决“如何让Nginx在同样硬件下处理更多请求”。
缓冲区设置：减少磁盘I/O
Nginx的缓冲区用于暂存客户端请求和上游响应数据，合理设置缓冲区能减少磁盘读写,提升响应速度。
client_body_buffer_size：客户端请求体缓冲区大小，默认8k或16k，如果经常有大型POST请求，可以适当增大,比如32k。proxy_buffers：反向代理时，后端响应数据的缓冲区数量和大小，例如proxy_buffers 8 16k;，表示8个缓冲区,每个16k。proxy_buffer_size：后端响应头部的缓冲区大小，默认4k，如果头部信息较长（比如Cookie多）,可以设为8k。
经验值：大部分场景下，保持默认即可，如果你发现磁盘I/O频繁，检查access_log和error_log的写入情况，以及是否开启了sendfile。
超时时间：避免资源浪费
合理设置超时时间,能防止慢连接长期占用worker进程。
client_body_timeout：客户端发送请求体超时，默认60秒,可调到30秒。client_header_timeout：客户端发送头部超时，同样60秒,可调到30秒。keepalive_timeout：长连接超时，默认75秒，对于高并发网站，建议降到15-30秒,避免过多空闲连接占用资源。send_timeout：发送响应给客户端的超时，默认60秒,可降到30秒。
注意：不要设置得太短，否则正常用户可能因为网络波动而断开连接，60秒是安全值，如果你追求极致并发,可以压到20秒左右。
压缩配置：节省带宽
开启gzip压缩能显著减少传输数据量，但会消耗CPU,需要权衡。
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml;
gzip_min_length 1000;
gzip_comp_level 2;gzip_comp_level：压缩等级1-9，等级越高压缩率越大，但CPU消耗也越大，通常2-4就够用,推荐2。gzip_min_length：小于该长度的响应不压缩，因为压缩小文件收益不大,一般设为1000字节。
日志优化：减轻I/O压力
日志写入是磁盘I/O的主要来源之一，如果日志量巨大,可以考虑：
- 关闭
access_log或使用缓冲写入：access_log /var/log/nginx/access.log main buffer=32k; - 将
error_log级别设为warn或error,减少告警日志。 - 使用
log_format精简日志字段,去掉不必要的头信息。
常见场景配置：从静态到反向代理
不同业务场景下，Nginx的配置侧重点也不同,下面针对三个典型场景给出具体参数调整建议。
静态文件服务：发挥最大性能
对于图片、CSS、JS等静态资源，Nginx的使命是快速响应,减少磁盘读取。
关键参数：sendfile on;（直接在内核空间传输文件，避免用户态拷贝）。tcp_nopush on;（在发送响应前合并数据包，提升网络利用率）。tcp_nodelay on;（禁用Nagle算法，减少延迟）。
配置片段：
location ~ \.(jpg|jpeg|png|gif|ico|css|js)$ {
expires 30d;
add_header Cache-Control "public, immutable";
root /var/www/static;
sendfile on;
tcp_nopush on;
}expires设置缓存时间，30天是个常见值。immutable告诉浏览器这个文件永远不会变,可以直接从缓存取。
反向代理与负载均衡：后端服务的桥梁
这是Nginx最常用的场景之一，配置反向代理时,核心是处理上游超时和缓冲。
基本配置：
upstream backend {
server 192.168.1.10:8080 weight=3;
server 192.168.1.11:8080 weight=2;
server 192.168.1.12:8080 backup;
}
server {
location /api/ {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 30s;
proxy_read_timeout 30s;
proxy_send_timeout 30s;
proxy_buffering on;
proxy_buffers 8 16k;
proxy_buffer_size 8k;
}
}注意：proxy_buffering on表示开启缓冲，Nginx会等后端响应全部接收后再发送给客户端，适合大文件传输；如果追求实时性,可以关闭。
负载均衡算法：默认是round-robin（轮询），其他还有least_conn（最少连接）、ip_hash（IP哈希，保持会话）、random（随机），如果后端服务器性能差异大，用weight调整权重。
SSL/TLS配置：安全与性能的平衡
HTTPS已经成为标配，但TLS握手会消耗CPU，且增加延迟,优化方向包括：
- 使用TLS 1.3，它比TLS 1.2握手更快,且更安全。
- 开启OCSP Stapling,减少客户端验证证书的额外请求。
- 使用session ticket或session cache,复用会话密钥。
配置示例：
listen 443 ssl http2;
ssl_certificate /etc/nginx/ssl/example.com.crt;
ssl_certificate_key /etc/nginx/ssl/example.com.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets on;
ssl_stapling on;
ssl_stapling_verify on;注意：ssl_ciphers只保留强加密套件，避免使用RC4、3DES等弱算法。http2可以提升多路复用能力,减少连接数。
安全与稳定性：把风险降到最低
除了性能，安全配置也是Nginx参数的重要部分,下面几个参数能帮你挡住常见攻击。
限制请求速率：防刷防爬
limit_req_zone和limit_req可以限制单个IP的请求频率,比如禁止每秒超过10个请求：
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
server {
location /login/ {
limit_req zone=mylimit burst=20 nodelay;
...
}
}rate=10r/s表示每秒10个请求，burst=20允许临时突增20个，nodelay表示突发请求不延迟，而是直接处理，如果超过限制,返回503。
访问控制：白名单与黑名单
通过allow和deny指令，可以控制特定IP或网段的访问权限,例如只允许内网访问管理后台：
location /admin/ {
allow 192.168.0.0/16;
allow 10.0.0.0/8;
deny all;
...
}注意：deny all要放在最后,否则会拒绝所有IP。
隐藏版本号：减少信息泄露
默认Nginx会在响应头里显示版本号，比如Server: nginx/1.24.0,关闭它：
server_tokens off;这样响应头只显示Server: nginx，不暴露具体版本,防止攻击者针对性利用已知漏洞。
nginx配置参数对比：不同场景下的选择建议
很多新手会在几个参数之间纠结，比如epoll和kqueue哪个好？sendfile和directio怎么选？下面用表格对比几组常见参数。
| 参数 | 应用场景 | 推荐值 |
|---|---|---|
worker_processes |
CPU密集型 | 等于CPU核心数 |
worker_connections |
高并发 | 1024-4096，配合ulimit |
use epoll |
Linux | 默认，无需手动设置 |
sendfile |
静态文件 | 开启 |
tcp_nopush |
大文件传输 | 开启 |
tcp_nodelay |
小文件、实时通信 | 开启 |
proxy_buffering |
反向代理大响应 | 开启 |
gzip_comp_level |
节省带宽 | 2-4 |
keepalive_timeout |
长连接场景 | 15-30秒 |
对比说明：sendfile和directio不冲突，前者用于静态文件加速，后者用于绕过系统缓存，适合大文件传输，如果服务器内存充足，用sendfile就够了。directio需要配合directio alignment,一般场景用不上。
配置参数常见问题解答
nginx配置中worker_connections设置多少合适？
这个值取决于你的系统文件描述符限制和内存，每个连接大约占用2-3KB内存，1024个连接约3MB，4096个约12MB，如果你的服务器内存充足，且预期并发连接数较高，可以设置到4096，但必须确保ulimit -n大于这个值，否则Nginx启动时会报错，一个稳妥的做法是：先设置1024，压测观察资源占用,然后逐步提升。
nginx反向代理时，proxy_buffers和proxy_buffer_size的区别是什么？
proxy_buffer_size用于存储后端响应的头部信息，默认4KB，如果头部太大（比如包含大量Cookie或自定义头），需要调大，否则会返回502或头部截断。proxy_buffers则用于存储响应体，多个缓冲区组成一个缓冲池，两者共同决定Nginx能缓存多少上游数据,避免后端发送过快时Nginx来不及转发。
nginx配置access_log buffer对性能提升有多大？
开启缓冲写入后，日志不会实时写到磁盘，而是攒够一定量再一次性写入，这能显著减少磁盘I/O次数，提升整体吞吐量，据统计，在高并发场景下，日志缓冲可以降低I/O占用50%以上，但代价是如果服务器突然宕机，缓冲区内的日志会丢失，所以对于关键业务日志，建议保留实时写入,或者使用双写策略。
回到最核心的那句话：Nginx配置参数没有万能公式，但抓住worker进程数、事件模型和缓冲区这三个杠杆，你已经能解决90%的性能问题。 其他参数像调料一样，根据具体菜系（场景）适量添加，剩下的就是不断压测和观察,找到最适合你业务的那一味。