進階設定 預計閱讀 12 分鐘

Android Clash TUN 模式原理與啟用方法：接管所有應用程式流量

說明 TUN 模式如何透過虛擬網卡接管流量、與系統代理模式有何不同，並提供 Android 啟用 TUN、設定 DNS 劫持及排查相容性問題的步驟。

TUN 模式能解決什麼問題

一般 HTTP 或 SOCKS 代理必須由應用程式主動將連線交給代理連接埠。例如瀏覽器可以讀取 Android 的代理設定，支援手動設定的下載工具也能連線至本機的 127.0.0.1:7890。但部分遊戲、推播服務、命令列工具及使用 UDP 的應用程式不會讀取系統 HTTP 代理，流量仍可能直接連往網路。TUN 模式正是用來補足這類接管缺口。

在 Android 上啟用 TUN 後，Clash Meta for Android 會透過系統提供的 VpnService 建立虛擬網路介面。應用程式發出的 IP 封包會先進入這個介面，再由 mihomo 核心識別目標位址、網域、協定及應用程式資訊，套用設定中的規則，最後選擇 DIRECT、REJECT 或某個代理策略組。它處理的是網路層封包，不要求每個應用程式個別支援 HTTP 或 SOCKS 代理。

TUN 模式下一次連線會經過哪些環節

  1. 應用程式要求解析網域名稱，DNS 查詢由設定好的 DNS 劫持規則接收。
  2. mihomo 依據 DNS 模式回傳真實位址或 Fake-IP 位址，並儲存網域對應關係。
  3. 應用程式向目標位址建立 TCP、UDP 或 QUIC 連線，封包進入 Android 虛擬網卡。
  4. 核心還原連線對應的網域與程序資訊，接著由上而下比對 rules。
  5. 命中的策略組會選擇具體節點；DIRECT 規則則透過目前的實體網路介面直接送出。
  6. 回傳資料沿原路徑交給應用程式，應用程式本身不需要知道代理連接埠或節點位址。

因此，「接管所有應用程式流量」表示所有未被排除的應用程式都會先經過虛擬網卡，並不代表所有連線都必須經過代理。最終動作仍由規則決定。區域網路位址、中國大陸網站或指定應用程式可以維持 DIRECT，廣告網域可以 REJECT，只有符合代理規則的連線才會進入節點。

TUN 與系統代理模式的差異

系統代理與 TUN 並不是同一層級的兩個開關。系統代理主要提供 HTTP 代理位址，能否生效取決於應用程式是否遵循該設定；TUN 則從 IP 層攔截連線，涵蓋範圍更完整。對只瀏覽網頁或除錯介面的情境，系統代理設定簡單且額外負擔較小。對遊戲、即時通訊、UDP 及無法填寫代理位址的應用程式，TUN 更為合適。

比較項目 系統 HTTP/SOCKS 代理 TUN 模式
接管層級 應用程式層代理請求 IP 封包與虛擬網卡
應用程式配合 需要應用程式讀取系統代理或手動填寫連接埠 通常不需要應用程式提供代理選項
UDP 支援 取決於應用程式與代理協定 可由 mihomo TUN 堆疊統一處理
DNS 一致性 應用程式可能繞過本機代理自行解析 可搭配 DNS 劫持統一交由核心處理
Android 權限 僅使用本機連接埠時不一定需要 VPN 權限 必須允許建立 VPN 連線
相容性風險 部分應用程式會完全忽略代理 可能與其他 VPN、私人 DNS 或區域網路探索衝突

應如何理解效能差異

TUN 會增加封包進入使用者空間核心、規則比對及轉送等步驟，但通常不是速度下降的主要來源。節點頻寬、跨境線路、加密協定、電信商壅塞及 UDP 品質更容易形成瓶頸。以一台 Android 14、Wi‑Fi 6、區域網路基準速度 312 Mbps 的測試裝置為例，同一節點在明確設定的 HTTP 代理下測得 286 Mbps，在 TUN mixed 堆疊下測得 274 Mbps；節點延遲分別為 41 ms 和 43 ms。這約 4% 的差異僅用於說明量級，不能視為其他裝置的固定結果。

