上个月周六晚上我被一个电话从沙发上拽起来。同事说办公室的内网突然访问不了文件服务器其他业务倒是正常。我ssh上去看了半天CPU、内存、磁盘都没问题习惯性敲了ip route show和traceroute问题一下暴露了发往内网文件服务器的流量没走内网网关而是绕到备用出口那条链路上去了。一查变更记录前几天测试高可用方案时有人用一条临时命令把系统默认路由改过测试结束忘了恢复。就这么一个小动作让整个办公室的内网访问慢了两个数量级。这类问题的根子基本都出在路由的排序和替换上。路由表一乱网络就乱排序规则搞不清排查时你永远会往错误的方向想替换方式用错服务器一重启问题又原样回来了。这篇文章就把我在服务器上处理路由排序、替换的经验一次讲清楚覆盖临时改道、永久生效、多网卡优先级、策略路由以及开发侧那些同样叫“路由”“排序”“替换”的场景。1. 一条路由的“插队规则”路由选路顺序里最关键的三层判断很多人一遇到网络问题就traceroute但traceroute只能看到结果看不到“为什么是这条路”。路由表里明明躺着好几条路由系统到底按什么顺序选这个机制搞不懂后面的所有“排序替换”都是盲操作。Linux内核选路时会依次做三层判断最长前缀匹配、路由优先级、metric数值。这三层不是并列关系而是层层过滤。第一层没比出结果的才轮到第二层第二层还分不出高下的才轮到第三层。1.1 最长前缀匹配规则优先于数值大小最容易误解的就是这一点。很多人以为路由表里metric小的就一定优先但实际上只要匹配目的地址的前缀长度更长哪怕它的metric是100也会无条件赢过一条metric为1但前缀更短的路由。换句话说路由“排序”不是简单按数值从小到大排列而是先分层、再谈大小。我经常用一个内网场景说明服务器上有10.10.10.0/24 via 192.168.1.1 dev eth0这条明细路由同时还有一条default via 192.168.2.1 dev eth1的默认路由。访问10.10.10.50时永远走192.168.1.1这个内网网关默认路由的metric再小也没用因为/24比/0具体得多。这个规则不搞明白排查时就容易出现“我明明改了默认路由为什么流量不走新网关”的困惑。1.2 metric和优先级数值越小越靠前当前缀长度完全相同时才轮到metric出场。最常见的场景就是两条默认路由并存一条走主出口一条走备用出口谁的metric小谁就是当前生效的主出口。这个“排序”直接决定了业务流量去往哪个方向。查看和设置metric的命令很直观# 添加一条默认路由指定metric为100 ip route add default via 192.168.1.1 dev eth0 metric 100 # 再添加一条备用默认路由指定metric为200 ip route add default via 192.168.2.1 dev eth1 metric 200 # 查看当前默认路由的排序情况 ip route show执行后能看到两条default并存但系统只会选择metric小的那条作为主用。很多老教程还在用route命令我建议尽早切到ip route系列命令route对metric的显示不全操作逻辑也不如ip命令清晰排查问题时容易漏信息。1.3 用命令查看路由的“真实排序”ip route show看到的是默认路由表main表的排序结果。如果配置了策略路由还要看对应的自定义路由表而ip route get可以告诉你某个目的IP到底会被哪条路由命中这是排查排序问题最快、最直接的方式。# 查看某个目的地址实际走哪条路由 ip route get 10.10.10.50 # 查看自定义路由表100里的排序情况 ip route show table 100我个人经验无论配置什么路由先ip route get确认“落点”再确认业务访问路径能少踩一半的坑。很多线上故障查到最后就是“路由确实加上了但没走它”。2. 路由替换的完整链路从临时命令到持久化配置每个环节的坑都不同路由替换这个操作听起来很简单——把旧路由删掉加一条新的。但实际执行时坑一个接一个ip route add遇到前缀已存在时会直接报RTNETLINK answers: File exists手动del add中间窗口期又可能把网络弄断。替换不是“加了就行”而是要分清临时生效和永久生效两条链路。2.1 临时替换为什么ip route replace比del add稳妥ip route replace会在内部做一次检查如果路由表中存在相同前缀和相同metric的路由就替换为新的下一跳如果不存在就等价于一次普通的add。省去了先del后add的两步操作也就避开了两个风险一是删除时误删了别的路由二是删除后添加失败导致断网。我在生产服务器上做临时改道时用的命令是这样的# 将默认路由替换为新的网关和出口网卡 ip route replace default via 192.168.2.1 dev eth1 metric 100 # 验证替换结果 ip route show ping -c 4 8.8.8.8替换后立刻看路由表和连通性。这里有个小细节如果只想替换上一跳不想动metric命令里就别写metric写了就相当于连metric一起改。很多同事在这个环节踩过坑替换完路由变了metric也变了备用路由的优先级跟着乱掉。2.2 持久化替换网卡配置文件与NetworkManager的博弈临时命令的代价很明显只要重启网络服务或重启服务器所有临时改动全部丢失。要做永久替换必须落到配置文件里。但这里有一个非常大的坑——现代Linux发行版里NetworkManager、systemd-networkd、network-scripts这套老组件经常并存有时候两个服务各管一块配置文件相互冲突时行为完全不可预期。我处理这类问题有一个固定顺序先确认当前网络由哪个组件接管再只在对应的配置体系里改动。# 查看NetworkManager是否在运行 systemctl status NetworkManager # 查看systemd-networkd是否在运行 systemctl status systemd-networkd # 查看netplan是否存在Ubuntu 18.04 ls /etc/netplan/确认清楚之后再去改对应的配置文件。最忌讳的就是明明系统走的是NetworkManager你手动改了/etc/sysconfig/network-scripts/route-eth0重启后配置没生效还以为是文件格式写错了实际上是NetworkManager根本没读这个文件。2.3 替换后的验证与回滚我通常这样做远程操作服务器的路由最怕的就是把自己锁在外面。我处理这类变更时从不直接执行完就走而是写一个带自动回滚的脚本#!/bin/bash # 保存当前默认路由作为回滚依据 ip route show default /tmp/route_backup.txt # 执行替换 ip route replace default via 192.168.2.1 dev eth1 metric 100 # 等待30秒等待人工确认如果ssh断开脚本会自动恢复旧路由 sleep 30 ip route replace default via $(awk {print $3} /tmp/route_backup.txt) dev $(awk {print $5} /tmp/route_backup.txt) metric $(awk {print $9} /tmp/route_backup.txt)这个习惯是从一次远程服务器变更中总结出来的。那次我人在外地改完路由后ssh直接断掉卡了十几分钟才通过带外管理口恢复。从那以后凡是涉及默认路由、网关这类“一改就断连”的变更我必定脚本化操作给自己留一个自动回退的保险丝。3. 麒麟V10永久默认路由实测与CentOS/Ubuntu配置的差异对照热搜里“麒麟v10添加永久默认路由”被问得很多。麒麟V10服务器版基于RHEL/CentOS生态和Ubuntu体系的配置思路完全不同网上不少教程混着写很容易把人带偏。我实际在麒麟V10上配过几次把差异和坑集中说清楚。3.1 麒麟V10的route-ethX文件写法麒麟V10如果使用network-scripts这套老体系明细路由写在/etc/sysconfig/network-scripts/route-eth0文件里。文件内容格式如下# 目标网段 via 下一跳 dev 网卡名 10.10.10.0/24 via 192.168.1.1 dev eth0 # 也可指定metric语法是后面的数字 10.20.0.0/16 via 192.168.2.1 dev eth1 metric 50默认路由则写在网卡配置文件/etc/sysconfig/network-scripts/ifcfg-eth0里加上一行GATEWAY192.168.1.1。修改后重启网络服务生效systemctl restart network有一个容易被忽略的点route-eth0这个文件只有在对应的ifcfg-eth0存在且DEVICEeth0、BOOTPROTO配置合理时才会被读取。如果你网卡实际叫ens33文件名却写成route-eth0配置永远不会生效。改之前一定要用ip link show确认网卡名。3.2 nmcli方式与纯文件方式的取舍麒麟V10的桌面版默认由NetworkManager接管网络纯手改route-ethX文件经常不生效或者重启后又被NetworkManager覆盖。这种情况下我推荐用nmcli来做永久配置命令示例# 给eth0添加一条永久明细路由 nmcli con mod eth0 ipv4.routes 10.10.10.0/24 192.168.1.1 # 设置永久默认路由并指定metric nmcli con mod eth0 ipv4.gateway 192.168.1.1 ipv4.route-metric 100 # 重新激活连接生效 nmcli con up eth0nmcli con mod写入的是NetworkManager的配置库重启后依然保留。如果环境是“无桌面最小化安装”的服务器并且坚持使用传统network服务再考虑route-ethX文件方式。两种方式不要混用否则会出现“配置都在但到底谁生效”的混乱局面。3.3 几个主流发行版的默认路由配置对照我整理了一张对照表方便在不同系统间切换时快速定位发行版持久化默认路由配置方式常用命令麒麟V10 / CentOS 7ifcfg-eth0里写GATEWAY明细路由写route-eth0systemctl restart networkCentOS 8 / RHEL 8NetworkManager集中管理nmcli con mod eth0 ipv4.gateway ...Ubuntu 18.04/etc/netplan/*.yaml的routes段netplan applyDebian 10/etc/network/interfaces或/etc/network/interfaces.d/*systemctl restart networking这个表不一定覆盖所有小版本但大方向是对的。跨发行版操作时先确认网络管理栈再决定改哪个文件是省时间的关键。4. 多网卡场景下的路由优先级metric、策略路由与业务救急多网卡服务器是路由混乱的重灾区。最常见的故障就是服务器加了一块网卡配置完IP和网关后原有的业务访问变慢或者干脆不通。原因不是网卡坏了而是新网卡的默认路由“插队”到了旧路由前面流量方向被带偏了。4.1 典型故障一加网卡业务全乱服务器原本只有一块网卡enp3s0网关是192.168.1.1跑得好好的。后来加了块网卡enp4s0接另一条链路网关192.168.2.1。配置完成后系统里出现了两条默认路由。内核只看metric哪条小就走哪条。如果新网卡自动获取到的metric比旧网卡小所有出网流量就一股脑涌向新链路老链路反而闲置了。此时用ip route show查看会看到两条default并列但实际只有一条生效。很多人到这里会选择删掉其中一条但这样做的隐患是万一生效的那条链路断了没有备用的兜底路由。4.2 用metric调整“排序”而不是靠删路由多网卡场景下更稳妥的做法是保留两条默认路由但通过metric明确主次关系。主用路由metric小备用路由metric大正常情况下流量走主用主用故障时内核会自动切换到备用。# 主出口 ip route replace default via 192.168.1.1 dev enp3s0 metric 100 # 备用出口 ip route replace default via 192.168.2.1 dev enp4s0 metric 200 # 验证主备切换 ip link set enp3s0 down ip route show ping -c 4 8.8.8.8 ip link set enp3s0 up实测时down掉主网卡后流量会在几秒内切到备用链路业务不中断。这种“排序”思路比删路由优雅得多也是生产环境双出口的标准做法。4.3ip rule策略路由与自定义路由表实战metric只能解决“同前缀路由谁优先”的问题解决不了“不同源地址走不同出口”的需求。比如业务场景要求来源为10.0.0.0/8的流量走内网专线其他流量走公网出口。这时就要上策略路由pbr。策略路由的配置分两步先定义规则再往自定义路由表里填路由。# 1. 添加一条策略规则来自10.0.0.0/8的流量查table 100 ip rule add from 10.0.0.0/8 lookup 100 prio 1000 # 2. 在table 100里添加路由 ip route add 10.0.0.0/8 via 192.168.10.1 table 100 ip route add default via 192.168.1.1 table 100 # 3. 刷新路由缓存使策略生效 ip route flush cache # 4. 验证 ip rule show ip route show table 100 ip route get 10.10.10.50 from 10.0.0.2关键点是ip rule里的prio数值越小优先级越高规则从上往下逐条匹配lookup 100指的是查自定义路由表100不是查主表。如果你把ip rule和ip route add table 100的命令顺序写反策略会处于“有规则没路由”的状态流量照样走默认路径。4.4 业务救急时的临时方案与收敛方案遇到线上业务因为路由问题中断我的处理原则是先临时改道恢复业务再补持久化配置绝不在高峰期直接改配置文件重启网络。比如流媒体推流服务器或录播服务器突然推流卡顿先快速看一下ip route get确认是不是走了错误的出口如果确认立刻用ip route replace把默认路由临时纠正回来业务一般马上恢复。等业务低峰期再把临时改动落成持久化配置同时保留回滚脚本。这个过程说起来简单但很多人一着急就跳过“临时改道”直接改配置重启网络结果断连时间更长反而把故障扩大了。5. 从服务器路由到业务路由排序与替换思维在其他技术栈的迁移处理过服务器路由的问题后我越来越觉得“路由”“排序”“替换”这三个词不只是网络运维的事。前端框架的内部路由、后端的数据排序、文本处理里的字符串替换底层都是同一套逻辑先明确规则再安排顺序最后确认覆盖。很多“诡异Bug”本质上是这三步里某一步出了问题。5.1 前端路由vue路由和react路由背后的排序逻辑vue-router和react-router都叫“路由”但内部对路由顺序的处理不同。vue-router的addRoute支持按name和path注册匹配时也有优先级概念react-router v6则引入了自动打分排序机制匹配顺序由参数权重自动计算不用手动排。实际开发中经常遇到“明明配了/user/:id但访问/user/profile却匹配到别的页面”。这类问题的本质和服务器路由选路一模一样具体路由和动态路由谁优先。理解“越具体越优先”这条规则前端路由和服务器路由都能少踩坑。5.2 数据排序mysql order by、hashmap和list排序的共性数据侧的“排序”也同样涉及“顺序由什么决定”的问题。MySQL的ORDER BY走索引时是索引排序走不上索引就变成filesort临时文件排序性能差异巨大Java的HashMap本身无序扩容后元素顺序还会变需要稳定顺序时就得换LinkedHashMap或TreeMap。// Java中对List按某个字段排序 list.sort(Comparator.comparing(User::getAge).reversed()); // 保持插入顺序的Map MapString, String map new LinkedHashMap();这些操作和服务器路由改metric有异曲同工之处你得先想清楚要按什么规则排再去选对应的工具否则排出来的结果永远不是你想要的。5.3 文本替换命令行到IDE的替换陷阱字符串替换这块最容易出问题的是换行符。在Linux下写的脚本拿到Windows上跑经常因为\r\n和\n不一致而报错。我处理跨平台文本时习惯先用file命令确认文件格式再决定怎么替换。# 查看文件格式 file script.sh # 用sed替换文本 sed -i s/old_text/new_text/g file.txt # 跨行替换需要perl perl -0pe s/old\n text/new/g file.txtIDE里做全局替换时也要注意勾选“正则表达式”还是“普通文本”这两个选项的匹配范围完全不同。替换前先确认匹配范围替换后立刻grep验证结果是防止“替换炸了”的最基本手段。5.4 技术迁移中的“替换”思维从doris替换es看架构决策热搜词里有“doris 替换 es”这个场景表面上是中间件选型替换实际上就是一个大型“替换”工程。从Elasticsearch迁移到Doris要处理查询语法差异、聚合逻辑差异、数据同步链路、历史数据回放等一堆问题。这和给服务器替换默认路由很像顺序安排不对跑了半天业务还是卡住的回滚方案不准备出了问题就进退两难。我每次做这类技术迁移都会先列三件事当前系统的ip route show也就是现状拓扑目标配置长什么样如果失败怎么回滚。三件事都想清楚再动手成功率会高很多。最后说点个人体会。做了这些年服务器和业务开发我最大的感受是很多问题不是不会改而是不知道“改完之后影响谁”。路由的替换、排序的调整、组件的迁移都是同一套思维。多问自己一句选路规则是什么覆盖范围是什么回滚方案是什么大部分线上事故都能提前拦住。 
长河君 · 2026/9/9 16:09:05 · 阅读 1.2k 服务器路由排序与替换实战：从ip route到策略路由
上个月周六晚上我被一个电话从沙发上拽起来。同事说办公室的内网突然访问不了文件服务器其他业务倒是正常。我ssh上去看了半天CPU、内存、磁盘都没问题习惯性敲了ip route show和traceroute问题一下暴露了发往内网文件服务器的流量没走内网网关而是绕到备用出口那条链路上去了。一查变更记录前几天测试高可用方案时有人用一条临时命令把系统默认路由改过测试结束忘了恢复。就这么一个小动作让整个办公室的内网访问慢了两个数量级。这类问题的根子基本都出在路由的排序和替换上。路由表一乱网络就乱排序规则搞不清排查时你永远会往错误的方向想替换方式用错服务器一重启问题又原样回来了。这篇文章就把我在服务器上处理路由排序、替换的经验一次讲清楚覆盖临时改道、永久生效、多网卡优先级、策略路由以及开发侧那些同样叫“路由”“排序”“替换”的场景。1. 一条路由的“插队规则”路由选路顺序里最关键的三层判断很多人一遇到网络问题就traceroute但traceroute只能看到结果看不到“为什么是这条路”。路由表里明明躺着好几条路由系统到底按什么顺序选这个机制搞不懂后面的所有“排序替换”都是盲操作。Linux内核选路时会依次做三层判断最长前缀匹配、路由优先级、metric数值。这三层不是并列关系而是层层过滤。第一层没比出结果的才轮到第二层第二层还分不出高下的才轮到第三层。1.1 最长前缀匹配规则优先于数值大小最容易误解的就是这一点。很多人以为路由表里metric小的就一定优先但实际上只要匹配目的地址的前缀长度更长哪怕它的metric是100也会无条件赢过一条metric为1但前缀更短的路由。换句话说路由“排序”不是简单按数值从小到大排列而是先分层、再谈大小。我经常用一个内网场景说明服务器上有10.10.10.0/24 via 192.168.1.1 dev eth0这条明细路由同时还有一条default via 192.168.2.1 dev eth1的默认路由。访问10.10.10.50时永远走192.168.1.1这个内网网关默认路由的metric再小也没用因为/24比/0具体得多。这个规则不搞明白排查时就容易出现“我明明改了默认路由为什么流量不走新网关”的困惑。1.2 metric和优先级数值越小越靠前当前缀长度完全相同时才轮到metric出场。最常见的场景就是两条默认路由并存一条走主出口一条走备用出口谁的metric小谁就是当前生效的主出口。这个“排序”直接决定了业务流量去往哪个方向。查看和设置metric的命令很直观# 添加一条默认路由指定metric为100 ip route add default via 192.168.1.1 dev eth0 metric 100 # 再添加一条备用默认路由指定metric为200 ip route add default via 192.168.2.1 dev eth1 metric 200 # 查看当前默认路由的排序情况 ip route show执行后能看到两条default并存但系统只会选择metric小的那条作为主用。很多老教程还在用route命令我建议尽早切到ip route系列命令route对metric的显示不全操作逻辑也不如ip命令清晰排查问题时容易漏信息。1.3 用命令查看路由的“真实排序”ip route show看到的是默认路由表main表的排序结果。如果配置了策略路由还要看对应的自定义路由表而ip route get可以告诉你某个目的IP到底会被哪条路由命中这是排查排序问题最快、最直接的方式。# 查看某个目的地址实际走哪条路由 ip route get 10.10.10.50 # 查看自定义路由表100里的排序情况 ip route show table 100我个人经验无论配置什么路由先ip route get确认“落点”再确认业务访问路径能少踩一半的坑。很多线上故障查到最后就是“路由确实加上了但没走它”。2. 路由替换的完整链路从临时命令到持久化配置每个环节的坑都不同路由替换这个操作听起来很简单——把旧路由删掉加一条新的。但实际执行时坑一个接一个ip route add遇到前缀已存在时会直接报RTNETLINK answers: File exists手动del add中间窗口期又可能把网络弄断。替换不是“加了就行”而是要分清临时生效和永久生效两条链路。2.1 临时替换为什么ip route replace比del add稳妥ip route replace会在内部做一次检查如果路由表中存在相同前缀和相同metric的路由就替换为新的下一跳如果不存在就等价于一次普通的add。省去了先del后add的两步操作也就避开了两个风险一是删除时误删了别的路由二是删除后添加失败导致断网。我在生产服务器上做临时改道时用的命令是这样的# 将默认路由替换为新的网关和出口网卡 ip route replace default via 192.168.2.1 dev eth1 metric 100 # 验证替换结果 ip route show ping -c 4 8.8.8.8替换后立刻看路由表和连通性。这里有个小细节如果只想替换上一跳不想动metric命令里就别写metric写了就相当于连metric一起改。很多同事在这个环节踩过坑替换完路由变了metric也变了备用路由的优先级跟着乱掉。2.2 持久化替换网卡配置文件与NetworkManager的博弈临时命令的代价很明显只要重启网络服务或重启服务器所有临时改动全部丢失。要做永久替换必须落到配置文件里。但这里有一个非常大的坑——现代Linux发行版里NetworkManager、systemd-networkd、network-scripts这套老组件经常并存有时候两个服务各管一块配置文件相互冲突时行为完全不可预期。我处理这类问题有一个固定顺序先确认当前网络由哪个组件接管再只在对应的配置体系里改动。# 查看NetworkManager是否在运行 systemctl status NetworkManager # 查看systemd-networkd是否在运行 systemctl status systemd-networkd # 查看netplan是否存在Ubuntu 18.04 ls /etc/netplan/确认清楚之后再去改对应的配置文件。最忌讳的就是明明系统走的是NetworkManager你手动改了/etc/sysconfig/network-scripts/route-eth0重启后配置没生效还以为是文件格式写错了实际上是NetworkManager根本没读这个文件。2.3 替换后的验证与回滚我通常这样做远程操作服务器的路由最怕的就是把自己锁在外面。我处理这类变更时从不直接执行完就走而是写一个带自动回滚的脚本#!/bin/bash # 保存当前默认路由作为回滚依据 ip route show default /tmp/route_backup.txt # 执行替换 ip route replace default via 192.168.2.1 dev eth1 metric 100 # 等待30秒等待人工确认如果ssh断开脚本会自动恢复旧路由 sleep 30 ip route replace default via $(awk {print $3} /tmp/route_backup.txt) dev $(awk {print $5} /tmp/route_backup.txt) metric $(awk {print $9} /tmp/route_backup.txt)这个习惯是从一次远程服务器变更中总结出来的。那次我人在外地改完路由后ssh直接断掉卡了十几分钟才通过带外管理口恢复。从那以后凡是涉及默认路由、网关这类“一改就断连”的变更我必定脚本化操作给自己留一个自动回退的保险丝。3. 麒麟V10永久默认路由实测与CentOS/Ubuntu配置的差异对照热搜里“麒麟v10添加永久默认路由”被问得很多。麒麟V10服务器版基于RHEL/CentOS生态和Ubuntu体系的配置思路完全不同网上不少教程混着写很容易把人带偏。我实际在麒麟V10上配过几次把差异和坑集中说清楚。3.1 麒麟V10的route-ethX文件写法麒麟V10如果使用network-scripts这套老体系明细路由写在/etc/sysconfig/network-scripts/route-eth0文件里。文件内容格式如下# 目标网段 via 下一跳 dev 网卡名 10.10.10.0/24 via 192.168.1.1 dev eth0 # 也可指定metric语法是后面的数字 10.20.0.0/16 via 192.168.2.1 dev eth1 metric 50默认路由则写在网卡配置文件/etc/sysconfig/network-scripts/ifcfg-eth0里加上一行GATEWAY192.168.1.1。修改后重启网络服务生效systemctl restart network有一个容易被忽略的点route-eth0这个文件只有在对应的ifcfg-eth0存在且DEVICEeth0、BOOTPROTO配置合理时才会被读取。如果你网卡实际叫ens33文件名却写成route-eth0配置永远不会生效。改之前一定要用ip link show确认网卡名。3.2 nmcli方式与纯文件方式的取舍麒麟V10的桌面版默认由NetworkManager接管网络纯手改route-ethX文件经常不生效或者重启后又被NetworkManager覆盖。这种情况下我推荐用nmcli来做永久配置命令示例# 给eth0添加一条永久明细路由 nmcli con mod eth0 ipv4.routes 10.10.10.0/24 192.168.1.1 # 设置永久默认路由并指定metric nmcli con mod eth0 ipv4.gateway 192.168.1.1 ipv4.route-metric 100 # 重新激活连接生效 nmcli con up eth0nmcli con mod写入的是NetworkManager的配置库重启后依然保留。如果环境是“无桌面最小化安装”的服务器并且坚持使用传统network服务再考虑route-ethX文件方式。两种方式不要混用否则会出现“配置都在但到底谁生效”的混乱局面。3.3 几个主流发行版的默认路由配置对照我整理了一张对照表方便在不同系统间切换时快速定位发行版持久化默认路由配置方式常用命令麒麟V10 / CentOS 7ifcfg-eth0里写GATEWAY明细路由写route-eth0systemctl restart networkCentOS 8 / RHEL 8NetworkManager集中管理nmcli con mod eth0 ipv4.gateway ...Ubuntu 18.04/etc/netplan/*.yaml的routes段netplan applyDebian 10/etc/network/interfaces或/etc/network/interfaces.d/*systemctl restart networking这个表不一定覆盖所有小版本但大方向是对的。跨发行版操作时先确认网络管理栈再决定改哪个文件是省时间的关键。4. 多网卡场景下的路由优先级metric、策略路由与业务救急多网卡服务器是路由混乱的重灾区。最常见的故障就是服务器加了一块网卡配置完IP和网关后原有的业务访问变慢或者干脆不通。原因不是网卡坏了而是新网卡的默认路由“插队”到了旧路由前面流量方向被带偏了。4.1 典型故障一加网卡业务全乱服务器原本只有一块网卡enp3s0网关是192.168.1.1跑得好好的。后来加了块网卡enp4s0接另一条链路网关192.168.2.1。配置完成后系统里出现了两条默认路由。内核只看metric哪条小就走哪条。如果新网卡自动获取到的metric比旧网卡小所有出网流量就一股脑涌向新链路老链路反而闲置了。此时用ip route show查看会看到两条default并列但实际只有一条生效。很多人到这里会选择删掉其中一条但这样做的隐患是万一生效的那条链路断了没有备用的兜底路由。4.2 用metric调整“排序”而不是靠删路由多网卡场景下更稳妥的做法是保留两条默认路由但通过metric明确主次关系。主用路由metric小备用路由metric大正常情况下流量走主用主用故障时内核会自动切换到备用。# 主出口 ip route replace default via 192.168.1.1 dev enp3s0 metric 100 # 备用出口 ip route replace default via 192.168.2.1 dev enp4s0 metric 200 # 验证主备切换 ip link set enp3s0 down ip route show ping -c 4 8.8.8.8 ip link set enp3s0 up实测时down掉主网卡后流量会在几秒内切到备用链路业务不中断。这种“排序”思路比删路由优雅得多也是生产环境双出口的标准做法。4.3ip rule策略路由与自定义路由表实战metric只能解决“同前缀路由谁优先”的问题解决不了“不同源地址走不同出口”的需求。比如业务场景要求来源为10.0.0.0/8的流量走内网专线其他流量走公网出口。这时就要上策略路由pbr。策略路由的配置分两步先定义规则再往自定义路由表里填路由。# 1. 添加一条策略规则来自10.0.0.0/8的流量查table 100 ip rule add from 10.0.0.0/8 lookup 100 prio 1000 # 2. 在table 100里添加路由 ip route add 10.0.0.0/8 via 192.168.10.1 table 100 ip route add default via 192.168.1.1 table 100 # 3. 刷新路由缓存使策略生效 ip route flush cache # 4. 验证 ip rule show ip route show table 100 ip route get 10.10.10.50 from 10.0.0.2关键点是ip rule里的prio数值越小优先级越高规则从上往下逐条匹配lookup 100指的是查自定义路由表100不是查主表。如果你把ip rule和ip route add table 100的命令顺序写反策略会处于“有规则没路由”的状态流量照样走默认路径。4.4 业务救急时的临时方案与收敛方案遇到线上业务因为路由问题中断我的处理原则是先临时改道恢复业务再补持久化配置绝不在高峰期直接改配置文件重启网络。比如流媒体推流服务器或录播服务器突然推流卡顿先快速看一下ip route get确认是不是走了错误的出口如果确认立刻用ip route replace把默认路由临时纠正回来业务一般马上恢复。等业务低峰期再把临时改动落成持久化配置同时保留回滚脚本。这个过程说起来简单但很多人一着急就跳过“临时改道”直接改配置重启网络结果断连时间更长反而把故障扩大了。5. 从服务器路由到业务路由排序与替换思维在其他技术栈的迁移处理过服务器路由的问题后我越来越觉得“路由”“排序”“替换”这三个词不只是网络运维的事。前端框架的内部路由、后端的数据排序、文本处理里的字符串替换底层都是同一套逻辑先明确规则再安排顺序最后确认覆盖。很多“诡异Bug”本质上是这三步里某一步出了问题。5.1 前端路由vue路由和react路由背后的排序逻辑vue-router和react-router都叫“路由”但内部对路由顺序的处理不同。vue-router的addRoute支持按name和path注册匹配时也有优先级概念react-router v6则引入了自动打分排序机制匹配顺序由参数权重自动计算不用手动排。实际开发中经常遇到“明明配了/user/:id但访问/user/profile却匹配到别的页面”。这类问题的本质和服务器路由选路一模一样具体路由和动态路由谁优先。理解“越具体越优先”这条规则前端路由和服务器路由都能少踩坑。5.2 数据排序mysql order by、hashmap和list排序的共性数据侧的“排序”也同样涉及“顺序由什么决定”的问题。MySQL的ORDER BY走索引时是索引排序走不上索引就变成filesort临时文件排序性能差异巨大Java的HashMap本身无序扩容后元素顺序还会变需要稳定顺序时就得换LinkedHashMap或TreeMap。// Java中对List按某个字段排序 list.sort(Comparator.comparing(User::getAge).reversed()); // 保持插入顺序的Map MapString, String map new LinkedHashMap();这些操作和服务器路由改metric有异曲同工之处你得先想清楚要按什么规则排再去选对应的工具否则排出来的结果永远不是你想要的。5.3 文本替换命令行到IDE的替换陷阱字符串替换这块最容易出问题的是换行符。在Linux下写的脚本拿到Windows上跑经常因为\r\n和\n不一致而报错。我处理跨平台文本时习惯先用file命令确认文件格式再决定怎么替换。# 查看文件格式 file script.sh # 用sed替换文本 sed -i s/old_text/new_text/g file.txt # 跨行替换需要perl perl -0pe s/old\n text/new/g file.txtIDE里做全局替换时也要注意勾选“正则表达式”还是“普通文本”这两个选项的匹配范围完全不同。替换前先确认匹配范围替换后立刻grep验证结果是防止“替换炸了”的最基本手段。5.4 技术迁移中的“替换”思维从doris替换es看架构决策热搜词里有“doris 替换 es”这个场景表面上是中间件选型替换实际上就是一个大型“替换”工程。从Elasticsearch迁移到Doris要处理查询语法差异、聚合逻辑差异、数据同步链路、历史数据回放等一堆问题。这和给服务器替换默认路由很像顺序安排不对跑了半天业务还是卡住的回滚方案不准备出了问题就进退两难。我每次做这类技术迁移都会先列三件事当前系统的ip route show也就是现状拓扑目标配置长什么样如果失败怎么回滚。三件事都想清楚再动手成功率会高很多。最后说点个人体会。做了这些年服务器和业务开发我最大的感受是很多问题不是不会改而是不知道“改完之后影响谁”。路由的替换、排序的调整、组件的迁移都是同一套思维。多问自己一句选路规则是什么覆盖范围是什么回滚方案是什么大部分线上事故都能提前拦住。