TUN 模式的流量接管原理

一般的系統代理模式仰賴作業系統向應用程式提供 HTTP 或 SOCKS 代理位址。瀏覽器、部分下載工具與遵循系統網路設定的軟體，會主動將連線交給 Clash；但遊戲用戶端、命令列程式、獨立更新程式，以及自行實作網路堆疊的應用程式，可能直接連線至目標位址。此時即使用戶端介面顯示「系統代理已啟用」，這些連線仍可能繞過代理連接埠。

TUN 模式會建立虛擬網路介面，並配合路由規則將指定流量送入該介面。Clash 核心從虛擬介面讀取 IP 封包、還原連線目標，再依照設定檔中的代理規則選擇 DIRECT、REJECT 或某個代理策略。回傳資料會經由相同鏈路交還給應用程式，因此應用程式通常不需要知道本機代理連接埠，也不必額外支援 HTTP 或 SOCKS 協定。

這裡的「全域流量接管」描述的是流量進入 Clash 的範圍，不等同於代理模式中的 GLOBAL。啟用 TUN 後仍可使用 Rule 規則模式：區域網路位址直連、特定網域名稱走代理、廣告網域拒絕，其餘連線則依照兜底規則處理。只有將執行模式切換為 Global，才會讓可處理的連線統一使用所選的代理策略。

TUN 主要處理第三層 IP 流量。網域名稱比對還依賴 DNS 解析結果與核心的網域映射機制；UDP、QUIC、IPv6 能否完整運作，則與用戶端使用的核心、節點協定、系統權限及設定內容有關。現代 mihomo 核心通常提供較完整的 TUN 能力，但不同桌面用戶端對設定項目的呈現方式並不相同。

啟用 TUN 前的檢查項目

先確認目前的訂閱可以正常使用。選擇可用節點，在僅啟用系統代理的狀態下瀏覽網頁，並檢查規則清單是否命中預期策略。如果訂閱本身解析失敗、節點無法連線或規則設定錯誤，啟用 TUN 只會擴大故障範圍，不會修復基礎連線問題。

  1. 確認用戶端核心：查看用戶端的核心資訊或「關於」頁面。較新的 mihomo 核心支援 TUN、自動路由與 DNS 劫持等參數；較早的 Clash 核心或精簡版用戶端可能缺少部分選項。
  2. 保留目前設定：匯出正在使用的設定檔，或記錄訂閱名稱、代理模式與 DNS 設定。修改 YAML 時要保持空格縮排一致，不能使用 Tab 鍵取代縮排。
  3. 確認權限方式：Windows 通常透過服務模式或系統管理員權限操作虛擬網卡；macOS 可能要求系統管理員授權；Linux 通常需要 root 權限，或為程序授予網路管理能力。
  4. 退出其他 VPN：同一套系統中同時執行多個虛擬網卡工具，容易發生預設路由、DNS 與防火牆規則競爭。行動平台通常還限制同一時間只能啟用一個系統 VPN 通道。
  5. 記錄區域網路環境：如果需要存取印表機、NAS、開發設備或公司內網，應記錄其位址範圍，啟用後優先驗證這些直連資源。

mihomo TUN 設定參數

多數圖形化用戶端會提供 TUN 開關，並自動產生基本參數。需要手動維護 YAML 時，可以從精簡設定開始，再依照系統狀況加入嚴格路由、MTU 等選項。以下展示的是常見結構，實際可用欄位應以用戶端整合的核心版本為準。

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

enable 與 stack

enable 控制 TUN 功能是否啟動。stack 決定核心處理網路資料的方式，mihomo 常見值包括 system、gvisor 與 mixed。系統堆疊通常效能直接；gVisor 使用者空間網路堆疊在部分環境中相容性較佳；mixed 則混合處理 TCP 與 UDP。若用戶端已提供建議值，優先保留用戶端預設設定；遇到特定應用程式無法連線或 UDP 異常時，再逐項切換並測試。

