最近在使用双 VPN 的网络环境时,遇到了一次比较典型但又容易被忽略的问题:一边需要翻墙访问公网,一边又要连接公司内网,结果发现内网网站通过域名无法访问。这里记录一下整个排查和解决过程,作为一篇个人使用日志。
背景
当时的网络环境是同时开启了两个 VPN:
VPN A:Mihomo Party
- 用于翻墙访问墙外网站
- 采用规则模式,规则中已经排除了内网域名
VPN B:OpenVPN
- 用于访问公司内网
- 内网中包含数据库、内部网站以及其他服务
从设计上看,两个 VPN 的职责是明确分开的:
公网流量交给 Mihomo,内网流量交给 OpenVPN。
问题现象
问题出现时的表现比较奇怪:
- 公网网站可以正常访问,翻墙没有问题
- 内网数据库可以正常连接
- 但通过浏览器访问内网网站(使用域名)却始终打不开
这说明问题并不是简单的“内网不通”。
初步排查
首先检查的是最基础的连通性。
使用 ping 测试内网域名,结果是正常的,这意味着:
- OpenVPN 隧道是通的
- 内网路由没有问题
既然网络层没问题,那就只能把注意力放到应用层。
逐步定位问题
接下来我把关注点放在浏览器和代理行为上。
浏览器默认是依赖系统代理的,而 Mihomo Party 启动后会接管系统代理设置。虽然在 Mihomo 的规则中已经把内网域名设置为 DIRECT,但浏览器的请求实际上仍然会先被送到 Mihomo。
这一步本身并不一定有问题,真正的关键在于 DNS。
DNS 解析路径的差异
在这个双 VPN 场景下,实际上存在两套完全不同的 DNS 解析路径。
当流量走代理时:
浏览器
→ Mihomo Party
→ Mihomo 内置 DNS 或公网 DNS
这种情况下,内网域名是无法被正确解析的。
而当流量真正直连时:
浏览器
→ 系统路由
→ OpenVPN 下发的内网 DNS
只有走这条路径,内网域名才能解析成功,内网网站才能访问。
问题就出在这里:浏览器访问内网网站时,并没有真正绕过系统代理。
问题根因
总结下来,根因其实很清晰:
浏览器访问内网域名时,流量仍然被系统代理交给了 Mihomo,导致 DNS 使用的是公网侧的解析器,而不是 OpenVPN 提供的内网 DNS,从而造成内网域名解析失败。
解决办法
解决思路其实很直接:
让浏览器在访问内网资源时,彻底绕过系统代理。
在 Windows 系统中,这需要通过配置 系统代理的例外规则(ProxyOverride) 来实现。
具体操作如下:
- 打开 Internet 选项
- 进入 连接 → 局域网设置
- 在 代理服务器 中点击 高级
- 在“不使用代理服务器的地址”中添加内网地址和域名,例如:
localhost;127.*;192.168.*;10.*;
172.16.*;172.17.*;172.18.*;172.19.*;172.20.*;
*.suanleme.local
完成以上配置后,浏览器在访问这些地址时将:
- 不再经过代理程序
- 直接使用系统路由和内网 DNS
- 内网网站可以正常访问
但在实际使用中很快发现,这种方式只能暂时生效。
只要重新启动 Mihomo,系统代理的例外配置就会被覆盖,无法持久化。
针对系统代理配置不可持久化的问题,后续对原因进行了进一步排查,并最终通过脚本的方式进行修正,完整的分析和解决过程已整理如下:
再看一次整体流程
调整完成后,整个访问逻辑就变得很清晰了。
-
内网域名
- 浏览器直连
- 使用 OpenVPN 下发的内网 DNS
- 可以正常访问
-
公网域名
- 浏览器走系统代理
- 由 Mihomo Party 转发
- 使用 Mihomo 内置 DNS 翻墙访问
内网和公网各走各的路,互不干扰。
结果验证
修改系统代理例外后:
- 浏览器可以正常访问内网网站
- 公网网站依然可以正常翻墙
- 内网数据库访问没有受到任何影响
双 VPN 可以稳定同时使用。
小结
这次问题的关键不在 VPN 本身,而在于浏览器、系统代理和 DNS 之间的配合关系。
在双 VPN 环境下:
- 分流规则只是第一步
- 系统代理例外决定浏览器是否真正直连
- DNS 解析路径最终决定访问是否成功
把这几个点想清楚之后,这类问题基本都能快速定位和解决。
Top comments (0)