Linux ip rule 优先级冲突时如何判断实际路由表

Linux ip rule 出现多条规则都能匹配时，不要按命令输出的感觉猜最终路由。正确判断方法是：先把 RPDB 按 priority 从小到大排列，再把真实数据包的源地址、目标地址、入口网卡和 mark 原样带入 ip route get，最后确认返回结果对应的 table 和下一跳。

priority 数字越小，规则越先处理。规则命中了某张表，不等于这张表一定能给出可用路由；如果该动作没有成功，RPDB 可能继续检查后面的规则。

先列出 RPDB，确认谁会先匹配

ip rule 操作的是路由策略数据库。每条规则由匹配条件和动作组成，动作通常是查询某张路由表。先用详细列表保留现场：

# 显示所有策略规则，包含协议和更完整的属性
ip -details rule show

# 同时查看常见数字表名，避免把 100、200 看成规则优先级
ip route show table 100
ip route show table 200

重点记录三列：priority、selector 和 lookup/table。常见默认规则是 priority 0 查询 local 表、32766 查询 main 表、32767 查询 default 表。自定义规则如果用 100 和 200，100 会先于 200；不要把“写在前面”当成真正的排序依据。

用同一组条件复现实际查询

只执行 ip route get 目标地址 容易漏掉源地址、入口网卡或 mark，结果可能走到 main 表而不是故障流量使用的路径。排障时应尽量补齐上下文：

# 用真实源地址和目标地址复现一次策略路由查询
ip route get 198.51.100.10 from 192.0.2.10

# 流量从指定网卡进入时，把入口条件也带上
ip route get 198.51.100.10 from 192.0.2.10 iif eth0

# 规则依赖防火墙标记时，使用同一个 mark 值复现
ip route get 198.51.100.10 from 192.0.2.10 mark 0x1

把输出中的设备、网关和表信息与规则逐项对照。若 iproute2 支持 fibmatch，可以在查询末尾追加它查看更完整的 FIB 匹配过程；不支持时以本机 ip route get help 的提示为准。

区分“规则命中”与“表里没有路由”

这是最容易误判的地方。假设 priority 100 的规则匹配 fwmark 0x1 并查询 table 100，但 table 100 没有覆盖目标地址的路由，查询可能继续到后面的 main 规则。此时“最后走了 main”不一定表示 100 规则没有匹配，而可能表示它匹配后没有产生成功的路由决定。

用唯一 priority 修正，并保留回滚动作

修规则前先保存当前状态。临时实验可以使用一段明确且未占用的 priority；生产变更则应由配置管理系统维护，避免手工命令与 NetworkManager、systemd-networkd 或其他网络管理器互相覆盖。

# 保存当前规则，便于变更前后对照
ip rule save > /tmp/ip-rule.before

# 示例：给来自指定源网段的流量分配明确且唯一的优先级
sudo ip rule add priority 100 from 192.0.2.0/24 table 100

# 用同样的查询条件确认修正后的设备和路由表
ip route get 198.51.100.10 from 192.0.2.10

# 实验结束后按完整 selector 删除，避免留下隐性规则
sudo ip rule del priority 100 from 192.0.2.0/24 table 100

不要用“再加一条更优规则”掩盖重复配置。记录 priority、selector、table、变更时间和验证命令；如果故障涉及 mark，还要记录 mark 是在哪里设置的。这样才能区分规则排序问题、标记丢失问题和路由表内容问题。

常见问题

priority 越大是不是越优先？

不是。数字越小越早处理，priority 100 会先于 200。建议给自定义规则显式指定唯一值。

为什么规则匹配了却最后显示 main 表？

可能是前面的规则动作没有找到成功路由，RPDB 继续检查后面的规则；也可能是你执行 route get 时遗漏了源地址、iif 或 mark。

只看 ip route show 能判断 ip rule 吗？

不能。它只能说明某张表里有什么路由，不能说明数据包是否会先进入这张表。需要先看 ip rule，再用对应条件执行 ip route get。