Clash Verge网络链路与代理原理进阶教程

上一篇已经带你看完 Clash Verge 的主要界面和功能。这一篇继续拆开背后的网络链路、代理协议、系统代理、TUN 和分流逻辑。

一、先看懂整条网络链路

这张截图显示的实际网络链路是：

flowchart LR
    A["浏览器或其他遵守系统代理的应用"] --> B["macOS（苹果电脑操作系统）系统代理"]
    B --> C["127.0.0.1:7897"]
    C --> D["Mihomo 代理核心"]
    D --> E{"Rule（规则）判断"}
    E -->|"PROXY"| F["DMIT-VPS 节点"]
    F --> G["目标网站看到美国 DMIT 出口 IP"]
    E -->|"DIRECT（直连）"| H["通过本地网络直连"]

二、先补齐必须知道的网络与协议基础

1. Clash Verge 和 Mihomo 分别做什么

Clash Verge 是我能看见和点击的控制界面。

真正负责接收流量、匹配规则、连接 DMIT（云服务器服务商名称）服务器的是后台的 Mihomo 内核。

可以这样记：

• Clash Verge：汽车的仪表盘和方向盘。
• Mihomo：汽车发动机。

核心理解： Mihomo 是一个纯后台进程，也就是 Clash Verge 这层界面外壳里面的网络内核。它会接管设备上的网络流量，再根据配置文件中的规则判断每一段流量走哪条路。

2. 协议、节点和配置有什么区别

• 协议： 一套技术规范。比如 Shadowsocks（中文常称“影梭”的代理协议，英文缩写为 SS（Shadowsocks 的缩写））规定数据怎么加密、怎么握手、怎么传输，它是一个抽象的方案模板。
• 节点： 一台运行着某种代理协议的具体服务器，例如“香港 01”“日本 01”。节点有 IP（互联网协议地址）、端口、密码或密钥，是实际可以连接和使用的东西。
• 配置： 一整份说明书，里面可以包含节点列表、策略组、分流规则、DNS（域名系统，负责把域名转换成 IP）、本地端口和其他参数。

3. 买了 DMIT VPS 后，我到底建立了什么

先给结论：

你建立的是一台自建代理服务器，更准确地说，是在 DMIT 的 VPS 上部署了一套 VLESS + TCP + REALITY 代理入口，再让 Clash Verge 充当 Mac 上的客户端和分流控制器。

它能产生类似 VPN（Virtual Private Network，虚拟专用网络）的使用效果，但严格来说，当前这套方案不是 WireGuard 或 OpenVPN（两种传统 VPN 协议）那种完整的网络层 VPN。

买到 VPS 时，你还没有节点

DMIT 卖给你的 VPS，只是一台放在海外机房、拥有公网 IP 的远程 Linux（开源服务器操作系统）电脑。

刚买完时，它通常只具备：

• 一套操作系统；
• 一个公网 IP；
• 处理器、内存和磁盘；
• 一组 SSH（Secure Shell，安全远程登录协议）登录凭证；
• 访问互联网的能力。

这时它还不会自动理解 VLESS，也不会自动接收 Clash Verge 的代理请求。它只是一台“海外云电脑”，还不是代理节点。

真正把 VPS 变成代理节点的是服务端程序

历史操作记录显示，当时在 DMIT VPS 上安装了 3X-UI（管理 Xray Core 的网页控制面板），再通过面板创建 VLESS + TCP + REALITY 入站。

这里要把两个软件分开：

• 3X-UI： 管理面板。负责让人用网页创建用户、端口和 REALITY 参数，并生成分享链接。
• Xray Core（Xray 代理核心）： 真正监听网络端口、验证客户端并转发流量的服务端程序。

可以把 3X-UI 理解成服务器的“设置后台”，把 Xray Core 理解成真正工作的“代理发动机”。关闭管理网页不等于 Xray 代理服务一定停止；真正承接流量的是 Xray Core。

在 3X-UI 中点击“添加入站”，本质上是在告诉 Xray：

1. 在 VPS 的某个端口等待连接；
2. 只接受符合 VLESS 格式的请求；
3. 使用 UUID（通用唯一标识符）辨认允许连接的客户端；
4. 使用 REALITY 密钥、shortId（REALITY 的短标识）等参数验证连接；
5. 验证成功后，替客户端连接它真正想访问的网站；
6. 收到网站返回的数据后，再沿代理通道送回客户端。

这个“等待客户端连接的服务端入口”叫 inbound（入站监听，也就是服务器对外开的接待窗口）。

vless:// 链接不是服务器，而是连接说明书

服务端入站创建完成后，3X-UI 可以导出一条以 vless:// 开头的分享链接。

这条链接通常包含：

• VPS 的服务器地址；
• Xray 正在监听的端口；
• UUID；
• REALITY 公钥；
• shortId；
• SNI（服务器名称指示，客户端握手时声明的目标域名）；
• uTLS（模拟浏览器 TLS 握手指纹的客户端实现）类型；
• TCP 等传输参数。

它没有把服务端程序“装进”链接里。它只是把客户端连接远端所需的公开参数和身份参数打包成一张连接说明书。

后来把这条链接转换或填写成 Clash 配置，才出现了首页中的：

配置名称：DMIT-Reality
策略组：PROXY
节点名称：DMIT-VPS
节点类型：VLESS

DMIT-VPS 只是客户端中的节点标签。真正的服务仍然运行在 DMIT VPS 上；换成 Karing、v2rayN 或其他兼容客户端时，仍然可以使用同一个远端代理入口。

一次访问到底怎样经过这台 VPS

下面按照请求和返回两个方向走一遍：

sequenceDiagram
    participant A as 浏览器或其他应用
    participant M as Mac 上的 Mihomo
    participant X as DMIT VPS 上的 Xray
    participant W as 目标网站

    A->>M: 请求访问目标网站
    M->>M: 按规则决定交给 DMIT-VPS
    M->>X: 建立 VLESS + TCP + REALITY 代理连接
    X->>X: 核验 UUID 和 REALITY 参数
    X->>W: 以 DMIT 的公网 IP 连接目标网站
    W-->>X: 把网页数据返回给 DMIT
    X-->>M: 通过代理通道把数据送回 Mac
    M-->>A: 交还给最初发起请求的应用

因此，目标网站看到的来源通常是 DMIT 的公网 IP，而不是当前家庭宽带的公网 IP。

你租来的不是“一个 IP 转换器”。你租来的是一台远程电脑，然后在这台电脑上运行代理服务，让它代替本机访问网站，再把结果转发回来。

它到底算不算 VPN

要看使用的是宽泛叫法，还是严格技术分类。

说法	是否合适	原因
自建代理服务器	最准确	服务端运行 VLESS/REALITY 代理入口，客户端逐项把请求交给它
自建代理节点	日常可以这样说	DMIT-VPS 确实是 Clash Verge 中可选择的代理出口
加密代理通道	可以	本机与 DMIT 之间建立了受 REALITY 保护的代理连接
自建 VPN	宽泛口语中能理解，但不够准确	使用效果与消费级 VPN 类似，但当前协议不是传统网络层 VPN
一台 VPN 服务器	容易误导	容易让人误以为服务端运行的是 WireGuard、OpenVPN 等 VPN 协议

传统 VPN 更像是在操作系统网络层建立一张虚拟网卡，把完整 IP 数据包送进隧道。

VLESS 代理更像是本机 Mihomo 接到一项“请访问这个网站”的任务，再通过代理通道把任务交给 DMIT。两者都可能让目标网站看到远端服务器的 IP，但接管位置、数据格式和配置方式不同。

如果 Clash Verge 开启 TUN（虚拟网卡接管模式），整机使用体验会更接近传统 VPN；但远端使用的仍然可以是 VLESS 代理协议，不会因为本机开了 TUN 就自动变成 WireGuard。

当前本机实际能确认到哪一层

2026 年 7 月 30 日重新只读核验后，可以确认：

• 当前配置仍然叫 DMIT-Reality；
• PROXY 策略组当前选中 DMIT-VPS；
• 该节点类型为 VLESS，传输网络为 TCP；
• 配置启用了 TLS，并包含 REALITY 公钥、shortId、SNI 和浏览器指纹参数；
• 节点允许 UDP；
• 当前为规则模式；
• 系统 HTTP、HTTPS 和 SOCKS 代理都指向本机 127.0.0.1:7897；
• TUN 当前关闭。

当前客户端配置没有设置 flow: xtls-rprx-vision。历史记录还显示，2026 年 3 月 22 日曾经因为客户端误加 XTLS Vision（Xray 的流控模式）导致连接超时，删除该参数后恢复。因此，这个节点应描述为 VLESS + TCP + REALITY，不能写成“必定附带 XTLS Vision”。

当前 SSH 密钥无法登录这台 VPS，所以这次没有从远端实时读取 Xray 进程和 3X-UI 数据库。3X-UI/Xray 的建立过程来自历史教程与当时的节点导入记录；客户端协议、节点参数和当前选择则来自本机实时配置。

3X-UI 与 Xray 的关系可以查看 3X-UI 官方架构说明。

4. 常见代理协议对比

Clash Verge 支持多种代理或隧道协议。它们定义了流量如何加密、伪装和传输，可以理解为不同的伪装方式和传输通道：

协议	一句话概括
Shadowsocks（简称 SS）	较早流行的代理协议，把流量加密成随机字节，简单高效，但流量特征已经被审查系统熟悉。
Trojan（借用标准 TLS（传输层安全协议）外观的代理协议）	把代理流量包装成正常的 HTTPS（加密的网页传输协议）连接，防火墙看到的更接近普通 HTTPS 网站访问，伪装性通常比纯 SS 好。
V2Ray / Xray（两套相关的代理框架名称）	不是单一协议，而是框架或工具箱，内置 VMess（V2Ray 体系的代理协议）、VLESS（轻量、无状态的代理协议）等多种协议，可以自由组合传输层和安全层。常见组合之一是 VLESS + XTLS Vision（Xray 的流控模式）+ REALITY（借用真实站点 TLS 特征的安全传输层）。
Hysteria（基于 QUIC（建立在 UDP（用户数据报协议）之上的现代传输协议）的代理协议）	常与 HTTP/3（第三版超文本传输协议）一起讨论，侧重高延迟、易丢包网络中的传输表现。TCP（传输控制协议）丢包后要按规则重传；QUIC 的多条数据流互相影响较少。Hysteria2（Hysteria 第二代协议）是其后续版本。
WireGuard（现代 VPN（虚拟专用网络）隧道协议）	Linux（开源操作系统）内核内置，加密强、代码精炼，但流量特征相对明确，更多用于企业组网或家庭 VPN。

5. Shadowsocks + v2ray-plugin（传输伪装插件）：两层加密和伪装

SS 负责加密，v2ray-plugin（给 Shadowsocks 增加传输伪装的插件）负责把连接伪装成 HTTPS。具体原理是双层分工。

第一层：SS 加密

SS 拿到原始请求，用加密算法把数据变成一堆无规律的随机字节。问题在于，随机字节本身也是一种特征，审查系统可能通过熵值分析发现“这段流量不对劲”。

第二层：插件伪装

v2ray-plugin 会在 SS 的出口和入口外面增加一层 WebSocket over TLS（运行在 TLS 加密层上的网页双向长连接）：

1. TLS 握手： 客户端和服务端先完成 TLS 握手，需要一张有效证书，可以使用 Let’s Encrypt（免费自动签发 TLS 证书的服务）签发。从网络层面看，这就是标准的 HTTPS 连接建立过程。
2. 升级到 WebSocket： TLS 建立后，连接升级为 WebSocket。后续数据使用 WebSocket 帧传输，对外表现为浏览器和服务器之间的长连接。很多正常网站也使用 WebSocket，例如聊天和实时推送，因此流量特征不突兀。
3. 把 SS 密文作为载荷： WebSocket 帧里装的是 SS 加密后的随机字节。中间网络先看到 TLS 保护的 HTTPS 流量，里面才是 WebSocket 帧，SS 密文藏在最内层。

整条链路是：

flowchart LR
    A["你的浏览器"] --> B["SS 客户端加密"]
    B --> C["v2ray-plugin 包装成 WebSocket"]
    C --> D["TLS 加密（HTTPS 外层）"]
    D --> E["互联网"]
    E --> F["TLS 解密"]
    F --> G["v2ray-plugin 解 WebSocket 帧"]
    G --> H["SS 服务端解密"]
    H --> I["目标网站"]

关键理解

两层加密各司其职。SS 加密保证代理数据的机密性，插件外层的 TLS 负责让连接外观更接近正常 HTTPS。可以把它想成一件快递：SS 先给内容上锁，插件再把它装进普通纸箱。

与单纯 SS 的区别

对比项	纯 SS	SS + v2ray-plugin
流量特征	随机字节流，熵值异常	标准 HTTPS/WebSocket 流
TLS	无	有完整 TLS 握手和证书
被识别风险	较高，流量指纹明显	较低，混在大量 HTTPS 流量中
握手包	SS 自有协议握手	标准 TLS ClientHello（TLS 握手时客户端发出的第一份能力清单）

为什么仍然可能被识别？

