网站打不开或请求失败#

验证：未记录

适用版本: 未记录
验证范围: 尚未登记验证记录。

链路：客户端 → DNS（Domain Name System，域名系统）→ 网络连接 → TLS（Transport Layer Security，传输层安全）→ 入口代理 → 后端。先确定失败阶段，再改配置。

1. 从发生故障的客户端检查#

需要 dig、curl。替换成实际域名和允许匿名读取的健康路径；不携带业务凭证。

export SITE_HOST='api.staging.example.com'
export SITE_PATH='/health/ready'
date -u '+%Y-%m-%dT%H:%M:%SZ'
dig "$SITE_HOST" A
dig "$SITE_HOST" AAAA
curl -sS --connect-timeout 3 --max-time 15 -o /dev/null -w 'status=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' "https://$SITE_HOST$SITE_PATH"
SITE_RC=$?
printf 'curl_exit=%s\n' "$SITE_RC"

计时字段是从请求开始累计的时间；不要把 first 直接当应用处理时长。未使用 --fail 时，HTTP 500 也可能退出 0。

结果	判断	下一步
DNS `NXDOMAIN`	当前解析链认为域名不存在	核对域名、委派、公共/私有区域；Route 53、Cloud DNS
DNS `SERVFAIL` 或解析超时	解析服务、委派或校验故障	比较同网段正常主机的解析器；不要把私有域名交给公网解析器判断
curl 6	名称解析失败	核对应用实际解析器；`dig` 与应用可能使用不同的解析路径
curl 7 / 28	连接失败 / 超时	看失败阶段，检查监听、路由、出入站规则和回程；路由排障
curl 35 / 60	TLS 协商 / 证书验证失败	核对证书域名、有效期、完整链、客户端时间与信任库；TLS
301/302 循环	重定向或会话配置问题	浏览器检查每跳 Location、协议和 Cookie；会话
401/403	身份或访问策略拒绝	通过请求标识定位代理、防火墙或应用的拒绝记录；不要直接放开权限
502/503/504	已得到某层 HTTP 响应	进入第 3 步，确认响应来自入口还是后端

2. 只部分用户失败#

仅当域名同时配置两种地址时比较：

curl -4 -sS --connect-timeout 3 --max-time 15 -o /dev/null -w 'ipv4=%{http_code}\n' "https://$SITE_HOST$SITE_PATH"
curl -6 -sS --connect-timeout 3 --max-time 15 -o /dev/null -w 'ipv6=%{http_code}\n' "https://$SITE_HOST$SITE_PATH"

只一种失败时，检查该地址族的入口、路由和规则。要区分解析与连接，可把当前合法入口的 IPv4 地址代入：

export ENTRY_IP='REPLACE_CURRENT_ENTRY_IPV4'
curl --resolve "$SITE_HOST:443:$ENTRY_IP" -sS --connect-timeout 3 --max-time 15 -o /dev/null -w 'resolved_status=%{http_code}\n' "https://$SITE_HOST$SITE_PATH"

它保留域名和证书校验，仅覆盖本次解析；不加 -k。若环境强制使用代理，连接及解析可能由代理处理，先核对代理路径。不要绕过访问控制直接访问源站。

3. 入口与后端分界#

AWS ALB（Application Load Balancer，应用负载均衡器）：在正确账号/区域读取目标健康，变量填实际目标组 ARN（Amazon Resource Name，资源标识符）。

export AWS_REGION='REPLACE_REGION'
export TARGET_GROUP_ARN='REPLACE_TARGET_GROUP_ARN'
aws sts get-caller-identity
aws elbv2 describe-target-health --region "$AWS_REGION" --target-group-arn "$TARGET_GROUP_ARN" --query 'TargetHealthDescriptions[].{Target:Target.Id,Port:Target.Port,State:TargetHealth.State,Reason:TargetHealth.Reason}' --output table

对齐同一请求的 elb_status_code、target_status_code 与目标地址，结合 ALB 日志与监控。目标不健康继续检查探针路径、端口、规则与应用依赖；全部不健康时 ALB 可能仍把请求发给不健康目标，不能推断“必定不转发”。官方健康检查说明。

GCP 从负载均衡和 Cloud Logging 检查对应后端健康与请求日志；Kubernetes 后端进入 Pod 检查。

浏览器失败但 curl 成功：在开发者工具 Network 中检查预检 OPTIONS、实际请求、重定向和响应头，见浏览器跨域过程。curl 不执行浏览器跨域策略。

4. 恢复验收#

从原故障客户端重测实际业务路径，比较故障地域和正常地域；确认入口与应用错误率、延迟均恢复。健康端点 200 只是一项证据，不能代替业务验证。