Nginx 不直接处理数据库故障，而是通过健康检查与故障转移机制绕过因数据库异常导致响应失败的后端节点；需配置主动/被动健康检查、proxy_next_upstream 重试及应用层协同兜底。
Nginx 本身不直接处理数据库故障，它作为反向代理或负载均衡器，只负责转发 HTTP 请求到后端服务（如应用服务器）。当数据库出问题导致后端应用节点异常（比如返回 500、超时、拒绝连接），Nginx 可通过健康检查与故障转移机制自动绕过异常节点，保障服务连续性。
理解故障源头：数据库异常如何影响 Nginx 节点
数据库故障通常不会让 Nginx 自身崩溃，但会引发连锁反应：
- 后端应用（如 Java/Python 服务）因连不上 DB 而响应变慢、超时或直接返回 5xx 错误
- Nginx 将这些响应原样透传给客户端，或在超时后主动断开连接
- 若未配置容错策略，Nginx 仍会持续把请求打到已“半瘫痪”的后端节点上，加剧雪崩
启用主动健康检查（需 nginx-plus 或开源版搭配模块）
标准开源 Nginx 不自带主动健康检查，但可通过以下方式实现：
- 使用 nginx-plus：内置
health_check指令，支持周期性 GET 请求探测后端状态（例如访问/health接口，该接口应校验 DB 连通性） - 使用开源方案：nginx_upstream_check_module（需编译安装），可配置 TCP 或 HTTP 检查，失败达阈值后自动摘除节点
- 关键点：后端服务的
/health接口必须真实反映 DB 状态（比如执行SELECT 1），不能只检查进程存活
配置被动健康检查与优雅降级
即使无主动探测，Nginx 也能基于请求结果自动识别异常节点：
- 在
upstream块中启用max_fails和fail_timeout，例如：server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
表示连续 3 次失败（超时/5xx/连接拒绝）后，30 秒内不再转发请求至此节点 - 配合
proxy_next_upstream指令，指定哪些响应触发重试（如error timeout http_500 http_502），让失败请求自动流转到其他健康节点 - 注意：
proxy_next_upstream_tries和proxy_next_upstream_timeout控制重试上限，避免无限循环
配合应用层做兜底与可观测性
Nginx 的故障转移只是第一道防线，需与后端协同：
- 后端应用应提供带 DB 状态的健康检查端点，并在 DB 中断时主动返回 503，便于 Nginx 快速识别
- 在 Nginx 日志中记录
$upstream_addr和$upstream_status，结合监控（如 Prometheus + Grafana）实时观察各节点错误率、响应时间突增等信号 - 极端情况下可人工临时
down异常 server（通过 reload 配置），或设置维护页（error_page 503 /maintenance.html）
