进阶设置 预计阅读 12 分钟

macOS 开启 TUN 增强模式：接管终端与全局流量的原理和步骤

解释系统代理与 TUN 虚拟网卡的区别，以及为什么终端、游戏不走系统代理，并给出在 Mac 客户端授权、开启和验证 TUN 的完整流程。

系统代理与 TUN：接管发生在不同位置

在 Mac 上开启系统代理后，浏览器可以正常连接，终端命令却仍然超时，通常不是同一个开关失效了，而是两个程序采用了不同的网络路径。系统代理提供 HTTP、HTTPS 或 SOCKS 代理地址，应用需要主动读取并使用这些设置。TUN 则通过虚拟网络接口和路由，把匹配范围内的 IP 流量送入代理内核。

比较项系统代理TUN 增强模式
接管条件应用读取系统代理或单独配置代理连接匹配虚拟网卡相关路由
常见用途浏览器及遵循系统设置的应用终端工具、部分游戏及其他直连程序
权限需求可能需要授权修改网络代理设置通常需要特权辅助服务创建接口与路由
UDP 流量普通 HTTP 系统代理不能通用接管还需内核、出站协议与节点共同支持
出站选择由内核运行模式与规则决定同样由内核运行模式与规则决定

“全局流量”也不是绝对覆盖承诺。局域网排除、显式绑定接口的程序、其他 VPN 的路由和系统自身流量，都可能改变实际覆盖范围。验证时应检查目标应用的具体连接，而不是仅凭菜单栏开关判断。

开启前：确认内核、节点与现有网络

确认客户端实际运行的内核

Clash 是配置与客户端生态中的常见名称，不代表所有应用使用相同内核。Clash Meta 后续以 mihomo 名称持续开发；是否支持某个 TUN 字段，应以正在运行的内核版本及其文档为准。先在客户端的“关于”、内核管理页或启动日志中记录客户端版本、内核名称和版本号。图形界面与内核版本是两项信息，不能互相替代。

先建立可用的基线

  1. 更新订阅，选择一个可用节点。在只开系统代理的状态下，确认浏览器能访问需要测试的网站。
  2. 确认当前使用“规则”模式，并查看目标域名会命中哪个策略组。节点延迟测试通过，不等于 HTTPS 和 UDP 都可用。
  3. 暂时断开其他个人 VPN、网络加速器和另一个代理客户端。受单位管理的 VPN 不要擅自卸载，应先确认组织的网络要求。
  4. 记下当前系统代理状态和本地监听端口，并保留现有配置备份，便于出现故障后恢复。

端口值需要读取客户端设置。例如，只有本地混合端口确实为 7890 时，127.0.0.1:7890 才是有效的代理入口；它不是所有客户端的固定值。TUN 本身也不是把系统代理端口改成另一个数字。

授权与开启：先安装服务，再接管流量

不同客户端的菜单名称并不统一。以 Clash Verge Rev 的常见界面为例，先打开「设置」→「Clash 设置」，检查“服务模式”的安装与运行状态，再开启“TUN 模式”。如果当前版本调整了入口，应按界面中的“服务模式”和“TUN 模式”设置项定位，不要把其他客户端的菜单路径直接套用。

  1. 安装特权辅助服务。点击服务模式对应的安装按钮；macOS 请求授权时，确认发起请求的是刚刚打开的客户端，再按系统提示完成管理员认证。不要在终端中以管理员身份运行整个图形应用。
  2. 确认服务已运行。安装成功后，界面应能显示服务就绪。若仍显示未安装或无法连接，先处理服务错误，不要反复切换 TUN。
  3. 开启 TUN 模式。等待内核重新载入配置，检查日志中是否出现创建虚拟接口、添加路由失败等信息。不同版本的成功提示可能不同。
  4. 保留规则模式进行首次测试。先验证已有规则，不要同时更换节点、切换全局模式和修改 DNS，否则难以判断是哪项变动影响结果。
  5. 单独验证 TUN。服务稳定后，可以临时关闭系统代理再测试。这样更容易确认连接不是继续经由浏览器读取的 HTTP 代理进入内核。

Apple 芯片 Mac 应优先选择适配 Apple 芯片的客户端，Intel Mac 选择对应架构。架构主要影响应用与辅助程序能否正常运行；两种架构下，TUN、路由和规则分流的基本关系相同。

配置字段：路由、协议栈与 DNS 接管

如果图形客户端已经提供 TUN 开关，优先使用界面管理。部分客户端会把界面选项合并到运行配置，直接修改订阅原文件可能被更新覆盖。需要自定义时，应使用客户端提供的覆写或配置合并功能，并检查最终运行配置是否生效。

下面是 mihomo 的局部配置示例，只展示 TUN 相关字段，不是可以独立运行的完整订阅。它假设已有可用的代理、规则和已启用的内置 DNS 配置：

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
  • enable：启用 TUN 功能。图形开关关闭时，客户端可能重新生成此值。
  • stack: mixed：选择混合协议栈。其他可用取值及行为应以当前内核支持为准；不要因为网络慢就反复随机更换。
  • auto-route：由内核自动配置相关路由。自定义路由、其他 VPN 或管理策略仍可能影响最终路径。
  • auto-detect-interface：尝试识别出站接口。从 Wi-Fi 切到以太网后若连接异常，可重启内核并检查识别结果。
  • dns-hijack：把匹配的传统 DNS 请求交给内置 DNS 处理。示例中的 any:53 不是“接管所有加密 DNS”的含义。

