网站故障排查顺序：从网络到数据库逐层定位问
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e130fc11d786.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状态码，问题核心大概率在应用层。打开浏览器开发者工具的网络面板，查看具体接口的响应时间与状态码，可以区分是后端处理慢还是前端渲染出错。同时登录服务器查看应用日志，通常能定位到报错的代码行和堆栈信息。
3.1 区分慢请求与错误请求
若接口返回200但耗时超过数秒，需关注代码中的循环、外部API调用或数据库查询效率。若出现大量502或504，则可能是网关超时或后端进程崩溃。Nginx日志中的upstream_response_time字段能直观反映后端处理耗时，配合应用日志中的异常堆栈，可快速锁定具体模块。
3.2 检查服务健康与进程状态
使用systemctl status或ps aux | grep 进程名确认应用进程是否存活。进程频繁退出重启，通常由内存溢出或配置错误引起。查看服务启动时间和重启次数，若多次自动拉起，说明存在持续崩溃循环。此时不应盲目增大重启上限，而应翻看日志找出崩溃的根本原因。
4. 聚焦数据库性能与连接配置
接口响应变慢但服务器资源正常时，数据库往往是主要嫌疑。慢查询、锁表、连接数耗尽或磁盘I/O瓶颈，都会拖垮整体服务。登录数据库管理工具，开启慢查询日志，查看查询耗时排名靠前的SQL语句。
4.1 定位慢查询与索引缺失
通过EXPLAIN关键字分析慢查询的执行计划，能明确是否缺少索引或发生了全表扫描。例如给查询频繁使用的where条件和order by字段添加复合索引，往往能显著降低查询耗时。同时定期执行ANALYZE TABLE更新统计信息，帮助优化器选择更优的执行路径。
4.2 检查连接数与锁等待
使用show processlist查看当前连接状态，若大量连接处于Sleep或Locked状态，需检查连接池配置是否过小，以及是否存在未提交的长事务。数据库锁等待严重时，业务请求会排队堆积，此时应优先定位锁源事务并评估是否终止，避免死锁扩大。生产环境建议设置合理的事务超时时间和最大连接数，并定时巡检。
5. 常见问题
5.1 Q1：刷新页面后偶尔能打开，偶尔白屏，这是什么原因？
这类间歇性故障多与资源达到临界点有关，例如CPU或内存处于高水位，请求量大时部分进程被杀死或超时。可重点观察负载趋势和错误日志出现的时间点，同时排查单点进程是否存在内存泄漏，建议配合监控工具记录峰值时段的数据变化。
5.2 Q2：更换DNS后，网站长时间无法访问，如何判断生效情况？
不同地区运营商对DNS缓存刷新速度不一，通常需要24到48小时完全生效。可借助公共DNS（如223.5.5.5）或第三方解析检测平台查询不同地域的解析状态。若解析已更新而网站仍无法访问，则需从CDN回源和防火墙规则继续排查。
5.3 Q3：数据库连接池调大后，数据库CPU反而飙升，怎么处理？
连接池过大意味着同时活跃的连接大幅增加，会加重数据库的上下文切换和锁竞争。建议按实际并发量反向调节，逐步缩小连接池并观察响应时间，同时配合数据库侧限制最大连接数，避免资源被异常请求拖垮。
6. 总结
网站故障排查不必从底层往上层盲目尝试，按照网络、服务器、应用、数据库的顺序逐层递进，能显著缩短定位时间。日常运维中，建议提前配置告警规则和核心指标监控，提前备份配置文件和关键日志，并建立一份故障排查清单。线上问题发生时按清单执行，既能减少慌乱中的误操作，也能尽早恢复服务，将损失控制在最小范围。
