为什么 macOS 上开 TUN 会涉及「系统扩展」

与仅在应用内开启「HTTP/SOCKS 系统代理」不同，TUN 模式要在内核路径上插入虚拟网卡并接管路由，使未单独配置代理的程序也能按 Clash 规则分流。苹果把这类能力纳入 Network Extension 体系管理：实现上往往表现为需要用户批准的系统扩展（System Extension）或配套的内核扩展策略，而不是普通 App 权限点一下就能永久生效。你在日志或界面里看到的「扩展加载失败」「packet tunnel 未启动」，很多时候并不是订阅坏了，而是系统扩展尚未被允许运行，或批准后又因更新、签名变化需要重新确认。

因此，在 Clash macOS 客户端里打开 TUN 之前，建议先在脑中区分两件事：一是规则与节点是否正常（可暂时用系统代理模式验证）；二是本机策略是否允许网络扩展组件启动。第一层问题可参考站内 Clash TUN 模式深度解析 与 规则分流最佳实践；本文则专注第二层——权限与系统代理冲突这一 macOS 特有组合。

ℹ 界面差异：不同发行版、图形壳（GUI）对 TUN 的开关命名可能写作「增强模式」「虚拟网卡」「TUN 设备」等，但底层都需要用户态与扩展组件协同。若你刚换客户端，可先读 如何选择适合自己的 Clash 客户端，再对照自己所用版本的文档打开对应权限页。

系统扩展被阻止：在隐私与安全性中放行

当 macOS 拦截未签名的系统软件或首次加载网络扩展时，屏幕一角常出现「系统扩展被阻止」类提示。处理顺序建议固定为：打开 系统设置 → 隐私与安全性，向下滚动到与系统扩展、开发者或允许相关的条目，在列表中找到与你的 Clash 客户端或其所依赖的网络扩展包对应的项，点击允许或启用。部分版本会要求你随后重启 Mac 才能完成装载；若跳过重启，TUN 接口可能一直处于「半初始化」状态，表现为 ping 不通、DNS 间歇异常。

若你使用 MDM 或公司设备，策略可能禁止用户自行批准系统扩展：此时本地界面不会出现「允许」按钮，需要管理员下发描述文件或调整策略，这与个人电脑上的操作路径不同，属于组织策略边界而非 Clash 配置问题。家用场景下，仍看不到批准项时，可核对是否用了测试版系统、是否从非预期路径安装了客户端（例如权限隔离导致扩展 bundle 不一致）。

与「登录项」和后台运行的关系

某些客户端会把网络扩展辅助进程注册为登录项或后台服务，以便在用户登录前或切换用户后仍能拉起隧道。若你在「隐私与安全性」里已点过允许，但重启后扩展仍未加载，可打开系统设置 → 通用 → 登录项（或旧版「用户与群组」中的登录项），确认与代理相关的 helper 未被你手动禁用。再观察客户端日志是否仍报 NEProvider、permission denied 等字样，以区分是策略拒绝还是进程未启动。

仍无法加载：重启、登录项与网络权限

批准系统扩展后若 TUN 仍不可用，可按下面顺序收窄问题，避免同时改多个变量。第一，完全退出 Clash 客户端与其菜单栏助手（不仅是关窗口），再重新打开并只开启 TUN 一项，观察是否出现新的系统弹窗。第二，执行一次重启：macOS 对系统扩展的装载顺序与缓存，有时需要完整重启后才能与路由表、DNS 设置对齐。第三，检查是否同时运行了其它 VPN 或过滤类扩展（企业安全软件、家长控制、第三方防火墙）：它们也可能注册网络扩展，与 Clash 争用优先级或互斥，表现为「一开 TUN，另一个断」或「两者都显示已连接但流量异常」。

第四，在客户端内查看是否有单独的网络权限、辅助功能（个别壳会用 AppleScript 或自动化控制其它应用）或本地网络相关提示，按系统对话框逐项允许。第五，若你近期升级过 macOS 大版本，留意客户端是否已发布适配该版本的构建；未适配时可能出现扩展加载成功但路由写入失败，需要结合发行说明判断。

⚠ 安全提示：不建议为了「省事」长期关闭 SIP 或全局降低 Gatekeeper 策略来绕过扩展签名。优先使用官方渠道获取的客户端与更新，并在系统设置中完成正规批准流程。

TUN 与系统代理：避免两套出口叠在一起

很多用户习惯在客户端里同时勾选「设置为系统代理」并开启「TUN」。在部分环境下这可以工作，但也容易出现重复转发：应用先把流量交给系统代理端口，再由内核 TUN 再截一次，日志里出现环路、延迟放大或策略命中混乱。更稳妥的做法通常是二选一为主：以 TUN 为主时，关闭客户端写入系统代理，或到 系统设置 → 网络 → 高级 → 代理 中确认 HTTP/HTTPS/SOCKS 未被重复指向同一本地端口；以系统代理为主时，先不要开 TUN，验证浏览器与尊重系统代理的应用是否已按规则分流。

