Clash/Mihomo 原理详解：配置结构、分流规则与链式代理

Q: 全局模式开了，为什么模拟器还是本地 IP？

Global 只决定已经进入 Mihomo 的流量统一走哪个代理，并不会扩大流量接管范围。模拟器、部分游戏或应用如果不读取系统代理，流量可能没有进入 Mihomo；这类场景通常需要 TUN，或在应用自身配置代理。

Q: dialer-proxy 可以填写策略组名称吗？

可以。Mihomo 官方文档说明，dialer-proxy 的值可以是一个代理节点名称，也可以是一个 proxy-group 名称。当前节点建立连接时，会先通过该节点或策略组指定的出站建立拨号链路。

Q: 开启 TUN 后，DNS 劫持一定会生效吗？

不一定。Mihomo 官方文档说明，TUN 的 DNS hijack 仍受平台网络机制影响，例如 Android 开启 Private DNS 时无法自动劫持相关 DNS 请求，Windows/macOS 对发往本地网络的 DNS 请求也存在限制。

做跨境电商、社媒账号运营或广告验证时，网络环境往往需要同时处理多种流量：浏览器或指定 App 经代理访问，本地支付、内网工具和部分系统服务则保持直连。Clash/Mihomo 的作用，就是按照既定规则对这些连接进行 分流与调度，再交给不同的出站节点处理。

Clash 的理解门槛，主要来自几个经常被混在一起的概念：规则、Global、TUN，以及链式代理的前后关系。它们分别涉及路由策略、流量接管和出站链路；层级没有理清时，即使配置项本身没有写错，实际流量也可能与预期不同。本文只梳理 原理与配置结构，桌面端完整操作流程见 Clash Verge 桌面端配置指南，手机端完整操作流程见 Clash Meta Android 配置指南。

1. Clash 不是 VPN，是规则型代理调度器

传统 VPN 通常建立一条加密隧道，把全部流量送进远端网关。Clash（及其主流分支 Mihomo）做的事情不同：它读取一份 YAML 配置，维护一组 出站（outbound） 节点，再按 规则（rules） 决定「这一连接走哪个 outbound、还是直连」。

Clash Mihomo 流量接入、规则调度与代理出口工作原理示意图 — 图1：Clash/Mihomo 从流量接入、规则调度到代理或直连出口的工作原理

可以把它理解成三层：

入站（inbound）：系统代理、TUN 虚拟网卡、或本地 SOCKS/HTTP 端口，负责接收本机应用的连接。
路由（rules + proxy-groups）：对每条连接做匹配，选中策略组里的某个节点，或 DIRECT（直连）。
出站（proxies）：真正发起 TCP/UDP 连接的一层——可能是 HTTP 代理、SOCKS5、或 SS/VMess 等协议节点。

因此，Clash 的核心价值是 可编程的分流，而不是「一键全隧道」。这对需要混合流量的业务场景尤其重要：例如浏览器和特定 App 走代理，而本地 ERP 或银行客户端保持直连。

2. 配置文件四要素

Clash/Mihomo 的配置文件通常是 YAML。无论客户端 UI 如何包装，底层都围绕四个部分展开。

Clash Mihomo YAML 配置文件 proxies、proxy-groups、rules 和 DNS 四个核心部分示意图 — 图2：Clash/Mihomo 配置文件的四个核心部分：proxies、proxy-groups、rules 与 DNS

2.1 proxies：节点定义

每个节点至少包含：

name：显示名称，策略组和规则引用时用。
type：协议类型，如 http、socks5、ss、vmess、trojan 等（以当前 Mihomo 文档为准）。
server / port：目标地址与端口。
认证字段：HTTP/SOCKS5 常用 username / password（注意 YAML 字段名，不要与个别客户端的 user 混用）。

从 IPWeb dashboard 生成的动态住宅或静态住宅线路，多数以 HTTP 或 SOCKS5 形式填入 proxies。手动追加的节点与订阅拉取的节点 共存于同一列表，后续链式代理会引用这些 name。

2.2 proxy-groups：策略组

