做跨境电商、社媒多账号或广告验证时，你往往不只需要「换 IP」——还需要 按域名/App 分流：业务流量走代理，本地支付或内网工具直连。Clash 系客户端（Clash Verge、Clash Meta 等）正是为这种 规则型代理调度 设计的。
很多人第一次用 Clash，卡在「规则/Global/TUN 该开哪个」「链式代理前后顺序怎么排」。本文只讲 原理与配置结构，桌面端完整操作流程见 Clash Verge 桌面端配置指南，手机端完整操作流程见 Clash Meta Android 配置指南。
目录
- 1. Clash 不是 VPN，是规则型代理调度器
- 2. 配置文件四要素
- 3. 代理协议层：Clash 常见 type
- 4. 三种运行模式与流量接管方式
- 5. 链式代理原理：前置节点 + 住宅落地
- 6. 常见问题
- 7. 结语
1. Clash 不是 VPN，是规则型代理调度器
传统 VPN 通常建立一条加密隧道，把 全部 流量送进远端网关。Clash（及其主流分支 Mihomo）做的事情不同：它读取一份 YAML 配置，维护一组 出站（outbound） 节点，再按 规则（rules） 决定「这一连接走哪个 outbound、还是直连」。
可以把它理解成三层：
- 入站（inbound）：系统代理、TUN 虚拟网卡、或本地 SOCKS/HTTP 端口，负责接收本机应用的连接。
- 路由（rules + proxy-groups）：对每条连接做匹配，选中策略组里的某个节点，或
DIRECT（直连）。 - 出站（proxies）：真正发起 TCP/UDP 连接的一层——可能是 HTTP 代理、SOCKS5、或 SS/VMess 等协议节点。
因此，Clash 的核心价值是 可编程的分流，而不是「一键全隧道」。这对需要混合流量的业务场景尤其重要：例如浏览器和特定 App 走代理，而本地 ERP 或银行客户端保持直连。
2. 配置文件四要素
Clash/Mihomo 的配置文件通常是 YAML。无论客户端 UI 如何包装，底层都围绕四个部分展开。
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. proxy-groups：策略组
策略组把多个节点组织成「可选出口」或「自动选择逻辑」。常见类型：
| 类型 | 行为 |
|---|---|
select |
手动选一个子节点或子组 |
url-test |
按 URL 测延迟，自动选最快 |
fallback |
按顺序尝试，失败则切下一个 |
load-balance |
负载均衡到多个节点 |
relay |
链式串联：按 proxies 数组顺序，流量依次经过各 hop |
relay 组是实现多跳的一种声明式方式；另一种是单个节点上的 dialer-proxy 字段（见下文链式代理章节）。二者不要混为一谈：relay 是组类型，dialer-proxy 是节点级属性。
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— 兜底规则，通常放最后
理解「首条命中」很关键：如果把 MATCH 写在中间，后面的规则永远不会执行。改规则后若「看似没生效」，先检查顺序，再检查 DNS 缓存（见 DNS 小节）。
4. dns（可选）：解析方式影响分流
DNS 配置决定域名如何解析，进而影响 IP-CIDR / GEOIP 规则是否按预期工作。Mihomo 常见两种 enhanced-mode：
fake-ip：对匹配域名返回虚假 IP（如 198.18.0.0/16 段），连接时再还原真实目标。优点是解析快、规则易命中；部分依赖真实 DNS 响应的应用可能需要额外调优。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 配置中的 mode 为准）：
| 模式 | 行为 | 典型场景 |
|---|---|---|
| 规则（Rule） | 按 rules 分流，命中走代理组，未命中看兜底 |
日常混合流量 |
| 全局（Global） | 默认全部走选定策略组 | 需要整机浏览器统一出口 |
| 直连（Direct） | 不走代理 | 临时关闭、排查故障 |
系统代理 vs TUN
- 系统代理：告知操作系统「HTTP/HTTPS 走某本地端口」。多数浏览器会遵守；部分游戏、模拟器、命令行工具、原生 SDK 不会，仍可能直连。
- TUN（虚拟网卡）：在系统网络栈更底层接管 IP 包，由 Clash 决定转发到 outbound 还是 DIRECT。覆盖范围更广，但可能带来额外 CPU/延迟开销，且与已有虚拟网卡、复杂网段环境冲突时需排查。
因此：全局模式 ≠ 所有程序都走代理。只有系统代理时，「全局了但某 App 仍显示本地 IP」是预期现象，不是节点坏了——需要 TUN 或该 App 自身的代理设置。
5. 链式代理原理：前置节点 + 住宅落地
链式代理（proxy chain） 指流量依次经过多个 outbound，再访问目标站点。典型业务拓扑：
本机 → 前置节点（低延迟、稳定中转）→ 住宅 IP（最终出口）→ 目标网站
目标网站看到的 IP 是 最后一跳 的地址。前置节点负责连通性与延迟；住宅代理负责出口信誉与地域一致性——适合平台注册、账号环境隔离、广告落地页验证等。
Mihomo 里实现链式常见两种方式：
1. 节点级 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 会对不上预期地区。
2. relay 策略组
proxy-groups:
- name: "Chain-US"
type: relay
proxies:
- HK-Relay
- IPWeb-US-Residential
数组顺序即 hop 顺序：先 HK-Relay，再 IPWeb-US-Residential。UI 客户端（如 Clash Verge）也提供可视化「链式代理」组合，底层仍是上述逻辑。
6. 常见问题
Q1：规则模式里，某个网站没走代理怎么办？
先查三点：① 该域名是否被更靠前的 DIRECT 规则命中；② 是否只有系统代理、而该 App 不读系统代理；③ DNS 是否为 fake-ip 导致 IP 规则与预期不符。需要该 App 必走代理时，可尝试 TUN 模式。
Q2：全局模式开了，为什么模拟器还是本地 IP？
全局模式通常仍依赖 系统代理 生效范围。模拟器、部分游戏使用独立网络栈，不读取系统代理设置。这是 流量接管层级 问题，不是节点失效。TUN 把 IP 层接管后，覆盖会明显扩大。
Q3：relay 和 dialer-proxy 有什么区别？
relay 是 策略组类型，把多个已定义节点按顺序串联成一个可选出口。dialer-proxy 是 单个 proxy 条目上的字段，指定「连这个节点前先经谁拨号」。两者都能做链式，配置入口不同；不要写成「relay 等于 dialer-proxy」。
Q4：链式代理顺序反了会怎样？
目标站看到的 IP 是 最后一跳。若住宅节点在前、前置节点在后，出口可能变成前置节点的 IP，地域与 ASN 与购买的住宅线路不一致。连接后务必用 IP 查询工具核对 ASN 与地区。
Q5：手动加的住宅节点，订阅更新会丢吗？
在 同一配置文件 里通过编辑 proxies 追加的节点，一般不会因「刷新订阅」而删除——前提是客户端合并策略是「追加/保留本地修改」，而非整文件覆盖。不同客户端行为略有差异；重要节点建议备份 YAML。
7. 结语
Clash/Mihomo 的本质是：用 YAML 描述 outbound 集合，用 rules 做首条命中路由，用 proxy-groups 组织选择与链式。搞清 Rule/Global/Direct、系统代理与 TUN 的差异，以及 dialer-proxy / relay 的 hop 顺序，再去做客户端配置会少踩一半坑。
- 下一步（桌面实操）：Windows 链式代理与 TUN 实操 — 按 Clash Verge 逐步配置。
- 手机端单层住宅节点：Android 导入 ipweb 住宅 IP 教程 — Clash Meta 分步配置。
- 需要住宅出口：动态住宅代理 适合轮换与地域定向；静态住宅代理 适合长期绑定。可先 查看定价与试用。
