Nginx高并发连接调优实战手册

马哥Linux运维 2026-03-16 371
加入交流群

马哥Linux运维

1579 文章 549.2w阅读 61粉丝

描述

一、概述

1.1 背景介绍

Nginx 的高性能源自其事件驱动架构。与 Apache 的"每连接一线程"模型不同，Nginx 使用单线程事件循环处理数千个并发连接。理解这套架构是调优的前提。

Nginx 采用 master-worker 进程模型。master 进程负责读取配置、管理 worker 进程、绑定端口。实际的连接处理和请求处理由 worker 进程完成。每个 worker 进程运行一个事件循环，使用操作系统提供的 I/O 多路复用机制（Linux 上是 epoll）监听所有连接上的事件，在单个线程内高效调度数千个连接。

epoll 的工作原理：

epoll 是 Linux 2.6 引入的 I/O 事件通知机制，相比 select/poll 有两个核心优势。第一，epoll 使用红黑树管理被监控的文件描述符，添加和删除操作的时间复杂度是 O(log n)，而 select/poll 每次调用都要将整个描述符集合从用户空间复制到内核空间。第二，epoll 使用回调机制，内核在事件发生时将就绪的描述符加入就绪链表，epoll_wait 只需要检查就绪链表，时间复杂度是 O(就绪事件数)，而非 O(所有被监控的描述符数)。

在 10 万并发连接的场景下，每次事件循环 select 需要遍历 10 万个描述符，而 epoll 只需要处理实际有事件的那几十个描述符。这就是 Nginx 能在单个 worker 进程中处理数万并发连接的根本原因。

连接处理的全链路分析：

一个 HTTP 请求从到达服务器到返回响应，经历以下阶段：

 

客户端 → 内核网络栈 → Nginx accept → 读取请求 → 处理请求 → 代理到上游 → 上游响应 → 返回客户端

具体到系统层面：

1. 数据包到达网卡，触发硬中断
2. 内核协议栈处理 TCP 三次握手，连接进入 accept 队列
3. Nginx worker 的 epoll_wait 返回，调用 accept() 获取新连接
4. 新连接的 fd 加入 epoll 监控
5. 数据到达，epoll 通知 worker 读取请求
6. Nginx 解析 HTTP 请求，匹配 location 规则
7. 如果是反向代理，建立到 upstream 的连接
8. 将请求转发到 upstream，等待响应
9. 从 upstream 读取响应，通过缓冲区暂存
10. 将响应写回客户端连接
11. 如果是 keepalive 连接，保持连接等待下一个请求
12. 连接关闭，fd 从 epoll 中移除

 

并发瓶颈的四个层级：

高并发场景下的瓶颈不会只出现在 Nginx 配置层面。完整的瓶颈分析需要覆盖四个层级：

系统层瓶颈： 文件描述符数量限制（每个连接消耗一个 fd）、内核网络栈参数（TCP backlog、端口范围、连接跟踪表）、内存限制（每个连接需要内核和用户空间各分配缓冲区）。

Nginx 层瓶颈： worker 进程数、每个 worker 的最大连接数、事件处理模型配置、keepalive 参数、缓冲区大小。

上游层瓶颈： 到 upstream 的连接池配置、upstream keepalive 连接数、upstream 响应时间、连接超时设置。

应用层瓶颈： 后端应用的处理能力（QPS 上限）、数据库连接池、缓存命中率、应用线程池/协程池大小。

Nginx 调优的核心思路是：确保每一层都不会成为瓶颈，让请求能够顺畅地通过整条链路。

1.2 核心概念

连接与请求的区别：

一个 TCP 连接（connection）上可以承载多个 HTTP 请求（request）。HTTP/1.1 的 keepalive 机制允许在同一个连接上串行发送多个请求。HTTP/2 更进一步，在同一个连接上可以并行发送多个请求（通过多路复用 stream）。因此 Nginx 的 worker_connections 参数限制的是并发连接数而非并发请求数。

反向代理场景的连接消耗：

当 Nginx 作为反向代理时，每个客户端请求需要消耗两个连接：一个是客户端到 Nginx 的前端连接，一个是 Nginx 到 upstream 的后端连接。因此实际能处理的并发客户端请求数约为 worker_connections / 2。如果启用了 upstream keepalive 连接池，后端连接可以复用，实际能处理的并发数会高于这个理论值。

背压（Backpressure）机制：

Nginx 的 proxy_buffer 机制实现了上游和下游之间的背压解耦。当 upstream 的响应速度快于客户端的接收速度时，Nginx 将响应缓存在 proxy_buffer 中，尽快释放 upstream 连接。如果缓冲区也满了，Nginx 会暂停从 upstream 读取数据，形成自然的背压。这个机制使得一个慢客户端不会长时间占用 upstream 的连接资源。

1.3 适用场景

Web 服务器/反向代理在高并发下出现 502/504 错误

服务器连接数达到上限，新请求被拒绝（Connection refused）

TIME_WAIT 连接堆积导致端口耗尽

upstream 响应正常但客户端体感延迟高

压测时 QPS 无法随资源线性增长

HTTP/2 或 HTTP/3 环境下的特定调优需求

1.4 环境要求

组件 版本要求 说明
操作系统 Ubuntu 24.04 LTS / Rocky Linux 9.5 内核 6.12+
Linux 内核 6.12+ 支持 io_uring、BBR v3、最新 TCP 优化
Nginx 1.27.x 主线版本，包含最新特性
OpenSSL 3.3+ TLS 1.3 和 HTTP/3 (QUIC) 支持
systemd 256+ 进程管理和资源限制
wrk 4.2+ HTTP 压测工具
vegeta 12.12+ HTTP 负载测试工具
Prometheus 3.x 监控指标采集
Grafana 11.x 监控仪表盘
nginx-module-vts 或 nginx-prometheus-exporter 最新版 Nginx 指标暴露

二、详细步骤

2.1 系统层调优

2.1.1 文件描述符限制

每个网络连接消耗一个文件描述符。如果要支持 10 万并发连接，Nginx worker 进程需要能打开至少 10 万个文件描述符。

 

# 查看系统级别的文件描述符限制
cat /proc/sys/fs/file-max
# 默认值通常足够大（数十万到数百万），但需要确认

# 查看系统当前已使用的文件描述符数
cat /proc/sys/fs/file-nr
# 输出格式：已分配  空闲  最大值

# 查看 Nginx 进程的文件描述符限制
# 先获取 worker 进程 PID
ps aux | grep "nginx: worker"
# 再查看限制
cat /proc//limits | grep "Max open files"

 

调整文件描述符限制：

 

# 方法 1：通过 sysctl 调整系统级限制
cat << 'EOF' | sudo tee /etc/sysctl.d/99-nginx-tuning.conf
# 系统级最大文件描述符数
fs.file-max = 2097152

# inotify 监控实例数（与 Nginx 无直接关系，但大量文件监控场景需要）
fs.inotify.max_user_instances = 8192
fs.inotify.max_user_watches = 524288
EOF
sudo sysctl --system

# 方法 2：通过 limits.conf 调整用户级限制
cat << 'EOF' | sudo tee /etc/security/limits.d/99-nginx.conf
# Nginx 运行用户的文件描述符限制
nginx    soft    nofile    1048576
nginx    hard    nofile    1048576
root     soft    nofile    1048576
root     hard    nofile    1048576
*        soft    nofile    1048576
*        hard    nofile    1048576
EOF

# 方法 3：通过 systemd 单元配置（推荐，精准控制 Nginx 进程）
sudo mkdir -p /etc/systemd/system/nginx.service.d/
cat << 'EOF' | sudo tee /etc/systemd/system/nginx.service.d/limits.conf
[Service]
LimitNOFILE=1048576
EOF
sudo systemctl daemon-reload
sudo systemctl restart nginx

