为什么过宽的 VPN 路由会掐断少数公共网站

大多数页面能加载，两三个却超时，浏览器于是把责任推给连接。失败的网站有一个正常网站没有的共同点：它们解析出的地址落在 VPN 安装的前缀之内。宽到足以覆盖整段公网范围的路由，会把隧道本不该承载的流量一并抓走，症状看起来像网站故障，而不是路由决策。

解析失败的那个域名，然后去看路由表，而不是盯着浏览器。

比较地址，而不是比较网站名

查清客户端实际尝试的地址，再看哪条路由与它匹配。45.61.20.10 之内的目的地会落进 45.0.0.0/8，只要该前缀存在；这与网站本身是否和隧道有关毫无关系。把失败地址与已安装前缀逐一对照，是减法题，不是猜谜。

Windows 能直接回答这两半，一次查询就能看出哪个接口、哪个下一跳赢得了选择。如果网站返回多个地址，就解析两次；把每个地址和匹配到的路由一起记下。不同地址可能给出不同答案，其中只有一个才是失败的那一例。

Resolve-DnsName www.example.org
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 45.61.20.10
Get-VpnConnection | Format-List Name,SplitTunneling,Routes

要读最具体的那条匹配前缀，而不是第一行眼熟的条目。表里存在一条路由，并不证明它赢得了查询；最长的匹配才算数。两个前缀可以同时匹配一个地址，但只有一个会收到报文。落选的那条仍留在表里，在列表里看来同样真实。

把前缀、接口和解析出的地址记下来。这三个值就是全部诊断。

找出是谁装上了这条路由

路由来自四个地方：系统原生 VPN 配置文件、管理策略、连接脚本，或者完全另一个客户端。删掉正在生效的那条可以确认它的相关性，但 下一次连接会从已保存的配置里把它重新建出来，所以要改的是源头。

先查配置文件的路由列表，再查管理策略，最后查任何在连接时运行的脚本。这个顺序与各自真正担责的频率相符，也能把改动限制在一层，而不是三层。

仔细读原生按类生成的行为

原生 Windows 配置文件有一个有文档的设置 NativeProfile/DisableClassBasedDefaultRoute，它控制一条由接口地址推断出来的自动路由。以 45 开头的配置文件地址，在这种行为下可能生成一条 45.0.0.0/8 记录，一个公网地址就是这样把整个 A 类范围都收进了隧道。

这个属性名容易读反：设为 true 会关闭推断，false 才会启用。它也与默认路由不是同一个对象，更管不住那些自行安装前缀的第三方客户端。

如果推断就是被证实的原因，就通过它的管理归属方修改配置文件，并显式给出本来要用的私有前缀。如果是脚本添加了这条记录，就修脚本。用一条同样说不清的宽路由替换另一条，只改变了症状，没有回答问题。

修好源头，再复核两条路径

改动之后重新连接，对一个失败的公共网站和一项必须走隧道的资源分别重复查询。前者现在应当解析到物理接口，后者仍应选中 VPN。不要停在第一次成功上；一个同时破坏私有访问的修复，只是把一处故障换成了另一处。

同时复核服务器端的地址规划。与公网空间重叠的地址池会反复造成这一类问题。运营方有意选择的网段值得另作讨论，而不是自动重新编号。

调高 MTU 或清空 DNS，都纠正不了仍在把该地址送进隧道的那条前缀。先测选择，再测路径。