网站打不开不是一个单一故障类型。应先确认 DNS 是否返回预期地址，再区分 TCP/TLS 连接失败、HTTP 状态错误、过多重定向和应用返回异常；每一步都有不同证据和修复责任人。

先记录现象而不是直接改配置

记录完整 URL、访问时间、浏览器错误、是否只有某个网络失败、根域与 www 是否一致，以及是否经过 CDN。‘打不开’可能对应 NXDOMAIN、连接超时、证书警告、403、5xx 或页面加载后接口失败。

先保存现象和原始结果，再进行配置修改。否则修复后无法判断究竟是哪一层发生变化。

  • 完整 URL 和协议
  • 失败时间与网络环境
  • 浏览器或客户端错误文本
  • 根域、www、IPv4/IPv6 是否都受影响

按四层证据逐步缩小范围

第一层是 DNS：确认 A、AAAA 或 CNAME 是否有结果且指向预期。第二层是连接与 TLS：确认标准端口能建立 HTTPS，证书域名和信任链正常。第三层是 HTTP：查看状态码、重定向、最终 URL 和响应头。第四层是应用：如果 HTTP 返回 2xx，仍需检查页面脚本、接口、鉴权和业务日志。

综合诊断可以快速给出模块结果，但每层异常应回到对应单项工具和服务器日志核对。

  • DNS 地址结果
  • TLS 握手和证书链
  • HTTP 状态与跳转
  • 页面和应用自身响应

用结果组合判断下一步

没有 A/AAAA 时，优先查域名和 DNS；有地址但 HTTP 与 SSL 都失败时，检查端口、防火墙、监听和 CDN；SSL 失败而 HTTP 有响应时，检查 HTTPS 终止层和证书；HTTP 返回 4xx/5xx 时，转向 WAF、鉴权、反代和应用日志。

不要因为某一层正常就跳过其他层。例如 DNS 正常不代表端口开放，证书有效也不代表应用返回 200。

  • 无地址 → DNS/委派
  • 有地址无连接 → 端口/防火墙
  • TLS 失败 → 证书/终止层
  • HTTP 错误 → 代理/WAF/应用

修复后按原现象回归

修复后使用同一个 URL、相近时间和原网络环境复测，再补充另一个网络环境或 IPv6/IPv4 路径。对跳转问题，记录每一次 location 和最终 URL；对证书问题，记录 SAN、授权状态和链；对 HTTP 问题，保存状态码和关键响应头。

如果综合报告为 partial，不要把未完成模块当成正常。应先重试失败模块，再确认完整报告和单项结果是否一致。

  • 复用原始 URL 和环境
  • 保留修复前后证据
  • 验证根域和 www
  • 确认 partial 模块已补测

立即处理

使用相关工具

Website Site Check输入域名或首页地址，汇总检查 DNS、IP、HTTP/HTTPS、重定向、SSL 证书、安全响应头和邮件记录，并按证据给出分级建议。DNS 查询查询 A、AAAA、CNAME、MX、TXT、NS 和 SOA 等常见 DNS 记录。HTTP Headers 查看器检测公开网页的状态码、最终 URL、重定向、响应时间和分类响应头，并检查常见安全响应头。SSL Certificate Checker检测公开网站 SSL 证书的颁发者、有效期、剩余天数、域名匹配、信任状态和证书链信息。域名查询免费域名查询工具，可解析域名的 IPv4、IPv6 与 CNAME 记录，并展示相关 IP 的归属地和运营商参考信息。适合检查 DNS 是否生效、域名是否指向预期服务器，以及排查更换主机、CDN 或解析配置后出现的网站访问问题。

常见问题

关于这个问题

DNS 正常但网站仍打不开，下一步查什么？

继续查 HTTP/HTTPS 连接、标准端口、SSL 证书、重定向、CDN/反向代理和应用响应；DNS 只证明名称解析有结果。

HTTP 返回 200 就代表网站完全正常吗？

不代表。还要检查页面内容、脚本、接口、登录状态和业务日志；200 只说明本次请求得到了成功响应。