# 验证生效
cat /proc/$(pgrep -f "nginx: master")/limits | grep "Max open files"
# 预期输出：Max open files            1048576              1048576              files

 

2.1.2 内核网络参数调优

 

# 高并发 Nginx 服务器的内核参数调优
cat << 'EOF' | sudo tee /etc/sysctl.d/99-nginx-network.conf

# ============ TCP 连接相关 ============

# TCP 全连接队列长度（accept 队列）
# 当 Nginx accept() 来不及处理时，新连接在这里排队
# 默认 128，高并发场景远远不够
net.core.somaxconn = 65535

# TCP SYN 半连接队列长度
# 三次握手过程中等待 ACK 的连接在这里排队
net.ipv4.tcp_max_syn_backlog = 65535

# 允许 TIME_WAIT 状态的 socket 被快速回收复用
# 只影响连接到外部服务器的连接（Nginx 到 upstream）
net.ipv4.tcp_tw_reuse = 1

# 本地端口范围（Nginx 连接 upstream 时需要本地端口）
# 默认 32768-60999，约 2.8 万个端口
# 扩大到 1024-65535，约 6.4 万个端口
net.ipv4.ip_local_port_range = 1024 65535

# TCP FIN_WAIT2 超时时间（秒）
# 默认 60 秒，高并发下可以适当缩短
net.ipv4.tcp_fin_timeout = 15

# TCP keepalive 参数（系统默认值，Nginx 有自己的 keepalive 配置）
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3

# ============ 缓冲区相关 ============

# 网络设备的接收队列长度
net.core.netdev_max_backlog = 65535

# 默认和最大的 socket 缓冲区大小
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

# TCP 缓冲区自动调整范围：最小值  默认值  最大值（字节）
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 131072 16777216

# 系统总的 TCP 内存页数限制
net.ipv4.tcp_mem = 786432 1048576 1572864

# ============ 拥塞控制 ============

# 启用 BBR 拥塞控制算法（Linux 4.9+）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# ============ 连接跟踪 ============

# 连接跟踪表大小（如果使用了 iptables/nftables）
# 每个连接跟踪条目约占 300 字节
# 10 万连接需要约 30MB 内存
net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_tcp_timeout_established = 600
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30

# ============ 其他 ============

# 允许更多的 SYN 重试
net.ipv4.tcp_synack_retries = 2

# 启用 TCP 快速打开（TFO），减少握手延迟
net.ipv4.tcp_fastopen = 3

# 增大 ARP 缓存
net.ipv4.neigh.default.gc_thresh1 = 4096
net.ipv4.neigh.default.gc_thresh2 = 8192
net.ipv4.neigh.default.gc_thresh3 = 16384
EOF

sudo sysctl --system

# 验证关键参数
sysctl net.core.somaxconn net.ipv4.tcp_max_syn_backlog 
    net.ipv4.ip_local_port_range net.ipv4.tcp_congestion_control

 

2.1.3 验证 BBR 拥塞控制

 

# 确认 BBR 模块已加载
lsmod | grep bbr

# 如果没有加载
sudo modprobe tcp_bbr

# 确认当前使用的拥塞控制算法
sysctl net.ipv4.tcp_congestion_control
# 预期输出：net.ipv4.tcp_congestion_control = bbr

# 查看可用的拥塞控制算法
sysctl net.ipv4.tcp_available_congestion_control

# BBR 相比 CUBIC 的优势：
# - 基于带宽和 RTT 估计而非丢包率
# - 在高延迟和有损网络中表现更好
# - 能更好地利用可用带宽
# - 对 buffer 膨胀（bufferbloat）有更好的抑制

 

2.2 Nginx 全局参数调优

2.2.1 worker 进程配置

 

# 文件路径：/etc/nginx/nginx.conf

# worker 进程数
# auto 会根据 CPU 核心数自动设置
# 在纯代理场景下设为 CPU 核心数
# 如果有大量 CPU 密集操作（如 SSL 握手、gzip 压缩），可以设为核心数的 1-2 倍
worker_processes auto;

# 绑定 worker 进程到特定 CPU 核心
# 减少 CPU 缓存失效和上下文切换
# auto 自动分配（Nginx 1.9.10+）
worker_cpu_affinity auto;

# 每个 worker 进程的最大文件描述符数
# 必须大于等于 worker_connections
worker_rlimit_nofile 1048576;

# 错误日志级别（高并发下 warn 或 error 即可，info/debug 会产生大量日志）
error_log /var/log/nginx/error.log warn;

# PID 文件
pid /run/nginx.pid;

 

2.2.2 事件模型配置

 

events {
    # 每个 worker 的最大并发连接数
    # 这个数字包含所有连接：客户端连接 + upstream 连接 + 本地文件 fd
    # 反向代理场景：可服务的并发客户端数 ≈ worker_connections / 2
    # 10 万并发需要：worker_connections >= 200000 / worker_processes
    worker_connections 65535;

    # 使用 epoll 事件模型（Linux 默认，显式指定更清晰）
    use epoll;

    # 允许一个 worker 一次 accept 多个连接
    # 减少 epoll_wait 的调用次数，提高 accept 效率
    multi_accept on;

    # accept 互斥锁
    # off：所有 worker 都监听同一个端口，由内核调度（reuseport 更优）
    # Nginx 1.11.3+ 配合 reuseport 时建议关闭
    accept_mutex off;
}

 

reuseport 优化：

 

# 在 listen 指令中启用 reuseport
# reuseport 让每个 worker 进程拥有独立的 listen socket
# 内核在 TCP 层面做负载均衡，避免惊群效应
server {
    listen 80 reuseport;
    listen 443 ssl reuseport;
    # ...
}

# reuseport 的效果：
# - 消除 accept_mutex 锁竞争
# - 内核级别的 worker 间负载均衡
# - 在高并发下（>10000 连接/秒）提升 2-3 倍的新建连接能力

 

2.2.3 HTTP 核心配置

 

