1. 从“一个请求”开始理解Nginx的江湖地位如果你刚接触服务器运维或者后端开发大概率会听到一个名字Nginx。它无处不在却又常常隐于幕后。你可能知道它很快知道它能做“反向代理”和“负载均衡”但具体怎么个快法为什么是它而不是别的软件心里可能没底。今天我们不谈那些空洞的“高性能、高并发”口号就从你浏览器敲下回车到页面加载出来这短短一瞬间看看Nginx到底扮演了什么角色以及我们为什么需要花时间搞懂它。想象一个场景你访问一个热门网站比如一个电商首页。你的请求并不是直接飞到存放网页和商品图片的“仓库服务器”我们称之为应用服务器那里。直接飞过去会有几个大问题第一“仓库”可能很忙同时处理成千上万个请求会累垮第二“仓库”可能只擅长打包货物运行业务逻辑不擅长快速分发小件处理静态文件第三如果只有一个“仓库”它一宕机整个网站就挂了。这时候就需要一个“超级前台”或者“智能调度中心”——这就是Nginx。Nginx的核心工作就是坐在所有应用服务器的前面接收所有来自互联网的请求HTTP/HTTPS然后根据一套你制定的规则决定把这个请求转给后面哪一台服务器去处理或者干脆自己就处理了。这个“超级前台”效率极高它用一套非常精巧的“事件驱动”和“非阻塞”模型来干活使得它用很少的资源CPU和内存就能同时应对数万、甚至数十万的并发连接。简单说它把杂活、累活都揽了让后面的业务服务器专心去处理复杂的业务逻辑。所以无论是个人博客还是日均PV过亿的大型网站Nginx的身影都极为常见。搞懂Nginx对于开发者而言意味着你能自己掌控流量入口优化访问速度对于运维而言意味着你能构建稳定、可扩展的服务架构。接下来我会带你绕过那些枯燥的理论直接切入核心概念、实战配置和那些容易踩坑的细节让你能快速上手并理解其背后的设计哲学。2. Nginx核心概念拆解进程模型、上下文与配置结构在动手安装和配置之前我们必须先理解Nginx的几个核心设计理念。这能帮你从根上明白它的配置为什么那样写出了问题该从哪个方向排查。2.1 核心架构Master与Worker进程这是理解Nginx高性能的基石。当你启动Nginx后用ps -ef | grep nginx命令查看通常会看到至少两个进程一个master进程一个或多个worker进程。Master进程以root用户身份运行因为需要监听80/443等特权端口。它的职责是“管理”本身不处理任何网络请求。它负责读取和验证配置文件、管理worker进程的生命周期启动、停止、平滑重启、重新加载配置、日志文件重开。Worker进程在Master进程指导下以普通用户如www-data,nginx身份运行的实际“干活”的进程。它们处理具体的网络连接、读取请求、处理请求静态文件或转发给后端。多个Worker进程之间是平等的共享监听套接字通过操作系统内核提供的机制如epoll,kqueue来实现高效的事件驱动和非阻塞I/O。这种设计带来了巨大优势高稳定性Worker进程是相互隔离的。即使某个Worker由于后端应用崩溃或代码bug而异常退出Master进程会立刻启动一个新的Worker接替不会影响其他Worker服务整体不会中断。高性能与可扩展性Worker数量通常配置为与服务器CPU核心数相同或倍数可以充分利用多核CPU的并行计算能力。每个Worker都能独立处理成千上万的连接。权限与安全Master以root权限做需要特权的事如绑定端口实际处理请求的Worker以低权限用户运行即使被攻破危害也相对有限。热部署与平滑升级这是Nginx的一大特色。你可以替换Nginx二进制文件然后通过向Master进程发送信号让它启动新的Worker使用新版本二进制并优雅地关闭旧的Worker实现服务不中断的版本升级。2.2 配置文件的骨架main, events, http, server, locationNginx的配置文件默认是nginx.conf像一棵树有清晰的层次结构。理解这个结构配置时才能心中有图。main上下文这是最外层的配置配置影响Nginx全局的指令。例如设置Worker进程数worker_processes、运行用户user、错误日志路径error_log、PID文件位置pid等。它不属于任何其他块。user nginx; worker_processes auto; # 自动设置为CPU核心数 error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid;events上下文这个块用来配置影响Nginx服务器与客户端网络连接处理的参数。它被包含在main上下文中。最重要的指令是use用来指定Nginx使用哪种事件驱动模型如epoll在Linux 2.6上这是最高效的以及worker_connections定义每个Worker进程可以同时打开的最大连接数。events { worker_connections 1024; # 每个worker最大连接数 use epoll; # Linux高效事件模型 multi_accept on; # 一个worker一次接受所有新连接 }http上下文这是配置HTTP服务器相关所有功能的核心块。一个nginx.conf里只能有一个http块。在这里你可以设置MIME类型、默认日志格式、连接超时时间、以及最重要的——定义多个虚拟主机server块。http { include /etc/nginx/mime.types; # 引入MIME类型定义文件 default_type application/octet-stream; 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; # 在sendfile开启时优化数据包发送 keepalive_timeout 65; # 长连接超时时间 # 这里可以包含其他server配置文件 include /etc/nginx/conf.d/*.conf; }server上下文这个块定义了一个“虚拟主机”。一个http块内可以有多个server块Nginx通过监听不同的server_name域名或端口来区分它们。这是你配置网站的主要地方。server { listen 80; # 监听80端口 server_name example.com www.example.com; # 匹配的域名 root /usr/share/nginx/html; # 网站根目录 index index.html index.htm; ... }location上下文这是嵌套在server块内的最灵活的配置单元。它根据请求的URI路径来匹配并对匹配到的请求应用特定的处理规则。location的匹配规则是理解Nginx配置的关键和难点。location / { # 匹配所有以 / 开头的请求 try_files $uri $uri/ 404; } location /images/ { # 匹配所有以 /images/ 开头的请求 expires 30d; # 设置缓存过期时间 access_log off; # 关闭访问日志 } location ~ \.php$ { # 使用正则表达式匹配所有以 .php 结尾的请求 fastcgi_pass 127.0.0.1:9000; # 转发给PHP-FPM处理 ... }2.3 Location匹配的优先级精确、前缀与正则的博弈这是配置中最容易混淆的地方。当请求到达一个server块时Nginx会遍历所有的location块找出“最佳匹配”。规则如下精确匹配 (location /exact/path)优先级最高。只有当请求的URI完全等于后面的路径时才会被匹配。前缀匹配普通前缀匹配 (location /prefix/)匹配以指定字符串开头的URI。最长前缀匹配 (location ^~ /longest/prefix/)如果匹配成功Nginx会停止搜索正则表达式location直接使用这个规则。^~符号赋予了它高于正则匹配的优先级。正则表达式匹配 (location ~ \.php$)按在配置文件中出现的顺序进行匹配第一个匹配成功的正则表达式会被使用。一旦被某个正则location匹配就不会再考虑后面的正则location但前缀匹配除非是^~的搜索发生在正则之前。通用匹配 (location /)这是一个特殊的普通前缀匹配匹配所有请求。如果没有任何其他location匹配最终会落到这里。一个经典的匹配顺序示例server { location / { # 规则A精确匹配根路径 # 仅匹配 http://example.com/ } location ^~ /static/ { # 规则B最长前缀匹配禁止正则检查 # 匹配 http://example.com/static/xxx } location ~ \.(gif|jpg|png)$ { # 规则C正则匹配图片 # 匹配 http://example.com/abc/1.jpg } location / { # 规则D通用匹配 # 匹配其他所有请求 } }对于请求/static/logo.png它会先尝试精确匹配失败然后找前缀匹配发现^~ /static/匹配由于使用了^~Nginx直接采用规则B不再检查后面的正则规则C。实操心得在配置时尽量使用精确匹配和带^~的前缀匹配来处理明确的静态资源路径将性能消耗较大的正则匹配如代理PHP、路由重写放在后面。清晰的匹配顺序是写出高效、无冲突配置的关键。3. 实战配置从静态服务到反向代理与负载均衡理解了核心概念我们来看Nginx最常用的几个实战场景。我会给出配置示例并解释每个指令的意图。3.1 基础静态文件服务器这是最简单的应用。假设你的网站文件放在/data/www目录下。server { listen 80; server_name my-site.com; # 设置字符集避免中文乱码 charset utf-8; # 网站根目录 root /data/www; # 默认索引文件 index index.html index.htm; # 通用location处理所有请求 location / { # try_files指令非常有用按顺序检查文件是否存在 # $uri 代表请求的文件路径$uri/ 代表对应的目录 # 如果文件和目录都不存在则返回404错误 try_files $uri $uri/ 404; } # 专门处理图片、字体等静态资源设置浏览器缓存 location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff|woff2|ttf|svg)$ { expires 1y; # 告诉浏览器缓存1年 add_header Cache-Control public, immutable; # 更精细的缓存控制 access_log off; # 静态资源访问日志通常可以关闭减少磁盘IO # 再次使用try_files确保文件存在 try_files $uri 404; } # 自定义错误页面提升用户体验 error_page 404 /404.html; location /404.html { root /data/www; internal; # 标记为内部请求禁止外部直接访问 } }关键指令解析try_files $uri $uri/ 404;这是静态服务器的灵魂。它按顺序检查1) 请求的文件$uri是否存在2) 请求的路径是否是一个目录$uri/如果是会寻找该目录下的index文件3) 如果前两者都不存在则返回404状态码。expires 1y;设置Expires和Cache-Control响应头告诉浏览器可以将这些静态资源缓存1年。这能极大减少重复请求加快页面加载速度。internal;用于error_page指定的位置表示这个location只能被Nginx内部重定向访问外部用户无法直接通过URL访问到/404.html这个页面更安全。3.2 反向代理与负载均衡这是Nginx在生产环境中最核心的用途。假设你有三个运行在8080端口的Java应用实例10.0.0.1:8080,10.0.0.2:8080,10.0.0.3:8080。首先在http上下文中定义一个上游服务器组upstreamhttp { # 定义名为 backend_servers 的上游服务器组 upstream backend_servers { # 默认负载均衡策略是轮询 (round-robin) server 10.0.0.1:8080; server 10.0.0.2:8080; server 10.0.0.3:8080; # 可以设置权重权重越高被分配到的请求越多 # server 10.0.0.1:8080 weight3; # server 10.0.0.2:8080 weight2; # server 10.0.0.3:8080 weight1; } ... }然后在server块中将特定请求代理到这个上游组server { listen 80; server_name api.myapp.com; location / { # 将请求代理到 upstream 块定义的服务器组 proxy_pass http://backend_servers; # 以下是一组非常重要的代理设置用于正确传递客户端信息 proxy_set_header Host $host; # 将原始请求的Host头传递给后端 proxy_set_header X-Real-IP $remote_addr; # 传递客户端真实IP proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 追加客户端IP到X-Forwarded-For链 proxy_set_header X-Forwarded-Proto $scheme; # 传递原始请求协议http/https # 超时设置根据后端应用处理能力调整 proxy_connect_timeout 30s; # 与后端服务器建立连接的超时时间 proxy_send_timeout 60s; # 向后端服务器发送请求的超时时间 proxy_read_timeout 60s; # 从后端服务器读取响应的超时时间 # 缓冲区优化提升性能 proxy_buffering on; proxy_buffer_size 4k; proxy_buffers 8 4k; proxy_busy_buffers_size 8k; } }负载均衡策略 除了默认的轮询round-robinupstream还支持其他策略ip_hash根据客户端IP的哈希值分配服务器能保证同一客户端的请求总是落到同一台后端服务器可用于解决Session共享问题。upstream backend_servers { ip_hash; server 10.0.0.1:8080; server 10.0.0.2:8080; }least_conn将请求发送给当前活跃连接数最少的后端服务器适合处理请求耗时差异较大的场景。hash根据你指定的关键字如$request_uri进行哈希分配可以实现URI级别的缓存亲和性。避坑指南proxy_set_header的重要性很多初学者配置反向代理后发现后端应用获取到的客户端IP都是Nginx服务器的IP如127.0.0.1日志里全是同一个IP。这是因为Nginx作为代理默认向后端传递的是它自己连接后端时的TCP连接信息。必须通过proxy_set_header指令显式地将原始客户端的IP$remote_addr等信息传递过去。后端应用如Tomcat, Node.js, PHP也需要配置为从X-Real-IP或X-Forwarded-For头部读取真实IP。3.3 HTTPS与SSL/TLS配置如今HTTPS已是网站标配。Nginx配置HTTPS需要SSL证书和私钥。server { listen 443 ssl http2; # 监听443端口启用SSL和HTTP/2 server_name my-secure-site.com; root /data/www; # SSL证书和私钥文件路径 ssl_certificate /etc/nginx/ssl/my-site.crt; # 证书链文件通常包含服务器证书和中间CA证书 ssl_certificate_key /etc/nginx/ssl/my-site.key; # 私钥文件 # SSL协议和加密套件配置禁用不安全的旧协议 ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4; ssl_prefer_server_ciphers on; # 启用HSTS强制浏览器在未来一段时间内只能通过HTTPS访问该域名 add_header Strict-Transport-Security max-age31536000; includeSubDomains always; # 会话复用提升性能 ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; location / { try_files $uri $uri/ 404; } } # 通常我们还会配置一个HTTP的server将80端口的所有请求重定向到HTTPS server { listen 80; server_name my-secure-site.com; # 301永久重定向到HTTPS版本 return 301 https://$server_name$request_uri; }关于国密证书GMSSL在一些特定领域需要使用国密算法。配置逻辑与上述类似但需要Nginx支持GMSSL。这通常意味着你需要使用支持国密的OpenSSL分支如GmSSL来编译Nginx。编译安装后配置文件中指定国密证书和私钥.sm2.key并配置对应的国密加密套件。这是一个相对专业的领域需要根据具体的国密合规要求进行操作。4. 高级场景与性能调优当网站流量增长或者有特殊需求时以下高级配置和调优技巧就显得尤为重要。4.1 动静分离与缓存优化动静分离是提升性能的经典模式。将静态资源图片、CSS、JS和动态请求API分开处理。upstream app_backend { server 10.0.0.10:8080; } server { listen 80; server_name www.my-large-site.com; root /data/static; # 静态资源根目录 # 动态API请求转发给后端应用 location /api/ { proxy_pass http://app_backend; proxy_set_header Host $host; # ... 其他代理头设置 } # 静态资源由Nginx直接高效处理 location ~* \.(jpg|jpeg|png|gif|css|js|woff2)$ { expires max; # 设置最大缓存时间 add_header Cache-Control public; # 可以进一步将静态资源托管到CDN这里配置CDN回源地址 # try_files $uri cdn_fallback; } # 首页或其他HTML页面可能也需要代理或者直接服务静态HTML location / { # 如果首页是静态的 try_files $uri /index.html; # 如果首页是动态的 # proxy_pass http://app_backend; } }代理缓存对于变化不频繁的动态内容如商品详情页、新闻文章Nginx可以充当缓存层将后端响应缓存起来直接返回给后续相同请求极大减轻后端压力。http { # 在http上下文中定义缓存路径和参数 proxy_cache_path /var/cache/nginx levels1:2 keys_zonemy_cache:10m inactive60m max_size1g use_temp_pathoff; server { location /dynamic-content/ { proxy_pass http://backend; # 启用缓存并指定缓存区域 proxy_cache my_cache; # 定义缓存键默认是$scheme$proxy_host$request_uri通常够用 proxy_cache_key $scheme$request_method$host$request_uri; # 针对哪些状态码进行缓存缓存多久 proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m; # 增加一个响应头方便调试是否命中缓存 add_header X-Cache-Status $upstream_cache_status; } } }$upstream_cache_status的可能值有MISS未命中、HIT命中、BYPASS绕过缓存、EXPIRED缓存过期等。4.2 连接、超时与缓冲区调优这些参数直接影响服务的稳定性和吞吐量需要根据实际业务调整。连接与进程events { worker_connections 4096; # 提高单个worker的连接数上限 multi_accept on; # 一次接受所有新连接在高并发下性能更好 use epoll; # Linux下务必使用epoll } http { # 启用文件描述符缓存减少重复打开同一文件的消耗 open_file_cache max1000 inactive20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on; # 关闭非必要的访问日志或使用缓冲写入减少磁盘IO阻塞 access_log /var/log/nginx/access.log buffer32k flush5s; # 对于静态资源server可以直接关闭access_log # access_log off; }代理超时这是解决“504 Gateway Time-out”错误的关键。如果你的后端应用处理某些请求很慢如大文件上传、复杂计算就需要调大这些值。location /slow-api/ { proxy_pass http://backend; proxy_connect_timeout 75s; # 建立连接超时 proxy_send_timeout 300s; # 发送请求超时对于上传场景很重要 proxy_read_timeout 300s; # 读取响应超时 # 注意client_body_timeout和client_header_timeout是客户端与Nginx之间的超时也需关注 }缓冲区代理缓冲区大小设置不当可能导致大响应被截断或效率低下。proxy_buffering on; proxy_buffer_size 8k; # 存储响应头的缓冲区大小 proxy_buffers 8 8k; # 用于读取响应的缓冲区数量和大小 proxy_busy_buffers_size 16k; # 当缓冲区忙时可分配的额外缓冲区大小 proxy_temp_path /var/tmp/nginx/proxy_temp; # 临时文件路径确保有足够空间如果响应体非常大如视频文件可以考虑关闭代理缓冲proxy_buffering off;让数据流式地传递给客户端减少Nginx内存占用但会增加后端服务器的连接保持时间。4.3 限流与访问控制保护后端服务不被突发流量或恶意请求打垮。限制请求速率使用limit_req_zone和limit_req。http { # 定义限制区域名为req_limit以客户端IP($binary_remote_addr)为key # 分配10m的内存空间来存储状态平均速率限制为每秒10个请求 limit_req_zone $binary_remote_addr zonereq_limit:10m rate10r/s; server { location /api/ { # 应用限制区域突发队列大小为5个请求 # 超过速率限制的请求会被延迟处理队列满则返回503错误 limit_req zonereq_limit burst5 nodelay; proxy_pass http://backend; } } }限制并发连接数使用limit_conn_zone和limit_conn。http { # 定义连接限制区域每个IP同时最多10个连接 limit_conn_zone $binary_remote_addr zoneconn_limit:10m; server { location /download/ { # 应用连接限制 limit_conn conn_limit 10; # 还可以设置下载速度限制 limit_rate 500k; # 限制单个连接下载速度为500KB/s alias /data/big-files/; } } }基于IP的访问控制location /admin/ { # 允许特定IP段 allow 192.168.1.0/24; allow 10.0.0.1; # 拒绝所有其他IP deny all; proxy_pass http://backend_admin; }5. 运维实战安装、启停、排错与高可用5.1 安装方式选择与初始化Linux系统安装Yum/Apt (推荐)最简单便于后续升级和管理。# CentOS/RHEL sudo yum install epel-release sudo yum install nginx # Ubuntu/Debian sudo apt update sudo apt install nginx源码编译安装需要最大灵活性时使用例如需要添加第三方模块如ngx_http_substitutions_filter_module、使用特定版本的OpenSSL如国密支持或进行深度定制。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-http_stub_status_module # 添加状态监控模块 make sudo make installDocker部署适合容器化环境快速部署和版本隔离。docker run -d --name my-nginx \ -p 80:80 -p 443:443 \ -v /path/to/nginx.conf:/etc/nginx/nginx.conf:ro \ -v /path/to/html:/usr/share/nginx/html:ro \ nginx:latest注意Docker方式需要将主机上的配置文件和网站目录通过-v参数挂载到容器内。生产环境建议使用docker-compose或Kubernetes进行编排。关键目录说明以Yum安装为例配置文件/etc/nginx/nginx.conf(主配置)/etc/nginx/conf.d/(推荐存放自定义server配置)。网站根目录/usr/share/nginx/html(默认)。日志文件/var/log/nginx/access.log(访问日志)/var/log/nginx/error.log(错误日志)。二进制文件/usr/sbin/nginx。5.2 日常操作命令与信号管理Nginx Master进程接收信号来管理服务。这些操作是运维日常。启动sudo systemctl start nginx(Systemd) 或/usr/sbin/nginx(源码安装)。停止快速停止sudo systemctl stop nginx或nginx -s stop。立即终止所有进程。优雅停止nginx -s quit。处理完当前所有请求后再停止。重载配置sudo systemctl reload nginx或nginx -s reload。这是最常用的命令之一。Master进程检查新配置语法如果正确则启动新的Worker进程并优雅关闭旧的实现配置热更新服务不中断。重新打开日志文件nginx -s reopen。在日志切割logrotate后通知Nginx重新打开日志文件。测试配置语法nginx -t。在每次修改配置文件后必须执行此命令它能提前发现语法错误避免错误配置导致服务重启失败。查看版本和编译参数nginx -V。5.3 常见错误排查思路当访问出现问题时按照以下顺序排查检查Nginx服务状态systemctl status nginx或ps -ef | grep nginx确认进程是否在运行。检查配置语法nginx -t确保没有语法错误。查看错误日志tail -f /var/log/nginx/error.log。这是定位问题的第一现场。常见的错误信息connect() failed (111: Connection refused)Nginx无法连接到后端服务器upstream。检查后端服务是否启动防火墙是否放行端口。upstream timed out (110: Connection timed out)代理超时。根据错误是connect、send还是read调整对应的proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout。13: Permission denied权限问题。检查Nginx Worker进程用户如nginx是否有权限读取网站文件root目录或访问证书文件。404 Not Found文件不存在。检查root目录和try_files指令配置以及请求的URI是否正确。403 Forbidden禁止访问。通常是目录索引被禁用autoindex off且没有默认索引文件index或者SELinux策略限制在CentOS/RHEL上常见。查看访问日志tail -f /var/log/nginx/access.log。查看请求是否到达Nginx状态码是什么。状态码含义200成功。301/302重定向。400客户端请求错误。403禁止访问。404未找到。500后端服务器内部错误。502 Bad GatewayNginx无法从后端收到有效响应。后端服务可能崩溃或未启动。504 Gateway Time-outNginx等待后端响应超时。检查网络与端口使用telnet 后端IP 后端端口或curl -v http://后端地址确认后端服务本身是否可访问。检查文件权限与SELinux确保网站目录和文件对Nginx进程用户可读。对于SELinux可以临时设置为宽容模式测试setenforce 0如果问题解决则需要配置正确的SELinux上下文chcon -Rt httpd_sys_content_t /your/web/root。5.4 构建高可用架构Keepalived Nginx单台Nginx存在单点故障风险。可以通过Keepalived实现Nginx的高可用HA。原理两台或多台Nginx服务器安装Keepalived它们共享一个虚拟IPVIP。Keepalived通过VRRP协议竞选出一个Master节点该节点绑定VIP并提供服务。其他节点为Backup。Master会定期向Backup发送心跳。如果Backup收不到心跳则认为Master故障会发起竞选新的Master接管VIP从而实现故障自动转移。简易配置步骤在两台服务器Nginx-A和Nginx-B上安装Nginx和Keepalived。配置Nginx确保服务正常。编辑Keepalived配置文件/etc/keepalived/keepalived.conf。Nginx-A (Master) 配置示例vrrp_script chk_nginx { script /usr/bin/pkill -0 nginx # 检查nginx进程是否存在 interval 2 # 每2秒检查一次 weight -5 # 如果检查失败优先级降低5 fall 2 # 连续2次失败才认为失败 rise 1 # 一次成功就认为恢复 } vrrp_instance VI_1 { state MASTER # 初始状态为MASTER interface eth0 # 绑定VIP的网络接口 virtual_router_id 51 # 虚拟路由ID同一组设备必须相同 priority 100 # 优先级MASTER要高于BACKUP advert_int 1 # 心跳间隔1秒 authentication { auth_type PASS auth_pass 1111 # 认证密码同一组设备必须相同 } virtual_ipaddress { 192.168.1.100/24 # 虚拟IP (VIP) } track_script { chk_nginx # 关联健康检查脚本 } }Nginx-B (Backup) 配置只需将state改为BACKUPpriority改为比100小的值如90。启动Keepalived服务systemctl start keepalived。测试访问VIP192.168.1.100应能访问到Nginx服务。手动停止Master上的Nginx或关机VIP应能自动漂移到Backup服务器服务中断时间很短秒级。通过以上五个部分的梳理我们从Nginx是什么、为什么快讲到了核心配置概念、常用场景配置、性能调优和运维实战。掌握这些你已能应对绝大多数与Nginx相关的日常开发与运维工作。记住理解其设计哲学事件驱动、非阻塞、Master-Worker是灵活运用和深度排查的基础。最好的学习方式就是搭建一个环境亲手修改配置观察日志解决遇到的各种问题。