网站如遇到打不开怎么排查？先不要急着修改服务器配置，应该先确认故障范围，再根据浏览器提示判断是本地网络、域名解析、HTTPS证书、服务器端口还是网站程序异常。用另一台设备或另一条网络访问同一地址，结合具体报错逐层检查；如果其他网络也无法打开，就应优先检查域名、服务器和网站服务。
网站打不开时，先判断是本地问题还是服务器问题？
第一步是保留完整的故障现象。记录访问的完整域名、出现问题的时间、浏览器提示、HTTP状态码，以及是否只有某个页面打不开。不要只记“打不开”，因为“找不到服务器”和“服务器返回500”对应的处理方向完全不同。
- 检查地址是否正确。确认域名拼写、路径、端口和协议没有写错。分别尝试带有或不带有 www 的地址，并确认网站是否强制使用 https。
- 换浏览器或隐私窗口访问。如果隐私窗口可以打开，可能是缓存、Cookie、浏览器扩展或本地代理造成的。此时清理该站点的缓存和Cookie，再暂时停用扩展进行验证。
- 换设备和网络访问。用手机流量、另一台电脑或其他网络测试。只有当前设备打不开，通常先查本地DNS、代理、防火墙和浏览器；所有设备、所有网络都打不开，则故障更可能在域名或服务器端。
- 测试网站首页和其他页面。只有一个路径返回404，通常是链接、路由或文件路径问题；整个站点都超时或拒绝连接，则应转向网络、端口或服务排查。
例如，手机流量可以打开而公司网络打不开，优先检查公司网络的DNS、代理策略或防火墙；所有网络都显示域名无法解析，则不必反复清理浏览器缓存，应直接检查域名解析记录。
根据报错信息，下一步应该查哪里？
浏览器的错误提示是定位故障的重要线索。先看提示属于哪一类，再执行对应动作，不要在没有证据时同时修改DNS、服务器和程序配置。
| 现象或提示 | 优先检查项目 | 恢复判断 |
|---|---|---|
| 找不到服务器、DNS_PROBE_FINISHED_NXDOMAIN | 域名是否过期，DNS记录、权威DNS和解析线路是否正确 | 多个网络都能解析到正确IP，并能继续建立连接 |
| 连接超时、ERR_CONNECTION_TIMED_OUT | 服务器是否在线，80或443端口是否开放，防火墙和安全组是否拦截 | 浏览器能在合理时间内收到服务器响应 |
| 连接被拒绝、ERR_CONNECTION_REFUSED | Web服务是否运行，监听端口是否正确，反向代理配置是否生效 | 目标端口处于监听状态，访问不再立即被拒绝 |
| 403 Forbidden | 目录权限、访问控制、IP限制、WAF规则和登录状态 | 授权用户能够访问，未授权路径仍保持正确限制 |
| 404 Not Found | URL路径、伪静态规则、路由配置和文件是否存在 | 目标页面返回正确内容，而不是仅打开首页 |
| 500、502、503 | 应用日志、PHP或其他运行环境、上游服务、数据库和资源使用率 | 首页、静态资源和关键功能都能正常返回 |
| 证书错误、连接不安全 | 证书是否过期，域名是否覆盖，证书链和服务器时间是否正确 | HTTPS地址显示有效证书，浏览器不再出现安全警告 |
确认范围后，网站打不开应该按什么顺序排查？
第一步：检查本地网络、代理和DNS
如果只有一台设备无法访问，先关闭不必要的VPN、代理和浏览器扩展，确认系统日期与时间正确，再重新连接网络。日期时间错误可能导致HTTPS证书被判断为尚未生效或已经过期。
接着清理本机DNS缓存。Windows可以执行 ipconfig /flushdns，macOS或Linux应使用本机对应的DNS刷新方式。刷新后重新打开浏览器，并通过其他公共网络再次测试。若仍只有当前网络异常，可临时更换可靠DNS进行对照，但不要把更换DNS当成服务器故障的永久修复。
第二步：检查域名解析是否指向正确服务器
如果多个网络都提示找不到服务器，登录域名管理平台检查域名状态、到期时间、DNS服务器和A记录或AAAA记录。确认记录中的IP是当前服务器地址，检查是否误删了主域名、www、邮件等必要记录，也要留意近期迁移、改机房或更换CDN后的解析变更。
解析记录修改后不会在所有网络立即同步。此时可以从不同网络查询解析结果，等待旧缓存自然更新，同时确认新服务器已经允许访问。如果解析已经指向正确IP，但浏览器仍显示超时，就继续检查服务器端口，不要重复修改DNS。
第三步：检查服务器是否在线以及端口是否开放
进入云主机、虚拟主机或托管平台查看运行状态、带宽、CPU、内存、磁盘和安全组规则。磁盘写满、内存耗尽、流量超限或实例被暂停，都可能让网站整体无法打开。
如果服务器在线，继续确认80端口和443端口是否开放，云平台安全组、防火墙、WAF或CDN是否拦截了访问。只有管理人员才应修改这些规则；修改前先记录原配置，避免为了恢复访问而开放不必要的端口。若端口不通，修正规则后从外部网络重新访问，看到服务器返回响应，才说明这一层恢复。
第四步：检查Web服务、反向代理和证书
端口开放但连接被拒绝时，检查Nginx、Apache或其他Web服务是否正在运行，以及配置文件是否存在语法错误。近期部署、改配置或续证书后出现故障，应优先查看变更记录和服务日志。
如果使用反向代理或CDN，还要检查代理到源站的地址、源站端口、回源协议和证书配置。代理能连接源站但源站返回异常，常见表现是502或503；源站服务正常而代理配置错误，也可能导致同样的提示。修改配置后先做语法检查，再平滑重载服务，避免直接重启造成更长时间中断。
第五步：检查程序、数据库和最近变更
出现500、502或503时，优先查看应用日志、Web服务错误日志和数据库连接日志。重点确认程序依赖是否安装、环境变量是否完整、数据库是否可连接、文件权限是否合适，以及最近发布的代码是否引入异常。
如果故障紧跟在发布、插件安装、主题修改或数据库升级之后，可以先回滚到最近一次确认正常的版本，再观察网站是否恢复。回滚前保留当前日志和数据库备份，避免用反复覆盖文件的方式掩盖真正原因。若只是后台或某个动态功能报错，而静态首页正常，应缩小范围到对应模块，不必重装整站。
修复后怎样确认网站真的恢复？
看到首页能打开并不代表故障已经完全解决。恢复后应从至少两个不同网络访问HTTPS地址，确认域名解析正确、证书有效、首页状态正常，并检查CSS、JavaScript、图片等静态资源是否加载。随后依次测试登录、搜索、表单提交、文件上传、支付或其他对业务重要的功能。
- 连接验证：不同设备和网络都能建立连接，不再出现超时、拒绝连接或证书警告。
- 页面验证：首页、主要栏目和故障页面返回正确内容，页面不是空白或错误页。
- 服务验证：Web服务、数据库、缓存和队列等依赖保持运行，日志中不再持续产生同类错误。
- 业务验证：用户能完成关键操作，后台数据写入和读取正常。
- 持续验证：观察一段时间的访问监控、错误率和服务器资源，防止服务因内存、磁盘或流量再次耗尽。
如果只有本地设备仍打不开，而外部网络和监控都显示正常，应回到本地代理、DNS缓存、浏览器扩展和网络策略检查。如果所有外部网络仍然失败，应把域名、报错截图、发生时间、测试网络、状态码和最近变更整理给服务器或域名服务商。信息越完整，越容易确认故障位于解析、网络、服务还是程序层。
