网站打不开的排查步骤：从域名解析到服务器资源逐层定位
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b40f7fb6ad99.html
📄
网站打不开时，用户反馈千差万别：有人提示连接超时，有人看到 502 或 500 错误，还有人刷新几遍又恢复了。面对这些情况，与其反复刷新或盲目重启服务器，不如顺着请求链路逐层排查。按照从网络入口、服务器资源到应用进程的顺序检查，通常能更快找到真正的问题所在。
1. 先确认访问范围与本地网络状态
排查的第一步是判断问题的影响范围。用手机切换至移动流量访问网站，如果正常打开，说明服务器端没问题，症结多在自己电脑或办公网络。此时可以重启路由器，或检查系统 DNS 设置是否被改成了不常用的地址。若同事或外地朋友同样访问失败，那问题大概率出在服务端的域名配置或机房链路上。
1.1 检查域名解析是否指向正确
在命令行输入 nslookup 你的域名 或 ping 你的域名，观察返回的 IP 是否与服务器实际公网地址一致。若解析出的 IP 是旧的、空白的，或者指向 CDN 后回源失败，都会导致页面无法访问。修改 DNS 记录后存在生效延迟，通常几分钟到几小时不等，别急着反复修改。使用 CDN 的站点还需登录 CDN 控制台，确认节点状态和回源配置是否正常。
1.2 验证端口是否被拦截
域名解析正常、服务器也能 ping 通，但浏览器打不开，多半是端口不通。在本地执行 telnet 服务器公网IP 443，如果连接超时或提示失败，重点检查云厂商安全组和服务器本地防火墙。常见坑是云平台安全组已放行，但服务器内 iptables 或 firewalld 未同步放行 80 和 443 端口，两层都要确认，顺序建议先外层后内层。
2. 检查服务器负载与磁盘空间
页面响应极慢、大量请求超时，通常与服务器资源耗尽有关。CPU 满载、内存不足或磁盘写满都会让服务假死。登录服务器后依次执行 top、free -h、df -h 三条命令，几秒内就能掌握 CPU 占用、物理内存余量和磁盘剩余空间。注意观察 load average 数值，如果持续超过 CPU 核数，说明负载已偏高。
2.1 定位 CPU 和内存占用异常的进程
在 top 界面按 P 键按 CPU 排序，按 M 键按内存排序，重点查看排名靠前的进程。常见异常包括：被入侵后植入的挖矿程序、数据库慢查询堆积，以及恶意爬虫疯狂抓取接口。建议同步查看 Nginx 或 Apache 访问日志，根据来源 IP 和请求路径判断是否属于合法流量。例如某个接口每秒被请求数百次，可在防火墙临时封禁来源 IP 或限制该接口的访问频率，压力会明显下降。
2.2 留意磁盘写满和 swap 频繁交换
磁盘使用率超过 80% 就该重视，超过 90% 会严重影响服务。日志文件、会话文件或临时目录写满后，应用无法正常写入缓存，网站会出现 500 错误或白屏。清理 /var/log 下的旧日志、删除 tmp 目录中的临时文件，通常能快速释放空间。另外，若 free -h 显示 swap 分区读写频繁，说明物理内存已不够用，系统在内存和磁盘间反复换页，性能会断崖式下降，应优先优化应用内存占用，再考虑升级配置。
3. 排查应用进程与服务的实际状态
资源充足、端口放行后网站依然报错，就要把注意力转向应用本身。进程存在不等于功能正常，Nginx 主进程活着但 worker 进程异常退出，或者 PHP-FPM 假死的情况并不少见。检查服务状态时，不要只看 systemctl status 的绿色 active 标记，还应该用 curl -I 域名 测试返回的 HTTP 状态码。
3.1 从错误日志快速定位原因
查看 Nginx 的 error.log、PHP-FPM 的日志或 Java 应用的异常堆栈，通常能直接找到线索。比如日志中出现 “upstream prematurely closed connection”，说明后端服务处理超时或主动断开；如果出现 “Connection refused”，则是后端端口未监听或进程已崩溃。结合日志时间点和用户报障时间对比，能更快锁定触发条件。
判断标准：如果 curl 返回 502 Bad Gateway，问题多半在 PHP-FPM 或应用服务器；如果返回 504 Gateway Timeout，多半是应用响应超时；如果返回 200 但内容为空，则需检查框架配置或缓存层。
4. 数据库连接异常也是常见诱因
很多网站访问异常并非 Web 层问题，而是数据库连接不上导致。当数据库连接数打满、慢查询堆积或主从延迟过大时，应用会直接报错。登录数据库执行 SHOW PROCESSLIST; 查看当前活跃连接，重点关注 Time 值很大的阻塞查询。若连接数持续跑满 max_connections，就要检查是否有脚本未释放连接，或是否被大流量并发打满。
另外，确认数据库磁盘空间是否充足也很关键。MySQL 的 binlog 日志默认保留时间较长，积累到一定量会占满磁盘。定期清理过期 binlog 并设置合理保留周期，可以避免因磁盘满导致数据库拒绝写入。遇到主从架构的站点，还需检查 SHOW SLAVE STATUS; 中的 Slave_IO_Running 和 Slave_SQL_Running 是否都为 YES，否则从库数据落后也会触发部分功能报错。
5. 常见问题
5.1 网站刷新几次又能打开，是什么原因
这种情况多与进程状态或连接池有关，例如 PHP-FPM 的 worker 进程耗尽后自动回收，或数据库连接数短暂打满又释放。建议查看对应时段的错误日志，确认是否有间歇性报错。同时检查 Nginx 的 keepalive_timeout 和 PHP-FPM 的 pm.max_children 设置是否合理，适当提高进程上限能减少类似波动。
5.2 用 IP 能访问网站，但用域名不行
这说明服务器和端口都没问题，故障集中在域名解析环节。检查域名的 A 记录或 CNAME 是否配置正确，以及是否开启了 DNSSEC 但密钥不匹配。海外注册商与国内解析商之间也可能存在同步延迟，必要时可更换权威 DNS 服务商。另外，某些公共 DNS 缓存了旧记录，可尝试在本地指定 223.5.5.5 或 114.114.114.114 做对比测试。
5.3 服务器重启后网站恢复，但过几天又出问题
重启只是暂时释放了资源，并没有解决根源。通常意味着存在内存泄漏、定时任务堆积或磁盘持续缓慢增长。建议部署简单的监控脚本，每小时记录 CPU、内存、磁盘和进程数，配合日志分析定位变化趋势。优先排查是否有常驻进程未被回收，以及 crontab 中是否有并发执行且未加锁的定时任务。
6. 总结
网站无法访问的排查应遵循从外到内的顺序：先确认域名解析和端口连通性，再检查服务器负载与磁盘，接着查看应用进程和日志，最后排查数据库连接与主从状态。每个环节都准备好对应的命令和观察指标，能显著缩短故障恢复时间。建议将本文提到的检查步骤整理成一张自查清单，运维人员在遇到告警时可逐项执行，避免遗漏关键节点。
