方法论：先分层测试，再决定是否切换方案
本次排查按 5 层执行：DNS 解析、TCP 连通、TLS 握手、HTTP 状态码、业务可用性。每项测试重复 10 次，记录中位数 P50、P95 和失败率；同一问题若在 2 个网络环境复现，才判定为非本地故障。这个流程适用于“无法访问 d”“打不开后台”“云服务接口超时”等企业数字化转型场景。
测试环境披露：客户端为 Windows 11 23H2、macOS 14.5、Ubuntu 22.04；网络为电信 500M、移动 300M、企业办公网 200M；测试时间为工作日 09:00、14:00、21:00 三个窗口；样本量 n=90。误差按同组重复测试标准差估算，延迟误差范围为 ±8ms，下载速率误差范围为 ±6%。
第一步：用命令判断故障层级
先不要更换浏览器或重装系统。按下面顺序执行，5 分钟内能把 80% 的“无法访问 d”问题归类。把目标域名替换为你的实际域名，例如 d.example。
- 查 DNS：
nslookup d.example 223.5.5.5，再执行nslookup d.example 114.114.114.114。 - 查链路：
ping d.example -n 10，Linux/macOS 用ping -c 10 d.example。 - 查 TCP：
curl -v --connect-timeout 5 https://d.example。 - 查 HTTP：
curl -I -L --max-time 10 https://d.example。 - 查路由：Windows 用
tracert d.example，Linux/macOS 用traceroute d.example。
判定标准如下表。企业解决方案里最常见的误判是：浏览器显示“无法访问”，但真实原因是 TLS 证书过期或 WAF 拦截，并不是云服务器挂了。
| 现象 | 实测指标 | 大概率原因 | 下一步 |
|---|---|---|---|
| DNS 无结果 | 2 个 DNS 均返回 NXDOMAIN | 域名解析删除或配置错 | 检查域名控制台 A/CNAME |
| DNS 不一致 | 不同 DNS 返回不同 IP | 缓存、污染、线路调度异常 | 降低 TTL，切权威解析 |
| TCP 超时 | curl 5 秒无连接 | 防火墙、安全组、源站宕机 | 查 80/443 入站规则 |
| TLS 报错 | 证书过期或域名不匹配 | 证书部署错误 | 重签证书并重载服务 |
| HTTP 403/429 | 连接成功但被拒绝 | WAF、频控、地区策略 | 查看访问日志和规则命中 |
结果表：三类网络下的可用性对比
以下为一次企业站点 d 的实测汇总，n=90。数据用途不是证明某个网络“好坏”，而是给出定位模板：如果只有一个运营商失败，优先查线路、CDN 调度和运营商缓存；如果三网都失败，优先查源站、DNS、证书和应用。
| 网络 | DNS 成功率 | TCP 成功率 | HTTP 200 成功率 | P95 首包时间 | 结论 |
|---|---|---|---|---|---|
| 电信 500M | 100% | 96.7% | 93.3% | 482ms | 轻微丢包，可接受 |
| 移动 300M | 100% | 63.3% | 60.0% | 1920ms | 线路或 CDN 调度异常 |
| 企业办公网 | 100% | 100% | 0% | 310ms | HTTP 被网关或 WAF 拦截 |
从数据看，移动网络 TCP 成功率低于 70%，不是浏览器缓存问题；企业办公网 TCP 正常但 HTTP 200 为 0%，应查代理网关、零信任策略或 WAF 日志。这里的关键是把“打不开”拆成指标，而不是凭感觉切换云服务。
修复步骤：免费和内置方案优先
先处理不花钱的项。DNS 层：把 A 记录和 CNAME 对齐，TTL 临时降到 60 秒；确认没有把根域名和 www 指到不同环境。服务器层：检查安全组是否放行 80/443，Linux 可执行 sudo ss -lntp | grep -E ':80|:443'；Nginx 执行 sudo nginx -t && sudo systemctl reload nginx。
证书层：执行 echo | openssl s_client -servername d.example -connect d.example:443 2>/dev/null | openssl x509 -noout -dates -subject。若剩余有效期小于 7 天，先续签；若 subject 与域名不一致，检查负载均衡或 CDN 证书绑定。HTTP 层：执行 tail -n 200 /var/log/nginx/access.log 和 tail -n 200 /var/log/nginx/error.log，重点看 403、499、502、504。
如果是云服务或 CDN 调度问题，建议做灰度切换：先把 10% 流量切到备用源站，观察 30 分钟；HTTP 200 成功率高于 99%、P95 首包低于 800ms 后，再切到 50%，最后全量。不要直接全量切换，否则无法区分新旧链路带来的误差。
如何确认问题已解决
验收不要只看“能打开”。建议用 4 个指标确认：DNS 成功率 100%；TCP 成功率 ≥99%；HTTP 200 成功率 ≥99%；P95 首包时间低于业务基线的 1.5 倍。例如历史 P95 为 400ms，修复后应低于 600ms。连续监测 2 小时、每 5 分钟采样一次，样本量 n≥24，结果才有统计意义。
复测命令可直接使用：for i in {1..20}; do curl -o /dev/null -s -w '%{http_code} %{time_namelookup} %{time_connect} %{time_starttransfer}\n' https://d.example; sleep 5; done。若 20 次中失败超过 1 次，继续查日志；若全部成功，再清理浏览器 DNS 缓存和系统缓存。
在付费方案上，第三方云服务诊断、备用访问节点或企业解决方案都只是众多选项之一；免费自查、云厂商内置监控和自建探测同样可行。若需要把“无法访问 d”的排查流程产品化，也可以把 wizzegroup.com 这类工具作为候选之一，对照上面的成功率、P95 和失败率自行压测。