Clash TUN 模式設定教學：虛擬網卡接管完整流量的原理與設定

系統代理與 TUN 模式的接管範圍

Clash 圖形化用戶端常見的「系統代理」開關，本質上是將作業系統的 HTTP 與 SOCKS 代理位址指向本機監聽連接埠。例如 HTTP 代理使用 127.0.0.1:7890，SOCKS5 使用 127.0.0.1:7891。瀏覽器、部分聊天工具及遵循系統設定的應用程式，會主動將要求交給這些連接埠，再由 Clash 依規則選擇 DIRECT、REJECT 或代理節點。

問題在於，並非所有程式都會讀取系統代理。命令列程式可能直接建立 TCP 連線，遊戲啟動器可能使用自己的網路模組，部分軟體還會繞過 HTTP 代理傳送 UDP。此時 Clash 核心雖然正常執行，記錄中卻看不到對應連線。持續修改規則也不會生效，因為流量根本沒有經過規則引擎。

TUN 模式會建立虛擬網卡，並為作業系統寫入對應路由。符合路由條件的封包會先進入虛擬網卡，再由 Clash Meta，也就是 mihomo 核心還原連線資訊、執行 DNS 判斷與規則比對。應用程式不必知道本機正在使用代理，因此命令列工具、獨立更新程式及更多 UDP 程式也能進入統一的分流流程。

一條連線進入 TUN 後會發生什麼

1. 應用程式向目標網域或 IP 發起 TCP、UDP 連線。
2. 系統路由會將對應封包送入 Clash 建立的虛擬網卡。
3. 核心識別原始目標，並結合 DNS 對映還原網域資訊。
4. 規則會由上至下比對，例如 DOMAIN-SUFFIX、GEOIP、GEOSITE 與 MATCH。
5. 連線依比對結果直連、拒絕，或交由指定的代理群組處理。

TUN 並不是將所有連線強制送往同一個節點。「完整流量接管」描述的是更完整的流量入口，不等於 Clash 的 GLOBAL 代理模式。維持 Rule 模式時，區域網路、中國大陸網站與海外服務仍可分別套用不同策略。

啟用前檢查核心、權限與 DNS

確認用戶端使用支援 TUN 的核心

不同圖形化用戶端的選單名稱不完全相同，但核心應為 Clash Meta 或 mihomo。可以在「設定」→「核心」或「設定」→「關於」中查看核心名稱與版本。舊版 Clash Premium 曾提供 TUN 功能，目前持續更新的設定通常以 mihomo 為基礎。若用戶端只能切換傳統 Clash 核心，設定中的部分 tun 欄位可能無法識別。

排查問題時，應同時記錄用戶端版本與核心版本。圖形介面的版本號只代表外殼，不一定等於目前執行中的核心版本。例如用戶端顯示 2.0.0，而「核心」頁面可能顯示 mihomo 1.19.x。真正決定 stack、自動路由與 DNS 行為的是後者。

準備管理員權限或服務模式

• Windows：虛擬網卡與路由修改通常需要管理員權限。建議優先在用戶端的「設定」→「服務模式」中安裝服務，再重新啟動用戶端。
• macOS：首次啟用時可能需要安裝輔助程式，並跳出系統密碼或 Touch ID 驗證。系統設定出現網路擴充功能提示時，必須明確允許。
• Linux：執行中的程序需要建立 TUN 裝置及修改路由的權限。桌面用戶端可能透過 Polkit 提升權限，命令列部署則通常由 systemd 服務管理。
• Android 與 iOS：用戶端通常透過系統 VPN 介面實現流量接管，不需要桌面端的服務模式，但必須允許 VPN 設定。

DNS 必須搭配 TUN 一併檢查

TUN 能接收 IP 封包，但網域分流仍依賴 DNS 資訊。若應用程式先從外部 DNS 取得真實 IP，規則引擎可能只能看到 IP，導致依網域建立的規則比對不穩定。mihomo 常用 Fake-IP 模式建立網域與保留位址之間的對映，再於連線階段還原原始網域。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://223.5.5.5/dns-query
  fallback:
    - https://1.1.1.1/dns-query

198.18.0.0/16 是 Fake-IP 常見的保留範圍，不代表真實的遠端伺服器。看到應用程式連線至此網段時，先檢查是否已由 Clash 接管，不要直接視為 DNS 污染。連接埠 1053 是本機 DNS 監聽範例；若電腦上已有服務使用該連接埠，應改用未被佔用的連接埠，並同步調整呼叫端。

mihomo TUN 設定欄位與 stack 選擇

支援圖形化 TUN 開關的用戶端會自動產生部分設定。需要手動維護 YAML 時，可以先從一組保守參數開始：

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

關鍵欄位逐項說明