v2ray-plugin 的 TLS 握手指纹可能和真实浏览器不同；长期、大流量的 WebSocket 连接也不完全符合真人浏览行为。

6. Trojan + TLS：伪装成普通 HTTPS 网站

流量过程：

浏览器
→ Mihomo（Trojan 客户端）
→ TLS 加密隧道
→ 境外 VPS（Trojan 服务器）
→ google.com（Google（谷歌公司及其服务品牌）的网站域名）

Trojan 的思路可以分成两步：

1. 握手阶段： Trojan 客户端连接服务器的 443 端口，执行一次真实的 TLS 握手，与浏览器访问一个 HTTPS 网站相似。防火墙看到的是本机与境外 VPS 建立了正常的 HTTPS 连接，不知道隧道另一端最终会访问 google.com。
2. 隧道内传输： TLS 加密隧道建立后，客户端在隧道内发送包含密码等信息的 Trojan 头部。服务器确认暗号正确后才进入代理通道；如果访客没有合法密码，服务器就返回一个 fallback（认证失败后转交伪装站点的回退机制）网页。

例如，检测系统发现 myblog.com（示例网站域名）的 443 端口流量很大，于是直接使用普通浏览器访问。Trojan 服务端发现访客没有合法密码，就返回一个正常网页。检测者看到的仍然像一个普通 HTTPS 网站。

7. VLESS + XTLS Vision + REALITY：三层分工

VLESS 负责说明“谁在连接、要访问哪里”，XTLS Vision 负责更高效地传输已经加密的数据，REALITY 负责保护并掩饰本机到 VPS 这一段连接。

这三个词不是三个并列的“加密协议”，而是三层分工：

组成	它负责什么	大白话类比
VLESS	识别用户，并把目标域名、端口等代理请求交给远端服务器	快递单：写明谁有权寄件、包裹要送到哪里
XTLS Vision	一种流控方式。遇到网站本身已经用 TLS 加密的数据时，尽量直接转发，减少重复封装、数据复制和明显的“TLS 套 TLS”特征	中转站不反复拆箱、换箱，检查后尽量原样转运
REALITY	保护本机到 VPS 的连接，并借用一个合适的真实 HTTPS 站点作为 target（REALITY 服务端配置的目标站点），让 TLS 握手和无效访问时的外部表现更接近正常 HTTPS 连接	给运输通道套上更像正常 HTTPS 的外观，同时核对只有合法客户端才知道的暗号

VLESS：说明用户身份和访问目标

在这套组合中，VLESS 是一套轻量的代理规则。客户端使用 UUID（通用唯一标识符）证明自己有权使用节点，同时告诉服务器最终要访问哪个域名和端口。常见的 VLESS + REALITY 配置不会只依赖 VLESS 本身保护公网传输，而是把这部分安全交给外层 REALITY。

XTLS Vision：优化已经加密的数据传输

XTLS Vision 不是网站证书，也不是另一个节点，而是 VLESS 配置中的一种流控模式，配置里常写成 xtls-rprx-vision（启用 XTLS Vision 的配置值）。

假设浏览器访问 https://google.com，网页内容本来已经被 Google 的 HTTPS 加密。XTLS Vision 会识别这类内层 TLS 数据，尽量高效地转发，减少外面再机械套一层 TLS 所带来的性能消耗和异常流量特征。

REALITY：保护并掩饰代理连接

客户端会使用 uTLS（模拟真实浏览器 TLS 握手指纹的客户端实现）模拟 Chrome（谷歌浏览器）等浏览器的 TLS 握手特征；服务端则配置一个真实 HTTPS 站点作为 target（REALITY 服务端配置的目标站点），并限定客户端可以使用的 serverName（客户端在 TLS 握手中声明的目标站点名称）。

合法客户端通过 REALITY 的密钥、shortId（REALITY 用来快速区分合法连接的短标识）等信息完成验证后，进入真正的 VLESS 代理通道；不符合验证条件的普通探测流量，会被服务端转发到配置好的 target。

所以“REALITY 可以伪装成任意已有 HTTPS 网站”并不准确。更准确的说法是：

REALITY 可以选用一个符合条件的真实 HTTPS 站点作为目标，让连接握手和探测失败时的表现更接近该站点；但它不会复制这个网站，也不会让 VPS 真的变成这个网站。

SNI（服务器名称指示）、SAN（主题备用名称）与证书的关系

先纠正一个最容易混淆的地方：浏览器就是客户端，另一头是网站服务器。不是“服务器相信了浏览器的请求”，而是浏览器通过服务器发回的证书，判断自己是否连接到了真正的目标网站。

SNI（Server Name Indication，服务器名称指示）是客户端在 TLS 握手时发给服务器的“我要访问哪个域名”。很多网站共用同一个 IP，服务器需要先看到 SNI，才能知道应该使用哪套网站配置、返回哪张证书。

SAN（Subject Alternative Name，主题备用名称）是 TLS 证书中的“适用域名名单”。客户端收到证书后，会检查自己要访问的域名是否出现在 SAN 中；如果不在，浏览器通常会提示证书与域名不匹配。

例如，浏览器准备访问：

https://api.example.com/users

其中，api.example.com（示例接口域名）是域名，/users 是网站内部的具体路径。SNI 中通常只会放 api.example.com，不会放 https://、/users 或后面的查询参数。

整个过程按时间顺序可以拆成九步：

sequenceDiagram
    autonumber
    participant C as 浏览器（客户端）
    participant D as DNS 服务器
    participant S as 网站服务器

    C->>D: 查询 api.example.com 对应的 IP
    D-->>C: 返回 203.0.113.10
    C->>S: 连接 203.0.113.10
    C->>S: 发送 TLS ClientHello<br/>SNI = api.example.com
    Note right of S: 根据 SNI 选择<br/>网站配置、证书和后端服务
    S-->>C: 返回证书<br/>SAN 中列出证书可代表的域名
    Note left of C: 核验签发机构、有效期、签名和 SAN

    alt SAN 包含 api.example.com
        C->>S: 继续 TLS 握手和密钥协商
        S-->>C: 完成密钥协商
        Note over C,S: TLS 加密连接建立成功
        C->>S: 发送加密后的 /users 网页请求
        S-->>C: 返回加密后的网页数据
    else SAN 不包含 api.example.com
        C--xS: 发送 TLS 警报并中止握手
        Note left of C: 提示证书与域名不匹配
    end

1. 浏览器先从网址中提取域名。 浏览器看到要访问的域名是 api.example.com。
2. DNS（域名系统，负责把域名转换成 IP）把域名解析为 IP。 假设解析结果是 203.0.113.10，浏览器就准备连接这个 IP。
3. 浏览器连接这个 IP。 但是一个 IP 后面可能同时放着 api.example.com、shop.example.com（示例购物网站域名）等多个网站，所以服务器此时还不知道浏览器具体要找谁。
4. 浏览器发送 TLS ClientHello。 ClientHello 是 TLS 握手时客户端发出的第一份能力清单，里面会说明浏览器支持哪些 TLS 版本和加密方式，并通过 SNI 报出 api.example.com。
5. 服务器根据 SNI 选择网站配置。 这通常不是重新向互联网查询，而是在服务器已有的配置中选择 api.example.com 对应的网站、证书和后端服务。
6. 服务器把选中的证书发给浏览器。 证书的 SAN 中记录了这张证书允许代表哪些域名。
7. 浏览器检查证书。 浏览器不仅检查 SAN 是否包含 api.example.com，还会检查证书是不是可信机构签发的、有没有过期、签名是否正确以及内容有没有被篡改。
8. 双方完成密钥协商。 证书验证通过后，浏览器和服务器还要协商并生成这次连接使用的加密密钥。完成这一步，TLS 加密连接才算真正建立成功。
9. 浏览器发送加密后的网页请求。 这时 /users 等具体路径才会通过已经建立的 TLS 通道发送给服务器，中间网络通常看不到这些加密后的具体内容。

严格来说，浏览器核对的是：

网址里的域名 ↔ 证书 SAN 中允许代表的域名

不是简单地核对：

SNI ↔ SAN

只不过在正常访问中，网址里的域名通常也会被填入 SNI，所以三者一般保持一致：

网址里的域名：api.example.com
SNI 报出的域名：api.example.com
证书 SAN：包含 api.example.com

如果证书的 SAN 包含 api.example.com，域名核对通过；如果证书只能代表 shop.example.com，浏览器就会认为服务器身份对不上，并提示证书错误。

两者的区别可以压缩成一句话：

SNI 是客户端先报出“我要找谁”，SAN 是服务器证书证明“我能代表谁”。

在 REALITY 配置中，serverNames（服务端允许使用的 SNI 名称列表）、target 和目标网站证书的 SAN 应当相互匹配。比如 serverName 填了 www.example.com（示例网站域名），目标网站返回的证书就应该允许用于 www.example.com，也就是证书的 SAN 中包含这个域名。

目标站点因此不是随便填一个就行。serverNames 不支持 * 通配符；配置不合适时，连接可能直接失败，也可能让握手行为与目标网站对不上，产生异常特征。

把整条 VLESS + REALITY 链路串起来

浏览器访问 google.com，并建立网站自己的 HTTPS 加密
→ Mihomo 用 VLESS 写明用户身份和目标地址
→ XTLS Vision 高效处理已经加密的内层 TLS 数据
→ REALITY 保护并掩饰“本机 ↔ DMIT VPS”这一段连接
→ DMIT VPS 验证客户端，解出 VLESS 请求
→ DMIT VPS 再连接 google.com

中间网络看到的是本机正在连接 DMIT VPS，以及一段外观更接近正常 HTTPS 的 TLS 流量；Google 最终看到的来源则是 DMIT VPS 的出口 IP。REALITY 提高的是这段代理连接的隐藏性和抗探测能力，不代表完全无法识别，也不等于匿名。

8. Hysteria 和 Hysteria2：用 QUIC 改善差网络传输

Hysteria 是第一代方案，Hysteria2 是从 2.0.0 开始使用的新协议。Hysteria2 几乎重写了第一代协议，因此不能只把它理解成修补了几个问题的小版本更新。现在看到机场或客户端写 hysteria2，通常指第二代协议。

Hysteria2 到底做什么

Hysteria2 是建立在 QUIC 之上的 TCP 和 UDP 代理。它可以把应用产生的 TCP 或 UDP 流量装进一条 QUIC 连接，再通过 UDP 发送到远程 Hysteria2 服务器：

应用产生 TCP 或 UDP 流量
→ 本机 Hysteria2 客户端
→ 封装进 QUIC 连接
→ 通过 UDP 发送到 Hysteria2 服务器
→ 服务器解包并连接目标网站

对于 TCP 请求，Hysteria2 会为不同连接建立不同的 QUIC 双向数据流。可以把它想成一条有多条车道的高速公路：某条车道出现丢包和重传时，其他数据流不必全部停下来等待。

为什么它适合高延迟、易丢包网络

传统 TCP 会根据丢包情况主动降低发送速度，避免继续造成拥堵。这个机制在正常网络中很重要，但在高延迟、无线干扰或偶发丢包的网络里，有时会把速度压得过低。

Hysteria2 使用 QUIC，并配合自己的拥塞控制（根据网络承受能力调节发送速度的机制）调节传输。因此，它在高延迟和易丢包网络中可能比传统 TCP 代理保持更好的吞吐量，也就是单位时间内成功传输更多数据。

但这不等于“丢包完全不影响速度”，也不代表它可以凭空突破宽带上限。带宽填写过高、网络本身严重拥塞或服务器性能不足时，连接仍然可能变慢甚至更加不稳定。

HTTP/3 伪装是怎么工作的

Hysteria2 服务器同时表现得像一个标准 HTTP/3 服务器：

• 合法客户端会发送带有认证信息的特殊 HTTP/3 请求；
• 认证成功后，这条 QUIC 连接才会切换成 Hysteria2 代理连接；
• 没有正确认证信息的普通访问或主动探测，会看到正常网页、反向代理（由服务器代替访问另一个网站）内容或普通错误页面。

所以 Hysteria2 的思路不是 REALITY 那种目标站点握手方式。Hysteria2 通常使用自己的 TLS 证书和认证参数，再把外部表现伪装成标准 HTTP/3 服务。

Hysteria2 的边界

• 它依赖 UDP；如果当前网络封锁或严重限制 UDP、QUIC，连接可能直接失败。
• 它更擅长把 TCP 流量放进优化后的 QUIC 通道；代理网站原生的 HTTP/3 流量不一定获得同样的加速效果。
• QUIC 通常在应用程序所在的用户空间处理，比成熟的系统内核 TCP 实现更可能消耗额外的处理器资源。
• 它适合差网络下的代理加速，不代表在稳定、低延迟网络中一定比其他协议更快。

具体机制可查看 Hysteria2 官方协议说明和 Hysteria2 关于 HTTP/3 的说明。

9. WireGuard：像给两台设备拉了一根加密网线

先暂时忘掉公钥、路由这些词。

WireGuard 的核心其实只有一句话：它会在两台设备之间建立一条加密通道，让两台原本相隔很远的设备，像插在同一张安全局域网里一样通信。

可以把普通互联网想成公共马路。你传出去的数据就像在马路上运输的包裹。

