路由表：数据包出门前的导航地图（网络基础系列第 10 篇）
前言
网络基础系列第 10 篇。
上一篇我们讲了子网掩码：它决定 IP 地址属于哪个"小区"。今天继续往前走：如果目标不在同一个网段，数据包到底该往哪里发？这就轮到路由表出场了。
🚀 建议阅读顺序：IP 地址 → 子网掩码 → 本篇文章（路由表） → ARP → ICMP。
一、开场：数据包出门，也要看导航
你开车去一个陌生地方，不会只盯着终点地址就踩油门。你会先开导航：走哪条路？上哪个高架？在哪个路口转弯？
数据包也一样。
应用程序只知道：
text
我要访问 93.184.216.34但操作系统必须回答一个更实际的问题：
这个包从哪块网卡发出去？下一跳交给谁？
这个决定不靠感觉 ，也不靠网卡自己悟。它靠 路由表。
一句话结论：路由表决定数据包去某个目标 IP 时，应该从哪个接口出去，以及下一跳是谁。
再短一点：
路由表是数据包出门前看的导航地图。
为了更好理解路由表在整个网络协议栈中的位置，我们先回顾一下前几篇已经登场的"角色"：
| 角色 | 负责的问题 |
|---|---|
| IP 地址 | 目标是谁 |
| 子网掩码 | 目标是否同网段 |
| ARP | 下一跳 IP 对应哪个 MAC 地址 |
| 交换机 | 目标 MAC 在哪个端口 |
| 路由表 | 去这个目标，下一跳是谁？从哪块网卡走？ |
没有路由表，系统就像拿着终点地址站在路口：地址知道了，但不知道先往哪边走。
这很像人生。
但我们今天只解决网络问题。
二、先看一张总览图
假设你的电脑配置如下：
text
本机 IP：192.168.1.10/24
网关：192.168.1.1
网卡：eth0
目标：93.184.216.34操作系统发送数据前，会查路由表。
Linux 查看路由表的标准命令：
bash
ip route输出示例：
text
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10这两行非常关键。
| 路由项 | 含义 |
|---|---|
default via 192.168.1.1 dev eth0 |
没有更具体的路由时，默认走网关 192.168.1.1，从 eth0 发出 |
192.168.1.0/24 dev eth0 ... |
192.168.1.0/24 是直连网段，从 eth0 可以直接到达 |
一句话总结：
直连网段直接发，非直连目标找网关。
当然，真实环境中的路由表可能更复杂，但先掌握这个模型已经能应对 80% 的日常场景。
三、路由表里到底有什么？
路由表中的每一条记录，本质上是在描述：
如果目标 IP 匹配这个网段，就按这条规则转发。
常见字段及其含义：
| 字段 | 含义 |
|---|---|
| 目标网段 | 要匹配的目标 IP 范围 |
| 下一跳 | 下一站交给谁（通常是网关 IP） |
| 出接口 | 从哪块网卡发出去 |
| 源地址 | 发包时优先使用的源 IP（可选） |
| metric | 路由优先级 / 成本，数值越小越优先 |
示例解读
text
10.0.0.0/8 via 192.168.1.254 dev eth0去往
10.0.0.0/8网段，下一跳交给192.168.1.254，从eth0发出。
text
172.16.0.0/16 dev eth1 src 172.16.0.10
172.16.0.0/16是eth1的直连网络，从eth1发出，源地址使用172.16.0.10。
你可以把路由表理解为一张规则表：它不只看"能不能去"，更决定"怎么去"。
四、直连路由：我家小区自己能到
当你给网卡配置 IP 和掩码时，系统会自动生成一条直连路由。
示例配置：
text
eth0: 192.168.1.10/24系统自动添加：
text
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10这意味着：192.168.1.0/24 这个网段就挂在 eth0 这条链路上。
此时如果你访问：
text
192.168.1.20系统查表发现目标属于 192.168.1.0/24，判定为直连，于是：
- ARP 解析
192.168.1.20的 MAC 地址 - 直接封装以太网帧
- 交给交换机转发
这里不需要网关。如果同网段通信还绕网关，就像你去隔壁工位递文件，非要先寄到总部------流程很完整，效率很感人。
五、默认路由：不知道去哪就先找它
默认路由通常长这样：
text
default via 192.168.1.1 dev eth0也可以写成：
text
0.0.0.0/0 via 192.168.1.1 dev eth00.0.0.0/0 匹配所有 IPv4 目标，所以默认路由的含义是：
如果没有更具体的路由匹配，就走这条。
例如访问：
text
93.184.216.34本机路由表中通常没有专门指向 93.184.216.34 或 93.184.216.0/24 的路由，于是走默认路由：
text
下一跳：192.168.1.1（网关）
出接口：eth0然后系统通过 ARP 获取网关的 MAC 地址。
⚠️ 访问公网服务器时，ARP 找的是网关的 MAC，而不是公网服务器的 MAC。
这句话在前几篇已经反复出现------不是复读机故障，而是网络分层模型的核心体现。
默认路由就像你小区的出口：你不知道某个具体地方怎么走，就先出小区、上主路。你不能站在楼下对着北京喊 ARP------北京听不到。
六、最长前缀匹配：更具体的路由优先
如果路由表里有多条路由都能匹配同一个目标，系统会选哪条？
最长前缀匹配（Longest Prefix Match）：匹配范围越小、越具体的路由，优先级越高。
示例
路由表：
text
10.0.0.0/8 via 192.168.1.1 dev eth0
10.1.0.0/16 via 192.168.1.2 dev eth0
10.1.2.0/24 via 192.168.1.3 dev eth0目标：10.1.2.8
| 路由 | 是否匹配 | 前缀长度 |
|---|---|---|
10.0.0.0/8 |
匹配 | 8 |
10.1.0.0/16 |
匹配 | 16 |
10.1.2.0/24 |
匹配 | 24 |
✅ 最终选择：10.1.2.0/24 via 192.168.1.3 （因为 /24 最具体）
类比查地址：
- 中国
- 中国 · 上海
- 中国 · 上海 · 浦东新区
目标在浦东，当然用最具体的"浦东新区"条目。
默认路由 0.0.0.0/0 也能匹配所有目标，但它前缀最短，所以永远是兜底选项。
七、metric：同样具体时，看成本
最长前缀匹配解决了"谁更具体"，但如果两条路由前缀长度相同呢？
这时候看 metric （路由成本 / 优先级）。数值越小，越优先。
示例
text
default via 192.168.1.1 dev eth0 metric 100
default via 10.0.0.1 dev wlan0 metric 600两条都是默认路由：
- 有线网卡
eth0，metric 100 ✅ 更优先 - 无线网卡
wlan0，metric 600
多网卡机器上很常见：
- 有线接公司内网
- 无线接外网
- VPN / Docker / Kubernetes 再添加一堆路由
- 虚拟机再加几张虚拟网卡
此时 ip route 输出密密麻麻，排查时要冷静：
- 先看目标 IP 匹配哪条最长前缀
- 再看同等前缀下 metric 更小的是哪条
- 不要一上来就盯着默认路由------很多包根本轮不到它。
八、下一跳必须可达
路由表里写了下一跳，不一定代表能走通 ------下一跳本身也必须可达。
示例：
text
10.0.0.0/8 via 192.168.1.254 dev eth0下一跳 192.168.1.254 必须能通过 eth0 直连到达。也就是说，本机需要能通过 ARP 获取它的 MAC 地址。
这就像导航告诉你"先去小区东门"，但东门被墙封了------路线再科学也出不去。
排查命令
bash
ip neigh show 192.168.1.254 # 查看邻居表
ping 192.168.1.254 # 测试连通性
arping 192.168.1.254 # 二层探测如果下一跳的 ARP 都失败，先别怪远端服务器------包还没离开本地链路。
九、路由表、ARP、交换机的完整配合
现在把整个发送流程串起来。
场景：访问公网服务器
text
本机：192.168.1.10/24
网关：192.168.1.1
目标：93.184.216.34第一跳帧的结构：
| 字段 | 值 |
|---|---|
| 源 IP | 192.168.1.10 |
| 目标 IP | 93.184.216.34 |
| 源 MAC | 你的网卡 MAC |
| 目标 MAC | 网关 MAC |
IP 目标是远方，MAC 目标是眼前的下一跳。
路由表决定下一跳是谁，ARP 找下一跳的 MAC，交换机把帧送到下一跳端口。
这就是前几篇知识点的最终合体------网络基础不再是孤立的名词，而是一条完整的数据包旅行路线。
十、常用排查命令（工程必备）
1. 查看路由表
bash
ip route关注：
- ✅ 直连路由是否存在
- ✅ 默认路由是否存在
- ✅ 目标网段是否有更具体路由
- ✅ 出接口 / 下一跳是否符合预期
- ✅ metric 是否导致走了"备胎"链路
2. 查看某个目标实际会怎么走（强烈推荐）
bash
ip route get 93.184.216.34输出示例：
text
93.184.216.34 via 192.168.1.1 dev eth0 src 192.168.1.10这个命令比你人工盯着路由表猜更直接------它等于让内核告诉你：如果现在发这个目标，我会这么走。
3. 查看邻居表（ARP 缓存）
bash
ip neigh确认下一跳的 MAC 是否解析成功。如果网关状态是 FAILED，路由表再正确也发不出去。
4. 查看三层路径
bash
traceroute 93.184.216.34
# 或
tracepath 93.184.216.34观察路径经过哪些三层节点。注意：traceroute 依赖 ICMP/UDP 探测，可能被防火墙过滤，结果仅供参考。
5. 抓包确认发包方向
bash
tcpdump -i eth0 -nn host 93.184.216.34多网卡场景下尤其有用：怀疑包没从预期网卡出去，就在对应网卡上抓包。眼见为实，抓包为证。
十一、典型工程场景：为什么配置了网关，却不走网关？
用户描述
我明明配置了默认网关，为什么访问某个地址却不走网关？
原因分析
有更具体的路由匹配了目标。
示例
路由表：
text
default via 192.168.1.1 dev eth0
10.0.0.0/8 dev tun0访问：
text
10.2.3.4- 默认路由
0.0.0.0/0可以匹配 10.0.0.0/8也能匹配，且更具体（/8 > /0）
✅ 最终选择 10.0.0.0/8 → 走 tun0
这类场景常见于
- VPN 客户端下发路由，将某些网段导向隧道
- Docker / Kubernetes / 虚拟机添加虚拟网卡路由
排查建议
不要只盯着默认网关，直接用：
bash
ip route get 10.2.3.4让内核直接告诉你答案。
猜网络问题，和猜女朋友为什么生气一样------成功率都不稳定。
十二、常见误区（慎入）
❌ 误区一：默认路由优先级最高
错误。
默认路由前缀 /0 最不具体。只要存在更具体的匹配路由，就会优先于默认路由。默认路由不是领导，是保底方案。
❌ 误区二：路由表只在路由器上存在
错误。
普通主机（你的电脑、服务器、容器节点）也有路由表。只要设备需要发送 IP 包，就必须决定"怎么走"。不要一提到路由表就只想到机房里的路由器。
❌ 误区三：能 ping 通网关 = 一定能上网
不一定。
能 ping 通网关，只说明本机到第一跳大概率没问题。后面还可能卡在：
- 网关没有默认路由
- NAT 未配置
- 上游网络不通
- DNS 故障
- 防火墙拦截
- 运营商链路问题
网关通了只是出了小区门，不代表高速不堵，也不代表目的地开门。
❌ 误区四：路由表里有目标路由 = 一定能到
不一定。
路由表只告诉你"往哪发"。下一跳是否可达、链路是否正常、对端是否有回程路由、防火墙是否放行，都可能影响最终通信。
路由表是导航，不是传送门。导航说能走，不代表路没塌。
十三、全文小结
本文核心要点汇总：
| 序号 | 核心结论 |
|---|---|
| 1 | 路由表决定数据包从哪个接口出去，以及下一跳是谁 |
| 2 | 直连路由表示某个网段就在本机链路上 |
| 3 | 默认路由是没有更具体匹配时的兜底路线 |
| 4 | 0.0.0.0/0 表示 IPv4 默认路由 |
| 5 | 多条路由匹配时，最长前缀匹配优先 |
| 6 | 前缀长度相同时，metric 越小越优先 |
| 7 | 下一跳必须可达，否则路由表有也发不出去 |
| 8 | ip route 查看路由表 |
| 9 | ip route get <目标IP> 查看内核实际选路结果 |
| 10 | 路由表、ARP、交换机共同完成第一跳发送 |
最后一句话
路由表负责决定下一跳，ARP 负责找到下一跳的 MAC，交换机负责把帧送到下一跳端口。
这三者配合，数据包才真正迈出第一步。
十四、下一篇预告
第 11 篇：ICMP：网络的"心跳检测"
- ping 为什么能判断连通性？
- 目标不可达、TTL 超时这些错误是谁返回的？
- ICMP 是不是只服务于 ping？
下一篇，我们继续拆解网络世界里的诊断信号。
💬 如果你对路由表有任何疑问，或者在实际工作中遇到过"诡异"的选路问题，欢迎在评论区留言讨论。
📚 本系列持续更新中，建议收藏 + 关注，不迷路。