网站故障排查步骤：从网络链路到数据库逐层定位
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f3a81ee11ccf.html
📄
线上站点突然白屏、接口超时或响应卡顿，与其反复刷新页面或盲目的重启服务，不如顺着请求的流转路径逐层排查。问题的根源往往隐藏在链路解析、服务器资源、应用进程与数据库配置这几环当中。先把排查顺序理顺，再针对性下手，才能更快恢复服务，把对用户的影响降到最低。
1. 先排查网络链路与域名解析
站点打不开时，第一步不是动服务器，而是先判断问题出在用户侧还是服务侧。一个有效的验证方式是切换访问环境：用手机流量代替办公网络访问，如果恢复正常，多半是本地网络缓存或设备设置的问题；如果只有某个地区或特定运营商的用户反馈无法访问，就要重点怀疑链路拥塞或解析尚未全网生效。
1.1 核对解析记录与实际返回地址
在终端执行nslookup 你的域名，对比解析出的 IP 是否与服务器真实公网地址一致。解析结果为空或指向了已停用的旧 IP，通常说明控制台上的 A 记录或 CNAME 配置有误。需要留意的是，修改解析后全球生效需要时间，从几分钟到几小时不等。同时，也要确认 CDN 节点是否异常，避免部分地区的回源请求持续失败。
1.2 测试端口连通性与防火墙规则
能 ping 通服务器但网页无法打开，大概率是端口未对外开放。云服务商的安全组和服务器内部防火墙需同时放行 80 与 443 端口。在本机输入telnet 服务器IP 443，若提示连接超时，基本可以锁定是防火墙拦截或上游 ISP 限制。这时优先检查安全组入站规则，再排查 iptables 等本地策略。一个常见的坑是：只改了云控制台安全组，却忘了服务器内部的 firewalld 或 ufw 规则同样需要同步更新。
2. 检查服务器负载与关键资源占用
页面响应缓慢、大量请求排队超时，通常与服务器资源耗尽有关。CPU 持续跑满、内存告急、磁盘剩余空间不足或带宽被占满，都会直接拖慢在线服务的响应速度。登录服务器后，依次使用top查看负载与 CPU 占用、free -h查看内存状况、df -h检查磁盘余量，这组命令能快速评估系统整体健康度。
2.1 定位资源消耗的主要来源
在top界面按 P 键按 CPU 占用率排序，仔细检查排名靠前的进程。常见的异常消耗包括：被入侵植入的挖矿程序、缺少索引导致的慢查询堆积，以及恶意爬虫的高频抓取。交叉查看 Nginx 或 Apache 的访问日志，可以确认这些请求来自哪些 IP 和 URL。例如，发现某个接口每秒被调用数百次，就可以通过限制请求频率或临时封禁来源 IP 来缓解压力。这里有个判断标准：如果 CPU 占用高的进程名你完全不认识，先不要急着 kill，用 systemctl status 或 ps aux 查看它的启动路径和依赖关系，确认为异常进程后再做处理。
2.2 防范磁盘写满与交换分区波动
磁盘使用率超过 80% 就应该引起警觉。会话文件、运行日志或临时目录写满后，程序无法正常创建缓存，通常会直接抛出 500 错误。清理过期日志和临时文件，往往能迅速释放空间。内存方面，若free -h显示 swap 分区读写频繁，说明物理内存严重不足，系统在内存与磁盘之间频繁换页，整体性能会急剧下降。此时应优先优化应用的内存占用，比如减少 PHP-FPM 的进程数或调整 Java 堆大小，必要时再考虑扩容。
3. 深入应用日志与后端进程状态
当网络和资源层面都正常，问题往往出在应用本身。页面白屏、特定功能不可用或接口返回 5xx，都需要结合日志来定位。查看 Nginx 错误日志（通常在 /var/log/nginx/error.log）能发现不少线索：比如常见的 Connection reset by peer 往往意味着后端进程崩溃或被强制杀掉。systemctl status 应用服务名可以快速查看进程是否还在运行，如果显示 exited 或 failed 状态，就要根据日志中的具体报错来修复。
3.1 从慢请求日志入手定位瓶颈
如果日志里反复出现超时记录，建议开启慢查询日志或请求耗时日志。例如在 Nginx 配置中启用 $request_time 变量记录耗时，再配合 PHP-FPM 的 slow log 设置，就能锁定是哪个接口拖慢了整体响应。一个典型场景是：某列表页接口耗时超过 10 秒，而日志显示慢操作全部集中在一个字段的模糊查询上，那就说明问题基本出在数据库查询环节。
4. 最终排查数据库状态与查询效率
前端页面能打开，但登录、提交订单或查询列表等操作一直转圈，多数情况下问题出在数据库。数据库连接数打满、大量慢查询堆积或死锁发生，都会导致应用等待数据返回而卡住。
4.1 检查连接数与活跃会话
登录数据库执行show status like 'Threads_connected'，对比 max_connections 配置值。如果连接数长期接近上限，说明存在连接未被正常释放的情况，比如代码里没有关闭连接池的闲置链接。使用 show processlist 查看当前执行的语句，如果发现同一 SQL 反复出现且 State 列显示 Waiting for table metadata lock，多半是有事务未提交导致的锁等待，找到对应会话并 kill 掉即可缓解。
4.2 化慢查询与索引策略
开启慢查询日志后，重点看那些扫描行数远大于返回行数的 SQL。执行explain 对应SQL，如果看到 type 列为 ALL 或 rows 数值巨大，说明没有命中合适的索引。一个典型的优化案例：某订单查询接口因 where 条件里的 create_time 字段缺少索引，高峰期每次扫描几十万行数据，加上复合索引后耗时从 3 秒降到了 50 毫秒。需要注意，索引不是越多越好，每个额外的索引都会拖慢写入速度，建议针对高频查询的 where 和 order by 字段来添加。
4.3 注意主从延迟带来的数据不一致
如果架构里有读写分离，还要留意主从同步延迟。刚写入的数据在从库查不到，往往就是同步没跟上。show slave status 中 Seconds_Behind_Master 数值较大时，说明从库处理压力过高或网络传输异常。此时可以考虑临时将读请求切回主库，并检查从库的硬件负载是否足够。
5. 常见问题
5.1 问题一：重启服务器后网站依然无法访问，还要检查什么？
重启后仍无法访问，建议先确认服务是否已随系统自启动。使用 systemctl enable 设置开机自启，同时检查数据库和中间件是否都正常拉起。另外，也要留心是否因为重启导致某些临时文件或 socket 文件丢失，比如 Redis 未配置持久化时，重启后缓存数据全部丢失也会引发异常行为。
5.2 问题二：排查了很久没头绪，最快的定位方法是什么？
最快的办法是分类排除：先从浏览器开发者工具的 Network 面板看请求是否发出、返回什么状态码，再顺着这条链路往后查。如果请求根本没到达服务器，问题在网络层；如果到达了但返回 502 或 504，重点看 Nginx 和后端应用进程；如果返回 500，则要优先翻应用日志和数据库慢查询记录。按这个顺序逐步缩小范围，比随机尝试效率高得多。
5.3 问题三：日志中出现大量 Connection reset by peer 是什么原因？
这类报错通常有几个常见来源：后端应用进程超时被杀掉、防火墙或安全组主动断开了连接、本地运行了负载均衡且健康检查间隔过短。建议先查看这一时间段的日志是否有 OOM（内存溢出）记录，再配合 top 观察进程是否频繁重启，逐一排除即可。
6. 总结
网站故障排查的本质是缩小范围、确认边界，而不是盲目尝试。建议按"链路解析 → 服务器资源 → 应用日志 → 数据库状态"的顺序依次排查，每到一个环节先问一句：这个环节有没有可能造成当前症状？同时，日常就做好三类储备：一是维护好常用命令清单，二是定期检查磁盘与日志目录的清理策略，三是为关键接口提前开启慢查询和访问日志。这样等真正出问题时，你已经有足够的数据来判断原因，恢复速度也会快很多。
