网站打不开怎么排查？从外到内逐层定位故障点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a79a23d4e3c1.html
📄
网站突然无法访问，很多人第一反应是反复刷新或直接重启服务器，但这往往治标不治本。更高效的做法是顺着用户请求的路径，从网络入口到数据存储，由外而内地逐层排查。这套系统化的定位方法，能够帮你尽快锁定故障源头，避免盲目操作。
1. 检查网络链路：域名解析与端口连通性
遇到网站打不开，先别急着登服务器。第一步要做的是区分问题是出在访客这边还是服务器那边。可以试着切换网络环境，比如用手机开热点访问网站。如果切换后能正常打开，多半是本地路由器缓存或DNS设置有误；如果只有特定地区或运营商的用户无法访问，则要考虑解析是否已全球生效或者链路是否存在拥堵。
1.1 核对域名解析是否指向正确
在本地命令行中输入 nslookup 你的域名，查看返回的IP地址是否与服务器当前公网IP一致。如果解析结果为空或指向旧地址，说明域名控制台的A记录或CNAME配置有误。需要注意的是，修改DNS记录后生效需要时间，短则几分钟，长则数小时。若网站使用了CDN，也需登录CDN控制台确认节点状态和回源配置是否正常。
1.2 验证端口连通性
服务器可以ping通但网页打不开，绝大多数情况是端口被拦截。云服务器的安全组规则、本地防火墙都要确保放行80和443端口。执行 telnet 服务器IP 443 测试连接，提示超时即被拦截。排查顺序应为：先检查云控制台安全组入方向规则，再检查服务器内部iptables或firewalld配置。
2. 排查服务器状态：资源耗尽会拖垮一切服务
系统响应迟缓、请求大面积超时，往往与资源耗尽有关。CPU满载、内存不足、磁盘无剩余空间或带宽被占满，都会导致服务变慢甚至拒绝响应。登录终端后，依次运行 top、free -h、df -h 三组命令，即可快速掌握CPU负载、内存余量与磁盘占用概况。
2.1 定位占用资源的异常进程
在top界面按 P 键将进程按CPU使用率降序排列，重点观察排名靠前的进程。常见的资源消耗因素包括：植入的挖矿木马、数据库慢查询堆积、恶意爬虫高频抓取。结合Nginx或Apache访问日志，确认异常请求的来源IP与访问路径。例如某接口每秒请求次数异常高，可临时屏蔽来源IP或添加请求频率限制，通常能迅速降低系统压力。
2.2 预防磁盘写满与swap频繁交换
磁盘使用率超过80%就应引起重视。日志文件、临时目录或会话文件写满后，应用无法写入缓存，网站常直接报500错误。清理过期日志与临时文件通常可释放空间。另外，若 free -h 显示swap读写频繁，说明物理内存严重不足，系统正频繁执行内存换页操作，整体性能会大打折扣。此时应优先优化应用内存占用或升级配置。
3. 深入应用层：进程存活不等于服务正常
系统资源正常、端口处于监听状态，但访问仍报错时，需将排查重点转向应用软件本身。执行 ps -ef | grep 应用名 确认进程存在。若进程消失，检查应用日志，如Java应用可查看 catalina.out，PHP应用查看PHP-FPM日志，以判定是报错退出还是被系统杀掉。此外还需验证进程是否处于僵死状态，此时端口虽被占用，但无法正常处理新请求，重启服务通常会暂时恢复。
3.1 观察应用日志与错误码
日志是定位应用故障最直接的依据。查看最近时段的错误日志，重点关注 OutOfMemoryError、数据库连不上的异常以及死锁记录。若页面返回502，通常与PHP-FPM或网关进程退出有关；504则表明上游应用响应超时，常见原因为代码死循环或外部接口调用阻塞。
4. 定位数据层：数据库与缓存要仔细检查
排除了以上问题，若网站依旧异常，则应关注数据存储环节。数据库连接池占满、慢查询过多导致连接堆积，或者缓存服务（如Redis）不可用，都可能引发网站故障。
4.1 检查数据库连接数与慢查询
登录数据库执行 SHOW PROCESSLIST; 查看当前连接状态，观察是否存在大量 Waiting for table lock 或 Copying to tmp table 的线程。同时打开慢查询日志，定位执行时间过长的SQL语句。为高频查询字段补充索引往往是有效的解决方案，比如订单查询按用户ID建索引，能明显降低查询耗时。
4.2 验证缓存服务状态
执行 redis-cli ping，返回PONG即正常。若缓存服务不可用，程序可能大面积回源数据库，导致数据库压力激增。排查缓存服务内存是否写满，以及持久化策略是否合理，例如设置了不适宜的淘汰策略导致热点数据被清理。
5. 常见问题
5.1 为什么网站时好时坏，时断时续？
这类间歇性故障，多半与定时任务、内存用量波动或带宽被特定时段占用有关。建议在故障发生时记录系统负载、连接数与访问日志，观察规律。如果总是某个时段出问题，可重点检查该时段是否有计划任务在跑，比如数据备份或日志切割占用了大量资源。
5.2 排查时是否有推荐的操作顺序？
推荐的顺序是：先访客侧（更换网络测试）→ 域名解析 → 端口连通性 → 服务器资源（CPU、内存、磁盘）→ 应用进程与日志 → 数据库与缓存。按此顺序操作，多数情况下能避免重复劳动。
5.3 服务器重启后过一会又出问题，怎么处理？
这种情况表明存在反复触发的根因。重启只是暂时缓解了症状。应优先查看启动后的系统日志和应用日志，查找崩溃前的报错信息，比如磁盘配额、权限变更或特定参数超出阈值。同时检查是否有外部攻击或抓取脚本在持续施压。
6. 结语
网站排查本质上是一场有章法的推理。遵循由外向内的顺序，依次验证网络链路、服务器资源、应用状态和数据层，再配合有效日志的查看，大多数故障都能快速定位。建议将本次排查思路整理成一份简明操作单，放在手边以备不时之需。同时，平时为关键服务加好监控告警，远比出事后花大量时间排查更省心。
