Clash TUN 模式是什麼?虛擬網卡接管全局流量的原理與開啟方法

為什麼需要 TUN:系統代理的三個盲區

多數 Clash 用戶端預設以系統代理方式運作:核心在本機開啟一個 HTTP/SOCKS 混合連接埠,再把這個位址寫進作業系統的代理設定。這個方案部署簡單,但存在三個結構性盲區。

• 只覆蓋主動遵循設定的應用程式。是否走代理由應用程式自己決定,只有讀取系統代理設定的程式才會把流量交給核心。大量命令列工具(git、curl、npm、docker)、多數遊戲和部分桌面軟體不讀這個設定,流量會直接繞過代理。
• 只處理 TCP。系統代理管不到 UDP 與 ICMP,語音通話、線上遊戲、QUIC 等基於 UDP 的流量都不在接管範圍內。
• DNS 仍走本地電信業者。應用程式自行解析網域名稱,解析結果可能被污染,被污染的錯誤 IP 再交給代理也無濟於事。

TUN 模式的思路是把接管點從應用層挪到網路層:由核心建立一塊虛擬網卡,讓作業系統把所有出站 IP 封包都路由進來,應用程式全程無感。

運作原理:虛擬網卡如何接管全局流量

TUN 是作業系統提供的第三層虛擬網路裝置,進出它的是原始 IP 封包;它的第二層版本叫 TAP,處理以太網幀。Clash 系核心(mihomo 等)使用的正是 TUN。

開啟 TUN 後,核心會依序做三件事:

1. 建立裝置。Windows 上載入 wintun 驅動程式產生虛擬網卡,macOS 上建立 utun 裝置,Linux 上開啟 /dev/net/tun。
2. 接管路由。修改系統路由表,把預設路由指向虛擬網卡(auto-route),同時記錄實體網卡作為真實出口(auto-detect-interface)。
3. 逐封包處理。核心從虛擬網卡讀出 IP 封包,重組 TCP 連線、為 UDP 建立轉送對映,再依配置中的規則(DOMAIN-SUFFIX、GEOIP、IP-CIDR、MATCH 等)決定這條連線走代理節點、直連還是拒絕。

協議堆疊 stack 的選擇

把原始 IP 封包還原成 TCP/UDP 流需要一套 TCP/IP 協議堆疊,mihomo 提供三種:gVisor 是使用者態實作,相容性最好;system 複用作業系統協議堆疊,負擔更小;mixed 讓 TCP 走 system、UDP 走 gVisor,是常見的折衷方案。桌面用戶端一般預設 gVisor 或 mixed,日常使用不必更動。

與 fake-ip 的配合

TUN 通常與 fake-ip 模式一起運作。應用程式的 DNS 查詢會被核心接管(dns-hijack),核心回傳 198.18.0.0/16 區段內的一個假位址,並記下它與網域名稱的對映;應用程式隨後連線這個假位址時,核心會反查出真實網域名稱,依網域名稱規則精確分流。直接好處有兩個:一是避開本地 DNS 污染,二是讓依網域名稱分流對只發送 IP 封包的情境同樣有效。

TUN 模式與系統代理對照

兩者不衝突。多數用戶端建議保留系統代理作為兜底:遵循系統代理的應用程式走應用層通道,其餘流量由 TUN 在網路層接住。

各平台開啟方法

Windows(以 Clash Verge Rev 為例)

1. 打開設定頁,找到「服務模式」(Service Mode),點擊安裝。該服務以系統服務常駐,負責建立虛擬網卡;裝好後主程式不必每次以系統管理員身分啟動。
2. 回到設定頁,打開「TUN 模式」開關。
3. 首次開啟若被防火牆攔截,允許 wintun 虛擬網卡通過。

macOS

在 Clash Verge Rev 或 ClashX Meta 中打開 TUN(增強模式)開關,系統會要求輸入登入密碼,用於安裝特權助手以建立 utun 裝置。授權一次即可,之後開關不再詢問。

Linux