auto-route 與 auto-detect-interface

auto-route 讓核心自動新增必要路由，將系統流量導向虛擬介面。auto-detect-interface 用於識別實際出口網卡，避免代理伺服器連線再次進入 TUN 而形成迴圈。設備在有線、無線與行動熱點之間切換後，如果所有連線突然中斷，可以先重新啟動 TUN，讓核心重新判斷出口介面。

dns-hijack 與 DNS 設定

dns-hijack 中的 any:53 用於接管傳統 53 連接埠的 DNS 查詢，讓網域名稱解析更容易與 Clash 規則保持一致。它無法直接攔截應用程式內建的 DoH 或 DoT，因為加密 DNS 使用的連接埠與協定不同。只設定 DNS 劫持卻未啟用核心 DNS 模組，也可能造成查詢失敗，因此應同時確認設定中的 dns.enable 以及 nameserver、fallback 或策略解析項目是否有效。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

fake-ip 模式會為網域名稱回傳保留位址範圍內的映射位址，核心據此保留網域名稱資訊並比對規則。少數區域網路設備、遊戲登入服務或依賴真實 DNS 回傳值的程式可能不相容於 fake-ip；可將相關網域名稱加入過濾清單，或依照用戶端能力改用其他增強模式。不要任意變更 fake-ip 位址範圍後，又讓它與區域網路路由使用相同網段，否則會產生位址衝突。

strict-route 與 MTU

strict-route 會強化路由限制，在部分系統上有助於減少流量繞行，但也更容易暴露公司 VPN、虛擬機網卡與特殊路由之間的衝突。建議先使用用戶端預設值，確認基礎連線穩定後再啟用。MTU 控制單一封包大小；網頁可以開啟但上傳卡住、部分網站持續逾時，或遊戲登入後斷線時，可以測試 1400 至 1500 範圍內的數值，每次只修改一個參數並重新連線。

Windows、macOS、Linux 與行動平台設定

Windows：服務模式與虛擬網卡

Windows 圖形化用戶端通常會將 TUN 放在設定頁、服務模式頁面或主介面的網路開關中。先安裝用戶端提供的服務元件，再以系統管理員權限確認安裝。服務模式可讓背景服務負責建立虛擬網卡與修改路由，日常啟動用戶端時不必反覆提升整個介面程序的權限。

  1. 關閉目前正在執行的其他 VPN、遊戲加速器，以及可能接管網路的安全工具。
  2. 在用戶端設定中安裝或啟用 Service Mode、服務模式或系統服務。
  3. 選擇 Rule 模式並確認訂閱節點可用，然後開啟 TUN Mode。
  4. 接受系統權限提示，等待虛擬網卡建立完成。
  5. 依序測試網頁、命令列工具、目標應用程式與區域網路資源。

如果開關立即復位，可檢查服務是否正在執行，以及用戶端日誌中是否出現建立介面、寫入路由或存取驅動程式失敗等資訊。Windows 的 Hyper-V、WSL、虛擬機軟體會增加虛擬交換器與網卡，但存在這些元件不代表一定衝突；應根據路由表與實際出口判斷，而不是直接刪除所有虛擬介面卡。

macOS：授權與 utun 介面

macOS 上的用戶端通常透過系統網路延伸功能或具備權限的輔助程序建立 TUN。首次啟用時可能出現系統管理員密碼、VPN 設定或網路延伸功能授權提示。完成授權後，可以在系統網路設定中看到對應的 VPN 狀態；在終端機執行 ifconfig 時，也可能出現新的 utun 介面。

如果 TUN 已連線但沒有流量，先檢查系統中是否仍啟用另一項 VPN，再確認用戶端沒有將代理伺服器本身的連線重新送入虛擬介面。使用企業網路設定描述檔的 Mac 可能受到管理員策略限制；這類限制需要在系統管理範圍內處理，反覆重新安裝用戶端通常無法改變策略結果。

