Clash TUN 模式啟用教學：全域流量接管原理與設定步驟

TUN 模式如何接管全域流量

一般的 Clash 系統代理模式，主要是向作業系統寫入 HTTP 或 SOCKS 代理位址。瀏覽器以及遵循系統代理設定的應用程式會將連線交給 Clash，但部分遊戲、命令列程式、商店用戶端與自行實作網路堆疊的軟體，可能直接連線至目標位址。此時即使系統代理已啟用，這些程式的流量也不一定會進入規則引擎。

TUN 模式採用另一條路徑。Clash Meta（目前常見的核心名稱為 mihomo）會在系統中建立虛擬網路介面，並配合路由規則將符合條件的 IP 流量送入該介面。核心讀取封包的目標資訊，再依據設定中的規則、策略群組與節點決定直連、代理或拒絕。對應用程式而言，它仍是在發起一般網路連線，不需要另外支援 HTTP 代理。

「全域流量接管」描述的是流量進入核心的範圍，不代表所有連線都必須經過同一個代理節點。TUN 負責將流量送入 Clash，最終走向仍由執行模式與規則決定。在規則模式下，區域網路位址、中國大陸網站、代理網站與攔截網域可以分別套用不同策略；在全域模式下，核心通常會將可代理流量交給全域策略群組；在直連模式下，進入核心的流量也可能直接放行。

啟用 TUN 前的版本、權限與設定檢查

首先確認用戶端使用的核心支援 TUN。現代 Clash Meta 或 mihomo 核心通常提供較完整的 TUN、自動路由與 DNS 搭配能力；較早期的 Clash 核心、停止維護的圖形用戶端或經過精簡的行動版實作，可能缺少部分欄位。設定檔能成功匯入，不代表目前的核心一定能辨識其中所有 TUN 選項，因此也要查看用戶端的核心名稱、核心版本與啟動日誌。

系統權限

建立虛擬介面、修改路由表與設定 DNS，通常需要提升權限。Windows 用戶端可能透過服務模式或系統管理員權限執行這些操作；macOS 會要求核准網路延伸功能、VPN 設定或輔助服務；Linux 則常涉及 root、CAP_NET_ADMIN、系統服務以及相應的路由權限。權限提示遭拒後，介面上的 TUN 開關可能看似已開啟，但日誌會顯示介面建立失敗或路由寫入失敗。

權限應透過用戶端提供的服務安裝、授權或網路延伸功能入口完成。反覆以系統管理員身分重新啟動，只能協助判斷是否為權限問題；長期使用時，較適合採用用戶端明確支援的背景服務方案。

訂閱與本機覆寫

訂閱主要提供節點、策略群組與規則，不一定包含適合目前裝置的 TUN 設定。有些圖形用戶端會將 TUN 參數儲存在應用程式設定中，再產生執行時設定；另一些用戶端則直接讀取 YAML 中的 tun 區段。手動編輯訂閱產生的檔案後，下一次更新訂閱可能會覆蓋變更。可靠的做法是使用用戶端的覆寫、混入或設定修補功能，並保留一份能正常啟動的原始設定。

網路環境

• 記錄目前使用的 Wi-Fi、有線網路或行動熱點，確認未啟用其他 VPN。
• 檢查本機是否正在執行虛擬機器、容器網路、遊戲加速器或企業安全軟體。
• 保留目前的 DNS 設定，以便發生網域解析故障時還原。
• 確認訂閱中的節點在一般系統代理模式下至少有一個可以連線。
• 暫停設定檔自動更新幾分鐘，避免排查期間參數遭到替換。

Clash Meta 與 mihomo 的 TUN 設定步驟

使用圖形用戶端時，通常可以在網路、服務模式或 TUN 設定頁面完成啟用。建議先安裝用戶端要求的服務元件，再啟用 TUN，接著查看日誌中是否出現虛擬介面、路由與 DNS 監聽相關紀錄。若用戶端允許選擇網路堆疊，可先從相容性較均衡的選項開始測試，不要一次修改多個進階參數。

直接維護 mihomo YAML 設定時，可以從以下基礎結構開始。不同版本支援的欄位與預設值可能有所變化，最終應以目前核心輸出的設定錯誤與用戶端說明為準。

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

基礎欄位說明

system 傾向使用系統網路堆疊，通常具備較佳的效能與系統協定相容性；gvisor 使用使用者態網路堆疊，在某些環境中的隔離與相容性表現不同；mixed 會依協定採用混合處理方式。哪一種較合適，與作業系統、核心版本、UDP 應用程式及本機安全軟體有關。若網頁瀏覽正常，但遊戲語音、UDP 請求或特定程式出現異常，可以一次只切換一個堆疊選項，再重新啟動核心比較結果。

