进阶配置 预计阅读 10 分钟

TUN 虚拟网卡与系统代理对比：两种流量接管机制的覆盖范围与取舍

系统代理依赖应用主动遵守设置，TUN 在网络层接管全部流量。本文对比两者的覆盖范围、权限要求与兼容性，并给出选择建议。

一、先区分流量接管与代理分流

系统代理和 TUN 解决的是同一个前置问题：应用产生的连接怎样进入 Clash 内核。连接进入内核后，才由规则、策略组和节点决定直连、代理或拒绝。因此，开启 TUN 不等于开启全局代理，系统代理也不等于只能使用规则模式。

本文中的 TUN 配置以 Clash Meta（mihomo）内核为例。不同客户端提供的开关、服务安装方式与默认端口并不统一；旧版 Clash 客户端也未必支持下文所有字段。操作前先在客户端的内核信息中确认实际运行的是 mihomo，而不是只看应用名称里有没有 Clash。

两条常见连接路径

  • 系统代理：浏览器读取系统代理设置，将连接发到本机 HTTP 代理端口，再由内核执行分流。
  • TUN：应用按正常方式发起 IP 连接，操作系统路由把符合条件的数据包送入虚拟网卡，再由内核处理。
  • 应用内代理：在 Git、命令行或聊天工具里单独填写 SOCKS5 或 HTTP 地址。这是第三种入口，不必依赖系统代理开关。

二、覆盖范围对比：浏览器、命令行与 UDP

系统代理本质上是一组供应用读取的设置，不是网络层拦截器。Windows 的不同网络 API、应用自带的网络库，以及 macOS 应用对代理配置的支持都可能不同。浏览器可用，只能证明这条浏览器连接可用，不能代表同一设备上的全部应用都已接入。

两种入口的常见适用范围
对象 系统代理 TUN 模式
遵守系统设置的浏览器 通常可以接入，适合网页访问 通常可以接入，仍受路由与规则影响
curl、Git 与构建工具 未必读取，常需环境变量或应用配置 通常不必逐个设置代理地址
游戏、语音与 QUIC HTTP 系统代理通常不覆盖其 UDP 连接 可接管受支持的 UDP，节点与链路也需支持
局域网打印机、NAS 取决于代理绕过列表和应用行为 需核对本地路由、直连规则和地址排除
其他设备的流量 仅设置本机不会自动覆盖其他设备 仅开启本机 TUN 也不会自动成为局域网网关

UDP 支持要看完整链路

HTTP 代理端口不是通用 UDP 隧道。SOCKS5 协议虽然定义了 UDP 转发，但应用是否实现、客户端是否接收、出口节点是否支持，是不同条件。TUN 可以把更多 UDP 流量送到内核，却不能把不支持 UDP 的节点变成支持 UDP 的节点。

例如 HTTP/3 常使用 UDP 443；某个网页通过 TCP 可以打开，不代表 QUIC 路径也正常。游戏能登录但语音不可用时，应分别查看登录连接和语音连接的目标地址、协议与策略，不能只看一个延迟测试数字。

三、权限与配置：端口入口和虚拟网卡

系统代理：先确认本地监听地址

下面用 127.0.0.1:7890 作为明确的示例入口，不表示所有客户端都默认使用该端口。mihomo 的 mixed-port 可以在同一个端口接受 HTTP 与 SOCKS 请求。实际值应以客户端显示的混合端口或当前生效配置为准。

# mihomo 配置片段：本机混合代理入口
mixed-port: 7890
allow-lan: false
mode: rule

Windows 11 可在「设置」→「网络和 Internet」→「代理」→「手动设置代理」核对地址和端口；客户端也可能通过自动配置脚本设置系统代理，不能只看手动代理一栏。macOS 可在「系统设置」→「网络」→当前网络服务→「详细信息」→「代理」检查。这里显示的入口必须与客户端监听端口一致。

本机使用时优先保持回环地址，不要为解决浏览器打不开而直接把监听地址改为所有网卡。向局域网开放代理是另一项配置任务，还需要访问控制与防火墙配合。

TUN：路由配置与后台服务权限

TUN 需要创建虚拟网络接口并调整路由，桌面客户端通常借助管理员权限或特权服务完成。Windows 客户端可能要求先安装服务模式；macOS 客户端可能使用特权辅助程序或网络扩展，授权方式取决于实现。并非所有 macOS Clash 客户端都会请求相同的网络扩展权限。

# mihomo TUN 配置片段，不是完整订阅
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53
  • stack: mixed 在当前 mihomo 实现中使用系统 TCP 栈与 gVisor UDP 栈组合；可用值和兼容性需要对应所用内核版本核对。
  • auto-route: true 自动设置相应路由。创建网卡成功，不代表路由一定安装成功。
  • auto-detect-interface: true 用于自动识别出口接口。Wi-Fi、有线网络和其他 VPN 并存时，仍需检查实际出口。
  • dns-hijack 是 tun 下的字段，示例分别匹配 UDP 与 TCP 的 53 端口请求，并将其交给内置 DNS 模块处理。