另一个常见混淆点是 Wi‑Fi 详情里的代理与客户端一键设置是否同源：有的场景下，你在 A 客户端里关闭代理，但系统网络里仍残留 B 工具写入的代理项，表现为「我明明关了 TUN，网页还走本地端口」。排障时以系统网络面板实际显示为准，而不是只看客户端开关状态。若你需要核对连接失败属于节点还是本地双代理，可结合 从日志读懂 timeout 与 TLS 的分层思路。

简言之：TUN 模式解决的是「全局接管与透明转发」；系统代理解决的是「显式声明使用代理的应用」。二者目标重叠时，务必明确谁写路由、谁写代理表，只保留一条主路径，再在 Clash 规则里做分流。这与 Linux 上调整 iptables、策略路由的思路类似，只是 macOS 把部分能力包进了 Network Extension 与用户批准流程里。

部分 App 仍不走代理：常见原因与对策

即便 TUN 已成功创建虚拟网卡，你仍可能发现：浏览器正常，但终端工具、某款 IM、游戏启动器或 IDE 自带更新器仍然直连或超时。常见原因包括：应用自带代理设置覆盖了系统行为；使用自己的证书钉扎或 QUIC/HTTP3 走独立通道；沙箱限制导致无法被透明转发；以及分流规则把该目标域名或 IP 判成了 DIRECT。应先在该应用的设置里搜「proxy」「网络」，关闭其内置直连或错误代理；再在 Clash 日志中确认连接是「未经过内核」还是「已入站但被规则直连」。

对于仅支持 SOCKS/HTTP 代理、完全不支持透明转发的老程序，有时反而需要显式指向本地代理端口，而不是指望 TUN 万能。此时更合理的组合是：全局仍用 TUN 照顾大多数流量，对个别应用单独配置 127.0.0.1 上的本地端口，并在规则里保证其目标走预期策略组。若你遇到的是开发工具类场景，也可对照 开发者场景下的代理与分流 中的「系统代理与 TUN 配合」段落，避免把 IDE 与系统设置改得互相打架。

最后，别忘了核对 DNS：TUN 常与 fake-ip、DNS 劫持等选项联动，若仅部分域名异常，可能是 DNS 模式与规则不一致，而不是扩展未加载。此类问题在 常见问题 与 DNS 相关条目中常有说明，可与本文并行查阅。

和 Linux 上排障有何不同

本站已有 Ubuntu 上 Clash TUN 与 systemd 一文，侧重 /dev/net/tun、权能与 systemd 单元。macOS 上没有同一套设备节点语义，取而代之的是用户可见的批准流程与 Network Extension 生命周期：你更多是在「系统设置」里解决问题，而不是给二进制 setcap。两套平台的共同点在于：路由只能有一套主控，DNS 与规则必须一致；差异在于：macOS 把安全与隐私拦截放在最前，不先过这一关，后面改 YAML 往往是无效劳动。

排查清单

按顺序做，可以快速判断问题落在「扩展 / 系统代理 / 应用自身」哪一层。

  1. 在 隐私与安全性 中确认系统扩展已允许，必要时重启后再开 TUN。
  2. 退出其它 VPN 或网络过滤扩展，排除扩展互斥。
  3. 选择单一主路径：TUN 为主则清理系统代理；系统代理为主则先关 TUN 对照。
  4. 在系统网络设置中核对代理项是否与客户端声明一致，无残留第三方写入。
  5. 看客户端日志：扩展是否加载成功、路由是否写入、规则命中是否符合预期。
  6. 对异常 App 单独检查其内置网络/代理设置与分流规则中的 DIRECT/PROXY 判定。
  7. 仍无法归因时，结合 DNS 模式与 规则顺序 复查，而非先换节点。

结语

在 macOS 上用好 Clash TUN 模式，核心不是「多勾几个选项」，而是把系统扩展批准、网络扩展运行与系统代理写入三件事对齐：任何一环留在半状态，都会表现为「扩展被阻止」「代理和 TUN 重复」或「只有部分应用生效」。先把权限路径走通，再调规则与节点，排障成本会低很多。

相比命令行堆参数，一款能在界面上区分 TUN 与系统代理、清楚展示扩展状态与日志的客户端，日常维护会更轻松；这与 Linux 服务器上追求可脚本化是不同取向，但目标一致：让透明代理稳定、可解释、可回滚。

→ 立即免费下载 Clash，开启流畅上网新体验，在桌面端用更直观的方式管理 TUN、系统代理与规则，减少与系统扩展权限相关的反复试错。