Nginx性能优化应该先改哪些参数

马哥Linux运维 2026-04-21 330

描述

背景与问题

Nginx 是高性能 HTTP 服务器和反向代理服务器，默认配置适合低流量场景。当 QPS（每秒请求数）达到数千甚至数万时，默认配置会成为性能瓶颈。表现为：服务器 CPU 使用率不高但请求开始排队、响应时间随并发增加急剧上升、连接数达到上限后开始拒绝服务。

本文以 Nginx 1.27.x 版本为基准，系统讲解高并发场景下必须调整的核心参数，以及每个参数调整背后的原理。内容包括：工作进程配置、连接管理、缓冲区优化、缓存策略、 upstream 负载均衡调优、HTTP 协议优化、以及内核参数调整。文章覆盖的参数都经过生产环境验证，调整思路按优先级排序，读者可以根据实际场景按图索骥。

1. 参数调整总览与优先级

Nginx 参数调整有明确的优先级顺序。错误地调整低优先级参数可能无效，而正确地调整高优先级参数能立即见效。优先级从高到低：

第一层是操作系统内核参数，影响 Nginx 能处理的最大连接数和文件描述符上限。第二层是 Nginx 进程模型配置，即 worker 进程数和连接处理方式。第三层是每个连接的内存缓冲区配置。第四层是 upstream 负载均衡和 keepalive 配置。第五层是 HTTP 协议层面的优化，如 gzip、chunked 编码等。

按这个顺序逐层调整，每调整一层后观察效果，避免盲目修改。

2. 内核参数调整

2.1 文件描述符上限

Nginx 每个连接需要占用一个文件描述符（FD），同时还需要额外的文件描述符用于打开日志文件、连接 upstream、打开缓存文件等。默认系统限制通常为 1024，远不够高并发使用。

检查当前限制：

# 查看系统级别的最大文件描述符
cat /proc/sys/fs/file-max

# 查看当前已使用的文件描述符数量
cat /proc/sys/fs/file-nr

# 查看 nginx 进程允许的最大 FD（soft limit）
cat /proc/$(cat /var/run/nginx.pid)/limits | grep "Max open files"

调整系统级限制：

# 在 /etc/sysctl.conf 中添加
fs.file-max = 1000000

# 使配置生效
sysctl -p

调整用户级限制（在 /etc/security/limits.conf 中）：

nginx soft nofile 100000
nginx hard nofile 100000

在 Nginx 配置中设置：

worker_rlimit_nofile 100000;

这个参数设置了 Nginx worker 进程能打开的最大文件描述符数量。应设置为与用户级限制一致。计算公式：理论最大连接数 = worker_rlimit_nofile / 2（因为每个连接需要 1 个 FD，还要留一些给日志、upstream、缓存等）。

2.2 网络内核参数

高并发场景下，网络积压队列和连接复用相关的内核参数必须调整：

# 在 /etc/sysctl.conf 中添加
# 调整 SOMAXCONN（Socket 监听队列最大长度）
net.core.somaxconn = 65535

# 调整 tcp 连接队列大小
net.ipv4.tcp_max_syn_backlog = 65535

# 允许 TIME_WAIT 状态的 socket 重用
net.ipv4.tcp_tw_reuse = 1

# 调整 TIME_WAIT 超时时间（毫秒）
net.ipv4.tcp_fin_timeout = 15000

# 调整 TCP keepalive 探测间隔
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3

# 调整本地端口范围
net.ipv4.ip_local_port_range = 1024 65535

# 调整 tcp 最大包缓冲大小
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

使配置生效：sysctl -p

参数原理解析：

net.core.somaxconn 是 listen() 系统调用的 backlog 队列长度。当 Nginx 调用 listen() 时，内核会将未 accept 的连接放入这个队列。如果队列满了，新连接会被拒绝。Nginx 默认的 backlog 为 511，如果上游处理速度跟不上连接到达速度，这个队列会很快填满。