建立 TUN 裝置需要 CAP_NET_ADMIN 權限。要麼以 root 執行核心,要麼替核心二進位檔案授權:

sudo setcap cap_net_admin,cap_net_bind_service=+ep /usr/local/bin/mihomo

Android 與 iOS

行動裝置沒有獨立開關:Android 用戶端(Clash Meta for Android、FlClash 等)基於系統 VpnService 運作,iOS 端(Clash Plus 等)基於 Network Extension 的 Packet Tunnel,兩者本身就是虛擬網卡方案。這也是行動裝置能全局接管所有 App 流量的原因。

手動撰寫配置(進階)

直接維護 mihomo 配置檔案時,等效配置如下:

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

auto-route 負責接管預設路由,auto-detect-interface 負責識別真實出口網卡,兩者缺一不可;dns-hijack 把 53 連接埠的 DNS 查詢劫持進核心。

適合開啟 TUN 的情境

• 遊戲與即時語音:UDP 流量只有 TUN 能接管,前提是所用節點支援 UDP 轉送。
• 命令列與開發工具:git clone、curl、套件管理器、容器拉取映像檔等不讀系統代理的操作。
• 不遵循代理設定的用戶端:部分中國大陸軟體、老舊程式、內建硬編碼網路堆疊的應用程式。
• 依進程分流:TUN 接管後核心能看到連線來自哪個進程,可配合 PROCESS-NAME 規則做細粒度分流。

反過來說,以日常網頁瀏覽為主的使用者,開不開 TUN 差別不大,系統代理已經足夠,不必為開而開。

常見衝突與排解

與其他 VPN、加速器共存

每個 VPN 類工具都想接管預設路由,同時開兩個的結果通常是路由表互相覆蓋、兩者都失效。同一時間只保留一個接管者;必須共存時,在另一個工具裡把本機網段和節點伺服器位址加入繞過清單。

流量迴圈

核心自己發往代理伺服器的流量如果也被路由進 TUN,會形成迴圈,表現為開啟瞬間全網斷線。auto-detect-interface 的作用就是讓核心出站流量綁定實體網卡,避開虛擬網卡。手動改路由表時,務必確保節點伺服器 IP 走實體出口。

瀏覽器 DoH 繞過 DNS 接管

Chrome、Edge 的「安全 DNS」會把網域名稱解析交給 DoH 伺服器(走 443 連接埠),核心的 dns-hijack 接不到這些查詢,fake-ip 隨之失效,表現為網域名稱規則對瀏覽器不生效。處理方式是關閉瀏覽器的安全 DNS,把解析交還給核心。

內部網路位址打不開

預設路由被接管後,公司內網、校園網、路由器管理頁可能無法連線。在規則裡為內部網段加上 IP-CIDR 直連規則:

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

虛擬機器、WSL2 與 Docker

Windows 上 Hyper-V 虛擬交換器與 TUN 路由可能衝突,導致 WSL2 斷網或容器無法連外網。可調整虛擬網卡的介面躍點數,讓 WSL2 的流量被正確接管,或在用戶端設定裡排除 Hyper-V 網段。

開啟 TUN 後完全無法上網

1. 確認 auto-route 與 auto-detect-interface 均已開啟。
2. 退出其他代理工具的「增強模式」「全局路由」類功能後再重試。
3. 查看用戶端日誌,確認虛擬網卡建立成功、沒有權限錯誤。
4. 仍不通時關閉 TUN 開關,多數用戶端會自動還原路由表;若未還原則重啟網路服務或重新開機。

常見問題

結論

TUN 模式把代理接管點從應用層下沉到網路層:一塊虛擬網卡接住全部出站 IP 封包,核心依規則逐連線分流。它解決的是系統代理管不到的三類流量——不讀代理設定的應用程式、UDP,以及被污染的 DNS。日常瀏覽用系統代理即可;涉及遊戲、命令列工具或頑固用戶端時,再開啟 TUN,並留意與其他 VPN 工具、瀏覽器 DoH 和內部網段的衝突。