TUN 路由 預計閱讀 13 分鐘

TUN ROUTING CHECK

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

說明虛擬網卡如何接收未使用系統代理的流量，並依序完成權限、DNS、路由與應用程式衝突檢查。

TUN 模式能解決什麼問題

一般系統代理必須由應用程式主動讀取作業系統中的代理設定。瀏覽器、部分下載工具和常見桌面應用程式通常能透過這種方式，將 HTTP 或 HTTPS 請求交給 Clash；但遊戲啟動器、命令列程式、獨立更新程式，以及自行實作網路堆疊的應用程式，可能會直接連線至目標位址。此時即使系統代理開關已開啟，這些連線也不會經過 Clash。

TUN 模式會建立虛擬網路介面，並將相應路由寫入作業系統。符合路由條件的 IP 封包會先進入虛擬介面，再由 Clash 或 mihomo 核心識別連線目標、執行規則比對，並選擇直連或代理出口。由於它處理的是網路層的流量入口，涵蓋範圍通常比系統代理更廣。

「TUN 接管」和 Clash 的「全域模式」不是同一項設定。TUN 決定流量能否進入核心；規則、全域、直連等執行模式，則決定流量進入核心後如何選擇出口。啟用 TUN 後仍可使用規則模式，讓中國大陸位址直連、指定網域名稱走代理，也能暫時切換至全域模式進行排查。

虛擬網卡接管流量的實際路徑

應用程式發起連線後，作業系統會先查詢本機路由表。啟用 TUN 且自動路由生效時，用戶端會新增指向虛擬介面的路由，同時保留區域網路、預設閘道和必要系統位址的可達路徑。封包抵達 TUN 介面後，核心會還原連線資訊，再將目標交由規則引擎處理。

  1. 應用程式要求解析網域名稱，DNS 查詢會進入系統解析器或 Clash DNS 模組。
  2. 作業系統依據路由表，將目標連線傳送至虛擬網卡。
  3. Clash 會依網域名稱、目標 IP、連接埠、程序資訊或規則集進行比對。
  4. 命中的策略群組會選擇具體的代理節點或直連出口。
  5. 出站連線透過實體網卡傳送，回傳資料再沿著虛擬介面交還給應用程式。

在這條路徑中，DNS 與路由必須保持一致。如果網域名稱由外部 DNS 直接解析，而規則又依賴網域分類，核心可能只能看到解析後的 IP，導致預期的網域規則未命中。使用 mihomo 的 Fake-IP 增強模式時，DNS 模組會為網域名稱回傳受控的虛擬位址，並在內部保存網域名稱與連線的對應關係。應用程式連線至該位址時，核心就能還原原始網域名稱，再執行網域規則。

Fake-IP 並非所有環境都適合固定使用。區域網路裝置探索、某些遊戲、企業內網網域名稱，以及依賴真實位址判斷的程式，可能需要加入排除清單；如果用戶端支援，也可以改用 Redir-Host。選擇方式應以網域規則識別是否穩定、區域網路服務是否可達為準。

啟用前檢查核心、訂閱與權限

先確認用戶端使用的核心支援 TUN。目前常見的 mihomo 核心提供 TUN、自動路由、介面自動偵測和多種協定處理能力，但不同圖形化用戶端顯示的開關名稱不完全一致。有些用戶端將 TUN 放在「設定」或「服務模式」中，有些則要求先安裝系統服務。已停止更新的舊用戶端可能仍搭載較早版本的核心，設定欄位與作業系統相容性也可能不同。

一、更新並載入有效訂閱

TUN 只會改變流量入口，不會修復失效節點。啟用前請先手動更新訂閱，確認目前設定已載入，並在策略群組中選擇可連線的節點。可以先使用系統代理測試瀏覽器連線：若一般代理也無法建立連線，應先檢查訂閱網址、節點狀態、策略群組選擇和本機網路。

二、準備系統權限

建立虛擬網卡與修改路由通常需要較高權限。Windows 用戶端可能要求安裝服務元件，或以系統管理員權限完成首次設定；macOS 會顯示網路延伸功能或 VPN 設定授權；Android 用戶端通常透過系統 VPN 介面接管流量，並跳出 VPN 連線確認。完成授權後，應回到用戶端檢查 TUN 狀態，而不是只根據系統彈窗判斷。

