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

TUN 與系統代理：流量接管入口不同，分流規則依然有效

瀏覽器可以連上目標網站，但終端機、遊戲或某個桌面程式卻無法連線，常見原因是這些程式沒有使用系統代理。系統代理主要提供 HTTP 或 SOCKS 代理入口，應用程式是否讀取這項設定，取決於程式本身。TUN 則會建立虛擬網卡，透過路由將 IP 封包交由代理核心處理，不必要求每個應用程式都支援代理設定。

此處所說的「接管所有流量」指的是流量入口的涵蓋範圍，不代表所有連線都會經過代理節點。使用 mode: rule 時，進入 TUN 的連線仍會比對 rules，並可分別交由 DIRECT、代理策略群組或 REJECT 處理。區域網路、排除路由、其他 VPN 與 IPv6 路徑，也可能影響實際接管範圍。

比較項目	系統代理	TUN 模式
流量入口	應用程式連線至本機代理連接埠	系統路由導向虛擬網卡
應用程式配合	應用程式須支援並使用代理	通常不必另外填寫代理位址
UDP 流量	受應用程式與代理協定支援程度限制	可交由核心處理，但出口節點仍須支援 UDP
權限需求	通常只需修改使用者代理設定	需要建立網卡及修改路由的系統權限
分流方式	進入核心後依目前模式處理	進入核心後同樣依目前模式處理

啟用前檢查：節點、權限與設定覆寫

先使用系統代理確認訂閱與節點可用，再啟用 TUN。如此發生問題時，就能將範圍縮小到虛擬網卡、路由與 DNS，而不必同時懷疑訂閱內容和節點連線。建議記下目前模式、策略群組選擇與 DNS 設定，並保留一份可正常連線的設定備份。

確認基本連線：使用規則模式，選擇已知可用的節點，開啟需要代理的網站。節點延遲測試成功，只代表測試目標可連線，不能取代實際瀏覽網頁。
確認核心權限：桌面版請檢查服務模式或輔助服務狀態；Android 請確認 VPN 授權。以一般使用者身分啟動的核心，不一定有權限建立虛擬網卡。
暫時結束其他 VPN：企業 VPN、遊戲加速器和另一個 TUN 用戶端都可能修改路由。請先確認單一用戶端可正常運作，再測試共存。
確認編輯位置：優先使用用戶端提供的覆寫設定或合併設定。直接修改訂閱快取檔案，可能在下次更新時被覆蓋。
檢查實際生效的設定：介面上的開關可能會改寫 tun.enable、stack 或 DNS 設定。儲存後請檢查執行中的設定，不要只看編輯器裡的文字。

本機代理連接埠與 TUN 是兩種不同的流量入口。範例中的 mixed-port: 7890 供應用程式連線至 HTTP/SOCKS 代理；DNS 監聽連接埠 1053 則供 DNS 服務使用。修改 7890 無法解決虛擬網卡建立失敗，也不要將 DNS 監聽連接埠填入瀏覽器的代理設定。

Windows、macOS、Linux 與 Android 的啟用步驟

Windows：先啟動服務，再啟用 TUN

以下以 Clash Verge Rev 常見介面為例，進入「設定」→「服務模式」，依照提示安裝服務並確認系統授權；服務啟動後，再開啟「TUN 模式」。不同版本可能將相關選項放在設定卡片中，名稱與分組也可能不同。重點是確認服務確實正在執行，而非只看到開關已開啟。

啟用後，前往 Windows「設定」→「網路和網際網路」→「進階網路設定」檢查介面卡，或執行下方的 PowerShell 命令。虛擬網卡名稱可由設定指定，不一定會包含 Clash 字樣。網卡出現只是第一步，還要查看記錄，確認路由與 DNS 是否初始化成功。

Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
route print

若記錄出現權限不足或裝置建立失敗，請先重新確認服務安裝狀態；以系統管理員身分啟動可用於診斷，但日常使用最好透過用戶端支援的服務機制執行核心。防火牆應針對特定程式或服務設定允許規則，不建議長期關閉整個系統防火牆。

macOS：確認輔助服務與網路權限

選擇支援 mihomo TUN 的用戶端，依設定頁面的提示安裝輔助服務，再啟用 TUN。出現系統授權提示時，請確認程式來源並完成授權。如果服務安裝成功，但開關無法維持開啟，請查看用戶端記錄以及「系統設定」→「網路」中的網路服務狀態；部分權限提示也可能出現在「系統設定」→「隱私權與安全性」。

ifconfig
netstat -rn -f inet
route -n get 1.1.1.1

