亚马逊云成品号 VPC 内网互通失败？子网、路由表与安全组常见配置陷阱排查

VPC 内网互通失败时，别先从 ping 或业务报错开始猜。实际排查里，最常见的不是“云网络不行”，而是子网没有挂到正确的路由表、路由缺少对端网段、安全组只放了单向流量，或者账号侧还卡在实名认证、企业认证、充值审核和配额限制上。下面按能直接落地的顺序拆开看。

VPC 内网互通失败时，最常见的配置陷阱

先把问题分成三类：路由没到、包被拦、资源没真正开出来。这个顺序比先翻应用日志更省时间。

• 能拿到对端私网 IP，但一直超时：优先看路由表、子网绑定、CIDR 是否重叠。
• 同网段机器有的能通、有的不能通：优先看安全组、主机防火墙、是否走错网卡。
• 控制台配置看起来都对，但创建不了测试资源：优先看账号认证、充值状态、风控审核、配额限制。

1. 子网绑错路由表，或者压根没绑定

这是最容易漏看的点。很多人以为路由已经配好，实际上是改了另一张路由表，或者只改了默认路由，目标子网并没有关联上。

排查时不要只看“有没有这条路由”，要看“这个子网实际用的是哪张路由表”。如果子网关联错了，控制台里看着很完整，流量还是不会走你期望的路径。

2. 路由只有去程，没有回程

内网互通里，单向路由很常见。尤其是跨 VPC、跨账号、跨地域或通过中转组件互联时，一边配置了到对端网段的路由，另一边忘了加回程路由，就会出现请求发出去了，响应回不来的情况。

如果你在测试里看到“能发包、没回包”，先别急着改安全组，先确认双向路由是否都在。

3. CIDR 重叠或网段写错

两个 VPC、子网，甚至本地 IDC 网段只要有重叠，就很容易出现路由选择异常。常见情况是：创建时看不出来，等到要做互通、专线、VPN、对等连接时才发现冲突。

还有一种低级但常见的错误：路由条目写对端网段时少写一位，或者把测试网段和生产网段混在一起，结果排障半天，其实根本没指向目标段。

4. 安全组只放了入方向，没放出方向，或者端口不对

很多项目在安全组里只盯着入方向，忽略出方向。实际上，跨 VPC 访问里，出方向被拦也会导致连接失败。还有一种情况是端口放了，但协议没放，或者只允许了某几个源地址，结果应用层连不上。

如果是数据库、Redis、Kafka、内部 API 这类业务，建议直接对着真实端口核一遍，不要用“全部放开后再慢慢收紧”的方式长期运行，但可以短时间做验证。

5. NACL、云防火墙、主机防火墙叠加拦截

不少用户以为安全组没问题就结束了，其实流量可能还会被网络 ACL、云防火墙、操作系统防火墙挡住。尤其是从容器节点、数据库主机、堡垒机到业务实例的链路里，任何一层都可能截断。

排查时别只看云控制台，最好同步看系统内的防火墙策略、监听端口和日志记录。

6. 你连的是公网地址，不是私网地址

这个错误在做双栈环境、灰度迁移、旧系统改造时特别常见。测试人员以为自己在验证内网互通，实际上访问的是 EIP、负载均衡公网入口，结论自然不准。

确认方式很简单：把目标地址、DNS 解析结果、实际路由路径核一遍，别只看业务名。

账号购买、实名认证、企业认证，为什么会卡住 VPC 排障

很多人把网络问题和账号问题分开看，但在实际项目里，这两类问题经常缠在一起。尤其是新购账号、刚做完实名认证、企业认证还在审核、充值未到账、支付方式触发风控时，最常见的不是页面大面积报错，而是部分资源能建，部分资源申请被拒，或者配额迟迟不放开。

• 账号购买后未完成实名认证或企业认证：一些地域、规格、网络资源申请会受限，尤其是新账号更明显。
• 支付方式不稳定：信用卡、PayPal、对公转账审核未过时，容易触发风控复核，导致创建和扩容延迟。
• 充值后马上开资源：账务同步没完成时，可能出现余额已显示、资源却仍然创建失败的情况。
• 欠费或续费到期：私网链路上的实例、网关、转发组件停掉后，表面看像内网不通，实际上是资源状态异常。
• 资源限制：VPC、子网、路由表、对等连接、ENI、NAT、VPN 等默认配额不够时，排障会被“资源申请不了”卡住。

