梯子翻墙

Appearance

🏆 2026 编辑力荐晚高峰稳定性实测首选
TOP 1光速云¥99/年

企业级内网 IPLC 专线 · 晚高峰 0 丢包 · 免配置自研微端

专属优惠券:AMM
🚀 直达官网 · 享专属特惠
TOP 2飞猫云¥9.9/月

国内三网 BGP 智能中转 · 专属开箱客户端 · 随时月付无套路

专属优惠券:flycat888
🐱 直达官网 · 9.9元上车
📊 查看 2026 全网 28 家实测可直达机场天梯榜 →

规则模式（Rule）、全局模式（Global）与直连模式（Direct）有什么区别？实战场景选择 ​

⚡ Answer-First 核心速览

规则模式是日常使用的最佳选择，它依赖分流规则表将国内流量导向直连以保证低延迟与大带宽，同时将受限的境外流量导向代理节点；全局模式会完全忽略分流规则，强行将所有出站流量投递给指定代理节点，适合跨境电商、外币支付等严防 IP 漂移的风控场景；直连模式则相当于临时关闭代理，所有数据直接由本地网关直出。分流规则遵循自上而下的短路匹配原则，末尾必须由 MATCH 兜底；涉及 IP-CIDR 分流时应配合 no-resolve 参数，防止本地发生不必要的 DNS 泄漏。

返回从零到精通使用大系

在启动任何出海代理客户端（如 Clash Verge Rev、Mihomo Party、Surge 或 Sing-box）时，主界面最醒目的控制选项通常是“路由模式”切换按钮。新手常常因为选错模式而遭遇各种奇怪的问题。有的用户开启全局模式后发现微信发不出图片、国内网盘下载速度骤降为零；有的用户开启规则模式后，却频繁触发某些海外银行或跨境电商的异地登录警告。

理解规则模式、全局模式与直连模式在操作系统网络协议栈中的流量调度逻辑，掌握分流规则从首行到末行的比对流水线，能够让你针对不同的工作任务与网络环境做出精准的架构配置。

三大核心路由模式的数据流分发机制 ​

现代代理客户端的核心本质是一个运行在本地用户态的高性能流量路由器。客户端通过设置系统代理（修改 Windows 注册表中的 WinINET 键值）或者接管 TUN 虚拟网卡，将应用程序产生的网络流量汇聚到本地监听端口（例如混合端口 7890）。数据包一旦进入代理内核，就会根据当前激活的路由模式被分发到不同的处理管道。

text
                      [应用程序发出连接请求]
                                │
                                ▼
                      [客户端本地监听端口 7890]
                                │
        ┌───────────────────────┼───────────────────────┐
        ▼                       ▼                       ▼
  【直连模式 Direct】       【全局模式 Global】       【规则模式 Rule】
        │                       │                       │
        │ 忽略所有代理节点       │ 忽略所有分流规则       │ 逐行比对分流规则表
        │ 直接绑定物理网卡出站   │ 强制投递到 GLOBAL 组   │ (Domain, IP-CIDR, GEOIP)
        │                       │                       │
        │                       ▼                       ├─ 匹配到 DIRECT ──> 本地直连
        │                 [用户选定节点]                ├─ 匹配到 PROXY  ──> 加密隧道
        │                       │                       └─ 未命中 ──> MATCH 兜底策略
        ▼                       ▼                               │
[本地运营商默认网关]    [境外落地服务器]                        ▼
        │                       │                     [目标对应出站]
        ▼                       ▼                               │
   (国内目标网站)          (海外目标网站)                       ▼
                                                      [最终互联网目标]

1. 规则模式（Rule）的工作流程 ​

规则模式是现代网络工具的技术基石。它的设计初衷是在“保证境内服务速度”与“顺畅访问海外受限资源”之间取得自动化平衡。

