网站突然无法访问的排查步骤?

别急着重启，先做"分层定位"

网站突然打不开，最危险的动作就是凭直觉乱试。有人一上来就重启服务器，结果把日志现场擦掉了;有人反复清缓存，折腾两小时才发现是域名过期。

正确的思路是先分层。网站访问链路其实是一条流水线：域名解析、网络连通、服务器状态、Web服务、程序代码、安全拦截、CDN配置，任意一个环节异常，浏览器都会显示"无法访问"。排查的意义，就是用最小的成本判断卡在哪一层，而不是把所有环节都翻一遍。

有个判断口诀很好用：如果报错是DNS解析失败，问题在域名侧;如果是连接超时或被拒绝，问题在网络或服务侧;如果返回了502、503这类状态码，说明站点还活着，问题在后端。

第一步：用IP直接访问，做关键切分

这是整套流程里性价比最高的一步。用浏览器直接访问服务器的IP地址(有SSL警告就忽略继续)，这一步能把问题一分为二。

如果IP能打开，说明服务器和Web服务都是正常的，问题百分之百出在域名解析或DNS环节，可以直接跳到第二步。如果IP也打不开，别急着下结论说服务器挂了，继续往下走。

紧接着测端口。用telnet或nc测试80和443端口：端口能连通，说明服务进程在跑，可能是Nginx只绑定了域名没绑定IP，或者SSL配置有误;端口不通(显示Connection refused或超时)，说明服务进程没起来，或者被防火墙拦截了。此时用SSH登录服务器看进程状态，如果连SSH都连不上，那才是服务器真的宕机了，需要去云服务商后台看实例状态。

第二步：查域名与解析，最容易忽略的环节

很多"服务器故障"其实是域名问题。排查顺序建议这样走：

先看域名本身。通过WHOIS查询域名是否过期、状态是否正常。如果域名过期，解析会直接失效;如果状态显示serverHold，多是实名认证未通过;显示clientHold，则是注册商暂停了解析。

再看解析记录。用nslookup或dig查询，对比返回的IP与服务器公网IP是否一致。常见错误包括A记录填错IP、只配置了www子域名却用裸域名访问、本该用A记录却配成了CNAME。有个容易被忽略的点是NS记录：如果你在DNS服务商面板里加了解析，但域名的NS记录仍指向旧服务商，那新面板里的所有配置对外部网络来说都是"不可见的"。

如果是国内站点，还要查备案状态。备案未接入当前服务商、备案信息专项核查不合格、备案被注销，都会导致服务商阻断访问。

第三步：排除本地与缓存干扰

这一步很多人会跳过，但它能省掉大量无用功。

判断依据很典型：同一网络里A电脑打不开、B电脑能打开;手机连WiFi打不开、切到流量就正常;换成公共DNS之后恢复正常。这些都指向DNS缓存，而不是服务器故障。

处理顺序是：先刷新本地DNS缓存(Windows执行ipconfig /flushdns，Mac执行sudo killall -HUP mDNSResponder)，再检查hosts文件里有没有遗留的测试条目(这个文件优先级高于DNS解析)，最后把系统DNS临时改成公共DNS重测。别忘了浏览器自己有独立的DNS缓存池，不跟随操作系统，Chrome和Edge需要单独清理。

第四步：按状态码定位后端问题

如果拿到了具体的错误码，排查就精准多了。

502和504来自同一层——请求到了Nginx，但Nginx转给后端(比如PHP-FPM)这一步没走通。一句话区分：502是上游根本没接上话，504是接上了但等太久没等到回复。

看Nginx的error.log就能分辨。写着connection refused，说明PHP-FPM没起来，或者socket路径与配置对不上;写着no live upstreams，说明上游整个不可用;写着Empty reply from server，多半是后端处理时panic了或被OOM kill了，可以用dmesg -T | grep -i "out of memory"确认。

这里有个实用技巧：从Chrome开发者工具里把报错请求复制成cURL命令，把目标地址改成后端服务地址直接请求，绕过Nginx。这样能快速确认是负载均衡的问题还是后端的问题，在链路复杂的环境里特别有效。

如果是504，fastcgi_read_timeout默认60秒，超时原因通常不在Nginx：慢查询没走索引、代码调第三方接口没设超时、导出大文件一口气查几十万行，都会让请求拖到几分钟。调大超时只是把报错往后推，真实原因要看PHP-FPM的slowlog。

第五步：检查资源、安全与CDN

前面都没问题，就要看这几个方向了。

资源耗尽是隐形杀手。磁盘写满(备份、日志、缓存膨胀)、内存跑满、inode耗尽，都会导致上传失败、更新中断、随机出现5xx错误。用df -h和free -h看一眼就知道。

安全拦截也常被忽略。WAF规则过严、IP黑名单、地区访问限制、防盗链配置异常，都可能阻断正常访问;网站遭受CC或DDoS攻击时，服务商也可能临时封禁。

如果站点接了CDN，还要查回源环节。回源地址填错、回源HOST配置不当、源站限制了CDN的回源IP，用户看到的都是"连接超时"或502。最快的验证办法是临时关闭CDN，直接用域名访问源站——源站正常而CDN异常，问题就锁定在CDN配置上。

一个真实案例

某外贸团队某天早上反馈全站打不开。运维第一反应是服务器宕机，准备强制重启。有人先做了第一步：用IP直接访问，发现能打开。于是方向立刻转向域名侧，dig一查，返回的还是三个月前的旧IP——原来前一天迁移服务器时改了A记录，但TTL设得很长，运营商递归DNS缓存还没更新。

全程没动服务器一行配置。如果按习惯先重启，不仅擦掉了日志，还会在错误方向上继续浪费一小时。

总结

网站突然无法访问，排查的核心不是命令多熟练，而是顺序对不对。建议严格按这个流程走：先用IP直连做切分，再查域名状态与解析记录，然后排除本地缓存干扰，接着按状态码定位后端，最后检查资源、安全策略与CDN。每一步都在缩小范围，而不是盲目尝试。

另外提醒两点：排查前先把当前状态和时间点记录下来，别急着重启破坏现场;如果所有环节都查完仍无解，带着这些信息提交工单，比空手求助效率高得多。故障恢复后，别忘了补上监控告警——下次故障来临时，你会感谢今天的自己。

纵横云服务器租赁，欢迎随时联系，客服联系方式：QQ3494196421,手机微信19906048601。