很多团队把VPC和云服务器都建好了，真正要把几个网络连起来时，却常常卡在路由上。包不通、流量绕远路、回包找不到路，多数情况都能追到阿里云路由的配置。这篇文章先理清基本概念，再用一个组网案例说明阿里云路由该怎么配。
路由表到底管什么
每个VPC里都有一张路由表。子网里的数据包要去某个目标地址，路由表决定它交给哪个下一跳处理。路由表由一条条路由条目组成，每条都写清楚目标网段、下一跳类型和下一跳实例这三件事。
路由表关联的对象是交换机，实例本身不挂路由表。同一个VPC里，不同交换机可以关联不同的路由表。比如生产子网走一套出口，测试子网走另一套，两边互不影响。
系统路由和自定义路由
创建VPC之后，系统会自动生成一条系统路由，用来保证同一个VPC里的实例互相通信。这条路由删不掉，也不需要你去维护。
需要访问VPC以外的网络时，才要添加自定义路由。常见的下一跳有以下几类：
- ECS实例可以做网关，多用于自建防火墙或代理的场景。
- NAT网关让子网内的实例主动访问公网，外部无法反向主动访问内部。
- VPN网关负责和本地数据中心之间建立加密隧道。
- 高速通道或边界路由器用来对接通过专线接入的本地网络。
- 转发路由器适合多个VPC、多个地域集中互联的场景。
排查路由是否生效，可以先看目标网段有没有和系统路由冲突，再确认下一跳的状态是不是可用。路由条目的网段越精确，匹配时通常优先级越高。流量走向和预期不一致时，这一点往往是关键线索。
案例：电商企业的跨地域组网
某电商公司在杭州地域部署了订单系统，北京地域部署了会员和营销系统，线下机房还保留着一套库存系统。三边要互通，但订单系统不能直接暴露在公网上，这是前提。
团队的做法大致是这样。
- 杭州和北京各自新建VPC，网段互不重叠。这一步看起来普通，但网段一旦撞上，后面几乎每条路由都要返工。
- 两个VPC挂到同一台转发路由器上完成跨地域连接，并在转发路由器的路由表里分别加入对端网段。
- 线下机房通过专线接入阿里云，在边界路由器上配置指向云上网段的静态路由或动态路由。
- 各VPC的路由表中，访问线下库存网段的流量指定对应连接作为下一跳，不让它默认走公网。
- 需要出公网的服务保留NAT网关的路由条目，只允许更新类请求出去；内部服务之间统一走私网。
上线初期出过一个典型问题：北京的营销系统访问线下库存时超时。排查下来，请求能够到达线下，但线下机房没有指向北京网段的回程路由，回包无处可去。补上回程路由后，问题就消失了。
这件事说明阿里云路由是双向的。只配了去程、忘了回程，是很常见的疏漏。而且表现出来往往只是“超时”两个字，很难一眼看出原因。
配置时要留意的几点
网段规划要提前做。VPC之间、VPC与本地网络之间的网段一旦重叠，后期改造成本很高。项目一开始就整理一张网段规划表，把每个网段的用途和归属写清楚，比事后补救省事得多。
路由表要分层管理。不建议所有交换机共用一张路由表，可以按生产、测试、管理等业务划分，各自独立。出了问题好定位，回滚时也不会牵连其他网络。
路由和安全规则要一起看。路由只决定数据包往哪走，能不能通过还要看安全组和网络ACL。路由已经通了却访问不了，多半是安全规则拦住了，别只盯着路由表反复改。
变更前先做验证。可以在测试VPC里搭一套相同的路由结构，确认连通性和回程路径都正常，再应用到生产环境。
小结
配阿里云路由，关键是让数据包在每一跳都有明确去处。把路由表和交换机的关联关系理清，分清系统路由和自定义路由，网段提前规划好，并检查回程路径，大部分组网问题都能很快定位。具体的配额、产品规格和功能细节会随版本调整，正式变更前请以控制台和官方文档为准。
