nginx 无法直接熔断数据库故障，因其不感知数据库状态，仅能基于上游应用返回的http状态码和超时响应做反向代理层面的故障转移；真正的熔断需由应用层实现数据库超时、降级与健康检查联动。
直接测试 Nginx 的“故障转移”在数据库锁表或卡死场景下的熔断表现，需要明确一个关键前提：Nginx 本身不连接数据库，也不感知数据库状态。它只负责反向代理 HTTP 请求到上游（比如应用服务器），而真正的数据库操作、锁表、超时、熔断逻辑，必须由后端应用层（如 Java/Go/Python 服务）实现和控制。
为什么 Nginx 无法直接熔断数据库故障
Nginx 的 upstream 机制能做的是：检测下游服务进程是否响应 TCP 连接、HTTP 响应是否及时返回、状态码是否异常（如 502/503/504）。但它看不到应用内部是否在等 MySQL 表锁、是否卡在慢查询、是否线程池耗尽。这些属于应用运行时行为，Nginx 无从知晓。
所以所谓“测试 Nginx 在数据库卡死时的熔断”，实质是测试：
– 应用服务在数据库异常时能否快速失败并返回可识别错误（如 500/503）；
– Nginx 是否配置了合理的超时与重试策略，能在应用僵死时及时切断并切换节点；
– 整个链路是否形成有效兜底（即：应用熔断 → Nginx 转发失败 → 触发备用 upstream 或降级）。
构建可验证的测试环境
你需要三类组件协同工作：
-
应用服务（至少两个实例）：部署相同业务代码，接入同一数据库；开启健康检查接口（如
/health）；在关键 API（如/api/order）中模拟数据库锁表现（例如执行SELECT * FROM t_order WHERE id=1 FOR UPDATE后故意 sleep 30s）。 -
MySQL 实例：手动加表级锁（
LOCK TABLES t_order WRITE）或行锁阻塞（用事务 hold 住锁），观察应用请求是否 hang 住。 -
Nginx 配置重点项：
-
proxy_connect_timeout 3s;—— 连不上应用就快速失败 -
proxy_send_timeout 5s;和proxy_read_timeout 5s;—— 防止卡在发请求或等响应 -
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;—— 允许在这些情况下尝试下一个 upstream -
proxy_next_upstream_tries 2;和proxy_next_upstream_timeout 8s;—— 控制重试上限 - 启用
health_check（需 stream 模块或 Plus 版本），或用开源方案（如 nginx-upsync-module + Consul）做主动探活
-
实操验证步骤
按顺序执行，逐层确认行为：
-
第一步：确认单点故障时 Nginx 是否甩开坏节点
停掉一台应用服务，持续 curl 接口，看 Nginx 是否自动将流量全打到另一台——这验证基础 failover。 -
第二步：制造应用“假死”（非进程退出，但不响应）
让某台应用在处理请求时卡在数据库锁上（sleep 30s），同时保持进程存活、健康接口仍返回 200。此时发起请求，观察：- 是否在
proxy_read_timeout时间内返回 504？ - 是否触发
proxy_next_upstream，把该请求转给另一台健康实例？（注意：默认是 per-request 重试，不是长连接切换）
- 是否在
-
第三步：验证健康检查能否剔除“半死”节点
如果用了主动健康检查（如 interval=3s, fails=2），当应用因锁表导致 /health 延迟 > check timeout，Nginx 应在数秒内将其标记为unhealthy，后续新请求不再转发过去。
真正有效的熔断要靠应用层配合
仅靠 Nginx 不足以应对数据库卡死。必须在应用中做：
- 数据库访问设置合理 query timeout（如 MyBatis 的
defaultStatementTimeout） - 使用 Hystrix/Sentinel/Resilience4j 等框架，在 DAO 层超时后主动熔断、降级（如返回缓存或空数据）
- 暴露准确的健康状态：/health 接口应检查 DB 连接 + 执行一条轻量 SQL（如
SELECT 1），任一失败就返回 503 - 避免“健康检查通、业务请求挂”的割裂现象
这样，Nginx 才能基于真实健康信号做决策，而不是靠猜测或固定超时硬扛。