WireGuard 则像一根看不见的专用管道。包裹进入管道前会被锁进箱子，通过普通互联网运到另一端后，再由另一端解锁。沿途网络能够看到双方正在传输数据，却不能直接读懂箱子里的原始内容。

所以，“虚拟网线”只是帮助理解的比喻。它不是真有一根线从你的 Mac（苹果电脑）拉到美国，而是双方的软件通过互联网模拟出了一条加密连接。

用“Mac 连接远程 VPS”走一遍

下面只是一个帮助理解的例子，不代表截图中的 DMIT-VPS 正在使用 WireGuard。截图里的实际节点仍然是 VLESS + REALITY。

假设 Mac 和一台远程 VPS 都配置了 WireGuard。当 Mac 通过这条通道访问网站时，双方会这样配合：

sequenceDiagram
    participant M as Mac 上的 WireGuard
    participant V as VPS 上的 WireGuard
    participant W as 目标网站

    M->>V: ① 加密整个 IP 数据包，通过 UDP 发出
    V->>V: ② 解密，取出原始 IP 数据包
    V->>W: ③ 代替 Mac 把请求发给网站
    W-->>V: ④ 网站把结果返回 VPS
    V->>V: ⑤ 再把返回数据加密
    V-->>M: ⑥ 通过 UDP 送回 Mac
    M->>M: ⑦ 解密后交给原来的应用

从 Mac 到 VPS 时要加密，从 VPS 回到 Mac 时也要加密，所以这是一条双向通道。

目标网站最终看到的来源 IP 是 VPS 的出口 IP，而不是 Mac 当前宽带的公网 IP。

虚拟网卡到底在做什么

WireGuard 启动后，会在系统里创建一张虚拟网卡。

真实网卡负责连接 Wi-Fi（无线网络）或网线；虚拟网卡则是软件创建的“内部入口”。系统把需要走 WireGuard 的数据交给这个入口，WireGuard 再负责加密并发给远端。

整个过程可以压缩成：

应用产生数据
→ 系统把需要加密的数据交给 WireGuard 虚拟网卡
→ WireGuard 加密整个 IP 数据包
→ 通过 UDP 送到远端设备
→ 远端 WireGuard 解密并继续转发

WireGuard 处理的是完整的 IP 数据包，不只是某个浏览器请求。因此它更像在网络层铺了一条路，而不是让每个应用逐次向代理服务器说明“我要访问哪个网站”。

peer（通信对端）：就是网线的另一头

peer 就是这条虚拟网线另一端的设备。

在上面的例子中：

• 对 Mac 来说，VPS 是它的 peer；
• 对 VPS 来说，Mac 也是它的 peer。

因此，WireGuard 不强调谁永远是客户端、谁永远是服务器。双方本质上都是能够发送和接收数据的对等节点。

公钥和私钥：先确认“网线两头是谁”

现实中不能让陌生设备随便接入这条虚拟网线，所以每台 WireGuard 设备都有一对密钥：

• 私钥： 像只能由自己保管的印章，不能发给别人；
• 公钥： 像可以交给对方核对的身份牌；
• 双方提前保存对方的公钥： 表示“我只接受这个指定设备”。

Mac 和 VPS 建立连接时，会用这些密钥确认对方身份，并协商本次通信使用的加密密钥。整个过程不会把私钥直接发送给对方。

AllowedIPs（允许通过某个对端传输的 IP 地址范围）：决定“哪些地址走这根网线”

AllowedIPs 这个名字容易让人误以为它只是一张白名单。对初学者来说，先把它理解成虚拟网线的送货范围最容易。

例如：

AllowedIPs = 0.0.0.0/0

可以先理解成“所有 IPv4（第四版互联网协议）地址都交给这个 WireGuard 对端”，通常用于让大部分或全部互联网流量通过远端 VPS。

如果写成：

AllowedIPs = 10.0.0.0/24

就表示只有去往 10.0.0.x 这一段内部地址的流量交给这个对端，其他网站仍然走原来的网络。这常用于只访问公司内网或家庭服务器。

说得更准确一点，AllowedIPs 同时做两件事：

1. 发送时选路： 去往哪些 IP 的数据应该交给哪个 peer；
2. 接收时检查： 这个 peer 是否有资格发来相应来源 IP 的数据。

WireGuard 把“对端公钥”和“允许它承载的 IP 范围”绑定起来，这套机制叫 Cryptokey Routing（加密密钥路由）。这个英文名称不需要死记，记住“认准哪台设备，再规定它负责哪些地址”就够了。

WireGuard 和 TLS、REALITY 有什么区别

WireGuard 不需要伪装成某个 HTTPS 网站，也不使用网站的 TLS 证书，所以它没有选择网站证书时所需的 SNI 和 SAN，也不需要 REALITY 的目标站点。

它使用 Noise（安全握手协议框架）和双方的 WireGuard 密钥验证设备身份、协商加密密钥。因此它核对的是“网线另一头是不是指定设备”，不是“这张网站证书能不能代表某个域名”。

可以这样区分：

方案	更像什么	主要验证什么
VLESS + REALITY	经过伪装的代理通道	连接者是否知道正确的身份和 REALITY 参数
Hysteria2	借助 QUIC 的高速代理通道	TLS 证书和 Hysteria2 认证信息是否正确
WireGuard	两台设备之间的加密虚拟网线	对方是否持有对应的 WireGuard 私钥

WireGuard 适合什么场景

下面四种场景用的是同一个 WireGuard，区别主要在于：哪些设备加入通道，以及哪些 IP 地址需要通过通道。

场景一：把分散在各处的设备组成一张虚拟局域网

假设你有四台设备：

• 家里的电脑；
• 随身携带的手机；
• 家里的 NAS（网络存储设备）；
• 放在美国机房的 VPS。

它们原本处于四个不同网络里，不能像连接同一个家庭路由器那样直接互相访问。

安装并配置 WireGuard 后，可以给它们分别分配一个虚拟 IP，例如：

家里的电脑：10.0.0.2
手机：10.0.0.3
家庭 NAS：10.0.0.4
云端 VPS：10.0.0.5

以后，手机访问 10.0.0.4，就可以通过 WireGuard 找到家里的 NAS；家里的电脑访问 10.0.0.5，就可以连接云端 VPS。设备虽然仍然分散在不同城市和不同网络里，但它们可以使用这组虚拟 IP 互相通信。

这里说的“虚拟局域网”是一种便于理解的说法。更准确地说，WireGuard 为这些设备建立了一张加密的 IP 通信网络。它们可以按虚拟 IP 互相连接，但不代表隔空投送、打印机发现等依赖同一家庭网络自动发现设备的功能一定会直接生效。

场景二：人在外面，安全访问公司或家里的内部设备

假设公司的文件服务器只能在办公室网络中访问，地址是 10.20.0.10。你在家里、酒店或咖啡馆时，电脑并不在公司网络里，所以通常无法直接打开这个地址。

公司可以在内网入口部署一个 WireGuard 对端。你的电脑建立连接后，请求会这样走：

外面的电脑
→ WireGuard 加密通道
→ 公司内网入口
→ 公司文件服务器 10.20.0.10

家用场景也是一样：你可以在外面通过 WireGuard 访问家里的 NAS、家庭服务器或路由器管理页面，不必把这些内部服务直接公开给整个互联网。

这种配置通常只让公司或家庭内部地址进入 WireGuard。你访问普通网站时，仍然使用当前酒店、咖啡馆或家庭宽带上网。

但“使用 WireGuard”不等于内部设备自动绝对安全。还要妥善保管私钥，并正确配置服务器权限和防火墙。

场景三：让大部分互联网流量通过远程服务器转发

这个场景更接近大家平时理解的 VPN 用法。

如果 Mac 把几乎所有目标 IP 都交给 WireGuard，数据会这样走：

Mac 上的应用
→ WireGuard 加密
→ 远程 VPS 解密
→ VPS 连接目标网站
→ 网站把结果返回 VPS
→ VPS 加密后送回 Mac

目标网站看到的是 VPS 的出口 IP。Mac 到 VPS 之间的数据受到 WireGuard 加密保护，因此在公共 Wi-Fi 上网时，中间网络不能直接读取这段通道里的原始 IP 数据包。

要实现这种效果，除了把 AllowedIPs 设置为覆盖大部分或全部目标地址，VPS 还要允许转发流量，并正确配置 NAT（网络地址转换，让多台设备借用服务器出口地址上网）。只在两端安装 WireGuard，但没有配置服务器转发，并不能自动把 VPS 变成互联网出口。

它与 VLESS 代理的最终效果有些相似：目标网站都可能看到远程服务器的出口 IP。区别在于，VLESS 更像应用把访问任务交给代理服务器；WireGuard 则是在 IP 网络层把数据包送进一条加密隧道。

场景四：只让指定网段进入隧道

这个场景叫 Split Tunneling（分流隧道）：只有指定目标地址通过 WireGuard，其他流量仍然直接上网。

例如，公司内网使用：

10.20.0.0/24

那么可以把这段地址放进 AllowedIPs。结果就是：

访问 10.20.0.x 的公司内部设备
→ 进入 WireGuard
 
访问普通网站
→ 不进入 WireGuard，继续使用当前网络

这样做的好处是，公司内部资料经过安全通道访问；看视频、下载文件和访问普通网站则不必绕到公司或远程 VPS，可以减少远端服务器的带宽占用。

这里的“指定网段”就是一组连续的 IP 地址。WireGuard 主要根据目标 IP 决定是否进入隧道，不是直接根据网站域名判断。如果公司内部域名需要通过专用 DNS 才能解析，还要同时配置对应的 DNS。

可以把四种场景压缩成下面这张表：

场景	哪些数据进入 WireGuard	主要目的
多设备虚拟组网	加入组网的设备之间的数据	让分散的设备按虚拟 IP 互相访问
远程访问内网	去往公司或家庭内部地址的数据	在外面安全使用内部资源
远程服务器转发	大部分或全部互联网流量	使用远程服务器作为上网出口
指定网段分流	只有指定 IP 范围的数据	内网走隧道，普通网站继续直连

这四种场景并不是互相排斥的。例如：

• “在外面访问公司内网”通常同时属于场景二和场景四：目标是远程访问内网，实现方式是只把公司网段送进隧道；
• “让电脑和手机都通过同一台 VPS 上网”通常同时属于场景一和场景三：先把多台设备接入同一张 WireGuard 网络，再让它们使用 VPS 作为互联网出口。

它的配置和运行都很精简，但主要目标不是把流量伪装成普通 HTTPS 网站。如果当前网络直接封锁或严重限制 WireGuard 使用的 UDP 通信，它也可能无法正常连接。

具体机制可查看 WireGuard 官方概念说明和 WireGuard 官方协议说明。

10. HTTP/2（第二版超文本传输协议）与 HTTP/3

上面提到的 WebSocket + TLS、gRPC（基于 HTTP/2 的远程过程调用协议）、QUIC 绕不开 HTTP/2 和 HTTP/3，它们是网页传输协议的新版本：

版本	底层传输	核心特点
HTTP/1.1（第一版常用的超文本传输协议）	TCP	一次一个请求，多个请求要排队，容易出现队头阻塞。
HTTP/2	TCP	支持多路复用，一个连接可以同时传多个文件。但底层仍是 TCP，一旦丢包，多个请求都要等待重传。
HTTP/3	QUIC（UDP）	使用 QUIC，每条数据流相对独立。某条流丢包时，其他数据流仍可继续。

为什么代理场景里经常提到它们：

• V2Ray / Xray 常用 WebSocket + TLS 或 gRPC 做传输伪装，这些都跑在 HTTP/2 上，防火墙看到的就是正常 HTTP/2 流量。
• Hysteria 直接基于 QUIC（HTTP/3 的底层），所以具备“丢包时不同数据流相互影响较少”的特性，差网络下通常比传统 TCP 方案更有优势。

简单说：HTTP/2 解决了一个连接内的排队问题，HTTP/3 进一步解决了丢包就全体卡住的问题。

11. 把协议知识放回当前截图

前面介绍了很多协议，不代表截图中的节点同时使用了所有协议。

截图直接显示的节点类型是 VLESS，并且界面标签显示 UDP 和 XUDP（客户端展示的 Xray UDP 承载能力标签）。但界面出现 XUDP，不等于当前配置已经明确启用 XUDP 编码。因此，从截图和当时的本机配置可以确认：

• DMIT-Reality（当前整份代理配置的名称）：整份配置说明书；
• PROXY：规则可以交给它选择出口的策略组；
• DMIT-VPS：PROXY 当时选中的实际节点；
• VLESS：本机 Mihomo 与远程节点使用的代理协议；
• REALITY：结合当时本机配置确认，是这条 VLESS 连接使用的安全传输层；
• WireGuard、Trojan 和 Hysteria2：本节用于横向学习的其他方案，不是当前截图正在使用的节点协议。

这里要养成一个习惯：协议名称、配置名称、策略组名称和节点名称必须分开看，不能看到配置名里有某个词，就自动推断整条链路的所有技术细节。

三、左侧菜单分别解决什么问题

先看左侧真实菜单的位置。首页、代理、订阅、连接、规则、日志、测试和设置，分别对应后面讲到的不同排查层级。

这张图要看什么

