原理進階 閱讀時間約 12 分鐘

Clash TUN 模式完整解析：虛擬網卡接管全流量的原理與設定步驟

了解 TUN 與系統代理的差異、虛擬網卡如何接管未使用代理設定的程式流量，以及服務模式安裝、DNS 劫持與啟用後的驗證方式。

TUN 與系統代理的差異

瀏覽器可以連線，命令列工具卻逾時；網頁運作正常，遊戲或桌面程式仍直接連線。遇到這類情況，先檢查流量從哪裡進入，不必急著更換節點。Windows 系統代理只是告訴會讀取這項設定的程式，將要求交給指定的 HTTP 代理。程式若不讀取系統代理，開啟這項設定也不會讓連線自動進入 Clash。

TUN 則是在網路層建立虛擬網卡，搭配路由將符合接管條件的 IP 封包送進核心。程式不必支援 HTTP 代理，也不必提供代理設定選項。核心收到流量後，再依規則決定直連、代理或拒絕連線。

比較項目系統代理TUN 模式
接入位置應用程式讀取代理設定後，主動連線至監聽連接埠。系統路由將流量送進虛擬網卡。
常見用途瀏覽器，以及遵循系統代理設定的桌面軟體。不讀取系統代理的程式，以及需要接管的 UDP 流量。
權限需求設定本機代理通常不必安裝系統服務。通常需要具備權限的背景服務，或以提升權限的方式執行核心。
處理範圍取決於應用程式是否採用代理設定。取決於路由、介面、排除位址與通訊協定支援。

虛擬網卡如何接管連線

一次連線可以分成四個步驟。先確認資料是否進入核心，再檢查套用的規則，最後才判斷節點效能。只看到虛擬網卡出現，並不能證明流量已成功交由它接管。

  1. 程式發出要求。程式向目標 IP 傳送 TCP 或 UDP 資料；若使用網域名稱，還會先進行名稱解析。
  2. Windows 選擇路由。用戶端啟用自動路由後，會新增相應路由，讓目標流量進入 TUN 介面。更明確的路由、排除位址和其他 VPN 都可能影響結果。
  3. 核心辨識流量並比對規則。核心透過 DNS 對應等資訊取得網域名稱，再依網域、IP 或處理程序規則選擇策略。若無法還原網域名稱，網域規則不一定會生效。
  4. 建立實際對外連線。直連流量會從實體網卡送出；代理流量則經由選定的節點轉送。用戶端必須避免自身對外流量再次進入 TUN，造成迴圈。

因此，TUN 並不會取代實體網卡。Wi-Fi、乙太網路仍負責實際連線，虛擬網卡則將指定流量交由核心處理。節點若不支援 UDP，啟用 TUN 也不會憑空增加 UDP 轉送能力；遊戲、語音和 QUIC 能否使用，還得視節點通訊協定、伺服器設定及網路環境而定。

啟用前：用戶端與服務模式

先建立可用的基本連線

  • 從可信來源匯入訂閱，並在用戶端選取實際要使用的設定檔，而不只是下載訂閱檔案。
  • 前往代理群組，手動選取一個節點；先使用系統代理，確認瀏覽器能正常連線。
  • 記下目前的監聽連接埠。常見範例是 7890，但請以用戶端實際設定為準，不要直接套用別人的連接埠。
  • 暫時關閉其他 VPN、網路加速器和另一套代理用戶端，避免多個虛擬網卡同時修改路由。
  • 備份原有設定、DNS 設定與 VPN 資訊。正在使用遠端連線的電腦不要貿然切換路由，請優先在本機操作。

服務模式不是 TUN 開關

在舊版 Clash for Windows 中，服務管理入口通常位於 General → Service Mode 旁的齒輪按鈕。開啟管理視窗後，按下其中的 Install 安裝服務，並依照提示完成 Windows 權限確認。不同封存版本的按鈕位置與狀態文字可能不同；若找不到，請先確認使用的版本，不要反覆安裝來源不明的驅動程式。

服務模式是為了解決背景程序執行特權操作的問題，TUN 開關則控制虛擬網卡接管。成功安裝服務後，仍須確認服務正在執行，再啟用 TUN Mode。兩者不能互相取代，也不代表必須長期以系統管理員身分執行整個圖形介面。

使用其他用戶端時，請在設定中尋找實際的「服務模式」、「系統服務」或「TUN 模式」入口。不要為了照著舊版介面教學操作而降級。若安裝服務時發生錯誤，請先記錄完整錯誤訊息與核心日誌，檢查權限、安全軟體的封鎖紀錄及舊服務殘留，不要直接關閉系統安全防護。

mihomo TUN 設定與 DNS 劫持

