网站故障排查指南：按层级定位系统问题根源
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6b94da93d314.html
📄
网站加载缓慢、页面白屏或接口频繁报错时，与其反复刷新或盲目重启，不如按照网络、服务器、应用代码再到数据库的顺序逐层筛查。这个纵向排查思路能显著缩短定位时间，避免在无关环节浪费精力。
1. 先从网络链路与域名解析入手
在动服务器之前，先判断故障是否出在客户端网络或域名解析环节。可以换用手机流量访问，或请不同地区的同事打开同一网址。如果换网后访问正常，问题多出在本机或本地局域网；若只有部分区域用户无法访问，则往往与骨干链路波动或DNS同步延迟有关。
1.1 核对解析记录与回源配置
使用nslookup或dig命令查看域名解析出的IP是否与服务器真实地址一致。解析为空或指向旧IP，常见原因是A记录被更改、CNAME配置有误，或TTL时间过长导致新记录未生效。需要登录域名控制台仔细比对记录值，并检查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带来异常流量。例如某接口被外部脚本高频请求，导致PHP进程数暴涨，日志中会留下该IP的大量记录，封禁即可恢复服务。
2.2 关注磁盘与内存预警信号
磁盘使用率超过80%就该引起重视。日志文件、临时目录或Session目录写满后，网站因无法写入数据而抛出500错误，清理过期日志和缓存一般能快速化解。内存方面，若free -h显示Swap占用持续偏高，说明物理内存吃紧，系统频繁在内存与磁盘间交换数据，性能会明显退化。此时应削减常驻进程，或考虑增加内存配置。
3. 深入应用代码与运行时日志
白屏、个别功能失效或返回500错误，根源常藏在应用代码或框架配置中。先查看应用日志中最近的报错堆栈，再确认配置文件是否被误改、依赖组件是否升级到不兼容版本。调试阶段可开启更详细的日志级别，记录请求参数和SQL语句，便于复现问题。
3.1 从错误日志定位异常拐点
打开运行日志或框架自带的调试文件，搜索fatal error或exception关键字，查看首次出现的时间点。对比该时间点前后的更改记录，往往能直接锁定是上线新代码、修改了环境变量，还是第三方服务不可用所引发。例如，某支付回调报错，日志显示签名验证失败，核查后发现是对接方更新了密钥但本地配置未同步，更新后即恢复正常。
3.2 理清调用链路与依赖关系
如果故障集中出现在某一业务模块，需顺着请求链路检查其依赖的外部服务、缓存或消息队列。可启用链路追踪工具或临时在关键方法入口输出耗时日志，判断耗时集中在调用自身逻辑还是等待下游响应。需要注意的是，若上游服务超时时间设置过长，可能导致大量请求线程被占用，继而拖垮整个应用。
4. 排查数据库状态与查询性能
当页面能打开但数据加载不出来，或后台列表操作非常缓慢时，问题大多出在数据库层面。先检查数据库连接数是否已达上限、主从复制是否延迟、以及是否存在大量慢查询。数据库无响应时，应用往往会报连接超时错误。
4.1 定位慢查询与锁表现象
开启MySQL慢查询日志，分析超过设定阈值（如1秒）的SQL语句。常见问题包括缺乏索引导致的全表扫描、复杂多表JOIN，以及字段类型隐式转换。同时，通过show processlist查看当前执行状态，若出现大量Waiting for table metadata lock，通常是有长事务未提交，阻塞了后续DDL操作，需找到对应会话将其终止。
4.2 避免连接池耗尽
数据库连接数被占满，多数是应用层未正确释放连接。排查应用配置中的连接池大小是否合理，并检查代码中是否有未关闭的ResultSet或Connection。建议为连接池设置合理的空闲回收时间，并在数据库侧限制最大连接数，以免个别异常应用拖垮整个数据库实例。
5. 常见问题
5.1 网站突然打不开，但手机流量访问正常，是什么原因？
这种情况多半是本地网络或DNS缓存问题。可尝试更换电脑的DNS为公共DNS（如223.5.5.5），或清空浏览器缓存后重试。若电脑能ping通域名但打不开网页，还需检查本机代理设置或hosts文件是否有残留记录。
5.2 服务器CPU持续100%，应该先做什么？
先登录服务器执行top查看占用CPU最高的进程ID，然后用ps -ef | grep 进程ID确认其路径。若为陌生脚本路径，优先考虑感染风险，应隔离进程并检查计划任务与开机自启项。若是正常业务进程，则需结合日志分析是访问量激增还是代码陷入死循环。
5.3 数据库连接池已满，应用一直超时，如何快速恢复？
可临时将应用无用的长连接改为短连接，并适当减小连接池的最大容量，以降低数据库压力。更根本的做法是重启应用释放残留连接，同时开启慢查询日志定位未关闭连接的操作。若为第三方监控工具占用，需单独调整其连接策略。
6. 总结
网站故障排查的本质是收缩范围：先区分是网络还是服务器，再区分是应用还是数据库。每次排查时，尽量从日志、监控数据和命令输出中找证据，而不是凭感觉重启服务。建议日常为关键指标（如CPU、磁盘、慢查询）配置告警，并保留最近的变更记录，这样故障来临时就能按图索骥，用最短时间恢复线上服务。
