很多用户为了兼顾内网访问、境外资源访问和本地应用的分流需求，会同时配置VPN静态路由规则和系统级、浏览器级的其他代理服务，操作后经常出现部分网站打不开、内网服务器无法访问、甚至全局断网的异常，这类问题大多属于VPN静态路由与其他代理的冲突范畴，shadowrocket本文从实际运维排查的落地步骤出发，梳理冲突的常见场景、定位方法和可复用的解决思路，不需要复杂的网络底层知识也能逐步完成排查。
冲突发生的典型现象初判
首先不要急着修改配置，先记录当前的异常表现，区分是全量网络中断还是部分业务异常，这一步能直接缩小排查范围，避免无意义的配置回滚操作。
运维人员正在排查VPN静态路由与其他代理的网络冲突问题
如果是开启VPN静态路由后，所有走其他代理的应用都出现连接超时，大概率是路由优先级被抢占，静态路由的转发规则覆盖了代理服务的出口路径，导致代理服务的回包流量无法正常回到本地监听端口。
如果是部分指定走VPN内网的业务反而跳转到公网，其他代理的流量也没有按预设规则走，说明两个服务的路由表条目出现了重叠，没有明确的转发优先级划分，系统在转发数据包时随机选择了下一跳地址。
逐项排查的核心步骤
第一步先检查系统路由表的条目优先级，Windows系统可以用内置的路由打印指令，macOS和Linux可以用网络状态查询指令，shadowrocket查看VPN静态路由生成的条目和其他代理注入的路由条目是否有同一目标网段的重复配置。
这里的预期结果是，正常情况下同一目标网段只会对应一个下一跳地址，如果出现两个不同的下一跳分别指向VPN虚拟网卡和代理服务的本地监听地址，就说明已经出现规则冲突。
第二步检查代理服务的分流规则是否和VPN静态路由的预设网段重叠，很多用户配置VPN静态路由的时候是为了访问企业内网的指定网段，却在浏览器代理的排除列表里漏加了对应内网段，导致访问内网请求被代理服务先拦截转发。
这一步排查的时候可以临时关闭其他所有代理服务，单独测试VPN静态路由对应的业务是否能正常访问，如果恢复正常，就说明冲突点出在代理的分流规则配置上，而非VPN本身的路由规则错误。
第三步检查虚拟网卡的路由度量优先级，部分系统会默认把后启动的网络服务的路由度量值设得更低，优先级更高，如果其他代理的虚拟网卡优先级高于VPN的虚拟网卡，原本应该走VPN的流量就会被代理服务接管。
通用的冲突解决配置方案
如果排查后发现是重复路由条目导致的冲突，可以手动删除冗余的路由条目，把需要走VPN静态路由的网段单独添加永久路由，指定下一跳为VPN虚拟网卡的网关地址，避免其他代理服务自动生成的条目覆盖规则。
如果是分流规则重叠的问题，只需要在所有代理服务的绕过列表里，完整添加VPN静态路由覆盖的所有内网网段，确保这部分流量不会被代理服务拦截转发即可，不需要改动原本的VPN路由配置。
很多用户容易陷入的误区是同时配置全局代理和VPN静态路由，全局代理会把所有非绕过列表的流量都转发到代理服务，本质上和VPN静态路由的分流逻辑是互斥的，小火箭加速器二者同时开启几乎必然出现冲突，非必要不要同时启用两类全局转发规则。
后续长期规避冲突的注意事项
每次新增代理服务或者修改VPN静态路由规则之后，都要重新核对一次路由表的条目，不要同时开启两个以上带全局路由注入功能的代理类服务，多个分流需求尽量整合到同一套规则体系里实现，能大幅降低VPN静态路由与其他代理的冲突概率。
如果是多设备共享代理的场景，不要在路由器层面同时配置VPN静态路由和透明代理，这类底层网络设备的路由冲突排查难度远高于单设备系统，很容易导致整个局域网的网络异常，后续排错需要逐一接入设备核对配置，耗费大量不必要的时间。
