Linux 怎样用 ip route get 判断实际出口

排查 Linux 网络问题时，先看 ip route 的默认路由，往往只能得到一个大概方向：真正发送到某个目标地址时，内核可能还会结合最长前缀、策略规则、源地址、接口和标记做选择。要回答“这个目标实际会从哪张网卡出去”，可以直接查询 ip route get。

ip route get 目标地址 会按给定的查询上下文计算一条路由，并把 dev 出口设备、via 下一跳和 src 首选源地址放在结果中。先读这三个字段，再根据策略路由场景补充 from、mark、iif 或 oif，比凭默认路由猜出口可靠。

先用目标地址查询候选出口

最小查询只需要一个目标地址。下面的命令使用文档网段作为示例，命令和输出用于说明字段含义，不代表某台机器的真实运行结果。

# 只按目标地址询问内核会选择哪条路由
ip route get 203.0.113.8

203.0.113.8 via 192.0.2.1 dev eth0 src 192.0.2.10 uid 1000
    cache

在这个示例里，203.0.113.8 是目标地址，via 192.0.2.1 是下一跳，dev eth0 是出口设备，src 192.0.2.10 是内核为这条目的发送方向偏好的源地址。uid 和末尾的缓存提示不是出口网卡本身，不要把它们混为一谈。

把 dev、via、src 读成三类不同结论

判断“实际出口”时，建议按下面的顺序读结果。dev 回答的是从哪个本地接口发出，via 回答的是交给哪个下一跳，src 回答的是发送报文倾向使用哪个本地源地址。

如果结果直接显示 dev lo，目标可能属于本机地址或本地路由；如果显示 unreachable、blackhole 或 prohibit，重点就不再是找出口网卡，而是确认路由类型和策略为何拒绝了这次发送。

策略路由场景要补齐查询条件

只传目标地址相当于询问一个简化上下文。在多网卡、VPN、容器、VRF 或基于源地址分流的主机上，同一个目标可能因为报文的来源和标记不同而得到不同结果。此时要让查询更接近真实流量。

# 指定真实的源地址，观察源策略是否改变出口
ip route get 203.0.113.8 from 192.0.2.10

# 指定入接口或出接口，模拟策略规则使用的接口条件
ip route get 203.0.113.8 iif eth1
ip route get 203.0.113.8 oif eth0

# 指定防火墙标记；数值应替换为业务实际设置的 mark
ip route get 203.0.113.8 mark 0x20

from 用于表达源地址条件，mark 用于表达报文标记，iif 和 oif 用于补充接口上下文；如果主机使用 VRF，还可以使用 vrf 名称 把查询放进对应的路由域。每次只改变一个条件，才能看出究竟是哪条策略影响了结果。

如果要确认策略规则本身，可以另外查看 ip rule 和各路由表，但它们与本次 ip route get 的职责不同：前者展示配置，后者针对给定上下文给出一次路由计算结果。

IPv6 和几个容易误读的边界

IPv6 查询要显式使用 -6，否则你可能一直在检查 IPv4 路由。源地址也应使用 IPv6 地址，不能把两种地址族的结果混在一起。

# 用 IPv6 地址族查询目标和首选源地址
ip -6 route get 2001:db8:20::8 from 2001:db8:10::10

还要注意三点。第一，ip route get 计算的是给定条件下的路由选择，不等于已经建立了 TCP 连接，也不证明远端一定可达。第二，存在多路径路由时，结果反映的是当前查询上下文下的选择，不能把一次结果写成所有连接永远固定。第三，命令没有返回可用路由时，应保留完整错误信息，继续检查地址族、策略规则、路由表和接口状态，不要自行补一个默认出口。

常见问题

只看 ip route 的 default 行可以吗？

只能作为初步线索。目标地址的更具体前缀、策略路由、源地址和标记都可能使实际选择不同，最终判断应以带真实上下文的 ip route get 为准。

src 是应用绑定的本地地址吗？

它是路由计算给出的首选源地址，不等同于应用一定已经绑定的监听地址。应用显式绑定、套接字选项和后续连接状态仍可能影响最终行为。

没有 via 是否说明出口错误？

不一定。直连网络可以直接通过设备发送，不需要网关；判断出口时应先看 dev，再结合目标前缀与接口地址确认是否属于预期链路。