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

先確認是否需要 TUN 模式

先用系統代理確認節點與設定正常，再啟用 TUN。若瀏覽器已能正常連線，但命令列、遊戲或不讀取系統代理設定的應用程式仍直接連線，才需要考慮透過虛擬網卡接管流量。TUN 無法修復失效的節點，也不能讓不支援 UDP 轉發的節點變成可用的 UDP 出口。

TUN 是作業系統提供的第三層虛擬網路介面。應用程式送出的 IP 封包路由至此介面後，核心會讀取封包、辨識連線，再依規則選擇直連或代理。系統代理只處理部分應用程式的代理請求，兩者所處的網路層級不同。

比較項目	系統代理	TUN 模式
流量接管方式	應用程式讀取系統的 HTTP 等代理設定	作業系統透過路由將 IP 封包送入虛擬網卡
常見適用對象	瀏覽器及遵循系統代理設定的應用程式	不支援代理設定的應用程式、部分遊戲與終端工具
UDP 流量	一般 HTTP 系統代理通常不支援	可以處理，但仍取決於節點協定與遠端能力
權限需求	通常只需修改使用者層級的代理設定	桌面版通常需要服務權限、管理員權限或網路管理能力
常見問題	代理連接埠錯誤、應用程式忽略系統設定	路由衝突、DNS 異常、權限不足、其他 VPN 干擾

啟用前檢查核心、設定與權限

建議使用明確提供 TUN 設定且仍持續維護的用戶端。以下 YAML 欄位以 mihomo 為例；舊版 Clash、不同分支的核心及行動版用戶端，支援的欄位並不完全相同。請先在用戶端的「關於」或核心資訊頁確認實際使用的核心，不要只憑應用程式名稱判斷相容性。

保留可用的設定。匯出目前的設定，記下系統代理連接埠、目前模式及所選策略。訂閱更新可能覆蓋直接修改訂閱檔案的內容，建議優先使用用戶端提供的覆寫或合併設定功能。
確認節點可用。先啟用系統代理，開啟一個實際需要透過代理存取的網頁。延遲測試顯示毫秒數，還不足以證明目標網站或 UDP 服務都能正常使用。
暫停其他流量接管工具。暫時中斷其他 VPN、遊戲加速器及另一個 TUN 用戶端。企業設備上的安全軟體或 VPN，請依管理規範處理，不要自行移除。
確認區域網路可連線。記下路由器、NAS、印表機的位址，例如 192.168.1.1。啟用後也要重新測試這些目標，避免只確認外網連線。

系統代理連接埠與 DNS 監聽連接埠用途不同。例如，混合代理連接埠可設為 7890，DNS 則可監聽 127.0.0.1:1053。實際值請以目前生效的設定為準；不要把代理連接埠填入系統 DNS 位址。

依平台啟用虛擬網卡

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

使用 mihomo 桌面版用戶端時，先進入「設定」，尋找「服務模式」或「服務管理」，完成安裝並確認服務正在執行。安裝服務時通常會出現 Windows 使用者帳戶控制提示。接著回到首頁或代理設定，啟用「TUN 模式」或「虛擬網卡模式」。實際選項名稱依目前用戶端介面而異。

先維持「規則模式」，並選擇已確認可用的策略。
啟用服務模式後，再啟用 TUN；若用戶端提供「自動路由」及「自動偵測出口網卡」，請先維持預設啟用狀態。
檢查記錄是否出現權限遭拒、建立網卡失敗或新增路由失敗。即使開關顯示已啟用，只要記錄仍有錯誤，就不能視為接管成功。
關閉系統代理，重新建立應用程式連線，並測試瀏覽器、終端工具及區域網路存取。

若用戶端沒有服務模式，可能需要以管理員身分執行；請先閱讀該用戶端的權限說明。不要同時啟動一般權限與管理員權限的兩個用戶端執行個體，否則容易發生連接埠占用及路由競爭。

macOS：授權輔助程式或網路權限

進入用戶端的 TUN 或網路設定，依提示安裝特權輔助程式、輸入管理員密碼，或允許系統要求的網路相關權限。不同用戶端可能採用不同實作方式；只有系統實際要求授權時才需要允許，不必手動安裝來源不明的延伸功能。

