云主机无法访问，先排查这几种常见原因

云主机无法访问，看起来都是“连不上”，实际可能卡在完全不同的层面：网络没通、安全策略拦了、系统已经卡死，或者应用服务自己掉了。排查一乱，时间就会耗在错误方向上。遇到这种故障，先别急着重启实例，先把现象说清楚，再按层往下查，通常会快很多。

先分清你遇到的是哪一种“无法访问”

“服务器挂了”这句话在排障里用处不大。云主机无法访问，常见的情况至少有这几类，入口完全不同：

• 公网访问失败，内网正常：多半先看安全组、弹性公网IP、带宽、路由和ACL。
• Ping不通，但端口偶尔能连：要考虑ICMP被禁用，不能直接下结论说主机坏了。
• 能Ping通，但网站打不开：重点转到Web服务、反向代理、证书、防火墙和端口监听。
• SSH或远程桌面进不去：优先检查22、3389这类管理端口，账户权限、登录策略和实例负载也要看。
• 所有端口都失联：要怀疑实例宕机、系统卡死、网卡异常，或者云平台侧网络故障。

先判断问题大概落在主机、网络还是应用。边界清楚了，后面的排查才不会散。

排查顺序别反：从云平台到系统，再到应用

先看云平台配置

很多云主机无法访问的问题，根本不在操作系统里，往往出在控制台配置层。尤其是做过上线、切换、网络调整之后，这一层很容易出错。

• 确认实例状态是不是运行中。如果是停机、重启中、迁移中，外部访问异常很正常。
• 检查公网IP是否还绑定在当前实例上，是否有释放、变更或漂移。
• 核对安全组入站规则，80、443、22、3389这些端口有没有放行，源IP范围是不是写窄了。
• 看子网、路由表、网络ACL有没有误拦截。
• 确认是否存在欠费、带宽封顶、清洗或防护策略触发的情况。

这类问题看起来严重，修起来反而快。比如安全组临时收紧后忘了放开，或者端口改了却没同步规则，都会直接表现成网站打不开、SSH连不上。

再从本地做连通性验证

平台配置没明显问题，再从你自己的终端做基础测试。目的就是把故障位置一点点拼出来。

1. 先Ping目标IP，看看有没有基础网络响应。
2. 再用telnet、nc，或者直接在浏览器里测目标端口，确认服务入口是否打开。
3. 用traceroute或tracert看链路停在哪一跳，判断是不是中间网络有问题。
4. 换一个网络环境再测一次，比如手机热点，排除本地出口网络限制。

这里有个常见误判：Ping不通，不代表云主机一定坏了。有些环境默认就不回ICMP，但22端口、80端口照样能用。排查云主机无法访问，不能只盯着Ping结果。

SSH进不去，就走控制台或VNC

如果管理端口已经失联，别一直在外面猜。直接用云平台提供的控制台登录、VNC，或者救援模式进系统，判断会更快。这一步通常能把“网络不通”和“系统出问题”分开。

• 看系统是不是卡在启动阶段，服务根本没拉起来。
• 看磁盘是不是写满了，很多服务在这种情况下会直接启动失败。
• 看CPU、内存是不是长期顶满，管理服务可能已经无响应。
• 看网卡配置和路由有没有丢失或写错。
• 看主机防火墙规则有没有把外部访问挡掉。

几种高频原因，基本都在这里面

安全组或系统防火墙拦截

这是最常见的一类。云安全组控制平台侧流量，操作系统里的iptables、firewalld或Windows防火墙控制主机内部流量。两层只要有一层拦住，外部看起来就是云主机无法访问。

检查时别只看“有没有规则”，还要看规则写得对不对：

• 入站规则里的协议、端口、源IP是否匹配当前访问方式。
• 系统防火墙是否放行同样的端口。
• 管理端口如果改过，比如SSH不再用22，安全组和运维文档有没有一起更新。

很多人卡在这里，是因为控制台放行了端口，就默认系统内也会通。实际上两层配置要对得上。

服务没起来，或者端口没监听

网络通，不代表业务通。能Ping通，但网站打不开，这时候更像是应用服务没起来，或者反向代理、证书、配置文件出了问题。Nginx崩了、Apache没启动、MySQL没监听端口，用户体感上都会是“服务器访问不了”。

• 先看服务进程在不在。
• 再看目标端口有没有监听。
• 查服务日志，确认是不是配置错误、证书问题，或者资源不足导致启动失败。

如果是网站访问异常，别把注意力都放在实例网络上。很多时候，问题已经下沉到应用层。