以下是 mihomo 的欄位示意片段，不是可單獨匯入的完整訂閱。片段中沒有節點、代理群組和分流規則，不能取代現有設定。舊版 Clash for Windows 不一定支援其中所有欄位；若用戶端能透過介面產生 TUN 與 DNS 設定，請優先使用介面或覆寫功能，避免修改在訂閱更新後遺失。

mode: rule
mixed-port: 7890

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

各個關鍵欄位的用途

  • auto-route：讓核心自動設定接管流量所需的路由。若只建立網卡，卻沒有正確路由，程式流量仍可能繞過它。
  • auto-detect-interface：嘗試自動辨識對外介面。使用多張網卡、企業 VPN，或同時連接有線與無線網路時，仍須檢查日誌中實際使用的出口。
  • stack: mixed：在 mihomo 中使用混合式協定堆疊。支援的協定堆疊與實作方式取決於核心版本；遇到特定程式的相容性問題時，再依文件比較其他可用選項。
  • dns-hijack：將進入接管範圍且送往指定連接埠的 DNS 流量交由內建 DNS 處理。此處分別列出 UDP 53 與 TCP 53，但不代表能辨識所有加密 DNS。
  • listen: 127.0.0.1:1053：讓內建 DNS 在本機迴圈位址的 1053 連接埠上監聽。這不是要將 Windows DNS 伺服器位址填成包含連接埠的字串。
  • fake-ip：為網域名稱指派合成位址，協助核心將後續連線對應回網域名稱。範例位址池為 198.18.0.1/16，並非節點位址。

範例中的兩個上游是一般 DNS 位址，只用來展示欄位結構，不代表適用於所有網路或提供加密解析。實際部署還須考量上游是否可連線、節點網域解析、分流解析和企業內部網域。如需這些設定，請參閱設定參考，不要將示範片段視為通用的最佳設定。

DNS 為什麼會影響規則命中

網域規則需要網域資訊。若應用程式自行進行加密解析，或使用舊快取直接連線至 IP，核心未必能取得預期的網域對應資訊。針對 53 連接埠的 DNS 劫持，無法自動涵蓋 HTTPS 上的 DoH 或 TLS 上的 DoT。瀏覽器的安全 DNS、程式內建解析器和 Windows 加密 DNS 設定，都可能改變實際的解析路徑。

排查時，可暫時關閉測試應用程式的自訂安全 DNS，改用系統解析進行比較，測試後再恢復設定。不要只憑一次解析結果就認定發生「DNS 洩漏」，也不要把所有網域都解析成 fake-ip 當作成功標準。區域網路裝置名稱、企業內部網域和少數特殊應用程式，可能需要依用戶端文件設定例外或專用上游。

啟用步驟：每次只變更一項設定

  1. 確認基本代理運作正常。維持規則模式，選取已確認可連線的節點。此時先不要啟用 TUN，確認訂閱與節點本身沒有問題。
  2. 安裝並啟動服務。在用戶端的服務管理入口完成操作，確認狀態正常。若服務無法啟動，請先解決權限或殘留服務問題，不要繼續疊加設定。
  3. 啟用 TUN。查看日誌是否出現權限不足、建立介面失敗、新增路由失敗或 DNS 連接埠遭占用等錯誤。若出現錯誤，請先關閉 TUN 並保留日誌。
  4. 關閉系統代理進行隔離測試。這個步驟是用來確認流量是否由 TUN 接管，並不代表兩者不能同時啟用。否則瀏覽器能連線，可能只是因為仍在使用 HTTP 代理。
  5. 重新建立測試連線。完全關閉並重新開啟測試程式，或重新發出要求。長連線與舊 DNS 快取可能仍沿用啟用前的連線路徑。
  6. 檢查連線詳細資訊。在用戶端的連線清單中查看目標、規則與策略鏈。驗證完成後，再依日常需求決定是否保留系統代理。

若只用來瀏覽網頁，系統代理已能滿足需求，就不必為了「涵蓋更多流量」而強行啟用 TUN。增加接管層，也代表必須處理區域網路探索、企業網路、休眠喚醒和多網卡切換等相容性問題。

Windows 驗證：網卡、路由與連線紀錄

不要只看開關顏色來判斷是否成功。請依序檢查虛擬介面、路由變化和實際連線，並交叉比對三項結果。以下命令只會檢視狀態，不會修改網卡或刪除路由。

第一步：查看介面與路由

開啟 PowerShell，在關閉與啟用 TUN 時分別執行以下命令。比較新增的介面與路由，不要假設虛擬網卡一定有固定名稱。

Get-NetAdapter -IncludeHidden |
  Format-Table Name, InterfaceDescription, Status, ifIndex

Get-NetRoute -AddressFamily IPv4 |
  Sort-Object InterfaceIndex, DestinationPrefix |
  Format-Table DestinationPrefix, NextHop, InterfaceIndex, RouteMetric

