AWS代充 AWS 路由表详解：掌握云端网络流量转发机制与配置排错指南

搜索“AWS 路由表详解”的用户，通常不是想看术语定义，而是遇到了实际问题：EC2 创建好了却不能访问公网；NAT 网关也配了，私网服务器还是无法下载软件包；VPC Peering 已建立，但两个 VPC 的应用仍无法互通；或者数据库部署在私网后，应用连接超时，不知道是路由、ACL 还是安全组的问题。

AWS代充 这篇文章直接围绕操作决策展开：什么时候该新建路由表，什么时候复用主路由表；公网子网和私网子网的目标路由怎么填；VPC Peering、VPN、Transit Gateway 分别该怎么配置；遇到网络不通时，从哪个页面开始查，如何快速定位是“路由缺失”还是“下一跳错误”。

先判断你的问题属于哪一类

在 AWS 里，很多“网络不通”并不是实例故障，而是路径设计不完整。以下是最常见的四类场景，基本覆盖大多数用户的搜索意图。

如果你还没开始配置，建议先画出一张最简单的流量路径图：源地址在哪个子网、目标地址在哪个子网、中间经过 Internet Gateway、NAT Gateway、Peering 还是 VPN。没有这一步，后续路由表很容易填错。

配置前的准备工作

账号与权限要求

如果你使用的是企业 AWS 账号，必须确认当前 IAM 用户或角色具备以下权限，否则路由表页面能看不能改：

• ec2:CreateRouteTable
• ec2:CreateRoute
• ec2:ReplaceRoute
• ec2:AssociateRouteTable
• ec2:DisassociateRouteTable
• ec2:DescribeRouteTables
• ec2:DescribeSubnets
• ec2:DescribeInternetGateways
• ec2:DescribeNatGateways

如果你在控制台里点“Edit routes”按钮是灰色，大概率不是网络问题，而是权限不完整。

前置资源检查

开始之前请确认以下资源已经准备好，避免中途卡住：

建议先规划的网段

很多路由冲突不是写错，而是 CIDR 规划有问题。比如两个 VPC 都用了 10.0.0.0/16，后面做 Peering 时无法互通。实践中建议：

• 开发环境：10.10.0.0/16
• 生产环境：10.20.0.0/16
• 数据库专用子网：划小一些，例如 /24 或 /25，便于控制
• 跨区域或混合云场景：提前预留不重叠网段

在 AWS 控制台创建并绑定路由表

步骤 1：进入路由表页面并新建路由表

登录 AWS 管理控制台，进入 EC2 或 VPC 控制台，在左侧找到“Route Tables”。点击“Create route table”。

参数填写建议如下：

常见错误：很多用户在默认 VPC 下新建了路由表，却想绑定到自建 VPC 的子网，结果找不到目标子网。这不是页面异常，而是 VPC 选错了。

步骤 2：编辑路由项

创建完成后，选中该路由表，点击“Routes”页签，再点击“Edit routes”。然后点击“Add route”。

这里的关键不是“能不能加”，而是“目标地址”和“Target”是否对应正确。

注意：不要把私网子网的默认路由直接指向 Internet Gateway。这样即使子网里没有公网 IP，也会导致设计混乱，且无法满足安全隔离目标。

步骤 3：绑定到正确的子网

很多配置失败不是路由没写，而是路由表没有关联到目标子网。进入“Subnet associations”页签，点击“Edit subnet associations”，勾选需要使用该路由表的子网。

推荐做法：

• 公网子网单独绑定公网路由表
• 私网应用子网绑定私网路由表
• 数据库子网使用单独路由表，避免误加默认出网路由

如果你只有一张路由表并把所有子网都绑上，前期省事，后期做数据库隔离、NAT 分流、跨 VPC 联通时会很难维护。

三种高频配置实操

场景一：搭建可 SSH 连接的公网 EC2

适用于个人开发者、跳板机、临时运维主机。

配置顺序如下：

• 创建 VPC，例如 10.0.0.0/16
• 创建公网子网，例如 10.0.1.0/24
• 挂载 Internet Gateway 到该 VPC
• 创建公网路由表，添加 0.0.0.0/0 指向 IGW
• 将公网子网关联到公网路由表
• 创建 EC2 时启用 Auto-assign public IP，或手动绑定 Elastic IP
• 安全组放行 22 端口，来源限制为你的办公出口 IP

如果你路由表配置正确，但 SSH 还是超时，继续检查：

• 实例是否真的分配了公网 IP
• 安全组是否允许 22/TCP
• NACL 是否拒绝入站或回包
• 操作系统防火墙是否放行 22

场景二：私网应用服务器通过 NAT 网关访问外网

这是网站应用和业务服务器最常见的做法。应用服务器不暴露公网，只通过 NAT 下载依赖、调用第三方接口。

标准配置如下：

AWS代充 常见错误案例：

• NAT Gateway 建在私网子网：私网无法出网
• 私网路由写成指向 IGW：实例没有公网地址，出网失败
• NAT 已创建但子网没重新关联正确路由表：流量仍走旧表

测试命令示例：

Linux 服务器登录后执行：curl -I https://aws.amazon.com

如果超时，再执行：ip route、nslookup aws.amazon.com、traceroute 8.8.8.8，分别确认系统路由、DNS 和网络出口。

场景三：两个 VPC 互通，应用访问另一端数据库

