为什么 Little Snitch 在 VPN 下仍然列出浏览器？

你打开 VPN，再打开 Little Snitch，浏览器就在那里，带着一条连向你以为走了隧道的网站的连接。那条条目本身并不能证明发生了泄漏。本地监控报告的是哪个进程在这台机器上打开了套接字，而浏览器确实打开了它；VPN 客户端是随后接管这些数据包的第二个进程。两句话同时成立，而界面展示给你的是第一层。

本地监控能归属什么、不能归属什么

归属发生在套接字上。内核知道哪条连接属于哪个进程，因此 Little Snitch 能以很高的把握把条目标成应用名。它默认看不到的是 VPN 围绕这股流量建立的外层连接，因为那属于另一个进程。

域名比看起来要弱。在 HTTPS 连接里，名字可能来自 DNS 查询、握手时提供的服务器名，或对地址的反向解析，取决于系统观察到了什么。这些都不需要解密页面，也都不能证明字节之后去了哪里。

所以浏览器条目回答的是谁，不是去哪。把它当作归属数据，去别处看在哪。

第一步：从空窗口开始，而不是滚动历史

旧条目无法告诉你当前配置做什么。把时间过滤器切到从现在开始，或按 Command-K，让窗口只显示该时刻之后出现的连接。

然后在你正在排查的应用里只做一件无害的事，比如加载一个你被允许加载的页面。一个动作、一个时刻，出现的条目才能不靠猜地对应上去。完成后等一两秒，因为一次页面加载会产生一批连接而不是一条。列表还在填充时就去读，几乎必然误判顺序。

读结果之前，先检查搜索框或状态过滤器是否把列表缩小了。上一次会话遗留的过滤器，是连接看起来消失、其实只是被隐藏的最常见原因，也是两个人看同一台机器却说法不一致的原因。

第二步：把扩展连接也显示出来，看到隧道本身

在当前 macOS 版本上，VPN 客户端通常是网络扩展而不是普通应用。在 Monitor 里打开显示网络扩展，该扩展建立的连接就会和其他一切一起出现。

现在两层可以一起读：浏览器是请求的来源，扩展是承载它的传输通道。两层都看到是正常且预期的；只看到扩展通常说明视图被过滤了，只看到应用则说明扩展视图没开。

任何单一视图都无法清点整条路径。路由规则、DNS 行为以及按应用的例外都在连接列表之外，所以要得到完整答案，需要单独检查这些。

第三步：把真正的直连和显示效果区分开

如果你怀疑某个目的地走了直连，就点名那个目的地并单独检查它。查看 VPN 客户端针对该主机或应用自己的路由与拦截配置，确认它是否本应被排除。

不该做的是把界面上每一条浏览器条目都拦截掉。浏览器仍然必须建立连接，而在监控里拦截并不会把它们导进隧道，只会让它们失败。这会把一个诊断问题变成一次故障。如果确实需要规则，就把它限定在你能够解释的那一个目的地上，并写明它为什么存在。

同样的谨慎适用于域名那一列。让你意外的名字可能是共享主机名、内容分发端点，或隧道建立之前发生的一次查询；把它当成泄漏证据，会写出破坏正常流量的规则。

第四步：把视图和规则分开

这个练习里的每一步改变的都只是监控显示什么。它们都不改变防火墙允许什么，也不会把流量搬进或搬出隧道。

结束时把过滤器还原到你能够解释的状态，避免下一个人打开窗口时读到你留下的视图。如果问题是一个目的地是否走隧道，请从路由与排除设置回答，然后用监控确认结果，而不是靠猜。