3_代理模式深度解析：TUN 与分流策略的工作原理

发表于 2025-08-01 更新于 2026-01-24 分类于 3-计算机系统，代理工具阅读次数： Waline：本文字数： 3k 阅读时长 ≈ 3 分钟

深入解析代理工具的 TUN 模式与分流策略（Rule/Global）的本质区别，帮助开发者解决终端无法代理的困惑。

浏览器能访问 Google，但终端 git clone 超时；开启「全局模式」后 AWS 数据库仍无法连接。这两个问题的根源在于混淆了流量接管机制与分流策略。本文厘清这两个概念的本质区别。

1. 流量接管机制：System Proxy Vs TUN

「如何抓取流量」与「如何处理流量」是两个独立问题。许多连接故障源于对前者的误解。

1.1 系统代理（System Proxy）

默认模式。Clash 仅修改操作系统的 HTTP/SOCKS5 代理环境变量。

机制：操作系统建议应用程序使用 127.0.0.1:7890 作为代理
局限：属于「君子协定」——浏览器遵守，但 Terminal、Git、Docker、Navicat、游戏通常忽略此设置

结果：浏览器访问 Google 正常，终端 ping / curl 超时。

1.2 TUN 模式（虚拟网卡）

机制：创建虚拟网卡（通常命名为 utun），修改系统路由表，将所有 L3 层 IP 流量强制指向该网卡
优势：强制接管——无论应用是否支持代理设置，流量均被捕获
适用：Terminal、Navicat、IntelliJ IDEA、游戏等不遵循系统代理的应用

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#4F46E5', 'lineColor': '#6366F1', 'primaryBorderColor': '#3730A3'}}}%%
flowchart TD
    subgraph OS["操作系统网络栈"]
        App1["浏览器"]
        App2["终端/IDE/Navicat"]
        SysProxy["系统代理设置"]
        RouteTable["路由表"]
        PhyNIC["物理网卡"]
        TunNIC["虚拟网卡 (TUN)"]
    end

    Core["Clash Core"]

    %% System Proxy Flow
    App1 --"读取配置"--> SysProxy
    SysProxy -.->|"HTTP/SOCKS5"| Core

    %% Direct Flow (Bypassing Proxy)
    App2 --"忽略代理"--> PhyNIC

    %% TUN Flow
    RouteTable --"默认路由"--> TunNIC
    TunNIC ==>|"L3 流量劫持"| Core

    classDef danger fill:#EF4444,stroke:#B91C1C,color:#fff
    classDef primary fill:#4F46E5,stroke:#3730A3,color:#fff
    classDef warning fill:#F59E0B,stroke:#D97706,color:#000

    class TunNIC danger
    class Core primary
    class PhyNIC warning

2. 分流策略：Rule Vs Global

流量被捕获后，分流引擎决定其去向。

2.1 策略类型

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#4F46E5', 'primaryTextColor': '#000', 'lineColor': '#6366F1'}}}%%
flowchart TD
    Traffic["入站流量"] --> Engine{"分流引擎"}

    Engine -->|"Rule 模式"| RuleMatch{"规则匹配"}
    RuleMatch -->|"GEOIP,CN"| Direct["直连"]
    RuleMatch -->|"DomainSuffix,google.com"| Proxy["代理"]
    RuleMatch -->|"MATCH (兜底)"| Final["默认出口"]

    Engine -->|"Global 模式"| GlobalProxy["全部走代理"]
    Engine -->|"Direct 模式"| AllDirect["全部直连"]

    classDef primary fill:#4F46E5,stroke:#3730A3,color:#fff
    classDef success fill:#10B981,stroke:#059669,color:#fff
    classDef warning fill:#F59E0B,stroke:#D97706,color:#000
    classDef info fill:#06B6D4,stroke:#0891B2,color:#fff

    class Engine primary
    class Direct,AllDirect success
    class Proxy,GlobalProxy info
    class RuleMatch warning

策略	行为
Rule（规则模式）	智能分流：国内直连、国外代理、MATCH 兜底
Global（全局模式）	忽略规则，所有流量强制走代理
Direct（直连模式）	所有流量直连，不走代理

2.2 模式组合矩阵

TUN（增强模式）与分流策略是两个独立开关：

组合	TUN	Mode	行为	场景
基础翻墙	关	Rule	仅浏览器被代理；国内直连，国外代理	日常浏览
误解高发区	关	Global	仅浏览器强制代理；终端/IDE 仍无法联网	⚠️ 不推荐
开发首选	开	Rule	全系统接管；国内直连，国外代理	开发环境
强制调试	开	Global	全系统强制代理；所有流量走代理	排查网络问题

关键区分
ClashX「增强模式」= TUN 机制（决定能否捕获 Navicat 流量）
Quantumult X「全部代理」= Global 策略（因 VPN 架构，天生运行于 TUN 模式）

3. 实践建议

遇到「Navicat 连不上数据库」或「终端 git clone 超时」时：

问题类型	解决方案
流量未被捕获	开启 TUN 模式（增强模式）
分流规则不当	检查 Rule 规则，确认目标域名/IP 匹配代理策略

推荐配置：TUN 模式 + Rule 策略——既保证全系统流量被接管，又实现智能分流。

相关资源

Whatshub 梯子脚本