Linux ip route get 怎么确认出站网卡和源地址：策略路由、mark 与连通性核对

一台 Linux 主机同时接了业务网卡、管理网卡和一条 VPN 线路时，哪怕把 ip route show 里的默认路由全翻一遍，也没法直接确定某个向外发起的请求最终会从哪块网卡出去。更稳妥的做法是用 ip route get 模拟一次内核原生的路由查询，再把返回结果里的源地址、出口设备、下一跳和对应的策略条件逐一核对清楚。

多出口场景下，ip route show 只能列出所有候选路由规则，只有针对具体目的地址发起的 ip route get 查询，才能拿到内核实际为这次请求选中的出站网卡和源地址。

先把“默认路由展示”和“实时路由查询”分开

ip route show 展示的是当前路由表里已经录入的所有条目，作用是确认已配置的规则是否存到系统里；ip route get 则是针对某一个具体目的地址做完整的路由解析，直接输出内核为这次查找最终选出的路径。两者看起来输出格式相近，实际排障价值差很多：前者只能回答“系统里有哪些可选的路由条目”，后者才能回答“这次向外发包实际会选哪条路径”。

ip route get 203.0.113.20

日常查询的常见输出类似下面这样，字段不一定会全部出现：

203.0.113.20 via 192.0.2.1 dev eth0 src 192.0.2.10 uid 1001
    cache

先记下来四个核心核对项：via 是解析得到的下一跳地址，dev 是最终选定的出口网卡，src 是内核推荐这次连接使用的源地址，uid 是本次查询时手动带入的用户上下文参数。不要把 cache 当成“链路已经连通”的依据，它只说明这次路由查找成功返回了已经解析过的目的项而已。

多网卡时，先固定源地址再验证出口选择

如果主机同时插了两张以上业务网卡，直接裸查目的地址只能看到内核的默认选择逻辑。要验证某个业务指定使用的源地址会匹配哪条策略，用 from 把变量固定下来再做查询：

ip route get 203.0.113.20 from 192.0.2.10
ip route get 203.0.113.20 from 198.51.100.10

两条命令得到的 dev 或者 via 不一样，通常就是源地址路由策略或者路由优先级在起作用。如果结果完全相同，也不要直接判定策略路由失效，先按顺序查看路由规则和各自定义路由表：

ip rule show
ip route show table main
ip route show table all

核对顺序很关键：先看路由规则的优先级排序，再看规则指向的对应路由表，最后确认这个表里是不是真的有匹配目标前缀的条目。如果只翻 main 主路由表，很容易漏掉自定义表里配置的默认路由规则。

fwmark 和入口设备会改变最终查找条件

透明代理、VRF 或者防火墙策略场景下，经常会用数据包标记来参与路由选择。这种场景下可以把对应标记带入路由查询条件：

ip route get 203.0.113.20 mark 0x2
ip route get 203.0.113.20 from 198.51.100.10 mark 0x2

mark 只是你手动传入的查找条件，前提是系统里的 ip rule 规则确实能匹配到这个标记。内核文档里也特意提到，反向路径检查是否会纳入 fwmark 逻辑，会受 src_valid_mark 等内核参数设置影响；所以“正向路由查找选到了 VPN 线路”和“回包一定能通过 rp_filter 校验”是两件完全独立的事。

ip rule show
sysctl net.ipv4.conf.all.src_valid_mark
sysctl net.ipv4.conf.all.rp_filter

connected 参数适合检查源地址二次选择逻辑

不带 from 参数时，ip route get 只会先按目的地址做一次路由查找。加上 connected 之后，如果第一次查找结果给出了首选源地址，工具会自动用这个源地址再发起一次路由查找；在复杂策略路由环境里，第二次的查找结果很可能和第一次完全不同：

ip route get 203.0.113.20 connected

这条命令很适合发现“默认查询看起来走 eth0，内核选完源地址后实际应该走 eth1”这类边界场景。它依旧只是路由层面的查询操作，不会真的向外发出 TCP SYN 包，也不会验证远端端口是不是正常监听。

用真实连接把路由证据补全闭环

路由层面的查询全部通过后，再做一次和实际业务协议匹配的连通性验证。TCP 类业务可以先用指定源地址发起短连接测试；UDP 服务则要结合抓包或者服务端日志，确认测试报文是不是真的送到了对端。

curl --interface 192.0.2.10 --connect-timeout 3 https://example.com/health
ip route get 203.0.113.20 from 192.0.2.10
ss -ntp

如果 ip route get 显示的出口和抓包结果不一致，优先排查网络命名空间、VRF、容器内部的路由规则，确认业务应用有没有自行绑定 socket 固定出口。如果出口完全一致但连接失败，再依次检查 DNS 解析结果、下一跳邻居状态、远端端口状态和两端防火墙规则，不用反复回去修改默认路由条目。

常见误判与复测清单

• 把 ip route show default 的输出当成所有目的地址的最终通行路径；应该改用具体的业务目标地址逐一做 ip route get 查询。
• 只看 dev 的出口结果不看最终返回的 src；多出口主机可能选对了网卡，却用了上游网络不认可的源地址发起连接。
• 发起查询时没有带上 from 或者 mark 限定条件；相当于直接把策略路由最核心的输入条件给漏掉了。
• 把路由查询成功等同于远端服务可达；必须补一次 TCP/UDP 层的实际验证，同时记录好执行命令时所在的网络命名空间和操作时间。

相关问题

为什么 ip route get 有时输出里带 cache 字段？

它只是表示内核返回了之前已经解析过的目的项记录，完全不等价于远端服务运行状态正常。后续还是要通过对应业务协议的实际测试，才能确认连通性没问题。

指定 oif 参数能不能证明应用最终会走这张网卡发包？

不能。oif 只是你手动传入的查询限定条件，只适合做假设场景验证；实际应用可能运行在另一个独立的网络命名空间里，也可能自行绑定了源地址和出口设备。

策略路由核对完全部正确但回包通信失败要怎么排查？

继续检查反向路径过滤规则、对端的回程路由配置、fwmark 标记有没有在双向路径上保持一致，同时确认服务端服务确实监听在预期的 IP 地址上。

收尾：留下可复现的四元证据

一次可以稳定复现的 Linux 出站链路排障，至少要留存目标访问地址、查询时的全部限定条件、dev/src/via 的完整输出结果和实际业务连通性验证记录。下次再遇到“默认路由配置正常但业务还是持续超时”的问题，就可以先复现内核的路由选择逻辑，再判断问题根源是在路由层面、回程链路还是上层应用本身。