3.4 Nginx Web 服务器配置与管理

预计阅读时间：18 分钟

学习目标

学完本章后，你将能够：

• 理解 Nginx 事件驱动架构及其与 Apache 的差异
• 配置虚拟主机（server block）和 location 匹配规则
• 搭建反向代理和负载均衡
• 配置 HTTPS、gzip、缓存和限流
• 运用 Nginx 运维命令诊断和重载配置

核心知识

• Nginx——高性能 HTTP 服务器和反向代理服务器，以事件驱动、异步非阻塞架构著称
• 虚拟主机（Server Block）——在同一 Nginx 实例上，通过 server_name 区分不同域名
• Location 匹配——根据 URI 路径，用前缀匹配或正则匹配指定不同的处理规则
• 反向代理（Reverse Proxy）——Nginx 接收客户端请求，转发到后端服务器，再将响应返回客户端
• 负载均衡（Load Balancing）——通过 upstream 模块将请求分发到多台后端服务器
• Worker 进程——Nginx 的工作进程，每个 worker 独立处理连接，数量通常等于 CPU 核心数
• 事件驱动（Event-Driven）——Nginx 不按连接分配线程，而是通过事件循环处理所有连接

知识关联

• 前置知识：4.5：网络故障排查 网络故障排查、3.3：实战：搭建个人网站 搭建个人网站
• 后续影响：Nginx 是 5.7：HAProxy 负载均衡 HAProxy 负载均衡、3.11：SSL/TLS 证书管理 SSL 证书管理的关联技术
• 配套技术：Let's Encrypt（HTTPS 证书）、Nginx Amplify（监控）

原理讲解

事件驱动架构：Nginx 为什么这么快？

传统的 Web 服务器（如 Apache 的 prefork 模式）为每个连接分配一个进程或线程。当并发连接数上升时，线程切换和内存开销急剧增加。Nginx 采用 事件驱动（event-driven） 模型：一个 worker 进程可以同时处理数千个连接，通过非阻塞 I/O 和事件通知（epoll / kqueue）实现高并发低内存。

请求处理流程

Nginx 处理一个请求的典型路径：接收 HTTP 请求 → 根据 server_name 匹配虚拟主机 → 根据 URI 匹配 location → 执行对应处理（serve 静态文件、proxy_pass 转发等）→ 返回响应。location 匹配有严格的优先级：精确匹配 = > 前缀匹配 ^~ > 正则匹配 ~ > 普通前缀匹配。

master/worker 进程模型

Nginx 启动后产生两类进程：一个 master 进程和多个 worker 进程。master 不处理业务请求，只负责：读取和校验配置、fork/回收 worker、平滑重载（reload 时新 worker 拉起、旧 worker 处理完存量连接后退出）。worker 进程数通常等于 CPU 核心数，每个 worker 内部用事件循环（epoll）处理数千个连接，worker 之间通过共享内存（如 upstream 连接统计、SSL 会话缓存）协作。

# 查看进程结构
ps -ef | grep nginx
# 输出:
# root      1234     1  0  master process nginx        ← master（root 运行）
# www-data  1235  1234  0  worker process              ← worker（www-data 运行，Debian/Ubuntu 默认）
# www-data  1236  1234  0  worker process
# www-data  1237  1234  0  worker process

# worker 数量配置（nginx.conf）
worker_processes auto;        # 自动等于 CPU 核心数
worker_connections 1024;      # 每个 worker 最大并发连接数（含 keepalive）

# 查看实际 worker 数
cat /proc/cpuinfo | grep processor | wc -l

为什么 Nginx 用 master/worker 模型而不是多线程？

传统 Web 服务器（如 Apache）为每个连接分配一个线程或进程。Nginx 的 master/worker 模型是完全不同的设计哲学：一个 worker 进程通过事件循环处理数千个连接，而不是为每个连接创建新线程。这背后是操作系统 I/O 模型的演进——Linux 的 epoll（以及 BSD 的 kqueue）允许一个进程同时监听大量文件描述符，只有真正有数据到达的连接才会被处理，空闲连接几乎不消耗 CPU。