Linux：權限、路由與轉送

Linux 需要系統提供 /dev/net/tun，並允許程序建立介面與修改路由。以 root 執行可用於短期驗證，但長期部署更適合透過 systemd 服務、容器權限或 capabilities 明確授予所需能力。精簡系統、容器與受限伺服器還要確認核心是否啟用了 TUN 設備。

ls -l /dev/net/tun
ip addr show
ip route show
ip rule show

這些命令可用於確認設備節點、虛擬介面、預設路由與策略路由。Linux 上的常見問題還包括 nftables 與 iptables 規則並存、Docker 橋接網路位址範圍重疊、伺服器已有策略路由，以及防火牆未允許 TUN 介面流量。排查時應先保存現有網路規則，不要在遠端伺服器上直接清空防火牆或預設路由，以免失去管理連線。

Android 與 iOS：系統 VPN 通道

行動用戶端通常借助 Android VPNService 或 Apple Network Extension 建立本機 VPN 通道，介面中的「VPN」、「增強模式」或「TUN」名稱可能不同。首次連線需要接受系統 VPN 授權。Android 可依照用戶端能力設定分應用程式代理或排除應用程式；iOS 與 iPadOS 的具體選項則取決於用戶端實作與系統權限。

行動系統通常只允許一個一般 VPN 設定處於啟用狀態，因此 Clash 類用戶端與公司 VPN、其他代理工具不能同時佔用通道。系統省電策略也可能暫停背景用戶端，表現為鎖定螢幕一段時間後連線中斷。可為用戶端保留背景執行權限，並避免同時啟用會重複修改 DNS 的網路工具。

如何確認 TUN 已經接管流量

僅觀察開關狀態不足以判斷鏈路是否完整。可靠的驗證方式應同時檢查虛擬介面、用戶端日誌、規則命中結果與實際應用程式連線。建議依照以下順序操作：

  1. 查看系統是否出現新的 TUN、utun 或用戶端虛擬介面，並確認介面處於啟用狀態。
  2. 開啟用戶端連線清單，使用原本不遵循系統代理的程式發起請求，觀察是否出現對應目標位址或程序記錄。
  3. 檢查規則命中結果。區域網路位址應依照 LAN 或私有位址規則直連，目標網站應進入預期的策略群組。
  4. 暫時關閉系統代理但保留 TUN，再測試瀏覽器與命令列連線。如果連線仍由用戶端記錄，表示流量並非僅靠系統代理進入核心。
  5. 分別測試 TCP、UDP、IPv4、IPv6 與 DNS。並非所有節點都支援相同的 UDP 或 IPv6 能力，應將節點限制與 TUN 故障區分開來。

Windows 可以使用 route print 或 PowerShell 的 Get-NetAdapter 查看介面；macOS 可使用 route -n get default 與 ifconfig；Linux 可使用 ip route 與 ip rule。診斷時應比對啟用前後的差異，而不是只看到一條預設路由就判斷設定正確。

常見衝突與逐步排查

啟用後所有應用程式都無法連線

先關閉 TUN，確認系統網路可以恢復，再檢查代理節點本身。接著查看日誌中是否出現介面建立失敗、預設網卡識別錯誤、路由迴圈或 DNS 逾時。若設備同時連線有線與無線網路，可暫時只保留一個實際出口，然後重新啟用 TUN。手動指定介面應作為自動偵測失敗後的處理方式；網卡名稱變更後也要同步更新。

網頁可以開啟，但遊戲或語音無法連線

這類情況通常需要檢查 UDP。確認所選節點與協定支援 UDP，策略群組沒有選擇只適用於 TCP 的鏈路，並查看用戶端是否記錄到對應的 UDP 工作階段。若應用程式使用 QUIC，可以暫時停用應用程式內的 QUIC 進行對照測試，但最終仍應從節點能力、規則命中結果與 TUN 堆疊相容性找出原因。

