AWS S3存储优惠 AWS EC2 实例状态检查通过但 Ping 不通？路由表与安全组深度排查

很多人看到 EC2 Status Check 2/2 passed 就以为机器没问题，结果从本地一 ping 还是超时。这个场景我遇到最多的，不是实例坏了，而是公网路径没打通：路由表、Security Group、NACL、公网 IP、系统防火墙，任何一层漏了，都会“状态正常但外部访问失败”。

如果你现在最关心的是“为什么能进控制台、能 SSH，偏偏 ping 不通”，先别盯着实例健康检查看，先按下面顺序排查，效率最高。

先判断：你到底卡在哪一层

现象	最可能的问题	优先检查项
状态检查通过，但公网 ping 超时	路由表 / 安全组 / NACL / 公网IP	是否有 EIP、子网路由是否指向 IGW
SSH 能连，ping 不通	ICMP 被安全组或系统防火墙拦截	Security Group 入站是否放行 ICMP
同 VPC 内能 ping，外网不行	公网出口没配好	子网是否公有子网、路由是否到 Internet Gateway
换个网络就好了	本地网络屏蔽 ICMP	公司网、运营商、VPN 策略

第一步：先确认实例有没有“真正的公网入口”

很多用户以为只要有 EC2 实例就能从外网 ping，实际上不行。你至少要同时满足这 3 个条件：

• 实例有 Public IPv4 或 EIP。
• 实例所在子网的路由表有一条 0.0.0.0/0 → Internet Gateway。
• 安全组允许你的源地址访问 ICMP。

如果你只有私有 IP，没有绑定公网 IP，就算状态检查全绿，外网也不可能直接 ping 通。这个错误在新账号最常见，因为很多人创建实例时选了默认项，结果只拿到了私网地址。

实操判断方法

• 在 EC2 控制台看实例详情，确认是否有公网 IPv4。
• 看子网所属路由表，确认默认路由是否指向 IGW。
• 如果是 EIP，确认已经绑定到当前实例，而不是绑在别的网卡上。

第二步：路由表不是“有默认路由”就够了

AWS S3存储优惠 不少人看到路由表里有默认路由，就直接跳过。这里最容易踩坑的是：路由写对了，但子网没关联对。AWS 里路由表和子网是绑定关系，关联错了，等于没配。

你要检查的是：

• 实例所在子网，是否关联到了正确的路由表。
• 路由表中是否存在 0.0.0.0/0 → igw-xxxx。
• 如果是 IPv6，还要看 ::/0 是否指向对应的 Internet Gateway。

一个典型案例：客户说“我已经开了 22 端口，为什么 ping 不通”。结果一看，实例放在私有子网，默认路由指向 NAT Gateway。NAT 只能给实例主动出网用，不能让外部主动 ping 进来。这种情况改安全组没有用，必须换到公有子网，或者绑定可访问的公网路径。

第三步：安全组放行 ICMP，不是只开 22/80 就够

Security Group 很多人只配 SSH 和 HTTP，忘了 ICMP。ping 走的是 ICMP，不是 TCP 22，也不是 TCP 80。

建议你这样看：

• 入站规则里加一条 ICMP - IPv4。
• 来源地址不要偷懒写错，建议先用你的当前公网 IP 做测试，别直接放 0.0.0.0/0 长期开着。
• 如果你只想测连通性，规则放开后测完就收紧，避免长期暴露。

很多新手会犯两个错：

1. 只开了 TCP 端口，忘了 ICMP。
2. 把来源写成了内网段，比如 10.0.0.0/16，结果外网当然 ping 不到。

AWS S3存储优惠 另外，Security Group 是 有状态 的，回包通常不需要你单独放行；但这不代表就一定通。因为下一层 NACL 可能还在拦。

第四步：NACL 常被忽略，但它会直接把包丢掉

如果你在安全组里已经放行 ICMP，还是 ping 不通，下一步就看 NACL。NACL 是无状态的，这意味着进站和出站都要分别允许。

检查重点：

• 入站是否允许 ICMP。
• 出站是否允许 ICMP 或相关返回流量。
• 有没有你自己写的拒绝规则排在前面。
• 临时排障时，先看是否有“显式拒绝”规则。

如果你不熟 NACL，排查时最实用的办法不是背概念，而是直接把子网级别的流量日志打开，看看 ICMP 包是在哪一跳被拒了。很多时候，安全组是对的，NACL 才是那个“看不见的拦截点”。

第五步：实例状态正常，不代表操作系统里没拦 ICMP

AWS 控制台只负责告诉你实例有没有挂，不负责告诉你 Linux 或 Windows 里有没有关掉回应。

常见情况包括：

• Linux 上启了防火墙规则，禁止 ICMP Echo Reply。
• Windows 防火墙策略收紧，默认不响应 ping。
• 系统安全加固脚本把网络访问做了额外限制。

