网站故障排查顺序：从网络到数据库逐层定位问
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d020b510437f.html
📄
网站访问卡顿、白屏或接口频繁报错时，与其一次次刷新页面甚至反复重启服务，不如沿着网络链路、服务器资源、应用代码和数据库配置这几层，按顺序从外到内做体检。理清排查思路再动手，往往能更快让服务恢复正常，把故障对用户的影响控制在最小范围。
1. 先看网络链路与域名解析
网站打不开时，先从网络层面下手，别急着动服务器。先判断问题出在用户端还是服务端，最简单的办法是换个网络环境测试。用手机流量而不是公司Wi-Fi访问，如果正常打开，多半是本地网络缓存或路由器设置的锅；如果只有某一地区或某个运营商的用户反馈异常，那重点怀疑链路拥堵或域名解析还没生效。
1.1 核对解析记录是否准确
在本地命令行输入nslookup 你的域名，检查解析出的IP是否为服务器公网IP。如果解析为空，或指向一个早已停用的旧地址，通常是云平台上的A记录或CNAME配置出了问题。改完解析记录，全球生效需要时间，短的几分钟，长的要几个小时。同时也要留意CDN节点状态，避免个别区域回源失败。
1.2 测试端口连通与防火墙放行
能ping通服务器却打不开网页，通常不是机器宕机，而是端口没开。云服务商的安全组和服务器内部防火墙都得同时放行80和443端口。本地执行telnet 服务器IP 443，如果显示连接超时或无法连接，基本就是防火墙拦截或运营商封禁。优先检查安全组入方向规则，再核对服务器的iptables或firewalld配置。
2. 查看服务器负载与资源占用
页面响应变慢、大量请求超时，多数跟服务器资源吃紧有关。CPU持续满载、内存耗尽、磁盘空间不足或带宽跑满，都会导致请求排队，表现为服务卡顿甚至短暂中断。登录服务器后，依次运行top看负载和CPU占用，再用free -h查内存，用df -h看磁盘余量，这几条命令能快速摸清系统健康状况。
2.1 找出资源占用大户
在top界面按P键按CPU占用排序，看排名靠前的进程。常见的高占用原因有：被入侵后植入的挖矿程序、因缺索引而堆积的慢查询，以及恶意爬虫的高频抓取。交叉翻看Nginx或Apache的访问日志，确认这些请求具体来自哪些IP和URL。好比发现某个接口每秒被调用几百次，通过限制请求频率或封禁来源IP就能快速缓解。
2.2 提防磁盘写满与内存交换
磁盘使用率超过80%就得介入清理。会话文件、日志或临时目录被写满后，程序无法正常创建缓存，常常直接返回500错误。清掉旧的轮转日志和临时文件，通常能立刻腾出空间。内存方面，如果free -h显示swap分区读写频繁，说明物理内存严重不足，系统在内存与磁盘之间来回换页，性能会急剧下滑。这时应当优化程序内存占用量，必要时考虑扩容。
3. 排查应用日志与后端服务状态
页面白屏、部分功能不可用或直接返回5xx状态码，问题核心多半在应用层。打开浏览器开发者工具的Network面板，先看是哪些请求失败、失败时返回什么状态码，再顺藤摸瓜去查后端日志。
先确认Nginx或Apache的访问日志里有没有大量499或502状态码。499说明客户端在等待响应时主动断开，通常是上游处理太慢；502则代表网关或代理连不上后端，这时要检查PHP-FPM、Java应用或Node服务是否存活，端口是否在监听。用ps aux | grep 服务名确认进程状态，再用systemctl status 服务名查看是否有异常退出记录。服务确实挂了就直接拉起，但光拉起不查原因，过一会儿可能又挂。重点翻应用错误日志，定位是代码抛异常、依赖服务连不上，还是配置项写错所致。
4. 深入数据库性能与连接情况
页面数据加载慢、接口超时，但应用日志里没有明显错误，那就要看数据库了。先连上数据库执行show processlist;，观察是否有大量SQL语句卡在copy to tmp table或sending data状态。这些往往指向查询缺索引、单表数据量过大或锁竞争激烈。
再查慢查询日志，找出执行时间超过1秒的语句。常见解法包括给WHERE和ORDER BY涉及的字段加联合索引、改写过于复杂的JOIN，以及避免在循环里频繁发起查询。连接数方面，用show status like 'Threads_connected';看当前连接是否接近上限，如果连接总是被打满，得同时调整应用的连接池大小和数据库的max_connections值，避免相互顶死。
5. 常见问题
5.1 网站能打开但特别慢，先查哪个环节？
先看浏览器Network面板里耗时最长的请求。耗时主要花在等待响应（TTFB）较长，多半是应用或数据库处理慢；如果静态资源加载慢，则优先怀疑带宽或CDN。用top确认服务器负载，再用show processlist看数据库有没有卡住的SQL，按顺序定位。
5.2 重启服务器后故障很快复发，是什么原因？
说明问题的根源并未解决，只是暂时缓解了症状。常见情形包括磁盘日志写满、内存泄漏或数据库连接数被占满。重启只是清空进程和缓存，过一会儿又会累积到同样状态。应当趁服务正常时观察日志和监控指标，找出真正的压垮点。
5.3 排查了一圈都没找到原因，还有什么办法？
如果应用、数据库和网络都正常，可以尝试切换网络环境，或从另一个地域访问同一域名，看是否属于运营商链路问题。也可以暂时关闭CDN或防火墙做对比测试。此外检查服务器时间是否准确，时间偏差会导致HTTPS证书校验失败或会话验证异常，这类问题隐蔽且常被忽略。
6. 总结
网站故障排查不是靠感觉乱碰，而是按网络、服务器、应用、数据库这一条清晰的链路逐层推进。先用快捷命令排除最外层，再逐步深入内部，每个环节都留有对应的验证手段和常见解法。日常还可为磁盘、CPU和数据库连接数配置监控告警，在问题变严重前提前介入，比事后紧急排查轻松得多。
