Nginx 高并发实战：从基础配置到性能调优的完整指南

一、为什么选择 Nginx

Nginx 是一款轻量级、高性能的 Web 服务器和反向代理服务器。它采用事件驱动的异步非阻塞架构，单个 worker 进程就能处理数万并发连接，内存占用却很低。在云服务器（如华为云 ECS）上部署 Web 应用时，Nginx 通常被放在统一入口位置，承担反向代理、负载均衡、静态资源服务、SSL 终结等多重职责，是后端架构中不可或缺的一环。

二、安装与基础配置

以常见 Linux 发行版为例：

# Ubuntu / Debian
sudo apt update && sudo apt install nginx -y

# 验证安装并设置开机自启
nginx -v
sudo systemctl enable nginx && sudo systemctl start nginx

主配置文件在 /etc/nginx/nginx.conf，站点配置建议拆分到 /etc/nginx/conf.d/ 目录下单独管理。这样新增、删除站点时互不干扰，也方便版本控制。

三、反向代理与负载均衡

生产环境最常见的用法，是把 Nginx 放在应用服务器前面做统一入口：

upstream backend {
    # 加权轮询：weight 越大分配到的请求越多
    server 192.168.1.10:8080 weight=3;
    server 192.168.1.11:8080 weight=2;
    server 192.168.1.12:8080 weight=1;
}

server {
    listen 80;
    server_name example.com;

    location / {
        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;
        # 超时设置，避免后端 hang 住拖垮网关
        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
    }
}

负载均衡策略怎么选：

• 默认轮询：后端机器性能相近时直接用，最简单也最常用。
• weight 加权：后端配置不一致时使用，按权重比例分配流量。
• ip_hash：需要会话保持的场景，同一客户端 IP 固定打到同一台后端。
• least_conn：长连接较多的场景，优先分配给当前连接数最少的后端。

特别提醒：proxy_set_header 这三行不要漏。缺了它们，后端应用看到的客户端 IP 会是 Nginx 本机地址，访问日志、限流、风控都会失真，排查问题时会非常痛苦。

四、静态资源优化

Nginx 处理静态文件的效率极高，动静分离是常规做法：

server {
    # 开启 gzip 压缩，显著减小文本类资源体积
    gzip on;
    gzip_min_length 1k;
    gzip_comp_level 6;
    gzip_types text/plain text/css application/json application/javascript text/xml;

    location ~* \.(jpg|jpeg|png|gif|css|js|woff2?)$ {
        root /var/www/static;
        # 浏览器缓存 30 天，减少重复请求
        expires 30d;
        add_header Cache-Control "public";
        # 静态资源关闭 access 日志，减轻磁盘 IO
        access_log off;
    }
}

经验值：gzip_comp_level 建议设为 4~6。级别太高会明显增加 CPU 开销，而压缩率的提升却很有限，得不偿失。

五、核心性能调优

nginx.conf 中的关键参数：

user nginx;
# worker 进程数，一般设为 CPU 核心数，auto 会自动适配
worker_processes auto;

events {
    # 每个 worker 允许的最大连接数
    worker_connections 4096;
    # Linux 下使用 epoll 事件模型
    use epoll;
    multi_accept on;
}

http {
    # 长连接：减少 TCP 握手开销
    keepalive_timeout 65;
    keepalive_requests 1000;

    upstream backend {
        server 192.168.1.10:8080;
        # 与后端也保持长连接池，避免频繁建连
        keepalive 32;
    }

    # 零拷贝文件传输，降低 CPU 与内存开销
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    # 打开文件缓存，加速静态文件访问
    open_file_cache max=10000 inactive=30s;
    open_file_cache_valid 60s;
}

理论最大并发数约等于 worker_processes × worker_connections。但要注意同时调大系统级限制：进程的 nofile（ulimit -n）和内核的 net.core.somaxconn，否则会出现 “too many open files” 或连接被拒绝，Nginx 侧怎么调参都救不回来。

六、安全加固

网关暴露在公网，基础安全配置不能省：

http {
    # 隐藏版本号，减少信息泄露
    server_tokens off;

    # 基于客户端 IP 限流：每秒 10 个请求，突发允许 20 个
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
    # 限制单 IP 并发连接数
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

    server {
        location /api/ {
            limit_req zone=api_limit burst=20 nodelay;
            limit_conn conn_limit 50;
            proxy_pass http://backend;
        }

        # 禁止访问隐藏文件（如 .git）
        location ~ /\. {
            deny all;
        }
        # 禁止访问备份与数据文件
        location ~* \.(bak|sql|log)$ {
            deny all;
        }
    }
}

七、常见故障排查

1. 502 Bad Gateway
后端服务挂了，或 proxy_pass 地址写错。先用 curl 直接请求后端地址确认存活，再检查安全组、防火墙以及 SELinux 是否放行。

2. 504 Gateway Timeout
后端处理太慢。适当调大 proxy_read_timeout，同时排查后端是否存在慢查询或下游依赖超时。

3. too many open files
worker_connections 设得太大，或系统 nofile 太小。两边要一起调，只调一边没用。

4. 修改配置不生效
每次改完务必先检查语法再重载：

nginx -t && nginx -s reload

语法错误时旧 worker 进程会继续运行，新配置根本不会加载，很多人都是在这里浪费半小时。

八、总结

Nginx 的调优思路可以概括为三句话：用对模型（事件驱动 + 多 worker）、减少重复开销（长连接、缓存、sendfile）、守好边界（限流、超时、隐藏信息）。掌握上面这些配置，足以支撑大多数中小型 Web 应用的高并发场景。后续还可以进一步研究 OpenResty / Lua 扩展、动态限流与可观测性接入，把网关能力做得更完整。