Clash TUN 模式怎麼開：虛擬網卡接管全域流量的原理與設定步驟

TUN 模式與系統代理的核心差異

Clash 用戶端中常見的「系統代理」與「TUN 模式」並不是功能強弱不同的兩個開關，而是兩種不同的流量導入路徑。系統代理會將 HTTP 與 HTTPS 代理位址寫入作業系統，常見的監聽位址是 127.0.0.1:7890。瀏覽器、聊天工具等會主動讀取系統代理設定的程式，會將連線交給 Clash；忽略系統代理的程式則會繼續直接連線。

TUN 模式會建立一張虛擬網卡，並在系統路由表中加入相應路由。符合路由條件的 IP 封包會先進入虛擬網卡，再由 mihomo 核心識別目標、比對規則，決定使用代理、直連或拒絕。因此，TUN 接管的是網路層流量，不要求每個應用程式都理解 HTTP 或 SOCKS 代理。

哪些情況適合啟用 TUN

• 瀏覽器可以連線，但遊戲啟動器、商店用戶端或桌面應用程式始終直連。
• git、套件管理器及其他命令列程式沒有讀取系統代理。
• 應用程式使用 UDP、QUIC，單純設定 HTTP 代理無法涵蓋。
• 不希望逐一為程式填寫 HTTP_PROXY、HTTPS_PROXY 或 SOCKS5 位址。
• 需要讓同一套 Clash 規則統一處理更多本機連線。

如果只是瀏覽網頁，系統代理通常更簡單，發生問題時也較容易定位。TUN 會修改路由與 DNS 的處理路徑，適合確實有接管需求的情境，不必把它視為安裝後必須啟用的功能。

啟用前先完成權限與服務準備

以下操作以使用 mihomo 核心的 Clash Verge Rev 2.x 設定結構為例。不同用戶端的選項位置可能略有差異，但準備工作大致相同：核心需要足夠權限建立虛擬網卡、寫入路由，並在應用程式結束或重新啟動後正確清理這些設定。

Windows：安裝服務模式

1. 結束其他正在執行的 VPN、網路加速器或虛擬網卡工具，避免首次安裝時發生路由衝突。
2. 開啟用戶端，進入「設定」→「系統設定」→「服務模式」。
3. 選擇「安裝」，在 Windows 使用者帳戶控制視窗中確認系統管理員權限。
4. 安裝完成後，確認服務狀態顯示為「執行中」，再進入「代理」頁面啟用「TUN 模式」。
5. 首次啟用後等待約 3 至 10 秒，讓虛擬網卡與路由完成初始化。

服務模式會讓具備系統管理員權限的背景服務處理虛擬網卡與路由，而圖形介面仍可由一般使用者權限執行。如果點擊安裝按鈕後狀態沒有變化，先完全結束用戶端，再使用「以系統管理員身分執行」啟動一次並重新安裝。企業電腦若限制安裝服務，需請裝置管理員授權。

macOS：允許輔助程式或網路擴充功能

1. 進入用戶端的「設定」→「系統服務」或「服務模式」，選擇安裝輔助程式。
2. 在系統密碼或 Touch ID 提示中確認操作。
3. 若系統阻擋網路元件，開啟「系統設定」→「隱私權與安全性」，在頁面下方允許對應元件。
4. 返回用戶端啟用 TUN；若系統再次詢問是否允許加入 VPN 設定檔，請選擇允許。

macOS 更新後，舊版輔助程式可能需要重新授權。若反覆要求輸入密碼，或 TUN 開關自動關閉，先在用戶端解除安裝服務模式，重新啟動系統，再從目前版本的用戶端重新安裝。不要同時保留兩個 Clash 圖形用戶端的系統服務。

Android：確認 VPN 連線權限

Android 上的 Clash Meta 類用戶端通常會透過系統 VPNService 建立本機虛擬網卡。開啟「設定」→「網路」→「TUN」後，系統會顯示 VPN 連線確認視窗。確認後，狀態列會出現鑰匙或 VPN 圖示。Android 同一時間只能維持一個 VPN 服務，現有的企業 VPN、WireGuard 或其他代理應用程式會被中斷。

Clash TUN 建議參數怎麼設定

