网站故障排查全流程：从网络到数据库逐层定位
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /adeb609eb477.html
📄
网站出现打不开、响应慢或接口异常时，与其反复刷新甚至盲目重启，不如按顺序逐层排查。故障往往源于网络链路、服务器资源、应用代码或数据库配置，理清排查路径再动手，能更快恢复服务，减少对用户的影响。
1. 先查网络链路与DNS解析
站点无法访问，先从网络层入手，不要急着重启服务器。判断问题出在用户侧还是服务侧，可以换一种访问方式验证，例如用手机4G网络而非办公Wi-Fi。若恢复正常，多为本地网络缓存或设备问题；若只有特定地区或运营商的用户反馈无法访问，则需怀疑链路拥堵或DNS解析未生效。
1.1 核对解析记录与实际IP
在本地终端输入nslookup 你的域名，看解析出的IP是否与服务器公网地址一致。若结果为空或指向旧IP，通常是控制台的A记录或CNAME配置有误。注意修改解析后全网生效有延迟，一般需要几分钟到数小时。同时确认是否CDN节点异常导致部分地域回源失败。
1.2 测试端口连通性与防火墙
能ping通却打不开网页，多半是端口未开放。云服务商安全组和服务器内部防火墙都要放行80和443端口。执行telnet 服务器IP 443，若超时或无法连接，基本锁定是防火墙拦截或ISP封禁。此时优先检查安全组策略，再核对iptables等本地规则。
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，问题多半在应用层。查看后端服务的运行状态，用systemctl status或ps aux | grep 进程名确认进程是否存活。若进程反复崩溃，看应用日志中的堆栈信息，定位异常代码位置。日志路径通常在/var/log/下，或应用配置中指定的目录。
3.1 常见应用故障类型
代码上线后出现的故障，多为语法错误、依赖缺失或环境变量未更新。排查时使用tail -f 日志文件实时观察，配合复现操作，能更快抓到报错瞬间的上下文。安全起见，检查是否近期配置文件被改动，比如连接池大小、超时时间等参数调整不当，也会引发连锁问题。
3.2 充分利用访问日志
Nginx或Apache的访问日志记录了每个请求的状态码和耗时。按状态码筛选，4xx多为客户端问题，5xx则是服务端异常。请求耗时长的URL，往往是慢接口的入口。用grep " 500 " 访问日志可快速统计5xx数量，判断故障是否集中在某一时刻或某一路径。
4. 深入数据库层排查慢查询与锁
前端请求超时或接口返回延迟，如果服务器资源正常，需要检查数据库。慢查询堆积会拖垮整个应用。先开启慢查询日志，分析执行计划；用EXPLAIN查看SQL是否走索引。常见问题包括缺少索引、全表扫描、锁等待超时。
4.1 定位慢查询与索引优化
在MySQL中执行SHOW PROCESSLIST;查看当前运行的事务，重点关注State为Locked或Sending data的记录。将慢查询日志中的SQL拿出来，用EXPLAIN分析，若type为ALL则说明全表扫描，应添加合适的索引。例如在用户表的email字段建立唯一索引，能显著加快登录查询。
4.2 处理锁竞争与连接数耗尽
并发高时容易触发锁竞争，表现为两个事务互相等待。优化事务逻辑，缩短持有锁的时间，避免在事务中做外部API调用。连接数被占满也是常见故障，重启数据库虽能临时缓解，但需调整max_connections参数，并排查应用是否未正确释放连接。
5. 常见问题
5.1 网站突然打不开，第一步该做什么？
先确认是全部用户还是个别用户受影响。可用本机浏览器直接访问，配合手机流量做对比。同时执行ping和telnet测试连通性，判断是否网络层问题，再决定是否登录服务器检查。
5.2 服务器CPU正常，但页面仍然很慢，可能是什么原因？
CPU正常不代表一切正常。重点检查数据库慢查询、磁盘I/O写入频繁、内存swap使用情况，以及应用是否存在死循环或线程阻塞。用iostat看磁盘，用ss -lnt看端口连接数。
5.3 排查完所有层面都没有问题，但故障仍未解决，怎么办？
考虑外部因素，例如第三方API依赖超时、云服务商区域故障、域名被劫持等。查看监控平台的告警记录，确认是否为上游服务问题。同时检查是否近期有CDN策略调整或HTTPS证书过期，这类问题常被忽略。
6. 总结
网站故障排查的核心逻辑是从外到内、从底层到上层。先验证网络和解析，再看服务器资源，随后分析应用日志，最后深入数据库。每一步都基于数据和证据做判断，而不是凭感觉重启。建议整理一份故障排查手册，把常用命令、日志路径和关键指标记录下来，下次遇到类似问题能更快定位，规避重复踩坑。
