网站故障排查顺序，由外到内逐步定位根因
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c8f41a04f22e.html
📄
网站突然打不开或者接口报错，很多人第一反应是重启服务，但往往重启之后问题还是存在。实际上，故障的源头可能根本不在应用本身，网络链路、服务器资源、代码逻辑甚至数据库都可能是诱因。与其盲目试错，不如按照从外部到内部的顺序逐层排查，每一步都确认无误后再进行下一步处理。
1. 先验证客户端到服务器的网络链路
发现网站无法访问，先别急着登服务器。最常见的做法是打开手机流量，使用浏览器直接访问网站域名。如果手机能正常打开，说明服务端运行正常，问题大概率出在你当前办公网络、本机代理设置或者浏览器缓存上。如果只有特定区域的用户访问困难，则需考虑运营商线路不稳定或 DNS 解析同步延迟。
1.1 核对 DNS 解析是否指向正确目标
在本地电脑的命令行工具中输入 nslookup 你的域名并回车，查看返回的 IP 地址是否与服务器实际公网 IP 一致。若解析出的地址不对或是空白，通常意味着域名解析记录修改后未生效，或者配置了相互冲突的多条记录。登录域名注册商平台，检查 A 记录、CNAME 记录以及是否开启了 CDN 加速，修正配置后等待几分钟让解析在全球范围内刷新。
1.2 检查端口连通性与防火墙规则
域名解析正确却依然无法打开页面，下一步就要验证端口是否通畅。进入云服务商的安全组控制面板，确认入方向规则已放行 80 和 443 端口。同时执行 telnet 服务器IP 80 命令测试 TCP 连接，如果显示连接失败，说明请求被安全组规则、服务器系统防火墙或者机房网络策略拦截了。
2. 排查服务器资源与进程占用情况
页面加载缓慢、接口响应超时，很大概率是服务器资源被耗尽。CPU 持续满载、物理内存不足、磁盘因日志堆积而写满，或是出口带宽被占满，都会导致新请求无法及时处理，用户端表现就是一直转圈等待。登录服务器后，依次执行 top、free -m 和 df -h 命令，就能快速掌握资源现状。
2.1 定位消耗资源的具体进程
在 top 命令的输出界面，按大写 P 键让进程按照 CPU 使用率从高到低排列，观察持续排在最前面的进程名称。常见的资源占用元凶往往来自几个方面：服务器被植入挖矿程序、数据库缺少索引导致慢查询频繁执行、爬虫未设置频率限制造成并发过高。结合 Web 访问日志分析对应时段，看看哪些 URL 被高频请求、哪些来源 IP 在批量涌入，通常能锁定异常流量的源头。比如某个接口被外部脚本每秒钟轮询多次，后端进程被占满连接数，日志中就会留下密集的请求痕迹。
2.2 留意磁盘空间与内存交换分区
磁盘使用率达到 80% 后写入性能会明显下滑，一旦完全占满，系统就无法创建临时文件或会话，页面会直接返回 500 错误。检查大文件分布后，可以用清理过期备份和滚动压缩历史日志来紧急释放空间。内存方面，如果 free -m 输出显示交换分区长期有大量占用，说明物理内存已经接近极限，系统正在频繁进行内存与磁盘之间的数据交换，响应速度会急剧下降。此时单纯重启服务只是暂时缓解，调整应用缓存上限或为服务器扩容内存才是长久之计。
3. 分析应用层运行日志与错误状态码
页面本身能打开，但部分提交操作报错，或者直接显示 500、502 等状态码，这通常说明应用运行时报错了。打开浏览器开发者工具，切换到 Network 标签页，刷新页面并观察各个请求的状态码：500 表示程序内部逻辑抛出异常，502 代表网关无法连接后端应用，404 则是路由或资源路径不存在。根据状态码你就能缩小排查范围到具体模块。
3.1 从应用日志中提取有效报错信息
几乎每种开发框架和网站程序都会生成错误日志文件。PHP 项目先查看 error_log 文件，Java 项目则关注应用容器输出的日志文件。打开日志后搜索 ERROR 或 Exception 关键字，仔细阅读堆栈信息，定位到具体报错代码文件和行数，再结合上下文判断是空指针、参数校验失败还是外部依赖连接超时。
4. 深入检查数据库连接与查询性能
当应用日志提示数据库连接失败或 SQL 执行超时，问题焦点就转移到数据层。先查看数据库服务本身是否存活，连接数是否已达上限。执行 SHOW PROCESSLIST 能实时看到正在运行的查询，如果存在大量长时间未返回的会话，说明 SQL 语句有不合理的全表扫描或者存在锁等待。
4.1 分析慢查询日志与索引使用情况
开启数据库慢查询日志，设定一个阈值如 1 秒，然后针对记录下来的 SQL 使用 EXPLAIN 语句分析执行计划。重点查看是否走索引、扫描行数大不大。常见的优化手段包括为 WHERE 条件字段加索引、避免在索引列上做函数运算、以及改写关联查询逻辑。
5. 常见问题
5.1 网站故障排查时应该先重启还是先看日志？
建议先看日志和资源状态，再决定是否重启。重启只能让当前进程初始化，无法清除根因，还可能掩盖关键报错信息。正确做法是先按照网络、资源、应用、数据库的顺序检查现状，找到具体指向后再执行操作。
5.2 排查时浏览器登录不上服务器怎么办？
确认你所在网络的出方向规则是否屏蔽了 SSH 端口，同时检查云平台安全组的入方向规则是否放行了 22 端口。如果本机限制较多，可以通过云控制台自带的 VNC 远程登录功能进行操作，或者临时修改防火墙策略放行你的办公 IP 地址。
5.3 为什么重启服务器之后故障短暂消失又复发？
这种情况多数是资源问题或代码缺陷没有根治。比如磁盘日志没有清理、数据库慢查询没有优化或应用缓存设置不合理，重启只是清空了当前进程状态，等运行一段时间后问题再次累积爆发。需要针对根因处理，而不是反复重启掩盖症状。
6. 总结
网站故障排查的核心是控制排查范围，不要一上来就怀疑应用代码。推荐按顺序执行：先确认外部网络与解析，再检查服务器资源，然后查阅应用日志，最后分析数据库状态。每一步都有明确判断依据后，再进行修复操作。建议把常用的检查命令和日志路径整理成一份速查清单，下次故障发生时可以直接对照执行，缩短中断时间，减少不必要的无效操作。
