先区分流量入口与出站模式

系统代理与 TUN 模式解决的是“流量怎样进入客户端”；规则、全局、直连解决的是“进入客户端后怎样转发”。两组设置处于不同层次。开启 TUN 不等于所有连接都经过远端节点，选择全局模式也不等于所有应用都会自动进入客户端。

一次连接可以按下面的顺序理解。代理组选择、订阅中的节点是否可用，都发生在流量入口之后。若连接根本没有进入内核，反复切换节点通常不会改变结果。

应用发起连接
  → 系统代理端口，或 TUN 虚拟网卡
  → Clash / mihomo 内核
  → 出站模式与规则判断
  → DIRECT、代理节点或 REJECT

系统代理：应用主动连接本机端口

系统代理本质上是一组供应用读取的网络设置。例如客户端在本机监听混合端口 127.0.0.1:7890，再把这个地址写入系统代理。支持该设置的应用会先连接本机端口，由内核继续访问目标。这里的 7890 只是示例，实际端口以客户端设置为准。

HTTP、HTTPS 与 SOCKS 的入口差别

  • HTTP 代理：应用把 HTTP 请求交给代理服务器处理。
  • HTTPS 经 HTTP 代理：通常先发送 CONNECT 请求建立隧道，再在隧道内完成 TLS 握手；这不代表客户端会解密 HTTPS 内容。
  • SOCKS5：应用通过 SOCKS 协商目标地址。是否把域名交给代理解析，取决于应用和连接方式。
  • 混合端口：同一个监听端口接受 HTTP 与 SOCKS 代理连接，但不表示系统会强制所有程序使用它。

macOS 在哪里检查

在 macOS 13 及后续版本中，可进入「系统设置」→「网络」→ 当前网络服务，例如「Wi-Fi」→「详细信息」→「代理」，检查网页代理、安全网页代理及 SOCKS 代理的服务器和端口。系统版本不同，入口文字可能略有差别。切换 Wi-Fi、以太网或其他网络服务后，也应检查当前服务，而不是只查看上一次使用的服务。

浏览器、终端和桌面应用不一定采用同一套代理设置。部分应用读取系统设置，部分使用自己的代理选项；命令行工具还可能读取 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 与 NO_PROXY 环境变量。因此，“浏览器能访问，终端不能”首先是入口差异线索，不足以证明节点故障。

TUN 模式：通过虚拟网卡与路由接收 IP 流量

TUN 提供虚拟的三层网络接口。应用仍按普通方式建立连接，操作系统依据路由把符合条件的 IP 数据包送入虚拟网卡，内核再处理这些数据。应用不必主动理解 HTTP 或 SOCKS 代理，因此它常用于不读取系统代理设置的程序。

在 macOS 上，虚拟接口通常表现为 utun 系列设备。不过系统 VPN 和其他网络服务也会创建同类接口，不能仅凭出现一个 utun 就判断客户端接管成功。还要结合客户端日志、路由和连接记录确认。

启用条件与能力边界

  • 权限：创建接口、配置路由等操作通常需要管理员授权或客户端的服务组件。授权成功不代表后续路由一定正确。
  • 内核：是否提供 TUN、支持哪些网络栈和字段，应以实际内核为准。客户端外壳叫 Clash，并不意味着一定使用 mihomo。
  • UDP：TUN 可让符合条件的 UDP 流量进入内核，但远端节点及协议还必须支持 UDP 转发。开启开关无法补齐节点能力。
  • 覆盖范围：IPv6、局域网、排除路由及其他 VPN 都可能影响接管范围。TUN 也不是对所有二层广播流量的完整接管。

mihomo 的 auto-route 用于自动配置相关路由，auto-detect-interface 用于自动识别出站接口。它们有助于常见网络环境下的设置，但不能保证与公司 VPN、虚拟机网络或多网卡策略完全兼容。

系统代理与 TUN 的实际差异

检查项系统代理TUN 模式
流量进入方式应用主动连接本机代理端口路由将 IP 数据包送入虚拟网卡
应用适配要求应用需读取系统设置或手动配置代理通常无需应用提供代理选项
UDP 使用条件取决于应用与代理协议，普通 HTTP 代理不能概括覆盖取决于路由、内核及节点的 UDP 能力
权限与影响范围主要修改网络服务的代理设置涉及虚拟接口、路由及可能的 DNS 接管
常见排查入口端口监听、应用代理设置、绕过列表授权状态、路由、DNS、IPv6 和 VPN 冲突

两者没有固定的速度排名。同一个请求如果最终使用同一节点，体验通常更受节点负载、链路质量和目标服务影响。TUN 多了一层流量处理，但不能由此推断它必然更慢；系统代理路径更直接，也不能保证应用一定按预期使用它。

DNS：解析位置决定域名规则能拿到什么信息

