很多个人用户搭建远程办公VPN、企业运维部署分支站点VPN隧道时，经常遇到明明VPN拨号已经显示连接成功，却无法访问对端内网资源，或者访问本地局域网设备的流量莫名其妙走了VPN隧道的问题，GOBOY这类故障九成以上都和VPN路由优先级的配置错误相关。不少操作者混淆了不同系统的路由优先级判定规则，踩了很多重复的坑，本文就结合Windows桌面系统、OpenWrt路由系统和企业级边缘路由的实际配置场景，梳理常见的VPN路由优先级配置错误排查思路和正确设置方法。
最常见的优先级倒置错误：静态路由度量值设置冲突
Windows系统默认生成的VPN虚拟网卡路由，度量值本身会低于物理网卡的默认路由，正常情况下访问VPN推送的内网段会优先走VPN隧道。但很多用户手动添加自定义静态路由时，错误地把VPN对应路由的度量值设置得比本地公网网关的路由更高，导致访问指定VPN内网段的流量优先走本地公网网关直接转发，最终出现目标地址不可达的丢包问题。
这类问题的排查方式非常简单，按下Win+R输入cmd打开命令提示符，执行route print命令查看完整的活动路由列表，找到目标VPN内网网段对应的条目，如果同一个目标网段同时出现两条路由，度量值数值更小的那条对应的下一跳不是VPN虚拟网卡的分配地址，就说明出现了典型的路由优先级倒置问题。
运维人员正在多设备场景下排查VPN路由优先级的配置异常问题
这个场景下的常见误区是很多人搞反了度量值的优先级逻辑，误以为度量值越大路由优先级越高，把Windows系统的配置经验直接套用到OpenWrt设备上。OpenWrt系统路由配置界面的路由度量字段默认值为0，要是手动填入过大的数值，VPN生成的路由条目会直接被运营商下发的默认路由覆盖，完全失去转发优先级。
策略路由规则顺序错误导致的VPN路由不生效
很多使用OpenWrt第三方固件的用户习惯用策略路由做流量分流，不少人配置时会把VPN的分流规则放在“默认所有流量走WAN”的兜底规则后面，但系统匹配策略路由规则是严格从上到下执行的，GOBOY匹配到第一条符合条件的规则就直接转发，根本不会继续匹配后面的VPN规则。
这类问题的排查步骤也很清晰，登录OpenWrt的终端界面执行ip rule show命令，查看所有策略路由的优先级序号，如果VPN对应的规则序号比普通WAN分流的序号更大，就说明规则顺序完全颠倒，序号数值越小对应的路由优先级越高。
这类错误的隐蔽性很强，很多用户装完VPN插件之后手动新增了全局WAN兜底规则，没有调整规则的排序，结果所有流量都不会走VPN，还反复排查VPN拨号本身的配置问题，花了几个小时都找不到路由层面的故障根源。
多VPN并存时的路由标记冲突问题
不少运维人员为了同时访问两个不同分支机构的内网资源，在同一台边缘路由设备上同时搭建了两个VPN隧道，配置时给两个VPN的路由段设置了重叠的掩码范围，又没有给不同VPN的路由配置专属的fwmark标记，系统全局路由表直接出现冲突条目，转发时随机选择下一跳，导致两个分支机构的内网访问都不稳定。
验证这类故障可以分别ping两个VPN下的已知内网服务器IP，同时用tracert命令跟踪转发路径，如果跟踪路径意外跳转到了另一个VPN的内网网段，就说明路由优先级因为标记冲突出现了混乱。正确的设置逻辑是给每个VPN的路由规则分配独立的标记值，在策略路由界面给不同标记的路由单独设置优先级，避免全局路由表的条目冲突。
验证路由优先级生效的标准操作流程
很多用户配置完VPN路由之后，GOBOYVPN只靠能不能打开公网网页判断VPN路由是否正常，很容易漏过局部网段路由优先级错误的问题。正确的验证第一步是先断开VPN隧道，用tracert命令访问目标VPN内网IP，确认路径完全走本地公网，本身无法抵达目标地址。
重新连接VPN之后再执行一次相同的tracert命令，查看路径的第一跳是不是VPN虚拟网卡的分配网关地址，如果转发路径里出现了本地运营商的公网网关，就说明对应网段的路由优先级配置仍然错误，需要返回调整度量值或者策略路由的规则顺序。
最后需要提醒的是，不要随便照搬网上的全局路由推空配置，把所有公网流量都强制设置成高优先级走VPN，一旦VPN隧道意外中断，整个设备的所有网络流量都会直接断连，反而影响正常的使用体验，GOBOY按需配置指定内网网段的高优先级路由就足够覆盖绝大多数使用场景。