蓝色底表示当前停留在“首页”。“代理”负责策略组和节点，“连接”负责查看真实请求路径，“规则”负责查看分流条件，“日志”负责查看内部报错。“设置”附近的重叠和重复图标来自长截图拼接，不是多个不同入口。

1. 首页

首页就是现在看到的总控制台，适合快速确认：

• 当前用了哪份配置；
• 当前节点是谁；
• 系统代理或 TUN 是否开启；
• 当前是规则、全局还是直连模式；
• 当前出口 IP；
• 流量和内存使用情况。

2. 代理

这里是完整的策略组和节点页面，可以：

• 查看所有代理组；
• 选择节点；
• 测试节点延迟；
• 查看节点是否超时；
• 查看某个组里包含哪些节点。

“代理组”和“节点”不是同一个东西。PROXY 是组，DMIT-VPS 是组里选中的节点。

3. 订阅

这里用于管理配置文件和订阅链接。

订阅链接的作用是下载配置，不是日常转发流量：

更新配置：Clash Verge → 订阅地址 → 下载节点和规则
正常上网：应用 → Mihomo → DMIT-VPS → 网站

订阅链接通常包含身份标识，不要公开。

4. 连接

这里显示 Mihomo 当前正在处理的网络连接，是排查问题最重要的页面之一。

里面通常可以看到：

• 哪个程序正在联网；
• 访问了什么域名或 IP；
• 命中了什么规则；
• 走了 DIRECT（直连出口）还是 PROXY；
• 最终使用了哪个节点；
• 上传和下载了多少数据。

“网站到底走哪条路”，以连接记录为准，不要只靠首页开关猜。

5. 规则

这里显示当前配置加载的分流规则。

Mihomo 通常从上到下匹配，匹配到一条就执行，不再继续往下找。常见结果是：

• DIRECT：使用本地网络直连。
• REJECT（拒绝连接）：直接拦截这项请求。
• PROXY：交给 PROXY 策略组。
• MATCH（兜底匹配规则）：前面都没匹配时使用的兜底规则。

6. 日志

这里显示 Mihomo 工作时产生的信息和报错，例如：

• 节点连接超时；
• network is unreachable（网络不可达）；
• DNS 查询失败；
• 规则加载失败；
• 端口被占用；
• TUN 启动失败。

“连接”主要看流量走向，“日志”主要看内部过程和错误。

7. 测试

这里用于测试预设网站或服务能否通过当前网络访问。

它不是宽带测速，也不能证明登录、播放、账号风控一定正常。

8. 设置

这里用于修改 Clash Verge 和 Mihomo 的详细配置，包括系统代理、TUN、DNS、端口、更新和界面等。

截图中左侧反复出现很多次“设置”，只是长截图的拼接现象。实际只有一个设置入口。

9. 左下角小图表

这是实时流量缩略图：

这张图要看什么

橙色数字对应上传，蓝色数字对应下载，最下面带芯片图标的数字对应 Mihomo 内存占用。三行数字使用的单位不同，不能混在一起比较。

• 橙色上箭头 2.93 KB/s（千字节每秒）：当时的上传速度。
• 蓝色下箭头 3.97 KB/s：当时的下载速度。
• 42.3 MB（兆字节）：Mihomo 内核占用的内存，不是已经消耗的代理流量。

四、顶部状态与当前配置

下面这张局部图同时包含首页标题、右上角三个按钮和当前配置卡。先区分“软件功能按钮”和“代理配置”这两层。

这张图要看什么

最上方三个图标属于 Clash Verge 界面功能；DMIT-Reality 是当前加载的整份配置；2026-03-24 17:21 是这份配置的更新时间。它们都不是当前代理节点的延迟或运行时间。

1. NEW（有新版本可以更新）

NEW 表示 Clash Verge 检测到有新版本可以更新。

点击后通常会打开更新说明或更新窗口。它不是“节点已更新”，也不是“订阅有新节点”。

2. 首页右上角三个按钮

从左到右分别是：

• 轻量模式：进入更精简的小窗口，只保留常用状态和开关。
• 问号：打开使用手册。
• 齿轮：首页设置，用来决定首页显示哪些卡片。

这个齿轮主要控制首页布局，不是 Mihomo 的全部网络设置。

3. DMIT-Reality 配置卡片

DMIT-Reality 是当前启用的配置名称。

它不是当前节点，而是整份配置，里面可以包括：

• 节点；
• 策略组；
• 规则；
• DNS；
• 本地端口；
• TUN 设置；
• 其他 Mihomo 参数。

右上角“订阅”按钮用于进入订阅管理页面。

更新时间：2026-03-24 17:21 表示这份配置上次更新的时间，不是节点运行时间，也不是套餐到期时间。

配置名称里虽然带有 REALITY，但名称本身不能证明协议细节。截图直接证明的是下面的节点类型为 VLESS。

五、当前节点区域：策略组、节点与能力标签

下面这张图必须分成三层看：最上方蓝色卡片描述节点名称、协议和能力；“代理组”下拉框显示规则会交给哪个策略组；“节点”下拉框显示该组最终选中了哪个具体出口。

这张图要看什么

PROXY 是策略组，DMIT-VPS 是该组当前选中的实际节点；Vless 是代理协议，UDP 表示节点允许转发 UDP。XUDP 是客户端展示的 Xray UDP 承载能力标签，不能只凭这个标签断言当前节点已经启用 packet-encoding: xudp。组名、节点名、协议名和能力标签不能互相替代。

把配置、规则、策略组和节点的关系画出来，会更容易理解：

flowchart TD
    C["DMIT-Reality 配置<br/>整份网络说明书"] --> R["分流规则"]
    C --> G["PROXY 策略组"]
    C --> L["节点列表"]
    R -->|"规则结果为 PROXY"| G
    L --> V["DMIT-VPS 节点"]
    G -->|"当前选择"| V
    V --> P["使用 VLESS + REALITY<br/>连接远程服务器"]

这不是“一层改名很多次”，而是逐层缩小范围：配置提供全部材料，规则决定交给哪个策略组，策略组再选择一个具体节点，节点最后负责真正连接远程服务器。

1. DMIT-VPS

这是当前策略组选中的节点名称。

名字只是人为设置的标签。它不等于协议，也不一定等于一台永久不变的物理服务器。

2. VLESS

这表示本地 Mihomo 与远程代理服务器之间使用 VLESS 规则通信。

它不是网站使用的 HTTPS。两者会同时存在：

本机 Mihomo
→ 使用 VLESS 连接 DMIT
→ DMIT 再使用 HTTPS 连接目标网站

3. UDP

这表示节点支持转发 UDP 流量。

DNS、部分实时通信、QUIC 或 HTTP/3 等可能使用 UDP。但显示支持，不代表每一项 UDP 流量现在都一定走它，还要看接管方式和规则。

4. XUDP（Xray 定义的 UDP 数据包编码与承载方式）：能力标签不等于已经启用

这里最容易产生的疑问是：旁边已经有一个 UDP 标签，为什么还要再显示 XUDP？

因为两者回答的不是同一个问题：

标签	它回答的问题	配置里的大致含义
UDP	这个节点允不允许代理 UDP 流量？	udp: true，打开 UDP 转发能力
XUDP	客户端或代理核心是否识别 Xray 的 UDP 承载方式？	真正明确启用时，配置通常写成 packet-encoding: xudp

可以把 UDP 理解成“这辆货车允许运输散装小包裹”，把 XUDP 理解成“这些小包裹应该怎样编号、写上收件地址，并装进远程运输通道”。

当前节点的真实配置

2026 年 7 月 30 日重新读取 DMIT-VPS 的 YAML（配置文件格式）后，能看到 udp: true，但没有 packet-encoding: xudp。按照 Mihomo 配置说明，packet-encoding 为空时使用原始编码。因此，首页的 XUDP 应当理解为客户端展示的能力标签，不能写成“当前流量正在使用 XUDP”。

为什么 UDP 需要额外编码

TCP 是连续的字节流，建立连接后，数据会沿着这条连接持续传输。

UDP 更像一封封彼此独立的明信片。每个 UDP 数据包都需要保留：

• 这个包属于哪段通信；
• 它应该送到哪个目标 IP 和端口；
• 数据包的边界在哪里；
• 远端收到后应该怎样还原并发送。

在显式启用 XUDP 时，它会按照 Xray 规定的格式，把这些信息和 UDP 数据一起编码。远端代理核心收到后，再拆出原来的 UDP 数据包并发送给目标服务。

如果一份 VLESS 配置明确写了 packet-encoding: xudp，路径可以理解成：

flowchart LR
    A["应用产生 UDP 数据包<br/>例如 DNS 或部分 QUIC 流量"] --> B["Mihomo 判断节点允许 UDP"]
    B --> C["XUDP 编码<br/>记录目标地址、端口和数据边界"]
    C --> D["放进 VLESS + REALITY 代理通道"]
    D --> E["DMIT 远端解出 XUDP 数据包"]
    E --> F["还原 UDP 数据包并发给目标服务"]

这张图解释的是 XUDP 的工作原理，不是对当前节点的实时状态证明。

Xray 官方还把 XUDP 放在 Mux（多路复用，把多段逻辑通信放进较少底层连接的机制）体系中：它可以让多段 UDP 通信通过 XUDP 聚合通道传输。对当前阅读来说，不需要记内部帧格式，只要记住它位于代理通道内部的 UDP 承载层。

这个标签不能证明什么

看到首页 XUDP 标签，只能说明客户端把它识别为相关能力，不能单独证明：

• 当前一定有 UDP 流量正在传输；
• 所有 UDP 数据包都进入了 Mihomo；
• UDP 一定通过 DMIT-VPS，因为规则仍可能让它走 DIRECT；
• XUDP 一定比其他 UDP 编码更快；
• 开启 XUDP 后，所有网站都会自动使用 HTTP/3。

所以，截图中的三个标签可以压缩成一句话：

VLESS 说明“使用哪套代理协议”，UDP 说明“当前节点允许代理 UDP”，XUDP 说明“客户端识别这种扩展能力”；是否真的启用 XUDP，要继续检查配置里有没有 packet-encoding: xudp。

具体字段可查看 Mihomo 的 VLESS 配置说明；XUDP 与多路复用的关系可查看 Xray 的出站代理与 XUDP 说明。

5. 代理组：PROXY

这是策略组名称。

规则如果写着“交给 PROXY”，Mihomo 就会查看这个组当前选择了什么出口。

6. 节点：DMIT-VPS

这表示 PROXY 当前选中了 DMIT-VPS。

六、网络入口：系统代理与 TUN

这一块最容易和下面的“规则、全局、直连”混在一起。先只记住一句话：

网络设置决定“流量怎样进入 Mihomo”，代理模式决定“进入以后从哪里出去”。

可以把 Mihomo 想成一个物流中转站：

• “系统代理”和 TUN 负责把包裹送进中转站，是入口层；
• “规则、全局、直连”负责给进入中转站的包裹分配去路，是决策层；
• DIRECT、DMIT-VPS 和 REJECT 才是最终可能执行的结果。

这两个层次彼此独立。打开系统代理，不代表所有请求都走 DMIT；切换全局模式，也不代表所有应用都已经被 Clash Verge 接管。

这张图要看什么

上方蓝色“系统代理”和灰色“虚拟网卡模式”是两个设置面板的切换标签：蓝色只说明当前正在查看系统代理面板，灰色只说明没有在查看虚拟网卡面板。它们本身不是两个总开关。下方“系统代理”右侧的蓝色开关，才直接说明系统代理已经开启。2026 年 7 月 30 日读取本机运行配置时，TUN 的确处于关闭状态，但这项结论来自实际配置，不是仅凭上方灰色标签得出。

先把截图上的每个控件看懂

上方蓝色“系统代理”

这是当前正在查看的设置页签。点击它，下面显示系统代理的状态、设置按钮和开关。

蓝色在这里表示“当前显示这个面板”，不能单独理解成“这个功能已开启”。是否真正开启，要继续看面板内部最右侧的开关。

上方灰色“虚拟网卡模式”

这是另一个设置页签。点击它，下面会切换到 TUN 的相关控制。

灰色表示“当前没有显示这个面板”，不等于 TUN 必然关闭。要判断 TUN 的实际状态，应当点开该面板查看开关，或者读取 Mihomo 的运行配置。

中间的状态说明

截图写着：

系统代理已启用，您的应用将通过代理访问网络

这句话是面向普通用户的概括。更准确地说，是愿意遵守 macOS 系统代理设置的应用会把新连接交给 Mihomo；游戏、部分命令行工具、某些 UDP 流量和已有长连接仍然可能不经过它。

下方“系统代理”状态行

这一行包含三部分：

• 左侧绿色状态图标：表示这一功能当前处于可用或运行状态；
• 中间齿轮：进入系统代理的详细设置；
• 右侧蓝色切换开关：这才是系统代理真正的开关。

因此，读这张图的正确顺序是：

先看上方蓝色页签
→ 确认当前正在查看“系统代理”面板
→ 再看下方右侧蓝色开关
→ 确认系统代理实际处于开启状态

系统代理和 TUN 是两条不同的入口。它们最终都把流量交给同一个 Mihomo，但接住应用的方式不同：