Get-DnsClientServerAddress -AddressFamily IPv4

新增介面只是線索，不能當作結論。TUN 可能透過多條路由涵蓋位址範圍，不一定會顯示為一條常見的預設路由。也要留意其他 VPN 的更具體路由。若實際流量使用 IPv6，只檢視上方的 IPv4 輸出，也不足以證明流量已完整接管。

第二步：略過明確代理設定並發出要求

先確認系統代理已關閉，再執行以下要求。--noproxy "*" 可讓 curl 不使用明確代理，包括由環境變數指定的代理；但它不會略過作業系統的 TUN 路由。

curl.exe --noproxy "*" -I --connect-timeout 10 https://example.com/

收到 HTTP 回應只能證明這次要求成功，無法單獨證明流量經過代理，因為目標也可能允許直連。請立即開啟用戶端的連線清單，依目標網域或位址搜尋這次要求，確認命中的規則和最終的 DIRECT 或節點策略。若要求太快消失，可同時查看用戶端日誌；是否記錄連線取決於日誌設定。

第三步：測試真正需要接管的程式

重新啟動原本不使用系統代理的程式，執行一次網路操作，再查看它是否出現在連線清單中。瀏覽器測試不能取代遊戲 UDP 測試；TCP 要求成功也不代表語音通道可用。若要確認遠端出口，請使用可信的出口查詢服務並對照連線詳細資訊，不要只憑網頁顯示的地區判斷整個系統。

IPv6 也應分開驗證。檢查用戶端的 IPv6 與路由設定、系統是否取得 IPv6 位址，以及目標是否使用 AAAA 記錄。未經測試，不要宣稱所有 IPv6 流量都已接管，也不要預設以全面停用 IPv6 作為修復方式。

常見故障與排查順序

現象優先檢查下一步處理方式
TUN 開關自動關閉服務狀態、權限與介面建立錯誤。記錄第一則錯誤，確認服務正在執行，再檢查舊虛擬介面或安全軟體紀錄。
啟用後所有網域都無法連線內建 DNS 是否啟用、上游是否可連線、監聽連接埠是否衝突。確認 1053 等實際使用的連接埠，檢查解析日誌，先恢復一組可用的上游。
有連線，但始終直連模式、規則順序與代理群組選擇。查看連線命中的具體規則，確認目前不是 Direct 模式，也沒有優先套用直連規則。
網頁正常，遊戲無法連線UDP 支援、節點伺服器端設定與遊戲本身的網路限制。確認對應的 UDP 連線，不要只根據延遲測試結果判斷。
無法存取印表機或 NAS區域網路路由、DNS 與廣播探索。比較直接存取裝置 IP 的結果；依實際網段設定略過規則，並檢查其他 VPN 的路由。
關閉用戶端後網路中斷系統代理是否殘留，以及服務狀態、DNS 與路由是否恢復。先正常停止流量接管與服務，再檢查系統代理，避免直接刪除所有網路設定。

區域網路問題需要分層處理。將某個私人位址範圍設為 DIRECT，只會改變流量進入核心後的對外策略，不等於讓該範圍完全略過虛擬網卡。依賴廣播、多點傳播或特殊探索通訊協定的裝置，也可能需要設定路由排除。網段必須依實際網路填寫，不能假設所有家庭網路都是 192.168.1.0/24。

變更 DNS 後仍命中舊結果時，請先保存必要資訊，再執行 ipconfig /flushdns 清除 Windows DNS 快取，並重新啟動測試應用程式。這不會清除所有瀏覽器內部快取，也無法修復錯誤的上游或路由。不要把連續執行網路重設命令當成排查流程。

關閉與復原檢查

測試失敗時，請先關閉 TUN，再透過用戶端正常退出或停止相關服務。前往 Windows 11「設定 → 網路和網際網路 → Proxy → 手動 Proxy 設定」，檢查是否仍保留本機代理；Windows 10 可在「設定 → 網路和網際網路 → Proxy」檢查相關開關。若代理原本由公司或機構設定，請勿覆寫原有設定。

  • 確認停止流量接管後，一般網頁與區域網路裝置都已恢復至測試前的狀態。
  • 若曾手動修改 DNS，請還原先前記錄的值，不要一律改成自動取得。
  • 再次查看介面與路由，確認沒有其他 VPN 或代理仍在接管流量。
  • 回報問題時，請附上系統版本、用戶端與核心版本、錯誤發生時間及已去識別化的日誌，並移除訂閱網址、存取權杖與節點憑證。

判斷 TUN 是否設定正確，最終要確認三件事：需要接管的程式確實進入核心、連線命中預期規則，以及退出後網路能正常恢復。分開驗證流量入口、DNS、規則與對外連線，比反覆切換節點更容易找出問題。

下載用戶端