三、記錄原有網路設定

啟用前請記錄目前使用中的 VPN、虛擬機器網卡、公司安全用戶端、DNS 工具和預設閘道。多個程式同時修改預設路由或 DNS 時，後啟動的一方可能會覆寫前一方。排查時應一次只保留一個流量接管工具，確認基礎連線後再逐項恢復其他程式。

Clash TUN 模式啟用步驟

不同用戶端的介面名稱有所差異，但執行邏輯大致相同。以下順序適用於使用 mihomo 核心的常見桌面用戶端。如果用戶端提供圖形化開關，請優先透過介面修改；直接編輯 YAML 前，應確認用戶端不會在儲存設定時覆寫該段設定。

  1. 啟動用戶端並更新目前訂閱，確認設定檔沒有解析錯誤。
  2. 在代理或策略群組頁面選擇可連線的節點，並將執行模式維持為「規則」。
  3. 進入設定頁面，找到 TUN、虛擬網卡或流量接管相關選項。
  4. 如果介面要求安裝服務模式、輔助服務或網路延伸功能，請先完成安裝與系統授權。
  5. 啟用 TUN，並開啟自動路由；如果支援介面自動偵測，也可以一併啟用。
  6. 檢查用戶端狀態區，確認 TUN 已在執行，而不是停留在「等待授權」或「啟動失敗」。
  7. 關閉系統代理進行一次覆蓋測試，觀察原本不讀取代理的應用程式是否仍能依規則連線。

以下是用於說明欄位關係的 mihomo 設定片段。實際可用欄位取決於用戶端內建的核心版本，圖形化用戶端產生的設定應以其介面和日誌為準。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

enable 控制 TUN 是否啟動；auto-route 讓核心自動加入所需路由；auto-detect-interface 用於識別目前的實體出站介面；stack 決定 TUN 封包使用的網路堆疊實作。部分用戶端會提供 system、gVisor 或 mixed 等選項，支援情況會隨平台與核心版本而變化。通常先使用用戶端預設值，只有遇到特定 UDP、效能或相容性問題時才切換。

範例中的公共 DNS 僅用於展示欄位結構。實際環境可使用本地網路允許存取的解析服務，或依照訂閱與用戶端說明設定 DoH、DoT。關鍵是 DNS 請求應能穩定抵達解析器，並與規則比對流程保持一致。

依 DNS、路由與規則驗證接管結果

開關顯示為啟用，不代表所有連線都已正常。驗證應分層進行，先查看用戶端日誌，再檢查 DNS 和路由，最後檢查具體應用程式。如此可區分是虛擬網卡未啟動、規則選錯出口，還是目標應用程式本身有限制。

檢查用戶端日誌

啟動 TUN 後，查看日誌中是否出現權限不足、介面建立失敗、路由寫入失敗或連接埠占用。接著開啟目標應用程式，日誌應出現相應的連線記錄。完全沒有記錄，通常表示流量沒有進入 TUN；有記錄但連線失敗，則繼續檢查規則命中、節點狀態和 DNS。

檢查網域名稱解析

執行一次系統 DNS 查詢，觀察是否能取得結果。在 Fake-IP 模式下，部分一般網域名稱可能回傳設定範圍內的虛擬位址，這是對應流程的一部分，不代表目標伺服器的真實位址發生變化。如果所有網域名稱都逾時，應檢查 DNS 監聽、上游解析器、防火牆以及其他 DNS 軟體。

檢查規則命中情況

在連線清單或日誌中找到測試網域名稱，確認它命中預期的規則與策略群組。在規則模式下，最終規則通常會處理未被前面規則比對到的連線。如果最終規則指向直連，即使 TUN 已接管，相關連線仍會經由本地網路直接發出。

分別測試 TCP、UDP 與區域網路

瀏覽器存取主要只能驗證 TCP 與 DNS，無法涵蓋所有情境。還應測試需要 UDP 的應用程式，並存取路由器管理位址、印表機或區域網路服務。如果外部連線正常但區域網路無法存取，應檢查區域網路位址是否被自動路由錯誤接管，以及用戶端是否提供繞過私有位址的設定。

