NGINX 生产环境部署白皮书

NGINX 生产环境部署白皮书

版本： 1.0
适用对象： 架构师、运维工程师、DevOps 团队
目标版本： NGINX 1.30.x Stable / 1.31.x Mainline

1. 文档概述

本白皮书旨在为 NGINX 在生产环境中的标准化部署提供系统化的技术参考，覆盖部署准备、架构设计、性能调优、安全加固、高可用方案、容器化集成及运维监控等全链路环节，适用于从单体应用到微服务网关的各类业务场景。

2. 版本选择策略

2.1 版本体系说明

NGINX 采用双轨版本策略：

• Stable（稳定版）： 以偶数次版本号标识（如 1.30.x），经过充分测试，适合生产环境部署。

• Mainline（主线版）： 以奇数次版本号标识（如 1.31.x），包含最新功能和修复，适合测试验证和功能尝鲜。

截至 2026 年 9 月，最新稳定版为 1.30.4，最新主线版为 1.31.5。1.30.0 稳定版合并了来自 1.29.x 主线版本的多项重要功能，包括 Early Hints、后端 HTTP/2 支持、加密客户端问候、上游服务器粘性会话支持以及多路径 TCP 支持。

2.2 选型建议

选型原则： 优先使用官方稳定版，避免使用未经验证的第三方编译版本。应建立版本跟踪机制，关注 nginx.org/security_advisories.html 的安全公告，及时评估和升级。

3. 部署前准备

3.1 系统环境检查

部署前需确认以下基础条件：

• 操作系统内核： Linux 内核 ≥ 2.6（推荐 4.x 及以上以获得更优的 epoll 性能）

• glibc 版本： ≥ 2.17

• 系统时间同步： 必须配置 NTP/chrony，防止 TLS 证书校验失败

• 文件描述符限制： 系统级 fs.file-max 和用户级 ulimit -n 均需 ≥ 65535

3.2 内核参数调优

NGINX 的高并发性能高度依赖 Linux 内核参数配置。生产环境建议在 /etc/sysctl.conf 中配置以下参数：

# 文件描述符
fs.file-max = 200000

# TCP 连接队列
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65535

# TCP 连接复用
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_max_tw_buckets = 5000

# 缓冲区
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# 端口范围
net.ipv4.ip_local_port_range = 1024 65535

执行 sysctl -p 使配置生效。

3.3 编译选项推荐

生产环境推荐源码编译安装，核心编译参数如下：

./configure --prefix=/usr/local/nginx \
    --with-http_ssl_module \
    --with-http_realip_module \
    --with-http_stub_status_module \
    --with-http_gzip_static_module \
    --with-http_v2_module \
    --with-stream \
    --with-stream_ssl_preread_module \
    --with-threads

--with-stream 和 --with-stream_ssl_preread_module 用于四层代理和 SNI 动态转发场景。

4. 核心架构设计

4.1 进程模型

NGINX 采用 Master-Worker 异步非阻塞事件驱动架构：

• Master 进程： 负责配置解析、工作进程管理和信号处理。

• Worker 进程： 执行实际请求处理，每个 Worker 单线程运行，进程间无锁竞争。

• 连接池： 复用 TCP 连接，降低资源消耗。

• 模块化设计： 支持动态加载 HTTP/Stream 等核心模块。

4.2 典型部署架构

根据业务规模，推荐以下三种部署拓扑：

单机部署（开发/小型站点）：

Client → NGINX (静态资源 + 反向代理) → 后端应用

双机高可用（中型业务）：

Client → VIP (Keepalived)
         ├── NGINX Node A (Master)
         └── NGINX Node B (Backup)
                ↓
         Backend Cluster (多台应用服务器)

集群化部署（大型业务/微服务）：

Client → L4 负载均衡 (LVS/云 LB)
         ├── NGINX Node 1
         ├── NGINX Node 2
         └── NGINX Node N
                ↓
         Kubernetes Ingress / 微服务网关

4.3 核心配置模块

负载均衡配置：

upstream backend_cluster {
    least_conn;
    server 10.0.1.1:8080 weight=3 max_fails=3 fail_timeout=30s;
    server 10.0.1.2:8080 weight=2;
    server 10.0.1.3:8080 backup;
    keepalive 32;
}