当一个 TCP 握手请求进入内核后，分流引擎会提取该请求的目标元数据，包括目标域名（Host / SNI）、目标 IPv4/IPv6 地址、目标端口以及发起请求的本地进程名称。 分流引擎随后将这些元数据带入配置文件中的 rules 列表，从第一行开始逐条向下比对。 一旦某一条规则被满足，内核立即终止后续比对，直接按照该条规则设定的出站动作（例如分流至“香港专线”策略组、直接走 DIRECT 或者走 REJECT 拦截）将数据包发出。

在规则模式下，访问百度、淘宝、哔哩哔哩等境内平台时，系统匹配到 GEOIP, CN 规则后直接走物理网卡直连，不会占用机场的宝贵流量，更不会因为绕道海外而带来额外的延迟。而访问 Google、GitHub、YouTube 时，流量会被规则精准识别并送入加密隧道。

2. 全局模式（Global）的工作流程 ​

很多用户误以为全局模式意味着“接管电脑上所有软件的流量”。在代理网络工程中，全局模式有其特定的定义。

全局模式指的是忽略配置文件中编写的所有分流规则，强制将所有被客户端截获的流量，无条件转发到当前在 GLOBAL 策略组中选中的单一节点。

在全局模式下，即使你访问的是国内的百度或者内网路由器后台（192.168.1.1），如果配置文件没有强制排除局域网私有段，客户端也会尝试把该连接打包发送给远在东京或洛杉矶的代理服务器。 这会导致两个直接后果。第一，国内网站会检测到你的访问来源为海外机房 IP，从而触发版权区域限制或安全人机验证；第二，由于所有数据都需要绕行海外再折返回国，国内网页的加载速度会显著下降，并白白消耗机场套餐的计费流量。

全局模式并非没有用途。在需要彻底固定出口 IP、排查分流规则失效故障、或者进行网络连通性基准测试时，全局模式是最直接有效的手段。

3. 直连模式（Direct）的工作流程 ​

直连模式与全局模式刚好相反。它指示代理内核忽略所有的境外节点与加密隧道，将所有接收到的网络请求全部走 DIRECT 本地直连出站。

在直连模式下，客户端虽然依然在本地监听 7890 端口，但它所扮演的角色仅仅是一个普通的本地中继。数据包进入内核后，内核不经过任何加工，直接调用本地操作系统的物理网卡 Socket 发送出去。

直连模式主要用于两个特定场景。第一是临时需要完全恢复国内原始网络环境，但又不想彻底关闭代理软件并重置系统代理配置；第二是在自建多网卡软路由或家庭服务器上，作为旁路网关临时切换流量走向。

分流匹配顺序与短路执行黄金法则 ​

在规则模式的实际应用中，分流规则的编写顺序直接决定了分流系统的成败。所有基于 Clash、Mihomo 和 Sing-box 的规则引擎，都遵循严格的**自上而下、短路评估（Short-circuit evaluation）**原则。

所谓短路评估，意味着规则引擎在内存中逐行扫描规则列表时，只要发现当前请求命中了某一行，就会立刻停止向下比对，直接执行该行的出站指令。后续哪怕有写得更详细、更精确的规则，也永远没有被执行的机会。

text
[发起请求: mail.google.com:443]
      │
      ▼
比对规则 1: DOMAIN,mail.google.com,Google-Mail  ──> 命中吗？ ──[是]──> [立即停止比对，发送至 Google-Mail 组]
      │ [否]
      ▼
比对规则 2: DOMAIN-SUFFIX,google.com,代理节点    ──> 命中吗？ ──[是]──> [立即停止比对，发送至 代理节点 组]
      │ [否]
      ▼
比对规则 3: DOMAIN-KEYWORD,google,自动优选      ──> 命中吗？ ──[是]──> [立即停止比对，发送至 自动优选 组]
      │ [否]
      ▼
比对规则 4: GEOIP,CN,DIRECT                    ──> 命中吗？ ──[是]──> [立即停止比对，走本地直连]
      │ [否]
      ▼
