网站打不开的完整排查指南，从网络链路到数据库逐层定位
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /675a6f04413a.html
📄
网站忽然打不开时，反复刷新浏览器或盲目重启服务器，往往既耽误时间又找不到真正的病根。正确的做法是扮演一次用户，跟着一次页面请求走过的路径，从最外层的网络解析开始，逐层向内推进，一直到数据读取的底层。这种分层定位的思路，能把排查范围从"整个系统"缩小到"某一个环节"，让问题浮出水面。
1. 先看网络链路：域名解析与访问路径是否通畅
检查网站问题前，先确认故障源头在客户端这边还是服务器那边。最省事的办法是断开Wi-Fi，用手机流量访问同一网址。如果流量环境能正常打开，说明服务器大概率没毛病，问题集中在本地路由器的缓存、DNS设置或宽带线路上；如果发现只有特定地区或某家运营商的用户访问异常，则更可能是跨网链路拥堵，或者DNS解析在部分节点还没有完全生效。
1.1 核对域名解析指向的IP
在Windows命令行或macOS终端里输入nslookup 你的域名，检查返回的IP是否和服务器当前公网地址一致。若记录为空，或者指向一个早已废弃的旧地址，就需要登录域名服务商的后台，确认A记录或CNAME配置有没有被误改。注意，修改DNS不是秒生效的事情，通常要等几分钟到几小时。假如站点用了CDN加速，还应登上CDN控制台检查边缘节点和回源配置是否健康，不少访问异常的真正诱因是CDN回源时被源站拒绝。
1.2 检查端口放行与防火墙规则
如果你能ping通服务器IP，但浏览器依然无法打开网页，问题基本出在端口上。云平台的安全组和服务器本机防火墙，都必须同时放行80（HTTP）和443（HTTPS）端口。在本地执行telnet 服务器IP 443，如果长时间连接超时，基本可以断定是拦截规则在作怪。此时优先登录云控制台检查安全组入方向规则，再回到服务器看iptables或firewalld的配置，先后顺序不要搞反，以免白费力气。
2. 再看服务器资源：负载过高或磁盘耗尽拖垮服务
网站加载极慢、页面反复超时，甚至直接显示连接重置，多半是服务器资源被"吃掉"了。CPU占满、内存不足、磁盘写满或带宽被占满，任何一项都能让服务响应陷入瘫痪。登录服务器后，依次执行top、free -h、df -h三组命令，可以快速看清系统当前的负载、内存余量和磁盘占用情况。
2.1 揪出占用资源最高的进程
在top命令的输出界面按P键，让进程按CPU占用率从高到低排序，重点观察排在最前面的程序是谁。常见的高占资源源头有：服务器被入侵后植入的挖矿木马、数据库缺少索引导致的查询堆积、以及恶意爬虫并发抓取。配合查看Nginx或Apache的访问日志，能进一步确认异常流量的来源IP和请求路径。例如发现某个接口每秒钟被刷几百次，临时封掉对应IP或限制请求频率，压力通常立刻就能降下来。若CPU并不高，但内存被占满，则优先排查常驻内存的PHP或Java进程是否出现泄漏。
2.2 留意磁盘余量与swap交换频率
磁盘使用率一旦超过80%，就要警惕了。会话文件、日志目录或临时缓存一旦写满，应用无法正常写入数据，网站常常直接抛出500错误。清理掉一周前的压缩日志或清空临时文件目录，往往就能释放大量空间。内存方面，如果free -h显示swap分区的占用在持续上升，说明物理内存已逼近极限，系统在不断进行磁盘和内存之间的换页操作，性能大打折扣。此时要么优化应用的缓存机制，要么考虑扩容升级。
3. 深入应用进程：运行中不代表逻辑健康
端口正常、资源也充裕，但网页仍然报错，这时候要检查应用本身是否处于假死或死锁状态。先看Nginx、Apache或Tomcat的错误日志，多数错误线索都写在这里，比如PHP-FPM的worker进程耗尽、网关超时或证书文件失效等。常见的误区是只看进程是否存活，其实进程活着，内部线程可能早已堵塞多时。
3.1 验证服务实际响应能力
在服务器本地执行curl -I http://127.0.0.1，观察HTTP状态码是200还是500。若本地访问正常而外网异常，问题又重新回到网络或防火墙环节；如果本地就已经报错，则重点看应用框架的日志输出。遇到504网关超时，多半是后端处理请求的时间超过了代理服务器的等待上限，需要优化慢查询或提升脚本执行效率。
3.2 复查配置文件或代码变更
网站最近是否更新过代码、修改过数据库连接串，或是更换过SSL证书？这些问题不在进程本身，而在配置变更。如果不确定，可以翻看发布记录，把最近一次变更回滚观察是否恢复。也可以对比之前的备份配置文件，排除人为误操作造成的隐患。另外，别忘了检查站点目录的读写权限，权限不足会导致静态资源无法加载，页面呈现纯文字或排版崩坏。
4. 最后查数据库：慢查询与连接数耗尽
当网页能打开，但需要登录或读取列表时特别卡顿，甚至直接报数据库连接失败，问题核心往往在数据库。数据库连接数到达上限后，新的请求都会排队等待，用户端表现就是页面长时间转圈。先使用SHOW PROCESSLIST;查看当前所有活跃连接，很多长期处于Sleep状态但未释放的连接，就是连接数被占满的直接原因。
4.1 定位慢查询语句
开启MySQL的慢查询日志，或直接在数据库中执行EXPLAIN分析某条SELECT语句的执行计划，重点关注全表扫描的记录。一张几十万行的表，在没有索引的字段上做模糊匹配，查询耗时可能达到上百毫秒，一旦并发量上来，数据库CPU必然飙升。举例来说，给WHERE条件里频繁使用的字段加上普通索引，原本2秒的查询往往能压缩到几十毫秒。
4.2 化连接池与缓存策略
应用层频繁建立和断开数据库连接，也会放大服务器压力。将连接池的最大连接数设定在一个合理区间，并延长空闲连接的超时回收时间，能有效降低反复连接的消耗。同时，把热点数据写入Redis或Memcached这类缓存中间件，减少直接查询数据库的次数，也是常见的优化手段。若数据库日志中出现"too many connections"字样，建议先临时调高max_connections参数应急，再持续观察内存是否承受得住。
5. 常见问题
5.1 网站打不开，怎么快速判断是服务器问题还是网络问题？
先用手机流量访问网站。如果能打开，说明服务器正常，问题出在本地网络、路由器或DNS上面；如果手机流量也打不开，再进一步执行ping和telnet测试，区分是服务器宕机、端口被封还是线路中断。
5.2 重启服务器后网站能打开，为什么不能一劳永逸？
重启只能暂时释放被占用的内存和文件句柄，但根源如未修复的代码漏洞、配置错误的数据库连接或磁盘空间不足，重启后很快就会再次出现。排查出具体病因后做针对性修复，才算真正解决。
5.3 为什么IP能ping通，但浏览器就是打不开网页？
ping走的是ICMP协议，而网页访问依赖80或443端口。能ping通只代表主机在线，端口是否放行、Web服务是否在运行、防火墙有没有拦截TCP连接，都是需要继续确认的环节。
6. 总结
网站无法访问时，按"网络解析→端口与防火墙→服务器资源→应用进程→数据库"这条链路由外向内地排查，能在最短时间内把故障范围明确到单一层次。每次处理完故障后，建议把当时的日志、执行过的命令和修复方案记录成文档，下次遇到类似问题，能少走不少弯路。
