Clash TUN 模式設定教學：虛擬網卡如何接管流量與各平台設定

TUN 與系統代理：流量接管入口不同

Clash TUN 模式會透過虛擬網路介面接收 IP 封包，再交由核心解析、比對規則並建立對外連線。系統代理則提供 HTTP 或 SOCKS 代理入口，必須由應用程式主動遵循代理設定。因此，若瀏覽器能連網，但命令列工具、遊戲或部分桌面軟體沒有經過代理，問題可能出在流量接管入口，而非節點本身。

本文設定適用於 Clash Meta 後續發展而來的 mihomo 核心。客戶端名稱含有 Clash，不代表使用相同核心；舊版 Clash、舊版 Premium 與 mihomo 的設定功能也不能直接畫上等號。開始前請先在客戶端的核心資訊或啟動記錄中確認目前執行的是 mihomo，並以該核心支援的設定欄位為準。

檢查項目	系統代理	TUN 模式
接管位置	應用程式的代理介面	系統路由與虛擬網路介面
應用程式需求	必須遵循系統代理設定或個別設定	進入對應路由的流量可由 TUN 接管
UDP 流量	一般 HTTP 系統代理無法全面接管	可接管，但代理的對外連線仍須支援 UDP
權限需求	通常不需要建立網卡的權限	通常需要管理員權限、特權服務或網路能力授權
分流依據	由核心規則決定	仍由核心規則決定

啟用前檢查：節點、權限與設定保存

確認基本連線正常。先使用系統代理開啟已知可連線的網站，確認訂閱已匯入，且策略群組中有可用節點。TUN 無法修復過期訂閱、節點驗證失敗或伺服器離線等問題。
備份目前生效的設定。記下目前模式、DNS 設定和既有路由。客戶端可能會根據訂閱內容產生執行設定，直接修改產生的檔案可能在更新後遺失；請使用客戶端提供的覆寫、合併或持久化設定功能。
暫停其他流量接管工具。先關閉其他 VPN、網路加速器和虛擬網卡代理，降低預設路由、DNS 與防火牆規則衝突的機會。排查完成後再逐一恢復。
保留本機操作管道。遠端桌面或 SSH 連線可能因路由變更而中斷。首次啟用時請在裝置本機操作，不要透過唯一的遠端連線直接修改路由。

選單名稱會因客戶端而異，請確認以下三項實際狀態：特權服務可正常使用、TUN 開關已啟用，且執行設定中有正確的 tun 區段。介面上的開關亮起，不代表虛擬網卡已成功建立。

mihomo TUN 設定：stack、路由與 DNS

以下範例可合併至現有 mihomo 設定，並非包含節點與策略群組的完整訂閱。範例保留既有代理與規則，只示範流量接管入口和 DNS。若頂層已存在 dns 或 tun，請合併欄位，不要重複宣告同名鍵。

mode: rule

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:
    - https://1.1.1.1/dns-query

stack：先使用 mixed，再依問題切換

mihomo 提供 system、gvisor、mixed 等 TUN 協定堆疊選項。mixed 會將 TCP 交給 system 堆疊、UDP 交給 gVisor 堆疊，是明確的起始選擇。不同系統與核心建置版本的相容性可能不同；若遇到連線異常，每次只切換一種堆疊，並以同一個目標重新測試，不要同時更換節點、DNS 和路由。

切換堆疊不會改變節點的傳輸能力。即使本機成功接管 UDP，若選用的代理協定或伺服器不支援 UDP 轉送，遊戲語音、QUIC 等連線仍可能失敗。此時應檢查對外連線能力，而不是反覆安裝虛擬網卡。

auto-route：設定路由，不會變更分流規則

auto-route: true 會讓核心自動設定通往 TUN 的路由。auto-detect-interface: true 用來自動識別對外網路介面，避免代理伺服器的連線再次進入 TUN 而形成迴圈。在有線、無線與虛擬網卡並存的裝置上，自動識別可能受既有路由影響；若需手動指定對外介面，請先確認實際介面名稱，再依目前核心支援的設定方式指定。

