跃点调低仍不走 VPN？路由前缀与出口选择怎么查

把 VPN 接口的跃点数调低，仍然没走预期出口，先别继续把所有数值改成 1。Windows 选择普通 IP 路由时，先看哪条路由更具体，再比较同等前缀长度下的成本。因此，低跃点的默认路由，未必能覆盖一条更具体的目标路由。

本文聚焦 Windows 的 IPv4 路由诊断，使用 NetTCPIP 模块中的只读命令。它帮助解释系统为某个地址选择的路径，不替代应用代理或客户端内部规则的检查。

先比较前缀，再比较跃点成本

DestinationPrefix 表示路由覆盖的目标范围，斜杠后的数字是前缀长度。对于同时匹配的目标，/24 比 /0 更具体；只有范围匹配的路由才参与比较，不能把全表中数值最大的前缀直接选出来。

Microsoft 的 Metric 说明明确区分这两个步骤：优先选择最长匹配前缀，同等前缀长度下才比较跃点。因此，给默认路由降低成本，并不会改变它覆盖范围较宽这一事实。

这里的“跃点数”指路由选择中的 Metric 成本值，不是一次 MTR 或 traceroute 中实际经过了几台路由器。

用一个示例看清比较顺序

假设目标是 203.0.113.9，有下面三条可用候选路由。表内地址与数值只用于计算，并非实测；不要把它们添加到电脑。

目标前缀	出口	RouteMetric	InterfaceMetric	合计
`0.0.0.0/0`	物理接口	1	5	6
`203.0.113.0/24`	VPN A	10	20	30
`203.0.113.0/24`	VPN B	5	40	45

三条都能匹配目标，但两条 /24 更具体，先排除 /0。随后在两条 /24 中比较，VPN A 的合计 30 小于 45，所以应优先于 VPN B。只看 RouteMetric，会把 B 的 5 错当成更优；只看全表合计，又会误选物理接口的 6。

在 Windows 的这项比较中，合计由路由跃点 RouteMetric 加上接口跃点 InterfaceMetric构成，依据 Get-NetRoute 的 RouteMetric 文档。这两个字段需要分开核对。

为什么只盯着默认路由容易看错？

默认路由 0.0.0.0/0 是较宽的匹配范围。某些 VPN 会添加更具体的路由，而不是直接删除原来的默认路由。

例如，OpenVPN 手册中的 redirect-gateway def1使用 0.0.0.0/1 和 128.0.0.0/1 覆盖 IPv4 地址空间，同时保留原默认路由。看到物理网卡的 /0 还在，不能据此认定流量没进隧道。应检查目标匹配到了哪条路由，而不是只数有几个默认网关。

这是一种具体实现示例，不表示所有 VPN、TUN 客户端都采用相同前缀。也不要为了“只剩一个网关”删除客户端建立的路由。

三步读取当前选择，不先改配置

第一步：对真实目标查询系统选路

在 PowerShell 输入要检查的真实 IPv4 地址，不要输入带路径的网址。尽量从应用诊断记录中确认本次连接的地址，避免把同一域名的另一个服务器当成同一次请求。

$targetAddress = Read-Host '输入要检查的真实 IPv4 地址'
Find-NetRoute -RemoteIPAddress $targetAddress

Find-NetRoute 文档说明它会返回本地地址对象和路由对象。重点记录路由对象中的 DestinationPrefix、InterfaceIndex、InterfaceAlias、NextHop 与 RouteMetric，并区分本地源地址和目标地址。

这个查询反映选路，不是对目标服务发送一次完整访问测试；选出了路由，也不能证明后续防火墙、远端回程或应用服务正常。

第二步：读取活动路由和接口成本

Get-NetRoute -AddressFamily IPv4 -PolicyStore ActiveStore |
    Select-Object DestinationPrefix, InterfaceIndex, NextHop, RouteMetric

Get-NetIPInterface -AddressFamily IPv4 |
    Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric, ConnectionState

第一条读取活动路由，第二条读取 IPv4 接口信息。通过 InterfaceIndex 对应两份输出，再计算同等匹配前缀候选项的成本。字段与参数可核对 Get-NetRoute 和 Get-NetIPInterface 文档。

先用第一步确认系统结果，再用第二步解释原因；不要靠表格显示顺序判断优先级，也不要只按 RouteMetric 给所有路由排序后就选第一行。

第三步：固定条件做前后对照

保持同一目标地址、同一网络和同一客户端配置，在允许的条件下比较 VPN 连接前后的输出。如果只是切换了接口或重连客户端，也重新记录一次；不要继续使用上一次连接的接口编号做判断。

观察结果	更合适的下一步
意外匹配了一条更具体的路由	核对它来自哪个连接或配置，查预期分流范围
同等前缀下选中了另一接口	对照路由与接口两项成本
系统选路符合预期，应用行为不同	查应用接入方式及客户端最终出站
路径正确，但连接仍失败	转查服务端口、回程与具体错误

表中是诊断方向，不能仅凭一条异常路由就认定某个客户端有故障。

系统路由与代理出口要分两层看

HTTP／SOCKS 代理应用可能先连接代理地址，之后由代理连接目标。对网站 IP 运行系统选路查询，不会自动模拟应用自己的代理设置。TUN 接管后，客户端内部还可能继续按规则选择出站。两层关系见规则、全局与 TUN 的区别。

同样，本文的 IPv4 输出不能解释一次实际走 IPv6 的访问；双栈情况应结合IPv6 是否绕过代理的核对方法。若目标是远端 NAS，还需检查地址重叠和回程，参见局域网分流与网段冲突排查。

跃点更小，是不是速度就更快？

不能这样判断。Metric 是选路成本；Microsoft 的自动跃点说明提到，自动设置会参考接口链路速度。这不是对某个 VPN 节点或网站进行实时测速，手动调低数值也不会直接提升远端带宽。

需要修正时，先确认是覆盖范围错误还是同等前缀的优先级问题，再从原客户端或连接配置中做单项调整，并保留恢复方法。不要把“所有接口都设成最低值”当作通用优化。

可填写的排查记录

时间／目标 IPv4	匹配前缀	接口名称／编号	路由成本＋接口成本	应用最终出站／结果
待填写	待填写	待填写	待填写	待填写