先聊一个我遇到过的真实翻车现场。某次给客户机房做网络改造服务器上插了两块网卡一块走办公网段一块走业务专线网段。装完系统配置好IP业务网卡明明也是通的可所有出网流量都跑了办公网卡业务系统访问时快时慢后来更是直接失联。排查到最后原因特别朴素默认路由被办公网卡抢走了而Linux判断“谁走默认路由”靠的正是metric也就是路由优先级。你查阅ubuntu网络配置也好折腾openeuler网络配置也好最终多半都会绕到metric这个参数上。metric不改变IP地址、不改变网关它只做一件事当系统里有两条甚至更多条路由都能到达目的地时告诉内核“先走谁、后走谁”。说白了它就是路由表里的“体重秤”谁数值小谁就优先被选中。这篇文章就把metric的底层逻辑、它在各类Linux发行版里的配置方法、以及双网卡环境下最容易踩的坑完完整整过一遍适合所有被多网卡、多线路、虚拟机多网卡问题困扰的人参考。1. 先搞清楚metric衡量的是什么路由优先级的本质逻辑1.1 一张路由表里的“体重秤”先看一个最普通的场景。服务器上有两张网卡eth0连接办公网网关是192.168.1.1eth1连接专线网关是10.0.0.1。系统配置完成后你执行ip route show大概率会看到类似这样的输出default via 192.168.1.1 dev eth0 metric 100 default via 10.0.0.1 dev eth1 metric 200 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100 metric 100 10.0.0.0/24 dev eth1 proto kernel scope link src 10.0.0.100 metric 200注意看这里出现了两条default路由也就是默认路由。在普通单网卡机器上默认路由只有一条一旦你加了第二块网卡、配置了第二个网关系统里就会出现多条默认路由。这时候问题来了内核要把一个目的地址不在任何已知网段里的数据包发出去到底走eth0还是走eth1metric就是裁决者。内核会逐条比较到达同一目的地的路由谁的metric值小谁就放进主路由表数值大的作为备用。所以上面这个例子里所有出网流量都会通过eth0的192.168.1.1走哪怕eth1的专线带宽更大、延迟更低也没用。这里有一个容易混淆的点很多新手会以为metric和网卡的物理顺序或者IP地址有关其实完全无关。它是路由项的一个独立属性你可以手动指定为一个任意数值。常见取值范围是0到4294967295但实际使用中没人会写那么极端通常就是0到1000之间的数字各家系统默认值也基本落在1到200这个区间内。1.2 为什么说metric数值越小越优先我说一个生活化的类比。你把metric想象成公司食堂的打饭排队号食堂窗口分发盒饭的时候不看谁先到只看号码牌。号码是1的先打号码是2的后打号码是100的等别人都打完再说。路由表选路就是这个逻辑default via 192.168.1.1 dev eth0 metric 100相当于拿了一张100号default via 10.0.0.1 dev eth1 metric 200相当于拿了一张200号那么所有出网流量必然先找192.168.1.1这个网关。理解了“数值越小越优先”之后你就掌握了整个网卡优先级配置的核心。无论你后续用ip命令临时调整、用nmcli做持久化配置、还是写netplan/ifcfg文件本质都是在改这一个数字。顺带提一个细节Linux系统里直连网段路由比如192.168.1.0/24 dev eth0这一类本身也有metric但它和默认路由的metric是两回事。你改默认路由的metric不会影响直连路由的优先级直连路由的metric更多影响的是当多个接口处于同一网段时ARP和本机回包走哪个接口。实际运维中除非你做的是非常复杂的策略路由否则直连路由的metric一般不用动重点盯住default路由的metric即可。还有一个概念需要区分metric和ip rule策略路由。metric解决的是“同一条路由表里多条路线的先后顺序”而ip rule解决的是“不同的数据包来源/目标使用不同路由表”。两者互补但在绝大多数“网卡优先级”场景里你只需要管metric就够了。只有当你想让某个特定网段的流量强制走某块网卡、而其他流量走默认网卡时才需要上策略路由。2. 手工调整网卡优先级用ip命令当场见效2.1 调整前的路由现状检查在改任何东西之前先确认当前的路由状态。我最常用的三个命令ip route show ip route show table all | grep default ip -6 route show | grep default第一个命令看IPv4主路由表第二个命令把系统里所有路由表包括local表、main表里的默认路由都翻出来第三个命令看IPv6的默认路由。为什么强调第三个因为很多人在双网卡环境里只调了IPv4结果IPv6的流量照样乱跑查半天才发现v6的metric根本没有动。拿到现状之后你还要确认每一块网卡对应的网关是哪个。用ip route show里的信息就够了一般来说default via 192.168.1.1 dev eth0 metric 100 default via 10.0.0.1 dev eth1 metric 200这是一个非常典型的状态。现在我想让eth1成为主出口也就是把eth1的metric改得比eth0小比如eth1改成50eth0改成100。2.2 改metric的标准操作与注意事项临时改起来很简单两条命令sudo ip route del default via 10.0.0.1 dev eth1 sudo ip route add default via 10.0.0.1 dev eth1 metric 50这里有一个很多人会踩的坑你直接执行ip route replace default via 10.0.0.1 dev eth1 metric 50是不会生效的。为什么因为replace操作要求匹配的旧路由存在而且replace只会替换匹配项的某些属性但在“默认路由”这个场景里sysctl的ip_forward、路由缓存以及fib表对default规则的匹配方式非常挑剔实战中最好的做法就是“先删后加”。两条命令分开执行顺序不能颠倒删掉旧路由之后紧接着加上新路由中间间隔越短越好避免出现窗口期断网。同样地把eth0从100改成50让两块网卡的优先级反过来也照葫芦画瓢sudo ip route del default via 192.168.1.1 dev eth0 sudo ip route add default via 192.168.1.1 dev eth0 metric 50此时再执行ip route show你会看到default via 192.168.1.1 dev eth0 metric 50 default via 10.0.0.1 dev eth1 metric 100出网流量会立刻切换走eth0。整个过程不用重启网卡不影响现有连接当然已经建立的TCP连接不会重新选路新连接才会走新路由非常适合临时切换线路的场景。补充一台机器上调整顺序时要注意的另一个点修改之后最好立刻ping一下外网比如ping -c 3 223.5.5.5同时用ip route get 223.5.5.5确认数据包确实从你期望的网卡出去。ip route get是我日常排查选路问题时最爱的命令它直接告诉你一个指定IP会走哪条路由、从哪个接口出、下一跳是谁一句顶十句。临时调整的缺点是重启网络服务、重启机器、或者重新DHCP获取地址之后配置会丢失一切回到原样。所以接下来重点说怎么把metric做成持久化配置。3. 让配置持久化不同系统各写各的配置3.1 NetworkManager一家亲nmcli写法目前主流的Ubuntu、OpenEuler、RHEL、CentOS系统很多都默认用NetworkManager管理网络。很多人对NetworkManager有误解觉得它就只会弹个图形界面其实它很好用尤其是nmcli命令一句话就能把metric写进配置。先看当前连接的名称nmcli connection show输出类似NAME UUID TYPE DEVICE Wired connection 1 8e6f8b6e-... ethernet eth0 eth1 f1a22c9d-... ethernet eth1注意连接名称不一定是网卡名称。这俩经常不一样尤其是桌面版Ubuntu连接名默认就是“Wired connection 1”。你要改的是连接名不是网卡名写错名字nmcli会直接报错。然后修改metricsudo nmcli connection modify eth1 ipv4.route-metric 50 sudo nmcli connection modify eth1 ipv6.route-metric 50再看ip route show如果没生效需要重新激活一下连接sudo nmcli connection up eth1nmcli connection modify的好处是把配置写进了NetworkManager的配置文件里重启之后依然生效。而且它对IPv4和IPv6分开管理你可以单独只调v4也可以一起调。我在OpenEuler和RHEL系列机器上基本都是这套写法兼容性很好。如果连接名是Wired connection 1这种带空格的注意引号不能丢sudo nmcli connection modify Wired connection 1 ipv4.route-metric 100不过有个细节要提醒ipv4.route-metric设置的是该连接所有路由的默认metric包括DHCP获取的默认路由。如果你希望同一条网卡上同时存在多条不同metric的路由比如加一条静态路由让某个网段走特殊网关就需要配合ipv4.routes参数指定metricsudo nmcli connection modify eth1 ipv4.routes 10.10.0.0/16 10.0.0.2 metric 80这里每个路由项后面都可以跟一个metric灵活度非常高。但说实话日常的“网卡优先级”需求用ipv4.route-metric就够了简单直观。3.2 Ubuntu 22.04的netplan怎么设置metricUbuntu的netplan是另一个常用方案。20.04之后gateway4这个写法已经标记为废弃新版本直接写routes列表。Ubuntu 22.04的网卡优先级配置最标准的格式是这样的network: version: 2 ethernets: eth0: dhcp4: true dhcp4-overrides: route-metric: 200 eth1: dhcp4: true dhcp4-overrides: route-metric: 50dhcp4-overrides里的route-metric是专门用来覆盖DHCP分配默认路由时的metric值。这个字段很多人不知道它比在routes里手动写default路由更优雅。因为如果用了静态IP你可以直接在routes里写network: version: 2 ethernets: eth0: addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 metric: 200 eth1: addresses: - 10.0.0.100/24 routes: - to: default via: 10.0.0.1 metric: 50这种写法一目了然eth1的默认路由metric是50eth0的默认路由metric是200流量优先走eth1。netplan写完之后一定要执行sudo netplan apply然后立刻检查ip route show。netplan的YAML格式非常敏感缩进错了一个字都会报错。我建议在改之前先cp一份备份改完之后用sudo netplan try而不是直接sudo netplan apply。netplan try会先试应用配置如果120秒内没有收到确认它会自动回滚到上一个可用配置这个机制能救命——尤其是你正在通过SSH远程操作服务器一旦改错网络配置导致连接断开有个自动回滚等于多了条命。3.3 OpenEuler/传统ifcfg文件的metric配置OpenEuler虽然默认也是NetworkManager但它的网络配置风格更贴近传统RHEL很多人习惯直接改/etc/sysconfig/network-scripts/ifcfg-ethX。如果系统里还保留着network-scripts或者你打算纯静态配置标准写法是在ifcfg文件里加一行METRIC50比如ifcfg-eth1DEVICEeth1 BOOTPROTOnone ONBOOTyes IPADDR10.0.0.100 NETMASK255.255.255.0 GATEWAY10.0.0.1 METRIC50ifcfg-eth0则写成DEVICEeth0 BOOTPROTOnone ONBOOTyes IPADDR192.168.1.100 NETMASK255.255.255.0 GATEWAY192.168.1.1 METRIC200然后重启网络sudo systemctl restart network这个方案在CentOS 7/Older以及OpenEuler上都很稳定。不过要注意的是如果系统同时启用了NetworkManager修改ifcfg文件之后最好用nmcli connection reload再nmcli connection up否则NetworkManager的缓存可能还是旧配置。另外传统ifcfg的METRIC只对由该配置文件生成的默认路由生效对DHCP获取的路由不一定管用。如果是DHCP模式你得在ifcfg里设置DHCP_METRIC50或者METRIC配合DHCP命令行参数使用不同版本的表现略有差异。说实话DHCP场景我更推荐统一用NetworkManager管理因为ipv4.route-metric对DHCP和静态IP一视同仁省去很多折腾。4. DHCP场景下metric为什么总“回到解放前”4.1 默认路由优先级是怎么被DHCP决定的为什么很多人配置好metric之后一重启网络就失效或者明明改了优先级但系统隔一段时间又自动恢复答案十有八九出在DHCP上。默认情况下Linux系统里DHCP获取到的网络配置系统会自动给默认路由分配一个metric值。这个值在不同发行版里不太一样常见的默认值有100、200、202等。问题是如果你在网卡配置文件里写了GATEWAY192.168.1.1同时又开着DHCP那么这两条默认路由会产生叠加或者静态优先级被DHCP的默认值覆盖掉导致配置看起来“变了”。更隐蔽的情况是机器上有两块网卡都开启了DHCP系统为两块网卡自动生成的默认路由metric分别可能是100和200。你手改其中一块成50看起来生效了但DHCP租约一旦续约或者网络服务重载DHCP客户端会重新下发路由把metric重置回默认值。这也是我反复强调“用NetworkManager统一管理、使用ipv4.route-metric”的原因。它能把DHCP获取到的默认路由的metric强制指定为你想要的值DHCP租约刷新时也不会丢失。4.2 nmcli和systemd-networkd下的DHCP metric设定nmcli的写法刚才已经提到了sudo nmcli connection modify eth1 ipv4.route-metric 50这个配置不只是给静态路由用的它对DHCP自动获取的default路由同样生效。所以双网卡DHCP环境下你分别给eth0和eth1设置不同的route-metric然后重新激活连接一切都会按你指定的优先级走。如果你的系统用的是systemd-networkd比如某些精简版Linux或者容器宿主节点配置方式是在.network文件里加[Match] Nameeth1 [Network] DHCPyes [DHCP] RouteMetric50注意RouteMetric是写在[DHCP]段下面的不是[Network]段。这个参数专门控制DHCP获取路由的metric。如果是静态IP则写在[Route]段[Match] Nameeth1 [Network] Address10.0.0.100/24 Gateway10.0.0.1 [Route] Gateway10.0.0.1 Metric50systemd-networkd的配置生效需要重启服务sudo systemctl restart systemd-networkd这里有一个非常容易踩的坑[Match]段的Name严格匹配接口名。如果你用了可预测网络命名规则网卡名可能是enp1s0、ens33这种配置里的名字跟实际对不上整个配置文件会被静默忽略。排查systemd-networkd问题时第一件事就是networkctl status看看接口状态再确认[Match]匹配是否命中。另外systemd-networkd的RouteMetric字段在较新版本里还支持IPv6格式为RouteMetric50它同时作用于v4和v6路由。如果只想影响其中一种用IPv4RouteMetric或IPv6RouteMetric是更精确的写法具体字段名取决于systemd版本老版本不支持区分就直接用RouteMetric。5. 多网卡主备与分流场景metric只是第一步5.1 主备切换必须配套网关健康检查聊到metric很多人的下一个问题是我设置了metric之后是不是就实现了网卡故障自动切换答案可能让你失望不一定。还是回到路由选路逻辑。内核选择默认路由只看metric大小它不关心这条链路的对端网关是不是真的活着。假设eth0的metric为100eth1的metric为200eth0的网关突然断电内核会怎么办它依然会把数据包从eth0扔出去然后等待超时、重传、再超时整个过程持续几十秒甚至更久而eth1全程在旁边“看戏”。这就是很多人配置了双网卡主备之后依然出现间歇性断网的深层原因——metric只解决“优先级”不解决“故障检测”。生产环境里要真正实现主备自动切换至少需要两件事配套一是网关健康检查二是路由动态调整。健康检查可以自己写脚本定时ping网关ping不通就把这条默认路由删掉让备用线路接管。比如#!/bin/bash #/usr/local/bin/check_gw.sh GW192.168.1.1 IFACEeth0 if ! ping -c 3 -W 1 -I $IFACE $GW /dev/null 21; then ip route del default via $GW dev $IFACE logger -t check_gw gateway $GW unreachable, remove default route fi再加个cron每分钟执行一次就能实现半自动切换。更成熟的做法是用keepalived或者双机热备软件配合BFD协议做链路检测但那是另一个话题了。对于中小企业场景脚本判断网关连通性已经足够实用。这里要特别强调做健康检查时ping必须指定-I $IFACE也就是用特定网卡去ping否则Linux会按照路由表选路如果默认路由恰好走了eth1那ping的结果根本不能反映eth0的健康状况。这个问题我见过好几个人踩过写出的脚本跟没写一样就是因为忘了-I参数。5.2 虚拟机环境与多网卡策略的注意事项再补充一个和虚拟机强相关的场景。很多人在VMware Workstation里给虚拟机配两张网卡一张NAT模式、一张桥接模式然后想在虚拟机内部设置metric实现“优先走桥接”之类的需求。方法本身和物理机一模一样但有几个虚拟机特有的坑。第一VMware虚拟网卡的命名通常不是eth0/eth1而是ens33、ens160这种并且两块网卡的命名顺序和你在VMware虚拟机设置里的添加顺序不一定一致。配置metric之前先用ip link show看清楚每块网卡对应的是哪个MAC地址再通过MAC地址在配置文件里做好绑定避免网卡名漂移导致配置张冠李戴。第二NAT模式下的VMnet8默认网关通常是192.168.x.2桥接模式的网关则是你物理路由器。两边的网段、网关都不同配置metric时尤其要确认每个网关真的可达。如果NAT那个网关本来就通桥接那个网关的物理链路不通你就算把桥接网卡的metric设成1数据包照样出不去。第三虚拟机的网卡热插拔场景。VMware允许在虚拟机运行状态下动态添加或移除网卡这会导致NetworkManager或systemd-networkd重新生成连接配置你之前手工设置的metric可能被新的默认连接覆盖。虚拟机环境里的网卡优先级配置最好也统一写进连接配置而不是临时用ip route改。顺带说一句如果你面对的是一台200人规模企业的服务器网卡优先级的问题往往会升级成更复杂的出口规划办公网段、业务网段、管理网段、备份网段要互相隔离外网出口可能还有多条线路。这个时候不能光靠metric单点配置还要整体设计VLAN、路由表、防火墙策略。但无论架构多复杂落地到每一台机器上的时候metric依然是决定“这块网卡上的流量走不走、何时走”的基础齿轮。把metric玩明白了后面做策略路由、策略分流才会顺手。6. 常见问题速查与避坑记录6.1 我踩过的高频坑整理了这些年运维中反复出现的几类问题按命中率从高到低排现象根本原因解决办法修改metric后重启失效DHCP续约或网络服务重载覆盖了手工配置用nmcli的ipv4.route-metric或netplan的dhcp4-overrides持久化配置metric改了但流量还是走老网卡修改的是连接名不是网卡名或改完没有重新激活连接nmcli要upshell连接netplan要apply确认修改对象是连接配置双网卡都配了默认路由但只有一块通另一块网卡的网关不可达或链路不通metric再小也没用先逐块网卡ping网关确认链路健康再谈优先级systemd-networkd配置了Metric但不生效[Match]匹配失败或者字段写错位置用networkctl status查看接口状态确认配置段名称和字段拼写IPv4流量正常IPv6乱跑只调了IPv4 metricIPv6默认路由没动同时设置ipv6.route-metric或补配IPv6的RouteMetric服务器重启后路由表出现多条default优先级错乱多块网卡都配置了Gateway系统为每个网关生成一条default路由统一规划网关配置只保留一个主网关其余通过metric控制优先级vmware虚拟机里网卡名漂移配置对不上可预测命名规则下添加/删除网卡会导致名称变化用MAC地址绑定连接配置或者用udev规则固定网卡名第一类问题出现的频率最高。说白了很多人以为把metric写进ifcfg或者netplan就万事大吉但DHCP一下就把你的“默认值”顶掉了。所以我在前文反复强调在进行网卡优先级配置时请优先选择NetworkManager的ipv4.route-metric或netplan的dhcp4-overrides这两种方式对DHCP场景有效不会被租约刷新覆盖。第二类问题也很典型。nmcli报错提示“unknown connection”或者改了之后路由没变化八成是连接名和网卡名搞混了。记住nmcli connection show列出来的“NAME”才是你要修改的对象不是ip link里看到的设备名。第三类问题是逻辑层面的——metric再小链路不通都白搭。判断链路健康最直接的办法是ping -c 3 -I eth0 192.168.1.1 ping -c 3 -I eth1 10.0.0.1注意-I参数不用它的话你ping的其实是“系统默认出口”而不是指定网卡结果没有参考意义。6.2 快速诊断命令清单最后整理一套我平时排查网卡优先级问题的命令序列按顺序执行基本都能定位问题# 1. 查看当前IPv4路由表 ip route show # 2. 查看IPv6默认路由 ip -6 route show default # 3. 查看某个IP实际会走哪个网卡出去 ip route get 223.5.5.5 # 4. 查看网卡名称和MAC对应关系 ip link show # 5. 查看NetworkManager连接及状态 nmcli connection show nmcli device status # 6. 查看systemd-networkd接口状态 networkctl status # 7. 检查是否有多条default路由注意metric值 ip route show table main | grep default如果查出来是多条default路由直接对照metric数值大小即可判断优先级。如果只有一条default路由但你期望是双线那问题出在没给另一块网卡配Gateway或者DHCP没有正确下发。总之ip route show的输出是一切判断的基础。最后分享一个实在的经验给网卡设置metric的数值尽量不要用1和100这种极端组合拉开梯度即可比如50和200。极端值在后续做策略路由、防火墙mark的时候容易引起不必要的麻烦而且一看到metric1的路由你根本分辨不出是手工配的还是系统自动生成的。留出余量比什么都强。在实际操作中我的体会是metric配置从来不是一次性的活它要和DHCP、NetworkManager、系统重启三个“对手”长期斗争。但只要理解了它就是个排队号、理解了DHCP会抢号、理解了不同系统有不同的持久化写法你就能在任何一台Linux机器上快速搞定网卡优先级。这套方法我已经在Ubuntu 22.04、OpenEuler、CentOS、VMware虚拟机上反复验证过照着做基本不会翻车。