网站打不开的排查方法，从网络到数据层逐步定位
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4275cf7df788.html
📄
网站出现无法访问、响应变慢或是接口频繁报错时，与其反复刷新页面或盲目重启服务，不如按照从网络到应用的固定顺序逐层筛查。每个环节都有对应的验证指令和判断依据，这样可以快速锁定问题根源，把排查时间压缩到最短。
1. 先验证网络链路和域名解析是否正常
遇到网站打不开，先不要急着登录服务器操作。换一个网络环境来测试，例如关闭WiFi改用手机流量访问，或者请不同地区的同事帮忙打开同一个网址。如果只有你自己访问失败，多半是本地网络的问题；要是所有人都无法访问，才需要继续往下排查。
1.1 核对DNS解析是否指向正确
在电脑的终端里输入nslookup 你的域名或者dig 你的域名，观察返回的IP地址。这里要留意三点：解析结果是否为空、返回的IP是否还是旧服务器的地址、解析出的IP与实际服务器的公网IP是否一致。如果解析异常，通常是A记录被误修改，或是TTL时间设置过长导致生效延迟，登录域名服务商后台检查一下记录即可。同时确认CDN回源配置有没有问题，很多时候部分地区访问异常其实是CDN节点故障引起的。
1.2 测试端口是否能够连通
如果ping域名能通但浏览器仍然打不开，说明网络链路通畅，但是端口被拦截了。重点检查服务器防火墙以及云平台安全组的80、443端口是否已放行。可以使用telnet 服务器IP 443来测试端口连通性，如果返回连接超时或直接被拒绝，基本可以断定是安全策略或运营商限制导致，此时应以调整防火墙规则为优先处理方向。
2. 核查服务器资源使用情况和系统进程
排除网络因素后，如果页面仍然卡顿或超时，就要关注服务器资源是否已经紧张。CPU跑满、内存不足、磁盘写满或是带宽被打满，都会导致请求排队等待，最终表现为页面一直转圈甚至服务中断。按顺序执行top、free -h、df -h这几个命令，十秒内就能掌握系统整体状况。
2.1 定位占用高资源的异常进程
在top界面按P键让进程按CPU占用率排序，找出是哪几个进程在抢占资源。常见的元凶包括被入侵后植入的挖矿程序、并发执行慢SQL而堆积的数据库进程，还有未做访问频率限制的爬虫脚本。把Web访问日志和可疑进程的ID对应起来，就能看到对应的来源IP和请求URL。例如某个IP每秒请求接口几十次，在日志里的痕迹会非常明显，直接做封禁或限流处理就能解决。
2.2 关注磁盘剩余空间和Swap占用
磁盘被写满是很隐蔽的故障点。日志文件、临时目录或Session存储一旦把磁盘占满，网站会突然抛出500错误。当使用率超过80%时，就应该清理过期的日志和缓存文件，往往能立竿见影地解决问题。内存方面，如果free -h显示Swap分区使用比例持续上涨，说明物理内存已经严重不足，系统在不断进行换页操作，整体性能会明显下降。优先检查是否有内存泄漏的进程，必要时考虑扩容服务器。
3. 通过状态码和应用日志定位代码层问题
当网络和系统资源都正常，页面依然白屏或功能时好时坏，问题就出在应用代码层。打开浏览器开发者工具的Network面板，查看关键请求的状态码：500表示程序内部抛出了异常，404说明路由或静态资源文件缺失，502则代表网关到后端服务之间连接不通，依据状态码可以快速缩小排查范围。
3.1 依靠应用日志还原现场
状态码只是表象，要看到具体报错信息必须查阅应用日志。先确认日志文件的路径和滚动策略，再根据出错的时间点去检索对应时段的记录。重点留意堆栈信息中的异常类型，例如空指针、数据库连接超时或是第三方接口调用失败。如果是偶发故障，可以在日志里加上请求ID和耗时记录，便于下次出现问题时能快速关联到同一请求链路。
4. 检查数据库连接与查询性能
很多接口超时或页面局部功能异常，源头都在数据层。先看数据库的活跃连接数是否接近上限，再用show processlist确认当前是否有长时间未完成的查询。一条慢SQL在数据量大的表上全表扫描，足以拖垮整个应用服务。
4.1 定位并优化慢查询
开启数据库的慢查询日志，把执行时间超过1秒的语句记录下来，逐条分析执行计划。常见的坑包括：联合查询缺少索引、在索引列上使用了函数运算、以及对大表做无谓的排序操作。针对高频查询，可以建立联合索引；对于复杂的报表统计，建议拆分成定时任务，在低峰期提前算好结果再缓存起来，而不是让用户每次请求都实时计算。
5. 常见问题
5.1 网站时好时坏，一会儿能开一会儿超时，是哪里出了问题？
这种间歇性故障大概率与服务器资源耗尽或数据库连接池占满有关。高峰期请求增多，线程或连接数被占满，后续请求只能排队等待然后超时。建议同时观察CPU使用率曲线和活跃连接数，两者达到峰值时正好对应故障发生的时间段，就能确认关联性。
5.2 重启服务器之后网站恢复了，是否就不用再排查了？
重启只是暂时释放了资源，并没有消除根本原因。建议在重启前先抓取一下进程列表和系统日志，看看有没有异常进程或频繁报错的服务。如果是内存泄漏，重启后短时间内又会复发，必须找到泄漏的代码段才能彻底解决。
5.3 为什么ping服务器能通，但浏览器却打不开页面？
ping走的是ICMP协议，并不代表80端口或443端口是开放的。可能的情况包括：防火墙规则只允许ICMP而不放行HTTP端口、Web服务进程没有启动或监听在错误地址上、以及服务器出口带宽已耗尽。用curl或telnet直接探测目标端口，能更快区分以上几种情况。
6. 总结
处理网站故障时，保持网络、系统、应用、数据四层递进的排查顺序，能避免走弯路。建议平时就整理一份服务器关键信息的文档，包括公网IP、端口放行规则、日志路径以及数据库账号权限，故障发生时对照检查会高效得多。每次修复后记录下根因和处理命令，也能帮助你在后续遇到类似问题时快速响应。
