VPC对等连接不通排查方法详解

云服务器之间明明配好了 VPC 对等连接，控制台也显示“已激活”，两台 ECS 之间的 ping 包却一去不回。这种“表面通了，实际不通”的情况在阿里云上并不罕见——往往不是服务故障，而是路由表、安全组或者网络 ACL 某个环节的配置出了遗漏。把排查路径梳理清楚，比频繁重建连接更治本。

本文由 云国际服务商『 云老大 飞弟：@yunlaoda360 / YunLaoDa-云服务器•运维部门•撰写』如需转载请注明！

VPC对等连接不通，先查明原因

VPC 对等连接是阿里云内两个 VPC 间基于内网 IP 直接路由的互通通道，它不依赖于公网，也不收取实例费用，只对跨地域流量收取数据传输费（同地域免费）。可即便配置已完成，从一台 ECS 去 telnet 对端业务端口，超时的概率仍然不低。原因很容易归为三类：对等连接状态没有真正进入“已激活”，路由表只设了单边的目标网段，以及安全组或子网 ACL 未放行两端的流量。更隐蔽的是，同一个对端 VPC 内，部分 ECS 能通、部分不通，往往暴露出子网关联的路由表和安全组不一致。所以排查不能盯着某一个点，而要沿着“状态—路由—安全”这条链路逐段验证。

为什么“已激活”状态还 ping 不通？

“已激活”只是对等连接生效的必要条件，不是充分条件。阿里云对等连接仅在两端状态均为“已激活”时才实际工作，但路由表、安全组和主机内部防火墙任何一个环节没放行，流量就过不去。实际碰到过这样的案例：跨账号对等连接双方都点了接受，状态正常，但发起端的 ECS 始终连不上对端的数据库。排查后才发现，对端虽然加了一条指向发起端 CIDR 的路由，却忘了把这条路由关联到数据库所在的子网，数据包根本进不去目标网段。至于 ping 不通，还有一个常见陷阱——ICMP 协议很可能被对端安全组或者操作系统的默认规则禁掉了，用 ping 作为唯一判断标准误判率远高于直接测试业务端口，telnet 端口成功率更能反映真实连通性。

路由表和安全组，谁在拦截你的流量？

两者的拦截位置不同，踩坑的方式也不一样。路由表决定的是流量能不能从源端走到对端 VPC，属于“能不能找到门”；安全组和网络 ACL 控制的是到了门口之后让不让进门。实际操作中，单向配置的问题经常被低估——多数人只检查本端的安全组入方向是否放通了对端 CIDR，却忽略了如果对端安全组自定义过出方向规则，即便数据包过来了，回包也可能被丢弃。路由表同样需要双向配置，发起端和对端 VPC 都要添加指向对方 CIDR 的“对等连接”类型路由条目，且目标网段不能与所在 VPC 的 CIDR 重叠。倘若两个 VPC 的子网规划时有重叠，上层路由无论如何都解决不了冲突，只能重新规划网段。排查时一个快速的定位方法：临时把安全组入方向放通 0.0.0.0/0，如果连通问题消失，基本可以确认是安全组规则需要收紧；如果还是不通，就要优先级推高去检查路由表和子网 ACL 的关联关系。

核对对等连接状态

对等连接在控制台的状态展示，是整个排查链路中最前置也最容易被误读的环节。不少团队看到“已激活”就以为万事大吉，实际仅仅是两端握手成功，并不能代表路由、安全策略已经生效。排查时建议先盯住两个动作：看状态，看操作记录。

查看连接状态方法

登录阿里云VPC控制台，在内网互通的对等连接列表中，每一条连接都会显示发起端与接受端各自的状态。需要重点确认的是两端状态是否为“已激活”。如果任何一端显示“已接受”或“已过期”，意味着对方尚未完成激活接受，或连接因超时已被系统关闭。跨账号场景下，子账号往往缺少查看对方状态的权限，此时需要主账号或拥有 AliyunVPCFullAccess 权限的 RAM 账号配合确认，否则排查一开始就走偏了。

确认是否激活生效

“已激活”只是链路建立的前置条件，并非连通性保证。实际生效的标志是：两端 VPC 路由表中均已存在指向对端CIDR的“对等连接”类型路由条目，且路由关联的子网正确。如果仅有发起端配置了路由，对端路由表缺失，流量包到了对端 VPC 后仍会被系统丢弃，表现为 ping 或 telnet 超时。云老大这类服务商在帮助用户做多 VPC 架构评估时，通常会用 traceroute 辅以流日志验证双向路径，快速排除单边配置的问题。

状态异常处理建议

