防火墙拦截健康检查探针是Nginx误判后端“假死”的主因，需通过分层定位拦截点、调整探测参数、改用TCP检查、后端暴露专用轻量健康端点等方式对齐防火墙策略。
防火墙拦截健康检查探针是导致 Nginx 误判后端“假死”的常见原因，尤其在启用主动健康检查时。关键不是绕过防火墙，而是让健康检查行为与防火墙策略对齐，避免被丢包、限速或连接重置干扰判断。
确认防火墙实际拦截点
先明确是哪一层被拦：
- 网络层（iptables/nftables）可能 DROP 或 REJECT 健康检查的 TCP 连接请求，表现为连接超时或拒绝
- 传输层（如 TCP SYN 包被限速）会导致 probe 延迟升高，触发 fail_timeout 误判
- 应用层（WAF 或安全组）可能拦截特定路径（如
/health）、User-Agent 或 HTTP 头，返回 403/404 而非真实状态
调整健康检查参数适配防火墙策略
若无法修改防火墙规则，可通过降低探测敏感度来规避误判：
- 增大 interval（如设为 30s），减少单位时间探针数量，避开速率限制
- 提高 fails 阈值（如从 2 改为 5），容忍偶发丢包或延迟抖动
- 降低 passes 要求（如设为 1），加快恢复速度，避免节点长期离线
- 避免使用过于激进的 rise/fall 参数组合，防止震荡
改用防火墙友好的检查方式
优先选择低开销、易放行的探测机制：
- 用 TCP 端口连通性检查（如
check type=tcp）替代 HTTP 请求，不依赖路径和头，更易通过安全组白名单 - 若必须用 HTTP，统一使用简单路径（如
/ping）和标准头（禁用自定义User-Agent），避免被 WAF 规则识别为异常流量 - 对 Java 应用等 GC 易引发响应延迟的服务，禁用
http_503等状态码触发重试，只保留error timeout，防止将短暂 GC 停顿误判为故障
配合后端暴露专用健康端点
让后端主动配合，提升检查可靠性：
- 在应用侧单独暴露一个轻量健康接口（如
/actuator/health或自定义/ready），该接口不走业务逻辑链路，不受 GC 或数据库连接池影响 - 确保该端点监听在与业务端口相同的 IP 上，并在防火墙中显式放行该端口+路径组合
- 配置 Nginx 的
health_check指向该专用路径，并设置合理超时（match块校验 HTTP 状态码和 body 关键字，增强准确性）