策略组把多个节点组织成「可选出口」或「自动选择逻辑」。常见类型：

类型	行为
`select`	手动选一个子节点或子组
`url-test`	按 URL 测延迟，自动选最快
`fallback`	按顺序尝试，失败则切下一个
`load-balance`	负载均衡到多个节点

策略组本身负责组织和选择出站节点；链式连接则由节点级的 dialer-proxy 建立，具体关系见下文链式代理章节。

2.3 rules：从上到下，首条命中

规则列表 按书写顺序 匹配，第一条命中的规则生效，后面的不再判断。常见规则类型：

DOMAIN,example.com,ProxyGroup — 精确域名
DOMAIN-SUFFIX,google.com,ProxyGroup — 后缀匹配
IP-CIDR,10.0.0.0/8,DIRECT — IP 段
GEOIP,CN,DIRECT — GeoIP 数据库（需配置）
PROCESS-NAME,chrome.exe,ProxyGroup — 按进程名（部分平台支持）
MATCH,ProxyGroup — 兜底规则，通常放最后

一个最小的分流结构可以写成：

rules:
  - DOMAIN-SUFFIX,example.com,ProxyGroup
  - GEOIP,CN,DIRECT
  - MATCH,ProxyGroup

这里先匹配指定域名，再判断中国大陆 IP 是否直连，最后由 MATCH 处理其余流量。理解「首条命中」很关键：如果把 MATCH 写在中间，后面的规则永远不会执行。改规则后若「看似没生效」，先检查顺序，再检查 DNS 缓存（见 DNS 小节）。

2.4 dns（可选）：解析方式影响分流

DNS 配置决定域名如何解析，进而影响 IP-CIDR / GEOIP 规则是否按预期工作。Mihomo 的 enhanced-mode 支持 fake-ip 与 redir-host，具体字段可参考 Mihomo DNS 官方文档：

fake-ip：由 Mihomo 返回 Fake IP 映射，并在后续连接阶段根据映射处理真实目标。部分依赖真实 DNS 响应的应用可能需要通过 fake-ip-filter 等配置调整。
redir-host：按真实 DNS 解析结果处理域名，客户端拿到的是实际解析出的 IP 地址。

DNS Leak 或「规则写了 DOMAIN 却仍直连」类问题，往往与 DNS 模式、以及是否启用 TUN 的 DNS 劫持有关，不能只看 rules 表面。

3. 代理协议层：Clash 常见 type

ipweb 住宅/静态线路在 Clash 里通常配置为：

socks5：通用性好，支持 TCP；UDP 取决于节点与客户端实现。
http：部分环境仅提供 HTTP 代理入口时使用。

订阅里常见的 ss（Shadowsocks）、vmess、trojan 等，是另一类加密传输协议，字段比 HTTP/SOCKS5 更多（cipher、uuid、sni 等）。本文不展开密码学细节；只需知道：Clash 的 type 决定 outbound 如何与远端握手，业务侧选 ipweb 节点时以 dashboard 给出的协议为准。

4. 三种运行模式与流量接管方式

客户端 UI 上的 规则 / 全局 / 直连，对应 Mihomo 的运行模式 rule、global、direct，具体定义见 Mihomo General 官方文档：

模式	行为	典型场景
规则（Rule）	按 `rules` 分流，命中走代理组，未命中看兜底	日常混合流量
全局（Global）	进入 Mihomo 的流量统一走 GLOBAL 中选定的代理或策略	希望已接管流量统一使用同一出口
直连（Direct）	进入 Mihomo 的流量直接连接目标	临时关闭、排查故障

Clash Mihomo Rule、Global 和 Direct 三种运行模式及流量路由关系示意图 — 图3：Clash/Mihomo 的 Rule、Global 与 Direct 三种运行模式

系统代理 vs TUN

系统代理：告知操作系统「HTTP/HTTPS 走某本地端口」。多数浏览器会遵守；部分游戏、模拟器、命令行工具、原生 SDK 不会，仍可能直连。
TUN（虚拟网卡）：在系统网络栈层面接管流量，再由 Mihomo 决定转发到 outbound 还是 DIRECT。覆盖范围通常比系统代理更广，DNS 劫持、自动路由等行为则取决于 TUN 配置与平台限制，详见 Mihomo TUN 官方文档。

