Mac VPN 推荐依据：架构、接管方式与分流
Mac VPN 推荐不能只看节点列表。网络扩展权限、M 系列芯片兼容，以及 Apple 服务共存，决定了客户端能否持续使用。选择顺序是：先确认软件适配当前系统，再确认流量如何接管，最后验证目标网站与日常同步是否都正常。
客户端与线路服务是不同层次。客户端负责读取配置、建立连接和执行规则；线路服务提供可连接的入口与出口。客户端界面显示“已连接”，只代表某个连接环节完成，不等于所有应用都已经使用该出口，也不等于 DNS 查询按预期处理。
| 使用需求 | 优先检查 | 容易忽略的限制 |
|---|---|---|
| 主要使用浏览器 | 系统代理与规则模式 | 部分应用不读取系统代理设置 |
| 覆盖更多应用流量 | 网络扩展或 TUN 接管能力 | 仍需核对路由、排除项及 DNS 设置 |
| 使用 M 系列 Mac | Apple Silicon 或 Universal 构建 | 图形界面与网络组件可能有不同兼容要求 |
| 保留 Apple 服务日常体验 | 域名分流、局域网直连与日志查看 | 网站出口与账户地区不是同一概念 |
选择结论：优先选适配当前 macOS、原生支持本机架构、能查看规则命中结果的客户端。只有浏览器需求时，不必为了功能名称主动开启更广泛的流量接管。
M 系列芯片兼容：原生运行与转译
在“关于本机”确认芯片类型，再选择对应安装包。Apple Silicon 构建面向 M 系列芯片，Intel 构建面向 Intel Mac；Universal 应用通常同时包含两类架构，但仍要查看发布说明中的系统要求。
安装后，可在“活动监视器”查看进程的“种类”列，判断实际运行的是 Apple 还是 Intel 进程。若应用提供“使用 Rosetta 打开”选项，也应检查是否被启用。能够通过 Rosetta 启动，不代表其辅助组件和网络扩展一定兼容。
不要把界面能打开作为唯一验收条件。应继续测试订阅更新、连接建立、休眠唤醒和网络切换。若问题只在唤醒后出现，先查看客户端是否恢复连接、默认路由是否变化，再考虑重装。反复重装会丢失现场信息，却未必修复路由冲突。
下载来源应是服务面板或客户端正式发布渠道。系统阻止启动时，先核对来源、签名与系统兼容说明，不要把关闭 Gatekeeper 或系统完整性保护当作常规安装步骤。
网络扩展权限：按实际提示授权
macOS 客户端可能使用系统代理、Network Extension，或通过特权辅助进程创建虚拟网络接口。实现方式不同，授权提示也不同。不是所有客户端都需要网络扩展，也不是看到 VPN 配置就意味着所有流量都必然经过远端。
- 确认提示发起者。首次启用接管功能时，检查系统提示中的应用或开发者名称是否与刚安装的软件一致，不为来源不明的组件授权。
- 允许所需配置。若提示添加 VPN 配置，确认后到系统设置的 VPN 相关页面核对。若提示批准网络扩展，按系统引导进入对应扩展设置；不同 macOS 版本的入口可能位于“通用”中的登录项与扩展，或隐私与安全性相关页面。
- 返回客户端复查。授权完成后，再启用对应模式。仅在客户端或系统明确要求时重启相关进程或设备，避免同时修改多个设置。
- 检查管理限制。受组织管理的 Mac 可能通过配置描述文件限制 VPN 或扩展。此时应联系设备管理员，不要尝试绕过管理策略。
完整磁盘访问权限、辅助功能权限并不是建立代理连接的普遍前提。若软件提出额外要求，应阅读该功能说明，区分自动化操作、文件读取与网络接管的用途。授权越多不代表连接越稳定。
订阅导入：先匹配格式，再检查连接
订阅链接通常携带配置访问凭据，应按密码级别保护。VPNRB 用户可登录面板获取订阅与 macOS 客户端入口；具体支持的格式、协议和系统版本，以面板提供的说明为准。不要将链接粘贴到公共转换网站，也不要在求助截图中展示完整地址。
Shadowsocks、VMess、Trojan、VLESS、Hysteria2 与 TUIC 不是可任意替换的配置名称。客户端需要同时支持实际协议及其参数。支持某种协议，也不代表能够直接读取任何订阅格式。这里列出的是兼容检查对象，不表示 VPNRB 提供全部协议。
- ✅ 选择客户端支持的订阅格式，将链接粘贴到“订阅”或“配置”入口，而不是浏览器搜索框。
- ✅ 手动更新订阅，确认出现线路名称；若列表为空，先检查链接完整性、套餐状态及更新错误。
- ✅ 选择线路后启用一种接管方式，保留规则模式作为日常验证起点。
- ✅ 打开目标网站并检查连接日志，区分配置解析失败、握手失败与规则未命中。
- ❌ 不同时运行多个接管网络的客户端，以免代理端口、默认路由或 DNS 设置互相覆盖。
IEPL 专线、中转和直连描述的是线路传输路径，与客户端协议不是同一维度。IEPL 通常用于专用传输链路的一段；中转经过额外转发入口；直连则由本地网络直接连接远端入口。它们都不能单凭名称证明某台 Mac 上的实际体验，需要在相同使用环境下验证。
Apple 服务共存：先看规则，不急着切地区
iCloud、App Store 和系统更新涉及不同域名、连接与账户状态。切换出口不会自动改变 Apple 账户的国家或地区。遇到商店内容、付款方式或账户验证问题，应把账户规则与网络连通分开检查，不要连续切换账户地区来排除网络故障。
日常可从客户端提供的规则模式开始，检查 Apple 相关连接命中直连还是代理。不能笼统地规定 Apple 服务必须全部直连：本地网络可能对某些目标访问不佳，而某条远端出口也可能影响下载或同步。应根据出问题的具体服务调整，改动后验证结果。
若 iCloud 文件停在等待状态，先暂停大文件传输并查看客户端连接记录；确认失败的是认证、文件传输还是其他请求，再临时改变相关规则。不要为了修复同步而直接退出 Apple 账户，账户重建可能引入额外的本地数据处理。
AirDrop、打印机和局域网共享还依赖本地网络可达性。开启虚拟接口接管后，应核对局域网网段的排除规则。发现本地设备不可见时，先暂停接管做对照，再检查客户端的局域网访问设置。
若已启用 iCloud 专用代理，它可能影响 Safari 的出口观察结果，具体行为取决于系统与网络配置。排查时可暂时停用相关功能做对照，完成后再恢复；不要将 Safari 的出口直接当作所有应用的出口。
DNS 与分流验证：连接图标之外的检查
先在客户端关闭状态下记录出口，再启用客户端，通过IP 查询页面核对浏览器当前出口。若目标是按规则代理，出口没有变化不一定是故障，可能是查询网站被分到直连；还需结合连接记录查看实际命中的策略。
DNS 泄漏通常指查询经由预期之外的解析路径发送。例如，本想让某个代理域名的查询进入隧道，却仍交给本地网络的解析器。系统代理并不天然接管所有 DNS；TUN 模式也需要正确配置 DNS 路由或劫持规则。浏览器自带的加密 DNS 又可能形成独立路径。
可以使用 DNS 检测页面观察解析器信息，并与客户端的 DNS 配置核对。但检测结果中的机构名称不能单独证明泄漏：公共解析服务可能使用分布式出口，客户端也可能有意让直连域名在本地解析。判断依据应是“实际路径是否符合预期”，而不是是否出现熟悉的地名。
终端工具也有差异。部分命令不会自动读取 macOS 图形界面的系统代理，需要显式设置代理参数或使用已经正确接管的虚拟接口；dig 的结果也不能完整代表所有应用的系统解析行为。因此浏览器能访问、终端不能访问时，应先核对接管范围，而不是立即认定线路失效。
常见故障：保留现场，逐项回退
有连接状态，网页仍打不开
先查看订阅是否有效、所选线路是否建立连接，再看请求是否进入客户端。日志里没有目标请求，优先检查系统代理或接管开关；出现域名解析错误，检查 DNS；出现握手失败，则核对节点配置、系统时间与网络环境。每次只修改一项，才能判断改动是否有效。
休眠后断网，或网络切换后不恢复
先断开客户端，再测试本地网络。若本地网络恢复，检查客户端重连与路由恢复情况；若仍不通，查看系统代理是否残留。不要只关闭窗口，应通过客户端的断开或退出操作结束接管。卸载软件前也先断开连接，避免留下失效的本地代理设置。
浏览器正常，Apple 服务或其他应用异常
确认异常应用是否使用了同一路径，然后检查相关域名的规则命中。临时切换全局代理可作为定位手段，但不应直接作为长期方案；若切换后恢复，继续定位遗漏规则或 DNS 差异，再返回日常分流设置。