策略路由是多出口网络的刚需能力，核心在于将业务逻辑映射到源ip、端口标记等维度：按源ip分流需定义清晰路由表并确保default路由与回环路由完整；按应用分流须结合iptables打标与fwmark联动；按入站接口决策适用于网关场景；容器环境中应绑定veth接口或利用networkpolicy标记实现动态策略路由。
Linux 策略路由不是“高级可选功能”，而是多出口、多业务、多租户网络环境下的刚需能力。它让流量调度从“只能看目的地”升级为“能认人、识应用、懂用途”。核心不在于命令有多复杂，而在于你能否把业务逻辑准确映射到源IP、端口、标记等策略维度上。
按源IP分流：最常用也最容易踩坑
这是中小企业双线接入（如电信+联通）的标配做法。关键不是加几条规则，而是理清优先级和表隔离：
- 先在/etc/iproute2/rt_tables里定义清晰的自定义表名，比如
100 telecom、200 unicom，避免用纯数字导致后期难维护 - 用
ip rule add from 192.168.1.10/32 table telecom绑定特定终端——注意from必须是真实发出流量的源地址，NAT后地址无效 - 每张自定义表里必须有明确的
default via X.X.X.X dev eth1，且不能漏掉to local回环路由，否则SSH可能断连 - 规则优先级数字越小越靠前，新增规则默认追加在末尾（优先级32767之后），若需更高优先级，显式指定
priority 100
按应用类型分流：绕过端口硬编码的灵活方案
直接匹配端口（如ip rule add to port 443）不可行，Linux策略路由本身不解析传输层字段。真正可行的是结合iptables打标：
- 用
iptables -t mangle -A OUTPUT -m owner --uid-owner nginx -j MARK --set-mark 1给特定进程打标记 - 再用
ip rule add fwmark 1 table app-lowlatency触发专用路由表 - 这样视频会议、远程桌面等低延迟应用就能走专线，而下载、备份走廉价链路，无需改应用配置
- 注意
fwmark是内核标记，重启后清零，建议写入启动脚本或用systemd service管理
按入站接口决策：适合网关/NAT设备场景
当一台Linux机器充当企业边界网关时，常需区分LAN侧不同子网的出口策略：
-
ip rule add iif br-lan from 10.10.1.0/24 table office表示从br-lan口进、源属办公网段的包查office表 - 搭配
ip route add 10.10.2.0/24 via 10.10.1.1 dev br-lan table office可实现内部子网间策略路由，不依赖三层交换 - 务必检查
iif是否在PREROUTING链生效——对转发流量有效，对本机出向流量无效 - 若启用了conntrack，配合
--ctstate ESTABLISHED,RELATED可确保回程路径一致，避免 asymmetric routing
与容器/K8s集成：别只盯着Pod IP
在Kubernetes中做策略路由，重点不在容器IP本身（易漂移），而在网络命名空间和接口绑定：
- 给CNI插件分配固定veth pair名（如
cali001），再用ip rule add from 10.244.1.5/32 oif cali001 table k8s-prod锁定出口 - 利用NetworkPolicy生成的iptables规则，在mangle表中标记流量，再通过
fwmark联动策略路由 - DaemonSet方式部署的策略路由守护进程，可自动监听Pod事件，动态更新
ip rule，比静态配置更适应弹性伸缩 - 注意kube-proxy的iptables模式会干扰mangle链，建议启用IPVS或eBPF模式以减少冲突
