Linux ip 命令查看策略路由命中顺序

排查 Linux 策略路由时，先看 ip rule show 得到 RPDB 的检查顺序，再用与目标流量相同的目的地址、源地址、入口接口和 fwmark 调用 ip route get。规则的 priority 数字越小越先检查；某条规则匹配后，如果关联路由表没有给出可用结果，内核才会继续看后面的规则。

想知道“哪条规则先被检查”，看 ip rule 的 priority；想知道“这组条件最后选到哪条路由”，看 ip route get。两者是规则顺序和路由解析的两份互补信息，不要把 ip route get 当成逐条规则命中日志。

Linux 内核网络文档地址：https://www.kernel.org/doc/html/latest/networking/

下面把问题收敛成一个只读的小项目：给定一个目的地址，分别模拟普通本机流量、指定源地址的流量和带 mark 的流量，整理出“规则条件—路由表—最终结果”的判断链。示例使用文档保留地址，不代表当前机器的真实配置。

项目目标：做一张策略路由命中诊断卡

假设待排查的目的地址是 203.0.113.8，可能的源地址是 192.0.2.10，入口接口是 eth1，防火墙标记是 0x2。这四个条件并不是每次都必须填写，但它们决定了规则选择器是否相同。

先把这些值写进诊断记录，再开始看规则。这样可以避免第一次查询带了源地址，第二次查询却只给目的地址，最后把两个不同的决策结果误认为“规则顺序不稳定”。

准备环境：只读查看当前 RPDB

ip rule 操作的是路由策略数据库（RPDB），而 ip route 操作的是具体路由表。第一轮只读取版本和规则，不需要为了查看顺序修改任何配置。

# 查看 iproute2 是否可用；这里只读取版本信息。
ip -V

# 按 priority 列出策略规则，先看规则顺序和 lookup 目标。
ip rule show

# 显示更完整的规则属性，便于发现 fwmark、iif、suppress 等条件。
ip -details rule show

常见的默认 RPDB 包含三条规则：priority 为 0 的 local 表、priority 为 32766 的 main 表，以及 priority 为 32767 的 default 表。实际主机可能由 NetworkManager、容器运行时、VRF 或其他网络管理组件添加额外规则，所以以当前命令输出为准。

按 priority 读取 RPDB 的检查顺序

策略规则按 priority 数字递增检查。数字越小，越早进入选择器判断；它和路由表内部的最长前缀、metric 或 preference 不是同一个排序维度。

下面是格式化后的示例输出，仅用于说明如何阅读字段：

0:      from all lookup local
100:    from 192.0.2.0/24 lookup 100
110:    fwmark 0x2/0xff lookup 200
32766:  from all lookup main
32767:  from all lookup default

阅读这份列表时可以按三列拆开：

• priority：决定这条规则在 RPDB 中的检查位置，100 先于 110，两者都先于 32766。
• selector：例如 from、fwmark、iif，决定当前流量是否符合规则。
• action：例如 lookup 100，表示匹配后尝试查询编号为 100 的路由表。

“命中”不能只理解为选择器匹配。规则匹配后，查表动作还可能没有找到可用路由，或者被 suppress_prefixlength 之类的抑制条件排除；这时 RPDB 才会继续处理后面的规则。最终判断要把规则输出和一次实际查询放在一起看。

用 ip route get 复现一次路由查询

ip route get 不是把路由表静态打印出来，而是请求内核解析一条到目标地址的路由。它可以带上 from、iif、mark 等条件；fibmatch 用于查看完整的 FIB 匹配路由。查询不会真的发送数据包。

# 先只按目的地址查询，作为没有额外选择器的基线。
ip route get 203.0.113.8

# 加入源地址，模拟源地址策略可能影响的本机流量。
ip route get 203.0.113.8 from 192.0.2.10

# 加入入口接口，模拟从 eth1 进入后需要转发的流量。
ip route get 203.0.113.8 from 192.0.2.10 iif eth1

# 加入 mark，并请求完整的 FIB 匹配信息；0x2 只是本例的示意标记。
ip route get fibmatch 203.0.113.8 from 192.0.2.10 mark 0x2

这几条命令的关键不是记住某一行示例输出，而是每次只改变一个决策输入：如果加上 from 后出口改变，优先回到含 from 的规则；如果加上 mark 后出口改变，优先回到含 fwmark 的规则。ip route get 给出的是解析结果，规则优先级仍要从 ip rule show 中读取。

把规则条件与查询结果逐项对照

为了把这个小项目做成可复用的诊断卡，可以固定四组查询。它们不写入配置，只收集同一目的地址在不同选择器下的结果。

# 用统一变量避免四组查询使用不同的目标地址。
DST="203.0.113.8"
SRC="192.0.2.10"
IIF="eth1"
MARK="0x2"

# 基线：只提供目的地址，观察普通输出路径。
ip route get "$DST"

# 源地址维度：对应 ip rule 中的 from 选择器。
ip route get "$DST" from "$SRC"

# 入口接口维度：对应转发规则中的 iif 选择器。
ip route get "$DST" from "$SRC" iif "$IIF"

# 标记维度：对应 fwmark 选择器；fibmatch 用于展开 FIB 匹配路由。
ip route get fibmatch "$DST" from "$SRC" mark "$MARK"

对照时可使用下面的判断表：

特别要注意 ip route get 与 ip route show 的差别：后者是在列出现有条目，前者是在给定查询键下请求解析结果。排障时只看某张表的静态条目，无法替代带完整条件的 route get。

验收：怎样确认自己真的看懂了命中顺序

一张合格的诊断卡至少应当能回答五个问题：

1. 当前规则按什么 priority 顺序排列，是否存在数字更小的自定义规则？
2. 目标流量的源地址、入口接口和 mark 是否与查询命令一致？
3. 匹配到的规则指向哪一张路由表，表内是否存在能返回结果的条目？
4. 是否存在 suppress_prefixlength、黑洞、不可达或禁止类型等会改变结果的动作？
5. 最后的 ip route get 输出是否与规则和路由表的解释一致？

如果这五项都能从命令输出中指出对应字段，基本就能解释“为什么这条规则先检查、为什么没有停在那里、最后为什么落到 main 或其他表”。如果只能看到一个出口接口，却说不出使用了哪些查询条件，说明诊断输入还不完整。

ip rule 的数字越大是不是越先命中？

不是。RPDB 按 priority 数字递增检查，数字越小越先。32766 的 main 规则通常会晚于 priority 为 100 的自定义规则。

ip route get 能直接显示第几条 ip rule 命中吗？

它主要返回一次路由解析结果，不能简单当成逐条 RPDB 规则的命中日志。要判断顺序，需要把同一查询条件与 ip rule show 的 priority、selector 和 lookup 目标对照。

为什么只执行 ip route show 看不出策略路由结果？

ip route show 展示的是路由表条目，未必带上源地址、入口接口和 mark 这些策略键。需要使用带完整条件的 ip route get 复现一次查询。

fibmatch 和普通 ip route get 有什么区别？

普通查询返回解析后的路由结果，fibmatch 更偏向展示完整的 FIB 匹配路由。它仍然不是一份逐条策略规则执行日志，规则顺序仍需从 RPDB 输出中确认。