比对规则 5: MATCH,漏网流量                      ──> [无条件接管所有未命中流量]

1. 规则顺序错误的典型灾难案例 ​

由于缺乏对短路原则的理解，很多初学者在自定义规则时经常犯下灾难性的排序错误。

错误案例一 将宽泛的地理位置规则置于特定业务规则之前 ​

yaml
# 错误示范
rules:
  - GEOIP,CN,DIRECT
  - DOMAIN-SUFFIX,bilibili.com,DIRECT
  - DOMAIN-SUFFIX,steamcommunity.com,游戏策略组
  - DOMAIN-SUFFIX,apple.com,苹果服务
  - MATCH,代理节点

看起来似乎合乎常理，但这里隐藏着一个巨大的隐患。某些海外服务（如 Steam 社区、微软更新、苹果某些云服务）在大陆部署了 Akamai 或网宿等国内 CDN 边缘节点。当客户端访问这些海外服务时，DNS 解析出来的目标 IP 属于中国大陆境内 IP。 如果把 GEOIP,CN,DIRECT 放在最前面，由于该请求的目标 IP 属于国内，系统会第一优先命中直连规则，从而直接绕过了后面专门编写的 DOMAIN-SUFFIX,steamcommunity.com,游戏策略组。其结果就是 Steam 社区依然打不开。

正确的做法是遵循从具体到宽泛、从精准到兜底的排序金字塔。

  1. 本地私有局域网直连（GEOIP,lan,DIRECT）
  2. 明确的精准域名规则（DOMAIN、DOMAIN-SUFFIX）
  3. 动态业务规则集（RULE-SET，涵盖 Telegram、YouTube、OpenAI、Netflix）
  4. 大陆境内域名与国家地理规则（GEOSITE,cn,DIRECT 与 GEOIP,CN,DIRECT）
  5. 最终兜底规则（MATCH）

错误案例二 MATCH 规则位置放错 ​

yaml
# 致命错误示范
rules:
  - DOMAIN-SUFFIX,google.com,代理节点
  - MATCH,代理节点
  - DOMAIN-SUFFIX,baidu.com,DIRECT
  - GEOIP,CN,DIRECT

在上面的配置中，第二行就写了 MATCH,代理节点。根据短路原则，所有未命中 google.com 的流量，无论是访问百度、淘宝还是本地路由器后台，都会在第二行无条件被 MATCH 强行吃掉并送往代理节点。写在 MATCH 下方的百度直连和国内 IP 直连规则，在逻辑上变成了永远无法触达的“死代码”。

在任何合规的 Clash 和 Mihomo 配置文件中，MATCH 规则必须且只能出现在整个 rules 数组的最末尾一行。

DNS 查询链路差异与 no-resolve 原理解析 ​

许多用户对规则模式有一个严重的误解，以为只要域名规则写得全，本地就不会发起针对境外域名的 DNS 解析。在实际网络交互中，规则模式下的 DNS 处理远比想象中复杂。

1. 规则模式下的 DNS 嗅探与潜在泄露 ​

假设配置文件中存在这样一条规则。

- IP-CIDR,91.108.4.0/22,Telegram-Group

当你在浏览器中访问 t.me 时，数据包进入内核。内核从上到下按序扫描。 第一条规则比对域名后缀，没命中；第二条比对域名关键字，没命中；接着遇到了上面的第三条规则 IP-CIDR。

这时问题出现了。规则引擎手里拿到的仅仅是域名 t.me，而第三条规则要求比对目标 IP 是否处于 91.108.4.0/22 网段内。 为了验证当前请求是否符合这条规则，内核被迫在本地立即发起一次 DNS 查询，试图把 t.me 解析为真实 IP。

如果你的本地客户端没有配置防污染的加密 DNS（DoH/DoT），而是直接将查询发给了家庭路由器默认由当地运营商（电信/联通/移动）分配的 DNS 服务器，那么这次查询就会立刻被本地运营商捕获并记录。运营商虽然看不到你后续传输的加密数据，但清清楚楚地记录了你在几点几分试图连接 Telegram。这就是典型的 DNS 分流泄漏。

