网站故障排查指南：按链路到数据库逐层定位问
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2ac304eaa92e.html
📄
线上网站出现白屏、加载缓慢或接口频繁报错时，与其反复刷新页面或盲目重启服务，不如沿着请求的流转路径逐层排查。问题的根源往往潜伏在网络链路、服务器资源、应用进程和数据库配置这几大环节中。理清排查的顺序，再针对性地操作，能够更快恢复线上服务，降低对用户的影响。
1. 先验证网络链路与域名解析状态
站点无法访问时，第一步不是动服务器，而是先判断问题是出在用户侧还是服务侧。一个实用的判断方法是切换访问方式：用手机流量代替办公网络访问，如果恢复正常，多半是本地网络缓存或设备设置的问题；如果只有某地区或特定运营商的用户反馈打不开，则需要重点怀疑链路拥塞或域名解析尚未全球生效。
1.1 核对解析记录与实际返回地址
在终端执行nslookup 你的域名，对比解析出的 IP 是否与服务器真实公网地址一致。解析结果为空或指向了已停用的旧 IP，通常说明控制台上的 A 记录或 CNAME 配置存在偏差。需要留意的是，修改解析后全球生效需要时间，从几分钟到几小时不等。同时，也要确认 CDN 节点是否异常，避免部分地区回源请求持续失败。若发现解析到旧地址，可在服务商控制台核对记录并修正，并耐心等待生效。
1.2 测试端口连通性与防火墙策略
能 ping 通服务器但网页无法打开，大概率是端口未对外开放。云服务商的安全组和服务器内部防火墙需同时放行 80 与 443 端口。在本机输入telnet 服务器IP 443，若提示连接超时，基本可锁定是防火墙拦截或上游 ISP 限制。此时优先检查安全组入站规则，再排查 iptables 等本地策略。避坑提示：修改安全组后，记得在服务器内用systemctl status firewalld确认防火墙状态，避免误伤正常端口。
2. 检查服务器负载与关键资源占用
页面响应缓慢、大量请求排队超时，通常与服务器资源耗尽相关。CPU 持续跑满、内存告急、磁盘剩余空间不足或带宽被占满，都会直接拖慢在线服务的响应速度。登录服务器后，依次使用top查看负载与 CPU 占用、free -h查看内存状况、df -h检查磁盘余量，这组命令能快速评估系统整体健康度。
2.1 定位资源消耗的主要来源
在top界面按 P 键按 CPU 占用率排序，仔细检查排名靠前的进程。常见的异常消耗包括：被入侵植入的挖矿程序、缺少索引导致的慢查询堆积，以及恶意爬虫的高频抓取。交叉查看 Nginx 或 Apache 的访问日志，可以确认这些请求来自哪些 IP 和 URL。例如，发现某个接口每秒被调用数百次，就可以通过限制请求频率或临时封禁来源 IP 来缓解压力。判断标准：若 CPU 占用率持续超过 90% 且进程异常，应立即停止相关服务并备份日志。
2.2 防范磁盘写满与交换分区波动
磁盘使用率超过 80% 就应该引起警觉。会话文件、运行日志或临时目录写满后，程序无法正常创建缓存，通常会直接抛出 500 错误。清理过期日志和临时文件，往往能迅速释放空间。内存方面，若free -h显示 swap 分区读写频繁，说明物理内存严重不足，系统在内存与磁盘之间频繁换页，整体性能会急剧下降。此时应优先优化应用的内存占用，如调低缓存上限，必要时再考虑扩容内存。
3. 深入应用日志与后端服务运行状态
当网络和资源层面都正常，问题往往出在应用本身。页面白屏、特定功能不可用或接口返回 5xx，都需要结合日志来定位。查看 Nginx 错误日志和业务应用日志是关键步骤，通常位于/var/log/nginx/error.log或应用自定义路径。关注日志中的报错码和堆栈信息，能快速缩小问题范围。
3.1 定位 5xx 错误的触发条件
若日志中频繁出现502 Bad Gateway，可能是后端进程崩溃或超时；504 Gateway Timeout则暗示请求处理时间过长，往往是数据库查询慢或依赖服务无响应。实际操作时，可先重启应用服务观察是否恢复，但要注意记录重启前的日志，避免丢失现场。避坑建议：不要直接重启所有服务，应逐个进程排查，优先处理报错频率最高的模块。
3.2 验证相关依赖服务的健康状态
应用可能依赖缓存服务如 Redis、消息队列或外部 API。若这些依赖失效，应用会表现为响应迟缓或功能缺失。使用redis-cli ping检查缓存连通性，或通过监控工具查看依赖服务的延迟指标。判断标准：若依赖服务恢复后问题随即消失，可确认是核心链路中的瓶颈点，后续应增加冗余或超时保护。
4. 核查数据库连接与查询性能
如果应用日志显示查询超时或连接池满，问题根源大概率在数据库端。数据库负载过高、锁等待或 SQL 执行效率低下，都会拖垮整个服务。进入数据库命令行，执行SHOW PROCESSLIST;查看当前会话，能直观看到卡住的查询和锁状态。
4.1 定位慢查询与索引缺失
开启慢查询日志，例如在 MySQL 中设置slow_query_log=ON并设定阈值，再分析慢查询记录，找出执行时间远超预期的 SQL。常见原因是未走索引或数据量过大。例如，一张百万行记录的表进行全表扫描，响应时间可能高达数秒。为高频查询的字段添加索引，往往能显著提升速度。注意索引不宜过多，每次写入都会额外开销，控制在核心查询范围内。
4.2 处理连接池耗尽与锁竞争
连接数打满时，新请求会排队等待，表现为接口长时间无响应。检查max_connections设置，并核对应用侧连接池大小，两者需匹配。若请求量正常但连接仍耗尽，可能存在死锁或长事务。在SHOW PROCESSLIST中查看 State 列为Lock的会话，关联表和 SQL 可追溯锁来源。优化建议：将大事务拆分为小事务，减少锁持有时间，必要时调整隔离级别。
4.3 预防主从延迟造成的读异常
使用读写分离架构时，主从延迟会导致刚写入的数据读取不到。检查SHOW SLAVE STATUS输出中的Seconds_Behind_Master值，若持续增大，说明从库同步滞后。这会引发用户看到不一致数据或报错。临时解法是将关键读请求强制路由到主库，长远则需优化复制配置或升级从库硬件。
5. 常见问题
5.1 排查时先看哪一层最有效？
先看网络连通性，再逐层向上。因为网络问题最易验证且成本低，能快速排除用户侧因素。确认域名解析和端口通断后，再转向服务端资源，减少无效操作。
5.2 重启服务后问题复现，该怎么办？
不要急着重启，先保存完整日志和状态快照。复现问题后，记录报错时间点，结合日志和监控数据回溯，定位触发条件。例如，若每次并发升高才报错，则需优化连接池或加缓存。
5.3 常见故障中有哪些可提前预防？
磁盘写满、连接池耗尽和慢查询是可以预判的。设置磁盘使用率和连接数的告警阈值，定期审查慢查询日志，并为关键表建立合理索引，能显著减少突发故障概率。
6. 总结
网站排查不是碰运气，而是按顺序走一遍请求链路。从域名解析和端口连通性入手，再到 CPU、内存和磁盘资源，接着看应用日志与依赖服务，最后深挖数据库的索引和锁状态。建议你将这些步骤整理成一张清单，并在每次故障后记录根因和修复动作。这样下次出现同类问题时，即可按图索骥，缩短服务中断时间。