这种设计的优势：线程切换的开销在高并发下会成为瓶颈（每次上下文切换约 1-10 微秒，10 万并发意味着频繁切换），而事件驱动模型完全没有这个问题。Nginx 的单个 worker 可以轻松处理 1 万+ 并发连接，内存占用仅几 MB，而 Apache 的 prefork 模式在 1 万并发时需要 1 万个进程，内存消耗可达数 GB。

master/worker 分离的意义：master 以 root 权限运行（绑定 80/443 端口、读取配置），worker 以低权限用户运行（处理请求）。即使某个 worker 被攻破，攻击者也拿不到 root 权限。

Nginx vs Apache：为什么高并发场景选 Nginx？

选型结论：如果是纯反向代理或静态文件服务器，Nginx 无悬念胜出。如果需要在 Web 服务器内直接运行 PHP（mod_php），Apache 的集成度更好。现代架构中，Nginx 做前端代理 + 后端应用服务器（PHP-FPM、Node.js、Go）的组合是最主流的方案。

事件驱动模型：epoll 如何工作？

epoll 的核心思想是就绪通知：程序注册一批文件描述符到 epoll 实例，然后调用 epoll_wait 阻塞等待。当某个 fd 上有数据到达时，内核将其标记为就绪并唤醒进程。与传统的 select/poll 相比，epoll 不需要每次都遍历所有 fd——它通过回调机制在 fd 就绪时直接加入就绪列表，时间复杂度从 O(N) 降到 O(1)。这就是为什么 Nginx 即使管理 10 万个连接，worker 的 CPU 开销仍然很低。

worker 连接数上限速算

单机 Nginx 的理论并发连接数 ≈ worker_processes × worker_connections。例如 4 核 CPU、worker_connections 1024，则约可承载 4096 个并发连接（一个连接对应一个客户端请求；若启用 keepalive，一个浏览器可能占用多个连接）。超出上限时 error.log 会出现 worker_connections are not enough，此时优先排查是否有连接泄漏，而非盲目调大数值。

示例代码

1. 安装与基本配置结构

# 安装 Nginx
sudo apt update && sudo apt install nginx -y

# 启动并设置开机自启
sudo systemctl enable --now nginx

# 验证服务状态
sudo systemctl status nginx
# 输出: ● nginx.service - A high performance web server and a reverse proxy server
#        Active: active (running)

# Nginx 关键目录结构
# /etc/nginx/
#   ├── nginx.conf           # 主配置文件
#   ├── sites-available/     # 可用站点配置
#   ├── sites-enabled/       # 已启用站点（符号链接到 sites-available）
#   └── conf.d/              # 额外配置片段
# /var/www/                  # 默认网站根目录
# /var/log/nginx/
#   ├── access.log           # 访问日志
#   └── error.log            # 错误日志

2. 配置虚拟主机（Server Block）

# /etc/nginx/sites-available/example.com
server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/example;
    index index.html index.htm;

    location / {
        try_files $uri $uri/ =404;
    }

    # 启用 gzip 压缩（也可放在 http 块中全局生效）
    gzip on;
    gzip_types text/plain text/css application/json application/javascript text/xml;
    gzip_min_length 1000;
}

# 启用站点（创建符号链接）
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t          # 测试配置
sudo systemctl reload nginx  # 重载

3. 反向代理

# 将 /api/ 路径的请求转发到后端应用
server {
    listen 80;
    server_name api.example.com;

    location /api/ {
        proxy_pass http://localhost:3000;
        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;

        # 超时设置
        proxy_connect_timeout 30;
        proxy_read_timeout 60;
    }

    # 拒绝访问 . 开头的隐藏文件
    location ~ /\. {
        deny all;
    }
}

4. 负载均衡

# 定义后端服务器池
upstream backend {
    # 负载均衡算法：least_conn（最少连接）、ip_hash（会话保持）、默认轮询
    least_conn;

    server 192.168.1.10:3000 weight=3;   # 权重 3，承担更多请求
    server 192.168.1.11:3000 weight=1;
    server 192.168.1.12:3000 backup;     # 备用服务器
}

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

    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
    }
}

