VPN 已连接，但 IP 地址没有变化：原因在这里

你连上了，客户端显示已连接，地址测试却仍然显示原来的那个数字。指示灯没有错；是配置文件和应用程序之间的某个环节，让这次请求留在了隧道之外。在动手改任何配置之前，先判断你面对的是三种情况中的哪一种：一个从未测量公网地址的测试、一条只覆盖部分流量的隧道，或者一条抢走路由决策的第二条路径。每一种都有一项不到一分钟的检查。

确认测试究竟测到了什么

Wi-Fi 或以太网对话框里显示的是你自己网段上的接口地址，而不是网站看到的地址，所以隧道完全正常时它也可以保持不变。位置又是另一个信号：已保存的账户区域、被允许的定位读数，都不会因为你更换出口而改变，已经认得你的登录状态也不会。

用一个公网地址回显服务，并且分别询问每个地址族，因为双栈测试结果会掩盖真正有意思的情况：

curl -4 -s https://ifconfig.me
curl -6 -s https://ifconfig.me

在连接前后各跑一次。如果 IPv4 的答案变成出口地址，而 IPv6 的答案没变，你的隧道并没有坏；是其中一个地址族走了隧道之外。如果两个答案都没变，这次请求根本没有进入隧道，下面这些就都适用。

配置文件可能只覆盖了一部分流量

分流隧道配置是最常见的原因，而且它不算故障。OpenVPN 只有在 redirect-gateway 出现在下发的选项里时，才会把所有流量放进隧道；没有它，客户端只拿到一小批具体路由，你的默认路由仍留在物理链路上。在 Windows 上，同一个开关显示为适配器 IPv4 属性里的“在远程网络上使用默认网关”，取消它是有意为之的选择，并且会在每次重连后保留。

按应用范围是第二层。Android 的按应用 VPN 设置决定哪些应用被包含在内，所以状态栏里的 VPN 钥匙并不能证明浏览器就在其中。一个自己代理流量的浏览器扩展会造出镜像：浏览器显示出口地址，而同一台机器上的邮件客户端或游戏仍然显示你的地址。在两个应用里比较同一个请求。如果一个变了、另一个没变，你看到的是范围问题，而不是隧道故障。

一个地址族仍然可能走直连

大多数 VPN 配置文件是为 IPv4 写的，很多至今仍然如此。在双栈网络上，隧道为 IPv4 取用 10.8.0.x，而物理链路保留着全局 IPv6 地址和默认路由，于是支持 IPv6 的网站会被直接访问，它报告的地址就是你的运营商地址。这是 IPv4 隧道正常工作时的一种泄漏，而只讲 IPv4 的测试看不见它。

ip -4 route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

在每一个答案里读出接口。如果 IPv6 查询指向你的以太网或 Wi-Fi 设备，而 IPv4 查询指向隧道，那么这个地址族的策略是缺失，而不是损坏。在整个设备上关掉 IPv6 会让症状消失，也会把决策藏起来；更好的做法是修正配置文件的覆盖范围，或者只在那一个连接上禁用该地址族，并记下你选了哪一种。

第二条路径可能抢走查询

一个竞争性的代理、第二个 VPN 客户端、来自容器或远程桌面工具的虚拟适配器，或者为你正在测试的那个精确前缀添加的多余路由，都可能取得优先权。具体路由永远胜过默认路由，所以为被测网站留下的一条 /24，只要指向你的局域网网关，就会把那份流量继续送出隧道，无论隧道多健康。

在改动任何东西之前，先用只读命令做一次盘点：

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
nmcli connection show --active

找一找是否有多条度量值合理的默认路由，以及是否有一条覆盖目标的具体路由。在浏览器里还要确认：是代理扩展、还是系统代理设置在掌管这条连接；扩展可以指定自己的上游，而不动操作系统的出口，于是同一台机器上浏览器与终端显示的地址会不一样。

用一次全新的请求重新测量

重新连接，然后用第一次测试时的同一个应用重复测量，因为缓存页面或复用连接报告的是旧状态。连接过程中留意客户端日志或事件视图：认证之后应用路由时报错，比任何指示灯都更有说服力，而且它通常会点名失败的路由或适配器。

把两种结果分开看。如果地址变了，但某个网站仍然拒绝你，那说明隧道是通的，是网站拒绝了数据中心地址；那是另一个问题，有另一个答案。如果地址始终不变，就按顺序问这四个问题：测试打印的是哪个地址、属于哪个地址族、是哪个应用发出的请求、这个请求走了哪条路由。Microsoft 关于 VPN 路由决策的文档解释了当隧道与物理适配器都有路由时，Windows 客户端如何在两者之间选择。