网站故障排查顺序，从网络到数据库逐层定位问题根源
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /94e2ba370d1c.html
📄
网站出现访问缓慢、页面白屏或接口频繁报错时，许多人习惯反复刷新浏览器，或者直接重启服务，但这样往往只能暂时缓解，问题很快又会重现。更高效的做法是沿着网络链路、服务器、应用代码到数据库的顺序，逐层排查并缩小范围，这样既能缩短故障时间，也能避免在做无用功时耽误正事。
1. 先确认网络链路与域名解析是否正常
在动服务器之前，先弄清故障到底发生在客户端网络，还是域名解析环节。最简单的办法是切换网络环境，比如用手机流量访问，或者请其他地区的同事打开同一个网址。如果换网络后访问恢复正常，问题多半出在本机或本地网络；如果只有特定区域的用户打不开，则很可能与骨干链路不稳定或DNS解析同步延迟有关。
1.1 核对域名解析记录与实际IP
在命令行执行nslookup或dig，对比解析出的IP与服务器真实地址是否一致。解析结果为空，或者仍指向旧IP，通常说明A记录或CNAME记录被改动过，也可能是TTL设置过长导致新记录尚未生效。此时需要登录域名管理后台逐项检查记录，同时确认CDN回源配置是否正确。个别地区无法访问，常见原因是CDN节点缓存了过期源站信息，清缓存或等待CDN重新回源即可。
1.2 验证端口开放与连接状态
有时ping能正常通过，但浏览器始终打不开，多半是防火墙或安全组策略拦截了HTTP/HTTPS流量。云服务器用户应登录控制台，确认80和443端口已加入放行规则；再用telnet 服务器IP 443测试端口连通性，如果超时或拒绝，基本可以判断是防火墙拦截，也可能是运营商对特定端口做了限制，这时考虑更换端口或联系网络服务商。
2. 查看服务器资源消耗与进程负载
页面响应极慢或请求频繁超时，往往意味着服务器资源已接近极限。CPU持续满载、可用内存偏低、磁盘空间告急、出口带宽被占满，这些都会让请求排队等待，最终表现为卡顿甚至服务中断。通过top、free -h和df -h三个命令可以快速掌握系统实时状态，定位资源瓶颈。
2.1 识别高占用进程的来源
在top输出中按CPU占用率排序，重点观察排名靠前的进程。常见情况包括：服务器被植入挖矿脚本、数据库慢查询不断堆积，以及未做频率限制的网络爬虫。结合Web访问日志，可以进一步确认哪些URL或来源IP带来了异常流量。例如某接口被外部脚本高频请求，导致进程数暴涨，日志中会有该IP的密集记录，按此封禁即可恢复。
2.2 留意磁盘与内存的预警信号
磁盘使用率超过80%就应提高警惕。日志文件、临时目录或Session目录被写满后，网站会因无法写入数据而抛出500错误，清理过期日志和缓存通常能快速缓解。内存方面，如果free -h显示Swap占用持续偏高，说明物理内存紧缺，系统在内存和磁盘间频繁交换数据，性能会急剧下降，此时应减少常驻进程，或考虑补充内存配置。
3. 深入应用代码与运行时日志
白屏、部分功能失效或直接返回500错误，问题往往出在应用层。查看框架或语言运行时日志是第一步，比如PHP的error_log、Python的日志文件、Java的异常堆栈。若日志没有明显记录，就需要在关键执行路径中临时添加日志输出，缩小可疑代码范围。常见原因包括第三方接口超时未设置、内存溢出或代码中引入了无效的循环调用，修复后务必测试异常分支是否也被处理。
3.1 区分代码问题与配置问题
代码逻辑没问题时，还要检查框架配置与环境变量。比如.env文件指向了错误的数据库地址、缓存驱动配置异常，或者路径权限不匹配，都会引发线上故障。遇到升级或发布后立刻报错，优先对比变更内容，回滚上一版本验证，往往比逐行读代码更快。
3.2 留意服务间的调用超时
微服务或依赖外部API时，若调用方没有设置超时时间，一次下游故障可能拖垮整个请求链路。在代码中为每次外部调用明确设置超时阈值，并配置重试机制，但重试次数不宜过多，否则会放大并发压力。同时可以在网关层统一配置熔断与降级策略，避免单点故障波及全局。
4. 分析数据库性能与慢查询日志
接口响应慢但服务器和代码都正常，数据库往往才是症结所在。开启慢查询日志，观察执行时间超过阈值的SQL语句，检查是否缺少索引、锁竞争严重或数据量增长过快。在条件允许的情况下，用EXPLAIN分析执行计划，确认是否走了有效索引。
4.1 化索引与查询结构
对频繁出现在WHERE或JOIN条件中的字段加索引是常见做法，但要避免创建过多冗余索引。对于大表，使用分页代替一次性全量查询；对于复杂关联，考虑拆分为多次简单查询。示例：某列表页每次请求耗时3秒，定位发现核心查询没走索引，加上组合索引后耗时降至0.1秒，效果立竿见影。
4.2 应对连接数与缓冲池压力
当数据库连接数达到上限，新请求会被拒绝。适当调大连接池上限是一个方向，但更要排查是否存在连接泄漏；代码中每次查询都应正确关闭连接。平时关注InnoDB缓冲池命中率，如果频繁读取磁盘，说明缓冲池偏小，需要在配置中适当调高，并预留足够物理内存。
5. 常见问题
5.1 网站偶尔打不开，刷新几次又正常，是什么原因？
这种间歇性故障多与资源耗尽或请求超时有关。可能是某段时间并发过高，占满了所有可用连接，也可能是Redis或MySQL连接池被暂时占满。建议在日志中记录故障时刻的系统指标，并设置告警阈值，方便定位突发流量来源。
5.2 所有应用都正常，但CDN访问仍然缓慢，如何排查？
先绕过CDN直接访问源站，对比两者耗时。如果源站速度快而CDN慢，多半是节点缓存命中率低或某个边缘节点异常。尝试刷新全部缓存，并检查回源协议是否与源站匹配，比如源站只支持HTTP，而CDN回源用HTTPS，也会引发延迟。
5.3 数据库CPU经常冲到100%，但慢查询日志却没什么记录，为什么？
慢查询阈值设置过高会漏掉高频短查询。如果阈值是5秒，而大量查询耗时0.5秒，日志就看不到任何记录。将阈值调整为1秒以内，同时开启通用日志查看整体请求频率，也可以借助性能监控工具，找出占用CPU最多的SQL语句进行优化。
6. 总结
网站故障排查没有固定脚本，但顺着网络、服务器、代码到数据库逐层推进，能有效减少盲目操作。建议平时建立一份检查清单，记录每次故障的症状、定位过程和最终解决方案，遇到同类问题时直接对照执行，排查效率会明显提升。同时，为关键指标配置监控告警，在用户感知异常前提前介入，避免小问题演变成长时间宕机。