四、DNS 与 IPv6：TUN 已开启仍有遗漏的原因

流量接管与域名解析必须一起检查。应用先查询域名，再建立连接；如果 DNS 请求走了另一条路径，可能出现域名解析失败、规则缺少域名信息或连接目标与预期不一致。只看到虚拟网卡名称，不能证明 DNS 链路已经正确。

53 端口劫持不包含全部 DNS

上面的 dns-hijack 示例针对传统 DNS。浏览器的 DNS over HTTPS 使用 HTTPS 连接，DNS over TLS 通常使用 TCP 853；它们不会因为配置了 53 端口劫持就自动变成内核 DNS 查询。排查时可暂时关闭浏览器的安全 DNS，进行一次同条件对照，再决定长期策略。

这段 TUN 示例还需要与已启用的 mihomo DNS 模块配合，例如 dns.enable: true，并保留可用的解析上游。fake-ip 与 redir-host 是解析处理模式，不是 TUN 的替代品；使用 Fake-IP 时仍需根据实际应用兼容性设置过滤列表。

IPv6 需要单独验证

如果网络同时提供 IPv4 与 IPv6，而当前客户端只正确接管了其中一类，应用可能优先使用另一类地址。排查时分别测试两种地址族，核对内核 IPv6 设置、DNS 的 AAAA 返回行为和系统路由。不要仅凭一次 IPv4 测试就判断全部连接都经过 TUN。

五、验证方法：一次只改变一个入口

建议按“显式代理→系统代理→TUN”的顺序检查。测试时固定同一策略组和同一个节点，关闭其他代理或 VPN；切换入口后重新建立连接，避免浏览器连接复用干扰结果。以下命令使用公共示例站点，只用于展示方法，响应耗时不是本文给出的实测成绩。

  1. 确认端口能用。关闭 TUN，用命令显式指定本地代理。如果这一步失败，先处理内核、端口或节点，不急着调整虚拟网卡。
  2. 确认系统代理。启用系统代理，用遵守系统设置的浏览器访问同一目标，并在客户端连接列表中核对目标域名、匹配规则与策略链。
  3. 确认 TUN。关闭系统代理，只保留 TUN。让命令行不使用应用级代理访问目标，核对连接记录，必要时同时检查系统路由。
  4. 确认真实业务。再测试游戏、语音、局域网访问等目标。网页成功不能替代 UDP 或本地资源验证。
# Windows PowerShell：使用 curl.exe，避免旧版 PowerShell 的 curl 别名
curl.exe -I --connect-timeout 10 --proxy http://127.0.0.1:7890 https://example.com/

# TUN 对照测试：不使用 curl 的代理配置
curl.exe -I --connect-timeout 10 --noproxy "*" https://example.com/

# 分别测试 IPv4 与 IPv6
curl.exe -4 -I --connect-timeout 10 --noproxy "*" https://example.com/
curl.exe -6 -I --connect-timeout 10 --noproxy "*" https://example.com/

macOS 与 Linux 可将命令中的 curl.exe 换为 curl。--noproxy "*" 只让 curl 不使用应用级代理，不会绕过 TUN。收到 HTTP 响应也只证明该请求收到响应；是否经过代理节点，必须结合内核连接记录或出口验证确认。

Windows 可用 route print 查看路由；macOS 可用 route -n get 1.1.1.1 检查指定 IPv4 目标的路由；Linux 可用 ip route get 1.1.1.1 查看选路。不同系统可能使用接口路由或策略路由，不能把“必须出现某条默认路由”当成统一判据。

六、兼容性与取舍：按最小接管范围选择

优先使用系统代理的情况

  • 主要使用浏览器，其他应用希望保持原有网络路径。
  • 工作设备已连接企业 VPN，不适合再自动调整全机路由。
  • 只需让少数开发工具使用代理，可以在工具里配置 HTTP 或 SOCKS5 入口。

考虑使用 TUN 的情况

  • 目标应用不读取系统代理，也没有独立代理设置。
  • 需要覆盖受支持的 UDP 业务，并且已确认节点具备相应能力。
  • 希望多个应用统一进入内核，再按域名、IP 或进程等规则分流。

TUN 与其他 VPN 并存时，容易遇到默认路由、DNS、网段重叠和回程路径冲突。比如企业网络也使用私有地址，简单添加“全部私网直连”可能绕开企业 VPN 的必要路由。应先记录企业网络的目标网段，再依据客户端支持的路由排除与规则能力配置，不要把一个通用私网规则当作完整方案。

两种入口可以同时启用，但不建议在故障排查阶段这样做。应用显式连接本地代理时可能直接走回环入口，其他应用才走 TUN；这会让“关闭一个开关后仍然能访问”的结果难以解释。保持一个主要入口，更容易判断权限、DNS、端口还是规则出了问题。

后续配置可从系统教程核对平台差异，或按使用文档完成订阅导入与规则模式设置。最终判断标准应是目标应用的真实连接记录，而不是客户端界面上的单个“已开启”状态。

下载Clash选择设备平台