Clash TUN 模式教学：虚拟网卡运作原理与启用方法

TUN 模式與系統代理：流量進入核心的方式不同

Clash 的系統代理與 TUN 模式，都是要解決同一個問題：應用程式發出的連線如何進入核心。系統代理會提供本機 HTTP 或 SOCKS 代理位址給應用程式；TUN 則會建立三層虛擬網路介面，透過作業系統路由，將符合條件的 IP 封包送入核心。兩者都不是節點通訊協定，也不會取代訂閱中的代理伺服器。

瀏覽器通常會遵循系統代理設定，但部分遊戲、命令列工具及使用自有網路堆疊的應用程式不會讀取這項設定。因此，即使瀏覽器已透過代理連線，其他程式仍可能直接連線。TUN 不需要這些程式支援 HTTP 代理，但流量涵蓋範圍仍受路由、排除項目、權限及通訊協定支援限制。

比較項目	系統代理	TUN 模式
接入方式	應用程式連線至本機代理連接埠	系統路由將 IP 封包送入虛擬網卡
常見入口	例如本機混合連接埠 7890	TUN 介面與對應路由，應用程式不必設定代理連接埠
UDP 流量	系統 HTTP 代理通常無法涵蓋	可以接管，但出站節點也必須支援 UDP
權限需求	通常只需修改使用者代理設定	桌面版需要相應的系統權限；Android 需要 VPN 授權
常見影響	未遵循設定的應用程式會繞過代理	可能與其他 VPN、虛擬網卡或路由規則衝突

虛擬網卡、路由與出站連線的運作流程

以連線至網站的 TCP 連線為例，應用程式會先取得目標 IP，再由作業系統查詢路由表。啟用自動路由後，符合接管條件的封包會進入 TUN 介面；核心讀取目標位址及可取得的網域資訊，依序比對規則，最後建立直連或代理出站連線。

應用程式送出封包：應用程式照常建立網路連線，不必設定 127.0.0.1:7890。
路由選擇：核心設定的路由會決定哪些位址進入虛擬網卡。實體介面、區域網路路由和排除規則也會一併納入判斷。
通訊協定處理：TUN 通訊協定堆疊會處理接收到的 IP 流量，再交由規則與出站模組處理。
選擇出口：符合條件的策略可能是 DIRECT、拒絕策略或某個代理群組，不一定會固定使用同一個節點。
傳回資料：核心會將回應送回應用程式，同時確保連往代理伺服器的連線透過實際網路出口傳送，避免再次進入 TUN 形成迴圈。

因此，「TUN 已啟用」只代表部分流量入口設定已生效。節點無法使用、代理群組選擇錯誤、DNS 逾時或出口介面選錯，都可能導致應用程式仍無法連線。排查時應分別確認虛擬網卡是否建立、連線是否進入核心，以及最後選用了哪種出站方式，不能只看開關狀態。

DNS 劫持與 fake-ip：保留網域比對條件

多數應用程式會先解析網域，再連線至 IP。如果 DNS 查詢完全繞過核心，核心可能只看得到目標 IP，網域規則便缺少直接比對的依據。DNS 接管可將查詢導入核心的解析模組，搭配快取對應或其他網域識別機制，提供分流所需資訊。

接管連接埠 53 的範圍

在 mihomo 的 TUN 設定中，dns-hijack 可指定接管目的連接埠為 53 的 DNS 流量。any:53 通常用於 UDP DNS，tcp://any:53 則用於 TCP DNS。這不是攔截所有加密 DNS 的通用方式：應用程式內建的 DoH 通常透過 HTTPS 連接埠 443 傳送，DoT 通常使用連接埠 853，不會因為設定了連接埠 53 就自動改由核心進行 DNS 查詢。

fake-ip 並非實際伺服器位址

fake-ip 模式會為符合條件的網域回傳保留位址範圍內的對應位址，例如 198.18.0.0/16 範圍內的位址。應用程式連線至這個位址後，核心會根據對應資料找回網域，再進行規則判斷與實際出站處理。這是本機對應機制，並非遠端網站將實際位址改成了該網段。

