ping 能看到 IP，nslookup 也能返回结果，并不代表网站一定可以访问。DNS 只是访问链路的第一步，后面还包括路由、端口、TLS、反向代理、上游服务和安全策略。
一、先明确“打不开”的具体表现
域名解析失败：通常停在 DNS 阶段。
连接超时：常见于路由、安全组、防火墙或端口未监听。
连接被拒绝：目标主机可达，但对应端口没有服务或被主动拒绝。
TLS 握手失败：证书、SNI、协议或加密套件异常。
返回 4xx/5xx：网络链路通常已通，应继续检查网关和应用。
把浏览器里的“无法访问”转换成明确的网络阶段，排查效率会高很多。
二、分层排查
1. DNS 层
dig example.com
dig +trace example.com
getent hosts example.com检查权威解析、TTL、A/AAAA 记录和本机解析结果。尤其注意 IPv6：客户端可能优先访问 AAAA 记录，而服务端并没有配置 IPv6 入口。
2. TCP 层
nc -vz example.com 80
nc -vz example.com 443
curl -v --connect-timeout 5 https://example.com如果 TCP 不通，继续检查云安全组、主机防火墙、负载均衡监听器、NAT 和回程路由。服务器侧使用 ss -lntp 确认服务是否监听在正确地址和端口。
3. TLS 层
openssl s_client -connect example.com:443 -servername example.com确认 SNI、证书域名、有效期和证书链。一个 IP 承载多个站点时，不带正确 SNI 可能得到默认证书或默认证站点。
4. HTTP 与代理层
curl -vkI https://example.com
curl -vk --resolve example.com:443:203.0.113.10 https://example.com/对比通过域名、指定公网 IP、负载均衡 IP 和源站 IP 的结果，就能判断问题位于 CDN、WAF、代理还是应用侧。
三、最容易忽略的问题
本机 hosts 文件或企业 DNS 缓存了旧地址。
A 记录正确，但 AAAA 记录错误。
CDN 回源地址或 Host Header 配置错误。
Nginx
server_name未匹配，流量进入默认虚拟主机。反向代理能访问，但后端健康检查失败。
云防火墙放行了入站，却遗漏回程路径或出口策略。
客户端使用了不可用的系统代理、VPN 或 PAC 规则。
四、推荐排查顺序
按照“DNS → 路由 → TCP → TLS → HTTP → 代理 → 应用”逐层验证，每一步都保留命令结果和时间点。不要一开始就修改 DNS，也不要在没有证据时同时重启多个组件。
故障恢复后，应补充域名解析、TCP 建连、TLS 握手、HTTP 状态码和页面关键字的多层监控。这样下次告警能够直接说明失败发生在哪一层，而不是只告诉你“网站打不开”。