# 健康检查（需 nginx-plus 或单独工具）:
# upstream 中的 server 会自动做被动健康检查
# 若连续失败则标记为不可用

5. HTTPS 配置

# 第一步：使用 certbot 获取证书（Let's Encrypt）
# sudo apt install certbot python3-certbot-nginx -y
# sudo certbot --nginx -d example.com -d www.example.com

# 第二步：Nginx HTTPS 配置
server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # 安全配置
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers on;

    # HSTS（告诉浏览器始终用 HTTPS）
    add_header Strict-Transport-Security "max-age=63072000" always;

    root /var/www/example;
    index index.html;
}

# HTTP → HTTPS 跳转
server {
    listen 80;
    server_name example.com;
    return 301 https://$server_name$request_uri;
}

6. 缓存与限流

# 缓存配置
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mycache:10m max_size=1g;

server {
    location / {
        proxy_cache mycache;
        proxy_cache_valid 200 302 10m;    # 200/302 响应缓存 10 分钟
        proxy_cache_valid 404 1m;          # 404 缓存 1 分钟
        proxy_cache_use_stale error timeout http_500;
        add_header X-Cache-Status $upstream_cache_status;  # 查看缓存命中状态
    }
}

# 限流：每个 IP 每秒最多 5 个请求
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;

server {
    location /api/ {
        limit_req zone=mylimit burst=10 nodelay;
        proxy_pass http://backend;
    }
}

7. location 匹配规则详解