遇到“已过期”状态，意味着接受方在 7 天内未完成接受操作，连接已经被系统自动释放，只能删除重建。碰到“已拒绝”则说明对方主动拒绝了请求，需要沟通后重新发起。还有一种容易被忽略的情况：连接状态正常但控制台无报错，实际不通。此时应先检查该连接是否存在跨地域计费导致账号欠费被停用——阿里云对跨地域对等连接按流量收取数据传输费，同地域免费。如果欠费，连接不会被删除，但流量会被静默中断，控制台看不出任何异常。这类隐性原因仅靠看状态无法发现，需要结合业务流量中断时间和计费记录交叉定位。

检查路由表配置

路由表是对等连接能否通路的“总闸”，配置不完整或目标网段写错，控制台状态再“已激活”也不会有实际流量通过。排查这类问题时，一个被反复验证的经验是：双向路由缺一不可，发起端与被对端都要在各自VPC的路由表中添加指向对方CIDR的条目，且下一跳类型必须选“对等连接”。很多故障其实只是对端VPC漏配了一条表项，自查时很容易只盯着自己这一侧。

添加路由表条目

路由条目的目标网段需要精确覆盖对端VPC内需要通信的子网。如果只是想让某一台ECS访问对端数据库，不能只写数据库所在子网的小段，而必须包含整个VPC的CIDR或实际通信的全部网段，否则部分回程流量会被丢弃。另外，下一跳实例必须选到对应的对等连接ID，误选“NAT网关”或“ECS实例”会导致路由失效——这在跨账号场景里更为常见，因为对端ID不易辨认。

确认路由是否冲突

当两个VPC的CIDR存在任何重叠时，路由表无法区分流量应该发往本地还是对端，这是对等连接不通的硬伤。曾有多VPC互联的项目因为早期规划随意，A、B两个VPC用了同一个/16网段，建完对等连接后持续超时，最终只能重建VPC或改用云企业网做策略路由绕过。如果业务不允许改网段，建议提前评估云企业网CEN（企业版）的转发路由器能力，它支持多路由表隔离和更灵活的下一跳，可以规避单点对等连接的CIDR冲突陷阱。

关联子网要正确

一条路由表只有关联到正确的子网才会真正作用于该子网内的资源。检查时常发现，路由表条目有了，但只关联了VPC内的A子网，而需要通信的ECS恰好在B子网，造成“部分实例能通、部分不能通”的假象。处理办法是在VPC路由表列表里点进具体路由表，确认“关联子网”列包含了哪些子网；如果没覆盖全，去子网详情页切换绑定的路由表。如果需要不同子网走不同路由策略，可以建多张路由表分别关联，但在基础对等连接排错阶段，统一用默认路由表绑全子网是最快收敛问题的方式。

检查安全组规则

安全组的作用：实例级防火墙

安全组是阿里云上直接作用于ECS网卡的实例级防火墙，其规则优先级高于VPC内部路由——哪怕路由表与对等连接状态均正常，安全组未放行同样会导致报文被丢弃。在实际排查中，一个容易被低估的事实是：安全组入方向默认拒绝所有流量，出方向虽默认放行全部，但一旦被自定义改写，就构成双向拦截风险。因此，很多“已激活却不通”的故障最终都落在这一层。

入方向规则：对端流量能否进来

排查前先明确一个前提：对等连接是双向交互，本端ECS必须能接收来自对端VPC的请求包。检查时重点关注本地实例关联的安全组入方向规则，是否已添加对端VPC的CIDR或具体IP作为源地址，并放通了业务所需端口。常见遗漏包括只开放80/443而忽略数据库3306、Redis 6379等内部端口，以及ICMP协议未显式放行导致ping丢包。另外，部分云镜像默认禁用了ICMP响应，必要时优先用telnet <对端IP> <端口>测试实际服务，避免被ping结果误导。

出方向规则：回程流量不能默认为畅通

即便本端入方向配置无误，对端安全组的出方向规则也会直接影响连通性。默认安全组出方向允许所有流量，但不少生产系统会出于安全要求，将出方向改为按需放行。一旦对端ECS的自定义出方向规则未包含本端VPC网段，回包请求就会被直接丢弃，造成“单边通”的假象。这类问题隐蔽性极高，因为用户往往只检查入方向。临时排查时，可在对端安全组出方向短暂放通0.0.0.0/0，如果马上恢复正常，说明出方向规则存在问题，后续再将授权范围重新收敛至最小必要网段。

排查其他潜在因素

状态确认、路由双写、安全组放行——这三板斧走完，理论上链路已经打通。但实际生产环境中，仍有约15%-20%的对等连接故障卡在更隐蔽的环节。下面这几个坑，踩过的人不在少数。

网络ACL的影响