net.ipv4.tcp_max_syn_backlog 是 SYN 队列的长度。当客户端发送 SYN 包后，服务器回复 SYN-ACK 但还未收到最后的 ACK 时，连接处于半开状态，放在 SYN 队列中。如果 SYN 队列满了，新的 SYN 包会被丢弃，导致连接建立失败。

net.ipv4.tcp_tw_reuse 允许将 TIME_WAIT 状态的 socket 重用于新的 outbound 连接。这在 Nginx 作为客户端连接 upstream 时特别有用，减少本地端口耗尽的问题。

net.ipv4.tcp_fin_timeout 缩短 TIME_WAIT 持续时间。默认 60 秒，在高并发场景下会占用大量端口资源。

3. Nginx 进程模型配置

3.1 worker 进程数

Nginx 采用多进程模型：一个 master 进程负责管理，多个 worker 进程处理请求。默认配置只有一个 worker 进程，远不能利用多核 CPU。

检查 CPU 核心数：

nproc
# 或者
grep processor /proc/cpuinfo | wc -l

设置 worker 进程数：

worker_processes auto;

auto 表示 Nginx 自动设置为 CPU 核心数，这是最推荐的配置。如果设置为具体数字，必须确保与 CPU 核心数匹配。worker 进程数不是越多越好：进程数过多会增加进程切换开销，每个进程还要占用独立内存。

3.2 worker 连接数上限

每个 worker 进程能处理的连接数受 worker_connections 限制。这个参数定义了单个 worker 能同时持有的最大连接数：

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

use epoll：Linux 下使用 epoll 事件模型，这是最高效的 I/O 多路复用机制。FreeBSD 下使用 kqueue，Windows 下使用 select。

multi_accept on：允许一个 worker 进程同时接受多个新连接。默认 off 意味着一次只 accept 一个连接。如果流量集中到达，未 accept 的连接会排队等待。

worker_connections 65535 是理论上限，实际设置需要结合 worker_rlimit_nofile 的值。计算方式：worker_connections * worker_processes 不能超过 worker_rlimit_nofile。

3.3 绑定 worker 到特定 CPU

将 worker 进程绑定到特定 CPU 核心，可以避免进程切换带来的缓存失效：

worker_cpu_affinity auto;

auto 会自动将每个 worker 绑定到不同的 CPU 核心。如果需要手动指定：

worker_cpu_affinity 0001 0010 0100 1000;  # 4 worker 对应 4 核心
worker_cpu_affinity 0101 1010;              # 2 worker 对应 4 核心（每进程绑定2个）

手动指定在 NUMA 架构服务器上特别有用，可以控制每个 worker 只访问本地内存，减少跨 NUMA 节点的内存访问延迟。

3.4 调整 worker 优先级

如果服务器上还运行着其他重要服务，可以适当降低 Nginx worker 的优先级，避免 Nginx 抢光 CPU：

worker_priority -10;

负数表示更高优先级（Linux 中 Nice 值）。默认 0，降低到 -10 可以让 Nginx 在争抢时获得更多 CPU 时间。但如果服务器专门跑 Nginx，不需要调整。

4. 缓冲区配置

4.1 客户端连接缓冲区

客户端请求的headers和body需要缓冲区来存储。缓冲区太小会导致 nginx 频繁读写磁盘，太大会占用过多内存：

http {
    # client header buffer size
    client_header_buffer_size 4k;
    large_client_header_buffers 4 32k;

    # client body buffer size（上传文件大小控制）
    client_body_buffer_size 128k;

    # 最大允许的 request body 大小（在 server/location 中设置）
    client_max_body_size 100m;
}

client_header_buffer_size：存储请求头的缓冲区大小。普通请求的 headers 通常小于 1KB，4KB 足够。如果存在大量 cookies 或较大的 headers，可以增大。

large_client_header_buffers：如果请求头太大超出 client_header_buffer_size，会使用这个缓冲区。第一个数字是缓冲区数量，第二个是每个缓冲区大小。如果出现大量 400 Bad Request 错误且错误日志显示 "request header is too large"，需要增加这个值。

