TUN 模式深度解析：全域透明代理的原理與設定

使用 Clash 時，大多數人首先遇到的問題是：為什麼開了代理，遊戲還是走國內線路？為什麼 git clone 不走代理？為什麼命令列工具需要單獨設定？ 這些問題的根源在於系統代理的工作機制——它並不能覆蓋所有應用程式。TUN 模式是解決這個問題的終極方案，本文帶你深度理解它。

系統代理的侷限性

「系統代理」模式的工作方式是：通知作業系統「請將 HTTP/HTTPS 請求傳送到本機 127.0.0.1:7890」。這種方式存在一個根本限制：只有主動讀取系統代理設定的應用程式才會遵循它。

瀏覽器（Chrome、Firefox、Safari）預設遵循系統代理設定，但以下類型的程式通常不會：

遊戲客戶端（Steam、Epic Games、各類網遊客戶端）
命令列工具（git、curl、wget、npm、pip）
Windows UWP 應用（Microsoft Store 安裝的應用）
部分 Electron 應用和底層網路函式庫直接呼叫的程式
幾乎所有使用 UDP 協定的程式（包括大多數遊戲和視訊通話）

此外，系統代理只能代理 HTTP/HTTPS 協定的流量，無法處理原生 TCP 連線和 UDP 流量。這意味著即便是理論上「支援代理」的應用，其 UDP 流量也會繞過代理直接送出。

TUN 模式的工作原理

TUN（Tunnel Network Interface）是作業系統提供的一種 虛擬網卡 介面。與 TAP 介面（工作在連結層）不同，TUN 工作在網路層（IP 層），可以直接讀寫 IP 封包。

Clash 的 TUN 模式工作流程如下：

Clash 向作業系統申請建立一塊虛擬網卡（通常命名為 Mihomo 或 utun0）。
修改系統路由表，將特定目標 IP 段的出站流量重新導向到這塊虛擬網卡。
Clash 核心從虛擬網卡讀取原始 IP 封包，解析出目標位址和協定類型。
對於 TCP 流量，Clash 建立一個本機 TCP 連線接收資料，再依規則轉發到代理節點或直連；對於 UDP 流量，同理處理。
從代理節點或直連伺服器返回的資料，重新封裝後寫回虛擬網卡，交給作業系統路由到發起請求的應用。

由於是在 網路層 攔截流量，而非應用層，所有程式——無論是否支援代理協定——的出站網路封包都會被擷取並處理。這就是 TUN 模式能實現真正全域代理的根本原因。

TUN 模式需要建立虛擬網卡並修改系統路由表，這兩項操作均需要管理員（Windows UAC 提權）或 Root/sudo（Linux/macOS）權限。這不是程式「要求過高權限」，而是作業系統的安全機制決定的。

fake-ip：TUN 模式的 DNS 解決方案

TUN 模式下，DNS 處理方式變得非常關鍵，也是最容易出問題的環節。讓我們先看傳統 DNS 流程：

應用程式 → 查詢 DNS: example.com → 取得真實 IP 203.0.113.1 → 向該 IP 發起 TCP 連線

問題在於：當 Clash 在 TUN 層面攔截到一個發往 203.0.113.1 的 TCP 連線請求時，它只看到 IP 位址，不知道這個連線對應的是哪個網域。而 Clash 的規則系統大量依賴網域比對（DOMAIN-SUFFIX、DOMAIN-KEYWORD），沒有網域就無法正確分流。

fake-ip 模式 是解決這個問題的優雅方案：

應用程式發起 DNS 查詢 example.com。
Clash 攔截這個 DNS 查詢，立即返回一個假 IP（如 198.18.0.1），並在內部記錄 198.18.0.1 → example.com 的對應關係。
應用程式拿到假 IP，向 198.18.0.1 發起 TCP/UDP 連線。
Clash 在 TUN 層面攔截到這個連線請求，查詢內部對應表，得知目標是 example.com。
Clash 依網域規則決定走代理還是直連。若走代理，由代理節點在目標地完成真正的 DNS 解析；若直連，Clash 會重新查詢真實 DNS 後建立連線。

