网站故障排查顺序：从网络到数据库逐层定位问
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /76013e05ac7d.html
📄
网站访问缓慢、页面白屏或接口频繁报错时，与其反复刷新页面或盲目重启服务，不如按照从外到内的顺序逐层排查。故障源头通常集中在网络链路、服务器资源、应用代码和数据库配置这几个环节，理清排查路径后再动手，往往能更快恢复线上服务，将故障对用户的影响降到最低。
1. 先排查网络链路与域名解析
网站无法访问时，先从网络层面入手，不要急于重启服务器。要判断问题是出在用户侧还是服务侧，最简单的方法是切换网络环境进行验证。用手机移动数据而非办公室Wi-Fi访问，如果能正常打开，多半是本地网络缓存或路由器设置的问题；如果只有特定地区或某个运营商的用户反馈打不开，则要重点怀疑链路拥塞或域名解析尚未生效。
1.1 核对解析记录是否正确
在本地电脑打开命令行，输入nslookup 你的域名，查看解析出的IP地址是否与服务器公网IP一致。如果解析结果为空，或者指向一个已经停用的旧地址，通常是云控制台上的A记录或CNAME配置有误。修改解析记录后，全球生效需要时间，短则几分钟，长则数小时。另外也要确认CDN节点是否正常，避免部分区域的回源请求失败。
1.2 测试端口连通性与防火墙放行
能ping通服务器却打不开网页，通常不是机器宕机，而是端口没对外开放。云服务商的安全组和服务器内部防火墙都需要同时放行80和443端口。在本地执行telnet 服务器IP 443，如果提示连接超时或无法连接，基本上可以锁定为防火墙拦截或运营商封禁。此时优先检查安全组入方向规则，再核对服务器内的iptables或firewalld配置。
2. 检查服务器负载与资源占用
页面响应变慢、请求大量超时，多数与服务器资源吃紧有关。CPU持续满载、内存耗尽、磁盘剩余空间不足或带宽被打满，都会导致请求排队，表现为服务卡顿甚至短暂中断。登录服务器后，依次执行top查看负载和CPU占用，接着用free -h查看内存情况，再用df -h检查磁盘余量，这一组命令能快速摸清系统层面的健康状况。
2.1 定位资源被谁占用
在top输出界面按下P键按CPU占用率排序，重点关注排名靠前的进程。常见的异常消耗原因包括：服务器被入侵后植入的挖矿程序、缺少索引的慢查询堆积，以及恶意爬虫的高频抓取。交叉查看Nginx或Apache的访问日志，可以确认这些请求具体来自哪些IP和URL路径。例如发现某个接口每秒被调用几百次，通过限制请求频率或封禁来源IP就能快速缓解压力。
2.2 警惕磁盘写满与内存交换
磁盘使用率超过80%时就需要介入处理。会话文件、日志或临时目录写满后，程序无法正常创建缓存，往往直接抛出500错误。清理旧的轮转日志和临时文件，通常能立即释放可用空间。内存方面，如果free -h显示swap分区读写频繁，说明物理内存严重不足，系统在内存与磁盘之间不断换页，整体性能会急剧下降。此时应优化程序的内存占用，必要时考虑扩容内存配置。
3. 分析应用日志与后端服务状态
页面白屏、部分功能不可用或直接返回5xx状态码，问题核心大概率出在应用层。打开浏览器开发者工具的Network面板，确认具体是哪个请求失败，记录下状态码与响应时间，再前往服务器端查看对应的应用日志。不要只盯着错误堆栈最后几行，更值得关注的是报错时间点前后发生的事件，例如是否有新版本刚发布、某个上游接口恰好超时、或配置文件被改动过。
3.1 关注各类常见返回码
502通常说明网关无法从上游获得有效响应，可能是后端进程崩溃或端口未监听，先检查PHP-FPM或Java进程是否存活；504代表上游处理超时，排查慢查询或外部接口调用是否无响应；499则表明客户端在服务端返回结果前主动断开，往往与持续请求等待时间过长有关。每类状态码背后都有对应的排查方向，结合日志能更快定位到具体模块。
3.2 灵活使用日志定位与临时降级
日志文件开启trace级别可以记录更细粒度的请求链路，但生产环境不宜长期开启以免增大磁盘压力。对于偶发性故障，临时提高日志级别并持续观察一段时间，比漫无目的地翻历史日志更高效。如果确认是某个第三方服务超时拖垮了接口，可以先把下游调用改为异步处理，或者设置更短的连接超时时间，避免请求被长时间挂起从而占用大量连接资源。
4. 深挖数据库连接与慢查询
当网络、服务器和应用层都未发现明显异常，接口却依然卡顿或报错，就要把注意力放到数据库上。数据库连接数被打满、慢查询堆积或锁等待时间过长，都会让后端服务看起来像"卡死"一样，表现为请求排队越来越大，最终大面积超时。先通过show processlist查看当前所有会话，观察是否存在大量状态为Waiting for table metadata lock或Copying to tmp table的线程。
4.1 定位慢查询并分析执行计划
开启慢查询日志，设定超过500毫秒或1秒的阈值，持续收集一段时间后进行分析。对筛选出的慢SQL执行explain，重点看type列是否从ref或range变成了all全表扫描，以及rows预估行数是否符合实际数据量。常见的修复方式是增加联合索引、改写子查询为关联查询，或者把复杂统计任务搬到离线数仓。值得注意的是，线上环境添加索引需要谨慎操作，在低峰期执行并监控锁等待时间与临时表空间变化。
4.2 管理连接数与主从延迟
数据库连接池上限设置过小，在业务流量突增时容易导致连接被占满，新请求只能排队等待。建议调整连接池的minimum-idle与maximum-pool-size参数，并同步检查应用端是否在每次请求后正确归还连接，出现连接泄漏时需结合监控逐步排查。另外，读写分离架构中如果主从延迟偏大，刚写入的数据读取不到会引发业务报错，可以先让核心接口强制走主库，并优化大事务的拆分逻辑，将延迟降到可接受范围内。
5. 常见问题
5.1 网站排查时先看日志还是先看监控指标？
建议先看监控大盘中的整体指标（CPU、内存、出入带宽、请求成功率），快速判断是全面故障还是局部故障，再根据异常链路翻看对应日志。监控负责提供方向，日志负责给出细节，两者结合才能既快又准地解决问题。
5.2 服务器重启后问题暂时消失，之后还会复现，怎么办？
这多半说明问题根源没有被移除，例如定时任务在特定时间抢占资源、内存缓慢泄漏或是前端缓存过期时间设置不合理。重启只是临时掩盖症状，应持续观察重启前后的资源曲线和日志特征，挖掘周期性规律，针对根因做结构性修复，而不是反复依赖重启。
5.3 排查时手上没有专业监控平台，有哪些轻量替代方案？
可使用系统自带命令组合，比如结合top、free、iostat和sar做基础采集，再配合开机自启脚本把关键指标定期写入日志文件。应用层可借助Nginx自带访问日志统计响应耗时，数据库则依靠慢查询日志与show status进行抽样观察。这些方式虽不如专业平台直观，但足够支撑日常的故障定位工作。
6. 总结
网站故障排查的核心原则是分清主次、逐层深入，先网络再服务器，后应用再数据库，每一步都用可量化的命令和日志来佐证判断，避免盲目操作。建议日常养成记录关键基线的习惯，比如平时接口平均响应时间、数据库连接数峰值、磁盘占用增长速率等，一旦出现异常便能快速找到偏移量。故障发生时保持冷静，按既定路径推进，能最大限度缩短恢复时间。