macOS 常見的虛擬介面名稱為 utun 加上數字，但系統或其他 VPN 也可能建立這類介面。不能只因為出現 utun 就認定目前用戶端已接管流量，還要根據啟動記錄及目標位址的路由判斷。

Linux：檢查 TUN 裝置與服務權限

Linux 通常需要可用的 /dev/net/tun，以及建立介面與修改路由所需的權限。不同發行版套件、桌面用戶端和獨立核心服務的授權方式各不相同，請依照對應專案的服務安裝說明操作。在容器中還需要額外設定裝置映射與網路權限，不能直接套用一般桌面環境的步驟。

ls -l /dev/net/tun
ip link show
ip rule show
ip route show table all

檢查路由時，也要查看策略路由與所有路由表。有些實作不會直接取代主路由表中的預設路由，只執行 ip route 可能看不到實際的接管路徑。不要為了省事，就把長期執行的服務一律改成最高權限。

Android 與 iOS：先分清平台的流量接管方式

Android 圖形介面用戶端通常透過系統 VPN 介面接管流量，首次連線時會要求 VPN 授權。以支援 mihomo 的用戶端為例，匯入設定後，啟用其 VPN/TUN 執行模式，再確認系統狀態列出現 VPN 標示。Android 一般情況下只能同時使用一項 VPN 服務；啟動另一個 VPN 可能會中斷目前的連線。

若只有部分應用程式無法連線，請檢查用戶端的應用程式存取控制或分應用代理設定；被排除的應用程式可能不在接管範圍內。iOS 用戶端多半透過 Network Extension 提供流量接管功能，設定格式與可用欄位依各用戶端而異；不要將桌面版 mihomo 的 YAML 片段直接當成所有 iOS 用戶端的啟用方式。

TUN 設定片段：stack、auto-route 與 DNS 劫持

以下是供現有 mihomo 設定使用的頂層合併片段，並非完整設定。其中沒有節點、訂閱提供者、策略群組和規則，請保留原設定中的這些內容。若原始檔案已有 dns 或 tun，請合併欄位，不要再複製一個相同名稱的頂層鍵。

mode: rule
mixed-port: 7890

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.cloudflare.com/dns-query

欄位	範例值	用途與注意事項
`enable`	`true`	要求啟用 TUN，仍須具備系統權限。
`stack`	`mixed`	TCP 使用 system 堆疊，UDP 使用 gVisor 堆疊。
`auto-route`	`true`	自動設定接管流量所需的路由，不代表所有連線都會選擇代理節點。
`auto-detect-interface`	`true`	自動偵測出口介面；使用多張網卡或多個 VPN 時，請確認偵測結果。
`dns-hijack`	`any:53`	接管進入 TUN 的 UDP 53 請求，並交由內建 DNS 處理。
`enhanced-mode`	`fake-ip`	透過映射位址關聯網域名稱與後續連線。

如何選擇 stack

system：使用系統網路堆疊。適合做為相容性測試選項，實際表現會受作業系統與環境影響。
gvisor：使用使用者空間網路堆疊。遇到特定系統堆疊問題時，可用來交叉測試，但不能保證在所有裝置上速度更快。
mixed：TCP 使用 system，UDP 使用 gVisor 處理，可做為起點，再依記錄與應用程式的實際狀況調整。

每次只修改一個欄位，重新連線後測試同一個應用程式。遊戲語音無法使用時，也要檢查節點協定、伺服器與出口網路是否支援 UDP；更換 stack 無法補足出口節點欠缺的功能。

default-nameserver 用於解析 DNS 上游的網域名稱，proxy-server-nameserver 則用於解析代理伺服器的網域名稱。範例將這兩類解析分開設定，是為了減少啟動時的解析依賴循環；實際使用時，應選擇目前網路可連線且符合自身隱私需求的解析器。DoH 上游的 HTTPS 連線是否經過代理，也取決於 DNS 路由相關設定，不能只憑 URL 中含有 https 就判斷連線的出口位置。

啟用後驗證：分別檢查流量入口、規則與 DNS

測試時先暫時關閉系統代理並保持 TUN 啟用，避免瀏覽器仍透過本機連接埠連線，掩蓋流量接管失敗的問題。同時也要清除測試程式本身的代理設定。先測試一般網頁，再測試原本不會讀取系統代理的程式，並在用戶端的「連線」或「記錄」頁面查看對應目標。

