Clash TUN 模式設定教學：虛擬網卡原理與 Windows、Mac、Android 開啟方式

TUN 模式與系統代理的流量接管範圍

系統代理是提供給應用程式的一組代理伺服器設定。瀏覽器可以讀取這些設定，將請求傳送到本機 HTTP 代理連接埠；自行建立連線的遊戲、命令列工具或部分桌面程式，則可能完全不讀取這些設定。開啟系統代理，不代表所有程式的連線都會經過 Clash。

TUN 是運作於網路層的虛擬介面。用戶端會建立介面並調整系統路由，讓符合條件的 IP 封包進入核心。核心處理 TCP、UDP 等連線，依規則選擇直連、代理或拒絕。應用程式通常不必另外填寫代理伺服器位址，但仍可能受路由排除、應用程式排除及平台限制影響。

本文的 YAML 範例適用於 Clash Meta 的延續專案 mihomo。不同 Clash 分支的欄位與平台支援不盡相同；請先在用戶端的「關於」或核心資訊中確認核心名稱，再參閱該核心的文件。介面上有 TUN 開關，也不代表舊版核心支援下文列出的所有欄位。

虛擬網卡、路由表與 DNS 如何協同運作

一次連線的處理流程

1. 應用程式要求解析網域名稱，或直接連線至某個 IP 位址。
2. 作業系統依路由表選擇出口。啟用自動路由後，相關流量會送入 TUN 介面。
3. 核心取得目標位址後，會依 DNS 對應、規則及可選的嗅探資訊進行比對。
4. 符合代理規則的連線會透過選定的節點送出；直連連線則由實際網路介面送出。

核心連往代理伺服器的連線必須經由實際出口送出，不能再次進入自身。auto-detect-interface 用來自動判斷出站介面，降低形成路由迴圈的風險。切換 Wi-Fi、連接網路線或啟停其他 VPN 後，原先選用的介面可能改變，應重新檢查記錄與路由。

DNS 劫持不等於攔截所有加密 DNS

dns-hijack 可將符合條件的 DNS 流量交由核心 DNS 模組處理，例如 UDP 53 和 TCP 53。瀏覽器透過 HTTPS 連線至外部解析服務時，請求通常使用 443 連接埠，不屬於一般的 53 連接埠 DNS 查詢；不能只靠一條 any:53 就認定所有網域查詢都已被接管。

使用 fake-ip 時，核心會回傳對應位址，再依後續連線還原網域名稱。範例中的 198.18.0.1/16 來自專用測試位址範圍，用於內部對應，並非代理伺服器位址。依賴真實解析結果的區域網路裝置或應用程式，可能需要依網域設定 fake-ip-filter；請勿直接排除大量網域。

mihomo TUN 設定與 stack 選擇

以下範例是合併至現有設定的片段，不包含節點、代理群組與分流規則，不能取代完整訂閱。請先備份設定，再透過用戶端支援的覆寫或合併功能加入，避免訂閱更新時覆蓋本機修改。若已有同名欄位，應合併其內容，不要在 YAML 頂層重複設定兩份 dns 或 tun。

mixed-port: 7890
mode: rule

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
    - 1.1.1.1

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

• mixed-port: 7890 是本例的 HTTP/SOCKS 混合代理入口，不是 TUN 接收封包所用的連接埠。改用其他未占用的連接埠，不會直接改變虛擬介面的路由。
• listen: 127.0.0.1:1053 是核心 DNS 的本機監聽位址，不代表必須將系統 DNS 設為「127.0.0.1:1053」。多數系統的 DNS 設定只接受伺服器 IP，不接受這種包含連接埠的寫法。
• auto-route 負責自動新增相關路由；auto-detect-interface 負責判斷實際出站介面。兩者都不是節點測速或自動選擇節點的功能。
• 範例中的解析伺服器用來說明欄位結構。實際部署時，應依網路連線狀況、解析策略與隱私需求選擇上游伺服器，不要把範例位址視為所有網路都適用的固定答案。

system、gvisor 與 mixed 的差異

不要把特定 stack 視為固定的「最快模式」。傳輸量、CPU 使用率與相容性會受到系統、核心建置版本、節點協定及應用程式負載共同影響。排查時請固定同一個節點與測試目標，每次只變更一項 stack 設定，重新建立連線後再比較。舊連線尚未中斷時，測試結果可能仍來自原本的處理路徑。

Windows：服務權限與虛擬網卡檢查

在 Windows 10、Windows 11 上，建立虛擬介面及修改路由需要相應權限。桌面用戶端通常會以系統管理員身分啟動，或透過背景服務執行核心；「開機啟動」與「服務模式」是不同設定。服務安裝完成後，也要確認服務確實正在執行。

1. 先關閉 TUN，匯入設定並選擇可用節點。開啟系統代理後瀏覽測試網頁，確認訂閱與節點本身運作正常。
2. 在用戶端設定中尋找「服務模式」，依提示安裝並啟動服務，或按照用戶端說明以系統管理員身分啟動。Windows 顯示使用者帳戶控制視窗時，請確認程式路徑。
3. 暫時關閉系統代理，再啟用「虛擬網卡模式」或「TUN」。如此一來，測試時較不會把系統代理的效果誤認為 TUN 已生效。
4. 開啟「設定」→「網路和網際網路」→「進階網路設定」，查看網路介面的變化。介面名稱由用戶端及核心設定決定，不必要求名稱一定是 Clash。
5. 開啟用戶端的連線清單，執行一個未另外設定代理的程式，確認清單中出現對應連線並顯示規則命中。

若要進一步檢查，可在 PowerShell 執行以下唯讀指令。請留意新增介面、路由的介面索引及 DNS 伺服器，不要只看工作列上的連線圖示。

Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
Get-DnsClientServerAddress
Get-NetTCPConnection -State Listen -LocalPort 7890

