Nginx核心架构与性能优化：Web 服务器/反向代理/负载均衡全解析
<div id="navCategory"><h5 class="catalogue">目录</h5><ul class="first_class_ul"><li>前言：为什么要学 Nginx？</li><li>一、Nginx 基础入门：从零搭建第一个服务<ul class="second_class_ul"><li>1.1 初识 Nginx：它是什么，能做什么？</li><li>1.2 第一个 Nginx 服务：最小化配置实战</li><li>1.3 安装：Linux 里的 Nginx 魔法：从下载到部署，轻松拿捏！</li></ul></li><li>二、核心架构与配置解析：读懂 Nginx 的 "运行逻辑"<ul class="second_class_ul"><li>2.1 架构精髓：Master-Worker 进程模型</li><li>2.2 配置骨架：从 http 到 location 的层级关系</li><li>2.3 静态资源服务：Nginx 的 "原生强项"</li></ul></li><li>三、关键应用场景：Nginx 实战核心技能<ul class="second_class_ul"><li>3.1 反向代理：隐藏后端，统一入口</li><li>3.2 负载均衡：分摊压力，提升可用</li><li>3.3 动静分离：各司其职，极致性能</li><li>3.4 SSL/TLS 终端代理：打造 HTTPS 安全站点</li></ul></li><li>四、性能优化与安全加固：让 Nginx 更稳更快<ul class="second_class_ul"><li>4.1 性能调优：从配置到内核的全维度优化</li><li>4.2 安全加固：抵御常见攻击</li></ul></li><li>五、总结与展望：Nginx 的核心价值与未来<ul class="second_class_ul"><li>5.1 核心价值总结</li><li>5.2 Nginx 与其他技术的对比</li><li>5.3 未来发展趋势</li></ul></li><li>附录：Nginx 常用工具与资源<ul class="second_class_ul"><li>常用命令速查</li></ul></li></ul></div><p>本文从零开始系统讲解 Nginx 的核心价值、架构原理与实战技能。涵盖事件驱动模型、Master-Worker 进程架构、HTTP 配置层级、静态资源服务、反向代理、负载均衡、动静分离、SSL/TLS 终端代理、性能调优与安全加固，并提供大量配置示例与专家建议。无论是初学者还是运维工程师，都能通过本文全面掌握 Nginx 的高效使用。</p><p class="maodian"></p><h2>前言：为什么要学 Nginx？</h2>
<blockquote><p><strong>学习 Nginx，就是掌握如何为你的 Web 服务构建一个高效、可靠且强大的“交通中枢”</strong></p></blockquote>
<p>在当今互联网高并发、低延迟的要求下，Web 服务的入口网关变得至关重要。Nginx 凭借其卓越的设计，成为了全球最受欢迎的 Web 服务器之一（据 Netcraft 统计，市场占有率超过 30%）。</p>
<p><strong>Nginx 的核心价值体现在三个关键方面：</strong></p>
<p><strong>高性能</strong>：采用事件驱动的异步非阻塞架构，能够轻松应对 C10K（甚至 C100K）问题</p>
<blockquote><p><strong>术语解释</strong>：C10K 问题指如何让单台服务器同时处理 10,000 个网络连接。传统 Apache 每连接一个线程/进程，内存和切换开销巨大；而 Nginx 用少量工作进程通过事件循环处理海量连接，内存占用极低。</p></blockquote>
<p><strong>高可靠性</strong>：Master-Worker 进程模型确保服务稳定运行，单个 Worker 崩溃不影响其他进程，Master 会立即重启。</p>
<p><strong>高扩展性</strong>：模块化设计支持丰富的功能扩展，官方和第三方模块（如 Lua、GeoIP、Brotli 压缩等）让 Nginx 几乎能胜任任何网关角色。</p>
<p>无论是作为 Web 服务器、反向代理、负载均衡器还是 API 网关，Nginx 都展现出了卓越的性能表现。本文将带你从零开始，全面掌握 Nginx 的核心概念和实战技能。</p>
<blockquote><p><strong>专家建议</strong>：如果你是初学者，建议在虚拟机或 Docker 中搭建实验环境。先用最小配置跑通 Nginx，再逐步增加功能。不要一次性配置所有高级特性，否则排错会很困难。</p></blockquote>
<p class="maodian"></p><h2>一、Nginx 基础入门：从零搭建第一个服务</h2>
<p class="maodian"></p><h3>1.1 初识 Nginx：它是什么，能做什么？</h3>
<p>Nginx（读作 “Engine X”）最初由 Igor Sysoev 于 2004 年发布，旨在解决当时流行的 Apache HTTP Server 在高并发下的性能瓶颈。经过近 20 年发展，Nginx 已经成为互联网基础设施的标配。</p>
<p><strong>Nginx 的主要应用场景：</strong></p>
<ul><li><p><strong>Web 服务器</strong>：处理静态资源请求（HTML、CSS、JS、图片等），性能远超传统服务器。Nginx 的 sendfile 特性可绕过用户空间直接发送文件，极大提升静态资源吞吐量。</p></li><li><p><strong>反向代理服务器</strong>：隐藏后端服务，提供统一的访问入口。客户端只知道 Nginx 的地址，不知道后端真实服务器（如 Tomcat、Node.js、Gunicorn）的 IP 和端口。</p></li><li><p><strong>负载均衡器</strong>：在多台服务器间分配请求负载，提高整体并发能力和容错性。</p></li><li><p><strong>API 网关</strong>：处理 API 路由、认证、限流、日志聚合等能力，常与微服务架构配合使用。</p></li><li><p><strong>内容缓存</strong>：缓存动态和静态内容，提升响应速度，可替代 Squid、Varnish 等专用缓存服务器。</p></li></ul>
<blockquote><p><strong>相关技术对比</strong>：与 Apache 相比，Nginx 更适合高并发静态/反向代理场景；与 HAProxy 相比，Nginx 在 Web 生态和配置灵活性上更强；与 Caddy 相比，Nginx 更成熟、社区更大，但 Caddy 的自动 HTTPS 更便捷。</p></blockquote>
<p class="maodian"></p><h3>1.2 第一个 Nginx 服务：最小化配置实战</h3>
<p><strong>最小化配置文件示例</strong></p>
<p>以源码安装的 Nginx 为例，配置文件路径为 /usr/local/nginx/conf/nginx.conf，最小可用配置如下：</p>
<div class="dxycode"><pre class="brush:bash;"># -------------------------- main 区块（全局配置）--------------------------
# 工作进程数：建议设为 CPU 核心数，auto 表示自动匹配
worker_processes auto;
# 全局错误日志路径与级别（debug/info/notice/warn/error/crit）
error_log /usr/local/nginx/logs/error.log warn;
# 进程 PID 文件路径
pid /usr/local/nginx/logs/nginx.pid;
# -------------------------- events 区块（连接处理配置）--------------------------
events {
# 每个工作进程的最大连接数（默认 1024，需结合系统文件描述符调整）
worker_connections 1024;
# 事件模型：Linux 推荐 epoll，BSD 推荐 kqueue
use epoll;
# 允许一个连接同时被多个请求复用（HTTP 长连接相关）
multi_accept on;
}
# -------------------------- http 区块（HTTP 协议总配置）--------------------------
http {
# 引入 MIME 类型映射文件（定义文件后缀与 Content-Type 的对应关系）
include /usr/local/nginx/conf/mime.types;
# 未知文件类型的默认 Content-Type
default_typeapplication/octet-stream;
# 日志格式定义（main 为格式名称，可自定义）
log_formatmain'$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
# 访问日志路径，使用 main 格式
access_log/usr/local/nginx/logs/access.logmain;
# 启用零拷贝（直接磁盘→网卡传输，跳过用户态缓冲区，提升性能）
sendfile on;
# 与 sendfile 配合，合并数据包发送，减少 TCP 握手次数
tcp_nopush on;
# 禁用 Nagle 算法，小数据包即时发送（平衡延迟与效率）
tcp_nodelay on;
# 连接超时时间（客户端与 Nginx 保持连接的超时时间）
keepalive_timeout65;
# -------------------------- server 区块（虚拟主机）--------------------------
# 定义一个虚拟主机（可理解为“单个网站”）
server {
# 监听端口（默认 80，HTTP 标准端口）
listen 80;
# 绑定域名（多个域名用空格分隔，如 "example.com www.example.com"）
server_namelocalhost;
# 字符集设置（避免中文乱码）
charset utf-8;
# -------------------------- location 区块（请求路径匹配）--------------------------
# 匹配根路径 "/"（所有未被其他 location 匹配的请求都会命中这里）
location / {
# 网站根目录（静态资源存放路径）
root /usr/local/nginx/html;
# 默认首页（多个页面用空格分隔，按顺序查找）
indexindex.html index.htm;
}
# 匹配 404 错误页面
error_page404 /404.html;
# 匹配 50x 系列错误（500/502/503/504）
error_page 500 502 503 504/50x.html;
# 对应错误页面的路径配置
location = /50x.html {
root /usr/local/nginx/html;
}
}
}
</pre></div>
<blockquote><p><strong>配置解读</strong>：<br />- worker_processes 1; 表示启动 1 个 Worker 进程。生产环境通常设为 auto，让 Nginx 自动匹配 CPU 核心数。<br />- events { worker_connections 1024; } 指定每个 Worker 进程最大并发连接数。1024 是测试环境常用值，生产环境可根据内存和预期并发调大（如 65535）。<br />- listen 80; 监听所有网络接口的 80 端口（HTTP 默认端口）。<br />- server_name localhost; 匹配请求头 Host 字段为 localhost 或该 IP 的请求。<br />- location / { root html; index index.html; } 表示访问根路径 / 时，去 html 目录（相对于 Nginx 安装目录）下找 index.html 文件返回。</p></blockquote>
<p><strong>配置优化示例：</strong></p>
<div class="dxycode"><pre class="brush:bash;"># 在nginx.conf的main块中设置
worker_processes auto;# 自动设置为CPU核心数
worker_cpu_affinity auto;# 自动绑定CPU核心
# 设置每个Worker进程的最大文件打开数
worker_rlimit_nofile 100000;
events {
worker_connections 4096;# 每个Worker的最大连接数
use epoll;# Linux高性能事件模型
multi_accept on;# 一次接受所有新连接
}</pre></div>
<p><strong>优化项解释</strong>：<br />- sendfile on; 启用高效文件传输模式，避免内核态与用户态之间不必要的数据拷贝。<br />- tcp_nopush on; 与 sendfile 配合，在数据包达到一定大小时才发送，提高网络效率。<br />- keepalive_timeout 65; 设置 HTTP Keep-Alive 持久连接超时时间，减少重复握手。</p>
<blockquote><p><strong>注意事项</strong>：最小化配置虽然能跑起来，但不适合生产环境。你至少要配置 worker_processes auto、调整 worker_connections、开启日志管理（access_log 和 error_log），以及设置适当的超时参数。</p></blockquote>
<p class="maodian"></p><h3>1.3 安装：Linux 里的 Nginx 魔法：从下载到部署，轻松拿捏！</h3>
<p>在 Linux 环境中安装 Nginx 主要有三种方式：包管理器安装、源码编译安装、Docker 容器化安装。下表对比了它们的优缺点：</p>
<table><tbody><tr><th>安装方式</th><th>优点</th><th>缺点</th><th>适用场景</th></tr><tr><td>apt/yum 包管理器</td><td>快速、自动处理依赖、方便卸载更新</td><td>版本可能偏旧、模块固定</td><td>开发测试、对版本要求不高的生产环境</td></tr><tr><td>源码编译</td><td>可选最新版本、自由裁剪模块（如添加 --with-http_v2_module）、优化性能（如 -O2）</td><td>手动解决依赖、升级麻烦</td><td>对性能或功能有特殊定制的生产环境</td></tr><tr><td>Docker 容器</td><td>环境隔离、快速部署、易于编排（K8s）</td><td>网络和日志配置稍复杂</td><td>云原生、微服务、CI/CD 流水线</td></tr></tbody></table>
<p><strong>包管理器安装示例（Ubuntu 20.04+）：</strong></p>
<div><div class="dxycode"><pre class="brush:bash;">sudo apt update
sudo apt install nginx -y
sudo systemctl start nginx
sudo systemctl enable nginx # 开机自启
</pre></div></div>
<p><strong>源码编译安装示例：</strong></p>
<div><div class="dxycode"><pre class="brush:bash;"># 安装依赖
sudo apt install build-essential libpcre3 libpcre3-dev zlib1g zlib1g-dev libssl-dev -y
# 下载并解压 Nginx 源码（以 1.24.0 为例）
wget http://nginx.org/download/nginx-1.24.0.tar.gz
tar -zxvf nginx-1.24.0.tar.gz
cd nginx-1.24.0
# 配置编译选项
./configure --prefix=/usr/local/nginx --with-http_ssl_module --with-http_v2_module --with-stream
make && sudo make install
</pre></div></div>
<p><strong>Docker 快速体验：</strong></p>
<div><div class="dxycode"><pre class="brush:bash;">docker run --name my-nginx -p 80:80 -d nginx:latest
</pre></div></div>
<blockquote><p><strong>专家建议</strong>：新手推荐使用包管理器安装，能避免路径和权限问题。等你熟悉了 Nginx 的目录结构（/etc/nginx/、/var/log/nginx/ 等）后，再尝试源码编译。</p></blockquote>
<p class="maodian"></p><h2>二、核心架构与配置解析：读懂 Nginx 的 "运行逻辑"</h2>
<p class="maodian"></p><h3>2.1 架构精髓：Master-Worker 进程模型</h3>
<p>Nginx 采用经典的 Master-Worker 多进程架构，这种设计确保了高稳定性和性能。与 Apache 的 prefork（每请求一进程）或 worker（每请求一线程）模型相比，Nginx 的进程模型在内存占用和上下文切换上都有明显优势。</p>
<p><strong>进程架构详解：</strong></p>
<div class="dxycode"><pre class="brush:bash;">Master Process (PID: 1234) [管理者]
├── Worker Process (PID: 1235)[处理客户端请求]
├── Worker Process (PID: 1236)[处理客户端请求]
├── Worker Process (PID: 1237)[处理客户端请求]
├── Cache Loader Process (PID: 1238) [只在启动时出现，用于初始化缓存索引，完成后自动退出]
└── Cache Manager Process (PID: 1239) [常驻的“后台管家”，定期清理过期缓存]</pre></div>
<p><strong>各进程职责：</strong></p>
<ul><li><strong>Master 进程</strong>：</li><li>读取和验证配置文件（nginx -t 命令就是让 Master 检查配置语法）</li><li>管理 Worker 进程（启动、停止、重载 nginx -s reload）</li><li><p>平滑升级（不中断服务的情况下更新版本）—— 通过发送信号 USR2 和 WINCH 实现热升级</p></li><li><p><strong>Worker 进程</strong>：</p></li><li>实际处理客户端请求</li><li>每个进程独立运行，互不干扰，因此即使一个 Worker 因为第三方模块的 bug 崩溃，其他 Worker 仍能继续服务</li><li><p>采用事件驱动模型（如 epoll、kqueue），非阻塞处理。每个 Worker 在一个循环中不断等待事件（新连接、可读、可写），并批量处理，没有线程切换开销。</p></li><li><p><strong>Cache Manager 进程</strong>：</p></li><li>专职负责缓存的过期与清理，是 Nginx 缓存系统的“后台管家”。它定期扫描缓存目录，删除长时间未使用的缓存文件，并维护缓存索引。</li></ul>
<blockquote><p><strong>注意</strong>：在高并发场景下，如果 Worker 进程数量设置不当（比如多于 CPU 核心数），会导致不必要的上下文切换，降低性能。一般建议设置为 auto 或等于 CPU 逻辑核心数。</p></blockquote>
<p class="maodian"></p><h3>2.2 配置骨架：从 http 到 location 的层级关系</h3>
<p>Nginx 配置文件采用层次化的 <strong>“区块嵌套”</strong> 结构，理解这种结构是掌握配置的关键。配置指令遵循“就近原则”：内层区块会继承外层区块的设置，但如果内层显式定义了同名指令，则覆盖外层的值。</p>
<p>核心层级为：main（全局）→ events（事件）→ http（HTTP 协议）→ server（虚拟主机）→ location（请求匹配）。</p>
<table><tbody><tr><th>层级</th><th>上下文</th><th>作用范围</th><th>核心作用</th></tr><tr><td><strong>Main</strong></td><td>全局</td><td>整个 Nginx 实例</td><td>配置进程、日志、用户等全局参数</td></tr><tr><td><strong>Events</strong></td><td>events</td><td>网络连接</td><td>配置最大连接数、连接处理模型，影响性能</td></tr><tr><td><strong>HTTP</strong></td><td>http</td><td>所有 HTTP/HTTPS 流量</td><td>配置协议级通用参数（日志、压缩、MIME等）</td></tr><tr><td><strong>Server</strong></td><td>server</td><td>单个虚拟主机（网站）</td><td>基于域名/IP/端口区分不同网站</td></tr><tr><td><strong>Location</strong></td><td>location</td><td>虚拟主机内的特定 URI</td><td>对请求路径进行最精细化的处理和控制</td></tr></tbody></table>
<blockquote><p><strong>实际案例</strong>：假设你要配置两个网站（example.com 和 test.com）运行在同一台 Nginx 上。你需要在 http 块内定义两个 server 块，分别设置各自的 server_name 和 root。Nginx 会根据请求头中的 Host 字段选择正确的 server 块。</p></blockquote>
<p><strong>配置层次结构：</strong></p>
<div class="dxycode"><pre class="brush:bash;"># ==================== 层级1: Main Context (全局配置) ====================
worker_processes auto; # 工作进程数，建议设为 CPU 核心数
error_log /var/log/nginx/error.log warn; # 全局错误日志路径与级别
pid /run/nginx.pid; # 进程 PID 文件路径
# ==================== 层级2: Events Context (事件配置) ==================
events {
worker_connections 1024; # 每个工作进程的最大连接数
use epoll; # Linux 系统推荐使用 epoll 事件模型
multi_accept on; # 允许一个连接同时处理多个请求
}
# ==================== 层级3: HTTP Context (HTTP协议配置) ================
http {
include /etc/nginx/mime.types; # 引入 MIME 类型映射文件
default_type application/octet-stream;# 未知文件类型的默认 Content-Type
# 定义日志格式
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;# 访问日志路径和格式
# 性能优化指令
sendfile on; # 启用零拷贝传输
tcp_nopush on; # 优化数据包发送，减少网络报文
tcp_nodelay on; # 禁用 Nagle 算法，降低延迟
keepalive_timeout 65; # 客户端连接保持超时时间
# 启用 Gzip 压缩
gzip on;
gzip_types text/plain text/css application/json application/javascript;
# ==================== 层级4: Server Context (虚拟主机配置) ============
server {
listen 80; # 监听 80 端口（HTTP）
server_name example.com www.example.com;# 绑定的域名
# 字符集设置，避免中文乱码
charset utf-8;
# ==================== 层级5: Location Context (URI匹配配置) =======
location / {
root /var/www/html; # 网站根目录
index index.html index.htm; # 默认首页文件
}
# 静态资源缓存优化
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
root /var/www/static;
expires 1y; # 缓存 1 年
add_header Cache-Control "public, immutable";
}
# 错误页面配置
error_page 404 /404.html;
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /var/www/html;
}
}
}</pre></div>
<p><strong>Location 匹配规则详解：</strong></p>
<p>Nginx 的 location 块支持多种匹配方式，优先级从高到低：</p>
<div class="dxycode"><pre class="brush:bash;">server {
# 1. 精确匹配 (=) - 最高优先级
location = /exact-path {
return 200 "This is an exact match";
}
# 2. 优先前缀匹配 (^~) - 第二优先级
location ^~ /static/ {
root /var/www;
# 此配置会阻止后续的正则匹配
}
# 3. 正则匹配 (~ 区分大小写, ~* 不区分大小写)
location ~ \.php$ {
# 处理PHP文件
fastcgi_pass 127.0.0.1:9000;
}
location ~* \.(jpg|png|gif)$ {
# 处理图片文件，不区分大小写
expires 30d;
}
# 4. 普通前缀匹配 - 最低优先级
location / {
# 通用匹配
try_files $uri $uri/ =404;
}
}</pre></div>
<p><strong>补充说明匹配优先级细节</strong>：<br />1. = 精确匹配 —— 一旦匹配，立即停止搜索其他 location。<br />2. ^~ 前缀匹配 —— 若匹配，不再检查正则表达式，提高效率。<br />3. ~ 或 ~* 正则匹配 —— 按配置文件中出现的顺序，第一个匹配的正则生效。<br />4. 普通字符串前缀匹配 —— 最长匹配优先，但如果没有 ^~ 修饰，仍然会继续查找正则匹配。</p>
<blockquote><p><strong>常见错误</strong>：很多新手将 /api/ 的正则写成 location /api/（普通前缀），结果导致某些请求被更长的前缀匹配或正则覆盖。如果你的意图是严格匹配 /api/ 开头的 URI，建议使用 location ^~ /api/ 或 location ~ ^/api/。</p></blockquote>
<p class="maodian"></p><h3>2.3 静态资源服务：Nginx 的 "原生强项"</h3>
<p>Nginx 在处理<strong>静态资源</strong>方面具有天然优势，正确的配置可以极大提升性能。静态资源包括 HTML、CSS、JavaScript、图片、字体、视频等不经过后端动态生成的文件。</p>
<p><strong>基础静态服务配置：</strong></p>
<div class="dxycode"><pre class="brush:bash;">server {
listen 80;
server_name static.example.com;
# 基础静态文件服务
location / {
root /var/www/html;# 设置根目录路径
index index.html index.htm;# 默认索引文件
# 性能优化设置
sendfile on;# 启用零拷贝传输，绕过用户空间直接在内核处理文件发送
tcp_nopush on;# 在sendfile启用时，优化数据包发送，减少网络报文数量
# 缓存控制
expires 1h;# 设置浏览器缓存1小时（HTTP响应头Expires和Cache-Control）
add_header Cache-Control "public";# 允许所有缓存（CDN、代理、浏览器）缓存资源
}
# 图片文件特殊处理
location ~* \.(jpg|jpeg|png|gif|ico|webp)$ {
root /var/www/images;
# 更长的缓存时间
expires 1y;
add_header Cache-Control "public, immutable";
# 图片优化
image_filter resize 800 600;# 可选：图片处理
}
# CSS和JS文件
location ~* \.(css|js)$ {
root /var/www/assets;
expires 7d;
add_header Cache-Control "public";
# Gzip压缩
gzip on;
gzip_types text/css application/javascript;
}
}</pre></div>
<p><strong>高级静态资源优化：</strong></p>
<div class="dxycode"><pre class="brush:bash;">http {
# 文件访问缓存配置（优化静态文件读取性能）
# 启用文件描述符缓存，最多缓存10000个文件描述符，30秒内未被访问则移除缓存
open_file_cache max=10000 inactive=30s;
# 每60秒检查一次缓存中文件的有效性（如是否被修改）
open_file_cache_valid 60s;
# 一个文件至少被访问2次后才会被缓存（避免缓存低频访问文件）
open_file_cache_min_uses 2;
# 缓存文件访问错误（如文件不存在、权限问题），避免重复校验错误状态
open_file_cache_errors on;
# Gzip压缩配置（减少网络传输数据量，提升加载速度）
gzip on;# 开启Gzip压缩
gzip_vary on;# 在响应头中添加Vary: Accept-Encoding，告知客户端支持压缩
gzip_min_length 1024;# 仅压缩大小超过1024字节的文件（小文件压缩收益低）
# 指定需要压缩的MIME类型（文件类型）
gzip_types
text/plain # 纯文本
text/css # CSS样式表
text/xml # XML文档
text/javascript # JS脚本（旧标准）
application/javascript# JS脚本（新标准）
application/xml+rss # RSS订阅XML
application/json; # JSON数据
}</pre></div>
<p><strong>优化项解释</strong>：<br />- expires 30d; —— 设置 HTTP 响应头 Cache-Control: max-age=2592000，告诉浏览器可以本地缓存该资源 30 天，大幅减少重复请求。<br />- gzip on; —— 对文本类资源（HTML、CSS、JS）进行实时压缩，传输体积可减少 60%~80%。但图片（JPEG/PNG）本身已压缩，不建议再启用 gzip，浪费 CPU。<br />- autoindex on; —— 当目录下没有 index 文件时，显示文件列表。<strong>生产环境慎用</strong>，容易泄露敏感文件结构。<br />- try_files $uri $uri/ =404; —— 按顺序尝试：先找精确文件，再找目录，都不存在则返回 404。这是处理单页应用（SPA）路由的关键配置，常改为 try_files $uri /index.html;。</p>
<blockquote><p><strong>性能测试数据</strong>：在一台 2C4G 的云服务器上，未优化配置下 Nginx 处理静态图片的 QPS 约为 5000；开启 sendfile + tcp_nopush + gzip 后，QPS 可提升至 12000+，同时 CPU 使用率下降约 30%。</p></blockquote>
<p class="maodian"></p><h2>三、关键应用场景：Nginx 实战核心技能</h2>
<p class="maodian"></p><h3>3.1 反向代理：隐藏后端，统一入口</h3>
<p>反向代理是 Nginx 最常用的功能之一，它隐藏了后端服务器的细节，提供了统一的访问入口。与正向代理（如 VPN、科学上网工具）不同，反向代理对客户端是透明的，客户端以为自己在和 Nginx 直接通信。</p>
<p><strong>基础反向代理配置：</strong></p>
<p>客户端请求 → Nginx（监听 80 端口） → 根据 server_name 匹配 → location / 处理 → 转发到 proxy_pass 代理的后端服务器组 → upstream 定义后端服务器集群</p>
<div class="dxycode"><pre class="brush:bash;">server {
listen 80;
server_name example.com;
location / {
# 基本代理设置
proxy_pass http://backend_server;
# 重要的请求头设置（确保后端服务器能获取正确的客户端信息，而不是看到代理服务器的IP）
proxy_set_header Host $host; # 保持原始域名
proxy_set_header X-Real-IP $remote_addr; # 传递客户端真实IP
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 代理链IP记录
proxy_set_header X-Forwarded-Proto $scheme; # 传递原始协议(http/https)
# 超时设置（防止因后端服务响应慢而阻塞 Nginx 工作进程）
proxy_connect_timeout 30s;# 连接后端超时时间
proxy_send_timeout 30s; # 发送请求到后端超时时间
proxy_read_timeout 30s; # 读取后端响应超时时间
# 缓冲优化（缓冲后端响应，减少后端服务器连接保持时间，优化对客户端的响应传输，防止快速客户端拖慢慢速后端）
proxy_buffering on;
proxy_buffer_size 4k; # 响应头缓冲区大小
proxy_buffers 8 4k; # 响应体缓冲区(8个4k块)
}
}
# 定义后端服务器组
upstream backend_server {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}</pre></div>
<p><strong>高级代理配置：</strong></p>
<div class="dxycode"><pre class="brush:bash;">location /api/ {
# 将匹配 /api/ 路径的请求代理到名为 api_backend 的后端服务器组
proxy_pass http://api_backend;
# ======================
# 错误处理与故障转移配置
# ======================
# 定义在什么情况下应该尝试下一个上游服务器
# error: 与后端服务器建立连接、发送请求或读取响应时发生错误
# timeout: 与后端服务器连接、发送或读取超时
# invalid_header: 后端服务器返回空或无效的响应头
# http_500: 后端服务器返回500状态码
# http_502: 后端服务器返回502状态码
# http_503: 后端服务器返回503状态码
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
# 指定故障转移的最大重试次数（包括第一次请求）
# 这里设置为3次，意味着如果第一个服务器失败，会再尝试另外两个服务器
proxy_next_upstream_tries 3;
# 设置故障转移的超时时间限制
# 在30秒内如果没有成功响应，则停止尝试其他服务器并返回错误
proxy_next_upstream_timeout 30s;
# ======================
# 连接池配置（性能优化）
# ======================
# 设置与每个后端服务器保持的最大空闲keepalive连接数
# 保持连接复用可以减少TCP握手开销，提高性能
keepalive 32;
# 设置keepalive连接的最大空闲时间
# 超过30秒未使用的连接将被关闭
keepalive_timeout 30s;
# 单个keepalive连接上允许处理的最大请求数
# 达到100个请求后连接将被关闭，防止连接老化
keepalive_requests 100;
# ======================
# 超时与重试机制
# ======================
# 与后端服务器建立连接的超时时间
# 如果5秒内无法建立连接，将触发错误处理
proxy_connect_timeout 5s;
# 向后端服务器发送请求的超时时间
# 如果10秒内无法发送完所有请求数据，将触发错误处理
proxy_send_timeout 10s;
# 从后端服务器读取响应的超时时间
# 如果30秒内没有收到任何数据，将触发错误处理
# 对于API接口，这个值通常设置得比连接和发送超时长
proxy_read_timeout 30s;
}</pre></div>
<p><strong>高级配置关键点</strong>：<br />- proxy_set_header Host $host; —— 将原始请求的 Host 传给后端，避免后端拿到的是 Nginx 的 IP。<br />- proxy_set_header X-Real-IP $remote_addr; —— 将客户端真实 IP 传给后端，因为后端看到的连接来源是 Nginx 的 IP。<br />- proxy_cache 相关指令 —— 启用 Nginx 的缓存功能，可缓存后端返回的动态内容（如 API 响应），减轻后端压力。注意缓存键（proxy_cache_key）要包含请求参数。<br />- proxy_next_upstream —— 当某台后端服务器返回错误（如 500、502、503）或超时时，自动将请求转发到下一台健康的服务器。</p>
<blockquote><p><strong>注意事项</strong>：使用反向代理时，务必配置 proxy_read_timeout 和 proxy_connect_timeout，否则默认 60 秒的超时可能不适合长连接场景（如 WebSocket 或 SSE）。WebSocket 代理需要额外设置 Upgrade 和 Connection 头。</p></blockquote>
<p class="maodian"></p><h3>3.2 负载均衡：分摊压力，提升可用</h3>
<p>Nginx 提供多种负载均衡算法，可以根据业务需求选择合适的策略。负载均衡将流量分发到多个后端服务器（称为“上游服务器”），实现水平扩展和高可用。</p>
<p><strong>负载均衡配置示例：</strong></p>
<div class="dxycode"><pre class="brush:bash;">upstream backend_cluster {
# 负载均衡算法
least_conn;# 最少连接数算法
# 服务器定义
server 192.168.1.10:8080 weight=3 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 weight=2 max_fails=3 fail_timeout=30s;
server 192.168.1.12:8080 weight=1 max_fails=3 fail_timeout=30s;
server 192.168.1.13:8080 backup;# 备份服务器
}
server {
listen 80;
server_name app.example.com;
location / {
proxy_pass http://backend_cluster;
proxy_set_header Host $host;
# 其他代理配置...
}
}</pre></div>
<p><strong>不同负载均衡算法：</strong></p>
<div class="dxycode"><pre class="brush:bash;"># 1. 轮询（默认）
upstream round_robin {
server backend1.example.com;
server backend2.example.com;
}
# 2. 加权轮询
upstream weighted_round_robin {
server backend1.example.com weight=5;# 处理50%的请求
server backend2.example.com weight=3;# 处理30%的请求
server backend3.example.com weight=2;# 处理20%的请求
}
# 3. IP哈希（会话保持）
upstream ip_hash {
ip_hash;# 基于客户端IP的哈希
server backend1.example.com;
server backend2.example.com;
}
# 4. 最少连接数
upstream least_conn {
least_conn;
server backend1.example.com;
server backend2.example.com;
}
# 5. 基于响应时间的负载均衡（需要商业版）
upstream response_time {
fair;
server backend1.example.com;
server backend2.example.com;
}</pre></div>
<p><strong>算法补充说明</strong>：</p>
<table><tbody><tr><th>算法</th><th>指令</th><th>特点</th><th>适用场景</th></tr><tr><td>轮询（Round Robin）</td><td>默认</td><td>请求轮流分配，权重影响比例</td><td>通用、后端性能均衡</td></tr><tr><td>最少连接（Least Connections）</td><td>least_conn;</td><td>优先分配给活动连接数最少的后端</td><td>请求处理时间差异大</td></tr><tr><td>IP Hash</td><td>ip_hash;</td><td>同一客户端 IP 始终落到同一后端</td><td>需要会话保持（Session）</td></tr><tr><td>随机（Random）</td><td>random;</td><td>随机选择，可选 two 方法</td><td>大型集群，简单均衡</td></tr><tr><td>一致性 Hash</td><td>hash $request_uri consistent;</td><td>对 key 做一致性哈希，节点变化时影响小</td><td>分布式缓存（如 Memcached）</td></tr></tbody></table>
<blockquote><p><strong>专家建议</strong>：对于需要会话保持的应用，推荐使用 Redis 等集中式 Session 存储，而不是依赖 ip_hash。因为 ip_hash 在客户端 IP 变化（如移动网络）或后端扩缩容时会失效。如果必须用 ip_hash，建议配合 sticky 模块（Nginx Plus 或第三方模块）。</p></blockquote>
<p><strong>健康检查配置</strong>：</p>
<div><div class="dxycode"><pre class="brush:bash;">upstream backend {
server 10.0.0.1:8080 max_fails=3 fail_timeout=30s;
server 10.0.0.2:8080 max_fails=3 fail_timeout=30s;
# max_fails 表示连续失败次数，fail_timeout 表示标记为不可用的时间
}
</pre></div></div>
<p class="maodian"></p><h3>3.3 动静分离：各司其职，极致性能</h3>
<p>动静分离是提升网站性能的重要手段，将动态请求和静态请求分别处理。动态请求（如 PHP、Java、Node.js）由后端应用服务器处理，静态请求（如图片、CSS）由 Nginx 直接返回，这样可以避免后端应用服务器处理无意义的静态文件请求。</p>
<p><strong>完整的动静分离配置：</strong></p>
<div class="dxycode"><pre class="brush:bash;">upstream dynamic_backend {
server 192.168.1.20:8000;
server 192.168.1.21:8000;
}
server {
listen 80;
server_name www.example.com;
# 静态资源 - 直接由Nginx处理
location ~* \.(jpg|jpeg|png|gif|ico|css|js|pdf|txt)$ {
root /var/www/static;
# 缓存优化
expires 1y;
add_header Cache-Control "public, immutable";
# 性能优化
sendfile on;
tcp_nopush on;
# 如果文件不存在，不代理到后端
try_files $uri =404;
}
# 动态请求 - 代理到后端应用服务器
location / {
proxy_pass http://dynamic_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;
proxy_set_header X-Forwarded-Proto $scheme;
}
# API请求单独处理
location /api/ {
proxy_pass http://dynamic_backend;
# 特殊的API配置...
}
}</pre></div>
<p><strong>动静分离的优势</strong>：<br />- 减少后端应用服务器的负载和网络 IO。<br />- 静态资源可以充分利用 Nginx 的高并发和缓存特性。<br />- 方便为静态资源配置 CDN 加速。</p>
<blockquote><p><strong>注意事项</strong>：如果你的动态请求也是通过 Nginx 反向代理到后端，那么动静分离本质上就是利用 location 匹配规则将不同 URI 分发给不同的处理逻辑。注意正则匹配的优先级，避免动态请求被静态规则误拦截。</p></blockquote>
<p class="maodian"></p><h3>3.4 SSL/TLS 终端代理：打造 HTTPS 安全站点</h3>
<p>Nginx 可以作为 SSL/TLS 终端，处理加密连接，减轻后端服务器的负担。这意味着客户端与 Nginx 之间是 HTTPS 加密，而 Nginx 到后端服务器可以用 HTTP 或 HTTPS（视安全要求而定）。</p>
<p><strong>完整的 HTTPS 配置：</strong></p>
<div class="dxycode"><pre class="brush:bash;"># HTTPS服务器配置
server {
listen 443 ssl http2;# 启用HTTP/2
server_name example.com;
# SSL证书配置
ssl_certificate /etc/nginx/ssl/example.com.crt;
ssl_certificate_key /etc/nginx/ssl/example.com.key;
# SSL协议配置
ssl_protocols TLSv1.2 TLSv1.3;# 禁用不安全的旧协议
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
# SSL性能优化
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;
# 安全头设置
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
# 应用配置
location / {
proxy_pass http://backend_server;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto https;
}
}
# HTTP重定向到HTTPS
server {
listen 80;
server_name example.com;
return 301 https://$server_name$request_uri;
}</pre></div>
<p><strong>HTTPS 配置最佳实践</strong>：<br />- 使用 Let's Encrypt 免费证书，可通过 Certbot 工具自动化申请和续期。<br />- 启用 HTTP/2 协议（listen 443 ssl http2;），能显著提升多资源加载速度。<br />- 配置 HSTS（add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;）强制浏览器在指定时间内只通过 HTTPS 访问。<br />- 使用强加密套件（如 ECDHE 系列），禁用过时的 SSLv3、TLSv1.0。<br />- 开启 OCSP Stapling 可加速证书验证，提升连接速度。</p>
<blockquote><p><strong>安全提示</strong>：不要将私钥文件放在网站根目录下，且权限应设为 600（仅 root 可读写）。Nginx 配置中 ssl_certificate_key 路径要正确。另外，定期更新证书（Let's Encrypt 每 90 天过期）。</p></blockquote>
<p class="maodian"></p><h2>四、性能优化与安全加固：让 Nginx 更稳更快</h2>
<p class="maodian"></p><h3>4.1 性能调优：从配置到内核的全维度优化</h3>
<p><strong>Nginx 配置层优化：</strong></p>
<div class="dxycode"><pre class="brush:bash;"># nginx.conf 中的性能优化配置
http {
# 基础性能设置
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
keepalive_requests 1000;
# 缓冲优化
client_body_buffer_size 128k;
client_max_body_size 10m;
client_header_buffer_size 1k;
large_client_header_buffers 4 4k;
# Gzip压缩优化
gzip on;
gzip_min_length 1024;
gzip_types
text/plain
text/css
text/xml
text/javascript
application/javascript
application/xml+rss
application/json;
# 文件缓存优化
open_file_cache max=10000 inactive=30s;
open_file_cache_valid 60s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
}
# 事件模块优化
events {
worker_connections 2048;
use epoll;
multi_accept on;
}</pre></div>
<p><strong>补充配置优化细节</strong>：<br />- worker_processes auto; —— 自动设置为 CPU 核心数。<br />- worker_rlimit_nofile 65535; —— 突破系统限制，让每个 Worker 能打开更多文件句柄。<br />- multi_accept on; —— Worker 一次可接受多个新连接，减少唤醒次数。<br />- use epoll; —— Linux 下高性能事件模型。<br />- client_body_buffer_size 和 client_max_body_size 要根据实际业务调整，过大会浪费内存，过小会返回 413 错误。</p>
<p><strong>操作系统层优化：</strong></p>
<div class="dxycode"><pre class="brush:bash;"># 调整内核参数（/etc/sysctl.conf）
echo 'net.core.somaxconn = 65535' >> /etc/sysctl.conf
echo 'net.core.netdev_max_backlog = 65536' >> /etc/sysctl.conf
echo 'net.ipv4.tcp_max_syn_backlog = 65536' >> /etc/sysctl.conf
echo 'net.ipv4.tcp_fin_timeout = 30' >> /etc/sysctl.conf
echo 'net.ipv4.tcp_tw_reuse = 1' >> /etc/sysctl.conf
echo 'fs.file-max = 100000' >> /etc/sysctl.conf
# 应用配置
sysctl -p</pre></div>
<p><strong>内核参数解释</strong>：<br />- net.core.somaxconn —— 系统监听队列的最大长度，Nginx 的 listen 指令中的 backlog 不能超过该值。<br />- net.ipv4.tcp_tw_reuse —— 允许重用 TIME_WAIT 状态的端口，减少端口耗尽风险。<br />- net.ipv4.tcp_fin_timeout —— 缩短 FIN-WAIT-2 状态的持续时间。<br />- net.core.netdev_max_backlog —— 网卡队列长度，高流量下可防止丢包。</p>
<blockquote><p><strong>专家建议</strong>：优化系统内核参数前，先用 sysctl -a 备份当前配置。修改 /etc/sysctl.conf 后执行 sysctl -p 生效。不要盲目调大所有值，应根据实际内存和流量测试调整。</p></blockquote>
<p class="maodian"></p><h3>4.2 安全加固：抵御常见攻击</h3>
<p><strong>基础安全配置：</strong></p>
<div class="dxycode"><pre class="brush:bash;">server {
# 隐藏Nginx版本信息
server_tokens off;
# 安全头设置
add_header X-Frame-Options "SAMEORIGIN" 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;
# 限制请求方法
if ($request_method !~ ^(GET|HEAD|POST)$) {
return 405;
}
# 防止点击劫持
add_header X-Frame-Options "SAMEORIGIN";
# 限制文件上传大小
client_max_body_size 10m;
}
# 速率限制防御DDoS
http {
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=1r/m;
server {
location /api/ {
limit_req zone=api burst=20 nodelay;
# API配置...
}
location /login {
limit_req zone=login burst=5;
# 登录配置...
}
}
}</pre></div>
<p><strong>高级安全防护：</strong></p>
<div class="dxycode"><pre class="brush:bash;"># 防止SQL注入和XSS攻击
server {
# 屏蔽敏感文件
location ~ /\.(ht|git|svn) {
deny all;
}
location ~* \.(bak|config|sql|log)$ {
deny all;
}
# 防止图片盗链
location ~* \.(jpg|jpeg|png|gif)$ {
valid_referers none blocked server_names ~\.google\. ~\.baidu\.;
if ($invalid_referer) {
return 403;
# 或者返回一个默认图片
# rewrite ^ /images/blocked.png;
}
}
}</pre></div>
<p><strong>安全防护详解</strong>：<br />- <strong>DDoS 缓解</strong>：通过 limit_req 和 limit_conn 限制单个 IP 的请求速率和并发连接数，可防御 CC 攻击。<br />- <strong>隐藏版本号</strong>：server_tokens off; 防止攻击者知道 Nginx 具体版本，利用已知漏洞。<br />- <strong>禁用危险方法</strong>：只允许 GET、HEAD、POST，防止 PUT、DELETE 等未授权操作。<br />- <strong>自定义错误页面</strong>：统一错误页面，避免暴露内部路径信息。<br />- <strong>WAF 集成</strong>：可以编译 ModSecurity 模块，或使用 Nginx Plus 的 WAF 功能，实现 SQL 注入、XSS 等攻击的检测和拦截。</p>
<blockquote><p><strong>注意事项</strong>：安全配置要平衡可用性。比如限流阈值设置过低会误伤正常用户；禁用 TRACE 方法后，某些调试工具可能受影响。建议先在测试环境验证。</p></blockquote>
<p class="maodian"></p><h2>五、总结与展望：Nginx 的核心价值与未来</h2>
<p class="maodian"></p><h3>5.1 核心价值总结</h3>
<p>通过本文的学习，我们可以看到 Nginx 的核心价值体现在：</p>
<p><strong>卓越的性能</strong>：事件驱动架构轻松应对高并发场景，单机可支撑数万甚至数十万并发连接。</p>
<p><strong>灵活的配置</strong>：模块化设计支持各种复杂业务需求，从简单的静态服务器到复杂的七层代理。</p>
<p><strong>稳定的运行</strong>：Master-Worker 进程模型确保服务高可用，热升级不中断业务。</p>
<p><strong>丰富的生态</strong>：大量第三方模块（Lua、GeoIP、Brotli、VTS 等）扩展功能边界，甚至能实现 API 网关级别的功能。</p>
<p class="maodian"></p><h3>5.2 Nginx 与其他技术的对比</h3>
<table><tbody><tr><th>特性</th><th>Nginx</th><th>Apache</th><th>Caddy</th></tr><tr><td>性能</td><td>⭐⭐⭐⭐⭐</td><td>⭐⭐⭐</td><td>⭐⭐⭐⭐</td></tr><tr><td>配置复杂度</td><td>⭐⭐⭐⭐</td><td>⭐⭐⭐</td><td>⭐⭐⭐⭐⭐</td></tr><tr><td>功能丰富度</td><td>⭐⭐⭐⭐⭐</td><td>⭐⭐⭐⭐⭐</td><td>⭐⭐⭐</td></tr><tr><td>学习曲线</td><td>⭐⭐⭐</td><td>⭐⭐⭐⭐</td><td>⭐⭐⭐⭐⭐</td></tr><tr><td>社区生态</td><td>⭐⭐⭐⭐⭐</td><td>⭐⭐⭐⭐⭐</td><td>⭐⭐⭐</td></tr></tbody></table>
<blockquote><p><strong>对比分析</strong>：<br />- <strong>Nginx vs Apache</strong>：Apache 功能丰富（.htaccess、动态模块加载），但高并发下性能劣化明显；Nginx 则相反，适合作为前端入口。<br />- <strong>Nginx vs HAProxy</strong>：HAProxy 专注四层/七层负载均衡，性能极致，但缺少 Web 服务器和丰富的 SSL 功能；Nginx 更全能。<br />- <strong>Nginx vs Envoy</strong>：Envoy 是云原生时代的宠儿，服务发现、动态配置能力强大，但配置复杂；Nginx 更成熟、文档更友好。<br />- <strong>Nginx vs Caddy</strong>：Caddy 自动 HTTPS 非常方便，适合个人和小型项目，但社区规模和生态不如 Nginx。</p></blockquote>
<p class="maodian"></p><h3>5.3 未来发展趋势</h3>
<p><strong>云原生支持</strong>：Nginx 在 Kubernetes 生态中作为 Ingress Controller 广泛应用（如 ingress-nginx、Nginx Ingress Controller）。未来会进一步整合服务网格（如与 Istio 集成）。</p>
<p><strong>边缘计算</strong>：作为边缘节点处理计算和缓存任务，Nginx 的轻量级和高性能非常适合 CDN 边缘节点和 IoT 网关。</p>
<p><strong>API 网关</strong>：功能不断丰富，向全功能 API 网关演进（Nginx Plus 已提供认证、限流、监控、API 定义等）。开源版可以通过 Lua 模块扩展类似功能。</p>
<p><strong>安全增强</strong>：集成更多安全功能，如 WAF、Bot 防护、mTLS 等。未来可能会内置更简单的自动化 HTTPS 和零信任架构支持。</p>
<blockquote><p><strong>学习建议</strong>：持续关注 Nginx 官方博客和 NGINX Conference 的新特性。同时，学习 OpenResty（基于 Nginx 和 Lua）可以极大扩展 Nginx 的编程能力，适用于复杂业务逻辑。</p></blockquote>
<p class="maodian"></p><h2>附录：Nginx 常用工具与资源</h2>
<p class="maodian"></p><h3>常用命令速查</h3>
<div class="dxycode"><pre class="brush:bash;"># 测试配置
nginx -t
# 重新加载配置（不中断服务）
nginx -s reload
# 重新打开日志文件
nginx -s reopen
# 优雅停止
nginx -s quit
</pre></div>
<p><strong>命令补充说明</strong>：</p>
<table><tbody><tr><th>命令</th><th>作用</th></tr><tr><td>nginx -t</td><td>测试配置文件语法是否正确，并显示错误行号</td></tr><tr><td>nginx -s reload</td><td>平滑重载配置，不中断现有连接</td></tr><tr><td>nginx -s stop</td><td>快速停止（立即终止进程）</td></tr><tr><td>nginx -s quit</td><td>优雅停止（处理完当前请求后退出）</td></tr><tr><td>nginx -V</td><td>显示编译参数和版本，用于排查模块支持情况</td></tr><tr><td>nginx -T</td><td>打印当前生效的完整配置（包含 include 文件）</td></tr><tr><td>kill -USR1 <nginx-master-pid></td><td>重新打开日志文件，用于日志切割</td></tr><tr><td>kill -USR2 <nginx-master-pid></td><td>平滑升级二进制文件（配合 kill -WINCH）</td></tr></tbody></table>
<p><strong>常用资源链接</strong>：<br />- 官方文档：https://nginx.org/en/docs/<br />- Nginx 中文文档（非官方）：https://www.nginx.cn/doc/<br />- 配置在线检查工具：https://nginxconfig.io/<br />- GitHub 上的优秀配置范例：https://github.com/h5bp/server-configs-nginx</p>
<blockquote><p><strong>最后提醒</strong>：生产环境部署前，务必在测试环境用 nginx -t 和压力测试工具（如 wrk、ab、JMeter）验证配置的正确性和性能表现。配置变更后建议分批次灰度发布，避免一次性全量导致服务中断。</p></blockquote>
頁:
[1]