區域網路網域：路由器管理位址、印表機和企業內部服務可能需要取得實際解析結果。應搭配內網 DNS 設定 fake-ip-filter 或專用網域解析策略。
快取殘留：關閉 TUN 後，如果應用程式仍使用快取中的 fake-ip 位址，可能會暫時無法連線。請重新啟動受影響的應用程式，必要時清除系統 DNS 快取。
瀏覽器加密 DNS：排查時可先暫時關閉瀏覽器自訂的安全 DNS，統一解析路徑；確認原因後，再決定是否保留這項設定。
IPv6：IPv4 可連線不代表 IPv6 也能正常接管。請一併確認核心、DNS、路由和節點是否支援 IPv6。

mihomo 設定範例：先確認核心，再合併欄位

以下範例適用於支援相應欄位的 mihomo 核心。Clash 是用戶端生態中常見的名稱，但不同用戶端搭載的核心並不相同，原版 Clash 的不同建置版本也不能直接套用這份設定。請先在用戶端的「關於」頁面或執行記錄中確認核心名稱，再確認用戶端是否會透過圖形介面設定覆寫這些欄位。

這段設定只示範 DNS 與 TUN，不包含節點、代理群組和分流規則，不能直接當成完整訂閱匯入。請合併至現有設定中對應的頂層欄位，避免出現兩個 dns: 或兩個 tun:。

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
  nameserver:
    - https://dns.alidns.com/dns-query

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

欄位	用途與檢查項目
`listen: 127.0.0.1:1053`	本機 DNS 監聽位址。1053 不是代理連接埠，也不代表系統會自動使用它。
`stack: mixed`	在支援的 mihomo 建置版本中，可搭配不同的通訊協定堆疊處理 TCP 與 UDP。若遇到相容性問題，可依目前核心文件測試其他堆疊。
`auto-route`	自動設定接管路由。關閉後通常需要自行維護路由，不建議在初次排查時預設停用。
`auto-detect-interface`	自動辨識出站介面。若有多張網卡同時啟用，仍應確認實際出口。
`default-nameserver`	用於解析 DNS 上游的網域。範例中的上游必須能從目前網路連線，範例位址並非所有網路都適用的固定答案。

Windows、macOS、Android 啟用步驟

Windows：先設定服務或系統管理員權限

先保持 TUN 關閉，確認目前訂閱能透過系統代理正常存取目標網站。如果這時就無法連線，應先處理節點或訂閱問題。
在用戶端中尋找服務模式、安裝服務或權限相關選項。支援背景服務的用戶端通常需要先進行一次系統管理員授權；其他實作方式可能需要提高用戶端的執行權限，請以用戶端說明為準。
關閉其他 VPN 的自動連線，啟用用戶端中的「TUN 模式」，並檢查記錄是否出現介面建立、路由新增或 DNS 監聽錯誤。
暫時關閉系統代理，再測試一般應用程式及原本不會遵循系統代理的應用程式，避免把系統代理生效誤認為 TUN 已生效。

Windows 11 的系統代理設定可在「設定」→「網路和網際網路」→「Proxy」中確認。排查時可使用 route print 查看路由，並透過 PowerShell 的 Get-NetAdapter 查看網卡。虛擬網卡名稱由用戶端決定，不應只憑某個固定名稱判斷是否成功。

macOS：確認輔助服務授權與網路出口

確認用戶端及其核心支援 TUN。依照提示安裝或授權必要的特權輔助服務，不要把系統代理開關當成 TUN 開關。
啟用 TUN 後，檢查用戶端記錄與系統路由。可在終端機使用 ifconfig 查看介面，並使用 netstat -rn 查看路由。
切換 Wi-Fi、有線網路或手機熱點後重新測試。如果仍選用舊的出口，請先重新啟動核心或停用後重新啟用 TUN，再確認介面辨識結果。

系統代理通常位於「系統設定」→「網路」→目前的網路服務→「詳細資訊」→「代理伺服器」。系統中出現 utun 介面本身，並不能證明它屬於目前的用戶端，因為其他網路服務也可能建立同類介面。請搭配啟用時間和記錄判斷。

Android：VPN 授權就是流量入口

Android 用戶端通常會使用系統 VpnService 建立虛擬網路介面。首次連線時會出現系統 VPN 授權提示；未授權就無法建立相應的流量接管路徑。這不代表已授予用戶端 root 權限，也不表示訂閱已成功連線。

