网站打不开时，不要一开始就反复刷新或直接修改服务器配置。更有效的顺序是：先确认故障范围，再根据错误提示区分浏览器、网络、DNS、证书、服务器或网站程序问题，最后用多个入口验证是否恢复。记录访问时间、完整网址、浏览器提示和错误代码，能够避免在排查过程中丢失线索。

第一步：先判断是单点故障还是普遍故障

先用当前设备访问其他正常网站，再让另一台设备或另一条网络访问同一网址。例如，手机关闭无线网络后使用移动网络测试，或者请不同地区的用户尝试访问。这个动作的目的不是立即解决问题，而是确定故障发生在哪一层。

• 只有一台设备打不开：优先检查浏览器缓存、扩展程序、本机代理、系统时间和本地网络。
• 同一网络下多台设备都打不开：重点检查路由器、网络出口、DNS解析和防火墙策略。
• 不同网络都打不开：服务器、域名、HTTPS证书、CDN或网站程序故障的可能性较高。
• 只有部分页面打不开：首页可能正常，但路由、接口、数据库或某个资源服务存在问题。
• 只有部分地区打不开：应重点查看DNS解析、CDN节点、区域访问策略和网络链路。

如果网站承担交易、登录或业务提交功能，先保留错误页面和日志时间，再进行修改。这样可以把故障发生时间与服务器访问日志、部署记录对应起来。

第二步：根据错误提示确定排查方向

浏览器显示的提示通常比“打不开”更有价值。不要只记录页面是否空白，还要区分是无法建立连接、域名无法解析、证书不受信任，还是服务器返回了错误状态。

第三步：排除浏览器和本机因素

如果只有当前设备访问失败，先在无痕窗口或另一款浏览器中打开网站。无痕模式可以减少缓存、Cookie和部分扩展程序的影响；如果无痕窗口能够打开，通常需要检查浏览器缓存、登录会话或扩展程序，而不是立即改动服务器。

随后检查浏览器是否设置了代理，安全软件或公司网络是否拦截了该域名。确认系统日期、时间和时区准确，因为时间错误会导致HTTPS证书被判断为尚未生效或已经过期。若近期修改过hosts文件，也要确认域名没有被指向错误的地址。

清理缓存适合处理旧页面、旧脚本或错误Cookie造成的异常，但它不能修复服务器宕机、DNS失效和证书过期。清理前应先保存错误提示，避免刷新后无法复现问题。

第四步：检查网络与DNS是否把域名指向正确位置

更换网络测试后，如果故障随网络变化，先检查本地DNS和网络出口。可以使用系统的域名查询工具查看域名是否能解析，以及返回的记录是否与当前服务器或CDN配置一致。出现解析失败、返回旧地址或不同网络解析结果差异很大时，应从域名管理、权威DNS和缓存更新情况入手。

同时确认域名没有到期、被暂停或处于异常状态。近期更换过服务器、CDN、DNS服务商或解析记录时，部分网络仍可能暂时使用旧缓存。在这种情况下，不要频繁来回修改记录，否则会让各地解析结果更难判断。应先确认最终配置，再等待缓存按其有效时间更新。

如果解析正常但仍然打不开，问题就不一定在DNS。还要确认解析得到的目标主机确实提供该网站，并检查服务器是否允许来自外部网络的80端口和443端口连接。

第五步：检查服务器、HTTPS和反向代理

确认服务器在线后，依次检查Web服务进程、监听端口、反向代理和防火墙。网站可能并非整台服务器宕机，而是Nginx、Apache、网关或容器中的某个服务停止，导致浏览器出现连接拒绝、502或超时。

如果问题集中在HTTPS，检查证书是否仍在有效期内，证书覆盖的域名是否包含当前访问的主域名和子域名，中间证书是否完整，以及HTTP到HTTPS的跳转是否形成循环。证书更新后，也要确认实际提供给浏览器的已经是新证书，而不是代理层或旧节点上的旧配置。

若使用CDN、负载均衡或WAF，应分别测试访问入口和源站状态。源站正常但外部访问失败，可能是CDN节点、回源配置、健康检查或WAF规则导致；源站本身也失败时，应优先修复源站，不要只反复刷新缓存。

第六步：检查近期发布、配置和依赖服务

如果网站是在发布代码、修改配置、迁移服务器或更新证书后开始打不开，应先对照变更时间检查最近一次改动。重点查看域名配置、环境变量、数据库连接、缓存服务、文件权限、路由规则和静态资源路径。应用本身可能能启动，但只要数据库或接口连接失败，首页就可能返回500或网关错误。

查看应用日志、Web服务器日志和系统资源使用情况。CPU、内存、磁盘空间耗尽，连接数达到上限，数据库连接池耗尽，都会表现为访问缓慢、超时或间歇性打不开。若确定故障由最近一次发布造成，且已有经过验证的旧版本，可以按既定流程回滚，再继续定位具体变更。

不要为了验证问题而同时修改代码、DNS、证书和防火墙。一次只调整一个相关项，并记录调整前后的结果，才能知道哪个动作真正改变了故障状态。

什么状态才算真正恢复

浏览器偶尔打开一次，不代表网站已经恢复。恢复判断应覆盖故障范围，而不只是当前设备的首页。至少应完成以下检查：

• 使用原来的网址访问，域名解析结果稳定，没有间歇性解析失败。
• 通过至少两条不同网络访问，首页能够持续返回预期内容。
• HTTP和HTTPS跳转符合预期，证书有效且没有安全警告。
• 登录、表单提交、关键接口或核心业务流程能够正常完成。
• 页面引用的脚本、样式、图片和接口没有大量返回404、403或5xx。
• 服务器、代理、应用和数据库日志中不再持续出现对应错误。

如果只恢复了首页，但登录、支付、后台或接口仍然失败，应将其视为部分恢复，并继续按对应状态码排查。若多地访问仍不稳定，先保留监控结果和日志，确认是单个节点、区域网络还是源站容量问题。

排查后仍打不开时应保留哪些信息

需要交由服务器、域名或网络服务提供方处理时，应一次性提供完整网址、首次发生时间、访问网络和地区、浏览器错误提示、HTTP状态码、DNS查询结果，以及是否在近期做过发布、迁移或证书变更。若能提供不同网络下的对比结果，通常比单独描述“网站打不开”更容易定位。

整体顺序可以概括为：先确认影响范围，再看错误提示；先排除本机和网络，再检查DNS、服务器入口、应用及其依赖；恢复后使用多网络和核心功能复核。按照这个顺序处理，既能缩小故障范围，也能避免在原因未明时反复修改配置。