临时路由用ip route add（如ip route add 10.20.30.0/24 via 192.168.1.254 dev eth0）立即生效但重启丢失；永久路由需按发行版写入配置文件：centos/rhel写/etc/sysconfig/network-scripts/route-eth0，ubuntu/debian用/etc/network/interfaces的up指令或netplan yaml的routes字段。
route 和 ip route 都能加静态路由，但临时生效和永久生效的写法、位置、甚至底层行为完全不同。别直接抄命令，先看清楚你要解决的是什么问题。
临时加一条静态路由用 ip route add 就够了
这是最常用也最安全的调试方式，适合验证网关是否可达、目标网段是否能通，或者临时绕过某个故障路径。
-
ip route add 10.20.30.0/24 via 192.168.1.254 dev eth0：必须指定via（下一跳）和dev（出口网卡），否则内核可能选错接口 - 如果漏掉
dev，而机器有多个网卡，流量可能从错误接口发出，回包失败——ping通但ssh或curl卡住就是典型症状 - 加完立刻生效，不用重启服务；用
ip route show查看，用ip route del 10.20.30.0/24删除 -
route add -net也能用，但语法更易出错：比如忘记netmask会导致掩码变成255.255.255.255，整个网段变单点路由
CentOS/RHEL 系统永久路由要写进 route-<em>iface</em> 文件
不是改 ifcfg-eth0，也不是丢进 /etc/rc.local——那是老系统兼容写法，新版 network 服务会忽略它。
- 文件路径必须是
/etc/sysconfig/network-scripts/route-eth0（接口名替换成你的真实设备，如ens33、bond0） - 内容格式严格：
10.20.30.0/24 via 192.168.1.254 dev eth0，不能带ip route add前缀，也不能用gw - 写完执行
systemctl restart network，不是systemctl restart networking（后者是 Debian 的） - 如果重启后没生效，检查
journalctl -u network，常见错误是接口名拼错，或route-<em>iface</em>文件权限不对（应为 644）
Ubuntu/Debian 永久路由得塞进 /etc/network/interfaces 的 up 指令里
Netplan 用户注意：如果你用的是 netplan（Ubuntu 17.10+ 默认），就别碰 interfaces 文件——它会被忽略，得在 .yaml 里配 routes 字段。
- 在对应接口块末尾加一行：
up ip route add 10.20.30.0/24 via 192.168.1.254 dev eth0 - 不能写成
post-up，某些旧版本 ifupdown 不识别；也不能漏掉up前缀，否则不会执行 - 改完运行
ifdown eth0 && ifup eth0，不要systemctl restart networking——它可能不重载up指令 - 如果用了 Netplan，配置要这样写：
routes: - to: 10.20.30.0/24 via: 192.168.1.254 on-link: true；on-link: true表示下一跳直连，避免查 ARP 失败
多网卡场景下，route add default gw 会破坏对称路由
一台机器有两个网卡（比如 eth0 接内网、eth1 接外网），想让某网段走 eth1，千万别只加一条 route add default gw——它会覆盖原有默认路由，且所有回包都强制走那个网关，导致 SSH 断连、HTTP 请求超时。
- 真正要做的，是用策略路由：
ip rule+ip route table - 先在
/etc/iproute2/rt_tables里注册新表名，比如100 tab_eth1（ID 不能重复，不能含短横线） - 然后分别给每张网卡建独立路由表：
ip route add default via 192.168.10.1 dev eth0 table tab_eth0，再加ip rule add from 192.168.10.100/32 table tab_eth0 - 这个过程没有“一键配置”，顺序错一步，回程路径就断了；建议先用
tcpdump -i eth0抓包确认出入接口是否一致
永久化配置容易漏掉接口名匹配、服务重启方式、以及多网卡下的策略路由隔离。临时命令看似简单，但一旦写进启动脚本或配置文件，就得考虑执行时机、依赖关系和错误兜底——很多“重启后失效”问题，其实不是命令错了，而是它根本没被执行。
