ip route 添加的路由重启后失效，因其仅为运行时配置，不持久化；需写入系统网络配置文件（如 Debian/Ubuntu 的 /etc/network/interfaces 或 RHEL/CentOS 的 network-scripts）才能生效。

为什么 ip route 添加的路由重启就没了

因为 ip route 是运行时配置，只写入内核路由表，不持久化。系统重启、网络服务重载（如 systemctl restart NetworkManager 或 systemctl restart networking）都会清空这些规则。

常见误操作是执行完 ip route add 10.200.0.0/16 via 192.168.1.1 dev eth0 后测试通了，就以为“配好了”，结果第二天发现失效。

• 临时调试用 ip route 完全没问题，但生产环境必须落盘
• Debian/Ubuntu 系统应写入 /etc/network/interfaces 的 up 段；CentOS/RHEL 8+ 推荐用 NetworkManager 的 connection 配置或 /etc/sysconfig/network-scripts/route-ifname
• 若用 systemd-networkd，需在 .network 文件中加 [Route] 小节

如何让多网卡出口流量走指定路由而不冲突

关键在于避免默认路由（0.0.0.0/0）重复或掩码覆盖错误。典型场景：服务器有 eth0（公网）、eth1（内网），想让所有访问 172.16.0.0/12 的流量强制走 eth1，其余走 eth0 的默认网关。

错误做法是直接加一条 ip route add 172.16.0.0/12 via 10.0.1.1 —— 如果没指定 dev，内核可能选错出接口；如果已有更精确路由（如 172.16.10.0/24），新路由还可能被忽略。

• 务必显式指定 dev： ip route add 172.16.0.0/12 via 10.0.1.1 dev eth1
• 检查是否存在冲突：用 ip route get 172.16.5.10 查看实际匹配路径
• 若需策略路由（比如按源 IP 分流），必须配合 ip rule 和独立路由表，不能只靠 ip route

ip route replace 和 ip route change 的区别在哪

两者都用于更新已有路由，但行为不同：replace 先删后加，change 只改参数、不重建。这个差异在涉及 TTL、MTU、优先级等属性时特别关键。

例如你有一条带 MTU 限制的路由：ip route add 192.168.100.0/24 via 192.168.1.254 dev eth0 mtu 1400，之后想把 MTU 改成 1300：

ip route change 192.168.100.0/24 via 192.168.1.254 dev eth0 mtu 1300

而用 replace 会触发一次路由删除再插入，可能造成短暂丢包；change 则原地修改，对转发无中断。

• 只要目标网络和下一跳不变，优先用 change
• replace 更适合“不确定原路由是否存在”的脚本场景（避免 No such process 错误）
• ip route show 输出里带 proto kernel 的通常是内核自动生成的直连路由，change 对它们无效

为什么 ip route flush cache 不起作用

因为现代 Linux 内核（2.6.32+）已移除路由缓存机制，ip route flush cache 是个空操作，执行后既不报错也不生效。这是很多老教程遗留的误区。

真正影响路由决策的是 FIB（Forwarding Information Base）表，它实时更新、无需手动刷新。所谓“路由不生效”，99% 是以下原因：

• 新添加的路由被更长前缀匹配的已有路由覆盖（用 ip route get x.x.x.x 验证）
• 策略路由规则（ip rule）优先级高于主表，导致流量没进 main 表
• 反向路径过滤（rp_filter）开启且不匹配，直接丢包（查 sysctl net.ipv4.conf.all.rp_filter）

遇到“加了路由却不通”，别急着刷缓存，先跑一遍 ip route get 和 tcpdump -i any host x.x.x.x 看包到底从哪出、有没有被 drop。