系统代理场景下，应用可能把域名交给代理，也可能先在本地解析。以 curl 为例，socks5:// 通常由本地解析目标域名，socks5h:// 则把目标域名交给 SOCKS 代理。即使端口相同，解析路径也可能不同。

TUN 接收到的主要是 IP 数据包。如果应用已经把域名解析为真实 IP，内核不一定天然知道原始域名。DNS 接管、Fake-IP 映射与流量嗅探可为域名规则提供信息，但三者作用不同。

  • DNS 接管：将匹配的 DNS 请求交给内核 DNS 模块。常见的端口 53 接管并不能直接解密应用自带的 DoH 或 DoT。
  • Fake-IP：由内核返回映射地址，并保留域名与地址的对应关系。常见地址段是 198.18.0.0/16；这类地址不是远端节点地址。
  • 嗅探：尝试从可见的协议特征恢复目标域名，例如部分 TLS ClientHello 中的 SNI。它不是 HTTPS 解密，遇到加密客户端问候等情况也有边界。

mihomo 配置片段的检查方式

下面只展示相关字段，不是完整配置。使用前需确认客户端确实运行支持这些字段的 mihomo，并保留原配置中的 DNS 上游、代理节点和规则。若客户端通过图形设置生成配置，应优先使用其设置入口，避免手工改动在刷新订阅时被覆盖。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

按入口逐项排查，不要同时改多个开关

第一步：单独验证本机代理端口

先关闭 TUN，保留内核运行，用明确指定代理的命令测试。下面假设混合端口是 7890；若客户端显示其他数值，需要同步修改。命令设置了 15 秒超时，输出连接阶段信息，便于区分端口拒绝、TLS 错误和目标超时。

curl -I -v --max-time 15 \
  --proxy http://127.0.0.1:7890 \
  https://example.com/

curl -I -v --max-time 15 \
  --proxy socks5h://127.0.0.1:7890 \
  https://example.com/

若出现连接 127.0.0.1:7890 被拒绝，应先检查内核是否运行、端口是否一致及是否被其他程序占用。若代理握手成功后目标超时，再查看节点和出站规则。单个测试地址成功，只能说明这条请求路径可用，不能代表所有站点都正常。

第二步：检查系统代理是否被应用采用

打开系统代理，在 macOS 终端运行 scutil --proxy 查看当前代理字典，再检查具体应用的独立设置与绕过列表。终端环境可用 env | grep -i proxy 检查已有代理变量。系统代理写入正确与应用实际采用，是两件需要分别验证的事。

第三步：单独验证 TUN

关闭系统代理后启用 TUN，重新建立目标应用的连接。可使用下面的命令去掉 curl 显式代理的影响，再到客户端连接页检查记录。这个命令只排除 curl 的代理使用，不会绕过 TUN 路由。

curl -I -v --max-time 15 --noproxy '*' https://example.com/

若没有对应连接记录，重点检查 TUN 启动日志、路由排除、IPv6 路径和其他 VPN；若已有记录，重点检查命中规则与最终出站。切换设置前已经建立的长连接可能继续沿用旧路径，必要时退出目标应用后重新打开。

场景选择：先用系统代理，按需增加 TUN

  • 主要使用浏览器：系统代理通常更容易确认影响范围。先验证浏览器确实遵循系统设置。
  • 终端开发工具：可以优先显式设置代理参数或环境变量；如需统一处理多个不支持代理的程序，再考虑 TUN。
  • 游戏或其他 UDP 应用：先确认节点支持 UDP，再检查 TUN 路由及应用连接记录。只打开系统 HTTP 代理通常不足以覆盖这类流量。
  • 公司 VPN 与内网访问：逐项验证内网域名、私有网段和 DNS。必要时调整排除路由与直连规则，不要直接覆盖公司要求的网络配置。

系统代理与 TUN 可以同时开启，但排障时建议先分别验证。应用显式连接本机代理端口时，仍可能走显式代理入口；其他连接再由 TUN 接收。不能把两个开关理解为必然经过两次远端代理，也不应假设内核在所有配置下都会自动处理所有路由冲突。

关闭后仍无法联网时怎样恢复

  1. 先在客户端中关闭 TUN 与系统代理，再正常退出客户端，让它有机会撤销自己设置的路由和代理。
  2. 检查当前网络服务的代理页面，清理指向已经停止监听的本机端口的设置；受组织管理的配置应联系管理员处理。
  3. 检查终端代理环境变量、应用独立代理与其他 VPN 是否仍在生效，然后重新建立网络连接。
  4. 若局域网和域名解析仍异常，记录路由与 DNS 状态，再按具体客户端的恢复步骤处理，不要盲目删除全部网络服务。

最终判断标准是可核对的连接路径：应用是否进入内核、域名如何解析、规则命中什么出站。把这三项分开检查，通常比反复切换系统代理和 TUN 开关更容易定位问题。