资源耗尽，系统进入假死状态

CPU打满、内存耗尽、磁盘写满，都会让云主机表现得像“坏了”。页面一直转圈、SSH连上后没响应、远程桌面卡死，这些都很典型。日志暴涨、数据库异常写入、程序死循环时，尤其容易出这种问题。

• CPU：找持续占满的异常进程。
• 内存：看有没有触发OOM，关键服务可能已经被系统杀掉。
• 磁盘：重点看根分区和日志目录，满了以后很多服务会直接报错退出。

这种故障有个坑：实例状态在控制台里往往还是“运行中”，但业务已经不可用了。所以只看云平台状态，容易漏掉。

网络配置被误改

手工改网卡、DNS、默认网关、hosts、resolv.conf，本来就是高风险操作。改完重启网络服务，如果参数写错，云主机无法访问几乎会立刻发生。

如果故障前刚做过这些变更，优先回溯：

• 静态IP配置是否改错。
• 默认网关是否丢失或写错。
• 网卡绑定关系有没有变化。
• hosts或DNS解析配置有没有影响系统访问外部依赖。

最近动过什么，就先查什么。比起大范围扫描，回看最近变更通常更快。

云平台侧异常

云厂商底层网络抖动、宿主机故障、存储异常，概率不算高，但不能排除。典型表现是：你这边配置看着没问题，系统也能进，但外部访问就是不稳定，甚至同区域其他实例也有类似情况。

• 先查云平台公告和监控告警。
• 提工单时带上实例ID、故障时间点、访问日志和测试结果，别只写一句“访问不了”。
• 业务不能等的话，尽快切到备用节点。

一个很典型的场景：网站打不开，问题却不在网络

有些故障表面看是云主机无法访问，根因其实在资源和服务。比如促销活动期间，官网突然打不开，外部用户会直接认为服务器断了。排查时如果只盯着安全组、公网IP和负载均衡，很容易在网络层来回绕。

这种场景里，更有效的判断方式是看现象组合：如果Ping正常，但80端口超时，重点就别再放在公网链路上了。进一步进控制台，很可能会发现磁盘已经满了。详细访问日志开着，日志切割又失效，短时间内写出大量文件，Nginx没法继续写日志，就会退出。监控如果只盯着进程存活，不看磁盘阈值，故障就会拖到用户先发现。

处理动作一般也很直接：

1. 进控制台清理历史日志文件，先把空间腾出来。
2. 释放磁盘后重启Nginx，让服务先恢复。
3. 补上日志轮转和磁盘阈值告警，避免同样的问题再来一次。
4. 把关键服务健康检查纳入日常巡检，不只看机器活着没活着。

这个场景很能说明问题：网站打不开，未必是网络坏了；云主机无法访问，也不一定是实例本身断了。

一份顺手的处理清单

临时救火时，最怕漏项。把下面这套动作固定下来，排查会稳很多：

1. 先确认实例状态、公网IP、安全组、路由是否正常，别一上来就登录系统折腾。
2. 从本地测Ping、端口、链路，必要时换网络环境复测。
3. SSH进不去就改走控制台或VNC，尽快看到系统真实状态。
4. 进系统后先看CPU、内存、磁盘、网卡，不要急着重启服务。
5. 核对系统防火墙和端口监听，确认请求到底有没有到进程前面。
6. 查Nginx、SSH、系统日志和内核日志，很多线索都在里面。
7. 回溯近期变更，比如发布、重启、策略调整、证书更新、网络配置修改。
8. 怀疑平台异常时，整理好证据链再联系云厂商，效率会高很多。

想少遇到“云主机无法访问”，平时要补这几块

故障修复能力要有，预防动作也不能省。生产环境里，下面几件事很实用：

• 监控别只看实例在线，网络、端口、资源、关键进程都要覆盖到。
• 安全组、路由、网卡这类变更，尽量走审批和备份，误改一次，恢复成本往往不低。
• 日志轮转、磁盘阈值、自动清理策略早点配上，别等磁盘满了再补。
• 提前准备备用登录方式，比如控制台、跳板机、救援镜像，别把SSH当成唯一入口。
• 关键业务尽量做多实例或多可用区容灾，单点故障时才有切换空间。

云主机无法访问，最怕的是排查没有顺序。按“平台配置、网络连通、系统状态、服务进程、资源负载”这个路径往下走，大多数问题都能较快收敛。如果现在就碰到网站打不开、SSH连不上，先查安全组、端口和控制台登录，这三步通常就能把范围缩小不少。