网站能打开，负载均衡健康检查却失败？路径、Host 与状态码排查

网站首页正常打开，控制台里的后端却显示“不健康”，可以先比较两次请求的目的地址、端口、协议、路径和 Host。浏览器可能经过 CDN、登录状态和负载均衡转发；健康探测有自己的请求设置，访问的后端和页面也可能不同。

下面以 Linux、Nginx 和 HTTP/HTTPS 应用负载均衡为例。命令里的地址、域名和端口都是示例，请换成实际后端配置。AWS ALB 的行为引用官方文档，其他产品需要核对对应说明。

先记下控制台显示的失败原因

在修改服务器前，记录故障后端的 IP、业务端口、探测端口、协议、路径、成功状态码范围、超时和健康阈值。业务转发端口与探测端口应分别确认。

AWS ALB 的目标健康详情可以区分状态码不匹配、请求超时和一般探测失败。全部目标不健康时，ALB 在特定条件下还会向这些目标继续转发请求，因此“网站仍能访问”无法独立证明探测正常。[1]

这张表用来决定下一步检查位置。同一个状态码可能有不同原因，例如 403 可以来自 Nginx，也可以来自应用鉴权。

用 GET 请求复现探测条件

在具有后端访问权限的机器上测试。以下示例假定探测使用 HTTP、8080 端口和 /healthz 路径。

curl --noproxy '*' --connect-timeout 2 --max-time 5 \
  -sS -D - -o /dev/null \
  -w '\ncode=%{http_code} connect=%{time_connect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
  http://10.0.0.12:8080/healthz

这里用 GET 请求，并保留响应头；--noproxy '*' 避免命令经过本机代理。示例中的 2 秒和 5 秒只用于诊断，实际复现时应对齐平台的超时设置。curl 的连接耗时、首字节耗时和总耗时也不能直接当作平台探测计时。[5]

首次测试保留跳转响应，不加 -L，方便看到失败发生在哪一步。curl -I 发送的是 HEAD，也不适合直接替代 GET 探测。[5]

再对同一地址添加业务域名，比较响应是否变化：

curl --noproxy '*' --connect-timeout 2 --max-time 5 \
  -sS -D - -o /dev/null \
  -H 'Host: www.example.com' \
  http://10.0.0.12:8080/healthz

如果第一条返回 404，第二条返回 200，优先检查虚拟主机匹配。仍应查看响应内容或日志，确认 200 来自预期服务，避免把默认欢迎页当作健康响应。

Host 不同，Nginx 可能选中另一份站点配置

Nginx 会根据监听地址、端口和 Host 选择请求对应的 server。找不到匹配名称时，请求可能进入该监听端口的默认站点；默认站点属于监听端口的属性。[3]

AWS ALB 的健康检查 Host 使用目标私有 IP；非默认端口还会带端口。例如后端私有 IP 为 10.0.0.12、探测端口为 8080 时，Host 可以是 10.0.0.12:8080。不能假定探测一定携带浏览器访问的业务域名。[2]

遇到 Host 不匹配，可按实际产品能力处理：支持配置探测 Host 时填写预期域名；不支持时，调整后端对探测请求的处理方式。修改前查证产品文档与实际探测请求。

配置前先查看完整生效配置，确认 /healthz 应该落在哪个 server：

sudo nginx -T

输出可能包含内部域名和路径，排障时在本机查看即可。不要把整份配置公开粘贴到评论区。

给探测路径安排明确的处理规则

如果健康检查只需确认 Nginx 正常响应，可以在实际接收探测请求的现有 server 块里加入独立路径：

# 放在已确认会接收探测请求的 server { ... } 内
location = /healthz {
    default_type text/plain;
    return 200 "ok\n";
}

该配置只能证明对应的 Nginx 请求链路能够响应。应用进程、数据库或业务依赖是否可用，需要由应用提供就绪检查；应用未准备好时，应让该接口按约定返回失败状态。不要用固定 200 掩盖应用故障。

若当前 server 层直接写了 HTTP 跳转 HTTPS 的 return 301，仅添加上面的 location 可能仍无法排除跳转。Nginx 的 server 级 rewrite 指令会先执行，需要检查跳转规则所在层级。[4] 对于已确认接收探测的 HTTP 站点，可以评估把跳转移到业务路径：

# 示例片段：替换现有跳转布局前，先备份并检查完整配置
location = /healthz {
    default_type text/plain;
    return 200 "ok\n";
}