client_body_buffer_size：存储请求 body 的缓冲区大小。如果 body 超过这个大小，会写入临时文件。默认是磁盘上的 tmpfs（如果配置了client_body_temp_path）。这个值设置得太小会导致频繁写磁盘，设置得太大会占用过多内存。

4.2 upstream 缓冲区

upstream 响应数据也需要缓冲区。启用缓冲区可以让 Nginx 异步处理 upstream 响应，减少阻塞：

upstream backend {
    server 127.0.0.1:8080;
    keepalive 32;
}

proxy_buffer_size 128k;
proxy_buffers 4 128k;
proxy_buffering on;
proxy_busy_buffers_size 256k;

proxy_buffer_size：存储 upstream 响应的 headers 部分。这个值应该大于 upstream 可能返回的最大 headers 大小。

proxy_buffers：存储 upstream 响应的 body 部分。第一个数字是缓冲区数量，第二个是每个缓冲区大小。如果 upstream 返回大文件，这个值需要足够大。

proxy_buffering on：启用响应缓冲。如果关闭，Nginx 同步转发 upstream 响应，会阻塞 worker 进程直到数据传输完成。对于静态文件和大多数 API 响应，开启缓冲是最佳选择。

proxy_busy_buffers_size：当这个大小的缓冲区被填满后，开始向客户端发送数据，同时继续从 upstream 读取数据填充缓冲区。这个值应该是 proxy_buffers 单个缓冲区的 2-3 倍。

4.3 FastCGI 缓冲区（PHP-FPM 场景）

如果 Nginx 后端是 PHP-FPM，使用 fastcgi 缓冲区配置：

fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 256k;
fastcgi_connect_timeout 60s;
fastcgi_send_timeout 60s;
fastcgi_read_timeout 60s;

fastcgi_connect_timeout：与 FastCGI 服务器建立连接的超时时间。不建议超过 75 秒。

fastcgi_send_timeout：向 FastCGI 服务器发送请求的超时时间。不是整个响应传输时间，而是两次写操作之间的超时。

fastcgi_read_timeout：从 FastCGI 服务器读取响应的超时时间。如果 PHP 脚本执行时间很长，需要增大这个值。

5. 超时配置

5.1 客户端超时

http {
    # 客户端保持连接的超时（两次请求之间）
    keepalive_timeout 65;

    # 客户端发送请求头的超时
    client_header_timeout 15s;

    # 客户端发送请求体的超时
    client_body_timeout 15s;

    # 响应发送超时（两次写操作之间）
    send_timeout 30s;
}

keepalive_timeout：HTTP keep-alive 保持连接的时间。设置太短会导致频繁建立连接增加开销；设置太长会占用连接资源。65 秒是常见的折中值。

client_header_timeout：客户端必须在指定时间内发送完整的请求头。如果超时，返回 408 Request Timeout。

client_body_timeout：客户端必须在指定时间内发送完整的请求体。如果超时，返回 408 Request Timeout。

send_timeout：向客户端发送响应时的超时。不是整个响应发送完成的时间，而是两次 write 操作之间的超时。如果客户端接收数据慢，Nginx 会在这个时间后关闭连接。

5.2 upstream 超时

upstream backend {
    server 127.0.0.1:8080;
    keepalive 32;
    keepalive_requests 1000;
    keepalive_timeout 60s;
}

keepalive：连接池中保持的空闲连接数量。这个数量不是越大越好：每个连接占用文件描述符和内存，过多会造成资源浪费。通常设置为 expected concurrent requests / worker_processes。

keepalive_requests：一个 keepalive 连接最多处理的请求数。处理完指定数量后，连接会被关闭并重新建立，防止内存泄漏。

keepalive_timeout：keepalive 连接保持空闲的超时时间。

6. 压缩与传输优化

6.1 Gzip 压缩

启用 gzip 压缩可以大幅减少传输数据量，提升响应速度：

http {
    gzip on;
    gzip_vary on;
    gzip_min_length 1024;
    gzip_proxied any;
    gzip_comp_level 4;
    gzip_types text/plain text/css text/xml application/json application/javascript application/xml application/xml+rss;
    gzip_buffers 16 8k;
    gzip_http_version 1.1;
    gzip_disable "MSIE [1-6].";
}

