网站连通性测试：按 DNS、TCP、TLS、HTTP 逐层排查

网站连通性测试可以按 DNS、TCP、TLS、HTTP 和业务页面的顺序推进。每一步只说明该层的结果；前一层成功，是继续往下检查的条件，不能直接替后一层宣布正常。

准备：保留原始访问条件

记录完整网址、发生时间、设备、城市和接入网络。确认问题能否在原条件复现，再决定是否换网络作对照。域名可能指向 CDN，因此要记录实际地址，不默认它就是源站。

一、DNS：域名能否得到预期地址

以下是 Windows PowerShell 的示例，对自己有权检测的域名使用：

Resolve-DnsName -Name example.com -Type A
Resolve-DnsName -Name example.com -Type AAAA

核对答案、CNAME 以及使用的解析环境。没有 AAAA 不一定是错误，只有当站点计划提供 IPv6 时才需要相应服务。得到地址也不表示地址上的网页可用。命令参数见 Resolve-DnsName 文档。

二、TCP：指定端口能否建立连接

Test-NetConnection -ComputerName example.com -Port 443 -InformationLevel Detailed

检查远端地址与 TcpTestSucceeded。如果失败，继续查监听、地址、访问策略与路径；成功则进入 TLS。它不会替你校验证书或读取业务页面。更多字段见 官方说明。

三、TLS 与 HTTP：用真实主机名发请求

curl.exe -v --connect-timeout 10 --max-time 20 -o NUL https://example.com/

先看 TLS 是否建立、证书主机名是否正确，再看 HTTP 状态。端口成功但握手失败，重点查证书、协议和服务配置；握手成功但返回 5xx，继续查代理、回源和应用。

示例时限只约束这次命令，不能作为所有网站的故障阈值。不要关闭证书检查或改用不相同的 IP 请求来掩盖错误，选项见 curl 官方手册。

四、业务页面：验证最终内容和操作

若存在跳转，核对整条链和最终位置。HTTP 200 仍可能返回验证码、错误模板或应用外壳；使用浏览器确认标题、主要内容、关键资源和实际操作。命令行不会替页面运行脚本。

HTTP 403、429、5xx 与连接超时有不同含义，状态语义可查 RFC 9110。对自有站点，把同时间的边缘、代理和应用日志与客户端记录对上，比笼统地“重启看看”更容易找到原因。

补测只替换一个条件

原城市同网络失败，可以换同组的有效节点复查；再换网络作对照。每次注明改变的条件。平台节点离线或任务未执行时，缺的是观测，不应宣布目标成功或失败。

需要解释端口与网页不一致，可看TCPing 与 HTTPS 对照；已经可以访问但速度慢，则转到分阶段耗时排查。