確認流量進入核心：建立一個新的連線，查看連線頁面是否出現目標網域名稱或 IP。瀏覽器重複使用舊連線時，可能不會立即產生新記錄；請關閉頁面後再試一次。
確認規則命中：查看比對到的規則與最終策略。中國大陸網站命中直連、境外服務命中代理群組，與 TUN 接管並不衝突。
確認網域解析：若用戶端提供 DNS 查詢功能，請優先使用該功能。也可以向本機 DNS 監聽連接埠送出查詢，確認內建 DNS 是否有回應。
確認 UDP：使用實際的語音、遊戲或其他 UDP 應用程式測試，不要把成功瀏覽一次 HTTP 網頁當成 UDP 正常的證據。

# macOS / Linux：測試範例中的本機 DNS 監聽連接埠
dig @127.0.0.1 -p 1053 example.com A

# 檢查網域名稱是否能成功連線
curl -I https://example.com

若使用 Fake-IP，查詢結果落在 198.18.0.0/16 範圍內可能是預期的映射結果，不能直接視為解析錯誤。網域名稱若列在過濾清單中，也可能回傳真實位址。不要只用「映射位址能否 ping 通」來判斷網頁能否開啟。

公開 IP 或 DNS 檢測網站只能反映它們實際觀察到的請求。出口位址符合預期，不代表所有應用程式、DNS 與 IPv6 都已接管。還需要一併檢查應用程式記錄、規則命中情況與系統路由。

啟用 TUN 後無法上網：依序排查故障

第一步：關閉 TUN，確認基本網路正常

如果關閉 TUN 後仍無法上網，請先處理 Wi-Fi、閘道、訂閱或節點問題。若關閉後網路立即恢復，請保留目前的設定備份，集中檢查 TUN 啟動記錄中的權限、介面、路由與 DNS 錯誤。可暫時將記錄層級設為 log-level: debug，重現一次問題後再恢復常用層級，避免長期記錄過多連線資訊。

第二步：檢查網卡建立與路由出口

若記錄出現 permission denied、operation not permitted 等訊息，通常應重新檢查服務權限。使用多張網卡時，請確認自動偵測的出口介面指向實際連網的介面，而不是另一個 VPN 或目前使用的虛擬網卡。只有確認自動偵測有誤後，才依目前核心支援的方式指定出口介面。

第三步：區分 DNS 問題與連線問題

若內建 DNS 查詢逾時，請檢查 dns.enable、1053 連接埠是否被占用、上游 DNS 是否可連線，以及設定是否已生效。若查詢成功但網站仍無法連線，再查看代理節點、規則與 TLS 連線記錄。單純比較「IP 能開啟、網域名稱無法開啟」只能做為線索，因為許多網站需要正確的 Host 與 TLS SNI，直接連線至 IP 也可能正常失敗。

第四步：排除 VPN、IPv6 與特殊路由衝突

結束其他 VPN 後重新測試；若問題只在 IPv6 連線時出現，請檢查 IPv6 DNS 回應、系統路由與節點出口支援是否一致。暫時限制 IPv6 可用於定位問題，但應將其視為診斷措施並記錄下來，不要在沒有說明的情況下當成長期修復方式。公司內網或區域網路裝置無法連線時，請檢查相關網段是否遭到接管，以及既有規則是否選擇直連。

第五步：最後再調整 stack 與 MTU

若已建立連線，但傳輸大型檔案時停頓、部分網頁長時間載入或特定 UDP 應用程式異常，請分別測試不同的 stack。懷疑路徑 MTU 有問題時，可在原設定上測試 tun.mtu: 1400，並記錄是否有所改善；1400 是排查起點，不是適用所有網路的最佳值。不要同時修改 DNS、MTU、規則與節點，否則無法判斷是哪項變更解決了問題。

恢復連線與日常使用：保留可驗證的回復方式

需要回復時，請先關閉 TUN，確認核心已結束執行或完成重新載入，再視需要啟用系統代理。正常結束時通常會清除自動建立的路由；若用戶端異常終止後網路仍未恢復，請先重新啟動相關服務或用戶端，再檢查是否有殘留介面與路由。不熟悉路由表時，請勿批次刪除系統路由。

只需要瀏覽器代理：系統代理通常就足夠，設定範圍較小，也更容易排查。
需要接管終端機或桌面程式：TUN 更適合，但必須確認權限、DNS 與規則都正常。
需要遊戲或語音：除了 TUN，也要確認節點支援 UDP、出口網路與實際應用程式連線正常。
經常連線至企業 VPN：請分別測試啟動順序、出口介面與區域網路存取，不要把單次成功視為長期相容。

完成設定後，請保留用戶端名稱、核心資訊、系統版本、啟用欄位與問題重現步驟。更換用戶端或更新訂閱後，請重新檢查執行中的設定是否保留覆寫內容。關於代理入口與常用欄位，請參閱使用教學；關於連接埠與設定結構，可參考進階手冊的連接埠說明。