Nginx Master进程不实现心跳检测，而是通过SIGCHLD信号和waitpid()系统调用即时感知Worker状态，属内建的主从式进程监护机制；外部健康检查需借助Keepalived、systemd Watchdog等工具实现。
Nginx 的 Master 进程本身不主动对外发送心跳包，也不实现传统意义上的“进程间心跳检测”。它和 Worker 进程之间是单向监控关系，本质是主从式管理机制，不是对等的心跳通信。
Master 进程通过操作系统信号（如 SIGCHLD）和定期轮询（waitpid() 类系统调用）来感知 Worker 进程状态，属于轻量级、内建的进程生命周期管理，而非网络或定时 HTTP/TCP 心跳。
Master 与 Worker 的状态感知方式
- Master 启动后 fork 出多个 Worker 进程，并记录其 PID
- Worker 崩溃时会向 Master 发送
SIGCHLD信号 - Master 收到该信号后，立即调用
waitpid()获取退出状态，确认哪个 Worker 异常终止 - Master 根据配置（如
worker_rlimit_core、daemon、master_process on）决定是否拉起新 Worker
这个过程无需额外模块、脚本或网络交互，是 Nginx 自身事件循环的一部分。
为什么不是“心跳检测”？
- ❌ 没有周期性发送/接收“我还活着”消息
- ❌ 不依赖超时、重试、上升/下降计数等典型心跳参数（如
rise=2 fall=5） - ❌ 不暴露
/status接口或支持check_status模块来展示 Worker 状态 - ✅ 是同步、即时、基于系统信号的进程管控，更接近“监护”而非“探测”
举例：若某个 Worker 因段错误崩溃，内核立刻通知 Master；Master 在毫秒级内捕获并重启它——这比任何用户态心跳都更及时可靠。
需要“心跳感”的场景，其实是外部在管 Nginx
真正需要心跳逻辑的，是 外部系统对 Nginx 整体可用性的判断，比如：
- Keepalived 检查本地 Nginx 是否响应
curl -f http://127.0.0.1/health - systemd Watchdog 要求 Nginx 主动调用
sd_notify("WATCHDOG=1")（需配合 patch 或 OpenResty） - 自定义 shell 脚本检查
ps aux | grep nginx | grep -v grep或端口netstat -tlnp | grep :80
这些都不是 Master 进程自己发心跳，而是被监管对象。
补充：Master 进程可被外部“心跳化”的方法
若你确实希望让 Master 具备可探测的健康信号，可通过以下方式间接实现：
- 在 Nginx 配置中启用一个内部 health 接口：
location /health { return 200 "OK\n"; access_log off; log_not_found off; } - 配合 systemd 的
WatchdogSec（需 Nginx 支持sd_notify，通常需使用 OpenResty 或打 watchdog 补丁） - 或由 Keepalived 的
vrrp_script定期访问该接口，失败则降权切换 VIP
但请注意：这是外部赋予的健康语义，不是 Master 进程原生能力。
Nginx 的 Master-Worker 模型设计简洁务实，靠系统机制保活，不画蛇添足加心跳。真要高可靠，重点应放在它之上一层（Keepalived/VIP）或之下一层（Worker 健康检查 upstream）。
