Nginx开源版无内置健康检查状态机，依赖第三方模块（如nginx_upstream_check_module）实现；其状态机隐式存在于check_peer_t的state字段、共享内存check_shm_t及定时器回调中，通过ngx_http_upstream_check_heartbeat_handler驱动状态迁移，并借助check_lock保证多worker间状态同步。
阅读 Nginx 源码中 upstream 节点健康检查（health check）的状态机，核心是理解 ngx_http_upstream_check_module（第三方模块）或 Nginx 官方商业版的 health_check 指令背后的状态流转逻辑。开源版 Nginx 主线（v1.25+）本身不内置主动健康检查状态机，它依赖第三方模块（如淘宝的 nginx_upstream_check_module）实现。因此，“阅读状态机”实际是指分析该模块中围绕 check_shm_t、check_peer_t 和定时器驱动的事件循环所构建的状态跳转机制。
明确状态机所在位置与关键结构体
在 nginx_upstream_check_module 中，健康检查状态机不是用 switch-case 显式编排的单个函数，而是通过字段 + 回调 + 定时器隐式表达的有限状态机（FSM）。重点关注以下结构：
-
check_peer_t：每个 upstream server 对应一个实例，含state字段（如CHECK_STATE_CHECKING、CHECK_STATE_DOWN、CHECK_STATE_UP），这是状态存储的核心； -
check_shm_t：共享内存块头，管理所有 peer 的状态快照，供 worker 进程读取； -
ngx_event_t check_ev：每个 worker 维护一个检查定时器，周期性触发ngx_http_upstream_check_heartbeat_handler—— 这是状态推进的入口函数。
追踪一次典型状态迁移路径
以“从 DOWN 到 UP”的恢复过程为例，阅读源码时可顺以下调用链观察状态变化：
- 定时器到期 → 进入
ngx_http_upstream_check_heartbeat_handler； - 调用
ngx_http_upstream_check_next_peer选中一个待检测 peer； - 若当前
peer->state == CHECK_STATE_DOWN，则尝试发起 HTTP/TCP 探针（构造 request，启动 event loop）； - 探针成功回调
ngx_http_upstream_check_success_handler：将peer->state = CHECK_STATE_UP，更新失败计数为 0，写入共享内存； - 探针失败则进入
ngx_http_upstream_check_fail_handler：增加失败计数，若超阈值（fall），保持或设为CHECK_STATE_DOWN。
注意状态同步与竞态处理
多个 worker 进程不能直接修改同一 peer 的状态，必须通过共享内存 + 原子操作协调。阅读时需关注：
- 所有状态变更（如
peer->state = ...）都发生在持有check_lock临界区中（通过ngx_shmtx_lock）； - worker 仅读取共享内存中的
peer->state来决定是否转发请求（见ngx_http_upstream_check_get_peer）； - 状态更新后调用
ngx_http_upstream_check_notify_worker发送信号，唤醒其他 worker 刷新本地缓存（非强制，靠下次定时器读共享内存）。
调试与验证技巧
光看代码易迷失，建议结合运行时行为辅助理解：
- 开启模块的 debug 日志（
error_log ... debug;并定义NGX_DEBUG_HTTP_UPSTREAM_CHECK）； - 在关键函数（如
_success_handler、_fail_handler）加ngx_log_debug打印 state 和计数； - 用
curl手动停/启 backend，观察/status接口返回的up/down变化节奏，反推状态跳转时机； - 在 gdb 中对
check_ev.handler下断点，单步跟踪一次完整心跳周期。