2. no-resolve 参数的物理防御机制 ​

为了根除这种由于 IP 规则匹配引发的本地 DNS 偷跑，Clash 规范引入了关键参数 no-resolve。

正确的配置写法如下。

yaml
rules:
  - GEOIP,lan,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,91.108.4.0/22,Telegram-Group,no-resolve

no-resolve 的字面含义是“不要解析”。当规则引擎扫描到带有 no-resolve 标记的 IP-CIDR 或 GEOIP 规则时。

  • 如果当前请求是以 IP 地址形式直接发起的（例如程序直接向 91.108.4.15:443 发送连接），规则引擎会正常进行网段比对并命中分流。
  • 如果当前请求是以域名形式发起的（例如访问 t.me），规则引擎将直接跳过这条规则，绝不尝试在本地向 DNS 服务器发起解析请求，从而彻底切断了本地运营商探知该域名的物理链路。

3. 全局模式下的 DNS 免疫优势 ​

在全局模式（Global）下，由于客户端预先知道所有流量都要送往远端的代理节点，因此本地根本不需要比对任何 IP-CIDR 规则。

客户端收到应用程序发出的连接目标 google.com:443 后，直接将目标域名字符串封装在 SOCKS5、Shadowsocks 或 Trojan 握手报文中，原封不动地通过加密隧道抛给海外的落地服务器。域名解析完全发生在几千公里外的海外机房，本地网络链路中没有任何明文的 DNS 查询数据包，从源头上免疫了国内运营商的 DNS 劫持与探测。

四大模式全维度技术特性横向对照 ​

为了理清不同模式在实际运行中的行为特征，下表将规则模式、全局模式、直连模式以及配合 TUN 虚拟网卡的高级模式进行综合对比。

评估维度规则模式（Rule）全局模式（Global）直连模式（Direct）TUN 虚拟网卡规则模式
网络接管层级应用层系统代理（L7）应用层系统代理（L7）应用层系统代理（L7）网络层虚拟网卡（L3）
分流规则生效情况严格按自上而下短路生效完全忽略分流规则完全忽略分流规则严格按自上而下短路生效
国内网站访问表现本地网卡直连，延迟极低，跑满带宽绕行海外代理，速度受限，易弹人机验证原始直连，体验与未开代理完全一致本地网卡直连，完美兼顾带宽与延迟
DNS 处理策略依赖本地分流或 Fake-IP 映射纯远端代理解析，零本地泄露系统原生 DNS，无任何代理干预驱动层劫持 53 端口并由 Fake-IP 接管
终端与游戏支持仅支持遵循系统代理的浏览器与应用仅支持遵循系统代理的浏览器与应用仅支持遵循系统代理的应用全面接管游戏 UDP、CMD、PowerShell、Docker
出口 IP 稳定性依据域名分流，不同网站可能展示不同落地 IP严格固定为当前 GLOBAL 选中的单一节点 IP真实本地宽带公网 IP依据域名分流，底层无感分流
配置复杂度较高（需定期维护节点池与规则集）极低（仅需选定一个可用节点）极低（无需任何额外配置）高（需安装 Wintun 驱动并配置防火墙权限）
内存与 CPU 负载极低（哈希查表毫秒级响应）极低（无复杂规则扫描计算）几乎为零稍高（需运行轻量级用户态网络协议栈）

从上表可以看出，规则模式与 TUN 模式的组合是功能最完备的形态，而在出口 IP 固定性与排错确定性上表现直接。

典型业务场景下的模式选型实战方案 ​

在日常工程实践中，盲目使用同一种模式往往会导致效率低下或安全风控。针对以下四个典型业务场景，给出了成熟的模式选型与落地配置建议。

场景一 日常多任务混合办公与代码开发 ​

业务特征 ​