域名规则为什么与 DNS 有关

不少分流规则依赖域名，而 TUN 接收到的基础信息是 IP 数据包。内核需要通过 DNS 映射、连接元数据或配置的嗅探能力识别域名。采用 fake-ip 时，内置 DNS 返回映射地址，随后由内核关联真实目标；采用其他 DNS 模式时，域名关联路径可能不同。

浏览器的安全 DNS 通常使用 HTTPS，流量走的是 443 端口，不会因为劫持 53 端口就自动变成内核可见的明文 DNS。若规则匹配异常，应对照浏览器 DNS 设置、内核 DNS 日志和实际命中规则排查。不要只修改一个字段，就假定域名识别已经完整。

验证 TUN：接口、终端连接与规则三项交叉检查

第一步：观察网络状态，不把接口名称当结论

打开「终端」，执行以下只读命令。第一条显示系统代理设置，第二条列出网络接口，第三条查询到指定地址的路由：

scutil --proxy
ifconfig
route -n get 1.1.1.1

macOS 常见的虚拟接口名是 utun 加数字，但系统服务和其他 VPN 也会创建此类接口。因此，看到 utun3 并不能证明它属于当前客户端。应结合开启前后的变化、客户端日志和路由结果判断。单个目标的路由查询也不能代表所有目的地址。

第二步：让终端明确不使用应用层代理

使用系统自带的 curl 测试，并用 --noproxy '*' 绕过 curl 的应用层代理。这个参数不会绕过 TUN，因此适合区分两条接管路径：

/usr/bin/curl --noproxy '*' --connect-timeout 10 --max-time 20 -I https://example.com

示例分别设置了 10 秒连接超时和 20 秒总超时。返回 HTTP 响应只能证明该目标连通，不能单独证明使用了代理节点；这个网站在部分网络中本来就能直连。运行命令时，应同时打开客户端的连接列表，查找 example.com 对应连接，确认匹配规则、策略组和最终出站。

第三步：对照关闭后的行为

  1. 保持节点、规则和测试网址不变，记录开启 TUN 时的连接日志。
  2. 关闭 TUN，并保持系统代理关闭，再运行同一条命令。
  3. 比较客户端是否仍能看到该连接、命中规则是否一致，以及请求结果有何变化。
  4. 恢复需要的开关状态。如果结果没有变化，检查目标是否本来直连、是否仍有其他 VPN，或测试程序是否复用了旧连接。

测试游戏时，还需要观察游戏实际建立的 UDP 会话。网页能打开、TCP 测试成功，都不能证明节点支持游戏所需的 UDP。游戏登录、资源下载和对局也可能使用不同域名与端口，应分别查看，而不是只测启动器。

常见故障：按权限、路由、DNS、出站顺序排查

TUN 开关立即关闭，或提示创建接口失败

先看辅助服务是否运行、内核是否成功启动，再检查运行配置是否存在 YAML 缩进错误或当前内核不支持的字段。安装包更新后，客户端与旧辅助服务可能需要重新配套；应通过客户端提供的服务管理入口修复，避免手动删除不明系统文件。

开启后所有网站都无法连接

先关闭 TUN，确认基础网络能够恢复。随后检查节点连通性、DNS 上游是否可达，以及日志中的出站接口。若同时运行 VPN，先在获准的情况下暂停其中一个再复测。路由互相覆盖可能导致连接进入错误隧道，也可能让 DNS 请求无法到达上游。

能连接 IP，域名却解析失败

重点检查内置 DNS 是否启用、上游解析器是否可达、DNS 请求是否被正确接管。不要直接用“访问 HTTPS 的 IP 地址”替代域名测试，因为证书与虚拟主机通常依赖域名。macOS 的 scutil --dns 可查看解析器状态，但最终仍应结合具体应用的解析路径判断。

终端已经接管，某个应用仍然直连

先区分“进入内核后命中 DIRECT”和“根本没有进入内核”。前者需要检查规则顺序、策略组选择和局域网排除；后者再检查应用是否绑定特定接口、其他网络扩展是否接管，以及连接是否在启用 TUN 之前就已建立。退出并重新打开目标应用，比只刷新窗口更适合验证新连接。

休眠唤醒或切换 Wi-Fi 后失效

先断开正在重试的应用连接，再重启内核，让接口识别与路由重新建立。若频繁复现，记录切换前后的网络类型、内核版本及相关日志后再报告问题。分享日志时，删除订阅地址、节点凭据和其他个人网络信息。

关闭与恢复：保留可重复的操作顺序

不再需要 TUN 时，先在客户端关闭 TUN，再确认普通网络恢复，最后退出应用。若此前开启了系统代理，也要按实际需要关闭；系统代理仍指向已经退出的本地进程时，遵循该设置的应用可能无法联网。

  • Wi-Fi 代理检查路径：「系统设置」→「网络」→「Wi-Fi」→「详细信息」→「代理」。有线连接应选择对应网络服务。
  • VPN 检查路径：「系统设置」→「VPN」。客户端创建的底层 TUN 不一定在这里以独立 VPN 条目出现，因此没有条目不代表没有虚拟接口。
  • 如果异常退出后网络未恢复，优先重新打开原客户端，再正常关闭 TUN 和系统代理；必要时重启 Mac，不要直接清空整套路由表。
Clash Mac版安装包