网站打不开的排查顺序：从域名解析到应用日志逐层定位
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /42ca7ad471ea.html
📄
当网站突然卡顿、白屏或接口持续报错时，与其反复刷新页面或草率重启服务器，不如顺着一条清晰的排查路径逐层推进。故障的根源往往不在表面，而是藏在网络链路、服务器资源、应用代码或数据库配置之中。按照合理的顺序排查，通常能更快恢复服务，减少对用户的影响。
1. 先确认网络连通与域名解析状态
站点无法访问时，先别急着动服务器。第一步要判断问题出在客户端还是服务端。比如，切换网络环境——用手机移动数据取代公司Wi-Fi访问，如果恢复正常，多半是本地网络缓存或设备配置所致。若是只有特定地区或某个运营商的用户反馈打不开，则更可能是链路拥堵或解析尚未生效。
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和路径。例如发现某接口每秒被调用数百次，即可通过限流或封禁来源IP缓解压力。
2.2 留意磁盘写满与交换分区过载
磁盘使用率超过80%时应引起警觉。若会话文件、日志或临时目录写满，程序无法正常写入缓存，常会直接抛出500错误。清理过期日志与临时文件，通常能立刻释放可用空间。内存方面，若free -h显示swap分区读写频繁，说明物理内存严重不足，系统正不断在内存与磁盘间交换数据，整体性能会急剧下降。此时应优先优化程序内存占用，必要时考虑扩容内存。
3. 深入应用日志与后端服务状态
页面白屏、部分功能失效或直接返回5xx状态码，问题核心大概率在应用层。打开浏览器开发者工具的Network面板，查看具体请求的HTTP状态码和响应时间，能快速区分是接口错误还是前端渲染异常。若返回502或504，则说明网关与后端服务之间的通信出了问题。
3.1 区分502与504的不同指向
502 Bad Gateway通常意味着后端进程崩溃或无响应，而504 Gateway Timeout则代表请求在合理时间内未得到处理。遇到502，检查应用进程是否存活——用systemctl status 服务名或ps -ef | grep 应用名确认进程状态，必要时查看启动日志中的崩溃原因。遇到504则需关注慢查询、外部接口调用超时或线程池耗尽的问题。
3.2 从错误日志中定位代码缺陷
应用日志是排查代码问题的核心依据。查看日志时，重点关注异常堆栈信息、错误码以及日志中的时间戳。比如日志里频繁出现数据库连接超时，就应转向检查数据库连接池配置；若出现内存溢出错误，则需要调整JVM参数或优化对象引用。日志级别也要合理设置，生产环境建议保持info以上，避免日志文件膨胀影响磁盘，同时又能保留足够的错误线索。
4. 核查数据库连接与查询性能
应用层排查无果时，需要把视线转向数据层。数据库连接数打满、慢查询堆积或锁等待严重，都会拖垮整个后端。先检查数据库的当前连接数是否接近上限，再看是否存在长时间未释放的事务或锁等待。
4.1 发现并优化慢查询
开启数据库的慢查询日志，观察执行时间超过阈值的SQL语句。常见的慢查询原因包括：缺少索引、数据量过大但未分页、或使用了不必要的表关联。针对高频慢查询，可使用EXPLAIN查看执行计划，确认是否走了索引。务必先在测试环境验证优化效果，再应用到生产库。
4.2 监控连接池与锁冲突
连接池设置过小会导致高并发时请求排队；设置过大则可能耗尽数据库资源。合理的初始值取决于业务流量，通常需要结合监控数据调整。若日志中出现大量锁等待超时，应检查是否有长事务未提交，或者代码中加锁顺序不一致导致死锁。此时优化事务粒度，缩短持锁时间，往往能快速缓解冲突。
5. 常见问题
5.1 网站时好时坏，刷新几次又能打开，是什么原因？
这种情况多为间歇性资源紧张所致。可能是定时任务在特定时刻占用大量CPU或磁盘IO，也可能是连接池在并发峰值时被短暂打满。建议查看与故障时间重合的定时任务日志和监控曲线，定位触发点。
5.2 手机能访问，电脑打不开，问题出在哪里？
基本可排除服务器故障，问题更可能出在电脑本机。先尝试清空浏览器缓存和DNS缓存，或者换个浏览器测试。若依旧无法访问，检查电脑的hosts文件是否残留旧解析记录，或本地代理软件是否拦截了域名。
5.3 所有环境都显示证书错误，但站点刚部署时正常，怎么回事？
多半是SSL证书过期所致，也可能因证书链不完整或域名与证书不匹配引发。查看证书的有效期，若已过期请尽快替换；若未过期，则检查中间证书是否已正确配置到服务器。
6. 结语
排查网站的可用性问题，核心在于按层次推进，做到不盲目重启、不无依据操作。建议在日常运维中做好三件事：建立监控告警机制，覆盖网络、系统、应用和数据库层面；记录每次故障的处理过程，沉淀为团队排查手册；定期检查日志清理情况和备份策略，避免磁盘满或数据丢失带来二次灾害。这样当故障再次来临时，就能从容应对，快速恢复。
