网站无法访问怎么排查，完整故障定位方法指南

📍 WDQWDWQD987AAAAA:216.73.216.25
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a886c1afe98c.html
📄

网站打不开、打开速度极慢或时断时续，问题可能出在域名解析、网络链路、服务器资源或后端程序等各个环节。与其盲目重启机器碰运气，不如按照从访问端到服务端、从外部到内部的顺序逐层排查，快速缩小故障范围，尽早恢复网站正常运行。

1. 先检查客户端与网络链路

收到网站异常反馈时，先别急着登录服务器，花一分钟判断故障影响范围。询问反馈者是所有人均无法访问，还是只有特定用户或地区受影响。自己切换网络环境测试，比如用手机4G/5G流量访问，以排除本地宽带、路由器或办公网络故障。若只有某区域用户访问失败，需重点排查CDN节点或运营商线路状况。

1.1 验证域名解析是否正确

在本地电脑打开命令行，执行nslookup 你的域名或ping 你的域名，核对返回的IP地址与服务器当前公网IP是否一致。若解析到旧IP、错误地址或提示超时，说明域名解析环节异常。登录域名注册商后台，检查A记录、CNAME记录是否正确，并确认修改后已超过TTL生效时间。若网站启用CDN，还需在CDN控制台检查加速节点是否处于正常运行状态。

1.2 测试服务器端口连通性

若域名解析正确但仍无法连接，需要测试服务器端口是否对外开放。在命令行输入telnet 服务器IP 80，观察是否返回连接成功信息。若提示拒绝连接或超时，多半是防火墙策略拦截。此时应前往云服务商控制台，检查安全组入方向规则是否放行80和443端口，同时登录服务器查看内部的iptables或firewalld配置，确保没有遗漏的拦截规则。

2. 核查服务器资源与进程状态

页面加载缓慢或间歇性不可用，通常与服务器硬件资源耗尽有关。当CPU持续高负载、内存不足、磁盘写满或带宽被占满时，服务器将无法响应新请求。通过SSH登录服务器，依次执行top、free -m、df -h三个命令，可以直观查看CPU、内存和磁盘的实时占用情况。

2.1 定位消耗资源的异常进程

在top命令运行界面按大写P键，进程会按CPU占用率降序排列，重点观察排名靠前的进程。常见的异常原因包括：服务器被植入挖矿木马、数据库查询因缺少索引而全表扫描、或是遭受恶意爬虫高频抓取。结合Web访问日志，查看是否存在某个特定请求路径或IP导致流量异常飙升，以便针对性封禁或优化。

2.2 处理磁盘与内存告警

磁盘使用率超过80%时需尽快介入处理。日志文件、临时目录或旧备份常挤占空间，导致程序无法写入缓存或会话文件，网站因此抛出500错误。定期清理过期日志和无用备份是有效预防手段。内存方面需留意swap交换分区的增长趋势，若swap持续被占用，说明物理内存吃紧，应检查是否有内存泄漏，同时调整PHP-FPM或Java虚拟机等进程的内存参数。

3. 排查数据库连接与状态

不少网站故障的根源并不在代码逻辑，而是数据库服务中断或连接超限。若网站出现“数据库连接失败”或相关报错，应优先确认数据库服务的运行状态及连接配置是否正确。

3.1 确认数据库服务运行与连接数

在服务器上执行systemctl status mysql或service mysqld status（根据实际数据库类型调整）查看服务状态。若服务未运行，尝试启动并观察日志输出。同时检查数据库最大连接数设置（如MySQL的max_connections），当连接数被占满时会拒绝新连接。排查是否有慢查询长时间占用连接，可通过开启慢查询日志记录耗时的SQL语句，为后续优化提供依据。

3.2 核对应用侧数据库配置

检查网站配置文件中数据库地址、端口、用户名和密码是否与当前环境匹配。注意数据库服务器是否变更过IP，或密码是否近期重置过。若应用与数据库在同一台机器上，使用127.0.0.1连接通常更稳定；若分离部署，则需确保云安全组已放行数据库端口（如3306），并限制来源IP以防被攻击。

4. 检查Web服务与应用日志

当网络和资源都正常时，问题可能集中在Web服务软件或应用代码层面。Nginx、Apache等Web服务器的错误日志会记录请求处理失败的具体原因，应用框架（如PHP、Python、Java）的运行日志则能暴露代码异常。

4.1 查看关键错误日志

Nginx错误日志一般位于/var/log/nginx/error.log，Apache为/var/log/apache2/error.log。关注日志中的“502 Bad Gateway”“504 Gateway Timeout”等关键字。502通常意味着后端PHP进程挂掉或未启动，504则说明脚本执行超时。应用日志位置因框架而异，如ThinkPHP的runtime目录、SpringBoot的logs目录，此处能直接看到堆栈信息，便于快速定位代码故障。

4.2 分析访问日志中的异常请求

访问日志（如/var/log/nginx/access.log）能反映真实请求情况，排查是否有大量404错误（可能被扫描攻击）、大量POST请求（可能被刷接口）、或特定URL集中在同一时间点导致服务崩溃。若发现异常IP频繁访问，可在防火墙层面临时封禁该IP，观察网站访问是否恢复正常。

5. 按故障现象制定优先级

实际排查时，不同故障现象对应不同的优先排查顺序，按以下清单可提高效率：

6. 常见问题

6.1 网站被攻击导致无法访问怎么办

先观察服务器流量是否异常暴涨，通过云服务商控制台查看带宽监控图。若确认遭大流量攻击，可立即开启CDN的高防功能或启用云防火墙流量清洗；同时封禁攻击IP段，限制单IP连接数。事后还应检查并修补应用漏洞，防止再次被利用。

6.2 重启服务器后网站仍异常是怎么回事

若重启后问题依旧，说明故障并非临时性资源耗尽，而是持久性配置或底层环境问题。应逐项复查：磁盘是否已满导致服务无法写入、数据库数据文件是否损坏、代码文件权限是否因重启被重置、依赖服务（如Redis、Memcached）是否未随系统启动。

6.3 手机能打开但电脑打不开

这种情况大概率是本地网络或客户端环境导致。先切换到不同Wi-Fi或用其他浏览器测试；若仅电脑异常，检查系统的hosts文件是否被改动、是否有代理软件干扰DNS解析，并尝试ipconfig /flushdns刷新本地DNS缓存。

7. 总结

网站故障排查的核心在于缩小范围与快速验证，遵循“由外到内、由软到硬”的顺序，即先确认网络与解析，再查资源与进程，接着看数据库与日志，最后结合现象做针对性调整。建议日常运维时提前搭建监控告警，记录服务器正常状态下的各项指标基线，这样在出现异常时即可对照快速定位。同时，将本次排查问题和解决步骤整理成文档，后续遇到类似情况能直接参照处理，有效缩短故障恢复时间。

图1 图2
nginx