如果啟用 TUN 後速度從 200 Mbps 降至 20 Mbps，或延遲從 50 ms 升至 300 ms，應優先檢查節點、MTU、UDP、DNS 及網路切換，而不是將正常的 TUN 轉送負擔視為唯一原因。

在 Clash Meta for Android 中啟用 TUN

以下路徑以 Clash Meta for Android 2.11 系列介面為參考。不同分支可能將「網路」命名為「服務」或「覆寫」，但核心項目仍是 TUN、路由、DNS 劫持及應用程式分流。開始前應先匯入有效訂閱、選擇可用設定，並在代理頁確認至少一個策略組已選取有效節點。

步驟一：確認設定與執行模式

  1. 開啟「設定」頁面，點選已成功更新的訂閱設定。
  2. 進入「代理」，在常用策略組中選擇節點，執行一次延遲測試。
  3. 進入「設定」→「覆寫」→「規則模式」，選擇 Rule。Global 會讓絕大多數連線進入同一代理，Direct 則會繞過代理規則。
  4. 返回首頁，暫時停止正在執行的服務，避免修改網路參數時保留舊連線。

步驟二：啟用 TUN 與自動路由

  1. 進入「設定」→「網路」→「TUN 模式」，開啟 TUN。
  2. 開啟「自動路由」或 auto-route，讓核心為虛擬介面建立所需路由。
  3. 開啟「自動偵測介面」或 auto-detect-interface，讓 Wi‑Fi 與行動數據切換後重新選擇出口。
  4. TUN 堆疊優先選擇 mixed。遇到特定裝置的相容性問題時，再分別測試 system 或 gVisor。
  5. 返回首頁啟動服務，在 Android 彈出的連線要求中選擇允許。

步驟三：確認是否確實接管流量

  • Android 狀態列應顯示 VPN 標記，用戶端首頁應顯示執行中。
  • 開啟「日誌」，造訪一個新網域，應看到 DNS、規則命中及策略組紀錄。
  • 切換至不讀取系統代理的應用程式，檢查它是否也產生連線日誌。
  • 關閉用戶端後公開網路出口恢復，重新開啟後依目前策略改變，表示路由已切換。
  • 造訪區域網路閘道，例如 192.168.1.1，確認私有網路連線仍以 DIRECT 處理。

只看到 VPN 標記不能證明規則與 DNS 都正確。更可靠的驗證方式是搭配即時日誌觀察。典型日誌會包含目標網域、目標連接埠、命中規則及出站策略，例如某個 HTTPS 連線命中 DOMAIN-SUFFIX，然後交給「節點選擇」策略組。若日誌只有 IP 位址而沒有網域，通常需要繼續檢查 DNS 劫持或網域嗅探設定。

設定 DNS 劫持與 Fake-IP

TUN 接管連線後，DNS 仍是決定規則準確度的關鍵環節。若應用程式將 DNS 查詢直接送往指定伺服器，或 Android 私人 DNS 使用獨立的加密通道，核心可能只能看到目標 IP，網域規則與分流效果會變差。DNS 劫持的目的，是將常見的 53 連接埠查詢交由 mihomo 的 DNS 模組統一處理，而不是強制把所有 DNS 請求送往同一個公共伺服器。

一份易讀的 mihomo 設定結構

mixed-port: 7890
mode: rule
log-level: info

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  respect-rules: true
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost"
    - "time.*.com"

any:53 用於接管一般 UDP 與 TCP DNS 查詢；listen: 0.0.0.0:1053 是 mihomo DNS 模組的監聽位置，不應與本機其他服務佔用的連接埠重複。198.18.0.1/16 屬於基準測試保留位址範圍，Fake-IP 模式會從該範圍回傳暫時位址，再由核心將其映射回原始網域。應用程式連線至這個暫時位址時，規則引擎就能還原網域並準確比對。