flowchart LR
    subgraph ENTRY["第一阶段：网络入口"]
        A["应用发出网络请求"] --> B{"应用是否遵守<br/>macOS 系统代理"}
        B -->|"遵守"| C["127.0.0.1:7897<br/>本机代理接待窗口"]
        B -->|"不遵守"| D{"TUN 是否开启<br/>且系统路由将其接管"}
        D -->|"是"| E["TUN 虚拟网卡"]
        D -->|"否"| F["绕过 Mihomo<br/>直接使用本地网络"]
    end

    C --> M["Mihomo 收到流量"]
    E --> M

    subgraph DECISION["第二阶段：代理模式"]
        M --> N{"规则、全局或直连"}
        N -->|"规则命中 DIRECT"| L["本地网络出口"]
        N -->|"规则命中 PROXY"| P["PROXY 策略组"]
        N -->|"规则命中 REJECT"| X["拒绝连接"]
        N -->|"全局"| G["GLOBAL 策略组"]
        N -->|"直连"| L
        P --> V["当前选择 DMIT-VPS"]
        G --> Q["GLOBAL 当前选择的出口"]
    end

这张图解释了一个常见现象：浏览器遵守系统代理，所以进入 Mihomo；某个游戏不遵守系统代理，而 TUN 又没开，于是它可能绕过 Mihomo。两者使用同一台 Mac，却可以走不同网络路径。

当前截图对应的两条真实路径

本机当前是“系统代理开启、TUN 关闭、规则模式”，混合代理端口是 127.0.0.1:7897，PROXY 当前选择 DMIT-VPS。

浏览器访问网页时，通常是：

浏览器
→ 读取 macOS 系统代理
→ 把请求交给 127.0.0.1:7897
→ Mihomo 收到请求
→ 规则模式判断
   ├─ 命中 DIRECT：本地网络直接访问
   ├─ 命中 PROXY：DMIT-VPS 代为访问
   └─ 命中 REJECT：拒绝连接

一个完全忽略系统代理的游戏，在 TUN 关闭时则可能是：

游戏
→ 不读取 macOS 系统代理
→ 没有进入 127.0.0.1:7897
→ TUN 又没有接管
→ 直接使用本地网络

这就是为什么同一时间浏览器可能显示美国 IP，游戏却仍然显示中国 IP。

1. 系统代理

截图中“系统代理”右侧的开关是蓝色，表示系统代理处于开启状态。

先记住一句最重要的话：

系统代理只负责告诉应用“先把请求交给本机 Mihomo”，并不直接决定请求最终走美国节点、走本地网络还是被拦截。

打开系统代理，实际上改了什么

Mac 原本允许应用直接连接网站。打开系统代理后，Clash Verge 会修改 macOS（苹果电脑操作系统）的网络代理设置，告诉愿意遵守这项设置的应用：

先不要直接访问网站，把 HTTP（超文本传输协议）、HTTPS 和 SOCKS（通用代理协议）请求交给 127.0.0.1:7897。

截图对应的本地代理地址是：

127.0.0.1:7897

其中：

• 127.0.0.1：回环地址，永远指向当前这台 Mac 自己；
• 7897：Mihomo 在本机等待接收代理请求的端口，可以把它理解成一个编号为 7897 的接待窗口。

所以，127.0.0.1:7897 不是美国服务器地址，也不是 DMIT 的公网 IP。它只是“当前 Mac 上的 Mihomo 接待窗口”。

这台 Mac 当时使用的是混合代理端口。所谓混合，就是 HTTP 和 SOCKS 等不同类型的代理请求可以交给同一个 7897 端口。

请求进入 7897 之后发生什么

应用把请求交给本机 Mihomo 后，Mihomo 才会读取配置和分流规则，决定下一步：

遵守系统代理的应用
→ macOS 告诉它使用 127.0.0.1:7897
→ 本机 Mihomo 收到请求
→ Mihomo 匹配规则
   ├─ DIRECT：使用当前本地网络直连
   ├─ PROXY：交给当前选中的 DMIT-VPS
   └─ REJECT：直接拒绝连接

因此，系统代理和规则模式分工完全不同：

部分	解决的问题	大白话理解
系统代理或 TUN	流量怎样进入 Mihomo	入口
规则、全局或直连模式	进入后应该交给谁	分流员
DMIT-VPS 等节点	代理流量从哪台远程服务器出去	出口

“系统代理已开启”只能证明 Mac 已经公布了这个本地入口，不能单独证明所有应用都已进入 Mihomo，也不能证明所有请求都走了 DMIT-VPS。

一个中国网站和一个海外网站会怎样走

假设浏览器遵守系统代理设置，并且 Mihomo 当前处于规则模式。

访问一个被规则判定为中国大陆直连的网站时：

浏览器
→ 127.0.0.1:7897
→ Mihomo
→ 命中 DIRECT
→ 使用当前宽带直接访问网站

这里虽然最终没有经过 DMIT，但请求仍然先进入了 Mihomo。Mihomo 判断它应该直连后，才使用本地网络访问网站。

访问一个被规则交给 PROXY 的海外网站时：

浏览器
→ 127.0.0.1:7897
→ Mihomo
→ 命中 PROXY
→ 当前选中的 DMIT-VPS
→ 目标网站

所以，“开启系统代理”和“所有网站都走代理”不是一回事。在当前规则模式下，同一个浏览器访问不同网站，完全可能走不同出口。

HTTPS 会不会被系统代理解密

通常不会。

浏览器访问 HTTPS 网站时，可以先通过本地 HTTP 代理发送 CONNECT（请求代理建立一条数据隧道的方法），然后浏览器仍然会与目标网站完成自己的 TLS 握手。

Clash Verge 开启系统代理，不等于给 Mac 安装了一张可以解密所有网页的证书，也不等于 Mihomo 会自动看到 HTTPS 网页里的账号、密码和正文。

可以把这两层分开理解：

系统代理
→ 负责把浏览器的连接送到 Mihomo
 
网站自己的 HTTPS
→ 负责加密浏览器与目标网站之间的网页内容

哪些应用通常会使用系统代理

不少浏览器、系统自带联网软件和普通桌面应用会读取 macOS 的系统代理设置。这些应用发起的新连接通常会先交给 127.0.0.1:7897。

但系统代理不是强制拦截整台电脑流量的总闸门。下面这些情况可能绕过它：

• 某些命令行程序不会主动读取 macOS 图形界面里的代理设置；
• 部分游戏、语音通话和实时通信主要使用 UDP，不会自动变成普通 HTTP 或 SOCKS 代理请求；
• 某些 App（应用程序）使用自己的网络实现，选择忽略系统代理；
• 某个软件已经单独填写了代理服务器或安装了浏览器代理扩展，可能按自己的设置走；
• 应用在打开系统代理之前就已建立的长连接，短时间内可能继续沿用原连接。

因此可能出现一种正常现象：浏览器已经显示美国出口 IP，但某个命令行下载工具、游戏或特殊应用仍然使用本地网络。

如果某个工具支持手动代理，可以在工具内部单独填写 127.0.0.1:7897。如果它完全不支持普通代理，又希望接管它的流量，才需要考虑 TUN。

系统代理能不能接住 UDP 和 DNS

不能简单地说“打开系统代理后，所有 UDP 和 DNS 都会自动进入 Mihomo”。

普通 HTTP 和 HTTPS 代理主要处理 TCP 连接。SOCKS 协议可以提供 UDP 转发能力，但前提是应用本身愿意按照 SOCKS 的方式使用它；macOS 的系统代理开关不会强制把所有应用产生的 UDP 数据包改造成 SOCKS 请求。

DNS 查询走哪里也取决于应用行为、Mihomo 的 DNS 配置和接管方式。有些应用会把域名直接交给代理，有些应用会先在本地解析，还有些浏览器可能使用自己的加密 DNS。

所以，系统代理比较适合“让遵守代理设置的网页和桌面应用进入 Mihomo”；要从 IP 网络层接管更广泛的 TCP、UDP 和 DNS 流量，通常要看 TUN。

关闭系统代理等于退出 Clash Verge 吗

不等于。

关闭系统代理，只是让 Clash Verge 撤销 macOS 中指向 127.0.0.1:7897 的代理设置。Mihomo 进程、配置文件、规则模式和当前节点仍然可以继续存在。

关闭后可能出现三种情况：

• 普通应用不再把新请求交给 Mihomo，恢复直接上网；
• 手动填写了 127.0.0.1:7897 的应用仍然可以继续使用 Mihomo；
• 如果 TUN 仍然开启，部分流量仍可能被虚拟网卡接管。

反过来也一样：系统代理开关已经打开，但如果 Mihomo 没有运行，或者 7897 端口没有正常监听，应用只会把请求交给一个无人接收的窗口，结果就是网页全部打不开。

系统代理与 TUN 的四种组合

系统代理	TUN	通常会发生什么
开	关	遵守系统代理的应用进入 Mihomo；忽略系统代理的应用可能直连
关	开	主要依靠虚拟网卡从 IP 网络层接管流量
开	开	普通代理请求使用本地端口，其他流量还可能被 TUN 接管；覆盖更广，但排查也更复杂
关	关	只有手动指定 Mihomo 代理地址的应用会进入 Mihomo，其他应用通常直连

结合截图和本机实际运行配置，可以确认当时是“系统代理开启、TUN 关闭、规则模式开启”。它能说明：

1. 遵守 macOS 系统代理的应用会把请求交给 Mihomo；
2. Mihomo 会继续按照规则决定直连、代理或拒绝；
3. 不遵守系统代理的应用仍然可能绕过 Mihomo；
4. 不能仅凭这个开关断言整台 Mac 的每一个数据包都经过了 DMIT。

系统代理出问题时怎样排查

现象一：打开系统代理后，所有网站都打不开。

先检查 Mihomo 是否正常运行，再检查“Clash 信息”中的混合代理端口是否仍然是 7897。如果系统指向 7897，但 Mihomo 实际没有监听这个端口，请求就没有接收者。

为了先恢复联网，可以临时关闭系统代理，让普通应用恢复直连，再继续检查日志、配置和端口。

现象二：浏览器可以走代理，命令行程序却不能。

这通常说明浏览器遵守了系统代理，而命令行程序没有读取这项设置。可以查看该工具是否支持手动代理、代理环境变量，或者改用 TUN 接管。

现象三：关闭系统代理后，网站仍然显示代理 IP。

检查 TUN 是否仍然开启，应用内部是否手动设置了代理，浏览器是否装有代理扩展，以及页面是否沿用了之前建立的长连接。

现象四：系统代理打开了，某个网站仍显示中国出口。

这不一定是故障。请求可能已经进入 Mihomo，但规则让它走了 DIRECT。到“连接”页面查看该请求命中的规则和出口，才能判断它是绕过 Mihomo，还是进入 Mihomo 后被正常分流到直连。

2. 虚拟网卡模式

这就是 TUN 模式。它的作用仍然是把流量送进 Mihomo，但接管方式与系统代理不同。

TUN 到底创建了什么

TUN 会在 macOS 中创建一张由软件模拟的虚拟网卡。

真实网卡负责把 Mac 连接到 Wi-Fi 或网线；TUN 虚拟网卡不连接真实网线，而是作为操作系统内部的一条新道路。Clash Verge 配置系统路由后，符合条件的 IP 数据包会先被送到这张虚拟网卡，再由 Mihomo 读取和处理。

可以把它想成：

应用发出 IP 数据包
→ macOS 路由把数据送进 TUN 虚拟网卡
→ Mihomo 从虚拟网卡读取数据
→ Mihomo 按规则选择 DIRECT、PROXY 或 REJECT

系统代理像是告诉应用“请自觉去 7897 窗口排队”；TUN 则更像系统直接在道路上设置了一个入口。应用不需要主动理解 HTTP 或 SOCKS 代理，也可能被系统路由送进 Mihomo。

TUN 能解决系统代理的哪些盲区

TUN 主要适合下面这些情况：

• 命令行程序不读取 macOS 系统代理；
• 游戏或实时通信使用 UDP；
• 某些应用使用自己的网络实现，直接忽略系统代理；
• 希望从 IP 网络层统一接管更多应用；
• 需要让 Mihomo 更集中地处理 TCP、UDP 和 DNS 流量。

官方快速入门也把两者分得很清楚：系统代理通常足以处理大部分浏览器需求；TUN 更适合接管不支持系统代理的游戏和命令行程序。

TUN 开启后，所有流量都会走 DMIT 吗

不会。

TUN 只决定“哪些数据包进入 Mihomo”。数据包进入以后，仍然要经过规则、全局或直连模式决定出口。

在规则模式下，即使 TUN 接住了整台 Mac 更多流量，也可能出现：

中国大陆网站 → TUN → Mihomo → DIRECT
海外网站 → TUN → Mihomo → PROXY → DMIT-VPS
广告域名 → TUN → Mihomo → REJECT

所以，TUN 不是“更强的全局模式”。TUN 是入口技术，全局模式是出口决策，两者不在同一层。

TUN 为什么会牵涉路由

路由就是操作系统判断“这个目标地址应该从哪张网卡送出去”的规则。

