Nginx全链路HTTPS健康检查的关键是在TLS安全前提下确保探测真实反映后端可用性：需暴露HTTP健康端点（如/healthz），启用nginx_upstream_check_module主动探测，并严格配置proxy_ssl_verify、proxy_ssl_trusted_certificate等参数实现可信TLS转发与自动容错。
要让 Nginx 在全链路 HTTPS 架构下可靠地做后端健康检查，关键不是“加密检查”，而是**在保证 TLS 安全的前提下，让健康探测能真实反映后端服务可用性**。Nginx 开源版不支持直接对 HTTPS 接口发起带证书校验的主动 HTTP 健康检查，但可通过组合被动机制、合理暴露健康端点和严格 SSL 代理配置，实现高可用与强安全兼顾的效果。
用 HTTP 健康端点支撑 HTTPS 后端探测
后端服务需提供一个可被 Nginx 主动访问的轻量级健康接口（如 /healthz），并确保它能在 HTTPS 端口上响应明文 HTTP 请求（即支持“HTTPS 端口跑 HTTP 探针”），或更推荐——单独监听一个受信任内网的 HTTP 健康端口（如 :8080/healthz）。
- 若复用 HTTPS 端口：后端需兼容非 TLS 的 HTTP 请求（例如 Spring Boot 的
server.http.port或反向代理前置处理） - 若使用独立 HTTP 健康端口：更安全可控，避免探针干扰主业务 TLS 握手，也绕过证书校验复杂度
- 返回必须是 2xx 状态码，且响应体尽量精简（避免大 payload 影响探测效率）
启用主动检查模块（推荐 nginx_upstream_check_module）
仅靠默认被动检查（max_fails/fail_timeout）无法提前发现隐患，必须引入主动探测能力。社区广泛验证的 nginx_upstream_check_module 是开源环境下的首选方案，需重新编译 Nginx 加入该模块。
- 配置示例中
check interval=3 rise=2 fall=5 timeout=1 type=http表示每 3 秒发一次探针，连续 2 次成功标记为健康，连续 5 次失败标记为异常 -
check_http_send "GET /healthz HTTP/1.0\r\n\r\n"发送标准 HTTP 请求，不依赖 Host 头或复杂头字段 - 务必搭配
check_http_expect_alive http_2xx，避免误判重定向或客户端错误
严格配置 proxy_ssl_* 实现全链路 TLS 可信转发
健康检查走 HTTP 不代表业务流量可以降级。所有真实请求仍需完整 TLS 加密，并启用证书校验，否则等于裸奔。
-
proxy_ssl_verify on必须开启，禁用该选项会跳过证书验证，失去 HTTPS 本质意义 -
proxy_ssl_trusted_certificate /etc/nginx/certs/backend-ca.crt指向后端服务所用 CA 的根证书（自签或私有 CA 必须显式配置） -
proxy_ssl_name "api.example.com"设置 SNI 主机名，确保后端证书中的Subject Alternative Name匹配 -
proxy_ssl_protocols TLSv1.2 TLSv1.3和proxy_ssl_ciphers限制协议与密钥套件，符合等保或行业合规要求
结合 proxy_next_upstream 实现请求级自动容错
即使健康检查正常，运行时仍可能出现连接中断、超时或上游返回错误。这部分靠 Nginx 的请求重试机制兜底，与健康检查形成双保险。
-
proxy_next_upstream error timeout http_502 http_503 http_504覆盖常见故障场景，触发失败转移 -
proxy_next_upstream_tries 3限制最多重试次数，防止单个请求过度消耗资源 -
proxy_next_upstream_timeout 10s控制整体重试窗口，避免长尾延迟累积