dns-hijack：接收傳統 DNS，不代表能接管加密 DNS

any:53 會比對進入 TUN 的 UDP 53 請求，tcp://any:53 則對應 TCP 53。這些設定會將符合條件的流量交由核心 DNS 處理，但無法自動將瀏覽器內建的 DoH 或應用程式自建的 DoT 還原為一般 DNS。測試期間可暫時關閉瀏覽器的「安全 DNS」，先確認系統的 DNS 解析流程。

範例中的 127.0.0.1:1053 是本機 DNS 監聽位址，不是系統代理連接埠，也不需要將網卡 DNS 設為含連接埠的位址。TUN 劫持和本機監聽是不同的入口。fake-ip 會回傳供核心映射使用的虛擬位址；解析結果落在 198.18.0.0/16 範圍內，不代表發生故障。

Windows：先確認服務權限，再檢查虛擬網卡

先退出其他 VPN。前往「設定」→「網路和網際網路」→「Proxy」，記下原有的手動 Proxy 設定，避免測試時混淆兩種流量接管入口。
在客戶端中安裝或啟用其提供的服務模式，並依 Windows 使用者帳戶控制提示授權。若客戶端沒有服務模式，可依其說明暫時以系統管理員身分執行，確認問題是否與權限有關。
啟用 TUN 並維持規則模式，查看記錄中是否出現建立介面或設定路由失敗的訊息。請勿從不明來源另行下載網卡驅動程式，以取代客戶端附帶的元件。
在客戶端中關閉系統代理，再執行下方命令查看介面與路由，並測試實際連線。測試完成後，可視需要恢復系統代理。

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

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

Resolve-DnsName example.com
curl.exe --noproxy "*" -I https://example.com

請在 PowerShell 中執行上述命令。--noproxy "*" 會讓 curl 忽略應用程式層的代理設定，但不會繞過系統路由，因此適合用來輔助檢查 TUN。網卡名稱視客戶端設定而異，不應只憑是否出現特定名稱判斷。也請確認核心連線記錄中有這次連線。

若記錄顯示存取遭拒，請先處理服務權限；若介面存在，但沒有請求進入核心，請再檢查路由、其他 VPN 及安全軟體的封鎖記錄。不要將關閉整個防火牆當成長期解決方案。

macOS：授權輔助服務，辨識 utun 介面

macOS 建立 TUN 介面及調整路由需要相應權限。桌面客戶端通常透過特權輔助服務完成；請依應用程式提示安裝或授權，並在系統要求時前往「系統設定」→「隱私權與安全性」確認。不同散布方式使用的授權機制各異，不要因為系統中沒有某個固定開關，就判定安裝失敗。

先使用一般代理模式確認節點可用，再啟用客戶端提供的特權輔助服務與 TUN。
若要單獨驗證 TUN，可前往「系統設定」→「網路」→目前的網路連線→「詳細資訊」→「代理伺服器」，檢查 HTTP、HTTPS 和 SOCKS 代理狀態。
使用終端機查看介面、路由與 DNS，再透過核心連線記錄確認測試請求命中的規則及對外連線。

ifconfig
netstat -rn -f inet
scutil --dns
curl --noproxy '*' -I https://example.com

utun 介面也可能由系統功能或其他 VPN 建立，只看介面數量無法判斷 Clash TUN 是否正常運作。請比對啟用前後的路由變化與記錄時間。macOS 可依介面和網域指派解析器；排查系統 DNS 狀態時，scutil --dns 比單獨查看 /etc/resolv.conf 更合適。

Linux：檢查 /dev/net/tun 與服務身分

Linux 需要可用的 TUN 裝置，以及建立介面、修改路由所需的權限。通常會涉及 CAP_NET_ADMIN，實際要求也會受核心功能、服務沙箱與執行環境影響。桌面客戶端可透過配套服務執行這些操作；直接執行 mihomo 時，請使用已審核的服務設定，不要任意授權來源不明的執行檔。

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