关键参数说明：weight 控制权重分配，max_fails 和 fail_timeout 定义故障判定条件，backup 标记备用节点（仅当所有非备用节点不可用时启用），keepalive 维持与上游的长连接池。

缓存配置：

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

location ~* \.(jpg|png|css|js)$ {
    proxy_cache cache_zone;
    proxy_cache_valid 200 302 1h;
    proxy_cache_use_stale error timeout updating;
    proxy_cache_lock on;
    add_header X-Cache-Status $upstream_cache_status;
}

proxy_cache_lock 可防止缓存未命中时大量请求同时穿透到后端（缓存击穿）。

5. 性能调优

5.1 Worker 进程与连接

worker_processes auto;
worker_rlimit_nofile 65535;

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

调优原则：CPU 密集型场景（纯静态文件服务）将 worker_processes 设为 CPU 核心数；IO 密集型场景（反向代理、PHP-FPM）设为 CPU 核心数的 1.5~2 倍。worker_rlimit_nofile 必须大于 worker_connections，否则会触发 too many open files 错误。

实际最大并发连接数 ≈ worker_processes × worker_connections。反向代理场景下，每个客户端请求占用 2 个连接（客户端→NGINX、NGINX→后端），因此实际并发需除以 2。

5.2 缓冲区优化

client_body_buffer_size 16k;
client_header_buffer_size 4k;
large_client_header_buffers 4 8k;

proxy_buffer_size 8k;
proxy_buffers 8 8k;
proxy_busy_buffers_size 16k;

缓冲区过小会导致频繁的磁盘 I/O 和临时文件写入，过大则浪费内存。建议根据实际请求体大小分布进行压测后确定。

5.3 Keepalive 连接复用

http {
    keepalive_timeout 65;
    keepalive_requests 1000;

    upstream backend {
        server 10.0.1.1:8080;
        keepalive 64;
        keepalive_timeout 60s;
    }
}

Keepalive 复用可显著降低 TCP 握手开销和 TLS 重新协商延迟，在高并发场景下效果尤为明显。

5.4 静态资源加速

location ~* \.(js|css|png|jpg|gif|woff2|svg)$ {
    sendfile on;
    tcp_nopush on;
    expires 1y;
    add_header Cache-Control "public, max-age=31536000, immutable";
    access_log off;
}

sendfile on 启用零拷贝传输，跳过用户态数据拷贝；tcp_nopush on 确保数据包满时才发送，提升网络效率。

5.5 调优验证方法

调优前务必建立基线。建议按以下顺序操作：先记录基线（访问日志状态码分布、错误日志关键报错、CPU/内存曲线），再修改一组配置，最后用同一组压测命令复测。

关键排查命令：

# 检查连接上限告警
grep 'worker_connections are not enough' /var/log/nginx/error.log | tail -20

# 统计状态码分布
awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

# 查看系统资源
vmstat 1 10

6. 安全加固

6.1 基础安全配置

隐藏版本信息：

http {
    server_tokens off;
}

默认情况下，NGINX 会在响应头中暴露版本号，攻击者可据此定位已知漏洞。

限制敏感目录访问：

location ~ /\.(git|ht|env|svn) {
    deny all;
    return 404;
}

6.2 SSL/TLS 安全配置

生产环境必须关闭 TLS 1.0/1.1 及 SSLv2/SSLv3 等已淘汰协议，强制启用 TLS 1.2 + TLS 1.3：

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;

ssl_stapling on;
ssl_stapling_verify on;
resolver 114.114.114.114 8.8.8.8 valid=300s;

6.3 安全响应头

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Frame-Options DENY always;
add_header X-Content-Type-Options nosniff always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy strict-origin-when-cross-origin always;
add_header Content-Security-Policy "default-src 'self'" always;

HSTS 头可防止 SSL 剥离攻击，其他安全头分别防范点击劫持、MIME 类型嗅探、XSS 等常见威胁。

6.4 请求限制

client_max_body_size 10m;
client_body_timeout 12;
client_header_timeout 12;
send_timeout 10;

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

location /api/ {
    limit_req zone=api_limit burst=20 nodelay;
    limit_conn conn_limit 20;
}

7. 高可用方案

7.1 后端容灾（upstream backup）