# 一个完整的 location 路由示例
server {
    location = /favicon.ico {           # 精确匹配：缩短小文件访问路径
        log_not_found off;
        access_log off;
    }
    location ^~ /static/ {              # 静态资源：不再检查正则，直接走文件服务
        alias /var/www/static/;
        expires 7d;                     # 浏览器缓存 7 天
    }
    location ~ \.php$ {                 # PHP 动态请求转发到 FPM
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
    location / {                        # 其余全部走前端应用
        proxy_pass http://node_app;
    }
}

8. proxy_pass 的 URI 传递规则

proxy_pass 结尾是否带 /，决定了匹配到的 location 前缀是否被剥离，这是新手最容易搞错的点：

# 常见实践：前端 SPA 与 API 分离
server {
    listen 80;
    server_name app.example.com;

    # 静态前端（Vue/React 构建产物）
    location / {
        root /var/www/app/dist;
        try_files $uri $uri/ /index.html;   # SPA 路由回退
    }

    # API 反向代理：剥离 /api 前缀
    location /api/ {
        proxy_pass http://127.0.0.1:8080/;  # 注意结尾斜杠
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

9. 负载均衡策略详解

# 策略一：轮询（默认）——请求依次分发，权重可配
upstream app1 {
    server 192.168.1.10:8080 weight=3;    # 权重 3：每 4 个请求分到 3 个
    server 192.168.1.11:8080 weight=1;
    server 192.168.1.12:8080 down;        # 手动标记下线（不参与分发）
}

# 策略二：ip_hash——同一客户端 IP 固定打到同一台后端（会话保持）
upstream app2 {
    ip_hash;
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
}

# 策略三：least_conn——分给当前活跃连接最少的后端
upstream app3 {
    least_conn;
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
}

# 策略四：fair（第三方模块）/ url_hash——按响应时间或 URL 分发，需编译安装

# 后端故障处理：fail_timeout 内失败 max_fails 次则标记不可用
upstream app4 {
    server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.12:8080 backup;      # 仅当主后端全挂时启用
}

# 验证分发效果：循环请求观察后端日志
for i in $(seq 1 8); do curl -s http://localhost/ > /dev/null; done

10. 缓存完整配置与动静分离

# http 块：定义缓存目录与共享区
proxy_cache_path /var/cache/nginx levels=1:2
                 keys_zone=api_cache:10m
                 max_size=5g
                 inactive=60m
                 use_temp_path=off;

# 动静分离：静态文件直接返回，动态请求才进缓存
server {
    listen 80;
    server_name www.example.com;

    # 静态资源：交给 Nginx 文件服务，不经过代理
    location ~* \.(css|js|png|jpg|jpeg|gif|ico|woff2?)$ {
        root /var/www/site;
        expires 30d;
        add_header Cache-Control "public, immutable";
    }

    # 动态 API：进缓存
    location /api/ {
        proxy_pass http://backend;
        proxy_cache api_cache;              # 启用缓存区
        proxy_cache_key "$scheme$request_method$host$request_uri";
        proxy_cache_valid 200 302 10m;      # 成功响应缓存 10 分钟
        proxy_cache_valid 404 1m;           # 404 只缓存 1 分钟
        proxy_cache_use_stale error timeout http_500 http_502 http_503;
        add_header X-Cache-Status $upstream_cache_status;  # HIT/MISS/EXPIRED
    }
}

# 手动清理某条缓存（按 proxy_cache_key 生成路径删除）
find /var/cache/nginx -type f | grep -E "$(echo -n 'GEThttp://api.example.com/api/user' | md5sum | cut -d' ' -f1)" | xargs rm -f

11. 安全加固

# 隐藏版本号（默认响应头 Server: nginx/1.24.0 → Server: nginx）
server_tokens off;

# 隐藏 PHP 版本号等上游信息（适用于 FastCGI 场景）
fastcgi_hide_header X-Powered-By;

# 限制请求方法，拒绝非法的 TRACE/OPTIONS
if ($request_method !~ ^(GET|HEAD|POST|PUT|DELETE)$) {
    return 405;
}

# 完整限流：登录接口每 IP 每分钟 5 次，防暴力破解
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/m;

server {
    location /login {
        limit_req zone=login_limit burst=3 nodelay;
        limit_req_status 429;              # 超过则返回 429 Too Many Requests
        proxy_pass http://backend;
    }
}

# 限制并发连接数：每 IP 最多 10 个连接
limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
server {
    limit_conn conn_limit 10;
}

# 基础 WAF 头
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

# 禁止访问隐藏文件与备份文件
location ~ /\. { deny all; }
location ~ \.(sql|bak|tar|zip|log)$ { deny all; }

常见错误

最佳实践

练习题

1. （概念）Nginx 的事件驱动架构和 Apache 的进程每连接模型有什么本质区别？为什么 Nginx 在高并发场景下更省资源？
2. （概念）location 指令中 = /exact、^~ /prefix、~ regex 三种写法的优先级顺序是什么？
3. （实操）在本地 Nginx 上配置两个虚拟主机：site1.local 和 site2.local，分别指向 /var/www/site1 和 /var/www/site2，在两个目录下各放一个不同的 index.html。修改 /etc/hosts 添加解析，用浏览器验证是否能正确访问两个站点。
4. （实操）配置一个反向代理，将 /app/ 路径的请求转发到 http://localhost:3000，同时设置正确的代理头（Host、X-Real-IP、X-Forwarded-For）。用 curl 或浏览器测试代理是否正常工作。
5. （🔍 挑战）使用 certbot 在测试环境中获取 Let's Encrypt 证书并配置完整的 HTTPS 站点（包括 HTTP→HTTPS 跳转、HSTS、SSL 协议限制）。如果无法获取真实证书，也可以创建自签名证书模拟配置。完成后用 SSLLabs SSL Server Test（ssllabs.com）或 openssl s_client 验证安全配置。

学习检查点

学完本章后，请检验自己是否掌握以下内容：

本章总结

Nginx 是当今互联网基础设施的基石。它以事件驱动、异步非阻塞的架构实现了高并发低占用的目标，同时提供了虚拟主机、反向代理、负载均衡、HTTPS 终结、缓存限流等丰富的功能。掌握 server block、location 匹配、proxy_pass 三大核心概念，配合 nginx -t 测试和 reload 热重载，就能在生产环境中游刃有余地管理 Nginx。

速查表

学习路径建议

• 学完本章后建议阅读 3.11：SSL/TLS 证书管理 SSL/TLS 证书管理（深入 HTTPS 配置）
• 学完本章后建议阅读 sec_web01 ModSecurity WAF 配置（Web 应用层防护）
• 高并发场景可看 5.7：HAProxy 负载均衡 HAProxy 负载均衡
• 安全加固可读 5.1：Linux 安全加固 Linux 安全加固

延伸阅读