网站故障排查步骤，从外到内逐层定位根因
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ed94dfc190e9.html
📄
网站打不开或者接口频繁报错，很多人的第一反应是重启服务，但重启之后问题依旧的情况其实很常见。故障源头往往不在应用本身，网络链路、服务器资源、代码逻辑或者数据库层面都可能藏有隐患。与其盲目折腾，不如建立一套从外到内的排查顺序，把问题先定位到具体层面，再动手处理。
1. 先查网络链路与域名解析
发现访问异常，不要急着登录服务器。先换个网络环境验证一下，比如用手机流量打开网站。如果手机能正常访问，说明服务端是健康的，问题大概率出在你当前办公网络的出口、路由器缓存或者本地设备上。如果只有特定地区的用户打不开，就要考虑运营商线路波动或者DNS解析同步延迟。
1.1 核对域名解析结果
在电脑上打开命令行，输入nslookup 你的域名 并回车，检查解析出来的IP是否和服务器实际公网IP一致。如果解析结果不对或者为空，通常是域名记录改完没生效，或者同时存在多条冲突的A记录。登录域名管理后台，检查A记录、CNAME和CDN配置，修正后等待几分钟让解析在全网生效。
1.2 测试端口连通性与防火墙
域名解析正常但浏览器还是进不去，下一步要确认端口是否通。登录云服务商控制台，检查安全组入方向是否放行了80和443端口。然后在本地执行telnet 服务器IP 80，如果提示连接失败，说明外部请求被安全组规则、服务器内置防火墙或机房网络策略拦住了。
2. 检查服务器资源与异常进程
页面加载很慢或者请求超时，最常见的原因是服务器资源被耗尽。CPU飙高、内存不足、磁盘写满或带宽跑满，都会让新请求排队等待，用户看到的画面就是一直转圈。SSH登录服务器后，依次执行top、free -m和df -h这三个命令，资源占用情况很快就会清楚。
2.1 找出消耗资源最多的进程
在top界面按大写P键让进程按照CPU使用率排序，留意持续排在前面的进程名称。常见的元凶包括：被植入的挖矿程序、缺少索引的SQL反复执行、爬虫没有限速导致并发过高。查看Web访问日志，看看对应时间段哪些URL被密集请求、哪些IP在大量涌入，基本就能锁定异常来源。比如某个接口被脚本轮询，进程被占满，日志里就会留下明显的密集访问痕迹。
2.2 关注磁盘空间与内存压力
磁盘使用率超过80%后，写入性能就会明显下降，一旦写满，临时文件或SESSION无法创建，网站会直接返回500错误。查看大文件分布，清理过期备份和滚动压缩旧日志可以快速释放空间。内存方面，如果free -m显示交换分区长期占用较高，说明物理内存已经不够用，系统频繁在内存和交换空间之间搬运数据，响应速度会断崖式下降。重启服务只能缓解一时，调整缓存上限或增加内存才是长久之计。
3. 定位应用代码与运行时错误
页面能打开但某些操作报错，或者直接显示500、502等状态码，说明问题出在应用运行层。打开浏览器开发者工具，切到Network标签，观察每个请求返回的状态码：500代表程序内部逻辑抛错，502表示网关连不上后端服务，404说明路由或资源路径不存在。状态码能帮你把排查范围缩到具体模块。
3.1 从运行日志中锁定报错位置
绝大多数开发框架都会输出错误日志。PHP项目先找error_log文件，Java项目查看Tomcat或Spring Boot的日志输出。在日志里搜索Exception或ERROR关键字，通常会直接给出出错的文件名、行号和具体异常信息。比如一条常见的SQL语法错误日志，会明确指出是哪条语句和哪个表出了问题，顺着这个信息去修改对应代码即可。
3.2 区分500和502的处理思路
500错误要去查应用本身的日志，看具体是哪个控制器或函数抛出的异常；502错误则优先检查反向代理与后端服务的连接状况，比如Nginx和后端端口是否正常监听、进程是否存活。如果后端服务频繁崩溃，还需要结合系统日志观察是否有内存溢出或进程被杀死的记录。
4. 排查数据库连接与查询性能
网站本身没挂，但操作时偶尔报错或者响应极慢，数据库往往脱不了干系。数据库连接数被打满、慢查询堆积、锁表或者连接池耗尽，都会直接影响业务接口的响应时间。
4.1 查看连接数与慢查询日志
登录数据库执行show processlist，可以看到当前所有连接和正在执行的SQL。如果大量连接处于Sleep状态，说明连接池配置过高或者应用没有正确释放连接。打开慢查询日志，找出执行时间超过1秒的SQL语句，重点检查是否缺少索引或者查询条件是否使用了函数导致索引失效。比如某条查询在数据量大的表上全表扫描，每秒请求一多，数据库CPU立刻就会飙升。
4.2 连接池与锁竞争的判断
如果连接池参数设置过小，高并发时请求会等待获取连接，表现为接口超时。相反，如果连接池过大，数据库自身连接数可能被占满，新的应用实例反而连不上。数据库出现锁等待时，可以在information_schema的innodb_trx表中查看未提交的事务和锁状态。确认是长事务持有锁不放，还是并发更新同一行导致的竞争，再决定调整事务粒度还是优化业务逻辑。
5. 常见问题
5.1 网站偶尔打不开但过一会儿又恢复了，是什么原因？
这种间歇性故障通常指向服务器资源周期性耗尽或数据库连接池达到上限。建议先观察系统监控，看看故障时间点是否与定时任务、流量高峰重合，同时检查慢查询和错误日志，确认是否存在内存泄漏或连接未释放的问题。
5.2 重启服务后问题暂时消失，但过几天又复发，怎么办？
反复出现说明根因没有被真正解决。可能是内存泄漏、日志文件持续增长占满磁盘，或者某个接口存在性能瓶颈。建议长期监控CPU、内存、磁盘和数据库连接数的趋势，记录每次故障前的变化，配合日志定位最终源头。
5.3 更换了域名解析，但部分用户还是访问不了旧地址？
DNS解析在全球生效需要时间，各地运营商的缓存刷新速度不同。另外检查是否还在使用旧的CDN配置或浏览器本地缓存。可以先清掉自己设备的DNS缓存测试，同时确认域名解析记录只保留一条正确的A记录，把TTL值调低可以加快生效速度。
6. 总结
网站故障排查的核心思路是逐层缩小范围，不要上来就动代码或重启服务。按照客户端网络、DNS解析、端口连通性、服务器资源、应用日志、数据库状态这个顺序从外到内检查，每一步都有明确的验证方法，能省下大量试错时间。建议日常就做好监控和日志收集，把每一次故障的处理过程记录下来，形成自己的排查手册，下次遇到类似问题就能快速应对。