觀察結果 優先檢查 處理方向
TUN 啟動後立即關閉 權限、服務元件、虛擬網卡 重新授權並檢查啟動日誌
應用程式連線沒有日誌 自動路由、預設介面、其他 VPN 恢復單一接管工具後重建路由
日誌有連線但網域名稱逾時 DNS 監聽與上游解析 檢查 DNS 設定及防火牆規則
瀏覽器正常，遊戲失敗 UDP、網路堆疊、遊戲程序規則 查看 UDP 日誌並測試其他堆疊
外部網路正常，區域網路失去連線 私有位址路由、介面選擇 調整區域網路繞過與自動路由

常見衝突與恢復順序

TUN 異常多發生在權限、DNS、路由和應用程式衝突四個層面。處理時應維持固定順序，不要直接重新安裝用戶端。每完成一步就重新測試，並觀察日誌是否出現變化。

TUN 已啟用但裝置無法連上網路

先關閉 TUN，確認基礎網路能夠恢復。接著檢查所選代理節點和最終規則。如果直連與代理都失敗，再查看 DNS 是否被設定為目前無法連線的位址。基礎網路恢復後，重新啟動用戶端並啟用自動路由；若仍然失敗，請暫時退出其他 VPN、虛擬機器網路管理工具和獨立 DNS 程式。

重新啟動或切換網路後失效

從有線網路切換至 Wi-Fi、連線至行動熱點或喚醒裝置後，預設出口介面可能會改變。啟用介面自動偵測可以減少手動設定，但用戶端仍可能需要重新建立 TUN。先關閉再重新啟用 TUN，確認新的預設閘道已被識別。經常切換網路的裝置也應避免在設定中固定已不存在的介面名稱。

區域網路裝置無法存取

印表機、NAS、路由器管理頁面通常使用私有位址或本地域名。請檢查規則是否允許這些位址直連，並確認路由沒有將區域網路流量錯誤送往代理出口。網域名稱類型的區域網路服務還可能依賴本地 DNS 或多點傳送探索；必要時將對應網域名稱加入 Fake-IP 排除項，並保留本地解析流程。

部分應用程式反覆連線或登入異常

先從連線日誌確認目標網域名稱和出口。如果應用程式依賴真實 IP、區域網路迴環或特殊 UDP 行為，可以針對該網域名稱或程序建立更精確的直連規則。規則應放在寬泛規則之前，避免被較早的網域後綴或規則集提前比對。調整後請重新建立連線，舊連線不一定會自動套用新策略。

關閉用戶端後網路沒有恢復

先確認用戶端程序和服務都已退出，再關閉系統代理或 VPN 設定。作業系統通常會清理由用戶端建立的暫時路由；若異常退出後仍有問題，可以停用再啟用實體網卡，或重新啟動系統以重建網路狀態。恢復基礎網路後再啟動用戶端，不要在殘留狀態下連續切換多個接管工具。

TUN、系統代理與執行模式如何搭配

只使用瀏覽器和明確支援代理設定的桌面程式時，系統代理設定較簡單，排查範圍也較小。需要接管遊戲、終端工具、商店應用程式或其他不讀取系統代理的軟體時，再啟用 TUN。某些用戶端允許同時開啟系統代理與 TUN，但不代表必須同時使用；測試階段可以關閉系統代理，僅透過 TUN 判斷涵蓋效果。

日常使用通常選擇「TUN 接管 + 規則模式」。TUN 負責將流量送入核心，規則模式則依網域名稱、位址和規則集分流。全域模式適合短時間判斷某個失敗是否由規則造成，但長期維持全域模式會略過細緻的分流邏輯。直連模式則可用於確認應用程式在本地網路下是否能夠存取目標。

行動裝置上的 TUN 往往透過系統 VPN 介面實現，同一時間通常只能維持一個系統層級的 VPN 連線。因此，啟用 Clash 類用戶端後，另一個 VPN 應用程式可能會被中斷。桌面系統雖然可能同時存在多個虛擬介面，但預設路由、DNS 和介面優先順序仍會互相影響；穩定的方案通常是明確指定一個主要接管工具。

啟用後的完整檢查清單

完成以上檢查後，TUN 連線可清楚拆分為四個部分：系統權限負責建立虛擬介面，路由負責將封包送入核心，DNS 提供規則可識別的目標資訊，策略群組決定最終出口。發生問題時依這四個部分逐項定位，比反覆重新安裝設定或連續切換節點更有效。

下載 Clash