在现代 Web 架构中，Nginx 反向代理被广泛用于负载均衡、安全防护和性能优化。但你是否想过：如果后端某台服务器宕机了怎么办？这时候就需要健康检查机制来自动剔除故障节点，保障服务的高可用性。
本教程将从零开始，用最通俗易懂的方式，教你在 Nginx 中配置反向代理并实现基本的健康检查功能，即使你是刚入门的小白也能轻松上手！
什么是 Nginx 反向代理？
简单来说，反向代理就是用户访问的是 Nginx 服务器，而 Nginx 再把请求转发给后端真正的应用服务器（比如运行着 Python、Java 或 Node.js 的服务器）。这样做的好处包括：
- 隐藏真实服务器，提高安全性
- 实现负载均衡，分摊流量压力
- 缓存静态资源，提升访问速度
为什么需要健康检查？
假设你有两台后端服务器 A 和 B，通过 Nginx 做负载均衡。如果服务器 A 突然宕机，但 Nginx 不知道，还会继续把请求发给 A，导致部分用户访问失败。这就是健康检查要解决的问题——自动探测后端服务状态，只把请求转发给健康的服务器。
Nginx 原生支持健康检查吗？
标准版 Nginx（开源版本）不支持主动健康检查，它只能通过“被动检查”来判断后端是否可用——即当某个请求失败时，才暂时标记该服务器为不可用。
如果你需要更强大的主动健康检查（比如定时 ping 后端），需要使用 Nginx Plus（商业版）或结合第三方模块（如 nginx_upstream_check_module）。但对大多数小型项目来说，Nginx 的被动健康检查已经足够实用。
实战：配置带健康检查的反向代理
下面我们以一个具体例子演示如何配置。假设有两台后端服务器：
- 192.168.1.10:8080
- 192.168.1.11:8080
我们希望 Nginx 能自动跳过宕机的服务器。编辑 Nginx 配置文件（通常位于 /etc/nginx/nginx.conf 或 /etc/nginx/sites-available/default）：
http { upstream backend { # 定义后端服务器组 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 { listen 80; server_name example.com; location / { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }}关键参数解释：
max_fails=3：在fail_timeout时间内，如果连续失败 3 次，就认为该服务器不可用。fail_timeout=30s：这个时间既是失败计数窗口，也是服务器被标记为不可用的持续时间。30 秒后，Nginx 会再次尝试将请求转发给它。
这样配置后，Nginx 就具备了基本的被动健康检查能力。这也是大多数使用 Nginx 配置实现高可用的常用方法。
测试健康检查是否生效
你可以手动停止其中一台后端服务（比如关闭 192.168.1.10 上的 Web 服务），然后不断刷新浏览器访问 Nginx 地址。你会发现请求只会被转发到另一台健康的服务器，不会出现 502 错误（前提是至少有一台服务器正常）。
进阶建议
如果你的业务对可用性要求极高，可以考虑以下方案：
- 使用 Nginx Plus 实现主动健康检查（支持 HTTP、TCP、UDP 等协议探测）
- 结合外部监控工具（如 Prometheus + Blackbox Exporter）实现更复杂的健康检查逻辑
- 在应用层返回特定健康检查接口（如
/health），供 Nginx 或其他组件调用
总结
通过本文，你已经学会了如何利用 Nginx 的 upstream 模块配置简单的健康检查机制，实现基本的负载均衡与故障转移。虽然开源版 Nginx 不支持主动探测，但其被动检查机制在多数场景下已足够可靠。
记住关键词：Nginx反向代理、健康检查、Nginx配置、负载均衡。掌握这些概念，你离构建高可用 Web 架构又近了一步！
提示：修改 Nginx 配置后，记得运行 nginx -t 测试语法，并执行 systemctl reload nginx 重新加载配置，无需重启服务。