在命名空间中启动的 Firefox 将 URL 交给了已有实例

一条命令在 VPN 命名空间内运行，Firefox 窗口出现了，页面却仍从普通连接出去。路由配置很可能不是首先要重建的东西。检查该命令是创建了你预期的浏览器实例，还是把 URL 交给了已在别处运行的实例。这一区别一步就能解释结果，并省下一小时的 nftables 排查。

线索是窗口瞬间出现，没有冷启动。

新窗口不等于新实例

桌面应用通常会复用已有进程。某个网络命名空间里的启动器不会把已在运行的接收方搬进该命名空间，因为接收方从来不是启动过程的一部分。Firefox 的远程控制行为与配置文件相关：针对已在使用中的配置文件启动，会把参数交给它的属主。新窗口是真的，新的网络路径不是。

隐私浏览和新窗口选项都不是网络隔离控制。

只影响窗口模式的命令行标志也不是。如果配置文件被占用，请求会交给拥有它的进程，而该进程会保持它启动时的命名空间。

在独立配置文件上强制使用独立实例

使用通过浏览器受支持的配置文件工作流程创建的专用配置文件，并用该配置文件明确启动。在支持这一点的 Firefox 构建中，--new-instance 会要求新实例，而不是在已有实例里开窗口。查看已安装构建自带的帮助输出，因为可用标志因版本而异。

不要同时打开同一个活动配置文件，也不要把「配置文件正在使用」的警告当成删除锁文件的指示。

也要在普通的非 root 用户下运行浏览器。网络设置往往需要管理员权限，而因为它属于同一个实验，很容易顺手把同样的权限也给浏览器。图形浏览器并不需要这些权限，以 root 运行它会带来另一类配置文件和权限问题。把权限与网络路径当作两个独立决定。

检查哪个进程承载流量

在 Linux 上，进程的网络命名空间可以通过它的命名空间链接看到。先为你认为在发请求的进程读取，再为实际发请求的进程读取。

readlink /proc/ACTUAL_PID/ns/net

浏览器会运行多个进程，所以身份很重要：建立连接的内容进程可能不是你最先检查的那个。把链接与你想要的命名空间对比，并用一个你能归到单个实例的、全新的无害请求来确认。归属就是全部检验。如果你说不出是哪个进程建立了连接，那你就没有检验命名空间。

当命名空间真的不对时

有时启动器确实失败了，新实例在错误的命名空间里启动。检查启动它的服务或包装器，因为单元或桌面条目在通过会话总线重新执行时可能丢掉命名空间。然后在责怪浏览器之前，从正确命名空间内的 shell 再测一次。一次只动一个变量，才是让这件事保持可诊断的唯一办法。

共享显示器也不会共享解析器。

如果进程在正确的命名空间里，而名称解析仍然失败，把它的解析器环境当作单独问题来查。另一次路由改动无法搬走一个在开始之前就已交给错误实例的请求。