阿里雲帳號充值方案 阿裡雲專線連線後，本地機房與阿裡雲 ECS 互相 Ping 不通路由丟包排查

问题现象先说清楚

很多人把阿里云专线接通后第一时间的目标，定义成“本地机房能 Ping 到 ECS，ECS 也能回 Ping 本地网段”。实际落地时，专线状态看起来正常，BGP 邻居也已经建立，路由表里能看到对端网段，但 Ping 还是不通，甚至表现为单向通、间歇性通、业务端口能连而 ICMP 不通。这类问题最容易让人误判成“专线质量差”，其实真正的原因通常藏在路由回程、策略控制和报文路径不一致里。

排查这类问题，不能只盯着专线链路本身。专线只是把物理和三层通路打通，真正决定能否互通的，是本地网关、云上 VPC 路由、ECS 安全组、网络 ACL、源地址选择、回程路径以及中间设备是否做了 NAT、策略路由或丢弃 ICMP。也就是说，Ping 不通只是表象，核心要回答的是：请求包走了哪条路，回包又走了哪条路，在哪一跳被拦住了。

先建立一个正确的排查顺序

排查专线连通问题，建议按“链路状态、路由可达、策略放行、报文验证、特殊场景”五层来做。不要一上来就改配置，先把每一层的事实确认清楚。很多故障之所以反复出现，就是因为把路由问题当成安全组问题，或者把安全组问题当成专线问题，最后改来改去，反而把原本能通的路径改坏了。

第一层：先看链路是不是健康

确认专线、边界路由器、云企业网或专线网关状态正常，BGP 邻居已建立，静态路由已下发。链路正常不等于一定可达，但链路异常一定不可达。这个阶段要重点确认：专线接口是否 Up，隧道或物理链路是否稳定，BGP 是否有抖动，是否存在频繁重连、hold timer 超时、路由反复收敛的情况。

如果专线链路本身不稳，Ping 的表现常常是“有时通、有时丢”，而不是完全不通。此时先不要纠结 ECS 的安全组，先把底层链路波动压下去。

第二层：确认路由是否真的双向可达

专线场景里，Ping 不通最常见的原因不是去程没路，而是回程没路。很多本地机房能把流量送到云上，是因为本地路由已经指向阿里云；但 ECS 回到本地机房时，云上路由表里没有正确的返回路由，或者返回流量被引到另一条默认出口，导致请求和响应不走同一条路径，最终被中间设备丢弃。

排查时要明确两件事：第一，本地网段是否已经被云上路由表学习到或手工配置进去；第二，云上 ECS 所在 VPC 子网的路由表里，去往本地网段的下一跳是否指向专线相关网关。若使用了企业网关、云企业网实例、VBR 或其他中转组件，还要确认路由传播是否开启，目标路由是否真正生效，而不是只写在配置里却没有下发。

很多故障的本质是“看得到路由，走不到路由”。比如控制台里显示路由已添加，但实际因为优先级被更精确的路由覆盖，或者被黑洞路由、默认路由抢占，结果真实转发路径并不按预期执行。此时要用路由表逐级确认，不要只看一处。

第三层：检查安全组和网络 ACL

ECS 侧最容易被忽略的是安全组。很多人以为安全组只影响 TCP/UDP 端口，实际上 ICMP 也会被拦截。Ping 不通时，先检查 ECS 入方向是否允许 ICMP Echo Request，出方向是否允许 Echo Reply。安全组是有状态的，但如果入方向本身被拒绝，回包就无从谈起。

网络 ACL 也要一起看。ACL 常见的问题不是完全禁止，而是只放行了业务端口，没有放行 ICMP，或者放行规则写在了错误的优先级上。尤其在多网段、多子网共用 ACL 时，很容易出现某个子网能通、另一个子网不通的情况。此时不要只盯着 ECS 实例，子网层面的放行策略同样关键。

阿里雲帳號充值方案 如果业务能访问但 Ping 不通，不代表网络没问题。很多企业安全策略会刻意屏蔽 ICMP，只允许业务端口通行。此时应该区分“网络不可达”与“ICMP 被禁止”这两种情况。前者是路由或链路问题，后者只是探测协议被拦截。判断方法很简单：如果 TCP 业务正常而 Ping 不通，大概率是 ICMP 策略问题；如果业务和 Ping 都不通，再去查路由和回程。

最容易踩坑的几个根因

回程路由缺失或走错出口

这是专线场景里最常见的故障。比如本地机房网段 10.10.0.0/16 能到云上 172.16.0.0/16，但云上返回 10.10.0.0/16 时，却因为路由优先级、默认路由或多出口策略，走到了公网出口，最终被 NAT 或边界防火墙丢掉。表面看是 Ping 超时，本质上是双向路径不一致。

验证时可以从云上 ECS 反向 Ping 本地机房网关或一台固定主机，同时在本地边界设备上抓包，看回包是否真的从专线口回来。如果请求包进了专线，回包却从公网口出去了，问题就非常明确了：需要修正云上或本地的路由策略，让对端网段的回程强制回专线。

安全组只放了业务端口，没放 ICMP

这是第二高频问题。因为很多运维在做连通性验证时默认 Ping，但生产环境中未必需要开放 ICMP。于是出现一种典型现象：专线通了，业务端口可达，但 Ping 不通。排查时要先确认是不是策略故意如此。如果业务验证通过，就不要把 ICMP 不通误判成链路故障。