开发者同时使用微信、企业微信、钉钉进行团队协作，使用国内网盘传输大文件，同时需要访问 GitHub 拉取代码、查看 AWS/GCP 英文文档，并使用 Google 搜索技术资料。

推荐方案 ​

规则模式 + 智能分流规则集（或叠加 TUN 模式）。

配置要点 ​

国内常用应用必须严格配置走直连，确保工作沟通与文件传输不受代理带宽限制。GitHub 域名与常用技术社区配置为代理出站。终端中开启终端代理环境变量，或直接开启 TUN 模式接管 git clone。

yaml
rules:
  # 开发工具常用直连域名
  - DOMAIN-SUFFIX,npmmirror.com,DIRECT
  - DOMAIN-SUFFIX,aliyun.com,DIRECT
  - DOMAIN-SUFFIX,tencent.com,DIRECT
  # 海外开发社区走代理
  - DOMAIN-SUFFIX,github.com,开发专用节点
  - DOMAIN-SUFFIX,githubassets.com,开发专用节点
  - DOMAIN-SUFFIX,docker.com,开发专用节点
  - DOMAIN-SUFFIX,stackoverflow.com,开发专用节点
  # 兜底规则
  - GEOIP,CN,DIRECT
  - MATCH,兜底代理

场景二 跨境电商店铺运营与海外网银支付 ​

业务特征 ​

管理亚马逊（Amazon）北美店铺、Shopee 东南亚店铺、PayPal 国际账户、Stripe 结算通道或海外虚拟信用卡（如 Wise）。这些平台拥有全球最严苛的反洗钱与反欺诈风控引擎，对登录者的 IP 纯净度、地理位置跳变、浏览器指纹有极其严苛的监控。

推荐方案 ​

全局模式（锁定专用静态住宅/原生独享节点），或者在规则模式中为店铺域名建立独立的专用静态策略组。

配置要点 ​

绝对不能使用带有 url-test（自动测速）的动态策略组。如果使用自动测速组，每次测速只要另一个节点延迟稍微低一点，客户端就会自动切换节点。在跨境电商后台看来，你的账号在几分钟前还在美国洛杉矶登录，几分钟后突然跳到了日本东京，系统会立刻判定账号被盗或处于高风险环境，当场触发二级身份验证甚至直接冻结店铺资金。

如果业务复杂必须常驻规则模式，务必为支付和电商域名单独拉出专用策略组。

yaml
proxy-groups:
  - name: "跨境电商专线"
    type: select
    proxies:
      # 只放入一个固定的纯净静态原生 IP 节点，杜绝任何自动切换
      - "美国俄勒冈静态原生01"

rules:
  # 电商与支付域名严格锁定专线
  - DOMAIN-SUFFIX,amazon.com,跨境电商专线
  - DOMAIN-SUFFIX,sellercentral.amazon.com,跨境电商专线
  - DOMAIN-SUFFIX,paypal.com,跨境电商专线
  - DOMAIN-SUFFIX,wise.com,跨境电商专线
  - DOMAIN-SUFFIX,stripe.com,跨境电商专线

场景三 ChatGPT、Claude 等前沿 AI 工具高频交互 ​

业务特征 ​

OpenAI 与 Anthropic 对访问请求的来源 IP 进行极其严苛的风险评分检查。公用机场的大多数万人共享节点通常早被 Cloudflare 标记为数据中心机房 IP（Data Center IP），直接报错“Access Denied”或“无法提供服务”。

推荐方案 ​

规则模式 + 独立 AI 策略组（绑定高质量解锁节点）。

配置要点 ​

不要为了使用 ChatGPT 而打开全局模式影响全局网络。通过完善的域名列表，把所有与 OpenAI、Anthropic、Perplexity 相关的域名精准捕获，并送入专门挑选出的优质原生节点或专线节点中。

yaml
proxy-groups:
  - name: "人工智能服务"
    type: select
    proxies:
      - "日本 02 专线 (解锁 ChatGPT)"
      - "新加坡 01 BGP (原生解锁)"
      - "美国 03 住宅 IP"

