服务器连不上，这事儿我太熟了。半夜被电话叫醒，那头急得不行："服务器崩了！连不上！"结果上去一看，多半不是什么大故障，就是安全组规则改错了，或者忘了加/0那个后缀。

别慌。连不上EC2，90%的情况是网络配置的问题，跟服务器本身没关系。咱们按一条线路排查，十分钟内基本能找到病根。

第一站：检查安全组——最频繁的"凶手"

安全组就是EC2的防火墙，只出不进默认全封。连不上服务器，头一个怀疑对象就是它。

去看一眼你实例关联的安全组，入站规则（Inbound rules）里有没有允许你当前IP访问目标端口。举个最常用的例子：你要连SSH（22端口），规则里得有"类型SSH、端口22、源IP是你自己电脑的公网IP"。源IP别写成0.0.0.0/0，那是全互联网都能连，跟把家门钥匙挂在门框上没区别。

如果你的IP是动态的，每次重启路由器就变，可以去AWS控制台看"EC2 > 网络与安全 > 安全组"，点进去编辑入站规则，把新的IP填上就行。再提醒一嘴：安全组是"白名单"机制，没明确允许的全拒绝，别指望默认放你进去。

第二站：确认密钥对没弄丢

用密钥对登录（Linux是.pem文件，Windows是.ppk或者密码）是EC2的铁规矩。连不上，有几种常见的密钥翻车情况：

  • 密钥文件没了：这玩意儿丢了没法找回，只能换新密钥重新部署实例。所以拿到密钥先备份到本地，最好再扔一份到公司密码管理器里。

  • 密钥权限太松：Linux下执行chmod 400 你的密钥.pem，权限收紧了，SSH客户端才认。权限太开放它反而不干活。

  • 用了旧密钥：实例创建时绑定了哪个密钥，登录时就得用哪个。中途换密钥得通过控制台或者CloudShell操作，不是随便改个文件名就能糊弄过去。

第三站：端口通不通，用telnet试试

安全组放行了，密钥也没问题，还是连不上。这时候用telnet测一下端口是否真的可达。

在你本地电脑上打开终端（Windows用CMD或PowerShell也行），敲：
telnet 你的EC2公网IP 22
如果屏幕黑了或者跳出一串字符，说明端口通着呢。如果报"Unable to connect"或者"Connection refused"，那说明网络层面压根没走到实例，问题还在安全组或者路由表上。

拿到这个结果，你就知道该往哪个方向查了。

第四站：检查网络ACL——隐藏的"第二道防火墙"

安全组查完了，还有一道看不见的防线叫网络ACL（Network Access Control List）。它附在子网（Subnet）层面，管着进进出出的流量。

不过别担心，AWS默认的VPC里，网络ACL默认是"全放行"的（入站和出站都允许所有流量）。除非你自己手贱改过它，否则基本不可能是它的问题。如果改过，去VPC控制台找到"Network ACLs"，看一眼入站规则有没有允许你的IP段，出站规则有没有允许返回的流量（默认都允许）。

第五站：路由表和互联网网关

这是最后一道关口了。如果你的EC2在私有子网（Private Subnet）里，没有互联网网关（Internet Gateway）搭桥，外网死活连不进去。

去VPC控制台看一眼路由表（Route Tables），和EC2所在子网关联的那张表，里面有没有一条目标0.0.0.0/0指向igw-xxxxxxxx（互联网网关）。没有？那说明这台实例压根没暴露到公网上。要么给它绑个弹性公网IP（EIP），要么在它前面架个堡垒机（Bastion），从内网跳进去。

第六站：操作系统内部——最后再怀疑

前面网络路径全通，但SSH还是拒你于千里之外，那就是操作系统内部的问题了。

  • sshd服务没起来：用AWS控制台里的"EC2 Instance Connect"或者"CloudShell"登录进去，敲sudo systemctl status sshd看一眼。

  • 防火墙软件拦截了：比如Ubuntu上的UFW，CentOS上的firewalld，你敲sudo ufw status或sudo systemctl status firewalld，确认它们没把22端口干掉。

  • CPU/内存爆了：系统负载太高，拒绝新的SSH连接。用EC2 Instance Connect进去敲top或htop，把吃资源的进程掐了再试。

最后的建议：别让排查变成猜谜

遇到连接问题，照着这条链从头到尾捋一遍：安全组 → 密钥 → 端口可达性 → 网络ACL → 路由表 → 操作系统。别东一下西一下地瞎猜，按顺序走，十分钟内基本能定位问题。

把你当前的IP地址加到安全组里，这是最管用的第一步。大部分"连不上"的求助，就这么解决的。