啟用後可用 ifconfig 檢查網路介面，再搭配用戶端記錄確認建立結果。macOS 上的 utun 介面也可能由系統服務或其他 VPN 建立，單憑看到 utun0、utun1，無法證明目前 Clash 的 TUN 正常運作。

Linux：確認 TUN 裝置與網路管理權限

先檢查系統是否提供 /dev/net/tun。核心必須具備建立虛擬網卡及修改路由所需的權限；圖形介面用戶端通常透過輔助服務取得權限，命令列部署則需要正確設定服務權限。只設定一般使用者的檔案讀寫權限，無法解決路由操作遭拒的問題。

test -c /dev/net/tun && echo "TUN 裝置存在"
ip link show
ip rule show
ip route show table all
ip route get 1.1.1.1

這些命令只會讀取狀態，不會變更網路設定。若在 Docker、LXC 或受限制的 VPS 中執行，還需要宿主環境允許使用 TUN 裝置並授予所需的網路能力；容器內的 root 身分不會自動取得宿主機的網路管理權限。遠端伺服器修改預設路由前，請先準備主控台等帶外復原管道。

Android 與 iOS：使用系統 VPN 授權入口

Android 上支援相關功能的用戶端，通常透過系統 VPN 服務接管流量；首次連線時會出現 VPN 連線要求，通常不需要 root。若啟用依應用程式代理，只有選取的應用程式會納入接管範圍。系統通常只允許一個一般 VPN 服務處於啟用狀態，連線至另一款 VPN 可能會讓目前用戶端中斷。

iOS 請使用用戶端提供的 VPN 設定與連線入口，依系統提示新增設定。桌面版的服務安裝步驟不適用於 iOS，也不應直接套用完整的桌面版 TUN YAML。行動裝置上也請檢查依應用程式排除、區域網路存取及背景執行設定。

設定 mihomo TUN 與 DNS 劫持

先合併欄位，再重新載入設定。以下是已有可用節點、策略組及規則時的設定片段，並非可獨立使用的完整訂閱。同一個頂層欄位只保留一份，尤其不要重複新增兩個 dns: 或兩個 tun:。

mixed-port: 7890
mode: rule

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

了解三個重要設定

auto-route：讓核心自動設定接管流量所需的路由。關閉後通常需要自行維護路由，不適合在初次排查時任意切換。
auto-detect-interface：自動辨識對外連線使用的網卡，協助代理流量避開接管迴圈。多網卡、其他 VPN 或特殊路由環境仍須確認實際出口。
dns-hijack：將進入 TUN 的指定 DNS 流量交由內建 DNS 處理。範例涵蓋一般 UDP 53 與 TCP 53；不會自動解密或接管所有應用程式內建的 DoH、DoT。

stack: system 指定使用系統協定堆疊。mihomo 也提供其他協定堆疊選項，但實際支援與行為取決於核心版本及平台。請先使用用戶端建議的預設值；遇到相容性問題時，再單獨切換協定堆疊並重新測試，避免同時變更路由、DNS 及 MTU。

分辨 Fake-IP 位址與實際出口位址

Fake-IP 模式會為網域名稱配置用於內部映射的位址，例如 198.18.0.1/16 範圍內的位址。核心會透過映射還原網域資訊並套用規則，因此解析結果落在該網段，不代表網站伺服器真的位於該網段，也不代表解析失敗。

上述範例使用兩個 IPv4 DNS 上游，以說明設定結構；實際網路環境請選擇可連線且符合分流需求的解析方式。dns.ipv6: false 用於限制此 DNS 模組回傳 AAAA 記錄，不代表關閉作業系統的 IPv6，也不能保證所有 IPv6 流量都已接管。應用程式自帶的加密 DNS、快取及硬編碼 IP，仍可能透過不同路徑連線。

確認流量確實經過 TUN

請先關閉系統代理再測試，才能區分兩種流量接管方式。若終端先前設定了 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，測試時也要排除這些變數；否則請求成功只能證明明確指定的代理可用。

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

在 Windows PowerShell 中，可使用 curl.exe 呼叫實際的 curl 程式。此處的 --noproxy "*" 用來略過 curl 的明確代理設定，無法繞過作業系統的 TUN 路由，因此適合搭配用戶端連線面板觀察接管狀況。範例網站僅供基本 HTTPS 檢查，請改用實際使用的目標重新測試。