location / {
    return 301 https://www.example.com$request_uri;
}

示例中的域名需替换为实际域名。它适用于专门承担 HTTP 跳转的站点，已有反向代理、ACME 验证或其他 location 时，要保留相应处理逻辑。不要为了套用片段直接覆盖整个站点文件。

修改前备份将要编辑的文件，随后检查并平滑加载：

# 将 /etc/nginx/conf.d/site.conf 替换为实际站点配置文件
sudo cp -a /etc/nginx/conf.d/site.conf "/etc/nginx/conf.d/site.conf.bak.$(date +%Y%m%d-%H%M%S)"
sudo nginx -t && sudo systemctl reload nginx

最后一行适用于使用 systemd 管理 Nginx 的主机。若加载后出现异常，恢复刚才备份的文件，再执行配置检查与 reload。

对齐成功状态码，检查 HTTPS 的名称信息

健康检查对“成功”的定义由具体产品决定。AWS ALB 的 HTTP 检查可以配置 Matcher，默认成功码为 200。[1] 不要把某个平台支持的状态码范围直接套用到另一个平台。

若响应是登录页跳转、404 或应用错误，先修复路径和访问条件。把这些响应全部纳入成功范围，会削弱健康检查筛除故障后端的作用。

HTTPS 排障还要区分 HTTP Host 和 TLS 握手中的名称信息。下面的命令保留域名作为 URL 主机名，同时把连接指向指定后端 IP，适合验证该域名对应的 TLS 与站点处理：[5]

curl --noproxy '*' \
  --resolve www.example.com:443:10.0.0.12 \
  --connect-timeout 2 --max-time 5 \
  -sS -D - -o /dev/null \
  https://www.example.com/healthz

这条命令验证的是“指定域名连接到该后端”的情况。平台是否携带相同 SNI、是否校验证书，需要另外查证，不能仅凭这条命令成功就排除探测握手差异。

本机测试成功后，继续检查探测来源网络

在后端主机上查看监听状态：

sudo ss -lntp

核对进程监听的地址与探测端口。只监听 127.0.0.1 的服务无法直接接收发往后端网卡地址的连接；服务器上的 curl 成功，也只覆盖了当次请求走过的网络路径。

结合所用产品的探测来源要求，检查安全组、网络 ACL、系统防火墙与访问控制。AWS ALB 的文档列出了相关安全组和网络 ACL 检查项，应核对实际链路；不要通过向整个互联网开放后端端口来代替排查。[2]

同时观察实际站点的访问日志和错误日志。常见路径可按安装方式调整：

sudo tail -n 100 /var/log/nginx/access.log
sudo tail -n 100 /var/log/nginx/error.log

日志里有探测请求时，对照来源、时间、Host、路径、状态码和处理耗时。若没有记录，先确认是否查看了正确虚拟主机的日志，以及该路径是否关闭日志，再判断请求是否到达服务器。需要记录 $http_host 等字段时，可临时增加诊断日志，完成后恢复原设置。

修改后分别验收探测和业务请求

每次只修改已经定位的一项，再重发相同测试请求。验收可以按以下顺序进行：

1. 用接近平台条件的请求确认响应状态、内容和耗时。
2. 等待控制台按实际阈值完成状态更新；AWS ALB 初次注册与恢复健康的判定条件也有区别。[1]
3. 逐个确认目标状态，并从访客入口检查首页、登录和实际业务接口。
4. 记录最终探测参数、修改文件和回滚位置，便于之后迁移或扩容时复用。

如果控制台仍报错，把失败原因与同一时间的请求日志放在一起看。Host 不一致就修正匹配关系，端口不通就检查网络与监听，应用响应慢就处理应用耗时。延长超时或放宽成功码，应建立在已经理解失败原因的基础上。

官方参考资料

资料核验日期：2026 年 10 月 15 日。文中的命令和配置用于说明排查方法，未在读者生产环境执行。

[1] AWS：Health checks for Application Load Balancer target groups
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html

[2] AWS：Troubleshoot your Application Load Balancers
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html

[3] Nginx：How nginx processes a request
https://nginx.org/en/docs/http/request_processing.html

[4] Nginx：ngx_http_rewrite_module
https://nginx.org/en/docs/http/ngx_http_rewrite_module.html

[5] curl：Command line tool manual
https://curl.se/docs/manpage.html