网站常见故障排查：从报错到根因的完整分析指南
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /eec47e7047f2.html
📄
网站出现访问卡顿、页面报错或功能失灵时，真正棘手的不只是故障本身，而是如何在混乱中快速锁定问题源头。与其像无头苍蝇一样乱试，不如建立一套从现象到根因的排查思路，按顺序验证，才能少走弯路，尽快恢复服务。
1. 先分清故障类型，再看报错码
动手排查前，先花一分钟给问题归个类：是网站完全打不开，还是加载特别慢，抑或只有某个功能报错？这个初步判断决定了后续的排查方向。同时，用户浏览器里显示的报错码是最直观的线索，千万别忽略。
例如，看到 502 Bad Gateway，意味着代理服务器找不到后端服务的有效响应，重点应放在应用进程或上游服务上；而 403 Forbidden 多半与权限配置或防火墙拦截有关；500 Internal Server Error 则是应用代码或服务器环境抛出的通用异常。至于 404，先检查 URL 路径和资源引用是否写错。记住，报错码是把范围缩小的利器，能帮你跳过大量无关检查。
2. 从域名解析到网络链路的验证
如果域名解析出错，后面的一切都是空谈。先用 ping 或在线解析工具确认域名是否指向正确的服务器 IP，同时检查解析记录是否过期或配置有误。如果解析正常但访问仍慢，再往下看网络链路。
2.1 路由追踪与 CDN 回源检查
使用 traceroute 或 MTR 工具观察数据包经过的每一跳节点，能直观发现哪个环节出现高延迟或丢包。若使用了 CDN，还需重点核对回源配置是否正确，比如源站 IP 有没有写错、缓存规则是否误把动态请求也缓存了。一个常见的隐蔽问题是 CDN 节点故障，此时可以临时把本地 hosts 指向源站 IP 来对比验证。
2.2 安全策略误拦截的确认
检查云安全组、服务器防火墙（如 iptables）以及 WAF 规则是否误伤了正常请求。尤其在搞促销或活动期间，某些安全组件因为触发阈值过低而限流，是造成用户大面积无法访问的常见原因。查看安全日志，留意是否有大量被拒绝的请求，并核对规则是否过于严格。
3. 服务器资源与应用状态的体检
登录服务器后，第一件事就是用 top 或 htop 查看 CPU 和内存使用率。如果资源长期处于高位，需要区分是真实流量冲击还是进程异常。用 ps aux 按资源占用排序，找出那些吃满 CPU 或内存的进程，确认它们是否属于正常业务。同时别忘了用 df -h 检查磁盘分区，使用率超过 90% 时，日志文件或临时缓存往往是幕后黑手，建议顺手配置日志轮转，免得下次又被写满。
3.1 应用日志里的关键信号
Nginx 或 Apache 的错误日志能精准反映后端超时和 5xx 的分布。对于 PHP 应用，开启慢查询日志能揪出执行时间过长的脚本；对于 Node.js 或 Python 服务，则要留意进程是否有未捕获的异常或事件循环阻塞。看日志时别只扫错误级别，很多 warning 级别的记录也可能暗示隐患。
4. 数据库慢查询与锁等待的定位
数据库往往是响应缓慢的深水区。进入 MySQL 或 PostgreSQL，执行 SHOW PROCESSLIST; 查看当前会话，重点关注执行时间过长或处于 lock 状态的线程。临时开启慢查询日志，并把阈值设到 2 秒以内，持续观察一段时间，能帮你锁定那些拖慢全站的罪魁祸首 SQL。
4.1 索引与表结构优化方向
发现慢 SQL 后，用 EXPLAIN 查看执行计划，检查是否走了全表扫描而没命中索引。通常给 WHERE 和 ORDER BY 涉及的字段加上适合的联合索引，性能就能立竿见影。此外，大表的数据清理和归档也要定期做，否则即使有索引，查询也会随着数据量增长而变慢。
5. 常见问题
5.1 网站报 502 错误，重启 Nginx 后恢复，但过一会又出现，怎么办？
这说明问题根源不在 Nginx 本身，而是后端的 PHP-FPM 或 Node.js 进程崩溃或超时。建议检查后端进程的运行状态和错误日志，同时调大 PHP-FPM 的 request_terminate_timeout 参数，并确认后端服务的内存是否充足。
5.2 用手机流量访问网站很慢，但电脑连 WiFi 就正常，是什么原因？
这种情况一般不是网站本身的问题，而是本地网络或运营商链路导致的。先用手机执行 traceroute 对比一下路由路径，看看是否经过了一个延迟极高的节点，或是运营商 DNS 解析到了旧的 CDN 节点。也可以尝试切换手机 DNS 为公共 DNS 再测试。
5.3 排查时发现磁盘空间突然少了 20G，但没装新东西，可能是什么占用了？
最常见的是应用程序日志或系统 core dump 文件被持续写入。用 du -sh /var/log/* 或 lsof | grep deleted 找出那些被进程占用但已删除的文件，这类文件会一直占着空间直到进程重启。确认后清理日志并设置 logrotate 策略。
6. 总结
排查网站故障不是靠运气，而是靠顺序和排除法。建议将本文的排查思路整理成一张清单：先看报错码缩小范围，再验证 DNS 和网络链路，然后是服务器资源与应用日志，最后深入数据库。遇到问题时按部就班地排查，并把每次的解决过程记录下来，形成自己的故障档案。这样，下一次遇到类似问题，你就能直接命中要害，大幅缩短恢复时间。