啟用後無法存取 NAS、印表機或路由器

檢查私有位址範圍是否被錯誤傳送至代理。常見區域網路範圍包括 10.0.0.0/8、172.16.0.0/12 與 192.168.0.0/16，但企業內網也可能使用其他位址。確保設定允許區域網路路由直連，並檢查 fake-ip 位址範圍沒有與實際網路重疊。以網域名稱存取失敗但使用 IP 可以存取時，應優先檢查本地域名解析與 fake-ip 過濾設定。

休眠或切換 Wi-Fi 後連線失效

網路恢復後，實際出口介面與預設路由可能已經變更，而 TUN 仍保留舊狀態。先停止 TUN，等待系統取得新的 IP 與 DNS，再重新啟用。若頻繁發生，可升級至用戶端支援的穩定核心版本，並檢查是否已啟用自動偵測介面。行動設備還需要檢查背景執行與省電限制。

與 Docker、虛擬機或公司 VPN 衝突

先比較各虛擬網卡使用的位址範圍與路由優先順序。Docker 橋接網路、虛擬機 NAT、公司 VPN 與 TUN 若宣告相同網段，系統可能將流量送往錯誤介面。處理方向包括調整本機虛擬網段、為公司內網新增明確的直連路由、關閉未使用的網路元件，或在無法同時執行時依情境切換。不要同時大幅修改 DNS、路由、MTU 與防火牆，否則很難判斷是哪項調整生效。

TUN 模式常見問題

啟用 TUN 後還需要啟用系統代理嗎？

通常不必同時依賴系統代理，因為 TUN 已透過虛擬介面接管符合路由條件的流量。部分用戶端會同時啟用兩者，以相容特定應用程式，但這不是判斷 TUN 是否運作的必要條件。排查時可以關閉系統代理、保留 TUN，再觀察連線清單。

TUN 模式會讓所有流量都經過代理節點嗎？

不會自動變更規則模式。TUN 決定流量如何進入 Clash，Rule、Global 與 Direct 則決定進入後如何處理。使用 Rule 模式時，連線仍會依照設定檔由上而下比對，分別走直連、拒絕或代理策略。

為什麼啟用後用戶端顯示 TUN 設備建立失敗？

常見原因包括系統權限不足、服務元件未安裝、TUN 設備無法使用、已有 VPN 佔用介面，或安全策略阻止修改網路。應先查看日誌中的具體錯誤，再檢查服務狀態與系統授權，不要只是不斷點擊開關。

system、gvisor 與 mixed 該選哪一個？

優先使用用戶端針對目前平台提供的預設值。基礎網路正常但特定 TCP、UDP 應用程式異常時，再切換其他堆疊進行對照。不同核心版本與作業系統的表現可能不同，不存在適用於所有設備的固定選擇。

TUN 模式能接管應用程式內建的加密 DNS 嗎？

傳統的 53 連接埠 DNS 可以透過 dns-hijack 接管，但應用程式內建的 DoH 或 DoT 使用加密連線，無法只靠 any:53 直接攔截。可以在應用程式中關閉獨立安全 DNS，或透過網域規則、策略與系統層級管理能力處理。

穩定啟用的建議順序

先確保訂閱、節點與 Rule 模式在系統代理下運作正常，再安裝所需服務並啟用 TUN。首次測試只保留自動路由、自動偵測介面與基本 DNS 設定，確認瀏覽器、命令列、UDP 應用程式及區域網路資源都能依規則存取。之後再依照實際問題調整 stack、strict-route、MTU 或 fake-ip 過濾項目。

TUN 的核心價值，是將原本不會主動使用代理的應用程式連線納入統一規則處理。穩定性取決於路由、DNS、權限與代理節點共同運作，因此排查時應分成四個層面檢查：「虛擬介面是否建立」、「流量是否進入核心」、「規則是否命中」以及「節點是否能傳輸」。逐層確認比反覆切換所有選項更容易找到故障位置。