TUN 打开后，Clash Verge 通常需要增加路由，让原本要交给 Wi-Fi 网卡的数据先进入虚拟网卡。Mihomo 处理后，再把真正需要发往互联网的数据交给实际网卡。

这里最怕形成回路：

Mihomo 准备连接 DMIT
→ 系统又把这条连接送回 TUN
→ Mihomo 再次处理
→ 不断循环

成熟客户端会通过路由排除、自身进程排除和出口网卡识别避免这种循环。用户随意修改高级路由、虚拟网卡地址或排除网段时，才更容易破坏这套关系。

TUN 为什么经常与 DNS 一起出现

很多分流规则依赖域名。如果应用先把域名解析成 IP，而 Mihomo 没看到原始域名，部分域名规则就可能难以准确匹配。

TUN 配置常使用 DNS Hijack（DNS 劫持，把符合条件的域名查询送进 Mihomo 内部 DNS 模块）处理这个问题。这里的“劫持”不是偷数据，而是让本机 DNS 请求进入 Mihomo 统一解析和分流。

但 DNS 接管不是绝对的。局域网 DNS、浏览器自带的加密 DNS、其他 VPN 软件和手动指定的 DNS 都可能改变实际路径。

为什么 TUN 需要更高权限

普通应用可以监听本地端口，但创建虚拟网卡、修改系统路由通常需要更高的系统权限。

Clash Verge 的服务模式会安装一个具有必要权限的后台辅助服务，让界面程序不必每次开启 TUN 都重新要求输入管理员密码。

服务模式只表示“有权限帮忙完成这些系统操作”，不代表 TUN 已经打开。首页下方的系统信息显示服务模式正在运行；本机运行配置则显示 TUN 仍然关闭。这是两项彼此独立的状态。

开启 TUN 后可能影响什么

TUN 覆盖范围更广，因此也比系统代理更容易与其他网络功能发生冲突：

• 另一款 VPN 或游戏加速器也在修改路由；
• 公司安全软件安装了自己的网络过滤器；
• 虚拟机、容器或开发环境使用特殊网段；
• 家庭打印机、NAS 或路由器管理地址被错误送进代理；
• IPv4 和 IPv6（第六版互联网协议）的接管范围不一致；
• DNS 被多个软件同时修改；
• 防火墙没有允许 Mihomo 或 TUN 虚拟网卡通信。

出现“开启 TUN 后全网断开，但关闭后马上恢复”时，不要一上来怀疑远程节点。这个现象优先说明本机的权限、路由、DNS 或软件冲突需要检查。

当前界面与运行配置能说明什么

截图直接显示系统代理开关处于开启状态，但没有展开虚拟网卡面板，因此不能只凭这张局部图判断 TUN 开关。2026 年 7 月 30 日读取本机实际运行配置后，可以进一步确认 TUN 处于关闭状态。

这说明当时主要依靠 macOS 系统代理把浏览器和普通桌面应用送进 Mihomo。它不能证明游戏、命令行程序以及所有 UDP 数据都已被接管。

如果日常只是浏览网页、使用遵守系统代理的桌面应用，而且没有发现漏代理问题，没必要为了“看起来更强”强行开启 TUN。

如果某个明确的软件不遵守系统代理，再考虑开启 TUN，并在开启后到“连接”页面确认该软件的请求是否真的出现。

具体机制可查看 Clash Verge Rev（Clash Verge 的社区延续版本）名词解释和 Mihomo TUN 官方配置说明。

七、出口决策：规则、全局与直连

系统代理和 TUN 解决的是“怎样进入 Mihomo”。进入以后，首页下面的“规则、全局、直连”才负责决定流量往哪里走。

这张图要看什么

蓝色高亮的“规则”表示截图当时启用了规则模式。“全局”和“直连”按钮虽然也在这里，但当时没有选中。切换这三个按钮只改变已经进入 Mihomo 的流量怎样选择出口，不会自动改变系统代理或 TUN 的接管范围。

先把截图上的三个按钮看懂

• 蓝色“规则”：当前已选中。下面的说明文字也写着“基于预设规则智能判断流量走向”，表示 Mihomo 会逐条匹配规则；
• 灰色“全局”：当前未选中。点击后，已经进入 Mihomo 的新连接通常统一交给全局策略组；
• 灰色“直连”：当前未选中。点击后，已经进入 Mihomo 的新连接通常统一使用本地网络；
• 三个按钮互斥：同一时刻只能选择一种代理模式；
• 切换按钮不会替你开启或关闭系统代理，也不会替你开启或关闭 TUN。

这里的“全局”尤其容易误解。它的完整意思是：

所有已经进入 Mihomo 的流量，统一按全局模式处理。

它并不是：

整台电脑的所有流量都会被强制抓进 Mihomo。

三种模式可以先压缩成一张表：

模式	进入 Mihomo 后怎样处理	适合什么情况
规则	根据域名、IP、进程等条件分别选择出口	日常使用
全局	把已进入 Mihomo 的流量统一交给 GLOBAL（全局出口策略组）	临时测试代理链路
直连	把已进入 Mihomo 的流量统一交给本地网络	临时停用远程代理或排查

把三个按钮放回实际选路过程，可以看到它们的分叉位置：

flowchart TD
    A["流量已经进入 Mihomo"] --> B{"当前代理模式"}
    B -->|"规则"| C{"从上到下匹配规则"}
    C -->|"DIRECT"| D["使用本地网络直连"]
    C -->|"PROXY"| E["交给 PROXY 策略组"]
    C -->|"REJECT"| F["拒绝连接"]
    B -->|"全局"| G["统一交给 GLOBAL 策略组"]
    B -->|"直连"| D
    E --> H["策略组当前选择 DMIT-VPS"]
    G --> I["使用 GLOBAL 组当前选中的出口"]
    H --> J["远程节点连接目标网站"]
    I --> J

注意：规则模式内部仍然可能得到 DIRECT；全局模式仍然只处理已经进入 Mihomo 的流量；直连模式也不等于关闭 Clash Verge。

网络入口与代理模式要组合起来看

“系统代理或 TUN”与“规则、全局或直连”不是同一组选项。前者是入口，后者是决策。把两个维度组合起来，才知道一条请求大概会怎样走：

网络入口	代理模式	对一条请求的实际含义
系统代理开、TUN 关	规则	遵守系统代理的应用进入 Mihomo，再按规则直连、代理或拒绝；这是截图对应的状态
系统代理开、TUN 关	全局	遵守系统代理的应用进入 Mihomo，再统一交给 GLOBAL；忽略系统代理的应用仍可能直连
系统代理开、TUN 关	直连	遵守系统代理的应用仍先进入 Mihomo，但最终使用本地网络
TUN 开	规则	更多应用和 IP 数据包会进入 Mihomo，再按规则分流
TUN 开	全局	被 TUN 或其他入口接住的流量统一交给 GLOBAL，覆盖通常更广，但仍要考虑路由排除
两种入口都关	任意模式	代理模式仍保存在 Mihomo 中，但通常只影响手动指定 127.0.0.1:7897 的应用

因此：

• 系统代理开 + 规则模式，不等于所有流量走代理；
• 系统代理开 + 直连模式，不等于系统代理已经关闭；
• TUN 开 + 规则模式，不等于全局代理；
• 全局模式 + TUN 关，不等于整台电脑被完整接管。

点击按钮后，究竟改变了什么

从“规则”切换到“全局”

入口不变。原本已经会进入 Mihomo 的应用，仍然通过原来的系统代理或 TUN 进入；改变的是 Mihomo 收到新连接后的出口决策。

切换前：进入 Mihomo → 逐条匹配规则 → DIRECT、PROXY 或 REJECT
切换后：进入 Mihomo → 统一交给 GLOBAL

从“规则”切换到“直连”

入口同样不变。请求仍可能经过 127.0.0.1:7897 和 Mihomo，只是 Mihomo 不再把新连接送给 DMIT-VPS，而是使用本地网络。

关闭“系统代理”

代理模式不会因此自动改变，Mihomo 和 7897 端口也可能继续运行。变化是 macOS 不再主动通知普通应用使用这个本地代理窗口。

手动配置了 127.0.0.1:7897 的应用仍然可以进入 Mihomo；如果 TUN 开着，被 TUN 接住的流量也仍会进入 Mihomo。

打开 TUN

规则、全局或直连的选择不会因此自动改变。变化是网络入口覆盖范围扩大，更多不遵守系统代理的 IP 数据包可能被送进 Mihomo。

为什么切换后最好重新连接

模式和开关主要影响新建立的连接。浏览器页面、下载任务、即时通信和视频播放可能仍在复用原来的长连接，因此刚切换后看到旧出口并不奇怪。重新加载页面、断开并重连，或者重新启动相关应用，测试结果会更清楚。

1. 规则模式：让不同请求走不同道路

截图中选中的是规则模式，也是当前这套配置日常最合适的模式。

Mihomo 会按照配置中的规则从上到下检查请求。匹配到第一条符合条件的规则后，就执行对应动作，通常不再继续向下寻找。

常见匹配条件包括：

• 域名，例如某个网站或某类网站；
• 目标 IP 或 IP 地址段；
• 发起请求的应用进程；
• 目标端口；
• 网站所属国家或规则集合；
• 最后一条 MATCH 兜底规则。

常见处理结果包括：

• DIRECT：使用当前本地网络直连；
• PROXY：交给 PROXY 策略组；
• REJECT：拒绝连接；
• 其他策略组：例如专门用于流媒体、人工选择或自动测速的组。

用两个网站理解规则模式

假设规则中规定中国大陆网站直连，其他未匹配网站交给 PROXY。

访问中国网站时：

请求进入 Mihomo
→ 命中中国网站规则
→ DIRECT
→ 当前宽带直接连接网站

访问需要海外出口的网站时：

请求进入 Mihomo
→ 前面的直连规则都没有命中
→ 命中代理或 MATCH 兜底规则
→ PROXY
→ DMIT-VPS
→ 目标网站

这里最容易误解的是：走 DIRECT 的请求也可能先进入过 Mihomo。DIRECT 描述的是出口，不代表请求一定绕过了 Mihomo。

规则顺序为什么重要

规则采用“先匹配到谁就执行谁”的方式，前面的规则优先级更高。

例如，前面已经有一条“所有 .com 域名都走代理”的宽泛规则，后面再写“某个 .com 网站直连”，后面的规则可能永远没有机会执行。

MATCH 是兜底规则，通常放在最后。如果把它放在前面，它会提前接住所有请求，后续规则就失去意义。

怎么确认某个请求命中了哪条规则

不要只看首页上的“规则”按钮。

正确验证方法是：

1. 打开左侧“连接”页面；
2. 在目标应用中重新发起一次请求；
3. 按域名、应用或时间找到对应连接；
4. 查看它命中的规则、策略组和最终节点。

规则模式的官方机制可查看 Mihomo 全局配置说明和 Clash Verge Rev 自定义规则说明。

2. 全局模式：把已接住的流量统一交给代理组

切换到全局模式后，正常的逐条分流规则不再承担主要出口选择。已经进入 Mihomo 的流量会统一交给 GLOBAL（全局出口策略组）。

注意关键词仍然是“已经进入 Mihomo”。

如果系统代理没有接住某个应用，TUN 也没有接住它，那么这个应用可能继续直连。仅仅把按钮切成“全局”，不能凭空接管整台电脑。

全局模式什么时候有用

全局模式适合做短时间对照测试。

例如，某个海外网站在规则模式打不开：

• 切换全局后可以打开：远程节点大概率可用，问题更可能出在分流规则；
• 切换全局后仍然打不开：继续检查节点、DNS、协议连接或目标网站；
• 浏览器可以打开，但某个应用仍然不行：继续检查这个应用是否进入 Mihomo。

为什么不建议长期无脑使用全局模式

所有已接住的流量都绕到远程节点，可能造成：

• 中国网站绕远路，延迟反而更高；
• 本地服务误判登录地区；
• 视频和下载消耗更多节点带宽；
• 公司内网、NAS 或路由器页面访问异常；
• 原本应该直连的服务被远程出口影响。

之前 UUMit（当时测试的中国网站名称）的案例就是典型情况：全局模式强制请求绕到美国 DMIT，再返回中国源站，最终出现 TLS 超时；规则模式允许中国网站直连后恢复正常。

3. 直连模式：让已接住的流量暂时不用远程节点

直连模式会让已经进入 Mihomo 的流量统一使用本地网络，不经过 DMIT-VPS。

它不等于：

• 退出 Clash Verge；
• 停止 Mihomo；
• 关闭系统代理；
• 关闭 TUN。

请求仍然可能先进入 Mihomo，只是 Mihomo 最后选择本地网络作为出口。

直连模式什么时候有用

它适合做另一组对照测试：

• 直连能打开、代理打不开：优先检查节点、代理规则或远程出口；
• 直连也打不开：问题可能在本地网络、DNS、目标网站或应用自身；
• 关闭系统代理后能打开，但直连模式打不开：可能是 Mihomo 内部 DNS、规则处理或本地端口链路存在问题。

直连模式也是临时“保留 Mihomo 运行，但暂停使用远程节点”的方式。

4. 三种模式怎样配合排查

可以用下面的顺序快速缩小问题范围：