對多數桌面情境而言，可以從 stack: mixed、auto-route: true、auto-detect-interface: true 開始，並讓 Clash DNS 接管 53 連接埠的查詢。以下是 mihomo 1.19 系列設定結構可識別的基本寫法：

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: 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
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query

圖形用戶端通常會產生或覆寫其中部分欄位。如果用戶端已提供「TUN 堆疊」、「自動路由」、「DNS 劫持」開關，優先在介面中修改，不要同時編輯訂閱產生的唯讀設定。訂閱更新可能會覆蓋設定內容，但用戶端儲存的全域覆寫通常仍會繼續生效。

堆疊選擇：mixed 作為一般起點

不要因為某個堆疊名稱看起來更進階就頻繁切換。先使用 mixed 執行，分別測試網頁、DNS、下載及需要接管的應用程式。若只有某一類連線失敗，再依序測試 system 與 gVisor；每次修改後都要完整停用並重新啟用 TUN。

自動路由與自動識別出口

auto-route: true 會讓核心自動寫入接管流量所需的路由；auto-detect-interface: true 用於識別目前實際使用的出口網卡。筆記型電腦從有線網路切換至 Wi-Fi，或從家庭網路切換至手機熱點後，自動識別可降低代理連線再次送回 TUN 的機率。

strict-route: true 會加強路由限制，在 Windows 上也有助於減少部分 DNS 請求繞過接管路徑。不過嚴格路由可能影響區域網路探索、虛擬機橋接或企業內網。若啟用後無法存取印表機、NAS 或公司網段，可以先暫時停用 strict-route 進行比較，而不是關閉整套 TUN。

為什麼 DNS 劫持常用 any:53

dns-hijack: any:53 表示將被接管流量中的傳統 UDP/TCP 53 連接埠查詢交由 mihomo DNS 模組處理。如此可讓網域解析結果與規則判斷保持一致，也能減少應用程式繞過系統 DNS 設定的情況。它不會自動接管應用程式內建的 DoH，因為 DoH 本質上是傳送至特定伺服器的 HTTPS 流量，需要另行透過網域或 IP 規則處理。

198.18.0.1/16 是 fake-ip 常用的位址範圍。應用程式查詢網域時，會先取得此範圍內的對映位址，核心再依對映還原原始網域並比對規則。若區域網路裝置、印表機網域或少數依賴真實 IP 的應用程式發生異常，應將相應網域加入 fake-ip 過濾清單，而不是任意改用一般公有 IP 位址範圍。

從介面啟用到確認接管的完整步驟

1. 在「設定檔」頁面更新並選取一份可用設定，確認至少有一個節點可以正常連線。
2. 將執行模式設為「規則」，避免測試時所有流量受到全域策略干擾。
3. 進入「設定」→「Clash 設定」→「TUN」，將堆疊設為 mixed。
4. 啟用「自動路由」、「自動識別出口網卡」及「DNS 劫持」。
5. 確認服務模式已安裝並正在執行，然後開啟 TUN 主開關。
6. 先測試會遵循系統代理的瀏覽器，再測試原本無法由系統代理接管的應用程式。
7. 開啟用戶端連線記錄，檢查目標網域是否出現，以及最後命中了哪條規則與策略群組。

為確認效果，可以暫時關閉「系統代理」，只保留 TUN。若瀏覽器與目標應用程式仍能依照 Clash 規則連線，表示虛擬網卡路徑已正常運作。測試結束後是否重新啟用系統代理，取決於用戶端實作；mihomo 通常能同時處理兩種入口，但排查期間一次只保留一種入口會更清楚。

Windows：檢查虛擬網卡與路由

在 PowerShell 中執行以下命令，即可查看目前的網路介面卡與 IPv4 路由。不同用戶端建立的網卡名稱可能包含 Mihomo、Clash 或 Meta：

Get-NetAdapter | Sort-Object Status, Name
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object RouteMetric |
  Select-Object -First 20

虛擬網卡應處於 Up 狀態，路由表中會出現由 TUN 管理的項目。不要只根據預設路由是否變成虛擬網卡來判斷成敗，因為不同系統與核心版本可能採用分段路由、策略路由或更具體的路由項目。

用記錄確認規則，不要只看網頁結果