rules:
  # OpenAI 核心生态域名
  - DOMAIN-SUFFIX,openai.com,人工智能服务
  - DOMAIN-SUFFIX,chatgpt.com,人工智能服务
  - DOMAIN-SUFFIX,oaistatic.com,人工智能服务
  - DOMAIN-SUFFIX,oaiusercontent.com,人工智能服务
  # Anthropic Claude 域名
  - DOMAIN-SUFFIX,anthropic.com,人工智能服务
  - DOMAIN-SUFFIX,claude.ai,人工智能服务

场景四 本地大容量数据传输与离线下载 ​

业务特征 ​

使用迅雷、BitTorrent、百度网盘下载大型单机游戏、高清视频素材，或者在局域网内与群晖 NAS 同步几十吉字节的工程文件。

推荐方案 ​

直连模式（Direct），或者在规则模式中配置针对 BT 协议与局域网段的强制直连规则。

配置要点 ​

绝大多数正规机场明确禁止在代理节点上跑 P2P/BitTorrent 下载。BT 下载会在瞬间建立成千上万个并发 TCP/UDP 连接，导致中继服务器端口迅速耗尽、带宽跑满，严重影响其他正常翻墙用户的体验。绝大多数机场系统内置了审计拦截，一旦检测到 BT 报文会自动掐断连接，屡次违规甚至会导致账户被封禁。 在大规模离线下载期间，建议直接在客户端界面切换到直连模式，释放物理宽带的全部潜能。

生产级 Clash 规则分流实战配置样例 ​

下面提供一份结构严密、可直接用于生产环境的 Clash Verge Rev / Mihomo 规则配置片段。该配置采用了现代化的规则集引用（rule-providers），保证规则能自动在云端更新，同时合理配置了 no-resolve 参数防止 DNS 泄漏。

yaml
# ==========================================
# 外部动态规则集订阅声明 (rule-providers)
# ==========================================
rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://testingcf.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/reject.txt"
    path: ./ruleset/reject.yaml
    interval: 86400

  icloud:
    type: http
    behavior: domain
    url: "https://testingcf.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/icloud.txt"
    path: ./ruleset/icloud.yaml
    interval: 86400

  apple:
    type: http
    behavior: domain
    url: "https://testingcf.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/apple.txt"
    path: ./ruleset/apple.yaml
    interval: 86400

  proxy:
    type: http
    behavior: domain
    url: "https://testingcf.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/proxy.txt"
    path: ./ruleset/proxy.yaml
    interval: 86400

  direct:
    type: http
    behavior: domain
    url: "https://testingcf.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/direct.txt"
    path: ./ruleset/direct.yaml
    interval: 86400

  telegramcidr:
    type: http
    behavior: ipcidr
    url: "https://testingcf.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/telegramcidr.txt"
    path: ./ruleset/telegramcidr.yaml
    interval: 86400

  cncidr:
    type: http
    behavior: ipcidr
    url: "https://testingcf.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/cncidr.txt"
    path: ./ruleset/cncidr.yaml
    interval: 86400

# ==========================================
# 策略组设计 (proxy-groups)
# ==========================================
proxy-groups:
  - name: "节点选择"
    type: select
    proxies:
      - "自动优选"
      - "故障转移"
      - "香港 01 节点"
      - "日本 01 节点"
      - "美国 01 节点"

  - name: "自动优选"
    type: url-test
    proxies:
      - "香港 01 节点"
      - "日本 01 节点"
      - "美国 01 节点"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

  - name: "电报消息"
    type: select
    proxies:
      - "节点选择"
      - "新加坡 01 节点"

  - name: "广告拦截"
    type: select
    proxies:
      - REJECT
      - DIRECT

