网站打不开的排查步骤：从域名解析到应用日志定位故
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /17f126926c3d.html
📄
网站出现打不开、白屏或接口报错时，与其反复刷新页面或者急着重启服务器，不如按照清晰的流程逐层排查。故障的根源往往集中在网络链路、服务器资源、应用代码以及数据库配置这几个环节，理清排查顺序再动手，通常能更快恢复线上服务，减少对用户的影响。
1. 先确认网络链路与域名解析是否正常
当站点无法访问时，应优先检查网络层，而不是立刻去动服务器。要判断问题出在用户端还是服务端，可以尝试更换访问方式。例如用手机移动数据而不是公司网络访问，如果恢复正常，多半是本地网络缓存或设备设置出了问题。如果只有特定区域或某个运营商的用户反映打不开，那么重点怀疑链路拥堵或域名解析未生效。
1.1 核对解析记录与实际返回地址
在本地命令行中输入nslookup 你的域名，检查解析出来的IP与服务器真实公网地址是否一致。如果解析结果为空，或者指向了已经停用的旧IP，通常是控制台里的A记录或CNAME配置不正确。修改解析记录之后，全网生效需要等待一段时间，从几分钟到几小时不等。同时也要确认是否因为CDN节点异常，导致部分地区回源请求失败。
1.2 测试端口连通情况与防火墙策略
能ping通服务器却打不开网页，一般不是服务器宕机，而是端口没有对外开放。云服务商的安全组和服务器自身的防火墙都需要同时放行80和443端口。在本机执行telnet 服务器IP 443，如果提示无法连接或者超时，基本可以判断为防火墙拦截或者运营商封禁。这时优先检查安全组规则，再核对服务器内部的防火墙配置。
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状态码，问题核心大概率在应用层。打开浏览器开发者工具的Network面板，观察具体接口的请求状态和返回内容。如果某个接口返回500或502，就要去后端应用日志里找对应的异常堆栈。常见的错误类型包括数据库连接超时、第三方服务调用失败、代码中未捕获的空指针异常等。
3.1 定位具体的异常堆栈信息
查看应用日志时，不要只盯着最后几行，要结合报错时间点前后的上下文。比如Java服务可以看catalina.out或业务日志，Python服务看gunicorn或uwsgi的日志输出。找到异常堆栈中的关键信息后，优先搜索项目代码中对应的类和方法，判断是逻辑错误还是依赖服务不稳定。如果是新上线代码后出现的故障，可以回滚到上一个稳定版本，先恢复服务再定位问题。
3.2 检查数据库连接与慢查询
很多接口超时与数据库有关。首先确认数据库服务本身是否正常运行，连接数是否已经打满。其次开启慢查询日志，找出执行时间超过1秒的SQL语句。缺少索引是慢查询最常见的原因，可以通过explain命令查看执行计划，确认是否走了全表扫描。另外，连接池配置过小也会导致请求排队等待，适当调大最大连接数通常能缓解这类问题。
4. 关注第三方依赖与外部服务调用的稳定性
如今的业务系统很少独立运行，往往依赖短信平台、支付接口、对象存储等外部服务。如果这些服务出现波动或限流，也会导致网站部分功能不可用。排查时可以尝试直接调用第三方接口的测试地址，看能否正常返回。同时检查调用第三方服务时的超时设置，如果超时时间太长，会导致线程被长时间占用，最终拖垮整个应用。
4.1 验证外部服务的可用性状态
第三方服务的健康状态页面通常会显示近期是否有故障报告。如果确认是外部服务的问题，可以暂时切换到备用服务商，或者在代码中增加降级逻辑，比如缓存上次的响应结果，避免因单个外部服务不可用而导致整个功能崩溃。
5. 常见问题
5.1 网站打不开时，应该先重启服务器还是先排查问题？
不建议立即重启服务器，因为重启会清空内存中的临时状态，反而丢失了排查线索。先按网络层、系统层、应用层的顺序逐步检查，确认根因后再决定是否重启，否则问题很可能在重启后再次出现。
5.2 浏览器显示无法连接，但服务器却可以ping通，这是怎么回事？
这种情况通常是端口不通、防火墙拦截或者服务未启动。先检查80和443端口是否在监听，再用telnet测试端口连通性，同时确认安全组和服务器防火墙是否放行对应端口。
5.3 修改了域名解析记录，为什么半天还是打不开网站？
域名解析的生效时间受DNS服务器缓存和TTL设置影响，通常是几分钟到24小时不等。可以通过nslookup指定公共DNS（如223.5.5.5）查询来验证是否已生效，如果公共DNS已经返回新IP，说明只是本地缓存未刷新。
6. 结语
网站故障排查并不复杂，重点是建立清晰的排查顺序：先看网络层，再看系统层，最后深入应用层。建议把这些命令和判断标准整理成一份自查清单，遇到问题时按步骤执行，可以大幅缩短故障恢复时间。同时养成定期查看日志和监控指标的习惯，很多隐患可以在爆发前就被发现和处理。