匯入訂閱並選擇可用策略，點選用戶端的連線按鈕，然後確認系統 VPN 授權。
檢查應用程式分流或略過清單，確認目標應用程式未遭排除；部分用戶端還會區分「僅代理所選應用程式」與「略過所選應用程式」。
在系統設定中檢查「一律使用 VPN」以及「未連線 VPN 時封鎖連線」等選項。不同廠牌的名稱可能不同，這些選項也可能阻止其他用戶端建立連線。
如果螢幕關閉後就中斷連線，請再檢查背景執行和電池最佳化限制，不要反覆更換 DNS 來掩蓋程序遭系統停止的問題。

同一個 Android 使用者或工作資料空間通常只能維持一個作用中的 VPN 服務。使用 VPN 介面的防火牆、過濾工具和代理用戶端可能會互相取代。桌面版 YAML 的 TUN 欄位也不一定是 Android 用戶端有效的設定方式，建議優先使用用戶端提供的設定。

TUN 啟用後無法上網：依連線流程逐層排查

建議每次只修改一項，並保留修改前的設定。先確認是所有應用程式都無法連線、只有特定網域無法連線，還是只有 UDP 功能異常；這三種情況的排查方向不同。

狀況	優先檢查	處理方式
開關立即關閉或介面建立失敗	權限、服務狀態、介面衝突	查看第一筆錯誤記錄，確認服務已啟動，暫時停用其他 VPN 後再試一次。
無法存取網域	DNS 上游與接管路徑	檢查 DNS 逾時記錄；使用 `nslookup example.com` 查看系統查詢結果，但這不能證明瀏覽器也採用相同的解析路徑。
網頁可正常使用，但語音或遊戲無法連線	UDP 出站能力、規則與 MTU	確認節點通訊協定及伺服器端允許 UDP，先查看連線記錄，再依目前核心文件調整 MTU。
無法連線至印表機、NAS 或內網網域	區域網路路由與內部 DNS	確認實際網段、直連規則及 TUN 路由排除項目，避免將整個內網流量送往遠端節點。
連線已建立，但出口不正確	模式、符合的規則與代理群組	在連線記錄中查看符合的規則與完整策略鏈，確認是否符合 `DIRECT` 或錯誤的預設策略。
關閉 TUN 後仍無法上網	殘留代理設定、DNS 快取、路由	結束用戶端後檢查系統代理，重新啟動受影響的應用程式，再確認路由是否已恢復。

排除區域網路流量與 DIRECT 是不同層級的操作

在規則中將內網位址指定為 DIRECT，表示連線進入核心後選擇直連；在 TUN 路由層排除網段，則可能讓流量完全不進入核心。兩者用途不同。企業 VPN 情境尤其需要先了解公司網段和 DNS 的設定方式，不宜直接套用涵蓋所有私有位址的排除清單。

MTU 與雙 VPN 衝突留待後續檢查

只有部分大型回應、上傳或特定 UDP 連線卡住時，才需要進一步檢查路徑 MTU。單純降低 MTU 無法修復 DNS 無法連線或節點失效的問題。兩套 VPN 同時修改預設路由時，也可能造成路由迴圈或出口改變；請先分別確認兩者能獨立運作，再評估進階路由組合。

啟用後的檢查清單與復原方式

確認流量入口：關閉系統代理並保持 TUN 啟用，測試目標應用程式，並查看連線記錄是否出現對應連線。
確認分流結果：分別存取一個應直連和一個應走代理的目標，在記錄中確認符合的規則與策略鏈。查詢出口 IP 只能作為輔助驗證，無法證明所有應用程式都已被接管。
確認 DNS：檢查解析是否成功、是否符合預期的 fake-ip 或實際位址模式，以及內網網域能否正常存取。
確認必要功能：實際測試所需的語音、遊戲或其他 UDP 功能。ping 使用 ICMP，不能單憑結果判斷 TCP、UDP 代理連線是否正常。
確認網路已復原：關閉 TUN，確認一般網路是否恢復。Windows 可視需要執行 ipconfig /flushdns 清除系統 DNS 快取，並重新啟動仍保留舊位址的應用程式。

如果只有瀏覽器和遵循系統代理的應用程式需要代理，系統代理通常較容易觀察和維護。若確實需要涵蓋不會讀取代理設定的程式，或需要統一處理 UDP，再啟用 TUN，並保留一份已驗證的復原設定。設定穩定與否，取決於流量入口、解析、規則和出口都能清楚說明，而不是開關越多越好。