很多openSUSE桌面用户同时配置VPN和系统代理服务时，经常遇到网页加载失败、VPN连接后流量未进入隧道、代理规则完全失效的异常，由于openSUSE默认的网络管理架构和其他主流Linux发行版存在细节差异，直接套用通用Linux故障排查方案很容易走弯路。这份指南从实际使用场景的典型现象切入，逐步定位冲突根源，不需要额外安装第三方调试工具就能完成排查修复。
先确认冲突的典型现象，排除基础网络故障
排查的第一步不要直接修改任何配置，先把所有关联的可变因素全部清空，断开VPN连接、关闭所有系统代理服务，直接使用裸网访问公网站点，确认裸网状态下网络访问完全正常，先排除运营商线路、网卡驱动、本地防火墙默认规则的原生网络故障。
接下来分别单独启用VPN、单独启用系统代理，分别测试不同场景下的网络访问状态，如果单独开启其中任意一项服务时网络都能正常使用，只有两项服务同时启用时才出现断网、流量走向不符合预期的情况，就可以确定故障属于二者的配置冲突，而非单个组件本身的功能异常。
检查NetworkManager的路由优先级冲突
openSUSE桌面默认使用NetworkManager统一管理所有网络连接，不管是VPN生成的隧道路由，还是系统代理写入的静态路由规则，都会被统一调度，很多冲突的根源是VPN推送的默认路由和系统代理配置的静态路由优先级重叠，导致内核选路逻辑混乱。
打开终端输入ip rule show命令，查看当前系统的路由策略表，正常情况下VPN生成的专属路由表优先级应该高于普通有线无线连接的主路由表，而系统代理通过全局配置写入的路由规则，优先级数值不能和VPN的路由表数值重复，否则就会出现选路冲突。
如果排查发现两条规则的优先级数值完全相同，就会出现流量随机切换路径、甚至直接丢包的异常，这时候可以打开nm-connection-editor工具找到对应的VPN连接配置，在IPv4设置的高级路由选项里，取消“自动从对端获取路由”的勾选，手动把VPN路由的优先级数值调整得比系统代理的路由数值更低，路由优先级数值越小代表匹配优先级越高。
排查代理配置的作用范围覆盖冲突
很多openSUSE用户习惯在桌面环境的系统设置里开启全局代理，同时又在VPN客户端的配置页面里填写了相同的代理地址端口，相当于两层代理转发规则叠加，很容易形成循环转发的死锁，导致所有网络请求都无法得到响应。
先打开系统设置的代理面板，查看当前代理的配置模式，如果设置的是所有协议流量都走代理，要同步检查VPN连接配置里的代理选项，要是这里也填写了和系统代理相同的地址端口，直接把VPN配置里的代理选项改成“无”，VPN的隧道连接流量本身不需要走本地代理转发。
还有一类常见误区是用户单独给终端配置了环境变量代理，而桌面环境的全局代理配置没有同步，VPN连接之后终端的代理规则和NetworkManager调度的桌面流量规则不统一，会出现浏览器能正常上网但终端工具完全连不通的情况，这时候可以在终端输入env | grep -i proxy命令，把多余的终端代理环境变量临时清空，测试冲突是否消失。
验证修复后的流量走向是否符合预期
调整完所有配置之后不要直接结束排查，先依次连接VPN、启用系统代理，打开浏览器访问可以查看出口IP的公开站点，确认当前的出口IP和代理、VPN的预期配置匹配，没有出现流量漏走的异常情况。
如果用户的使用场景是部分流量走代理、部分流量走VPN的分流模式，要单独测试分流规则里的不同目标站点，确认没有出现本该走VPN的流量被代理拦截，或者本该走代理的流量被VPN隧道转发的问题。
如果调整配置之后还是出现偶发的冲突，可以打开openSUSE的防火墙配置面板，把VPN用到的服务端口和本地代理服务的监听端口都加入信任列表，避免firewalld的默认规则拦截二者之间的本地转发流量，绝大多数场景下的冲突都可以通过上述步骤定位解决。