最後一個指令只會檢查本例代理連接埠是否正在監聽，無法證明 TUN 正常運作。若記錄顯示權限不足，請先處理服務權限；若連接埠已被占用，再確認是哪個程序正在監聽。不要為了解決介面建立失敗而直接關閉整個系統防火牆。

macOS：輔助服務與 utun 路由驗證

macOS 用戶端通常會透過特權輔助服務建立或管理 TUN，也有用戶端採用系統網路延伸功能。授權方式取決於用戶端的實作，不能把某款軟體的選單路徑套用到所有應用程式。下載與安裝時，也請確認選擇適用於 Apple 晶片或 Intel 架構的版本。

1. 先透過系統代理確認節點正常，再依用戶端提示安裝輔助服務或允許網路延伸功能。輸入管理員密碼前，請確認授權要求來自目前安裝的用戶端。
2. 啟用 TUN。若系統提示需要允許背景元件，請依指示前往「系統設定」→「一般」→「登入項目與延伸功能」檢查相關項目；不同 macOS 版本的名稱可能略有差異。
3. 暫時關閉系統代理後，重新開啟測試應用程式，並在用戶端中確認連線是否仍進入核心。
4. 從睡眠狀態喚醒或切換網路後，請重新測試。若只有喚醒後才失效，記錄當時的出站介面與核心記錄，再重新啟動 TUN 進行確認。

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

utun 介面可能同時供其他系統服務或 VPN 使用。看到 utun0 不代表它屬於目前的用戶端，介面編號也不固定。請比較開啟 TUN 前後的介面與路由變化，並參考用戶端記錄判斷。路由查詢只能說明目標 IP 的路由選擇，無法單獨證明所有網域解析或 IPv6 流量都已進入核心。

Android：VPN 授權、應用程式範圍與背景限制

Android 用戶端通常透過系統 VpnService 提供虛擬介面，一般使用者不需要取得 root 權限。首次連線時，系統會顯示 VPN 授權對話框。Android 的「VPN 模式」目標與桌面版 TUN 類似，但介面和路由通常由應用程式管理，因此不能直接照抄桌面版的 auto-route 設定。

1. 匯入訂閱並選定代理群組後啟動連線。確認系統 VPN 授權視窗顯示的應用程式名稱無誤，再點選允許。
2. 在用戶端檢查應用程式分流設定。若選擇「僅代理所選應用程式」，未選取的應用程式不會因為出現 VPN 圖示就自動經過代理。
3. 在 Android 13 上，常見路徑是「設定」→「網路和網際網路」→「VPN」，可在此查看目前使用的 VPN。部分廠牌的系統可能將入口放在「連線與共享」等分類，也可以直接在設定中搜尋「VPN」。
4. 前往用戶端的系統應用程式資訊，在「電池」或「應用程式電池用量」中視需要允許背景執行。若只有鎖定螢幕後才會斷線，請優先檢查省電與背景執行限制。
5. 若已啟用「一律開啟 VPN」或「封鎖未使用 VPN 的連線」，請先確認用戶端能穩定重新連線。若 VPN 中斷，後者可能會直接阻止網路連線。

同一位使用者或工作資料通常只能有一個使用 VpnService 的應用程式保持連線。啟動另一個 VPN、使用本機 VPN 的過濾工具或封包擷取工具時，可能會取代目前的連線。此時應確認系統目前授權的 VPN 應用程式，而非反覆重新匯入訂閱。

啟用後無法上網：依連線層級逐步排查

先區分節點故障與流量接管故障

關閉 TUN、恢復系統代理，使用相同節點連線至相同目標。若仍無法連線，請先處理節點、訂閱或代理群組問題；若系統代理正常而 TUN 失效，再檢查權限、路由、DNS 及其他 VPN。與同時變更連接埠、stack、DNS 相比，這種對照方式更容易縮小問題範圍。

• 瀏覽器正常，遊戲無法連線：檢查用戶端是否顯示遊戲連線、節點是否支援 UDP，以及規則是否將目標送往預期的代理群組。HTTP 網頁能正常開啟，不代表 UDP 出口也能使用。
• IP 可連線，網域名稱無法連線：檢查 DNS 記錄、系統解析設定及瀏覽器安全 DNS。nslookup example.com 可協助查看查詢結果，但查詢路徑可能與使用加密 DNS 的瀏覽器不同。
• 區域網路印表機或 NAS 連不上：檢查私有 IP 位址的路由、網域名稱解析及規則。私有網路連線需要正確直連或排除；只新增一條直連規則，不一定能修復錯誤的系統路由。
• 部分網頁載入時間過長：檢查 IPv4 與 IPv6 是否使用不同出口，再檢查 MTU。不要直接套用固定的 MTU 數值，應先確認是否有隧道疊加或路徑分片問題。
• 重新啟動用戶端後才恢復：檢查是否同時存在舊服務、重複的核心程序或其他 VPN，並記錄錯誤發生時間；不要只憑現象就認定是 stack 問題。

驗證與復原順序

有效的驗證應同時具備三類證據：介面或路由如預期變更；未設定代理的應用程式連線進入核心；規則命中及最終出口符合預期。只看到 VPN 圖示、代理連接埠正在監聽或節點延遲數值，都不足以完成驗證。

需要復原時，請先透過用戶端關閉 TUN，等待介面與路由清除，再依原本使用方式恢復系統代理。若 Android 啟用了封鎖非 VPN 連線，也要檢查該設定。若仍無法上網，再確認系統中是否殘留手動 DNS、代理位址或其他 VPN；不要直接刪除無法確認用途的網路介面。

常見問題