这类场景常见于：生产应用在 VPC-A，数据库迁移到 VPC-B；或者多个业务系统拆分在不同 VPC。

操作步骤：

• 先创建 VPC Peering Connection
• 确认两边 VPC CIDR 不重叠
• 在 VPC-A 的相关路由表中添加：目标为 VPC-B CIDR，Target 选择对应 pcx
• 在 VPC-B 的相关路由表中添加：目标为 VPC-A CIDR，Target 选择对应 pcx
• 检查两边安全组是否放行业务端口，例如 3306、6379、443

这里最容易漏的是“回程路由”。A 到 B 有路由，不代表 B 到 A 自动打通。只配单向，连接仍然失败。

涉及数据库业务时，路由表该怎么配

数据库相关问题往往表现为“连接超时”，但根源可能不同。下面给出更实用的判断方式。

如果是自建 MySQL 或 Redis，请同时检查系统防火墙：

• AWS代充 Linux firewalld：firewall-cmd --list-ports
• iptables：iptables -L -n
• MySQL bind-address 是否监听在正确网卡
• Redis 是否关闭 protected-mode 或正确绑定内网地址

很多人以为是 AWS 路由表有问题，实际上数据库只监听 127.0.0.1，外部当然连不上。

AWS代充 排错时不要只盯着路由表，按这个顺序查

当 EC2、数据库、VPN 或跨 VPC 访问失败时，建议按下面顺序排查，效率最高。

1. 先看子网关联的是哪张路由表

在 Route Tables 页面，找到该子网对应的路由表。很多故障来自“你改的是 A 表，实际子网挂的是 B 表”。

2. 再看默认路由和目标网段是否正确

重点检查：

• 公网子网：0.0.0.0/0 -> IGW
• 私网子网：0.0.0.0/0 -> NAT
• 跨 VPC：对端 CIDR -> pcx
• VPN：本地网段 -> vgw/tgw

3. 检查下一跳资源状态

即使路由存在，Target 资源状态异常也会失败。例如 NAT Gateway 处于 Failed、Peering 未 Accept、VPN Tunnel Down。

4. 检查安全组和网络 ACL

路由负责“怎么走”，安全组和 NACL 决定“让不让过”。例如 MySQL 3306 不通，路由正确也没用。

5. 检查实例本身

包括操作系统防火墙、服务监听地址、网卡配置、是否分配公网 IP、是否绑定 Elastic IP。

6. 使用 Reachability Analyzer

在 AWS 中可以使用 Reachability Analyzer 做端到端路径分析，适合定位以下问题：

• 从某个 ENI 到另一个 ENI 是否有可达路径
• 哪一跳被 NACL 或安全组阻断
• 路由是否缺失

这是比人工翻页面更稳的排错方式，尤其适合企业多账号、多子网环境。

不同用户的配置建议

AWS代充 个人开发者

建议采用 1 个 VPC、1 个公网子网、1 个私网子网的最小可用结构。

• 跳板机放公网子网
• AWS代充 应用和数据库放私网子网
• AWS代充 私网默认走 NAT Gateway；如果预算有限，可短期用 NAT 实例替代，但要自己维护

企业用户

建议按业务层拆分路由表，不要所有子网共用一张。

• Web 层、公网入口、应用层、数据库层分别控制
• 至少双可用区部署
• 统一命名规则：rtb-prod-app-apne1a 之类，便于审计

跨境业务

重点不是只看地域价格，而是先测延迟和回程链路。

• 面向东南亚用户，可优先评估 ap-southeast-1、ap-southeast-3
• 面向日本用户，可评估 ap-northeast-1
• 公网访问前先做 ICMP、TCP 和 HTTP 层测试，不要只看 ping

网站应用

建议公网子网仅放负载均衡器或 CDN 回源入口，不直接暴露应用主机。应用服务器走私网，数据库单独私网隔离。

AWS代充 数据库业务

数据库子网不要轻易配置直连公网的默认路由。跨应用访问通过 Peering、Transit Gateway 或 PrivateLink 设计，减少暴露面。

配置完成后的优化建议

安全优化

• 不要把 0.0.0.0/0 的 SSH 或 RDP 暴露给公网
• 数据库端口仅对应用安全组开放，不直接对网段全开放
• 为不同环境使用不同路由表，避免测试环境误通生产

性能优化

• 跨可用区访问数据库时，延迟和流量成本都会增加，尽量就近部署
• 跨 VPC 高频流量建议评估 Transit Gateway 或 PrivateLink，避免复杂 Peering 维护
• 访问公网资源多的私网业务，NAT Gateway 建议按可用区部署，减少跨 AZ 流量

成本优化

• 小规模开发环境可减少 NAT Gateway 数量，但生产环境不建议单点
• 大量公网静态内容尽量走 S3 + CloudFront，减少 EC2 公网出口压力
• 清理未使用的 Elastic IP、NAT Gateway、Peering 连接

AWS代充 稳定性优化

• 按可用区拆分子网和路由表，故障域更清晰
• 变更前先导出当前路由配置，避免误改后无法回滚
• 重要变更先在测试 VPC 验证，再复制到生产

如果你当前正遇到 AWS 路由表相关问题，最有效的办法不是重新建 VPC，而是先确认三件事：子网到底关联了哪张路由表、目标 CIDR 是否写对、Target 是否真的是当前场景需要的网关或连接类型。大多数网络不通，最终都能归结到这三项中的一项或多项配置错误。