如果你能 SSH/RDP 进去，直接在系统里检查防火墙规则，比在云控制台猜更快。很多用户排查半天，其实只是镜像初始化时被加固工具改了规则。

账号、实名认证、充值续费：为什么这些也会影响你排障

这部分经常被忽略，但实际影响很大，尤其是新开的 AWS 国际站账号。

1）AWS 不是“先充值再用”的模式

和国内云不同，AWS 国际站通常是按账单扣费，不是先充值余额。你如果习惯了阿里云、腾讯云那种预充值逻辑，在 AWS 上很容易误判：以为“账户里没钱”才导致访问异常。实际上，AWS 主要看信用卡/借记卡扣款是否成功。

2）新账号最常见的失败点是支付验证

• 卡片不支持国际扣款。
• 账单地址与卡片信息不一致。
• 虚拟卡、预付卡触发风控。
• 频繁更换支付方式，导致账户审核延长。

如果你是企业用户，建议一开始就用公司名下可稳定扣款的卡，不要图省事上来就用不稳定的虚拟卡。AWS 风控对“第一次扣款失败”的敏感度很高，后面可能会影响实例创建、按量资源开通，甚至要求补充验证。

3）不要买来路不清的成品账号

这类账号常见问题不是“能不能登录”，而是：

• 账单主体不在你手里，后续容易被找回。
• MFA 绑定权不在你手里，改密后风险更高。
• 异常登录地点会触发风控，实例突然停用。

真正做业务，最省事的方式还是自己注册、自己绑卡、自己完成验证。否则你现在排的是 ping 不通，后面可能变成账号冻结、资源回收、账单争议，这类问题代价更高。

成本角度：为了能 ping 通，值不值得开公网

如果你只是临时测连通性，先算清楚成本再开公网 IP。AWS 现在对公网 IPv4 是有费用的，长期开着会比很多人预估得高。

方案	适合场景	成本特征	风险点
公网 IPv4 + EIP	需要外网直接访问	有持续公网地址成本	安全组、NACL 暴露面更大
仅私网 + VPN / Bastion	内部访问、企业办公	公网暴露少，成本更可控	外网不能直接 ping
SSM Session Manager	仅管理实例，不依赖公网	省公网地址费用	不是用来做外网连通性测试

如果你的真实需求只是“远程管理主机”，不一定要为了 ping 去开公网。很多企业客户最后都会改成私网 + SSM，既少一层暴露，也少一部分地址费用。只有当你明确要对外提供服务、或者要验证公网可达性时，才需要完整打通公网链路。

我见过的 3 个典型排障案例

案例 1：安全组放行了 SSH，忘了 ICMP

客户说实例完全正常，外部连不上。最后发现安全组只开了 22 端口，ping 被默认拒绝。补一条 ICMP 入站后立刻恢复。这个案例最典型，处理时间 3 分钟。

案例 2：路由表配了，但子网没关联

实例在“看起来像公有子网”的网段里，实际关联的是另一个路由表，默认路由没走 IGW。结果 SSH 有时能通、有时不通，ping 一直失败。重新关联正确路由表后恢复。这个问题最容易误导新人，因为控制台里看着“配置都有”。

案例 3：公司网络本身禁了 ICMP

用户在办公室 ping 不通，手机热点却正常。最后发现公司出口策略禁了 ICMP。这个时候你改 AWS 再多也没用，应该换网络验证。很多“云上故障”其实是本地网络策略。

最实用的排查顺序

1. 确认实例是否有公网 IPv4 / EIP。
2. 确认子网路由是否指向 Internet Gateway。
3. 确认安全组是否允许 ICMP，来源是否写对。
4. 确认 NACL 是否放行进出方向。
5. 确认系统防火墙是否拦截 ping。
6. 换一个外部网络再测，排除本地网络封禁。

你最可能会问的几个问题

Q：状态检查通过，说明实例不是没问题吗？
A：只说明 AWS 视角下实例和宿主机健康，不代表公网链路通。公网 ping 还要看路由、SG、NACL 和系统防火墙。

Q：只开 22 端口可以吗？
A：如果你要 ping，不可以。22 只管 SSH，ping 走 ICMP。

AWS S3存储优惠 Q：没有公网 IP，能不能从外网 ping？
A：不能。必须先有可访问的公网入口，或者通过 VPN/跳板机从私网测试。

Q：AWS 能不能像国内云那样先充值再用？
A：通常不是这个模式，核心是绑卡和账单扣费。支付方式不稳定，后面会影响开机、续费和风控。

Q：新账号为什么老是被风控？
A：高频换地区、频繁失败扣款、虚拟卡、异常登录地点，都会增加审核概率。企业账号最好一开始就把付款方式和主体资料准备完整。

如果你现在正卡在“ping 不通”的问题上，别先改一堆规则。先把 公网 IP、路由表、Security Group、NACL 这四层逐个确认，通常 80% 的问题都能在这一步定位出来。剩下的 20%，再去看系统防火墙和本地网络策略，效率会高很多。