2026-06-28 進階設定 預計閱讀 9 分鐘

Clash TUN 模式與系統代理差異解析:流量接管機制對比與選擇建議

對比系統代理與 TUN 模式兩種流量接管方式的工作層級、覆蓋範圍與相容性差異,說明哪些程式會繞過系統代理,以及什麼場景該切換到 TUN 模式。

先搞懂兩種接管方式的原理

使用 Clash 之前,理解流量是怎麼被「劫持」進代理程式的,比記住任何一個開關名稱都更重要。Clash 及其衍生核心 Clash Meta(mihomo)提供兩條截然不同的路線:一條是「系統代理」,另一條是「TUN 模式」。它們要解決的是同一個問題——把裝置發出的網路請求送進 Clash 的規則引擎再轉發出去——但介入的層級完全不同,這直接決定了各自的覆蓋範圍、相容性與設定成本。

系統代理是作業系統層級提供的一套設定介面,本質上是告訴支援該協定的程式:「請把你的 HTTP/HTTPS 請求先發給這個位址和連接埠」。Windows、macOS 都內建了系統代理設定項,瀏覽器、部分下載工具、IDE 的網路元件會讀取這項設定。TUN 模式則是完全不同的思路,它在系統內部建立一張虛擬網路介面(Virtual Network Interface),作業系統會把這張虛擬網卡當成一條真實的網路出口,所有依路由表判斷該走這條出口的 IP 封包,不管來自哪個行程、使用什麼協定,都會先流入這張虛擬網卡,再由 Clash 核心解析、比對規則、轉發到對應節點。

系統代理:輕量但天生有縫隙

系統代理的優點是設定簡單、資源占用低、開關靈活,大多數人第一次接觸 Clash 都是先用這種方式。它的運作機制建立在應用程式主動「配合」的基礎上:程式內部要讀取系統或環境變數裡的代理位址,再自行連線到這個位址完成請求轉發。這意味著只有遵守這套約定的程式,流量才會被正確接管。

問題也正出在這裡。並不是所有連網程式都會讀取系統代理設定,常見的繞過情況包括:

  • 部分命令列工具或背景服務不會讀取系統代理環境變數,需要額外手動設定 HTTP_PROXY/HTTPS_PROXY。
  • 某些應用程式採用硬編碼的直連邏輯,或使用非標準連接埠通訊,系統代理設定對其完全無效。
  • UDP 協定的流量(例如部分即時通訊、遊戲加速場景)往往不在系統代理的接管範圍內,系統代理主要是針對 TCP 層級的 HTTP/HTTPS 請求設計的。
  • 行動端應用生態更為分散,不少 App 直接使用系統底層網路函式庫發起連線,跳過應用層代理設定。

換句話說,系統代理更像是一份「君子協定」:配合的程式會老實轉發,不配合的程式照樣直連出去。這也解釋了為什麼有些用戶明明開著 Clash,某個客戶端依然顯示「未連接代理」或者存取結果與預期不一致——問題往往不在規則寫錯了,而是這個程式根本沒走系統代理這條路。

TUN 模式:在網路層統一接管

TUN 模式的思路更徹底。它不依賴應用程式是否「願意」配合,而是在作業系統的網路協定堆疊層級插入一張虛擬網卡,並配合路由表規則,把裝置上幾乎所有符合條件的 IP 封包都導向這張虛擬介面。封包進入虛擬網卡後,由 Clash Meta(mihomo)核心在使用者態完成協定解析(常見實作基於 gVisor 或系統原生堆疊兩種協定堆疊模式)、網域比對、規則判斷,再決定走哪個代理節點或直連。

由於接管發生在網路層而不是應用層,TUN 模式幾乎不挑應用程式,無論是瀏覽器、命令列工具、遊戲客戶端還是系統自身的背景服務,只要它產生的流量符合路由規則,都會被統一納入管理,包括原本系統代理管不到的 UDP 流量。這也是為什麼很多需要精細分流遊戲、語音通訊、跨平台客戶端的用戶,最終都會轉向 TUN 模式。

注意

TUN 模式需要建立虛擬網卡,這項操作通常需要系統管理員權限(Windows 下需以管理員身分執行,macOS/Linux 下涉及網路擴充功能或 root 權限),首次啟用時系統可能跳出授權提示,屬於正常現象。

相容性與穩定性的現實差異

覆蓋範圍更廣並不代表 TUN 模式沒有代價。由於流量在網路層被截獲並送入使用者態協定堆疊處理,再轉發出去,封包要經過多一層封裝與解析,理論上會帶來輕微的效能開銷,在低效能裝置或對延遲極度敏感的場景下可能會有感知差異。此外,虛擬網卡與本機路由表、防火牆規則、VPN 客戶端之間存在互相影響的可能:

  • 如果裝置上同時運行其他 VPN 軟體或虛擬網路工具,可能出現路由表衝突,導致部分流量走向異常,建議避免同時啟用多個虛擬網卡類工具。
  • 部分企業內網環境或安全軟體會對系統新增的虛擬網路介面進行攔截或告警,首次開啟 TUN 模式前建議先了解所在網路環境的政策。
  • 不同作業系統對 TUN 裝置的實作細節不同,Windows 依賴 Wintun 驅動程式,macOS 使用系統網路擴充功能框架,設定入口與權限申請方式略有差異,但對終端用戶的開關體驗基本一致。

