macOS VPN 推荐这件事,难点不在装哪个客户端,而在装完之后系统给不给权限。M 系列芯片的 Mac 上,客户端要么以系统扩展加网络扩展的方式接管 utun 接口,要么退化成只监听本地回环地址的应用层代理:前者覆盖全部 App,后者只管得住愿意走代理的软件。本文按芯片架构与系统版本把这两条路径拆开,给出授权步骤、协议取舍,以及一份连上了却没通的排查清单。
macOS 客户端的三种形态
在 macOS 上做跨境访问,落到系统层面只有三条路径,区别在于谁来决定流量走向。
| 形态 | 需要的系统权限 | 覆盖范围 | M 系列 Mac 上的现状 |
|---|---|---|---|
| 网络扩展 + 系统扩展 | 放行系统扩展、授权 VPN 配置 | 全部 App 的 TCP / UDP 流量 | 主流方案,原生 arm64 |
| 应用层代理 | 无 | 仅主动设置代理的 App | 通用,受 App 支持度限制 |
| 内核扩展 kext | 需降低启动安全性 | 全部流量 | 已淘汰,新系统不建议 |
网络扩展是 NetworkExtension 框架里的 NEPacketTunnelProvider,它会在系统里建一张 utun 虚拟网卡,由客户端把流量接进隧道。这条路要两道授权:先让系统接受开发者的系统扩展,再允许客户端添加 VPN 配置。授权一次长期有效,系统跨大版本升级时可能要重新确认。
应用层代理只在本地回环地址上开一个端口,常见形式是 127.0.0.1 上的 SOCKS5 或 HTTP 代理,支持代理的 App 自己接过去。它不需要任何系统权限,装在受管电脑上也不会弹授权;代价是命令行工具和部分不读系统代理设置的应用要单独配置,后台更新这类流量也不会走代理。
内核扩展是 macOS 10.15 之后被逐步淘汰的旧方案。Apple 芯片的机器默认不允许加载第三方 kext,要开启得进恢复模式降低启动安全性。现在正规客户端不再走这条路,遇到要求关闭系统完整性保护的安装包,直接跳过。
Apple 芯片兼容性:实测中的四个卡点
M 系列芯片把能不能装和装完能不能用分成了两件事。下面四个卡点在实测里出现频率最高。
- 架构:原生 arm64 与 Rosetta 转译。用活动监视器的「种类」列就能看出来,显示 Intel 说明客户端跑在 Rosetta 2 转译层上。转译版能连,但网络扩展在转译层下偶尔握手慢、常驻内存偏高。优先选原生 arm64 的安装包,少一层不确定性。
- 签名与公证。未签名或未公证的包第一次启动会被拦下,提示无法验证开发者。到「系统设置 → 隐私与安全性」底部点「仍要打开」即可,但系统大版本更新后可能再拦一次。正规分发的安装包会做公证,不该反复出现这个提示。
- 系统扩展授权漏了一步。客户端显示已连接,utun 接口却没建立,多半是系统扩展开关没打开。位置在「系统设置 → 通用 → 登录项与扩展 → 网络扩展」,旧版本在「隐私与安全性 → 扩展」。打开后要回客户端点一次完成,授权才闭环。
- 本地网络权限。新版 macOS 里 App 首次访问局域网设备会弹「本地网络」授权。拒绝之后访问路由器管理页、NAS、打印机受限,国际线路本身不受影响。拿不准就先允许,之后在「隐私与安全性 → 本地网络」里再关。
结论很直接:在 Apple 芯片的 Mac 上,原生 arm64 加系统扩展是唯一值得作为默认的方案;应用层代理留给受管环境、临时排查,或者只需要单个 App 走国际线路的场景。
第一次启动:权限授予步骤
按顺序走一遍,能省掉大部分返工。
- 把安装包拖进「应用程序」再启动。直接在磁盘映像里双击运行,后续自动更新会因为路径只读而失败。
- 首次启动被 Gatekeeper 拦下时,去「隐私与安全性」放行,系统会要求输入登录密码或验证 Touch ID。
- 客户端请求添加 VPN 配置时点允许。这一步实际是把网络扩展注册成一条 VPN 配置,拒绝了只能在系统设置里手动补。
- 按提示打开系统扩展开关,回到客户端确认。此时「系统设置 → VPN」列表里应该有一条由客户端管理的配置。
- 用用户名加密码登录,不需要邮箱地址;同一账号不限台数,Mac、iPhone、Windows 可以同时在线。登录后导入订阅链接,线路清单会自动拉取。
- 选一条线路连上,再用后文的命令确认 DNS 与默认路由确实进了隧道。
与 iCloud 服务共存的注意点
iCloud 私密代理
私密代理和第三方客户端都是网络扩展,系统同一时间只让一条路径接管流量。常见表现是开启客户端后私密代理变成不可用,或者反过来,私密代理把客户端的隧道顶掉。要做的是二选一:需要固定出口地区、需要按域名分流时,在「系统设置 → Apple 账户 → iCloud → 私密代理」里把它关掉。
私密代理关闭不影响 iCloud 同步、iMessage 与查找,这些走的是普通 HTTPS,只是不再经过 Apple 的两跳中继。
接力、隔空投送与通用剪贴板
这些功能走蓝牙与点对点 Wi-Fi,不经过 utun 虚拟网卡,正常情况下开不开加速都一样用。例外是把按需连接配成全局接管、并且把局域网网段也塞进隧道的场景:此时设备发现会变慢。把 192.168 这类私有网段和 .local 域名放直连,问题就消失。
iCloud 云盘与地区判定
云盘、照片同步是普通 HTTPS 流量,会跟着隧道走。线路带宽有限时,把大文件同步和加速时段错开即可。另一个常见误解是换个出口就能改 App Store 地区:账号地区由 Apple 账户的账单信息决定,和出口 IP 无关,换线路不会让商店内容变化。
协议与线路:macOS 上的取舍
协议决定客户端怎么把流量接进隧道,线路决定接进去之后走哪条路。两件事分开看。
| 协议 | 传输层 | macOS 上的接管方式 | 说明 |
|---|---|---|---|
| Shadowsocks | TCP / UDP | 网络扩展或本地代理 | 结构简单,规则好写 |
| VMess / VLESS | TCP,可套 TLS | 网络扩展 | 与 TLS 组合后与普通 HTTPS 同形 |
| Trojan | TCP + TLS | 网络扩展 | 需要有效证书,握手接近 HTTPS |
| Hysteria2 / TUIC | QUIC(UDP) | 网络扩展转发 UDP | 弱网表现好,对 UDP 质量敏感 |
TCP 系协议在 macOS 上由网络扩展统一接管,所有 App 都吃得到,兼容问题最少。Hysteria2 与 TUIC 跑在 QUIC 上,对 UDP 转发链路更敏感:线路的 UDP 质量差时,典型表现是网页能开、视频卡。把它们当备选而不是默认,更稳妥。
线路类型上,IEPL 专线是端到端专有链路,晚高峰抖动小;中转经第三地转发,成本低、路径长;直连的延迟基本取决于物理距离。选哪条不看名字,看目标服务在哪个地区:目标在美国西海岸就选洛杉矶方向的出口,目标在日本就选东京。隧道内统一使用军工级加密,协议之间的差别在传输方式,不在加密强度。
分流规则值得单独调一次。macOS 客户端通常支持按域名后缀、IP 段、进程名三种方式判断走向:国内站点与局域网放直连,只让需要的域名走隧道,既省带宽也少一次 DNS 绕路。规则写错是连上了但某个站打不开的头号原因。
连上却不通:排查清单
客户端显示已连接,不等于流量真的进了隧道。按下面顺序过一遍,多数问题两分钟内能定位。
- ❌ 系统扩展开关没打开,utun 接口没建立,「已连接」只是界面状态。
- ❌ 分流规则把目标域名判成直连,去客户端日志里看规则命中记录。
- ❌ DNS 仍指向路由器或运营商,隧道建立了但解析在外面做,结果就是部分站点打不开。
- ✅ 换一条线路复测,同地区分别试 IEPL 专线与中转,能区分线路问题与本地配置问题。
- ✅ 检查是否同时开着 iCloud 私密代理或其他 VPN 配置,两条隧道会抢同一个默认路由。
- ✅ 重新导入订阅链接,排除本地线路清单过期。
# 1. 当前生效的 DNS 服务器
scutil --dns | grep 'nameserver\[[0-9]\]'
# 2. 默认路由是否落在隧道接口
route -n get default | grep interface第一条命令列出系统正在使用的 DNS。如果第一个 nameserver 是路由器地址或运营商地址,说明解析没进隧道。第二条命令输出里的 interface 若以 utun 开头,说明默认路由已被接管;仍是 en0,流量就根本没走隧道。
排查时不要反复重装客户端。授权、路由、DNS 三段里,重装只会重置第一段,后两段的问题会原样复现。
结论:一份可执行的选型顺序
在 M 系列 Mac 上,选型顺序可以固定成三步:先看是不是原生 arm64 的系统扩展客户端,再看协议与线路是否覆盖你要访问的地区,最后看分流规则能不能按域名精细控制。三条都满足,剩下的才是线路质量;缺一条,再便宜的方案也会在晚高峰还回来。
VPNEH 的 macOS 客户端走系统扩展加网络扩展这条路,协议覆盖 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 与 TUIC,线路分 IEPL 专线、中转、直连三类,共 90+ 国家 / 190+ 线路。注册只用用户名和密码,不需要邮箱地址;同一账号不限台数,Mac 与手机可以同时在线。首次付费后 14 天内可申请无理由全额退款,试用成本可控。