从网络到数据库排查网站故障的完整操作指南
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ae71bc9294cd.html
📄
线上访问异常时，多数人的第一反应是刷新页面或重启服务，但这往往是低效的。有效的做法是沿着用户请求的完整链路，从外到内逐层定位问题。从域名解析、网络连通性开始，再到服务器资源、应用日志与数据库状况，只要按照清晰的顺序排查，通常能较快找到症结并恢复服务。
1. 先确认网络链路与域名解析是否正确
网站打不开，先不要动服务器，而是判断问题出在用户端还是服务端。一个很实用的做法是换用手机流量访问测试，如果正常，那多半是本地网络或设备的原因。如果只有特定区域或少数运营商用户反馈打不开，则要怀疑链路拥堵或解析未完全生效。
1.1 检查解析记录与返回的IP
在命令行输入 nslookup 你的域名，对比返回的 IP 是否与服务器公网地址一致。如果解析结果为空，或指向了已弃用的旧地址，说明 DNS 记录配置有误。此处要特别注意，修改解析后生效需要时间，几分钟到几小时都可能，同时还应检查 CDN 节点状态，防止部分区域回源请求失败。
1.2 验证端口连通性与防火墙规则
能 ping 通但网页无法打开，通常是端口受限。云平台的安全组和系统内部防火墙都要放行 80 和 443 端口。在本机执行 telnet 服务器IP 443，如果连接超时，基本可以判定是防火墙拦截或运营商限制。此时优先查看安全组入站规则，再检查 iptables 或 firewalld 配置。
2. 检查服务器负载与资源使用状况
页面响应缓慢或大量请求排队超时，常与资源耗尽有关。CPU 满载、内存不足、磁盘写满或带宽占满，都会拖慢服务。登录服务器后，用 top、free -h、df -h 这三条命令，能快速了解负载、内存和磁盘的整体情况。
2.1 定位资源消耗的大户
在 top 界面按 P 键按 CPU 排序，留意排名靠前的进程。常见异常来源有挖矿程序、缺少索引的慢查询、恶意爬虫的高频访问。配合 Nginx 或 Apache 的访问日志，能确认这些请求的具体来源。例如发现某个接口每秒被调用几百次，就可以通过限流或临时封禁来源 IP 来缓解。
2.2 防止磁盘写满与swap频繁交换
磁盘使用超过 80% 就要重视了，会话文件或日志写满后，程序无法创建缓存，往往直接返回 500。清理过期日志和临时文件通常能快速释放空间。内存方面，如果 free -h 显示 swap 读写频繁，说明物理内存吃紧，系统在内存与磁盘间反复交换，性能会断崖式下降，应先优化应用内存占用，再考虑扩容。
3. 深入应用日志定位后端服务异常
网络和资源都正常时，问题多半出在应用层。白屏、功能不可用或 5xx 报错，都要靠日志来找线索。先看 Nginx 的错误日志，能快速分辨是客户端问题、后端超时还是应用崩溃。
3.1 关注慢请求与超时设置
在访问日志中，如果某个接口的平均响应时间明显变长，就要注意上游服务的处理能力。排查时要确认 PHP 或 Java 等应用进程是否存活，以及进程数是否达到上限。此外，FastCGI 或代理的超时配置过短，也可能导致偶发性 502 错误，适当调大超时值往往能解决问题。
3.2 分析异常堆栈与依赖服务
应用报错时，查看应用自身的日志文件，重点看堆栈信息。如果是调用外部接口或服务失败，要检查依赖服务是否可用。同时，确认本机时间与 NTP 是否同步，时间偏差会导致某些安全认证和请求签名校验失败，这类问题在日志中并不明显。
4. 排查数据库连接与查询性能瓶颈
很多接口超时和页面卡顿，根源在数据库。先从连接数入手，如果连接数经常打满，应用侧可能存在连接未释放的问题。执行 show processlist 可以查看当前会话，观察是否有大量空闲连接或长期未提交的事务。
4.1 定位并优化慢查询
开启慢查询日志，收集执行时间超过阈值的语句。找到后使用 explain 分析执行计划，确认是否走了全表扫描或缺少合适的索引。解决措施通常是补充联合索引或改写查询逻辑。例如，一个对时间字段的范围筛选，如果统计结果不精确，可以考虑先缩小扫描范围。
4.2 注意锁竞争与主从延迟
长时间不结束的写操作，会导致行锁或表锁堆积，阻塞其他请求。观察是否存在大事务，比如批量更新时单次处理过多数据。读多写少的场景若用了主从架构，还要关注主从延迟，延迟过大时，刚写入的数据在从库查不到，会引发业务逻辑错觉。
5. 常见问题
5.1 问：先重启服务再排查可以吗？
不建议。重启只是暂时掩盖了问题，进程被拉起后，后续请求依旧会把系统推向故障状态。正确的做法是先收集当前状态下的日志和进程信息，便于事后分析，然后再针对性处理。
5.2 问：数据库连接数很快就满了怎么办？
优先检查业务代码里连接池的配置，包括最大连接数和空闲回收时间。同时排查是否有连接泄漏，比如异常时未归还连接。必要时可以临时调大数据库的最大连接数，但这只是过渡方案，根本措施仍在应用侧。
5.3 问：排查时最先应该看哪个日志？
推荐先看 Nginx 错误日志和访问日志，它们能快速判断请求是到达了服务器并正常返回，还是在网关层就被拦截。结合 HTTP 状态码，能缩小范围指向网络、后端程序还是数据库问题。
6. 结语
系统性地排查网站故障，能帮你避免反复重启和无目的的更改。建议平时就把服务器基础状态、关键日志路径，以及数据库的监控方式记录成文档。遇到线上问题时，按照网络、资源、应用、数据库的顺序逐步核对，并保留当时的现场信息，这会大大缩短恢复时间。