规则模式失败
→ 切换全局模式测试远程节点
→ 再切换直连模式测试本地网络
→ 对比三个结果

测试结果	更可能的问题方向
规则失败，全局成功	分流规则或策略组选择
规则失败，直连成功	代理节点、代理规则或远程出口
全局和规则都失败，直连成功	远程节点、代理协议或目标服务限制
三种模式都失败	本地网络、DNS、应用、Mihomo 入口或目标网站
浏览器成功，某个应用始终失败	该应用没有进入 Mihomo，或使用了不同网络协议

切换模式后，最好重新加载页面或重新建立连接。已经存在的长连接可能继续沿用旧出口，导致测试结果混在一起。

八、运行状态：流量、连接和网站测试

先看整张运行状态卡。上半部分是最近 10 分钟的流量曲线，下半部分是当前速度、活跃连接、累计流量和内存占用。

这张图要看什么

曲线回答“什么时候传了较多数据”，六张数字卡回答“此刻速度多少、当前连接多少、累计处理多少、内核用了多少内存”。这些都是 Mihomo 看到的运行数据，不等于整台 Mac 的全部网卡统计。

1. 曲线图

首页流量卡片显示的是 Mihomo 当前实际处理到的流量，不是整台 Mac 网卡上的全部流量。

如果某个应用绕过了系统代理，而且 TUN 也没有接住它，这个应用的流量可能不会出现在这里。

下面把曲线单独放大。蓝色尖峰明显高于橙色曲线，说明截图这 10 分钟里下载活动比上传活动更突出。

这张图要看什么

横轴是时间，纵轴是每个时刻传输的数据量；蓝色是下载，橙色是上传。尖峰只表示那一刻传输量增大，不代表延迟、丢包或带宽上限发生了同样变化。

截图中的曲线显示最近 10 分钟：

• 橙色：上传。
• 蓝色：下载。
• 尖峰：某一刻传输了较多数据。

点击“10 分钟”可以在不同时间范围之间切换；点击图表可以切换平滑曲线和直线。

图表出现尖峰，只表示某一刻传输的数据量增加，不代表延迟突然升高，也不代表网络发生故障。

图表接近零也不等于节点断开。电脑暂时没有下载网页、视频或文件时，流量本来就会很低。

底部小字主要属于图表自身的绘制信息：

• Points（数据点数量）：图表当前显示的数据点数量。
• Compressed（压缩后的缓冲数据量）：内部压缩缓冲区的数据量。
• FPS（每秒绘制帧数）：图表刷新帧率。
• Smooth（平滑曲线模式）：当前使用平滑曲线。

这些是图表渲染信息，不是网络质量指标。

2. 上传速度、下载速度

下面六张数字卡使用了三类完全不同的量：实时速度、累计流量和资源占用。先不要只看数字大小，要先看每张卡的名称与单位。

这张图要看什么

KB/s 是实时传输速度，GB 是本次运行期间累计处理的数据量，MB 是内核当前占用的内存；“101”是逻辑连接数量。这四类含义不能相互换算。

16.0 KB/s 和 27.8 KB/s 是截图那一刻的实时速度。

KB/s 表示每秒传输了多少千字节。宽带套餐经常使用 Mbps（兆比特每秒）标注，两者不能直接把数字一比一比较，因为 1 字节等于 8 比特。

最重要的是：这里显示的是“此刻正在使用多少速度”，不是“这条网络最多能跑多快”。

例如，宽带最高能下载 500 Mbps，但当前只打开一个文字网页，Clash Verge 显示几十 KB/s 完全正常。

这两个数字也不是节点延迟：

• 速度表示单位时间传输了多少数据；
• 延迟表示一个请求往返需要等待多久；
• 带宽表示这条连接理论或实际能够承载的数据量上限。

高速下载需要足够带宽，但带宽大不代表每个请求的延迟一定低。

3. 活跃连接 101

这表示 Mihomo 当时正在跟踪 101 条逻辑网络连接。

它不代表 101 台设备，也不代表 101 个软件。

一个网页可能同时建立几十条连接，用来加载：

• 网页正文；
• 图片；
• 字体；
• 广告和统计接口；
• 视频分片；
• 后台通知；
• 第三方登录服务。

有些连接几秒就结束，有些 WebSocket 长连接会保持很久。数字不断上下变化属于正常现象。

真正需要注意的是：电脑明明没有做任何联网操作，活跃连接却长期异常增长，并且伴随高流量、内存持续上涨或陌生程序联网。这时才需要到“连接”页面按程序和域名逐项查看。

4. 上传量 16.1 GB（吉字节）、下载量 69.8 GB

这是当前 Mihomo 运行期间累计统计到的流量，通常会在内核重启后重新计算。

这部分通常统计 Mihomo 经手的流量，不只等于 DMIT-VPS 节点实际消耗的流量。通过 Mihomo 后走 DIRECT 的数据也可能进入内核统计。

它不一定等于：

• Mac 系统从开机以来的全部网卡流量；
• 宽带运营商统计的使用量；
• 订阅或服务器后台的计费流量；
• 网站最终收到的纯文件大小。

服务商可能计算协议开销、上行流量、计费倍率或采用自己的统计周期。因此，这张卡适合观察当前 Mihomo 会话的大致使用量，不适合直接拿来核对账单。

5. 内核占用 41.7 MB

这表示 Mihomo 当前使用了约 41.7 MB 内存，不是磁盘空间，也不是流量。

规则数量、活跃连接、DNS 缓存和正在转发的数据都会影响内存占用。数字在一定范围内波动很正常。

判断是否异常不要只看某个瞬间，而要看：

• 内存是否长时间只涨不降；
• 是否同时出现卡顿或内核崩溃；
• 重启 Mihomo 后是否恢复；
• 日志中是否有反复报错；
• 是否加载了非常大的规则集。

截图中的 41.7 MB 只能说明当时的瞬时占用，不能单独说明内核性能好坏。

6. 网站测试

Apple（苹果公司官网）、GitHub（代码托管网站）、Google、YouTube（视频网站）是预设测试地址。

这张图要看什么

四张卡片分别测试四个预设网址，右上角网络图标用于批量测试，加号用于增加自定义地址。这里显示的是目标连通性入口，不是宽带测速器。

点击每个“测试”会发起一次连接测试，并显示耗时。右上角两个按钮分别是：

• 网络图标：测试全部网站。
• 加号：添加自定义测试网站。

测试结果通常以 ms（毫秒）显示。它反映的是测试请求当时完成连接所需的大致时间，不是下载速度，也不等于传统网络工具只测往返时间的纯延迟。

测试中可能包含：

• 域名解析；
• 建立 TCP 或 QUIC 连接；
• TLS 握手；
• 目标服务器响应；
• 当前规则和节点带来的绕行时间。

所以两个网站的测试数字不同，不一定是节点忽快忽慢，也可能是目标网站距离、服务器负载和连接复用情况不同。

测试成功说明什么

测试成功通常只能说明：

• 测试 URL（统一资源定位符，也就是网址）在当时能够建立连接；
• 当前网络链路至少可以到达该测试目标；
• 测试没有在设定时间内超时。

它不能证明：

• 视频一定可以稳定播放；
• 大文件下载一定很快；
• 账号一定允许登录；
• 网站不会触发地区或风险控制；
• 其他应用一定使用了同一条网络路径。

测试超时说明什么

超时只表示测试没有在规定时间内成功结束，可能原因包括：

• 当前节点无法连接；
• 域名解析失败；
• 规则把测试请求送到了错误出口；
• TLS 握手失败；
• 目标网站暂时不响应；
• 本地防火墙或网络限制；
• 测试地址本身不适合当前网络。

不要看到一个红色“超时”就直接判断整条代理失效。应该同时测试其他网站，并查看“连接”和“日志”页面。

怎样添加自定义测试地址

自定义地址应该选择长期稳定、支持 HTTPS、响应体较小的网站。不要用需要登录、会跳转很多次或本身经常限制访问的网页做基础连通性测试。

测试地址只能用来回答“这个目标现在能不能较快建立连接”。要测试真实业务，就应该直接在对应应用里完成一次实际操作。

7. 怎样把流量、连接和测试一起看

三个页面各自回答不同问题：

位置	它回答什么
流量卡片	Mihomo 此刻处理了多少数据
连接页面	哪个程序访问了什么、命中什么规则、走哪个出口
网站测试	某个预设地址当时能否建立连接

三类信息应该按下面的顺序互相验证：

flowchart LR
    T["网站测试<br/>快速判断目标能否连接"] --> C["连接页面<br/>核对真实应用、规则和节点"]
    C --> I["IP 信息<br/>核对检测请求的出口身份"]
    I --> B["回到真实业务<br/>测试登录、播放或下载"]

网站测试给出的是快速信号，连接页面提供真实路径证据，IP 卡片只核对一次检测请求的出口；最终仍要回到实际应用验证业务是否正常。

例如，YouTube 测试成功，但浏览器仍打不开视频：

1. 先在“连接”页面确认浏览器访问的真实域名是否出现；
2. 查看这些连接命中了 DIRECT 还是 PROXY；
3. 确认最终节点是不是预期的 DMIT-VPS；
4. 再检查浏览器、账号地区、Cookie（网站保存在浏览器中的会话数据）和网站自身限制。

首页测试只是快速信号，“连接”记录才是判断真实应用流量路径的主要证据。

九、出口身份：IP 信息

这张卡会主动访问一个 IP 查询服务，让查询服务回答：“刚才这次请求是从哪个公网 IP 过来的？”

因此，它显示的是这一次检测请求的出口身份，不是 Mac 的物理位置，也不是对整台电脑所有应用的统一证明。

这张图要看什么

左侧是国家、隐藏后的公网 IP 和自治系统编号；右侧是数据库识别到的服务商、组织、城市和时区；底部是自动刷新倒计时、国家代码与近似坐标。它描述的是出口服务器，不是本人位置。

1. United States（美国）

这说明当时的 IP 检测请求使用了美国出口。

结合下方的组织、自治系统和位置数据，可以判断这次检测经过了 DMIT 美国机房。

它不代表本人当时身处美国。网站看到的是代理服务器出口，人与电脑仍然可能在中国。

2. IP 和眼睛按钮

IP 默认隐藏，点击眼睛可以查看完整出口 IP。截图没有泄露完整地址。

公网 IP 可以被网站、服务器日志和 IP 数据库用于判断大致网络来源。分享截图时隐藏完整 IP，可以减少暴露固定服务器地址和网络基础设施信息的风险。

但隐藏 IP 只是在截图里遮住显示，不会阻止正在访问的网站看到这次连接的来源 IP。

3. AS906（自治系统编号 906）：自治系统与自治系统编号

AS（Autonomous System，自治系统）是互联网中独立管理一组网络和路由策略的单位。

ASN（Autonomous System Number，自治系统编号）是分配给这个网络单位的号码。AS906 就是“自治系统编号 906”的常见写法。

可以把互联网想成许多大型园区拼在一起：

• IP 是园区里的具体门牌号；
• AS 是负责管理一批门牌和道路的园区；
• ASN 是这个园区在互联网路由系统里的编号。

AS906 表示这段出口 IP 由对应自治系统发布和管理，不是 DMIT 某台 VPS 的编号，也不能单靠它定位到某一台物理服务器。

4. 服务商 Unknown（未知）

这表示检测接口没有返回 ISP（Internet Service Provider，互联网服务提供商）字段，不代表代理坏了。

下面的组织已经识别为 DMIT Cloud Services（DMIT 云服务组织名称），所以仍然能判断这是 DMIT 的机房出口。

不同 IP 数据库的数据来源和更新速度不同。同一个 IP 在另一个查询网站上，可能显示不同的服务商名称、城市或用途分类。

5. 位置：Los Angeles, California（美国加利福尼亚州洛杉矶）

这是 IP 数据库推测的机房位置，不是本人真实位置，也不是 GPS（全球定位系统）定位。

IP 数据库通常根据运营商登记、网络路由、商业数据和历史记录推测位置。机房搬迁、IP 重新分配或数据库更新不及时，都可能导致城市显示不准确。

判断代理是否使用了预期国家时，国家和自治系统通常比精确到街道或坐标更有参考价值。

6. 时区：America/Los_Angeles（洛杉矶时区标识）

这是该 IP 地理数据对应的时区，不是 Mac 当前设置的上海时区。

网站可能把 IP 推测时区、浏览器报告时区、账号历史地区和语言设置放在一起判断访问环境。只改变出口 IP，不会自动把 Mac 的系统时区、语言和账号资料全部改成美国。

7. 国家代码与坐标：US（美国国家代码），-118.27，34.05

这分别是国家代码、经度和纬度，同样只是 IP 数据库的近似结果。

这些坐标通常指向城市或机房附近的代表点，不是当前 Mac 的实时定位，也不能替代 GPS 或地图定位权限。

8. 自动刷新 230s（230 秒）

IP 卡片每 300 秒自动刷新一次。截图时距离下一次刷新还有约 230 秒。右上角刷新按钮可以立即重查。

切换节点或模式后，可以点击刷新按钮重新检测。但旧连接可能继续使用之前的出口，所以最好重新打开页面或重新建立连接后再看。

9. IP 卡片能证明什么，不能证明什么

