打开第二个浏览器不会产生第二条 VPN 路由

两个浏览器、两个窗口，一个用工作账号，一个用个人账号，于是人们以为它们从此走不同的路径。事实并非如此。配置文件隔离只把 Cookie 分开，而路由决策发生在浏览器之下，根本不知道是哪个配置文件发起的请求。第二条路径需要一条选中它的规则，而这条规则能落脚的地方只有寥寥几处。

状态隔离不是路径隔离

浏览器配置文件隔离的是存储：Cookie、历史记录、扩展，有时还包括凭据。这种隔离在一个进程树内部执行，对哪个接口承载数据包没有任何发言权。

隐私窗口在观感上走得更远，在路由上却一步也没多走。浏览器发出的一切仍然沿操作系统选定的路径离开，除非套接字与网络之间有东西改变它。把存储隔离和网络隔离混为一谈，会产生浏览器厂商从未承诺、也没有任何测试能满足的期待。

究竟是什么在选择路由

有四样东西可以选择不同的路径：匹配可执行文件或包名的按应用 VPN 规则、在浏览器或系统内配置的代理、网络命名空间或容器，以及第二台物理设备。每一样都改变了真实的东西，也各有各的成本。

在移动平台上，按应用规则是常见的答案，因为 VPN 服务会收到一份包名列表。在桌面上则取决于客户端，而一条匹配可执行文件的规则会覆盖该文件打开的所有配置文件。如果两个配置文件真的需要不同路径，通常需要的是两个不同身份的进程，而不是两个标签页。这就是为什么在按配置文件的设计里，共享的浏览器安装永远不能成为边界。

应用层代理又多了一层中间人

浏览器里的代理设置确实会创建一条独立路径，同时也会与运营代理的一方建立一份独立的信任关系。对单个配置文件来说这是正当安排，但它并不等同于覆盖整个设备。

要有意识地选择代理：同一主机上的 SOCKS 监听、隧道内部带认证的代理，或者一个远程服务。把代理和全隧道 VPN 混在一起，会产生故障模式成倍增加的嵌套路径。

验证每个浏览器的真实请求

从每个浏览器发送同一个请求，比较观测到的出口地址，而不是比较设置页面。配置了代理却悄悄连不上，是回到默认路径时非常常见的情形。

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --proxy socks5h://127.0.0.1:1080 https://api.ipify.org
dig +short example.com

然后强制走代理、再关闭隧道，重复同一个请求，看哪一层真正承载流量。也要记录 DNS 的应答，因为自带加密解析器的浏览器可以完全绕开系统路径，却仍然显示你预期的页面。

把预期的映射写成两行：哪个进程走哪条路径，以及各自归谁所有。也要留意账号身份，因为两条路径并不能阻止同一个登录同时呈现给两个目的地。下一次浏览器更新之后要重新测试，因为代理设置容易丢失，也很难察觉。