fake-ip 的核心優勢在於：敏感網域的 DNS 查詢完全在代理節點端完成，徹底防止 DNS 洩漏；同時由於 Clash 掌握了網域資訊，規則比對準確率大幅提升。

開啟 TUN 模式

Clash Verge Rev（Windows / macOS）

開啟客戶端，點選左側「設定」圖示。
找到「TUN 模式」（或「Tun Mode」）開關，點選開啟。
系統彈出權限請求視窗，Windows 點選「是」，macOS 輸入系統密碼確認。
首次開啟會在背景安裝虛擬網卡驅動程式（Mihomo），稍等 5–10 秒。
客戶端狀態變為「TUN 已啟用」，此時所有出站流量均由 Clash 接管。

完整 YAML 設定（Mihomo 核心）

tun:
  enable: true
  stack: mixed        # mixed / system / gvisor
  dns-hijack:
    - any:53          # hijack all DNS queries
  auto-route: true
  auto-detect-interface: true

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
    - "+.stun.*.*.*"
  nameserver:
    - https://1.1.1.1/dns-query    # Cloudflare DoH
    - https://8.8.8.8/dns-query    # Google DoH
  fallback:
    - https://1.0.0.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

TUN Stack 模式詳解

TUN 的 stack 參數決定了如何處理被擷取的網路封包，直接影響效能、相容性和穩定性：

mixed（推薦）：TCP 流量使用系統原生網路堆疊處理，UDP 流量使用 gVisor 使用者態實作。在相容性和效能之間取得最佳平衡，適合絕大多數使用者。
system：TCP 和 UDP 全部交給作業系統網路堆疊處理。效能最佳、CPU 佔用最低，但在 Linux 某些核心版本上可能有相容性問題。追求極致效能的伺服器場景推薦。
gvisor：TCP 和 UDP 全部在使用者空間模擬完整網路堆疊（Google gVisor 專案）。相容性最好，能處理所有邊緣狀況，但 CPU 和記憶體開銷比 mixed 高 20–40%。遇到 mixed 模式出現奇怪問題時可切換嘗試。

常見問題與排查

區域網路裝置（印表機、NAS、路由器後台）無法存取

TUN 模式透過 auto-route 接管了全部流量，區域網路 IP 段的流量也會被路由到代理出口，自然無法到達本機裝置。在規則檔案 最前面 加入以下直連規則即可：

rules:
  - 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,127.0.0.0/8,DIRECT,no-resolve
  # ... 其他规则

關閉 Clash 後網路斷線

關閉 Clash 前務必先在設定中關閉 TUN 開關，讓程式有機會清理路由表項目。若已斷網：重新開啟 Clash → 關閉 TUN → 再退出程式。或進入裝置管理員（Windows）停用名為 Mihomo 的虛擬網卡，重啟網路即可恢復。

fake-ip-filter 白名單不夠用

本機開發網域（如 localhost、*.test）、企業內網網域、部分國內應用（QQ、微信）的特殊服務網域如果經過 fake-ip 處理，可能導致連線失敗。將這些網域加入 fake-ip-filter 清單，Clash 會對其進行真實 DNS 解析而非返回假 IP。

TUN 模式開啟後 CPU 佔用升高

這是正常現象。TUN 模式需要在使用者空間處理所有網路封包，比系統代理模式的 CPU 開銷高 10–30%。如果 CPU 佔用異常高（超過 20%），可嘗試：將 stack 從 gvisor 切換到 mixed；檢查是否有大量 UDP 流量（如 P2P）正在經過 Clash 處理。

總結

TUN 模式是 Clash 最強大也最完整的代理模式。它透過虛擬網卡在網路層攔截所有流量，搭配 fake-ip DNS 機制實現精確的基於網域的分流，徹底解決了系統代理模式覆蓋範圍有限的問題。

對於日常瀏覽器使用，系統代理模式已經足夠；但如果你需要代理遊戲、命令列工具或所有 App 的流量，TUN 模式是不二之選。設定好區域網路直連規則和 fake-ip-filter 白名單，TUN 模式可以運行得非常穩定。