相對地,系統代理沒有這些底層風險,設定即時生效、關閉即時恢復,出問題時排查路徑也更直觀——大多是某個程式沒讀取代理設定。這也是為什麼系統代理至今仍是很多輕量場景下的預設選擇。

覆蓋範圍一覽對比

對比維度系統代理TUN 模式
運作層級應用層,依賴程式主動讀取代理設定網路層,基於虛擬網卡與路由表統一接管
協定覆蓋主要覆蓋 HTTP/HTTPS,UDP 支援有限覆蓋 TCP 與 UDP,幾乎不區分協定類型
是否需要額外權限通常無需管理員權限需要管理員/root 權限才能建立虛擬網卡
相容性風險低,但存在「繞過代理」的程式存在與其他虛擬網路工具衝突的可能
典型適用場景日常瀏覽、輕量辦公、快速臨時使用遊戲分流、命令列工具、多行程精細管控

哪些程式容易繞過系統代理

如果發現某個軟體的流量始終沒有按照代理規則走,大多屬於以下幾類:

  1. 命令列與開發工具:例如套件管理器、建置工具,很多預設不讀取系統代理,需要另外設定環境變數或工具內建的代理選項。
  2. 使用自有網路堆疊的客戶端:一些即時通訊、雲端硬碟同步類軟體為了追求連線速度,自行實作了網路請求邏輯,不經過系統代理介面。
  3. 遊戲與語音通訊:大量遊戲使用 UDP 進行即時資料傳輸,系統代理對 UDP 的支援普遍薄弱或缺失,這類流量基本只能靠 TUN 模式接管。
  4. 系統背景服務與更新元件:作業系統自身的更新檢查、遙測回報等背景行程通常不走用戶設定的代理。

遇到這類問題時,與其逐一排查每個程式的代理設定入口,不如直接切換到 TUN 模式,從網路層一次性解決「接管不全」的問題。

什麼場景該切換到 TUN 模式

結合上面的對比,可以給出一個相對清楚的判斷標準:

  • 如果只是日常瀏覽網頁、處理少量應用程式的代理需求,系統代理已經足夠,設定也更省心。
  • 如果裝置上運行著大量不遵守系統代理約定的程式(命令列工具、遊戲、部分聊天軟體),或者需要對 UDP 流量做規則分流,TUN 模式是更徹底的解決方案。
  • 如果需要按行程做精細化分流(例如讓某個應用程式直連、其餘走代理),TUN 模式搭配 Clash Meta(mihomo)的行程規則(process-name)能達到應用層做不到的細緻程度。
  • 在企業網路、安全軟體較為嚴格的環境中,建議先確認虛擬網卡是否會被攔截,再決定是否啟用 TUN 模式,避免影響正常辦公網路。
建議

大多數客戶端支援系統代理與 TUN 模式共存或快速切換,可以先用系統代理驗證節點與規則是否正常運作,確認無誤後再開啟 TUN 模式擴大覆蓋範圍,這樣排查問題時思路會更清晰。

設定上的實際差異

從設定檔角度來看,系統代理不需要在 Clash 設定裡額外宣告,由客戶端介面上的一個開關直接呼叫系統 API 完成;TUN 模式則通常需要在設定檔中明確宣告相關欄位,例如啟用狀態、協定堆疊類型、是否接管 DNS 等。以 Clash Meta(mihomo)的常見寫法為例:

tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53
  auto-route: true
  auto-detect-interface: true

auto-route 決定是否自動設定路由表將流量導入虛擬網卡,dns-hijack 則用於接管 DNS 查詢,避免部分網域解析繞過規則比對。這些欄位大多數圖形化客戶端已經封裝成介面上的簡單開關,一般用戶無需手寫設定檔,但了解其含義有助於排查偶發的連線異常。

常見疑問簡答

開啟 TUN 模式後還需要系統代理嗎?一般不需要同時開啟,TUN 模式的覆蓋範圍已經包含系統代理能處理的部分,同時開啟容易造成路由判斷混亂,建議二選一。

TUN 模式會不會讓所有流量都變慢?額外的封裝解析確實存在開銷,但在多數現代裝置上這項開銷並不明顯,更多情況下網速差異來自代理節點本身的線路品質,而不是接管方式。

手機端也有 TUN 模式嗎?Android 端通常透過 VpnService 介面實現類似效果,概念上與桌面端的虛擬網卡思路一致,同樣能接管應用層無法處理的流量;iOS 端則依賴網路擴充功能框架實現同類能力。

下載客戶端