运行模式与流量接管是两个层级：Rule / Global / Direct 决定流量进入 Mihomo 之后如何路由；系统代理 / TUN 决定哪些流量能够进入 Mihomo。因此，Global ≠ 所有程序都会自动进入代理链路。只有系统代理时，不读取系统代理的 App 仍可能直连，需要 TUN 或该 App 自身的代理设置。

5. 链式代理原理：前置节点 + 住宅落地

链式代理（proxy chain） 指流量依次经过多个 outbound，再访问目标站点。典型业务拓扑：

本机 → 前置节点（低延迟、稳定中转）→ 住宅 IP（最终出口）→ 目标网站

目标网站看到的 IP 是 最后一跳 的地址。前置节点负责连通性与延迟；住宅代理负责出口信誉与地域一致性——适合平台注册、账号环境隔离、广告落地页验证等。

当前 Mihomo 使用节点级 dialer-proxy 建立链式连接；旧版 relay 策略组已被官方标记为 deprecated。dialer-proxy 可以指向一个代理节点，也可以指向一个策略组，详见 Mihomo dialer-proxy 官方文档。

dialer-proxy 的链路关系

在 后置节点 的配置里指定 dialer-proxy: 前置节点name，表示「连接此后置节点时，先经前置节点拨号」。例如住宅节点经某个订阅里的香港节点中转：

proxies:
  - name: "HK-Relay"
    type: ss
    server: relay.example.com
    port: 443
    cipher: aes-256-gcm
    password: "example"

  - name: "IPWeb-US-Residential"
    type: socks5
    server: YOUR_GATEWAY
    port: YOUR_PORT
    username: YOUR_USER
    password: YOUR_PASS
    dialer-proxy: HK-Relay

此处 IPWeb-US-Residential 是落地；HK-Relay 是 拨号链路。顺序反了，出口 IP 会对不上预期地区。

6. 常见问题

Q1：Mihomo 分流规则为什么看起来没有生效？

先检查规则顺序：Mihomo 按从上到下的顺序匹配，前面的规则优先。再确认流量是否已经进入 Mihomo，以及 DNS 解析结果是否影响了 DOMAIN、IP-CIDR 或 GEOIP 等规则的判断。

Q2：全局模式开了，为什么模拟器还是本地 IP？

Global 只决定已经进入 Mihomo 的流量统一走哪个代理，并不会扩大流量接管范围。模拟器、部分游戏或应用如果不读取系统代理，流量可能没有进入 Mihomo；这类场景通常需要 TUN，或在应用自身配置代理。

Q3：dialer-proxy 可以填写策略组名称吗？

可以。Mihomo 官方文档说明，dialer-proxy 的值既可以是一个代理节点名称，也可以是一个 proxy-group 名称。当前节点建立连接时，会先通过该节点或策略组指定的出站建立拨号链路。

Q4：开启 TUN 后还需要系统代理吗？

两者属于不同的流量接管方式。TUN 在系统网络栈层面接管流量，通常不依赖应用读取系统代理；系统代理则只影响遵循系统代理设置的应用。实际客户端可以根据场景单独使用或组合使用。

Q5：开启 TUN 后，DNS 劫持一定会生效吗？

不一定。Mihomo 官方文档说明，TUN 的 dns-hijack 仍受平台网络机制影响。例如 Android 开启 Private DNS 时无法自动劫持相关 DNS 请求；Windows/macOS 对发往本地网络的 DNS 请求也存在限制。

7. 结语

Clash/Mihomo 的核心可以归纳为：用 YAML 描述 outbound 集合，用 rules 做首条命中路由，用 proxy-groups 组织出站选择，再通过 dialer-proxy 建立需要的链式连接。理解 Rule/Global/Direct 与系统代理/TUN 分属不同层级，再去看具体客户端配置，会更容易判断问题出在路由、接管还是出站链路。