resolvectl 適用於使用 systemd-resolved 的系統；其他 Linux 發行版請檢查實際使用的解析服務。若已安裝名為 mihomo.service 的 systemd 單元，可使用以下命令查看服務狀態和本次啟動記錄；若單元名稱不同，請以安裝時使用的名稱為準。

systemctl status mihomo.service
journalctl -u mihomo.service -b --no-pager -n 100

檢查路由時，不要只查看主要路由表。自動路由可能搭配策略路由運作，因此還需查看 ip rule show 和所有路由表。容器中的 root 不等於擁有主機的完整權限；容器還必須正確掛載 TUN 裝置並設定所需能力，不應以直接啟用特權容器取代權限檢查。

驗證步驟：分別確認流量接管、規則與出口

確認流量已接管。關閉系統代理，執行前述 curl 請求並查看核心連線記錄。若能看到目標網域或目標 IP，代表請求已進入核心；只確認網頁能開啟還不足以判斷。
確認分流規則。分別連線至預期直連和預期代理的服務，記錄符合的規則、策略群組與最終節點。TUN 正常運作但命中 DIRECT，屬於分流結果，不是接管失敗。
確認 DNS。先測試系統解析，再執行 DNS 洩漏檢測。檢測網站顯示的是遞迴解析的出口，不一定與代理出口 IP 相同；應確認結果是否符合預先設定的 DNS 路徑。
確認 IPv6。若系統已啟用 IPv6，請分別檢查 IPv4 與 IPv6 的連線結果及核心記錄。只驗證 IPv4，不能代表雙協定堆疊的流量都已接管。
確認 UDP。使用實際需要的遊戲、語音或支援 HTTP/3 的應用程式重新測試，並確認節點具備 UDP 傳輸能力。一般網頁的 TCP 請求成功，不代表 UDP 運作正常。

建議記錄「啟用前、啟用後、關閉後」三組結果，包括系統代理狀態、命中規則、DNS 上游和錯誤記錄。延遲會受節點、目標網站、網路路徑和快取影響，不能只憑一次測速結果推斷 TUN 比系統代理更快。

常見故障排查與安全復原

現象	優先檢查項目	處理方式
啟用後立刻無法連網	介面權限、路由迴圈、上游 DNS 可連性	關閉 TUN 以恢復網路，再逐項查看啟動記錄
網域連線失敗，但 IP 可連線	核心 DNS、53 連接埠劫持、應用程式加密 DNS	單獨驗證 DNS 解析流程，避免同時更換節點
瀏覽器正常，遊戲異常	UDP 對外連線、節點能力、目標規則	確認 UDP 連線記錄及伺服器支援情況
無法連線區域網路裝置	私人網路路由、目標位址、網域映射	依實際網段設定路由排除或直連規則
切換 Wi-Fi 後連線異常	對外介面識別、舊路由、網路變更記錄	網路穩定後重新啟動核心並檢查路由

區域網路直連與排除流量接管是兩回事

將某個私人網路位址比對至 DIRECT，只代表流量進入核心後直接連線；將該網段排除於 TUN 路由之外，則代表流量不經過核心。兩種做法的記錄可見度與 DNS 行為不同。印表機、NAS 或公司內網連線異常時，請先確認目標的實際位址與網段，不要為了解決單一裝置的問題，就排除整個來源不明的位址範圍。

關閉後的復原順序

先關閉 TUN，等待客戶端移除介面和路由，再恢復原本的系統代理與 DNS 設定。若仍無法連網，請正常結束客戶端，並檢查殘留的代理、路由和其他 VPN 狀態；不要直接清空所有路由表。若更換 DNS 或 fake-ip 設定後仍連到舊位址，確認設定無誤後，可清除系統 DNS 快取並重新啟動相關應用程式。

最後請保留一份已驗證可正常運作的設定，明確記錄核心類型、TUN 堆疊、DNS 上游、對外介面選擇及必要的區域網路例外。後續更新訂閱時，只應變更預期內容；每次修改流量接管或 DNS 設定後，都依相同順序重新測試，才能分辨是設定、節點還是系統網路發生問題。