進入「記錄」頁面，將層級設為 info。啟動待測試的應用程式後，應看到目標位址、網路類型及命中策略，例如 TCP、UDP、MATCH、DIRECT 或特定代理群組。如果完全沒有對應連線，表示流量未進入核心；如果記錄存在但顯示 DIRECT，應檢查規則順序；如果已選擇代理卻發生逾時，則繼續檢查節點、UDP 支援或遠端服務。

TUN 啟用後無法連線的排查順序

排查時不要同時修改堆疊、DNS、節點與規則。依照「服務權限 → 虛擬網卡 → DNS → 規則 → 節點」的順序逐層確認，通常能更快找到故障位置。

第一步：確認基本設定與節點本身可用

關閉 TUN、啟用系統代理，用瀏覽器測試目前節點。如果此時也無法連線，問題不在虛擬網卡，應先處理設定、策略群組或節點狀態。TUN 只會改變流量進入核心的方式，不會修復失效的節點。

第二步：區分 DNS 故障與路由故障

網域連線失敗但已知 IP 可以存取時，通常應優先檢查 DNS。若用戶端記錄中沒有 DNS 查詢，請檢查 dns.enable 與 53 連接埠劫持；若有查詢但上游逾時，請更換可連線的上游 DNS，並確認用於解析代理伺服器網域的引導 DNS 可以直連。

如果網域可以解析，但 TCP 連線完全沒有出現在記錄中，更可能是路由未寫入、虛擬網卡未啟動，或流量已被另一個 VPN 提前接管。此時先結束其他 VPN 與網路過濾工具，再關閉並重新啟用一次 TUN。

第三步：處理區域網路與虛擬機網路

常見的私有位址包括 10.0.0.0/8、172.16.0.0/12 與 192.168.0.0/16。家用路由器、NAS 與印表機通常應比對 DIRECT。規則需要放在兜底 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
  - MATCH,節點選擇

虛擬機與容器網路也可能使用這些位址範圍，因此不能機械式地將所有私有位址排除在 TUN 之外。若需要代理虛擬機內部流量，應先確認流量實際經過主機的哪張網卡，再決定使用 DIRECT 規則、路由排除，或在虛擬機內另外設定代理。

效能、IPv6 與長期使用建議

TUN 增加了一層虛擬網卡與使用者空間處理，但日常網頁與下載速度通常更受節點延遲、線路壅塞、協定及遠端伺服器限制。評估效能時，應使用同一個節點與同一個目標檔案，分別測試關閉及啟用 TUN 的結果，每組至少執行三次。只比較一次測速，容易受到快取與瞬間線路波動影響。

出現高 CPU 使用率時，先將記錄層級從 debug 調回 info，停止持續連線測試，再觀察具體程序。大量 UDP 工作階段、P2P 軟體及頻繁 DNS 查詢，都可能明顯增加連線數量。桌面用戶端的連線頁面可用於找出異常活躍的程式。

IPv6：未確認網路條件前不要強制啟用

如果本地網路、代理節點及規則集都已正確支援 IPv6，可以啟用相應功能；如果電信業者只提供不穩定的 IPv6，可能出現應用程式優先嘗試 AAAA 位址後等待逾時。排查時可暫時關閉 Clash 設定中的 IPv6，再比較相同目標的連線時間。不要為了修復單一網站，就在整個作業系統中永久停用 IPv6。

保留一套可回復的設定

• 記錄目前可用的堆疊類型、DNS 模式與 strict-route 狀態。
• 用戶端或 mihomo 核心更新後，先確認服務模式仍在執行。
• 訂閱更新後檢查策略群組名稱，避免本地規則指向已不存在的群組。
• 修改 YAML 前先使用用戶端的設定檢查功能，縮排統一使用空格。
• 遇到斷線時先關閉 TUN；若網路立即恢復，再依照本文順序逐項排查。

TUN 的重點不是把所有開關全部開啟，而是讓權限、路由、DNS 與規則形成完整鏈路。先確認虛擬網卡成功建立，再透過記錄判斷流量是否進入核心，最後檢查命中的規則與出口。依照這個順序處理，瀏覽器可用但桌面程式無法連線、啟用後網域失效、區域網路裝置消失等問題，都能拆解成清楚的檢查步驟。