网站故障排查顺序，快速定位根因降低中断时长
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1739c5ddafb2.html
📄
网站打不开或接口频繁报错，重启服务往往治标不治本。问题可能出在客户端网络、域名解析、服务器资源、应用代码或数据库任一环节。与其凭感觉乱试，不如遵循一套固定的排查路径，从网络入口到数据层逐层筛选，快速锁定问题根源，缩短业务中断时间。
1. 先看网络链路与域名解析
遇到访问异常，第一步应判断是服务端故障还是访问路径受阻。切换手机流量访问网站，若页面能正常打开，说明服务器本身运行正常，问题多半出在当前办公网络、路由器缓存或电脑本地DNS设置上。若不同地区的用户都反映无法访问，则要重点排查运营商线路波动或域名解析同步延迟。
1.1 核对DNS解析结果是否准确
在本地终端输入nslookup 你的域名并回车，查看返回的IP地址是否与服务器公网IP一致。若解析出的地址有误或为空，通常是域名记录改动未完全生效，或后台误配置了多条A记录。登录域名服务商控制面板，检查A记录、CNAME记录及CDN启用状态，修正后等待几分钟让解析在全球范围重新生效。
1.2 检查端口开放状态与防火墙策略
域名解析没问题但页面依旧打不开，下一步应验证端口连通性。登录云服务商控制台，确认安全组入方向已放行80和443端口；同时可在本地执行telnet 服务器IP 80，若返回连接失败，则说明安全组规则、服务器自带防火墙或机房网络策略阻断了外部请求，需要逐项核查并调整放行规则。
2. 检查服务器负载与资源占用
页面加载缓慢或请求超时，首要怀疑资源瓶颈。CPU使用率长期接近100%、内存耗尽、磁盘被日志占满或出口带宽跑满，都会导致新请求排队，用户端表现为页面无限转圈。SSH登录服务器后，依次执行top、free -m和df -h三条命令，即可快速掌握CPU、内存和磁盘的实时状态。
2.1 锁定消耗资源的异常进程
在top界面按下大写P键，让进程按CPU占用率排序，重点关注持续排名靠前的进程名称。常见资源消耗源包括：被注入的挖矿程序、缺乏索引的慢SQL反复执行、以及未限制频率的爬虫或脚本并发请求。结合Web访问日志，检查对应时间段哪些URL被高频请求、哪些来源IP集中涌入，基本能锁定异常流量源头。例如某个接口被自动化脚本轮询触发，动态进程被占满，日志中会留下密集的访问痕迹。
2.2 处理磁盘空间与内存交换的隐患
磁盘使用率超过80%后写入性能明显下降，一旦写满会导致临时文件无法生成或SESSION创建失败，网站直接抛出500错误。通过du命令找出大文件目录，清理过期备份、压缩并轮转旧日志以紧急释放空间。内存方面，若free -m显示swap分区长期被占用，说明物理内存已逼近极限，进程频繁在内存和交换分区之间交换数据，系统响应速度会断崖式下降。此时重启服务只是权宜之计，调整应用缓存上限或升级内存配置才是根本解法。
3. 分析应用运行日志与错误代码
页面能正常展示但特定操作报错，或直接出现500、502等状态码，说明故障发生在应用运行时。借助浏览器开发者工具切换到Network标签页，逐个请求查看返回状态码：500表示程序内部逻辑抛出异常，502意味着网关无法连通后端服务，404则提示路由或资源路径缺失。状态码能帮助快速缩小排查范围，直达具体模块。
3.1 从框架日志中提取关键异常信息
几乎每个开发框架都会输出独立的错误日志文件。PHP项目优先查看error_log，Java应用则检查Spring Boot日志中的异常堆栈。找到报错时间点附近的日志记录，重点关注堆栈顶部的异常类型和出错代码行号。例如出现Class not found，多半是依赖未正确安装；出现Connection refused，则指向数据库或缓存服务未启动。先修复日志中反复出现的核心异常，再验证相关功能是否恢复。
4. 验证数据库状态与慢查询
当页面加载极慢且日志中频繁出现数据库超时，问题可能已经延伸到数据层。使用数据库客户端连接到实例，执行show processlist查看当前会话，观察是否有长时间运行未结束的SQL语句。同时打开慢查询日志功能，分析执行时间超过设定阈值的查询语句，借助explain命令检查执行计划，判断是否缺少索引或关联了过多数据表。
一个实用做法是：先为高频查询字段添加复合索引，再优化SQL写法避免在WHERE子句中对字段使用函数运算。若数据库连接数被异常占满，查看是否有未释放的连接池或死锁事务，必要时手动kill掉阻塞中的会话，待业务恢复后持续观察连接数曲线。
5. 常见问题
5.1 Q1: 重启服务后网站短暂恢复正常，很快又故障，这是为什么？
重启只能清空进程状态，无法修复底层诱因。如果资源耗尽问题反复出现，应深度检查是否存在内存泄漏、慢SQL堆积或异常流量持续涌入。完整的做法是保留崩溃前后的日志和监控快照，对比重启前后的资源曲线，找出触发阈值升高的具体原因。
5.2 Q2: 排查时先看日志还是先看服务器状态？
建议先执行uptime、free和df等命令确认服务器基础资源是否健康，因为资源耗尽时应用日志可能无法正常写入。待确认资源充足后，再翻阅应用日志和错误堆栈，这样能避免在异常环境下误判日志中的报错信息。
5.3 Q3: 无法SSH登录服务器时如何排查故障？
先利用云服务商提供的网页版VNC或管理终端进入系统，检查sshd服务状态和防火墙是否误禁用了22端口。若VNC也连不上，说明系统可能死机或网络配置异常，需要检查云控制台中的CPU和带宽监控图，必要时通过控制台执行硬重启操作。
6. 总结
网站故障排查的核心思路是分层递进：先确认网络与解析，再核查资源与进程，然后分析应用日志与数据库，最后才是代码层面的修复。这套顺序能从外部到内部避免盲目操作，在最短时间内定位根因。建议每次故障解决后记录排查过程和根因结论，形成团队内部的故障案例库，后续同类型问题可直接按经验快速处理，大幅减少系统中断时间。