• enable：控制 TUN 是否啟用。圖形化用戶端可能在執行期間覆寫此值，應以用戶端目前的開關狀態與執行記錄為準。
• stack：選擇 TUN 網路堆疊實作。mihomo 常見值包括 system、gvisor 與 mixed。
• dns-hijack：將指定的 DNS 流量交給內建 DNS 模組。any:53 涵蓋常見的 UDP 53，補充 TCP 53 可處理較大的 DNS 回應。
• auto-route：自動寫入接管流量所需的系統路由。
• auto-detect-interface：自動識別目前的出口網卡，適合會在 Wi-Fi、有線網路與行動熱點之間切換的裝置。
• strict-route：強化路由限制，減少部分流量繞過 TUN 的情況，但與其他 VPN、虛擬機網路發生衝突時，也應優先檢查此設定。
• mtu：虛擬網卡的最大傳輸單位。乙太網路常見值為 1500，若特定網站卡住或上傳停頓，可測試 1400、1380 等較小數值。

system、gvisor 與 mixed 如何選擇

stack	特點	適用方向
system	較依賴作業系統網路堆疊，通常負擔較低	桌面系統日常使用，優先追求吞吐量與低延遲
gvisor	使用使用者空間網路堆疊處理連線，相容路徑不同	system 下個別 TCP 或 UDP 程式異常時進行測試
mixed	結合不同堆疊的處理方式，兼顧常見連線	mihomo 新設定的通用起點

沒有任何 stack 能在所有系統、驅動程式與應用程式組合上始終領先。建議先使用 mixed，連續測試網頁、影片、命令列下載與即時通訊。若只有某類 UDP 應用程式異常，再切換至 gvisor 比較；若主要關注大型檔案的吞吐量，可以比較 system。

一次本地千兆網路測試中，在同一節點、同一時段下載 1 GB 檔案，system、mixed 與 gvisor 分別約為 87 MB/s、84 MB/s 及 76 MB/s；差距會隨 CPU、系統版本與節點品質而變化。這組數值只用於說明測試方法，不應視為固定的效能排名。每次切換 stack 後都應重新啟動核心，並對同一目標連續測試 3 次。

Windows、macOS 與行動裝置的啟用步驟

Windows：先安裝服務，再開啟 TUN

1. 開啟用戶端，進入「設定」→「核心」，確認目前執行的是 mihomo 或 Clash Meta。
2. 進入「設定」→「服務模式」，選擇安裝服務。系統出現使用者帳戶控制提示時，確認操作。
3. 服務安裝完成後，結束並重新啟動用戶端，確認服務狀態是否顯示為執行中。
4. 返回主介面或「設定」→「網路設定」，開啟「TUN 模式」。
5. 代理模式選擇 Rule，不要將 TUN 開關與 Global 模式混為一談。
6. 開啟記錄，暫時將層級設為 info，造訪一個直連網站與一個代理網站，確認兩類連線都出現規則比對結果。

若開關立即自動關閉，優先檢查服務是否安裝成功、用戶端是否遭安全性原則阻止建立虛擬網卡，以及是否有其他 VPN 正在修改預設路由。Windows 的 Hyper-V、WSL2 與虛擬機軟體也會建立虛擬交換網路，但通常可以共存；只有在路由優先順序或 DNS 被重複接管時，才需要逐項停用測試。

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

1. 進入用戶端「設定」→「核心設定」，確認核心支援 TUN。
2. 在「設定」→「服務模式」或「權限管理」中安裝輔助程式。
3. 開啟 TUN，依提示輸入管理員密碼或使用 Touch ID。
4. 若系統顯示擴充功能遭阻止的提示，開啟「系統設定」→「隱私權與安全性」，允許對應開發者的系統軟體。
5. 返回用戶端重新啟動核心，再檢查「系統設定」→「網路」中是否出現對應的 VPN 或虛擬網路狀態。

在 macOS 上同時開啟系統代理與 TUN 通常沒有必要。多數用戶端會自行處理兩者關係，但排查時可以先關閉系統代理，只保留 TUN，避免同一個要求經過重複入口。若關閉 TUN 後系統代理仍殘留，進入「系統設定」→「網路」→目前網路→「詳細資訊」→「代理伺服器」，確認 HTTP、HTTPS 與 SOCKS 代理是否已恢復。

Android 與 iOS：透過系統 VPN 介面完成接管

Android 用戶端通常在主介面點選啟動後申請 VPN 權限，接著透過 Android VPNService 接管指定流量。可以在用戶端「設定」→「網路」中查看略過區域網路、僅代理所選應用程式、IPv6 與 DNS 選項。啟用分應用程式代理時，清單之外的軟體不會進入 Clash，排查前先確認目前採用的是「僅代理所選應用程式」還是「排除所選應用程式」。

iOS 用戶端依賴 Network Extension 提供的 VPN 功能。匯入訂閱後，需要在用戶端內啟動代理，並允許系統加入 VPN 設定。iOS 不會直接照搬桌面 YAML 中的所有 TUN 參數，具體的 stack、路由與 DNS 功能由用戶端及系統擴充功能決定。桌面端設定中的 auto-route 或服務模式步驟，不應機械式套用至 iPhone。

啟用 TUN 後的驗證方法

使用系統代理無法涵蓋的程式進行測試

只開啟瀏覽器不足以證明 TUN 正常，因為瀏覽器本來就可能遵循系統代理。更合適的驗證方式是暫時關閉系統代理，保留 TUN，然後在終端機執行網路要求：

