前言
通过本文，简单了解原生模块和健康检查模块的优缺点
然后，希望让我劝你选择健康检查模块
Nginx健康检查模块安装
安装教程请绕道此处：Nginx使用upstream_check_module模块实现后端节点健康检查功能
另外，我的模块正确安装检验方式是：有nginx转发两台服务器，当其中一台服务器挂掉的情况下，nginx可以把情况都转发给健康的服务器。
注意：nginx.conf配置里需要加上proxy_next_upstream off;，这样可以防止nginx自主错误转发（理由请点击这里），引起“假验证成功”！
原生模块与健康检查模块运行机制分析
ngx_http_upstream_module
健康检查方式
被动检查，通过统计最大容忍错误次数，标记该后端服务器不可用
举例
upstream name {
server 192.168.57.110:8080 max_fails=1 fail_timeout=10s;
server 192.168.57.101:8080 max_fails=1 fail_timeout=10s;
}
说明
server 192.168.57.110:8080 max_fails=1 fail_timeout=10s;该后端服务器最大错误1次，错误超时时间为10s。
通过指令proxy_next_upstream、fastcgi_next_upstream和 memcached_next_upstream来配置，可以使得，我们遇到不健康模块时，转发到下一台服务器。
这种情况Nginx无法主动识别后端节点状态，后端即使有不健康节点， 负载均衡器依然会先把该请求转发给该不健康节点，然后再转发给别的节点，这样就会浪费一次转发，而且自带模块无法做到预警。So 此时使用第三方模块 nginx_upstream_check_module模块
upstream_check_module
健康检查方式
主动探测，按设置的心跳时间，主动发起心跳。通过统计最大容忍错误次数，剔除该后端服务器
举例
upstream name {
server 192.168.57.207:8090;
server 192.168.57.85:80;
check interval=3000 rise=2 fall=5 timeout=1000 type=http;
}
参考
模块开发文档：戳我进
总结
我们知道，如果我们使用原生检查方式，遇到错误，不会隔离服务器，而是错误请求转发到健康机器上，而使用主动的健康检查模块，我们可以轻松剔除异常服务器，完全隔离掉风险的发生！