网站故障排查顺序：从网络链路到数据库逐层定位
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b6867223eb82.html
📄
网站打不开、页面转圈或接口频繁超时，很多人第一反应是刷新页面或者干脆重启服务器，但这样往往治标不治本。想要快速恢复服务，关键是有章法地逐层排查。故障点通常藏在外网链路、服务器状态、应用日志和数据库配置这几层里，按照从外到内的顺序动手，定位会更准，恢复也更快。
1. 从网络链路与域名解析开始查
网站无法访问，先别急着动服务器。首先要分清楚是用户端的问题还是服务端的问题。最简单的方法是换个网络环境试试，比如用手机流量而不是公司Wi-Fi访问。如果换网络后能打开，多半是本地路由器缓存或DNS设置出了岔子；如果只有特定地区或某个运营商的用户打不开，那就要重点考虑链路拥塞或者域名解析还没生效。
1.1 核对域名解析记录是否指向正确
在自己的电脑上打开命令行，输入nslookup 你的域名，看解析出来的IP和服务器公网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状态码，问题核心大概率在应用层。打开浏览器开发者工具，查看网络面板中具体请求的状态码和数据返回时间，能快速判断是前端渲染失败还是接口报错。若确认是后端接口问题，就去翻应用服务（如Java的Tomcat、Python的Gunicorn）的日志文件，重点检索ERROR和Exception关键词，同时查看错误堆栈中首次出现的业务代码行，往往能直接定位到具体的出错方法或第三方依赖调用。
3.1 确认进程活着但服务没响应的情况
用ps -ef | grep 应用名确认进程存在，再尝试用curl -I 127.0.0.1在服务器本地访问，判断是服务本身没启动，还是对外网络链路的问题。如果本地访问正常而外部不通，回头再查防火墙和端口映射；如果本地也报错，就继续看应用日志和依赖的中间件，比如Redis或消息队列是否连接超时。
3.2 留意慢接口与超时配置
还有一种情况是进程活着但响应特别慢，检查应用侧的超时设置和连接池配置，确认是否因为某次慢查询拖垮了整个线程池。为关键接口设置合理的超时阈值（例如3秒），并开启慢请求日志，能帮助快速捕获表现异常的具体SQL或外部调用，避免单个故障拖垮整体服务。
4. 深入排查数据库层面的瓶颈
经过网络、服务器和应用层排查之后仍未定位，问题往往到了最内层的数据库。数据库连接数占满、慢查询堆积、锁等待严重或者主从延迟，都会导致接口长时间不返回数据。登录数据库执行SHOW PROCESSLIST;，能看到当前所有会话的耗时和状态。如果大量会话处于"Waiting for table metadata lock"或"Copying to tmp table"，通常意味着锁冲突或临时表过大。
4.1 定位慢查询并优化索引
开启慢查询日志，筛选出执行时间超过1秒的SQL语句。用EXPLAIN查看执行计划，检查是否走了全表扫描、用了临时文件排序或没有命中索引。常见的修复方式是给WHERE条件高频使用的字段加普通索引，或者在排序字段上做联合索引。需要注意的是，索引不是越多越好，写频繁的表添加过多索引反而拖慢插入和更新速度。
4.2 检查配置与主从复制状态
数据库连接池设置过小，遇到流量高峰就会出现连接等待；设置过大又容易打满数据库自身连接上限。建议根据实际并发调整连接池最小值与最大值，并同步核对数据库端的max_connections配置。主从架构下，在从库执行SHOW SLAVE STATUS;，关注Seconds_Behind_Master的值。如果该值持续增长且不为0，说明从库同步滞后，读操作会读到陈旧数据，需检查从库所在机器的磁盘I/O和网络带宽是否受限。
5. 常见问题
5.1 问题1：服务器重启后故障自动消失，还需要继续排查吗？
需要。重启确实能临时清除内存中的异常状态，但如果根因是配置错误、资源泄漏或磁盘写满，故障很快会再次出现。重启后建议仍按上述顺序完整排查一遍，并保留当时的系统日志和监控截图，以便从源头修复而非反复重启。
5.2 问题2：排查时先重启数据库是否可行？
不建议。数据库往往承载了大量有状态的数据和连接，直接重启会导致正在执行的事务被强制回滚，甚至引发数据不一致或主从重新同步的长时间不可用。除非明确是数据库实例卡死无法响应，否则应先通过进程列表和慢查询日志做在线诊断，再决定是否有必要维护窗口。
5.3 问题3：判断故障是否与CDN有关的标准是什么？
可以通过绕过CDN直接访问源站的IP和Host头，对比响应速度与状态码。如果源站访问正常而域名访问异常，且测试终端分布在不同地区均为同一表现，通常是CDN节点异常或缓存规则配置有误。可临时停用CDN观察恢复情况，再检查CDN的回源配置和缓存过期策略。
6. 总结
网站故障排查的核心原则是由外而内、逐层收窄范围。每次动手先明确当前层的判断指标，再决定是否进入下一层，避免在不确定的情况下盲目重启或修改配置。建议在日常维护中建立一套基线检查清单：定期核对域名解析、安全组规则、磁盘余量和数据库慢查询数量，故障出现时按清单快速对照，能大幅缩短恢复时间。