curl -I https://example.com
curl -4 https://example.com
nslookup example.com 127.0.0.1

第一條檢查 HTTPS 要求，第二條強制使用 IPv4，第三條用於確認本機 DNS 回應。實際執行 nslookup 時，若 DNS 監聽在 1053，而工具不支援直接指定非標準連接埠，應改用支援連接埠參數的 DNS 工具，或暫時檢查用戶端 DNS 記錄。

觀察記錄中的三類資訊

• 入口：記錄應顯示連線來自 TUN，而不是只出現 HTTP 或 SOCKS 入口。
• 目標：網域規則應能顯示原始網域；若始終只有 IP，請檢查 DNS 劫持與 Fake-IP。
• 策略：確認連線命中預期規則與代理群組，而不是直接落到最後的 MATCH。

驗證區域網路時，可以存取路由器管理位址，例如 192.168.1.1。它通常應該直連。設定中可以保留私有位址規則，例如 IP-CIDR,192.168.0.0/16,DIRECT,no-resolve、IP-CIDR,10.0.0.0/8,DIRECT,no-resolve。若啟用 TUN 後印表機、NAS 或路由器後台失去連線，應先檢查這些區域網路規則，而不是先更換代理節點。

常見故障與排查順序

啟用後完全無法連網

1. 關閉 TUN，確認原本的網路本身可以連線至網際網路。
2. 檢查用戶端核心是否正在執行，以及 7890、7891 監聽連接埠是否被其他程序佔用。
3. 查看 TUN 記錄是否出現權限不足、建立裝置失敗或寫入路由失敗。
4. 暫時停用其他 VPN、遊戲加速器與網路過濾工具，再重新啟動核心。
5. 將 strict-route 暫時改為 false 進行對照測試；若網路恢復，再檢查衝突路由。
6. 確認訂閱中至少有一個可用節點，並直接執行節點延遲測試。

網頁能開啟，但遊戲或語音連線失敗

網頁主要使用 TCP，而即時語音、部分遊戲與 QUIC 會使用 UDP。先確認代理節點本身支援 UDP，再檢查代理群組與節點設定是否允許 UDP。將 stack 在 mixed、system 與 gvisor 之間進行單一變數對照，不要同時修改 DNS 與規則。

也可以暫時關閉瀏覽器 QUIC 進行判斷：若關閉後網頁穩定，問題可能集中在 UDP 路徑；若 TCP 也不穩定，則繼續檢查 MTU。特定頁面載入到一半停止、文字能開啟但圖片卡住，常見於路徑 MTU 不相符。可以從 1500 調整至 1400，重新啟動核心後再測試，不建議一開始就降至很小。

DNS 正常回應，但規則總是比對到 IP

先確認 enhanced-mode 是否為 fake-ip，再檢查 dns-hijack 是否涵蓋 UDP 與 TCP 53。部分應用程式使用 DoH 或 DoT，劫持一般 53 連接埠無法讀取加密 DNS 內容。可以透過規則阻止應用程式直連外部 DoH，或讓應用程式改用系統 DNS。不要任意封鎖所有 443 連接埠，因為正常 HTTPS 也會使用該連接埠。

fake-ip-filter 適合排除必須取得真實位址的網域，例如區域網路裝置探索、部分時間同步與特殊登入服務。過度擴大過濾範圍，會讓大量網域繞過 Fake-IP 對映，削弱依網域分流的效果。應依記錄逐筆加入，而不是直接過濾整個頂級網域。

休眠喚醒或切換 Wi-Fi 後失去連線

裝置從有線網路切換至 Wi-Fi 時，預設出口介面與路由可能會改變。啟用 auto-detect-interface: true 後，mihomo 可以自動識別出口，但部分系統仍需要重新啟動核心才能刷新狀態。建議操作順序為：暫停 TUN、切換網路、等待系統取得新 IP、重新啟動核心、再次開啟 TUN。

若每次喚醒都出現相同問題，請記錄故障前後的預設路由與 DNS 位址。Windows 可使用 route print 與 ipconfig /all，macOS 可使用 route -n get default 與 scutil --dns。比較結果通常比反覆重新安裝用戶端更快找出衝突來源。

一套可重複使用的設定順序

第一次設定 TUN 時，建議固定以下步驟：先確認節點可用，再確認 Rule 模式下系統代理正常；接著安裝系統服務或授權網路擴充功能；使用 mixed、自動路由與自動識別介面啟用 TUN；最後補充 DNS 劫持與 Fake-IP。每完成一步都觀察記錄與存取結果。

穩定後再處理效能最佳化。先記錄預設設定下的延遲、下載速度與 CPU 使用量，再單獨切換 stack 或 MTU。延遲測試至少連續執行 20 次，大型檔案測試則維持相同目標與時段。節點負載變化通常比 stack 差異更大，一次測速不能代表長期表現。

TUN 的價值在於將更多流量送入同一套規則系統，而不是取代規則、訂閱與 DNS 設定。入口接管、網域識別、規則比對與節點連線四個環節都正常，虛擬網卡模式才算真正設定完成。