查看連線面板。找到剛建立的連線，確認目標網域或 IP、命中的規則及最後採用的策略。
測試直連目標。連線至路由器或 NAS，確認區域網路連線正常，且沒有誤經遠端節點。
測試代理目標。檢查實際需要代理的應用程式，確認命中的策略符合預期。
單獨測試 UDP。使用實際的語音、遊戲或其他 UDP 服務進行測試；HTTP 請求成功及節點延遲正常，都不能取代 UDP 測試。

切換模式後需重新建立連線。瀏覽器的長連線、遊戲連線或下載工作可能仍沿用舊連線；若只切換開關而未重新發出請求，容易把快取結果誤認為目前狀態。

排查啟用 TUN 後無法上網

先判斷問題發生在哪一層

狀況	優先檢查	下一步處理
啟用後完全無法上網	核心記錄、服務權限、其他 VPN、出口網卡	關閉 TUN 以恢復網路，再逐項排除路由競爭
網域連線失敗，但已建立的 IP 連線仍可使用	DNS 上游是否可連線、劫持設定、應用程式內建 DNS	查看 DNS 錯誤，暫時簡化解析設定後重新測試
網頁可用，但遊戲或語音無法使用	節點的 UDP 能力、命中的規則、遠端限制	改用確認支援 UDP 的出口，並重新建立服務連線
外網可用，但 NAS 或印表機無法連線	區域網路路由、內部網域解析、直連規則	先用區域網路 IP 測試，再檢查內部 DNS
切換 Wi-Fi 後失效	舊出口網卡、路由及 DNS 狀態	重新連線用戶端，確認新的預設出口
小型請求正常，但大型頁面卡住	MTU、路徑分片、節點連線品質	保留其他設定，只調整 MTU 進行對照測試

依序檢查權限、路由、DNS 與策略

先查看記錄。若出現 permission denied 或類似操作遭拒的訊息，請優先處理服務權限；若出現連接埠占用，請檢查是否重複執行核心。此時反覆更換節點通常無法解決問題。

接著檢查出口與路由。TUN 會將應用程式流量送入核心，但核心連線至代理伺服器時，仍須能連上實體網路。若代理的對外流量又被送回 TUN，就可能形成迴圈。多網卡裝置應檢查實際的預設出口，必要時依目前核心文件指定出口網卡，不要直接刪除系統的所有路由。

接著確認 DNS。可使用 nslookup example.com 查看解析結果，但也要依命令顯示的 DNS 伺服器及核心記錄判斷。Fake-IP 回傳內部映射位址是預期行為；逾時、連線遭拒或無法連線至上游，才是需要進一步排查的線索。若瀏覽器啟用安全 DNS，也應分別比較系統與瀏覽器的解析結果。

最後檢查命中的規則與策略。規則模式下，直連規則範圍設得太廣，可能讓目標略過代理；選取的策略組也可能仍指向 DIRECT。暫時切換至已知可用的策略進行比較，有助於找出問題；排查後請恢復原有分流設定，並確認新連線實際命中的規則。

僅在症狀符合時調整 MTU

只有在連線已建立，但傳輸較大的資料時卡住，或特定網路能穩定重現問題時，才考慮調整 MTU。可先記下目前值，再暫時測試 mtu: 1400，必要時測試 1280，每次只變更一項。這些數值是排查時可試的選項，並非適用於所有寬頻、行動網路或隧道環境的通用最佳值。

關閉 TUN 並恢復網路

先在用戶端關閉 TUN，再正常退出用戶端，讓核心清除自動路由。若先前也啟用了系統代理，還需另外關閉系統代理；關閉 TUN 不代表系統代理設定也已還原。

確認是否仍有其他代理用戶端或 VPN 正在執行。
將手動設定的系統 DNS 還原為原本設定；若原先採用自動取得，請恢復為自動取得。
若網路仍異常，先重新連線 Wi-Fi 或有線網路，再檢查預設路由；必要時重新啟動系統。
遠端裝置請優先使用事先準備的主控台復原，不要貿然執行清除路由或重設防火牆的命令。

重新啟用時，先維持「可用節點、規則模式、單一 TUN 用戶端」的最小組合。接著依序恢復自訂 DNS、依應用程式排除及其他網路工具，每恢復一項就測試一次。這樣才能確認是哪項設定影響結果，而不必反覆重新安裝用戶端。