Appearance
代理模式与智能分流:Rule vs Global vs TUN 模式深度剖析
导读:为什么开了代理之后微信/淘宝奇慢,甚至提示“异地登录”?为什么命令行里的
git clone或docker pull依旧超时报错?这些现象 99% 都是由于没有正确理解**代理模式 (Proxy Mode)与分流规则 (Routing Rules)**导致的。本教程将深入剖析主流内核的分流机制。
一、四大运行模式对比总览
以 Clash Verge Rev、Mihomo Party、Sing-box 等现代客户端为例,内核主要提供以下四种网络接管模式:
| 模式名称 | 中文定义 | 工作原理 | 适用场景 | 流量消耗与影响 |
|---|---|---|---|---|
| Rule (规则模式) | 智能分流 (默认推荐) | 根据预设的规则列表,国内网址走直连,海外受阻网址走代理节点 | 日常主力推荐,95% 时间保持此模式即可 | 最节省流量,国内网站(淘宝/B站/微信)不走代理,速度满血 |
| Global (全局模式) | 强制全量代理 | 绕过所有规则引擎,将设备所有的出站 HTTP/HTTPS 请求全部发往指定节点 | 临时排查规则失效、特定地区强校验业务(如锁定美区打折) | 消耗大量机场流量,访问国内网站延迟暴增,可能触发微信风控 |
| Direct (直连模式) | 完全放行 | 不经过任何节点中转,所有网络请求如同关闭代理软件 | 临时不需要翻墙或排查本地网络硬件故障 | 0 流量消耗,无法访问任何海外受限服务 |
| TUN (虚拟网卡模式) | 系统底层全局接管 | 在操作系统内核创建名为 tun0 的虚拟网卡,拦截包括 TCP/UDP/ICMP 在内的全栈流量 | 极客/开发者必备:接管终端命令行、Git、Docker、网游、未适配代理的应用 | 遵循 Rule 分流规则,但能抓取系统级顽固流量 |
mermaid
graph TD
AppTraffic["应用程序发出的网络请求"] --> CheckTUN{"是否开启 TUN 模式?"}
CheckTUN -->|是| TUN["虚拟网卡 (TUN) 强行捕获全栈 (TCP/UDP/ICMP)"]
CheckTUN -->|否| SysProxy["系统代理设置 (仅拦截遵循系统的 HTTP/Socks5 流量)"]
TUN --> Engine["分流规则引擎 (Routing Engine)"]
SysProxy --> Engine
Engine --> RuleCheck{"规则匹配优先级"}
RuleCheck -->|命中国内域名/GEOIP:CN| DirectOut["本地网卡直连出站 (Direct)"]
RuleCheck -->|命中OpenAI/Claude规则| AIServer["经由专属 AI 落地节点 (Proxy Group: AI)"]
RuleCheck -->|命中Netflix/YouTube规则| StreamServer["经由流媒体解锁节点 (Proxy Group: Streaming)"]
RuleCheck -->|所有规则未命中 (FINAL/MATCH)| DefaultProxy["默认代理节点出站 (Proxy Group: PROXY)"]二、为什么说 TUN 模式是程序员与重度玩家的“救星”?
1. 普通“系统代理”的致命缺陷
Windows 的“设置代理”或 macOS 的“网络偏好设置代理”,本质上只是在操作系统中写了一条环境变量配置。
- 遵守系统代理的软件:Chrome、Edge、Safari、Firefox 等常规浏览器;
- 无视系统代理的软件:
- Windows CMD、PowerShell、Linux Bash 终端;
git clone、npm install、pip install、docker pull;- Cursor、VS Code 插件市场、Android Studio SDK Manager;
- Steam / Epic / 暴雪国际服游戏客户端;
- WSL2 (Windows Subsystem for Linux)。
2. TUN 虚拟网卡如何一招破局?
当你在客户端中开启 TUN 模式 (Tun Mode) 并安装内核服务后:
- 客户端会在网络适配器列表中虚拟出一张物理网卡;
- 修改系统路由表,将默认网关(Default Gateway)的跃点数(Metric)调为最高优先级;
- 任何软件、任何端口、任何协议(TCP、UDP、DNS) 发出的数据包,在出物理网卡前都会被强行拽进 TUN 虚拟网卡;
- TUN 内核再根据你配置的分流规则,智能决定是本地放行还是加密出海。
推荐实践
在 Clash Verge Rev 或 Mihomo Party 中,日常使用时建议开启 “规则模式 (Rule)” + “TUN 模式” 组合。既享受了规则模式对国内网站的直连加速,又彻底解决了命令行和开发工具连不上外网的烦恼。
三、分流规则(Routing Rules)匹配机制解密
内核在收到一个网络请求时,会自上而下逐行检索规则集。只要命中其中任何一条,立即执行对应动作并退出匹配流程。
1. 常见的规则语法类型
yaml
rules:
# 1. 域名后缀匹配 (最常用):匹配该域名及其所有多级子域名
- DOMAIN-SUFFIX,openai.com,🤖 OpenAI
- DOMAIN-SUFFIX,chatgpt.com,🤖 OpenAI
- DOMAIN-SUFFIX,github.com,🚀 节点选择
# 2. 域名关键字匹配:只要包含关键字即命中
- DOMAIN-KEYWORD,netflix,🎬 奈飞流媒体
# 3. 完整绝对域名匹配:精准匹配单个子域
- DOMAIN,api.cursor.sh,🚀 节点选择
# 4. IP 掩码匹配:针对特定 IP 网段
- IP-CIDR,149.154.160.0/20,✈️ Telegram,no-resolve
# 5. 地理位置数据库匹配 (GeoIP):由 mmdb 离线库识别归属地
- GEOIP,CN,DIRECT
# 6. 兜底规则 (必须置于最底端):未被上述任何规则命中的流量走这里
- MATCH,🐟 漏网之鱼2. 规则书写的常见避坑陷阱
- 陷阱一:顺序颠倒
如果你把GEOIP,CN,DIRECT放在最顶部,那么国内云厂商反代给海外 CDN 的域名可能会被误判直连而无法访问。 - 陷阱二:缺失
no-resolve参数
在书写IP-CIDR规则时,若没有加上no-resolve,客户端会尝试先在本地把域名解析为 IP 再比对。如果本地 DNS 已经被 GFW 投毒污染,会导致错误的规则命中。
三、核心策略组(Proxy Groups)逻辑与实战配置
策略组类似于一个“虚拟开关容器”,它将多个真实物理节点组织在一起,实现负载均衡或自动化故障转移:
1. 常见的策略组类型
- Select (手动选择):由用户在 UI 界面上手动点击指定哪一个节点工作;
- URL-Test (自动优选最低时延):内核后台每隔一定时间向指定测速地址(如
http://www.gstatic.com/generate_204)发送心跳,自动将流量分流到响应最快的节点; - Fallback (自动故障自愈回退):按列表顺序优先使用第一个节点,若第一个节点发生超时,则毫秒级无感降级使用第二个备用节点;
- Load-Balance (负载均衡/哈希分流):将并发请求轮询分发到不同节点,适合爬虫或大并发下载。
mermaid
graph LR
subgraph 策略组协同体系
UserReq["应用流量请求"] --> Group["策略组 (Proxy Group: 🤖 OpenAI)"]
Group -->|模式: Fallback 故障转移| N1{"主用: 🇯🇵 日本01 (专线)"}
N1 -->|正常工作| Out1["海外出口"]
N1 -->|机房拔线/心跳失败| N2{"备用: 🇺🇸 美国02 (专线)"}
N2 -->|接管流量| Out2["海外出口"]
end四、排查分流命中与常见疑难杂症
1. 怎么知道我访问的网页到底走直连还是走代理?
打开客户端的 【连接 (Connections)】 页面:
- 在搜索框输入目标网址(如
openai.com); - 查看记录中的
Rule字段:显示匹配上了哪一条规则; - 查看
Proxy字段:显示最终是通过哪个真实物理节点发出去的,以及消耗的流量和握手时延。
2. 为什么明明选了规则模式,有些国内网站打不开?
- 原因:部分小众国内企业域名的后缀不在默认的国内白名单库(
geosite:cn)中,被流转到了底部的MATCH, 代理,而某些国内站点屏蔽了海外 IP 访问。 - 解决办法:在客户端的覆写规则(Parsers / Merge)中,将该域名手动添加为直连:yaml
rules: - DOMAIN-SUFFIX,your-local-site.com,DIRECT
五、下一步学习
- 📱 多设备全家桶:如何把规则与代理分发给全屋设备与软路由?阅读 多设备协同与软路由透明网关指南 →
- 🛡️ 底层网络调优:如何避免 DNS 泄漏与 Fake-IP 冲突?阅读 自定义规则集与 DoH 防污染实战 →