Mac 上的 VPN、内容过滤器与 Private Relay：当前哪个在生效
Mac 的三层网络在设置里长得一样。用出口路径、流策略和浏览范围，区分 VPN、内容过滤器与 Private Relay。
你的 Mac 可以同时装有 VPN 隧道、内容过滤器和 iCloud Private Relay，而它们没有一个会说明是哪一层在塑造某条连接。设置面板彼此相似，图标彼此相似，几乎每个厂商都把自己的产品叫作网络安全。三个事实能把它们分开：流量是否从你能叫得出名字的远端出口离开，策略引擎是否在逐条流上做允许或丢弃的决定，以及保护是否止步于 Safari。把这三点理顺，大部分“我的 VPN 开着吗”都会自己给出答案。
识别组件的三个条件
条件一是出口。隧道提供商会把数据包交给远端网关，因此你的公网地址会变化，而且如果配置档这么写，该网关后面的主机会变得可达。如果地址从不改变、也没有任何私有子网打开，那你看的不是一条能用的隧道，无论菜单栏怎么说。
条件二是决定。内容过滤器会评估每条流并返回允许或丢弃。它可以执行分类封禁、按应用生效的规则，或雇主下发的策略，也可以记录判定结果。它单独做不到的，是给流量一个去处。
条件三是范围。Private Relay 保护的是浏览中一个被划定的片段，而不是整台设备，它的职责是把“你是谁”和“你访问什么”分开，而不是把你放到另一个网络里。
把三者并排一看，边界很难错过：
| Layer | Question it answers | Evidence to look for | What it does not do |
|---|---|---|---|
| VPN tunnel provider | Where does my traffic emerge, and which private networks can I reach? | Changed public address, a connected service, a default route through a utun interface | Enforce per-app content policy |
| Content filter | May this flow proceed, and who decided? | A filter extension in Network Extensions, drop verdicts, an MDM profile | Supply a different public exit |
| iCloud Private Relay | Can the local network see which sites Safari loads? | A relay egress address in Safari only, the relay toggle in iCloud settings | Cover other apps or grant access to a private subnet |
内容过滤器是策略引擎，不是出口
在 macOS 上，过滤器以 Network Extension 的形式出现，建立在 Apple 的过滤器数据提供方类 NEFilterDataProvider 之上。在受管理的部署中，它由 MDM 推送、以系统扩展方式安装，并在 System Settings > General > Login Items and Extensions 中一次性批准。此后它会看到 TCP 流，某些配置下也看到 UDP，并对每条流返回判定。
让人困惑的是它的失败方式。丢弃一条流的过滤器会造成超时、卡住的 TLS 握手或重置，看起来和“隧道已建立却送不出流量”一模一样。公网地址从未改变，因为本来就没有可改变它的出口。
商用客户端常常把两种角色打包在一起。一个安装包同时带来隧道提供商和过滤器，过滤器负责阻断，隧道负责选路。所以应用名字并不能告诉你究竟是哪个组件拒绝了连接。先看扩展列表，再看已连接的服务，最后看客户端日志，按这个顺序。
Private Relay 覆盖的是 Safari，不是整台机器
Private Relay 把它所覆盖的浏览经两条由不同运营方分别运营的中继送出，因此没有任何单一运营方同时掌握你的身份和你的目的地。这是一种隐私设计，不是隧道：没有可以进入的网关，没有私有子网，也无法把出口地址固定在你选定的国家。
它的范围刻意很窄：覆盖 Safari 浏览，以及随之而来的 DNS 查询和不安全的 HTTP 加载。终端会话、邮件客户端、聊天应用和游戏启动器都在它之外。如果在终端里检查仍显示你的接入网地址，而 Safari 显示的是中继地址，那正是预期结果，不是安装坏了。
可用性是有条件的。它需要 iCloud+ 订阅，并非所有地区都提供，受管理的网络也可能封锁中继访问，此时 Safari 会回退到直连。Apple 的 Private Relay 概览是当前范围的参考。当 VPN 配置档已连接并承载那份流量时，中继不会叠在它上面；路径由配置档决定。
按正确顺序读证据
先看服务状态，因为这是最便宜的信号。scutil --nc list 会列出已配置的 VPN 服务以及每一个是否已连接。一个配置档可以在那里放上好几年从未连接过，而人们常常把它算作隧道。
然后看接口和路由。ifconfig 会显示 utun 接口，但仅凭它们的存在说明不了太多，因为 macOS 把 utun 用于 VPN 之外的多种用途。关键在默认路由是否指向其中之一，这由 route -n get default 报告。
关于名称解析，scutil --dns 会列出系统实际会使用的解析器，DNS 代理提供方也会出现在那里。把 dig +short example.com 与 dig +short example.com @1.1.1.1 对比，就能把正在应答的解析器和被劫持的解析器分开。
扩展活动会进入统一日志：log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m。你要找的是哪个扩展启动了，以及过滤器有没有对你关心的那条流报出判定，而不是背下一行日志。
在关掉任何东西之前先收窄症状
先给故障分类。名称解析不了、连接被立刻拒绝，以及连接挂到超时，是三种不同的观察，背后是三种不同的责任方。解析问题指向解析器或 DNS 代理。立刻被拒绝指向过滤器的某条规则。沉默通常指向路由，或指向一条已经建立却不转发的隧道。
在受管理的 Mac 上，应当假定过滤器属于组织。为了测试 VPN 而关掉它，恰恰移除了你想观察的那个组件，而 MDM 往往会在下次检查时把它恢复。改动任何东西之前先向管理员问清策略名称，并用出问题的那一个应用去测，而不是测整个系统。
还有一个陷阱：为了测试 VPN 而关掉 Private Relay，对境外流量什么也说明不了，因为中继从来没有覆盖过那份流量。每一层都必须在它真正管辖的应用上测试。
按这份清单走，在第一个不通过的项目处停下：
scutil --nc list是否把你预期的服务显示为已连接？- 从终端看到的公网地址，是否与接入网分配的地址不同？
- 是否安装了过滤器扩展，它有没有为失败的那条流记录判定？
- 故障是否只在 Safari 中出现？如果是，先核对中继的范围，再怪隧道。
如果四项都通过而应用仍然失败，问题在网路层之上：代理设置、证书信任，或应用层的白名单。