网络ACL是子网级别的无状态防火墙，跟安全组的实例级管控不是一回事。一个容易漏掉的细节：网络ACL的入方向和出方向规则是独立生效的，而且默认出方向并不像安全组那样全放通。如果你在子网上绑定了自定义ACL，只配了入方向放行对端网段，出方向没配回程流量的放行规则，就会出现单通——这类故障往往表现为telnet对端端口时能建立连接，但后续数据交互瞬间中断。排查时回到VPC控制台的“网络ACL”页签，逐一核对入/出两方向的规则条目。如果快速定位问题，可以临时将出方向也放通0.0.0.0/0，测试通过后再收敛，这比逐条比对效率高得多。另外，多个子网关联不同ACL的情况也很常见，部分ECS能通、部分不通多数就是出在ACL或子网路由表关联不一致上。

云主机防火墙检查

走到这一步，云平台层面的管控已经没问题了，但很多人忘了——阿里云不会替你管ECS系统内部。Linux自带的iptables或firewalld，Windows的Windows Defender防火墙，默认策略在不同镜像版本里差异很大。CentOS 7 Minimal镜像通常iptables全空，但某些加固镜像（比如等保加固版）会预置规则，甚至直接禁ping。实际排查中，我们遇到过控制台一切配置正确、安全组全放通、ACL没开，但ICMP和TCP都失败的情况，ssh上去一查，iptables里有一条REJECT all规则挂在INPUT链底部。验证这个环节有个通用做法：在ECS内执行traceroute看数据包断在哪一跳——如果到了对端IP前几跳都通，最终一跳挂掉，基本锁定是目标主机内部防火墙。建议优先用telnet或tcping测业务端口，不要死磕ping，ICMP被系统防火墙干掉太常见了。

跨账号跨地域问题

跨账号的对等连接多了一层组织边界，故障点也相应增加。状态方面，发起方创建后，接受方必须在控制台“对等连接”列表里手动确认接受——这个操作在RAM子账号下经常因为没有AliyunVPCFullAccess权限而失敗，但控制台提示不够直接，容易被忽略。跨地域的对等连接还有一个物理层面的硬伤：延迟放大和丢包率抬升。同地域对等连接走的是骨干网内网通路，延迟基本在1ms以内；跨地域走的是阿里云的跨域传输链路，华东到华南实测单向延迟通常8-15ms，偶尔出现0.1%-0.3%的瞬时丢包。如果业务对延迟敏感（比如数据库同步、高频交易回调），这个差异必须做前期评估——此时单纯靠对等连接未必是最佳方案。另外，跨地域流量按量计费这一点容易在预算上打个措手不及，按0.5元/GB（以华东-华南为例）算，一条持续跑满100Mbps的同步任务每月能产生3TB+数据量，费用不算小数。

快速解决与预防措施

实际运维中，大部分VPC对等连接不通的问题都可以在10分钟内定位到根因——前提是按正确的顺序排查。我们整理了一份速查表，经过多个生产环境验证，能覆盖90%以上的常见故障场景。

排查流程速查表

按照“状态→路由→安全→主机”的层级逐项检查，不要跳步。第一步，登录控制台确认对等连接两端均为“已激活”状态，跨账号场景下需对方手动接受请求，过期未接受会自动变为“已过期”。第二步，检查两端VPC路由表是否都添加了指向对端CIDR的条目，下一跳类型必须为“对等连接”，且关联到正确的子网——这一步是重灾区，很多运维只检查了发起端，遗漏了对端路由。第三步，逐项验证安全组和网络ACL规则：安全组需在入方向放行对端VPC的CIDR及业务端口，网络ACL如果启用，入方向和出方向都要显式放行，默认规则是拒绝。第四步，登录ECS执行 telnet <对端IP> <端口> 测试实际业务端口，不要依赖ping——ICMP协议经常被安全组或系统防火墙静默丢弃。如果前四步都确认无误但依然不通，检查ECS操作系统内部的iptables或firewalld规则，以及应用层是否绑定了正确的监听地址（0.0.0.0而非127.0.0.1）。测试阶段可以临时将安全组入方向放宽到0.0.0.0/0来快速排除安全组因素，定位后立刻收紧，避免长时间暴露。

配置优化建议

对等连接本身不收实例费用，同地域流量免费，这使得它在点对点场景下成本极低，但跨地域流量按量计费，如果有持续的大流量互通需求，需要提前评估数据传输成本。多VPC互通超过3个时，点对点对等连接的配置复杂度呈指数级增长——每个新加入的VPC都要与现有所有VPC建立双边连接并配置双向路由。这种情况下，企业版云企业网CEN是更合理的选择，它通过中心化的网络实例管理路由自动分发，减少了单条链路逐一排查的低效问题。对于团队配置经验不足、或业务线较多导致路由策略频繁变更的场景，让像云老大这类服务商做一次整体的网络架构评估，通常能把链路故障的排查时间从小时级压缩到分钟级。