依序啟用

1. 更新至用戶端支援的穩定核心，並確認目前設定可以正常載入。
2. 安裝或啟用用戶端所需的系統服務、網路延伸功能或虛擬網卡元件。
3. 啟用 TUN，先使用自動路由與自動辨識出口介面。
4. 保持規則模式，選擇一個已確認可用的策略節點。
5. 重新啟動核心，查看是否回報設定欄位、權限、介面或路由錯誤。
6. 分別測試瀏覽器、終端機命令與原本不遵循系統代理的應用程式。
7. 基礎連線穩定後，再啟用嚴格路由或調整網路堆疊。

修改設定後，應完整重新載入核心。只在文字編輯器中儲存 YAML，但用戶端仍使用舊的執行時設定，是常見的誤判原因。可以透過用戶端日誌中的設定載入時間、核心啟動時間與目前運作模式，確認新設定是否已生效。

TUN 模式與 DNS 的搭配方式

TUN 接管 IP 封包，而規則比對經常依賴網域名稱。應用程式會先查詢網域名稱，再連線至回傳的 IP；如果 DNS 查詢繞過 Clash，核心可能只能看到目標 IP，網域規則的比對能力就會受到影響。更複雜的情況是，本機 DNS 回傳了不適合的位址，而代理節點所在的網路實際上能解析出另一組結果，最後就會呈現節點可用但特定網站無法開啟。

mihomo 的 DNS 模組可以統一處理查詢，並與規則分流、Fake-IP 或 Redir-Host 等增強模式搭配。以下結構用於說明各部分的關係，解析伺服器位址應依實際網路與設定來源選擇。

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-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

Fake-IP 模式會為網域回傳保留位址範圍中的暫時位址，並在核心內部保存網域對應關係。當應用程式連線至這個暫時位址時，核心便能還原原始網域並執行網域規則。這種方式有助於保留規則比對資訊，但少數依賴真實 IP、區域網路探索、裝置投放或特殊驗證流程的應用程式，可能需要加入過濾清單。過濾項目應根據明確故障逐項新增，過大的萬用字元範圍會削弱網域對應效果。

dns-hijack 中的 any:53 主要處理傳統 53 連接埠 DNS。應用程式內建的加密 DNS、瀏覽器 DoH 或固定外部解析機制，不一定會經過相同路徑。排查時可以暫時關閉瀏覽器的安全 DNS 功能，讓系統查詢先進入 Clash，以判斷問題是否來自多套 DNS 同時運作。

避免 DNS 迴圈

核心查詢上游 DNS 時，相關流量也需要正確選擇出口。如果 DNS 上游網域本身依賴尚未完成的解析，或查詢被路由規則反覆送回同一個監聽入口，就可能形成啟動階段的解析迴圈。設定較複雜時，應注意預設解析伺服器、代理節點網域解析，以及直連上游的可達性。日誌中連續重複的 DNS 逾時，通常比網頁錯誤頁面更能說明問題。

確認 TUN 已生效的測試方法

介面開關變為啟用狀態只是第一步。完整驗證還需要確認虛擬介面存在、路由已寫入、流量能夠進入核心、規則正確命中，以及 DNS 沒有繞行。建議採用由淺入深的測試順序，每一步只回答一個問題。

1. 查看啟動日誌：確認沒有設定解析失敗、權限不足、虛擬介面建立失敗或路由寫入失敗。
2. 檢查一般網頁：造訪符合直連與代理規則的網站，觀察連線清單中的策略命中情況。
3. 測試不讀取系統代理的程式：先關閉系統代理，只保留 TUN，再執行終端機下載工具或目標應用程式。
4. 觀察連線紀錄：核對網域、目標位址、處理程序資訊與最終策略，確認流量確實經過核心。
5. 測試 UDP：使用確實依賴 UDP 的應用程式進行短時間測試，判斷目前網路堆疊是否相容。
6. 檢查區域網路：開啟路由器、NAS 或印表機位址，確保私有網段沒有被錯誤代理。
7. 切換網路：從 Wi-Fi 切換至熱點後，重新觀察預設介面與路由是否自動更新。

連線紀錄是區分「未接管」與「接管後規則錯誤」的關鍵。如果目標應用程式執行時完全沒有新連線出現，應優先檢查 TUN 介面、路由、應用程式繞過設定與權限；如果連線已出現但選用了錯誤策略，應檢查規則順序、網域辨識與策略群組；如果策略正確但連線逾時，則繼續檢查節點、DNS、MTU、防火牆與遠端服務。