gzip on：启用 gzip 压缩。

gzip_vary on：在响应头中添加 Vary: Accept-Encoding，告诉缓存服务器根据 Accept-Encoding 缓存不同版本。

gzip_min_length 1024：小于 1024 字节的响应不压缩。压缩小文件的压缩率低且消耗 CPU，不值得。

gzip_proxied any：代理请求也启用压缩，不管请求头是什么。

gzip_comp_level 4：压缩级别 1-9。级别越高压缩率越高，但 CPU 开销也越大。4 是平衡点，大多数场景下最优。

gzip_types：指定要压缩的 MIME 类型。不在列表中的内容不会被压缩。

**gzip_disable "MSIE [1-6]."**：禁止 IE6 对 gzip 内容的处理（IE6 对 gzip 支持有 bug）。

6.2 静态资源缓存

对于不常变化的静态资源，设置长期缓存减少重复请求：

location ~* .(jpg|jpeg|png|gif|ico|css|js|woff|woff2|ttf|eot)$ {
    expires 30d;
    add_header Cache-Control "public, no-transform";
    access_log off;
}

expires 30d：设置缓存时间为 30 天。静态资源应该设置较长的缓存时间。

**add_header Cache-Control "public, no-transform"`**：添加缓存控制头。public 表示任何缓存都可以存储；no-transform 表示不允许转换内容（如禁止 CDN 重新压缩图片）。

access_log off：关闭静态资源的日志记录，减少无效日志。

6.3 Sendfile 零拷贝

Linux 的 sendfile 系统调用可以减少内核态与用户态之间的数据拷贝：

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
}

sendfile on：启用 sendfile 系统调用。这是 Linux 高效传输文件的标准方式，避免了内核缓冲区到用户缓冲区再到网络缓冲区的多次拷贝。

tcp_nopush on：在 Linux 上启用。与 sendfile 配合使用，当发送 HTTP 响应头时，先不发送数据包，而是积累数据然后一次性发送。这减少了网络小包的数量。

tcp_nodelay on：禁用 Nagle 算法。对于实时性要求高的应用（如 SSH、游戏），应该启用；对于 HTTP 服务，两个都应该启用。

7. 连接处理优化

7.1 HTTP/2 配置

HTTP/2 相比 HTTP/1.1 有显著的性能优势：多路复用减少了连接数，头部压缩减少了传输量，服务器推送可以主动发送资源：

http {
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'TLS_AES_256_GCM_SHA384TLS_AES_128_GCM_SHA256';
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared10m;
    ssl_session_timeout 1d;
}

server {
    listen 443 ssl http2;
    server_name example.com;
}

listen 443 ssl http2：启用 HTTP/2。Nginx 1.27 版本已经完整支持 HTTP/2。

ssl_session_cache：SSL session 缓存，减少 SSL 握手开销。10MB 可以缓存约 40000 个 session。

ssl_session_timeout：SSL session 缓存有效期。

ssl_prefer_server_ciphers on：使用服务器端配置的加密套件优先级，而不是客户端的偏好。这确保了使用最安全的配置。

7.2 upstream keepalive 配置

Nginx 与 upstream 之间的连接复用是提升性能的关键：

upstream backend {
    server 127.0.0.1:8080;
    keepalive 64;
    keepalive_requests 10000;
    keepalive_timeout 60s;
}

location / {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
}

proxy_http_version 1.1：HTTP/1.1 才支持 keep-alive。

**proxy_set_header Connection ""**：清除 Connection 头，避免传递 close 指令导致连接被关闭。设置空字符串表示使用持久连接。

keepalive 64：每个 upstream server 保持 64 个空闲连接。如果有 4 个 upstream 进程，则总共有 256 个持久连接。

keepalive_requests 10000：每个连接处理 10000 个请求后关闭，防止内存泄漏。

7.3 连接队列与限流

在高并发场景下，需要限制最大并发数防止压垮 upstream：

limit_req_zone $binary_remote_addr zone=req_limit:10m rate=1000r/s;
limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

server {
    location / {
        # 限流：每秒 1000 个请求
        limit_req zone=req_limit burst=2000 nodelay;

        # 连接数限制：每个 IP 最多 100 个并发连接
        limit_conn conn_limit 100;

        proxy_pass http://backend;
    }
}

limit_req_zone：定义限流规则。$binary_remote_addr 是客户端 IP 的二进制形式，比字符串形式更省内存。

rate=1000r/s：每秒钟 1000 个请求。burst=2000 表示允许突发到 2000 个请求。nodelay 表示突发请求不延迟处理。

limit_conn：限制单个客户端的并发连接数。超过后返回 503 Service Unavailable。

8. 缓存配置

8.1 代理缓存

Nginx 可以缓存 upstream 响应，减少对后端服务器的请求：

proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=api_cache:100m max_size=10g inactive=60m use_temp_path=off;

server {
    location /api/ {
        proxy_pass http://backend;
        proxy_cache api_cache;
        proxy_cache_valid 200 60s;
        proxy_cache_valid 404 10s;
        proxy_cache_use_stale error timeout updating;
        add_header X-Cache-Status $upstream_cache_status;
    }
}

proxy_cache_path：定义缓存存储路径和参数。

levels=1:2：缓存键的目录层级

keys_zone=api_cache:100m：共享内存区名称和大小，100m 可以缓存约 100 万个 key

max_size=10g：缓存最大磁盘占用

inactive=60m：60 分钟内未被访问的缓存自动清除

use_temp_path=off：缓存直接写入最终路径，不经过临时目录，减少文件移动

proxy_cache_valid：不同状态码的缓存有效期。200 响应缓存 60 秒，404 缓存 10 秒。

proxy_cache_use_stale：当 upstream 发生错误或超时时，使用旧的缓存响应。这提升了用户体验，但需要业务上接受返回旧数据的风险。

$upstream_cache_status：显示缓存命中状态，值为 HIT/MISS/EXPIRED/UPDATING/BYPASS/STALE。这个 header 帮助前端判断数据是否来自缓存。

8.2 缓存清理

当 upstream 数据更新时，需要主动清理缓存：

# 需要加载 ngx_cache_purge 模块
location ~ /purge(/.*) {
    proxy_cache_purge api_cache $1;
}

使用方式：curl -X PURGE http://example.com/purge/api/users/123

这会在数据更新后主动清除缓存，确保用户立即获取最新数据。

9. 负载均衡策略选择

9.1 轮询与加权轮询

默认的负载均衡策略是轮询，每个 upstream 依次处理请求：

upstream backend {
    server 127.0.0.1:8080 weight=5;
    server 127.0.0.1:8081 weight=3;
    server 127.0.0.1:8082 weight=2;
}

加权轮询用于 upstream 性能不一致的场景。weight 越大的 server 分到的请求越多。性能好的机器 weight 设置更高。

9.2 最少连接数

最少连接数策略将请求发送到当前连接数最少的 upstream：

upstream backend {
    least_conn;
    server 127.0.0.1:8080;
    server 127.0.0.1:8081;
}

适合请求处理时间差异较大的场景。长时间占用连接的请求不会让某台 upstream 过载。

9.3 IP 哈希

IP 哈希策略保证来自同一 IP 的请求始终打到同一台 upstream：

upstream backend {
    ip_hash;
    server 127.0.0.1:8080;
    server 127.0.0.1:8081;
    server 127.0.0.1:8082;
}

适合需要会话保持的场景。但当某台 upstream 下线时，可能导致会话丢失（除非使用 ip_hash 配合 down）。

9.4 最少响应时间

Nginx Plus（商业版）支持最少响应时间策略，将请求发送到平均响应时间最短的 upstream。开源版可以通过第三方模块如 nginx-upsync-module 或 Consul 配合实现动态负载均衡。

10. 高可用与容灾

10.1 upstream 健康检查

Nginx 开源版没有内置健康检查，需要通过配置实现被动健康检查：

upstream backend {
    server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:8081 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:8082 max_fails=3 fail_timeout=30s;
}

max_fails=3：连续 3 次失败后，认为该 server 不可用。

fail_timeout=30s：不可用状态持续 30 秒后，重新尝试该 server。

这种被动检查依赖真实请求来判断 server 健康状态。如果某台 upstream 挂了，在排查完成前会有少量失败请求。

10.2 backup 与 down

upstream backend {
    server 127.0.0.1:8080 weight=5;
    server 127.0.0.1:8081 weight=3;
    server 127.0.0.1:8082 backup;  # 备份 server
}

backup：标记为备份 server。只有在所有非 backup server 都不可用时，才启用。

down：标记为永久下线，用于临时维护。

10.3 主备架构

在双 Nginx 主备场景中，使用 Keepalived 做 VIP 漂移：

# Nginx Master 配置
virtual_server 192.168.1.100 443 {
    delay_loop 6
    lb_algo rr
    lb_kind VRRP
    persistence_timeout 0
    protocol TCP

    real_server 192.168.1.101 443 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }

    real_server 192.168.1.102 443 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

Keepalived 定期探测 real_server 的健康状态，当 Master 不可用时，VIP 自动漂移到 Backup。这个架构保证 Nginx 层的 HA。

11. 生产环境验证清单

完成参数调整后，必须逐项验证：

Nginx 配置语法正确：nginx -t

文件描述符上限已生效：ulimit -n 应显示 100000 或更大

worker 进程数正确：ps aux | grep nginx 应显示多个 worker

端口监听正常：ss -tlnp | grep nginx 应显示监听端口

upstream 连接池生效：观察 netstat -an | grep ESTABLISHED | grep upstream_port 连接数

限流生效：使用 ab 或 wrk 压测验证

缓存生效：检查 X-Cache-Status 响应头显示 HIT

性能提升验证：对比调整前后的 QPS 和延迟 P99

12. 常见误区

12.1 误区一：worker_processes 设置越大越好

实际：worker_processes 应该等于 CPU 核心数。超过 CPU 核心数后，进程切换开销反而降低性能。可以用 top 或 htop 观察 CPU 使用率，如果多个 worker 的 CPU 使用率都接近 100% 且总体已无提升空间，说明配置合理。

12.2 误区二：worker_connections 设置为系统最大 FD

实际：worker_connections * worker_processes 必须小于 worker_rlimit_nofile。因为除了连接，还有日志文件、upstream 连接、缓存文件描述符等占用。通常 worker_connections 设置为 worker_rlimit_nofile 的 60-70% 较为安全。

12.3 误区三：gzip 压缩级别越高越好

实际：gzip 压缩级别 1-9，级别越高压缩率提升有限但 CPU 开销指数增长。测试数据表明，级别 1 的压缩速度是级别 9 的 5-10 倍，而压缩率差异通常不超过 10%。建议使用级别 4 或 5。

12.4 误区四：proxy_buffering 永远应该开启

实际：对于需要实时推送数据的场景（如长轮询、Server-Sent Events），关闭 proxy_buffering 让数据实时转发更合适。判断标准：如果 upstream 返回的数据需要立即到达客户端，就关闭缓冲；如果可以接受一定延迟，就开启。

13. 总结

高并发场景下 Nginx 优化的核心是：最大化连接处理能力、最小化每个请求的开销、合理利用缓存和压缩减少数据传输。

参数调整的优先级是：内核参数大于进程模型大于缓冲区配置大于协议优化。按这个顺序逐层调整，每层调整后观察效果。

优化不是一劳永逸。流量模式变化、upstream 性能变化、业务逻辑调整都可能让原有的最优配置不再最优。建议建立定期 review 机制，结合监控数据分析配置是否仍然合理。

最终，所有优化都应该回归到业务指标：QPS、延迟 P99/P95、错误率。只有这些指标改善了，优化才是有效的。

打开APP阅读更多精彩内容