通过 upstream 模块的 backup 参数实现主备自动切换：

upstream backend_servers {
    server 192.168.1.10:80 weight=3 max_fails=2 fail_timeout=30s;
    server 192.168.1.11:80 backup;
}

当主服务器连续失败 2 次（max_fails=2）且失败时间窗口为 30 秒（fail_timeout=30s）时，NGINX 自动将流量切换至备用服务器。

7.2 NGINX 自身高可用（Keepalived）

使用 Keepalived + 双 NGINX 实现 NGINX 层的 Active-Passive 高可用。核心机制为 VRRP 协议管理的虚拟 IP（VIP），当主节点故障时，VIP 自动漂移至备用节点。

对于需要更高冗余的场景，可扩展为 Active-Active 模式，使用多个 VIP 分布在多台 NGINX 节点上，结合轮询 DNS 或 L3 负载均衡设备进行流量分发。需要注意的是，Active-Active 模式下单个节点故障会导致容量减半，建议使用不依赖服务端状态的会话保持方式（如 sticky cookie）。

7.3 云环境建议

在公有云环境中，推荐使用云服务商提供的四层负载均衡服务（如 AWS NLB、阿里云 SLB）来分发流量至 NGINX 集群，实现 Active-Active 高可用，避免自建 Keepalived 的运维复杂性。

8. 容器化与 Kubernetes 集成

8.1 Docker 部署

FROM nginx:1.30-alpine
COPY nginx.conf /etc/nginx/nginx.conf
COPY conf.d/ /etc/nginx/conf.d/
COPY ssl/ /etc/nginx/ssl/
EXPOSE 80 443
HEALTHCHECK --interval=30s --timeout=3s \
  CMD curl -f http://localhost/health || exit 1

容器化部署时需注意：配置文件应通过 ConfigMap 或挂载卷管理，日志应输出到 stdout/stderr 由容器运行时收集，SSL 证书应通过 Secret 注入。

8.2 Kubernetes Ingress

在 Kubernetes 环境中，NGINX 通常以 Ingress Controller 形式部署，负责南北向流量的接入、TLS 终止和路由分发。推荐使用 Bitnami Helm Chart 或官方 NGINX Ingress Controller 进行标准化部署：

helm install my-release oci://registry-1.docker.io/bitnamicharts/nginx

关键配置要点：资源限制建议 CPU request 100m / limit 200m，Memory request 128Mi / limit 256Mi；启用 Horizontal Pod Autoscaler 实现自动扩缩容；配置 Pod Disruption Budget 保障滚动更新期间的高可用性。

9. 监控与可观测性

9.1 日志配置

建议启用结构化 JSON 日志格式，便于后续的日志采集和分析：

log_format json_combined escape=json '{'
    '"time":"$time_iso8601",'
    '"remote_addr":"$remote_addr",'
    '"method":"$request_method",'
    '"uri":"$request_uri",'
    '"status":$status,'
    '"body_bytes_sent":$body_bytes_sent,'
    '"request_time":$request_time,'
    '"upstream_response_time":"$upstream_response_time",'
    '"http_user_agent":"$http_user_agent"'
'}';

9.2 关键监控指标

9.3 可观测性集成

推荐技术栈组合：Prometheus + Grafana + Loki（或 ELK）。NGINX 的 with-http_stub_status_module 模块可直接暴露连接数、请求数等基础指标，结合 nginx-prometheus-exporter 可将指标接入 Prometheus 体系。日志侧通过 Promtail/Fluent Bit 采集，推送至 Loki 或 Elasticsearch 进行集中存储和查询。

10. 运维管理规范

10.1 配置管理

• 所有 NGINX 配置文件纳入 Git 版本管理，配置变更须经 Code Review 后合并。

• 使用 Ansible/SaltStack 进行批量配置分发和一致性校验。

• 配置变更流程：修改 → nginx -t 语法检查 → 灰度节点 reload → 全量 reload → 验证。

10.2 日常运维清单

10.3 故障排查速查

nginx -t                          # 配置语法检查
nginx -s reload                   # 平滑重载
nginx -s reopen                   # 重新打开日志文件
systemctl status nginx            # 服务状态
ss -s                             # 连接统计

附录：核心参数速查表