http {
    # ============ 基础配置 ============

    # MIME 类型
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    # 日志格式（高并发下日志 I/O 也是瓶颈之一）
    log_format main '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent" '
                    '$request_time $upstream_response_time '
                    '$connection $connection_requests';

    # 访问日志缓冲写入（减少 I/O 次数）
    access_log /var/log/nginx/access.log main buffer=64k flush=5s;

    # 高并发压测时可以临时关闭访问日志
    # access_log off;

    # ============ 性能配置 ============

    # 使用 sendfile 系统调用传输文件（零拷贝）
    sendfile on;

    # 配合 sendfile 使用，将多个小数据块合并为一个 TCP 包发送
    tcp_nopush on;

    # 禁用 Nagle 算法，减少小数据包的延迟
    # 与 tcp_nopush 配合：先用 nopush 攒数据，最后一个包用 nodelay 立即发送
    tcp_nodelay on;

    # ============ 连接管理 ============

    # 客户端 keepalive 超时时间（秒）
    # 连接空闲超过此时间后关闭
    # 高并发下不宜设太长，否则空闲连接占用过多 fd
    keepalive_timeout 65;

    # 单个 keepalive 连接上允许的最大请求数
    # 达到后关闭连接，防止单个连接长期占用资源
    keepalive_requests 1000;

    # keepalive 连接的空闲超时（仅 Nginx 1.19.10+）
    # 与 keepalive_timeout 区别：这个是 upstream keepalive 的参数
    # keepalive_time 1h;

    # ============ 超时配置 ============

    # 客户端请求体读取超时（秒）
    client_body_timeout 30;

    # 客户端请求头读取超时（秒）
    client_header_timeout 15;

    # 向客户端发送响应的超时（两次 write 操作之间的间隔）
    send_timeout 30;

    # ============ 缓冲区配置 ============

    # 客户端请求体的缓冲区大小
    client_body_buffer_size 16k;

    # 客户端请求头的缓冲区大小
    client_header_buffer_size 4k;

    # 大请求头的缓冲区
    large_client_header_buffers 4 16k;

    # 最大请求体大小（文件上传限制）
    client_max_body_size 100m;

    # ============ 压缩配置 ============

    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 4;
    gzip_min_length 1000;
    gzip_types text/plain text/css application/json application/javascript
               text/xml application/xml application/xml+rss text/javascript
               image/svg+xml;

    # ============ 连接关闭控制 ============

    # 延迟关闭（lingering close）
    # 确保在关闭连接前读完客户端发送的剩余数据
    # 防止客户端收到 RST 导致的数据丢失
    lingering_close on;
    lingering_time 30s;
    lingering_timeout 5s;

    # 对超时连接发送 RST 而非 FIN
    # 减少 TIME_WAIT 状态的连接数
    # 仅对超时连接生效，正常连接仍走优雅关闭
    reset_timedout_connection on;

    # 包含其他配置文件
    include /etc/nginx/conf.d/*.conf;
}

 

2.3 上游连接池配置

upstream keepalive 是高并发调优中最容易被忽略但效果最显著的配置项。

 

# upstream 配置示例
upstream backend {
    # 后端服务器列表
    server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.12:8080 max_fails=3 fail_timeout=30s;

    # keepalive 连接池大小
    # 每个 worker 进程保持的到 upstream 的空闲 keepalive 连接数
    # 这不是最大连接数，而是"空闲连接缓存"大小
    # 当请求量超过 keepalive 数时，多余的连接在使用完后会被关闭
    #
    # 计算方法：
    # keepalive >= 平均并发请求数 / worker_processes
    # 但不宜设太大，否则空闲连接占用过多服务端资源
    keepalive 64;

    # 每个 keepalive 连接上的最大请求数（Nginx 1.15.3+）
    # 达到后连接被关闭并重新建立
    keepalive_requests 10000;

    # keepalive 连接的最大存活时间（Nginx 1.19.10+）
    # 防止长时间复用同一个连接
    keepalive_time 1h;

    # keepalive 连接空闲超时（Nginx 1.15.3+）
    # 空闲超过此时间的连接会被回收
    keepalive_timeout 60s;
}

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://backend;

        # 使用 HTTP/1.1 到 upstream（keepalive 需要 HTTP/1.1）
        proxy_http_version 1.1;

        # 清除 Connection 头，防止客户端的 "Connection: close" 传递到 upstream
        proxy_set_header Connection "";

        # 超时配置
        proxy_connect_timeout 5s;     # 连接 upstream 的超时
        proxy_send_timeout 30s;       # 发送请求到 upstream 的超时
        proxy_read_timeout 60s;       # 等待 upstream 响应的超时

        # 代理缓冲区配置
        proxy_buffering on;
        proxy_buffer_size 8k;         # 响应头的缓冲区
        proxy_buffers 32 16k;         # 响应体的缓冲区（32 个 16k 的块）
        proxy_busy_buffers_size 64k;  # 在响应还未完全读取时可以发送给客户端的缓冲区大小

        # 请求头传递
        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_set_header X-Forwarded-Proto $scheme;
    }
}

 

upstream keepalive 未配置时的问题：

 

# 没有 keepalive 时，每个请求到 upstream 都会新建 TCP 连接
# 每次新建连接：TCP 三次握手（至少 1.5 RTT）+ 内核分配资源
# 大量短连接导致 TIME_WAIT 堆积

# 查看 TIME_WAIT 连接数
ss -s | grep "TIME-WAIT"
# 或
ss -tn state time-wait | wc -l

# 查看到 upstream 的 TIME_WAIT
ss -tn state time-wait dst 10.0.1.10
ss -tn state time-wait dst 10.0.1.11

# 如果 TIME_WAIT 数量超过本地端口范围（默认约 28000 个端口）
# 新连接会因为无法分配源端口而失败
# 表现为 Nginx 报 502 错误，日志中出现 "cannot assign requested address"

 

2.4 限流限速配置

 

http {
    # ============ 连接数限制 ============

    # 定义限制区域（基于客户端 IP）
    # zone=conn_limit:10m 表示使用 10MB 共享内存存储状态
    # 每个 IP 状态约占 64 字节，10MB 可以跟踪约 16 万个 IP
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

    # 基于服务名的连接数限制
    limit_conn_zone $server_name zone=server_conn_limit:10m;

    # ============ 请求速率限制 ============

    # 定义速率限制区域
    # rate=100r/s 表示每秒 100 个请求
    limit_req_zone $binary_remote_addr zone=req_limit:20m rate=100r/s;

    # API 接口的速率限制（更严格）
    limit_req_zone $binary_remote_addr zone=api_limit:20m rate=30r/s;

    server {
        listen 80;

        # 每个 IP 最多 200 个并发连接
        limit_conn conn_limit 200;

        # 每个 server 最多 50000 个并发连接
        limit_conn server_conn_limit 50000;

        # 限流错误码（默认 503）
        limit_conn_status 429;
        limit_req_status 429;

        location / {
            # 请求速率限制
            # burst=200 允许突发 200 个请求进入队列
            # nodelay 立即处理突发请求（不延迟排队）
            limit_req zone=req_limit burst=200 nodelay;

            proxy_pass http://backend;
        }

        location /api/ {
            # API 接口更严格的速率限制
            limit_req zone=api_limit burst=50 nodelay;

            proxy_pass http://backend;
        }
    }
}

 

2.5 HTTP/2 调优

 

server {
    listen 443 ssl http2 reuseport;
    server_name www.example.com;

    # SSL 证书
    ssl_certificate /etc/nginx/ssl/cert.pem;
    ssl_certificate_key /etc/nginx/ssl/key.pem;

    # SSL 优化
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256ECDHE-ECDSA-AES256-GCM-SHA384';
    ssl_prefer_server_ciphers off;

    # SSL 会话缓存（减少 TLS 握手次数）
    ssl_session_cache shared50m;
    ssl_session_timeout 1d;
    ssl_session_tickets on;

    # OCSP Stapling（减少客户端的证书验证延迟）
    ssl_stapling on;
    ssl_stapling_verify on;

    # HTTP/2 特定参数
    # 单连接上的最大并发 stream 数
    http2_max_concurrent_streams 128;

    # HTTP/2 连接的最大请求数
    keepalive_requests 10000;

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

 

2.6 HTTP/3 (QUIC) 配置

 

# Nginx 1.25.0+ 原生支持 HTTP/3
# 需要使用 --with-http_v3_module 编译（或使用官方预编译包）

server {
    # HTTP/3 使用 UDP 协议
    listen 443 quic reuseport;
    # HTTP/2 兼容
    listen 443 ssl http2;

    server_name www.example.com;

    ssl_certificate /etc/nginx/ssl/cert.pem;
    ssl_certificate_key /etc/nginx/ssl/key.pem;

    # HTTP/3 需要 TLS 1.3
    ssl_protocols TLSv1.2 TLSv1.3;

    # 通知客户端支持 HTTP/3
    add_header Alt-Svc 'h3=":443"; ma=86400';

    # QUIC 特定参数
    # quic_retry on;  # 启用地址验证（防止 DDoS）

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

# 验证 HTTP/3 支持
curl --http3 https://www.example.com/ -I

# 如果 curl 不支持 HTTP/3，使用 h3 测试工具
# 或在浏览器开发者工具中查看 Protocol 列

 

2.7 启动和验证

 

# 检查 Nginx 配置语法
sudo nginx -t

# 预期输出：
# nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
# nginx: configuration file /etc/nginx/nginx.conf test is successful

# 查看编译参数（确认支持的模块）
nginx -V 2>&1 | tr ' ''
' | grep -E "^--with"

# 重载配置（不中断服务）
sudo nginx -s reload

# 验证 worker 进程数
ps aux | grep "nginx: worker" | grep -v grep | wc -l

# 验证 worker 的文件描述符限制
for pid in $(pgrep -f "nginx: worker"); do
    echo"PID $pid: $(cat /proc/$pid/limits | grep 'Max open files' | awk '{print $5}')"
done

# 验证监听端口
ss -tlnp | grep nginx

# 验证 reuseport 是否生效（应该看到每个 worker 都有独立的 listen socket）
ss -tlnp | grep ":80" | wc -l
# 如果启用了 reuseport，数量应等于 worker 进程数

# 验证 keepalive 配置
curl -v -H "Connection: keep-alive" http://localhost/ 2>&1 | grep -i "keep-alive"

# 快速压测验证
# 使用 wrk 进行基准测试
wrk -t4 -c1000 -d30s http://localhost/

 

三、示例代码和配置

3.1 完整配置示例

3.1.1 高并发反向代理完整配置

 

# 文件路径：/etc/nginx/nginx.conf
# 适用场景：10 万级并发的反向代理服务器
# 硬件规格参考：8 核 16GB，千兆网络

user nginx;
worker_processes auto;
worker_cpu_affinity auto;
worker_rlimit_nofile 1048576;

error_log /var/log/nginx/error.log warn;
pid /run/nginx.pid;

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

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    # 日志格式
    log_format main '$remote_addr - [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    'rt=$request_time uct=$upstream_connect_time '
                    'urt=$upstream_response_time '
                    'conn=$connection reqs=$connection_requests';

    # 日志缓冲写入
    access_log /var/log/nginx/access.log main buffer=64k flush=5s;

    # 基础性能
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    # 连接管理
    keepalive_timeout 65;
    keepalive_requests 1000;
    reset_timedout_connection on;

    # 超时
    client_body_timeout 30;
    client_header_timeout 15;
    send_timeout 30;

    # 缓冲区
    client_body_buffer_size 16k;
    client_header_buffer_size 4k;
    large_client_header_buffers 4 16k;
    client_max_body_size 50m;

    # 压缩
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 4;
    gzip_min_length 1000;
    gzip_types text/plain text/css application/json application/javascript
               text/xml application/xml text/javascript image/svg+xml;

    # 限流
    limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;
    limit_req_zone $binary_remote_addr zone=req_per_ip:20m rate=200r/s;
    limit_conn_status 429;
    limit_req_status 429;

    # upstream 定义
    upstream app_backend {
        server 10.0.1.10:8080 max_fails=3 fail_timeout=30s weight=5;
        server 10.0.1.11:8080 max_fails=3 fail_timeout=30s weight=5;
        server 10.0.1.12:8080 max_fails=3 fail_timeout=30s weight=3;

        keepalive 128;
        keepalive_requests 10000;
        keepalive_timeout 60s;
    }

    # 默认 server（拒绝未匹配的请求）
    server {
        listen 80 default_server;
        server_name _;
        return 444;
    }

    # 主站点
    server {
        listen 80 reuseport;
        server_name www.example.com api.example.com;

        # 连接限制
        limit_conn conn_per_ip 300;

        # 状态监控端点
        location /nginx_status {
            stub_status on;
            allow 10.0.0.0/8;
            deny all;
        }

        # 健康检查端点
        location /health {
            access_log off;
            return 200 "OK
";
        }

        # 静态文件
        location /static/ {
            alias /var/www/static/;
            expires 30d;
            add_header Cache-Control "public, immutable";
            access_log off;
        }

        # API 代理
        location /api/ {
            limit_req zone=req_per_ip burst=100 nodelay;

            proxy_pass http://app_backend;
            proxy_http_version 1.1;
            proxy_set_header Connection "";

            proxy_connect_timeout 5s;
            proxy_send_timeout 30s;
            proxy_read_timeout 60s;

            proxy_buffering on;
            proxy_buffer_size 8k;
            proxy_buffers 32 16k;
            proxy_busy_buffers_size 64k;

            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_set_header X-Forwarded-Proto $scheme;

            # 错误处理：upstream 返回错误时尝试下一个服务器
            proxy_next_upstream error timeout http_502 http_503;
            proxy_next_upstream_tries 2;
            proxy_next_upstream_timeout 10s;
        }

        # 默认代理
        location / {
            limit_req zone=req_per_ip burst=200 nodelay;

            proxy_pass http://app_backend;
            proxy_http_version 1.1;
            proxy_set_header Connection "";

            proxy_connect_timeout 5s;
            proxy_send_timeout 30s;
            proxy_read_timeout 60s;

            proxy_buffering on;
            proxy_buffer_size 8k;
            proxy_buffers 16 16k;
            proxy_busy_buffers_size 32k;

            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_set_header X-Forwarded-Proto $scheme;
        }
    }
}

 

3.2 实际应用案例

案例一：worker_connections 不足导致 502

场景描述： 某电商平台的 Nginx 反向代理在促销活动期间频繁返回 502 错误。Nginx error.log 中出现大量 "worker_connections are not enough" 警告。后端应用服务器负载正常，响应时间也正常。

排查过程：

 

# 查看 Nginx 错误日志
tail -100 /var/log/nginx/error.log | grep -i "connections"
# 2026/03/13 1401 [alert] 1234#1234: 768 worker_connections are not enough

# 查看当前 Nginx 配置
grep worker_connections /etc/nginx/nginx.conf
# worker_connections 768;   <- 默认值太小

# 查看 worker 进程数
grep worker_processes /etc/nginx/nginx.conf
# worker_processes 4;

# 当前最大并发连接数 = 4 * 768 = 3072 个连接
# 反向代理每个请求消耗 2 个连接，实际只能服务约 1536 个并发请求

# 查看当前实际连接数
ss -s
# TCP:   5432 (estab 4210, closed 890, orphaned 12, timewait 890)

# 查看 Nginx 连接状态
curl -s http://localhost/nginx_status
# Active connections: 3891
# server accepts handled requests
#  2847362 2847362 15823451
# Reading: 42 Writing: 312 Waiting: 3537

 

解决方案：

 

# 第一步：调整 worker_connections
# 编辑 /etc/nginx/nginx.conf
# 将 worker_connections 从 768 调整到 65535

# 第二步：同时调整系统层限制
# 文件描述符
cat << 'EOF' | sudo tee /etc/systemd/system/nginx.service.d/limits.conf
[Service]
LimitNOFILE=1048576
EOF

# 内核参数
echo"net.core.somaxconn = 65535" | sudo tee -a /etc/sysctl.d/99-nginx.conf
sudo sysctl --system

# 第三步：在 nginx.conf 中添加
# worker_rlimit_nofile 1048576;

# 第四步：重载配置
sudo systemctl daemon-reload
sudo nginx -t && sudo nginx -s reload

# 第五步：验证
# 新的最大并发：4 * 65535 = 262140 个连接
# 反向代理模式：约 131070 个并发请求
cat /proc/$(pgrep -f "nginx: worker" | head -1)/limits | grep "Max open files"

 

案例二：upstream keepalive 未配置导致 TIME_WAIT 堆积

场景描述： Nginx 反向代理服务器在高峰期频繁出现 502 错误，error.log 中记录 "cannot assign requested address while connecting to upstream"。后端服务正常，但 Nginx 服务器上有数万个 TIME_WAIT 连接。

排查过程：

 

# 查看 TIME_WAIT 连接数
ss -s | grep TIME-WAIT
# TCP:   48291 (estab 3200, closed 2100, orphaned 5, timewait 43002)

# 查看到 upstream 的 TIME_WAIT
ss -tn state time-wait dst 10.0.1.10 | wc -l
# 14523

ss -tn state time-wait dst 10.0.1.11 | wc -l
# 14891

ss -tn state time-wait dst 10.0.1.12 | wc -l
# 13588

# 查看本地端口范围
sysctl net.ipv4.ip_local_port_range
# net.ipv4.ip_local_port_range = 32768    60999
# 可用端口约 28000 个
# 每个目标 IP 的 TIME_WAIT 已接近端口范围上限

# 查看 Nginx upstream 配置
grep -A 10 "upstream" /etc/nginx/conf.d/default.conf
# upstream backend {
#     server 10.0.1.10:8080;
#     server 10.0.1.11:8080;
#     server 10.0.1.12:8080;
# }
# 没有 keepalive 配置，每个请求都新建 TCP 连接到 upstream

# 查看 proxy_http_version
grep "proxy_http_version" /etc/nginx/conf.d/default.conf
# 没有设置，默认是 HTTP/1.0，不支持 keepalive

 

解决方案：

 

# 第一步：添加 upstream keepalive

# 修改 upstream 配置
# upstream backend {
#     server 10.0.1.10:8080;
#     server 10.0.1.11:8080;
#     server 10.0.1.12:8080;
#     keepalive 128;
#     keepalive_requests 10000;
#     keepalive_timeout 60s;
# }

# 第二步：在 location 中启用 HTTP/1.1 和清除 Connection 头
# location / {
#     proxy_pass http://backend;
#     proxy_http_version 1.1;
#     proxy_set_header Connection "";
#     ...
# }

# 第三步：扩大本地端口范围（兜底措施）
echo"net.ipv4.ip_local_port_range = 1024 65535" | 
    sudo tee -a /etc/sysctl.d/99-nginx.conf

# 第四步：启用 TIME_WAIT 复用
echo"net.ipv4.tcp_tw_reuse = 1" | 
    sudo tee -a /etc/sysctl.d/99-nginx.conf

sudo sysctl --system

# 第五步：重载 Nginx
sudo nginx -t && sudo nginx -s reload

# 验证效果（观察 TIME_WAIT 数量变化）
watch -n 5 'ss -s | grep TIME-WAIT'
# 几分钟后 TIME_WAIT 应该逐渐降低

# 配置 keepalive 后的效果：
# 连接被复用，不再频繁新建和关闭
# TIME_WAIT 从 43000 降到 2000 以下
# 502 错误消失

 

案例三：10 万并发压测调优全过程

场景描述： 需要对一个新部署的 Nginx 反向代理进行 10 万并发连接的压力测试。服务器配置为 16 核 32GB，万兆网卡。后端有 8 台应用服务器。目标是支持 10 万并发连接，QPS 达到 5 万以上。

调优过程：

 

# ============ 第一轮：基准测试 ============

# 使用默认配置进行基准测试
wrk -t8 -c10000 -d60s http://target-server/api/health

# 基准结果（模拟数据）：
# Running 1m test @ http://target-server/api/health
#   8 threads and 10000 connections
#   Thread Stats   Avg      Stdev     Max   +/- Stdev
#     Latency    42.3ms   15.2ms   312ms    78.5%
#     Req/Sec    3125     412       4501     72.1%
#   1498762 requests in 1m, 285MB read
#   Socket errors: connect 6752, read 0, write 0, timeout 234
# Requests/sec:  24979.37

# 问题分析：
# 1. 大量连接错误（connect 6752）—— 连接数限制不够
# 2. QPS 约 2.5 万，距离目标 5 万还有差距
# 3. 有超时错误（timeout 234）

# ============ 第二轮：系统层调优 ============

# 应用前面的系统层优化
sudo sysctl -p /etc/sysctl.d/99-nginx-tuning.conf
sudo sysctl -p /etc/sysctl.d/99-nginx-network.conf

# 调整 Nginx 文件描述符限制
sudo mkdir -p /etc/systemd/system/nginx.service.d/
cat << 'EOF' | sudo tee /etc/systemd/system/nginx.service.d/limits.conf
[Service]
LimitNOFILE=1048576
EOF
sudo systemctl daemon-reload

# 再次测试
wrk -t8 -c10000 -d60s http://target-server/api/health

# 第二轮结果：
# Socket errors: connect 0, read 0, write 0, timeout 12
# Requests/sec:  31245.89
# 连接错误消失，QPS 提升到 3.1 万

# ============ 第三轮：Nginx 配置调优 ============

# 调整 worker_connections、添加 reuseport、配置 upstream keepalive
# 使用前面的完整配置模板

sudo nginx -t && sudo nginx -s reload

# 提高并发到 5 万
wrk -t16 -c50000 -d60s http://target-server/api/health

# 第三轮结果：
# Requests/sec:  48923.17
# 平均延迟：25.6ms
# 无连接错误
# QPS 接近 5 万

# ============ 第四轮：精细调优 ============

# 1. 确认压测客户端本身不是瓶颈（使用多台客户端）
# 2. 检查 Nginx 的 CPU 使用率分布
pidstat -p $(pgrep -f "nginx: worker" | tr '
'',') 1 10

# 如果某个 worker CPU 使用率明显高于其他，说明负载不均衡
# 启用 reuseport 后应该比较均衡

# 3. 检查网络瓶颈
sar -n DEV 1 10
# 查看网卡带宽使用率

# 4. 提高到 10 万并发
wrk -t16 -c100000 -d120s http://target-server/api/health

# 最终结果（模拟数据）：
# 16 threads and 100000 connections
# Thread Stats   Avg      Stdev     Max   +/- Stdev
#   Latency    35.8ms   18.4ms   520ms    82.3%
#   Req/Sec    3312     578       4892     68.7%
# 6350421 requests in 2m
# Requests/sec:  52920.17
# 无连接错误，无超时错误
# 目标达成

 

3.2.1 压测与调优自动化脚本

 

#!/bin/bash
# 文件名：nginx_benchmark.sh
# 功能：Nginx 性能基准测试脚本
# 依赖：wrk, curl, ss
# 用法：./nginx_benchmark.sh  [connections] [duration]

set -euo pipefail

# ============ 参数 ============

TARGET_URL="${1:?用法: $0  [connections] [duration]}"
CONNECTIONS="${2:-1000}"
DURATION="${3:-30s}"
THREADS=$(nproc)
REPORT_DIR="/tmp/nginx_benchmark_$(date +%Y%m%d_%H%M%S)"

mkdir -p "$REPORT_DIR"

echo"========================================"
echo"Nginx 性能基准测试"
echo"========================================"
echo"目标 URL: $TARGET_URL"
echo"并发连接: $CONNECTIONS"
echo"测试时长: $DURATION"
echo"线程数:   $THREADS"
echo"报告目录: $REPORT_DIR"
echo"========================================"

# ============ 测试前检查 ============

echo""
echo"[1/5] 测试前环境检查..."

# 检查目标可达
if ! curl -sf -o /dev/null -m 5 "$TARGET_URL"; then
    echo"ERROR: 无法访问 $TARGET_URL"
    exit 1
fi

# 检查 wrk 工具
if ! command -v wrk &> /dev/null; then
    echo"ERROR: wrk 未安装"
    echo"Ubuntu: sudo apt install -y wrk"
    echo"Rocky:  需要从源码编译"
    exit 1
fi

# 记录系统状态
echo"系统配置:" > "$REPORT_DIR/system_info.txt"
echo"CPU 核心数: $(nproc)" >> "$REPORT_DIR/system_info.txt"
echo"内存: $(free -h | grep Mem | awk '{print $2}')" >> "$REPORT_DIR/system_info.txt"
echo"somaxconn: $(sysctl -n net.core.somaxconn)" >> "$REPORT_DIR/system_info.txt"
echo"file-max: $(sysctl -n fs.file-max)" >> "$REPORT_DIR/system_info.txt"
echo"tcp_tw_reuse: $(sysctl -n net.ipv4.tcp_tw_reuse)" >> "$REPORT_DIR/system_info.txt"
echo"local_port_range: $(sysctl -n net.ipv4.ip_local_port_range)" >> "$REPORT_DIR/system_info.txt"

# ============ 预热 ============

echo""
echo"[2/5] 预热阶段（10 秒）..."
wrk -t"$THREADS" -c100 -d10s "$TARGET_URL" > /dev/null 2>&1

# ============ 正式测试 ============

echo""
echo"[3/5] 正式测试 ($DURATION)..."
wrk -t"$THREADS" -c"$CONNECTIONS" -d"$DURATION" --latency "$TARGET_URL" 
    > "$REPORT_DIR/wrk_output.txt" 2>&1

# ============ 采集指标 ============

echo""
echo"[4/5] 采集系统指标..."

# 连接状态统计
ss -s > "$REPORT_DIR/ss_summary.txt" 2>&1

# TIME_WAIT 统计
ss -tn state time-wait | wc -l > "$REPORT_DIR/timewait_count.txt" 2>&1

# Nginx stub_status（如果可用）
curl -sf "http://localhost/nginx_status" > "$REPORT_DIR/nginx_status.txt" 2>/dev/null || true

# ============ 输出报告 ============

echo""
echo"[5/5] 测试结果"
echo"========================================"
cat "$REPORT_DIR/wrk_output.txt"
echo""
echo"========================================"
echo"TIME_WAIT 连接数: $(cat "$REPORT_DIR/timewait_count.txt")"
echo""

if [ -f "$REPORT_DIR/nginx_status.txt" ]; then
    echo"Nginx 状态:"
    cat "$REPORT_DIR/nginx_status.txt"
    echo""
fi

echo"完整报告保存在: $REPORT_DIR/"
echo"========================================"

 

四、最佳实践和注意事项

4.1 最佳实践

4.1.1 不同业务场景的参数模板

场景 A：API 网关（高 QPS，小请求体）

 

# 特点：请求小、响应小、延迟敏感
upstream api_backend {
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    keepalive 256;          # 较大的连接池
    keepalive_requests 50000;
    keepalive_timeout 120s;
}

server {
    keepalive_timeout 30;    # 较短的客户端 keepalive
    keepalive_requests 500;

    location / {
        proxy_pass http://api_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_connect_timeout 3s;
        proxy_read_timeout 10s;

        # 小缓冲区，因为响应通常不大
        proxy_buffer_size 4k;
        proxy_buffers 8 8k;
    }
}

 

场景 B：文件下载服务（高带宽，大响应体）

 

# 特点：大文件、长连接、带宽密集
upstream file_backend {
    server 10.0.1.20:8080;
    server 10.0.1.21:8080;
    keepalive 32;            # 连接数不用太多，但每个连接传输时间长
    keepalive_requests 100;
    keepalive_timeout 300s;  # 较长的超时
}

server {
    keepalive_timeout 120;
    client_max_body_size 10g;  # 允许大文件上传

    location /download/ {
        proxy_pass http://file_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_read_timeout 600s;  # 大文件传输需要较长超时

        # 大缓冲区 + 临时文件缓存
        proxy_buffering on;
        proxy_buffer_size 16k;
        proxy_buffers 64 32k;
        proxy_busy_buffers_size 128k;
        proxy_max_temp_file_size 1024m;  # 允许缓存到临时文件
        proxy_temp_path /var/cache/nginx/proxy_temp;
    }
}

 

场景 C：WebSocket 代理（长连接，双向通信）

 

# 特点：长连接、双向数据、连接数多
map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

upstream ws_backend {
    server 10.0.1.30:8080;
    server 10.0.1.31:8080;
    # WebSocket 不使用 keepalive 连接池
    # 因为 WebSocket 连接是持久化的
}

server {
    location /ws/ {
        proxy_pass http://ws_backend;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        # WebSocket 超时要设长，否则空闲连接会被断开
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;

        # 禁用缓冲（WebSocket 需要实时传输）
        proxy_buffering off;
    }
}

 

4.1.2 灰度调优流程

 

# 修改 Nginx 配置时的安全流程

# 第一步：在测试环境验证配置
sudo nginx -t

# 第二步：备份当前配置
sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.$(date +%Y%m%d_%H%M%S)

# 第三步：灰度生效
# 如果有多台 Nginx，先在一台上 reload
sudo nginx -s reload

# 第四步：观察指标（至少 10 分钟）
# 关注：错误率、延迟、连接数、CPU/内存

# 第五步：确认无异常后，在其余服务器上逐台 reload

# 第六步：如果发现问题，立即回滚
sudo cp /etc/nginx/nginx.conf.bak.20260313_143000 /etc/nginx/nginx.conf
sudo nginx -t && sudo nginx -s reload

 

4.1.3 安全加固

 

# 隐藏 Nginx 版本信息
server_tokens off;

# 安全响应头
add_header X-Content-Type-Options nosniff always;
add_header X-Frame-Options SAMEORIGIN always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy strict-origin-when-cross-origin always;

# 限制请求方法
if ($request_method !~ ^(GET|HEAD|POST|PUT|DELETE|PATCH)$) {
    return 405;
}

# 禁止访问隐藏文件
location ~ /. {
    deny all;
    access_log off;
    log_not_found off;
}

 

4.2 注意事项

4.2.1 配置注意事项

worker_connections 与文件描述符的关系：

worker_connections 只是 Nginx 配置层面的限制，实际生效还需要操作系统允许打开那么多文件描述符。必须确保 worker_rlimit_nofile >= worker_connections。推荐设置 worker_rlimit_nofile 为 worker_connections 的 2 倍以上，因为除了网络连接，Nginx 还需要打开日志文件、缓存文件等。

proxy_buffering 的副作用：

proxy_buffering on（默认）会让 Nginx 尽快从 upstream 读取完整响应，释放 upstream 连接。但如果响应很大且客户端接收很慢，Nginx 会将响应缓存到内存甚至磁盘临时文件中。这会增加内存和磁盘 I/O 消耗。对于 Server-Sent Events (SSE) 和流式响应，必须设置 proxy_buffering off。

keepalive_timeout 不宜过长：

客户端 keepalive 超时设得太长会导致大量空闲连接占用 worker_connections 的配额。如果 10 万个客户端都保持 keepalive 但实际只有 1 万个在发请求，那 9 万个空闲连接白白占用了资源。一般 30-120 秒是合理范围。

4.2.2 常见错误

错误现象 原因分析 解决方案
502 Bad Gateway upstream 连接失败或超时 检查 upstream 健康状态，调整 proxy_connect_timeout
504 Gateway Timeout upstream 响应超时 调整 proxy_read_timeout，排查后端性能
"worker_connections are not enough" 并发连接超过 worker_connections 增大 worker_connections，同时调整系统 fd 限制
"cannot assign requested address" 本地端口耗尽（TIME_WAIT 堆积） 启用 upstream keepalive，扩大 ip_local_port_range
"too many open files" 文件描述符限制不足 调整 worker_rlimit_nofile 和系统 limits
"upstream prematurely closed connection" upstream 关闭了 keepalive 连接 确保 upstream keepalive_timeout > Nginx keepalive_timeout
"110: Connection timed out" while connecting to upstream upstream 的 accept 队列满或网络问题 检查 upstream 的 somaxconn 和 backlog
Nginx CPU 100% 某个核 单个 worker 负载过重 启用 reuseport 均衡负载

4.2.3 兼容性问题

HTTP/2 与 upstream：Nginx 到 upstream 的连接目前不支持 HTTP/2（截至 1.27.x），即使客户端使用 HTTP/2。upstream 连接始终使用 HTTP/1.1。如果 upstream 是 gRPC 服务，使用 grpc_pass 指令而非 proxy_pass。

HTTP/3 客户端兼容性：部分老版本浏览器和客户端不支持 HTTP/3。必须同时保留 HTTP/2 监听以确保兼容性。通过 Alt-Svc 头通知支持 HTTP/3 的客户端升级。

TCP Fast Open：需要内核 3.7+ 支持。某些中间网络设备（防火墙、负载均衡器）可能丢弃 TFO 的 SYN 包。在公网环境建议测试后再启用。

reuseport 与热重载：使用 reuseport 时，nginx -s reload 会导致短暂的连接中断（旧 worker 的 listen socket 被关闭，新 worker 创建新的 listen socket）。如果对零停机有严格要求，需要评估影响。

五、故障排查和监控

5.1 故障排查

5.1.1 日志查看

 

# 查看 Nginx 错误日志（实时跟踪）
sudo tail -f /var/log/nginx/error.log

# 按错误级别过滤
grep '[error]' /var/log/nginx/error.log | tail -20
grep '[crit]' /var/log/nginx/error.log | tail -20
grep '[alert]' /var/log/nginx/error.log | tail -20
grep '[emerg]' /var/log/nginx/error.log | tail -20

# 统计错误类型分布
awk -F'[][]''/[(error|crit|alert|emerg)]/ {print $2}' 
    /var/log/nginx/error.log | sort | uniq -c | sort -rn

# 统计 upstream 错误
grep "upstream" /var/log/nginx/error.log | 
    grep -oP '(timed out|connection refused|no live upstreams|prematurely closed)' | 
    sort | uniq -c | sort -rn

# 分析访问日志中的 HTTP 状态码分布
awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

# 分析响应时间分布（需要自定义日志格式包含 $request_time）
awk '{print $NF}' /var/log/nginx/access.log | 
    awk '{
        if ($1 < 0.1) bucket="<100ms";
        else if ($1 < 0.5) bucket="100-500ms";
        else if ($1 < 1) bucket="500ms-1s";
        else if ($1 < 5) bucket="1-5s";
        else bucket=">5s";
        count[bucket]++
    }
    END {for (b in count) print count[b], b}' | sort -rn

 

5.1.2 实时状态监控

 

# 使用 stub_status 模块查看实时连接状态
curl -s http://localhost/nginx_status

# 输出示例：
# Active connections: 12456
# server accepts handled requests
#  28473621 28473621 158234512
# Reading: 142 Writing: 1523 Waiting: 10791

# 字段含义：
# Active connections -- 当前活跃连接数（包括 Waiting）
# accepts           -- 总接受连接数
# handled           -- 总处理连接数（handled == accepts 表示没有丢弃连接）
# requests          -- 总请求数（一个连接可以发多个请求）
# Reading           -- 正在读取请求头的连接数
# Writing           -- 正在写响应的连接数
# Waiting           -- keepalive 空闲等待的连接数

# 使用 watch 持续监控
watch -n 1 'curl -s http://localhost/nginx_status'

# 编写简单的监控脚本
whiletrue; do
    echo"$(date +%H:%M:%S) $(curl -s http://localhost/nginx_status | 
        awk '/Active/{printf "active=%s ",$3} /Reading/{printf "reading=%s writing=%s waiting=%s",$2,$4,$6}')"
    sleep 5
done

 

5.1.3 连接状态分析

 

# 查看 Nginx 进程的连接数
for pid in $(pgrep -f "nginx: worker"); do
    fd_count=$(ls /proc/$pid/fd 2>/dev/null | wc -l)
    echo"Worker PID $pid: $fd_count file descriptors"
done

# 查看各状态的 TCP 连接数
ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn

# 查看到各 upstream 的连接分布
ss -tn | awk '{print $5}' | grep -E "10.0.1.(10|11|12):8080" | 
    sort | uniq -c | sort -rn

# 查看 SYN 队列溢出
netstat -s | grep -i "SYNs to LISTEN"
# 或
nstat -a | grep TcpExtListenOverflows

# 查看 accept 队列溢出
nstat -a | grep TcpExtListenDrops
# 如果这个数字在增长，说明 somaxconn 或 Nginx backlog 不够大

 

5.2 性能监控

5.2.1 Prometheus 指标采集

使用 nginx-prometheus-exporter：

 

# 安装 nginx-prometheus-exporter
# 下载地址：https://github.com/nginxinc/nginx-prometheus-exporter/releases

# 运行 exporter（基于 stub_status）
nginx-prometheus-exporter -nginx.scrape-uri=http://localhost/nginx_status &

# exporter 默认监听 9113 端口
curl -s http://localhost:9113/metrics | grep nginx

# 暴露的关键指标：
# nginx_connections_active    -- 活跃连接数
# nginx_connections_accepted  -- 总接受连接数（counter）
# nginx_connections_handled   -- 总处理连接数（counter）
# nginx_connections_reading   -- 读取请求头的连接数
# nginx_connections_writing   -- 发送响应的连接数
# nginx_connections_waiting   -- keepalive 空闲连接数
# nginx_http_requests_total   -- 总请求数（counter）

 

Prometheus 采集配置：

 

# 文件路径：/etc/prometheus/prometheus.yml（相关片段）

scrape_configs:
-job_name:'nginx'
    scrape_interval:15s
    static_configs:
      -targets:
          -'nginx-server-01:9113'
          -'nginx-server-02:9113'

# 同时采集 node_exporter 的系统指标
-job_name:'node'
    scrape_interval:15s
    static_configs:
      -targets:
          -'nginx-server-01:9100'
          -'nginx-server-02:9100'

 

5.2.2 关键监控指标

指标名称 正常范围 告警阈值 说明
活跃连接数 取决于业务 > 80% worker_connections 总量 接近上限说明需要扩容
新建连接速率 取决于业务 突增 200% 以上 可能是流量攻击或业务突发
HTTP 5xx 错误率 < 0.1% > 1% 502/504 是最常见的上游问题
请求延迟 P99 < 500ms > 2s 尾部延迟反映最差情况
Worker CPU 使用率 < 80% > 90% 单个 worker 过高说明负载不均
TIME_WAIT 连接数 < 5000 > 20000 持续增长说明 keepalive 配置有问题
accept 队列溢出 0 > 0 且持续增长 需要增大 somaxconn 或 backlog
dropped connections 0 > 0 handled != accepted 说明有连接被丢弃

5.2.3 告警规则

 

# 文件路径：/etc/prometheus/rules/nginx_alerts.yml

groups:
-name:nginx_alerts
    rules:
      # 连接数接近上限
      -alert:NginxConnectionsHigh
        expr:nginx_connections_active>50000
        for:5m
        labels:
          severity:warning
        annotations:
          summary:"Nginx 活跃连接数过高"
          description:"{{ $labels.instance }} 活跃连接 {{ $value }}，接近配置上限"

      # 5xx 错误率过高
      -alert:NginxHighErrorRate
        expr:|
          rate(nginx_http_requests_total{status=~"5.."}[5m])
          /
          rate(nginx_http_requests_total[5m])
          > 0.01
        for:5m
        labels:
          severity:critical
        annotations:
          summary:"Nginx 5xx 错误率过高"
          description:"{{ $labels.instance }} 5xx 错误率 {{ $value | humanizePercentage }}"

      # 连接被丢弃
      -alert:NginxConnectionsDropped
        expr:|
          (rate(nginx_connections_accepted[5m]) - rate(nginx_connections_handled[5m])) > 0
        for:5m
        labels:
          severity:critical
        annotations:
          summary:"Nginx 存在丢弃的连接"
          description:"{{ $labels.instance }} 正在丢弃连接，每秒约 {{ $value }} 个"

      # Nginx 进程消失
      -alert:NginxDown
        expr:nginx_up==0
        for:1m
        labels:
          severity:critical
        annotations:
          summary:"Nginx 服务不可用"
          description:"{{ $labels.instance }} Nginx 进程未运行"

 

5.3 备份与恢复

5.3.1 配置备份

 

#!/bin/bash
# 文件名：nginx_config_backup.sh
# 功能：备份 Nginx 完整配置

BACKUP_DIR="/backup/nginx/$(date +%Y%m%d_%H%M%S)"
mkdir -p "$BACKUP_DIR"

# 备份配置文件
cp -r /etc/nginx/ "$BACKUP_DIR/nginx-config/"

# 备份 SSL 证书
cp -r /etc/nginx/ssl/ "$BACKUP_DIR/ssl/" 2>/dev/null

# 备份 systemd 覆盖配置
cp -r /etc/systemd/system/nginx.service.d/ "$BACKUP_DIR/systemd/" 2>/dev/null

# 备份系统调优参数
cp /etc/sysctl.d/99-nginx-*.conf "$BACKUP_DIR/" 2>/dev/null
cp /etc/security/limits.d/99-nginx.conf "$BACKUP_DIR/" 2>/dev/null

# 记录当前状态
nginx -V > "$BACKUP_DIR/nginx_version.txt" 2>&1
nginx -T > "$BACKUP_DIR/nginx_full_config.txt" 2>&1

# 压缩
tar czf "${BACKUP_DIR}.tar.gz" -C "$(dirname $BACKUP_DIR)""$(basename $BACKUP_DIR)"
rm -rf "$BACKUP_DIR"

echo"Nginx 配置已备份到 ${BACKUP_DIR}.tar.gz"

 

5.3.2 恢复流程

 

# 1. 解压备份
tar xzf /backup/nginx/20260313_143000.tar.gz -C /tmp/

# 2. 恢复配置
sudo cp -r /tmp/20260313_143000/nginx-config/* /etc/nginx/

# 3. 检查配置语法
sudo nginx -t

# 4. 重载配置
sudo nginx -s reload

# 5. 验证
curl -I http://localhost/

 

六、总结

6.1 技术要点回顾

Nginx 高并发能力的基础是 epoll 事件驱动模型，单个 worker 进程可以处理数万并发连接，调优时不要盲目增加 worker 数量

系统层调优（文件描述符、somaxconn、端口范围、BBR）是基础，Nginx 配置层面的参数再大也无法突破系统限制

upstream keepalive 是高并发反向代理中效果最显著的优化项，必须配合 proxy_http_version 1.1 和 proxy_set_header Connection "" 使用

TIME_WAIT 堆积的根因通常是 upstream 连接未复用，启用 keepalive 后配合 tcp_tw_reuse 可以有效解决

reuseport 消除了 accept_mutex 的锁竞争，在高新建连接速率场景下提升显著

限流（limit_conn / limit_req）是保护 Nginx 和后端服务的最后一道防线，必须在上线前配置好

不同业务场景（API 网关、文件下载、WebSocket）的调优参数差异很大，不存在万能配置

6.2 进阶学习方向

Nginx 内部机制深入：连接池管理、事件调度器实现、内存池分配策略、变量延迟求值机制。通过阅读 Nginx 源码理解 ngx_event_module 和 ngx_http_module 的交互。

OpenResty / Lua 扩展：在 Nginx 中嵌入 Lua 脚本实现动态路由、复杂限流、A/B 测试、灰度发布。OpenResty 的 cosocket API 支持在 Nginx 中进行非阻塞网络操作。

QUIC/HTTP3 深度调优：QUIC 协议的拥塞控制、0-RTT 连接恢复、连接迁移等特性的调优和生产实践。

6.3 参考资料

Nginx 官方文档: https://nginx.org/en/docs/

Nginx 管理指南: https://docs.nginx.com/nginx/admin-guide/

Linux 网络栈调优: https://www.kernel.org/doc/html/latest/networking/

wrk HTTP 压测工具: https://github.com/wg/wrk

nginx-prometheus-exporter: https://github.com/nginxinc/nginx-prometheus-exporter

BBR 拥塞控制: https://github.com/google/bbr

man 7 tcp / man 7 socket / man 2 epoll_wait

附录

A. 命令速查表

 

# Nginx 管理
nginx -t                                    # 检查配置语法
nginx -T                                    # 输出完整配置
nginx -s reload                             # 重载配置
nginx -s stop                               # 停止服务
nginx -V                                    # 查看编译参数

# 系统参数查看
sysctl net.core.somaxconn                   # TCP accept 队列
sysctl net.ipv4.ip_local_port_range         # 本地端口范围
sysctl net.ipv4.tcp_tw_reuse                # TIME_WAIT 复用
sysctl fs.file-max                          # 系统文件描述符上限
ulimit -n                                   # 当前用户文件描述符限制

# 连接状态
ss -s                                        # TCP 连接状态汇总
ss -tn state time-wait | wc -l              # TIME_WAIT 数量
ss -tn state established | wc -l            # ESTABLISHED 数量
nstat -a | grep TcpExtListenOverflows       # accept 队列溢出

# Nginx 状态
curl -s http://localhost/nginx_status        # stub_status
curl -s http://localhost:9113/metrics        # Prometheus 指标

# 压测
wrk -t8 -c10000 -d60s http://target/        # wrk 压测

 

B. 配置参数详解

nginx.conf 核心参数说明：

worker_processes：worker 进程数，auto 根据 CPU 核心数设置

worker_cpu_affinity：CPU 亲和性绑定，auto 自动分配

worker_rlimit_nofile：每个 worker 的文件描述符限制

worker_connections：每个 worker 的最大连接数

multi_accept：是否一次 accept 多个连接

accept_mutex：accept 互斥锁，使用 reuseport 时建议关闭

keepalive_timeout：客户端 keepalive 空闲超时

keepalive_requests：单个 keepalive 连接的最大请求数

reset_timedout_connection：超时连接发 RST 而非 FIN

proxy_http_version：到 upstream 的 HTTP 版本，keepalive 需要 1.1

upstream keepalive：upstream 空闲连接池大小（每 worker）

upstream keepalive_requests：upstream keepalive 连接最大请求数

upstream keepalive_timeout：upstream keepalive 空闲超时

proxy_buffer_size：响应头缓冲区大小

proxy_buffers：响应体缓冲区（块数和每块大小）

limit_conn：并发连接数限制

limit_req：请求速率限制（rate + burst + nodelay）

reuseport：listen 指令的参数，每个 worker 独立 listen socket

C. 术语表

术语 英文 解释
epoll Event Poll Linux 高效 I/O 事件通知机制，支持 O(1) 事件获取
惊群效应 Thundering Herd 多个进程/线程同时被唤醒竞争同一个事件，大部分白白唤醒
reuseport SO_REUSEPORT 允许多个 socket 绑定同一端口，内核层负载均衡
backlog Listen Backlog TCP accept 队列长度，等待被 accept() 的已完成连接
TIME_WAIT TIME_WAIT State TCP 连接关闭后的等待状态，默认持续 60 秒（2MSL）
keepalive HTTP Keep-Alive TCP 连接复用，一个连接承载多个 HTTP 请求
upstream 上游服务器 Nginx 反向代理后面的应用服务器
worker_connections Worker 连接数 每个 worker 进程能同时处理的最大连接数
BBR Bottleneck Bandwidth and RTT Google 开发的 TCP 拥塞控制算法
TFO TCP Fast Open TCP 快速打开，减少握手延迟
QUIC Quick UDP Internet Connections Google 开发的传输层协议，HTTP/3 的基础
stub_status Nginx 状态模块 暴露连接数、请求数等基础指标的内置模块
proxy_buffering 代理缓冲 Nginx 缓存 upstream 响应，解耦上下游速度差异
burst 突发容量 limit_req 中允许的突发请求数，超过 rate 但在 burst 内的请求进入队列

 

打开APP阅读更多精彩内容
声明：本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人，不代表电子发烧友网立场。文章及其配图仅供工程师学习之用，如有内容侵权或者其他违规问题，请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

下载APP
|投诉反馈|电子发烧友网
© 2021 elecfans.com
湘ICP备2023036445号-105
×
20
完善资料，
赚取积分