規則模式下的判斷

規則會由上至下比對，命中後通常會停止繼續檢查。TUN 不會改變這項基本順序。若某個網域應走代理卻命中直連規則，需查看它是以網域、目標 IP 還是程序資訊進入規則引擎。寬泛的 IP-CIDR、GEOIP 或提前出現的直連規則，都可能覆蓋後續更具體的處理。兜底規則通常放在規則清單末尾。

常見衝突與分層排查順序

啟用 TUN 後完全斷網

先關閉 TUN，確認基礎網路立即恢復，再查看核心日誌。完全斷網通常與介面建立後核心未正常運作、預設路由指向錯誤、DNS 無回應或權限狀態不完整有關。恢復測試時先關閉 strict-route，保留 auto-route 與 auto-detect-interface，並暫時退出其他 VPN。若裝置同時連線有線與無線網路，應確認核心辨識到真正能夠存取外網的預設介面。

瀏覽器可用，但遊戲或語音失敗

瀏覽器主要使用 TCP 與 HTTPS，遊戲、即時語音及部分即時通訊功能則會使用 UDP。此時應查看 UDP 連線是否進入核心、節點是否支援相應傳輸，以及目前 TUN 網路堆疊是否適合該應用程式。切換 system、gvisor 或 mixed 時應逐項測試，避免同時更改 DNS、節點與規則，否則無法判斷改善來自哪一項。

啟用後無法存取區域網路

確認私有位址範圍仍由直連處理，並檢查嚴格路由是否改變本地網段的出口。常見私有網段包括 10.0.0.0/8、172.16.0.0/12 與 192.168.0.0/16，但實際裝置也可能使用鏈路本地位址、IPv6 區域網路位址或特定多點傳送協定。若能直接開啟裝置 IP，卻無法使用裝置名稱，問題更可能出在本地 DNS、mDNS 或 Fake-IP 過濾。

與其他 VPN、虛擬機器或容器衝突

多個網路工具都可能建立虛擬介面並修改預設路由。企業 VPN、遊戲加速器、虛擬機器橋接、Docker 或容器子網路，都可能與 TUN 的自動路由重疊。排查時先退出其他接管工具，確認 Clash TUN 能獨立正常運作，再逐一恢復。若兩個工具必須共存，需要明確哪些網段由哪個介面處理，並避免雙方都將對方的虛擬網段設為預設出口。

休眠或切換網路後失效

筆記型電腦從休眠恢復、Wi-Fi 漫遊或切換熱點後，預設介面與閘道可能改變。雖然 auto-detect-interface 用於辨識出口，但用戶端未必會在所有系統事件後立即重建路由。可以先重新啟動核心，而不是重新安裝用戶端；若重啟核心即可恢復，應繼續檢查用戶端對網路變化的監聽、背景執行權限與服務狀態。

訂閱更新後 TUN 設定消失

這通常表示參數寫在訂閱產生的檔案中，而用戶端更新時重新下載並替換了該檔案。應將 TUN 與 DNS 參數移至用戶端支援的覆寫層、混入設定或獨立的全域設定。調整後手動更新一次訂閱並重新啟動核心，確認參數仍然存在，才能證明儲存位置正確。

按層級縮小問題範圍

分層排查的重點，是保留可比較的結果。每次只修改一個變數，修改後重新啟動核心，並記錄日誌中的第一個明確錯誤。直接重新安裝用戶端會清除部分現場資訊，也無法說明問題究竟來自權限、路由、DNS 還是節點。

TUN 日常使用設定建議

完成基礎設定後，不必持續增加參數。自動路由、明確的 DNS 方案、容易理解的規則與穩定節點，通常比大量實驗性選項更容易維護。對只使用瀏覽器與一般桌面軟體的裝置而言，系統代理已能涵蓋主要需求；當命令列程式、遊戲或特定應用程式無法遵循系統代理時，再啟用 TUN 會更有針對性。

需要長期使用 TUN 的裝置，應定期留意核心升級後的欄位變化，並在升級前保留可正常運作的設定。出現異常時，先比較升級前後的核心版本、網路堆疊與 DNS 行為。用戶端介面中的設定名稱可能不同，但底層仍可依介面、路由、DNS、規則與節點這五個環節理解。

最終設定目標並不是讓所有流量機械式地通過代理，而是讓需要接管的連線可靠地進入規則引擎，再依用途選擇直連、代理或拒絕。理解這一點後，TUN、全域模式與規則模式之間的差異會更清楚，也能避免將節點故障誤判為虛擬網卡問題。