排障前先问一句：现在是“流量过不去”，还是“资源根本没法正常申请和下发”。很多项目真正卡住的是后者。

按业务场景排查，比按组件名更快

跨账号互通

跨账号时，别只看网络配置，还要看授权、共享、对端是否接受了关联请求，以及双方路由是否都补齐。一个账号看着完全正确，另一个账号没有同步变更，最后还是不通。

生产和测试隔离

这类场景最容易出现路由混用。为了省事把生产网段和测试网段写在一起，后期一加新子网就冲突。建议前期就把网段规划清楚，不然后面每次加环境都要重改路由和安全组，成本会越来越高。

亚马逊云成品号 数据库、缓存、内部 API 私网访问

这类故障通常不是“整网不通”，而是业务端口没放行，或者访问方用了错误的安全组。若是数据库，重点看数据库端口、源地址和回包路径；若是内部 API，重点看域名解析有没有指向私网地址。

容器集群或多网卡实例

容器节点和多网卡实例很容易出现“配置在节点上，流量从另一张网卡出去”的情况。排查时要同时看节点路由、容器网络插件配置、Pod 所在网段和安全组是否一致。

跨地域容灾

跨地域不通不一定是配置错误，也可能是你把高时延误判成了不通。先确认是否真的有丢包、回程是否对称、DNS 是否还在把流量打到旧地址上。容灾切换时，DNS 和路由切换往往比实例本身更容易出问题。

亚马逊云成品号 常见错误，尤其容易让人走弯路

1. 只改安全组，不查路由表。
2. 只看一侧的路由，忘了回程路由。
3. 把公网连通当成内网互通成功。
4. 测试时用的是运维机，业务实际机器却在另一张子网里。
5. 账号未完成认证、余额不足或风控未过，就急着开通大批网络资源。
6. 没有先确认配额，导致排障时连测试资源都创建不出来。

如果你还在账号开通阶段，先做这 4 个决定

这部分看起来和网络排障没直接关系，但在企业项目里非常关键。账号状态不稳，后面所有网络配置都可能被反复打断。

• 先确认认证路径：是个人账号还是企业账号，是否需要补齐实名认证和企业认证，是否涉及合规审批。
• 先确认支付方式：能否稳定完成充值、续费和自动扣费，是否会因为支付方式触发风控审核。
• 先看资源配额：VPC、路由表、对等连接、ENI、VPN、NAT 等默认额度够不够，别等到联调时才发现创建失败。
• 先按业务划分环境：生产、测试、容灾、研发最好提前分开，后面做内网互通、限流和隔离时才不会反复改网段。

FAQ

Q1：ping 不通，就一定是 VPC 内网互通失败吗？

不一定。很多环境会主动拦 ICMP。最好直接用业务端口、数据库端口或实际应用接口来判断，不要把 ping 当成唯一标准。

Q2：同一个子网里的机器，为什么还是互相访问失败？

优先看安全组和主机防火墙。还有一种情况是多网卡或容器网络导致流量走错出口，看上去像同网段问题，实际上是实例侧路由不对。

Q3：路由表里明明有到对端网段的路由，为什么还是不通？

最常见的是子网没有关联到这张路由表，或者对端没有配回程路由。再往下查，就是 CIDR 冲突和安全组限制。

Q4：跨账号、跨地域互通失败，先查网络还是先查账号？

如果连资源创建、授权、配额申请都不顺，先查账号侧；如果资源都正常，只有流量不通，再按路由、安全组、回程路径去查。

Q5：为了省成本，能不能先少配几条路由，后面再补？

可以临时验证，但不建议长期这么做。路由和网段规划前期省下来的那点时间，后面往往会变成更高的排障和重构成本。

最后的排查顺序

1. 先确认是不是访问了私网地址。
2. 再确认子网是否绑定了正确路由表。
3. 检查双向路由是否都存在，CIDR 是否冲突。
4. 亚马逊云成品号 核对安全组、NACL、主机防火墙是否放行端口和方向。
5. 最后看账号认证、充值状态、风控审核和配额限制。

亚马逊云成品号 按这个顺序排，通常能很快分清是配置问题、账号问题，还是资源限制问题。对企业用户来说，真正省时间的不是多开几个测试，而是把账号状态、网络路径和业务场景一起看。