网站无法访问怎么排查？从外到内定位故障根因
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b8f8101e7fc8.html
📄
网站突然打不开或响应极慢时，直接重启服务器往往治标不治本。故障可能藏在网络链路、域名解析、服务器资源或应用代码等不同层次里。按照从外部链路到内部服务、从表面现象到底层逻辑的顺序逐一筛查，能把排查时间压缩到最短，尽快恢复业务。
1. 先判断网络出口与域名解析状态
遇到访问异常，先别急着登录服务器。立刻换上手机流量访问站点，如果手机能打开而电脑不行，问题基本出在本地网络或设备缓存上。若是只有某个地区或某个运营商的用户打不开网页，就需要怀疑网络链路中断或CDN节点异常。
1.1 核对域名解析结果
在电脑命令行里执行nslookup 你的域名，查看解析出的IP是否与服务器实际地址一致。解析出旧IP或直接报错，通常意味着DNS记录被改错或者TTL缓存尚未刷新。此时登录域名服务商控制台，检查A记录和CNAME记录是否配置正确，同时留意CDN加速域名是否被误删或停用。
1.2 测试端口连通性
域名解析无误但页面依然打不开，就要验证端口是否对外开放。云服务器需到安全组或防火墙规则中确认80和443端口已放行。使用telnet 服务器IP 443命令做连通性测试，若提示连接失败或超时，说明防火墙策略或机房网络把请求挡在了门外。
2. 检查服务器资源余量与可疑进程
网页加载缓慢、频繁超时，多半是服务器资源耗尽所致。CPU持续满载、内存不足、磁盘被写满或带宽被打满，都会让新请求一直排队，最终表现为页面白屏或连接重置。登录服务器后，依次使用top、free -h和df -h三条命令，即可快速掌握资源现状。
2.1 找出异常消耗的进程
在top界面按大写P键按CPU占用率排序，重点观察长期盘踞前几名的进程。常见元凶包括服务器被植入挖矿木马、数据库查询语句缺少索引而被反复全表扫描、以及未做频率限制的采集程序疯狂抓取页面。请务必同步打开Web服务器日志，不少异常消耗都对应着高频访问的特定URL或UA标识。
2.2 留意磁盘与交换分区的隐患
磁盘使用率超过80%就应立刻处理。日志文件或临时目录占满分区后，网站可能因为无法写入会话文件直接爆出500错误。清理过期备份、压缩历史日志通常能立即缓解。同时关注free -h结果，如果swap占用持续攀升，说明物理内存已严重不足，系统性能会暴跌。此时重启只是临时手段，调整缓存参数或扩容内存才是正解。
3. 深入应用层追踪代码与日志线索
页面能打开但功能报错，或直接返回500、502等状态码，问题多半出在应用代码或运行环境上。打开浏览器开发者工具的Network面板，逐个观察请求响应状态：500表示应用内部逻辑异常，502表示网关与后端服务连接被切断，404则是路由地址或文件路径错误。
3.1 从错误日志中定位异常点
主流框架和内容管理系统都有完善的日志记录。PHP项目优先查看error_log文件；Java应用在Tomcat或Spring Boot的logs目录中寻找异常堆栈；使用Nginx时同时查看error.log，往往能直接看到某个上游服务不可用的明确提示。找出报错时间点对应的日志片段进行上下文分析，绝大多数代码级故障都能在这里找到线索。
3.2 关注依赖服务与外部接口
网站功能依赖的数据库、Redis缓存或第三方API一旦失效，也会引发大面积报错。执行ps aux | grep mysql确认数据库进程状态，再用简单查询语句测试连通性。如果业务调用了支付、短信等外部接口，到服务商控制台查看调用记录，确认是否因欠费、密钥过期或访问量超限被限制。
4. 应急预案与长期规避措施
完成排查后，还要做好两手准备：一方面制定快速回滚方案，另一方面从源头减少故障发生概率。把修复过程梳理成标准操作文档，方便下次遇到同类问题时按序处理。
4.1 常用避坑与快速止血做法
- 修改配置或发布代码前先备份原文件，多人协作时使用版本控制工具登记变更，方便随时回滚。
- 核心节点配置独立的监控告警，对CPU、内存、磁盘和响应时间设置阈值，异常触发即时通知，避免业务受损后才被动发现。
- 遇到疑似攻击或恶意抓取，优先在防火墙或Web服务层封禁对应IP段，再深入分析攻击方式。
5. 常见问题
5.1 网站能打开但图片全部加载不出来怎么办
先在图片链接上右键复制地址并单独打开，确认是404还是超时。如果是404，多半是文件路径更改或资源被误删；若是超时，检查防盗链设置、对象存储服务是否欠费或带宽是否已跑满。
5.2 重启服务器后网站恢复了，还需要继续排查吗
需要。重启只是释放了临时占用的资源，并没有消除根因。务必观察CPU、内存和进程日志，确认是否存在泄漏或异常进程，否则故障很快会复发且可能更严重。
5.3 排查时先看服务器还是先看代码
先快速分流。页面完全无法打开，优先看网络和服务器资源；页面能打开但个别功能报错，优先看应用日志和错误状态码。先判断故障层级，再决定深入的方向，能避免走弯路。
6. 总结
网站故障排查的本质是逐步缩小范围。先从网络和域名入手排除外部因素，再检查服务器资源与进程，随后深入应用日志和依赖服务，最后把修复经验沉淀为文档与监控策略。遇到宕机别慌乱，按这个顺序逐层过滤，绝大多数故障都能在短时间内定位并解决。建议你现在就检查一下监控告警是否配置完整，这是预防下次故障最值得投入的一步。
