网站无法访问排查顺序，从网络到数据库层层定位
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7c29825ffa3f.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错误，根源多存在于应用代码或框架配置中。先查看应用日志最新报错堆栈，再核对配置文件是否被意外改动、依赖组件是否升级到不兼容版本。排查时可临时开启详细日志记录，以便捕获更完整的错误上下文。一个常见案例是部署时漏传某个类文件，导致接口全部返回404，结合日志中的文件路径提示能迅速定位。
3.1 检查框架配置与依赖变更
代码未改动却突然报错，多半是配置或环境变化引起。检查数据库连接串、缓存服务地址、密钥文件等是否被误修改，以及近期是否有人执行过依赖更新。比如PHP版本从7.4升级到8.0后，某些旧函数被移除，代码中未兼容的部分便会触发致命错误，回滚版本或修正代码即可解决。
3.2 利用错误日志缩小故障范围
应用日志是排查问题的关键线索。根据时间戳筛选出故障发生前后的记录，重点关注ERROR或WARNING级别的堆栈信息。很多框架会输出具体文件和行号，直接指向出错位置。若日志量大，可先按接口或模块过滤，再逐条分析，通常能明显缩短定位时间。
4. 深入数据库层面排查慢查询与锁表
当网络、服务器和应用都正常，但页面仍出现加载缓慢或部分功能异常，问题很可能在数据库层。登录数据库执行show processlist，查看当前是否存在长时间未完成的查询或大量锁等待。慢查询日志能帮助识别执行时间过长的SQL语句，进而判断是否需要补充索引或优化查询逻辑。锁表则多因长事务未提交或批量更新操作引发，找到阻塞源头并处理即可恢复。
4.1 检查连接数是否被耗尽
数据库连接池被占满时，新请求会排队等待，甚至直接超时。查看数据库的最大连接数配置与当前活跃连接数，若接近上限，需要排查是否有连接泄漏，即代码中未正确释放连接。调整连接池大小或优化代码逻辑，可避免此类瓶颈反复出现。
4.2 验证主从同步状态
使用读写分离架构时，从库同步延迟会造成数据不一致，表现为刚提交的内容读不到。执行show slave status检查同步进程是否正常，重点关注延迟秒数。若延迟持续增加，可能是从库性能不足或网络带宽受限，适当提升硬件或优化同步机制能有效缓解。
5. 常见问题
5.1 网站打不开应该先做什么检查
建议先做网络层排查：切换移动网络访问网站，或让异地用户协助测试，同时确认域名解析是否指向正确IP。通过简单对照即可剔除本地网络或DNS的干扰因素。
5.2 服务器负载不高为什么网站仍然很慢
资源空闲时仍响应缓慢，应关注应用层与数据库层。检查是否存在慢查询语句、索引缺失或锁等待，同时查看应用是否有阻塞调用，如请求外部接口超时未设限制。逐层捕获调用耗时，才能定位真实的性能瓶颈。
5.3 接口偶发报错如何有效追踪
偶发问题最需要依靠日志。开启完整的请求日志与错误堆栈记录，记录每次报错的时间、参数和返回信息，并关联服务器与数据库日志，对比故障时间点的上下文。将日志输出到集中式日志平台，更便于检索与分析。
6. 总结
网站故障排查遵循从网络到数据库的纵向思路，能在最短时间内缩小范围。遇到问题时，先做外部对比测试，再逐步向内检查服务器资源、应用日志与数据库状态。平时重视日志留存和监控告警，许多故障在爆发前就能提前发现，明显减少突发停机带来的影响。