# ==========================================
# 核心路由执行树 (rules)
# ==========================================
rules:
  # 1. 局域网私有网段与常见本地设备直连
  - GEOIP,lan,DIRECT,no-resolve
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

  # 2. 广告与恶意遥测直接丢弃
  - RULE-SET,reject,广告拦截

  # 3. 苹果生态专用优化直连
  - RULE-SET,icloud,DIRECT
  - RULE-SET,apple,DIRECT

  # 4. Telegram 专用 IP 段匹配 (强制 no-resolve 防泄露)
  - RULE-SET,telegramcidr,电报消息,no-resolve

  # 5. 海外已知服务规则集
  - RULE-SET,proxy,节点选择

  # 6. 国内常见直连域名集合
  - RULE-SET,direct,DIRECT

  # 7. 国家地理数据库兜底
  - GEOIP,CN,DIRECT
  - RULE-SET,cncidr,DIRECT

  # 8. 必须置底的最终兜底规则
  - MATCH,节点选择

这套配置具备三大工程优势。首先，局域网与国内常用服务通过规则库被分流到直连，不仅访问极速而且不耗费节点配额；其次，针对广告与恶意遥测实施了客户端级阻断，净化网络环境；最后，Telegram 与国内 IP 规则全部施加了 no-resolve 保护，彻底消除了分流过程中的 DNS 嗅探隐患。

常见问题深度解答 ​

Q1 为什么开启全局模式后某些国内软件依然显示本地真实 IP ​

这通常发生在使用了某些跨平台即时通信软件或桌面游戏时。 出现该现象的原因在于系统代理无法捕获基于底层 UDP 协议或绕过系统代理 API 的流量。 在普通全局模式下，客户端仅仅修改了 Windows 的 HTTP/SOCKS5 系统代理设置。如果一个应用程序在代码底层直接调用原始 Socket 与服务器建立连接，或者直接发送 UDP 数据报，这些流量就会完全避开客户端的本地监听端口，依然经由物理网卡直出互联网，从而暴露你的真实 IP。 要实现对整台电脑所有协议、所有进程无死角的全局接管，必须开启 TUN 虚拟网卡模式。

Q2 规则模式下访问未知的小众海外网站会被拦截或走直连吗 ​

这取决于你配置文件的最末尾一行 MATCH 规则绑定了哪个出站。 如果你的配置末尾写的是 MATCH,DIRECT，那么任何没有被前面规则命中的海外冷门小网站都会走直连，其结果自然是打不开； 如果你的末尾写的是 MATCH,节点选择 或 MATCH,PROXY，那么所有前面未能识别的流量都会自动回落到代理节点转发。因此，在编写规则时，除非有极特殊的白名单诉求，通常建议将 MATCH 绑定至你的主代理策略组。

Q3 开启规则模式会导致系统 CPU 占用显著增加吗 ​

不会。现代 Clash 与 Mihomo 内核将分流规则预先编译为内存中的前缀树（Trie 树）与基数树（Radix Tree），摆脱了低效的逐行线性文本比对。 即使你的配置文件中引用了包含十万条域名的庞大规则库，当一个域名进入内核时，匹配算法的时间复杂度仅为与域名长度成正比的微秒级操作，内存占用一般在几十兆字节以内，对现代计算机的 CPU 算力消耗微乎其微。

Q4 为什么有的用户建议在规则模式中把 GEOIP 规则替换为 GEOSITE ​

因为 GEOIP 匹配的是纯粹的 IP 地址库，而 GEOSITE 匹配的是结构化的域名数据库。 在访问一个网站时，先拿到的是域名，后拿到的是 IP。如果依赖 GEOIP 进行分流，内核往往需要先执行一次 DNS 查询拿到目标 IP 才能做出裁决，这会带来额外的网络延迟甚至产生 DNS 污染风险； 而 GEOSITE 允许内核直接在应用层比对域名字符串（例如直接识别出 google.com 属于海外域名），省去了等待 DNS 解析的时间，在网络分流的决策效率和准确率上显著优于传统的 GEOIP。