如果确实需要 Ping 作为日常巡检手段，那就明确在安全组和 ACL 中放行对应的 ICMP 类型，同时记录在变更规范里，避免后续被基线加固策略重新覆盖。

本地网关做了 NAT 或策略路由

本地机房常见的边界设备会做源地址转换。问题在于，NAT 后云上看到的源地址可能不是原始机房网段，而是另一个中间地址。这样一来，云上回程如果仍按原始网段回，就会找不到对应路径；如果按 NAT 后地址回，又可能被本地设备当成异常流量丢弃。

更隐蔽的是策略路由。很多边界设备会根据源地址、目的地址、端口或接口做分流，同一个网段的不同流量可能走不同出口。Ping 用的是 ICMP，和业务流量可能走的不是同一条策略，结果就是“业务通、Ping 不通”。这时候不能只看静态路由，而要看实际策略匹配结果。

MTU 不匹配导致看似通、实际丢包

专线环境下，MTU 问题经常被低估。链路两端如果存在封装开销，实际可用 MTU 会小于默认值。小包 Ping 可能正常，大包 Ping 就开始丢；TCP 建连偶尔成功，数据一多就卡住。很多人会误以为是线路抖动，其实是分片或 PMTUD 相关问题。

排查时可以用不同大小的 Ping 包做验证，逐步增大长度，观察是否在某个阈值开始丢包。若确认是 MTU 问题，就需要统一调整链路两端的 MTU、MSS，或者检查中间设备是否放行 ICMP 的分片相关报文。这个问题如果不处理，后面即使路由和安全组全对，业务依然会出现“偶发卡顿”和“部分页面打不开”。

实战排查方法

从本地机房到 ECS 做分段验证

不要只做端到端 Ping，应该把路径拆开。先从本地机房 Ping 阿里云专线下一跳地址，再 Ping VPC 网关地址，最后 Ping ECS 内网地址。每一段都通，才能说明问题真正落在最终主机层。如果中间某一段不通，故障就能快速收敛到对应设备。

同样的思路也适用于云上反向排查。先在 ECS 上 Ping 本地边界地址，再 Ping 机房核心网关，最后 Ping 业务服务器。这样可以区分是云上出不去，还是本地进不来。

同时看三类证据

第一类是控制面证据，包括路由表、BGP 邻居、专线状态、传播结果。第二类是数据面证据，包括抓包、会话表、NAT 表、ACL 命中记录。第三类是主机面证据，包括 ECS 上的防火墙、系统路由、反向路径检查、ICMP 限制策略。只看其中一种，很容易误判。

比如云上路由已经正确，但 ECS 操作系统里又配置了额外的静态路由，导致回包从另一个网卡出去；或者安全组没问题，但系统防火墙把 ICMP 全部拒了。控制台里看不出来的问题，往往要落到实例内部和边界设备上才能发现。

阿里雲帳號充值方案 抓包比猜测更可靠

阿里雲帳號充值方案 排查网络问题，最忌讳凭感觉改配置。最有效的方法，永远是抓包。无论是在本地边界网关上抓包，还是在 ECS 上用工具观察 ICMP 请求和响应，都能把“包有没有到”“回包有没有走”“中间哪一跳断了”说清楚。只要抓到包，就能缩小范围。

例如本地机房 Ping ECS，ECS 没有收到请求包，说明问题在上游路由或安全策略；ECS 收到了请求包却没回，说明主机安全组、系统防火墙或内核策略有问题；ECS 发了回包但本地没收到，说明回程路径或中间设备有问题。这个判断比反复改配置高效得多。

处理建议按优先级落地

如果你现在正面对“专线已通但互 Ping 不通”的场景，可以按下面的顺序处理：

先确认本地和云上两边的路由是否完整，尤其是对端网段的回程路由是否存在；再检查安全组、ACL 和主机防火墙，确认 ICMP 是否被放行；接着检查是否存在 NAT、策略路由、默认路由抢占等路径偏移；最后再看 MTU、分片和链路稳定性。这个顺序能最大程度避免来回试错。

如果是生产环境，建议把验证动作拆成两类：一类是连通性验证，重点看路由和回程；另一类是策略验证，重点看安全组、ACL 和协议放行。把两类问题混在一起，很容易把临时放通当成永久修复，或者把协议屏蔽误判成网络故障。

经验总结

阿里云专线接通之后，本地机房与 ECS 互相 Ping 不通，绝大多数情况不是“专线没通”，而是“通路存在，但返回路径不对”或者“通路存在，但协议被策略拦了”。真正的排查核心，是把网络路径拆开看，别只盯着一个 Ping 结果下结论。

如果把这类问题归纳成一句话，就是：先查路由，再查策略，最后查报文。路由决定能不能到，策略决定能不能放，报文决定问题到底出在哪一跳。按这个思路走，专线故障基本都能收敛到具体设备、具体网段、具体规则，而不是停留在“感觉不通”的层面。

对于后续运维，建议把专线开通后的验收清单固定下来：双向路由核对、ICMP 和业务端口放行、NAT 与策略路由确认、MTU 检查、抓包留证。这样一旦再遇到丢包或互 Ping 不通，就能直接按清单排查，不用每次从头猜。