网站故障排查顺序：按层级定位问题根源
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /32d864169b53.html
📄
网站无法访问或响应迟缓时，与其反复刷新或盲目重启，不如按照从网络到数据库的顺序逐步排查。这种纵向逐层诊断的方式，能够快速缩小故障范围，精确定位问题环节，避免在无关区域浪费时间。
1. 先验证网络连通性与域名解析
在接触服务器之前，先判断问题是否源于客户端网络或域名解析环节。尝试切换手机移动数据访问网站，或请异地同事打开同一网址进行对照测试。如果更换网络后访问恢复正常，则问题多半出在本地网络；若仅部分区域用户无法访问，则可能与网络链路波动或DNS同步延迟有关。
1.1 核对解析记录与CDN配置
使用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 定位高CPU进程的成因
在top输出中按CPU占用率排序，重点关注排名靠前的进程。常见诱因包括：服务器被植入挖矿程序、数据库慢查询堆积，以及缺乏频率限制的爬虫攻击。结合Web访问日志，可进一步锁定产生异常请求的URL或IP。例如某接口遭外部脚本高频调用，导致PHP进程数量激增，日志中会留下该IP的大量访问记录，封禁后服务通常即可恢复。
2.2 关注磁盘与内存的预警信号
磁盘使用率超过80%就应引起重视。日志文件、临时目录或Session目录写满后，网站可能因无法写入数据而抛出500错误，清理过期日志与临时文件往往能迅速解决。内存方面，若free -h显示Swap交换分区使用率持续偏高，说明物理内存紧张，系统频繁在内存与磁盘间交换数据，导致整体性能下滑。此时应精简常驻进程，或考虑扩充内存配置。
3. 深入应用代码与日志定位问题
出现白屏、部分功能失效或500错误时，根源多位于应用代码或框架配置中。先查看应用日志中的最新报错堆栈，再核实配置文件是否被意外修改、依赖组件是否升级至不兼容版本。排查阶段可临时开启更详细的日志级别，以便捕获更多上下文信息。常见问题如PHP内存限制过低导致脚本执行中断、未捕获的异常未被记录、第三方API超时未设置合理的降级策略等，都可通过日志中的关键线索逐一排除。
3.1 对比近期变更缩小范围
若故障发生在代码部署或配置调整之后，优先对比变更内容。检查版本控制记录，确认是否有未合入的补丁、环境变量变更或数据库迁移脚本遗漏。回滚最近一次变更并观察恢复情况，是快速验证的有效手段。
4. 查数据库连接与查询性能瓶颈
当应用能正常显示但部分页面加载缓慢，或出现数据库连接超时提示，需要将注意力转向数据库。首先确认数据库服务正常运行，连接数是否达到上限。执行show processlist查看当前活跃查询，找出长时间运行的SQL语句，这些通常是性能瓶颈的来源。缺少索引、数据量增长后旧查询计划失效、锁等待过多，都是常见诱因。
4.1 化慢查询与索引结构
开启慢查询日志，收集执行时间超过阈值的语句。针对高频慢查询，检查explain执行计划，确认是否走全表扫描或索引失效。合理增加复合索引、调整查询条件顺序，往往能显著降低响应时间。
4.2 检查连接池与并发限制
应用连接池配置过小，或数据库最大连接数设置不足，高并发场景下会导致请求排队甚至拒绝服务。核对连接池的初始大小、最大容量及等待超时时间，并关注数据库端max_connections参数，按实际业务峰值预留适当余量。
5. 常见问题
5.1 网站完全打不开，先检查哪里？
先做网络对照测试，切换移动网络访问，若正常则问题在本地网络或DNS缓存。随后检查域名解析是否指向正确IP，再确认80/443端口在防火墙中放行。
5.2 服务器CPU一直100%，该如何处理？
使用top命令定位高占用进程，结合访问日志判断是否为恶意爬虫或挖矿程序。若为正常业务请求，需增加限流或优化代码逻辑；若为异常进程，立即终止并加固安全策略。
5.3 数据库响应很慢，可能的原因有哪些？
常见原因包括慢查询缺乏索引、连接数打满、锁竞争激烈或硬件资源不足。建议开启慢查询日志，结合执行计划分析瓶颈，并检查连接池配置是否合理。
6. 结语
网站故障排查的关键在于按层级逐层缩小范围，从网络、服务器、应用到数据库依次推进，每个环节都依托命令行工具和日志数据做出判断，而非盲目猜测。建议在日常运维中记录常见故障的处理步骤，形成团队内部的排查手册，提升问题解决效率，缩短业务中断时间。