它能帮助确认：

• 检测请求是否使用了预期国家的出口；
• 出口 IP 是否发生变化；
• 网络组织是否接近预期的 DMIT；
• 规则或节点切换后，检测请求的出口是否改变。

它不能单独证明：

• 每个应用都使用相同出口；
• 所有域名都命中相同规则；
• DNS 一定没有泄漏；
• 人已经获得完全匿名；
• 网站无法通过账号、Cookie、浏览器特征或行为识别用户；
• 显示的城市和坐标绝对准确。

10. 怎样确认某个具体应用的出口

如果只想确认浏览器，可以在该浏览器里打开可信的 IP 查询网站，再到 Clash Verge“连接”页面找到对应请求。

如果想确认另一个应用：

1. 先清空或记住当前连接列表；
2. 在目标应用中发起一次明显的新请求；
3. 回到“连接”页面查找对应进程、域名或目标 IP；
4. 查看它命中的规则和最终节点；
5. 如果应用自身能显示出口地区，再与连接记录交叉验证。

首页 IP 卡片、目标应用里的实际结果和 Mihomo 连接记录三者一致时，结论才更可靠。

十、软件本身是否正常：Clash 信息与系统信息

这两张卡不是用来判断网站内容，而是用来确认 Clash Verge、Mihomo、本地端口和操作系统这几层是否正常配合。

1. Clash 信息卡

先看 Clash 信息卡的完整字段。这里把代理核心、本地入口和运行统计放在一起。

这张图要看什么

v1.19.17 Mihomo 是代理核心版本，127.0.0.1:7897 是系统代理指向的本机地址，7897 是 Mihomo 实际监听的混合端口，129:27:32 是本次内核运行时间，14 是顶层规则数量。

内核版本 v1.19.17

这是截图当时 Mihomo 代理核心的版本，可以把它理解成网络发动机的版本。

Mihomo 负责：

• 监听本地代理端口；
• 接收系统代理或 TUN 送来的流量；
• 解析 DNS；
• 匹配规则；
• 选择策略组和节点；
• 与远程代理服务器通信；
• 统计连接和流量。

内核版本和 Clash Verge 界面版本不是同一个数字。界面可以更新，内核也可以单独更新；排查兼容性问题时，两者都要记录。

系统代理地址 127.0.0.1:7897

这是 macOS 系统代理当前指向的地址，表示遵守系统代理的应用应该把请求送到本机 7897 端口。

它描述的是“系统准备把请求送到哪里”。

混合代理端口 7897

这是 Mihomo 实际等待接收 HTTP 和 SOCKS 等代理请求的本地端口。

它描述的是“Mihomo 在哪里等待请求”。

这两个字段虽然都显示 7897，含义并不重复：

macOS 系统代理地址
→ 负责指路：把请求送去 127.0.0.1:7897
 
Mihomo 混合代理端口
→ 负责接收：在本机 7897 端口等待请求

两边号码一致，请求才能正常交接。

如果系统代理仍然指向 7897，但 Mihomo 改成监听另一个端口，应用就会把请求送到错误窗口，常见结果是所有遵守系统代理的网站都打不开。

反过来，Mihomo 正常监听 7897，但系统代理没有开启，普通应用也不会因为端口存在就自动把请求送过来。

运行时间 129:27:32

这表示截图当时这次 Mihomo 运行已经持续约 129 小时、27 分钟、32 秒，大约是 5 天 9 小时。

它不是：

• Mac 的开机时间；
• 这台电脑的总使用时间；
• VPS 已运行多久；
• 订阅还剩多久。

内核重启、应用重启或某些配置切换可能让运行时间重新开始计算。

运行时间长本身不是问题。如果同时出现内存持续上涨、规则更新不生效或连接异常，重启内核可以作为排查步骤，但不能用重启代替定位根因。

规则数量 14

这表示当前配置加载了 14 条顶层规则。

它不等于只覆盖 14 个网站。一条顶层规则可能引用一个包含成千上万个域名或 IP 的规则集。

规则数量也不代表配置质量：

• 规则多，不一定更准确；
• 规则少，不一定功能简单；
• 真正重要的是顺序、匹配条件、引用的规则集和最终出口。

要判断某个网站为什么走 DIRECT 或 PROXY，仍然应该看“连接”页面中的实际命中结果。

2. 系统信息卡

系统信息卡描述的是运行 Clash Verge 的这台 Mac，以及软件怎样随系统工作。

这张图要看什么

这台机器当时报告 Darwin macOS 26.5.1，没有开启登录自启，使用服务模式运行；最后检查软件更新的时间是 2026/7/24 16:06:00，Clash Verge 界面版本是 v2.4.4。

Darwin（macOS 的底层系统核心名称）：macOS 26.5.1

Darwin 是苹果操作系统的底层系统名称，26.5.1 是截图当时返回的系统版本信息。

这个字段主要用于排查平台兼容性。例如，TUN 权限、系统代理写入方式、窗口行为和后台服务，在 macOS、Windows（微软桌面操作系统）和 Linux 上可能不同。

开机自启：未启用

这表示截图当时 Clash Verge 没有设置为登录 Mac 后自动打开。

不开机自启不代表错误，但要留意启动顺序：

Mac 已经联网
→ 系统代理可能仍指向 127.0.0.1:7897
→ Clash Verge 和 Mihomo 尚未启动
→ 7897 暂时无人接收
→ 遵守系统代理的应用可能打不开网页

这不是每次开机都必然发生，但出现“刚开机无法联网，启动 Clash Verge 后恢复”时，应优先检查这一层。

如果需要开机自启，目标不是单纯让界面弹出来，而是确保 Mihomo 已经成功启动、本地端口开始监听，然后再让应用使用系统代理。

运行模式：服务模式

服务模式表示 Clash Verge 已安装一个具有必要系统权限的后台辅助服务。

它主要帮助完成：

• 启动需要较高权限的 Mihomo；
• 创建 TUN 虚拟网卡；
• 修改系统路由；
• 减少反复输入管理员密码；
• 在界面程序之外协助维持需要权限的后台操作。

服务模式不是代理模式。下面这些推断都不成立：

服务模式 = TUN 已开启        错
服务模式 = 所有流量走代理    错
服务模式 = 当前使用全局模式  错

截图中的真实组合正好可以证明这一点：

服务模式：开启
系统代理：开启
TUN：关闭
代理模式：规则

后台辅助服务可以独立于主界面进程存在。关闭 Clash Verge 窗口，不一定等于后台服务和 Mihomo 已经全部退出；需要结合菜单状态、进程和端口判断。

最后检查更新

2026/7/24 16:06:00 表示最后一次检查 Clash Verge 新版本的时间。

它不是：

• 订阅更新时间；
• 节点更新时间；
• Mihomo 运行开始时间；
• 配置文件修改时间。

“检查更新”只是在询问有没有新的软件版本，不代表已经完成下载和安装。

Verge 版本 v2.4.4

这是截图当时 Clash Verge 图形界面和管理程序的版本号。

到这里一共有三个容易混淆的版本：

显示内容	它属于谁	主要影响什么
Verge v2.4.4	Clash Verge 界面和管理程序	页面、开关、订阅管理、后台服务调用
Mihomo v1.19.17	代理核心	协议、规则、DNS、TUN、流量转发
macOS 26.5.1	操作系统	权限、路由、系统代理和平台兼容性

左上角 NEW 通常表示 Clash Verge 检测到可用的新版本，不等于订阅有新节点，也不自动说明 Mihomo 内核版本已经更新。

升级前可以先查看更新说明，并保留当前可用配置。升级后如果出现异常，应同时记录升级前后的 Verge 版本、Mihomo 版本、系统版本和报错日志。

十一、日常使用与固定排查顺序

理解完整篇后，日常使用其实不需要盯住每个数字。关键是分清六层：

flowchart LR
    A["应用发起请求"] --> B{"系统代理或 TUN<br/>是否接住"}
    B --> C["Mihomo"]
    C --> D{"命中哪条规则"}
    D --> E{"交给哪个策略组"}
    E --> F{"最终选择哪个节点<br/>或 DIRECT"}
    F --> G["远程节点或本地网络"]
    G --> H["目标网站或服务"]

1. 每次打开后，用 30 秒看这七项

1. 配置： 当前是不是 DMIT-Reality。
2. 入口： 系统代理或 TUN 是否按需要开启。
3. 模式： 日常是否保持规则模式。
4. 策略组： PROXY 是否选中预期的 DMIT-VPS。
5. 内核： Mihomo 是否正常运行，本地端口是否仍是 7897。
6. 出口： IP 卡片是否显示预期国家和网络组织。
7. 真实连接： 目标应用的请求是否出现在“连接”页面，并命中预期出口。

这七项不是每次都要逐一研究。日常网络正常时看前四项即可；出现异常时再继续向后检查。

2. 固定按照六层定位问题

第一层：本地网络本身能不能用

临时关闭系统代理和 TUN，确认 Mac 能否使用本地网络打开普通网站。

• 本地直连也不行：先处理 Wi-Fi、宽带、DNS 或目标网站问题；
• 本地直连正常：再继续检查 Clash Verge。

第二层：Mihomo 有没有正常运行

检查：

• Clash 信息是否能读取；
• 混合代理端口是否为 7897；
• 日志是否出现端口占用、配置错误或内核退出；
• 系统代理地址和 Mihomo 监听端口是否一致。

如果入口指向一个没有程序监听的端口，所有后续规则和节点都没有机会工作。

第三层：目标应用有没有进入 Mihomo

在目标应用中重新发起请求，然后看“连接”页面。

• 能看到请求：说明入口基本正常；
• 完全看不到：检查应用是否忽略系统代理，是否需要手动代理或 TUN；
• 浏览器能看到、游戏看不到：通常是接管方式差异，不是节点一定坏了。

第四层：请求命中了什么规则

连接记录中重点看：

• 目标域名或 IP；
• 命中的规则；
• 结果是 DIRECT、PROXY 还是 REJECT；
• 是否命中了过于宽泛的前置规则；
• MATCH 兜底最终交给谁。

规则错误时，换节点往往没有用，因为请求可能根本没有被交给那个节点。

第五层：策略组最终选了哪个出口

规则写着 PROXY，只表示把请求交给 PROXY 策略组。还要继续确认这个组当前选中的是：

• DMIT-VPS；
• 另一个节点；
• 另一个自动选择策略组；
• DIRECT；
• 已经失效的出口。

策略组就像菜单，节点才是最终选中的菜。

第六层：远程节点和目标服务是否正常

入口、规则和策略组都正确后，再检查：

• 节点能否建立连接；
• TLS 或 REALITY 握手是否成功；
• DNS 是否返回可用地址；
• VPS 是否在线；
• 目标网站是否限制该机房 IP；
• 账号是否触发地区或安全风控；
• 视频、下载等真实业务是否有足够带宽。

延迟测试成功，只能证明基础连接在当时可用，不能替代真实业务测试。

3. 常见现象与最可能的检查方向

现象	优先检查
打开系统代理后所有网页都打不开	Mihomo 是否运行、7897 是否监听、端口是否一致
浏览器能代理，命令行或游戏不能	应用是否遵守系统代理，是否需要 TUN
中国网站变慢或超时	是否误用全局模式，规则是否把中国网站送到美国
海外网站打不开，中国网站正常	PROXY 节点、代理规则、DNS、远程握手
切换节点后 IP 没变化	旧连接、IP 卡未刷新、请求走 DIRECT、应用绕过 Mihomo
开启 TUN 后全网断开	权限、路由、DNS、其他 VPN 或防火墙冲突
网站测试成功，但真实应用失败	真实应用未进入 Mihomo、账号风控、应用协议或目标域名不同
延迟很低，但视频仍然卡	带宽、丢包、拥塞、服务器负载或视频源限制
关闭系统代理后仍显示代理 IP	TUN、应用内部代理、浏览器扩展或旧长连接
内存数字持续上涨	活跃连接、规则集、DNS 缓存、反复报错或内核异常

4. 网络完全混乱时的安全恢复顺序

不要同时乱切五六个开关。按照下面的顺序，一层一层恢复：

1. 关闭 TUN；
2. 关闭系统代理；
3. 确认 Mac 本地直连网络正常；
4. 启动或重启 Mihomo，确认 7897 正常监听；
5. 只开启系统代理，保持规则模式；
6. 确认 PROXY 选择 DMIT-VPS；
7. 用浏览器测试一个中国网站和一个海外网站；
8. 到“连接”页面核对两者的规则和出口；
9. 刷新 IP 卡片；
10. 只有明确存在某个应用无法被系统代理接住时，再开启 TUN。

这样做的目的，是每次只增加一个变量。哪一步开始出错，就从哪一层继续查。

5. 最后把整套逻辑压缩成三句话

系统代理或 TUN 决定“哪些流量进入 Mihomo”。

规则、全局或直连模式决定“进入后应该交给谁”。

策略组和节点决定“代理流量最终从哪台服务器出去”。

以后遇到“某个软件没有被代理”或“某个网站打不开”，不要只盯着首页开关。固定检查：请求有没有进入 Mihomo；进入后命中了哪条规则；规则交给哪个策略组；策略组最终选择哪个出口；出口能否连接目标服务。