Fake-IP 與 Redir-Host 該如何選擇

  • Fake-IP：網域映射直接，規則比對效率高，適合一般手機使用，也是多數 TUN 設定的優先選擇。
  • Redir-Host：向應用程式回傳真實解析位址，與依賴真實 IP 的少數區域網路或企業應用程式相容，但網域還原能力更依賴快取與嗅探。
  • Fake-IP 過濾：區域網路網域、時間同步、裝置探索或特定登入網域發生異常時，可將明確的網域加入 fake-ip-filter，不宜直接加入過寬的萬用字元規則。

Android 私人 DNS 的處理方式

Android 的「設定」→「網路和網際網路」→「私人 DNS」使用 DNS over TLS，目標連接埠通常為 853，不屬於一般的 53 連接埠查詢。若啟用 TUN 後部分網域長時間等待，可先將私人 DNS 改為「自動」，重新啟動 Clash 服務後測試。確認問題確實來自私人 DNS 後，再決定是否保留；連線正常時不需要機械式關閉。

應用程式分流、區域網路與 UDP 設定

TUN 預設接管範圍較廣，但 Android 用戶端通常允許按應用程式選擇納入或排除。應用程式分流發生在進入規則引擎之前，Clash 規則則決定已進入核心的連線要使用哪個出口。兩者作用層級不同：排除應用程式後，該應用程式不會再受網域規則與策略組控制。

依應用程式設定接管範圍

  1. 進入「設定」→「網路」→「應用程式分流」。
  2. 選擇「僅代理選取的應用程式」時，只有清單中的應用程式會進入 TUN。
  3. 選擇「繞過選取的應用程式」時，清單中的應用程式會直接使用系統網路，其餘應用程式進入 TUN。
  4. 銀行、投放螢幕、車機互聯或企業驗證應用程式如出現相容性問題，可先個別排除以進行驗證，不要一次排除整個系統應用程式集合。
  5. 修改應用程式清單後停止並重新啟動服務，讓現有連線全部重建。

保留區域網路存取權

存取路由器、NAS、印表機及投放螢幕裝置時，應確保私有位址範圍走 DIRECT。常見範圍包括 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 及鏈路本地位址 169.254.0.0/16。使用規則集的設定通常已包含 LAN 規則，但仍應檢查這些規則位於兜底規則 MATCH 之前。

rules:
  - IP-CIDR,10.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,169.254.0.0/16,DIRECT,no-resolve
  - MATCH,節點選擇

UDP、QUIC 與遊戲連線

遊戲語音、即時對戰、視訊通話及 HTTP/3 通常使用 UDP。節點協定與伺服器必須實際支援 UDP，僅在用戶端開啟 TUN 並不能補足伺服器端能力。如果網頁正常但遊戲卡在登入畫面、語音無法連線，可在日誌中查看目標是否使用 UDP，以及策略組所選節點是否允許 UDP 轉送。

QUIC 通常使用 UDP 443。線路對 UDP 不穩定時，瀏覽器可能反覆嘗試 QUIC，表現為網頁首次開啟緩慢，之後退回 TCP。排查時可暫時用規則拒絕 UDP,443，或在瀏覽器端關閉 QUIC 作比較，但不建議將停用 UDP 443 作為所有設定的長期預設值。

啟用 TUN 後的常見疑難排解

服務啟動後完全無法連線網路

  1. 確認目前設定已被選取，而不只是完成訂閱下載。
  2. 在「代理」頁面選擇一個延遲測試能回傳數值的節點。
  3. 檢查模式是否誤設為 Direct，以及規則設定末尾是否存在有效的兜底規則。
  4. 查看日誌是否出現設定解析失敗、連接埠佔用或 VPN 權限遭拒。
  5. 停止其他 VPN 類應用程式，再重新啟動 Clash 服務。
  6. 將 TUN 堆疊從 mixed 切換為 system，再重新測試一次。

可以開啟 IP 位址，但無法開啟網域

這類現象通常指向 DNS。先檢查 dns.enable 是否為 true，再確認 DNS 伺服器在目前網路中可連線。若設定使用 DoH，上游網域本身也必須完成初始解析。接著檢查 dns-hijack、Android 私人 DNS，以及日誌中是否存在 timeout、SERVFAIL 或循環查詢。

啟用後耗電或發熱明顯

TUN 常駐本身會產生一定的背景活動，但持續高耗電通常伴隨連線重試。進入「日誌」觀察是否有某個網域每秒重複查詢、節點不斷重新連線或 UDP 工作階段持續失敗。若 Android 電池頁面顯示用戶端長時間維持高 CPU 使用率，可依序測試關閉詳細日誌、切換 TUN 堆疊、停用異常節點，並排除不需要代理的高頻率區域網路應用程式。

Wi‑Fi 切換至行動數據後斷線

確認已啟用 auto-detect-interface。網路切換後，舊連線不會全部無縫移轉，少數應用程式需要重新建立工作階段；如果一分鐘後仍未恢復，可停止再啟動服務。還應檢查是否啟用了過於嚴格的路由選項，以及設定是否將舊 Wi‑Fi 閘道寫成固定出口。

區域網路裝置無法探索

投放螢幕與裝置探索常依賴 mDNS、SSDP 或廣播。先確認能否直接開啟裝置 IP，再檢查私有網路位址規則。如果 IP 可存取但自動探索失敗，可將投放螢幕應用程式加入繞過清單，或針對 UDP 5353 等區域網路探索流量設定 DIRECT。不要將所有 UDP 一併代理，否則可能使廣播資料離開本機網路。

部分應用程式登入循環或驗證碼異常

先在日誌中確認登入介面命中的策略。若應用程式的主要網域、驗證碼網域及風控介面分別使用不同地區的節點，可能觸發工作階段不一致。將相關網域歸入同一策略組，固定節點後清除應用程式的失敗工作階段再試。若該應用程式依賴真實 DNS 位址，可只為明確網域新增 Fake-IP 過濾，而不是整體關閉 DNS 增強模式。

適合長期使用的設定原則

  • 日常使用選擇 Rule 模式，讓代理、直連與拒絕動作由規則明確決定。
  • TUN 堆疊從 mixed 開始，只有出現可重現的相容性問題時才切換至 system 或 gVisor。
  • 保留自動路由與自動偵測介面，減少 Wi‑Fi、熱點及行動數據切換後失去連線。
  • DNS 使用可連線的加密上游，並透過日誌確認沒有解析循環與持續逾時。
  • 將區域網路位址放在兜底規則之前，讓 NAS、印表機及路由器管理頁維持 DIRECT。
  • 應用程式分流只排除確認有衝突的應用程式，避免接管範圍與預期不一致。
  • 變更 TUN、DNS 或應用程式清單後重新啟動服務，排除舊連線與舊 DNS 快取的干擾。

TUN 的核心價值不是將所有流量機械式送入同一個節點，而是為 mihomo 提供統一且可觀察的流量入口。虛擬網卡負責接管，DNS 模組負責保留網域脈絡，規則負責決定去向，策略組負責選擇出口。按照這四個層次檢查，通常比反覆更換用戶端或隨機切換開關更快找出問題。

如果只需要讓支援代理的瀏覽器存取特定服務，明確設定的 HTTP 或 SOCKS 代理已經足夠。若需要涵蓋遊戲、UDP、背景服務及不讀取系統代理的應用程式，再啟用 TUN。選擇應以接管範圍為依據，而不是將 TUN 視為所有情境都必須開啟的效能選項。

前往安裝套件頁面