進階設定 預計閱讀 12 分鐘

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

從虛擬網卡與路由表說明 TUN 模式如何接管未使用系統代理的應用程式，並介紹 stack、auto-route、dns-hijack 的設定與故障排除。

TUN 模式：在 IP 層接收應用程式流量

TUN 是一種虛擬網路介面。作業系統會將符合路由條件的 IP 封包交給這個介面，代理核心讀取封包後，再依據目的位址、網域與規則，決定直接連線或交由代理節點處理。TUN 與系統代理的差異，首先在於接收流量的位置，而非節點速度。

系統代理通常會告知應用程式：HTTP 或 SOCKS 代理位於某個位址，例如 127.0.0.1:7890。瀏覽器可能會遵循這項設定，但命令列工具、遊戲或使用自有網路堆疊的程式不一定會。TUN 透過系統路由導流，因此能接收部分未讀取系統代理設定的應用程式流量。

一條連線會經過哪些環節

  1. 應用程式發出網域解析請求，取得實際 IP，或由核心分配 Fake-IP。
  2. 應用程式建立 TCP 或 UDP 連線，作業系統查詢路由表並選擇虛擬介面。
  3. TUN 協定堆疊處理封包，核心還原連線資訊並比對規則。
  4. 核心透過實體網卡建立直連或代理連線，再將回傳資料送回應用程式。

此處的「全流量」應理解為系統層級的導流能力，並不保證涵蓋所有網路環境。明確綁定實體介面的程式、虛擬機內部網路、容器網路、排除的網段，以及未納入接管的 IPv6 路由，都可能走其他路徑。區域網路廣播與第二層網路探索協定，也不能簡單視為一般的 TUN 代理流量。

啟用前：確認核心、權限與設定來源

以下設定適用於支援這些欄位的 mihomo 核心。Clash 原版、舊版 Premium 核心與 mihomo 的 TUN 功能及欄位並不完全相同；用戶端名稱也不代表核心類型。請先在用戶端的核心資訊、「關於」頁面或啟動記錄中確認核心名稱與實際版本，再查閱對應版本的欄位說明。

先匯出目前可用的設定，並確認訂閱更新是否會覆寫修改。如果用戶端支援設定覆寫、設定合併或設定擴充，應透過這些機制儲存 TUN 設定。直接編輯訂閱產生的暫存檔，可能在下次更新或重新啟動後失效。相關通用欄位可參考設定參考。

最精簡設定：先確認流量接管，再套用代理策略

以下提供一份用於桌面環境故障排除的完整精簡設定。所有連線都會設為直連，目的是確認虛擬介面、路由與 DNS 是否正常運作，並非提供可用的代理節點。7890 是本例的混合代理連接埠，1053 是本機 DNS 監聽連接埠，兩者用途不同。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false

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
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

rules:
  - MATCH,DIRECT

範例 DNS 上游使用一般 DNS，方便區分故障原因，但不提供加密傳輸；請依所在網路的可連線性與隱私需求調整。ipv6: false 是為了縮小初次排查範圍，並不會停用作業系統的 IPv6，也不保證其他程式不會透過系統 IPv6 路徑連線。

stack：協定堆疊選項不是速度設定

欄位值處理方式選擇重點
system使用系統協定堆疊處理連線。可作為相容性比較基準，實際行為依平台實作而異。
gvisor使用使用者空間網路協定堆疊。遇到連線相容性問題時，可與其他方案交叉測試。
mixedTCP 使用 system，UDP 使用 gVisor。適合作為支援此選項的 mihomo 版本之起點。

不要認定某種 stack 在所有裝置上都比較快。作業系統、核心版本與實際流量都會影響結果。測試時只修改 stack 這個設定，重新啟動核心並建立新連線；不適合用既有的長連線判斷切換效果。

auto-route 與 auto-detect-interface

auto-route: true 會讓核心自動設定路由，將流量導向 TUN；它不是代理規則的開關。auto-detect-interface: true 用於自動選擇出站介面，協助代理連線從實際網路出口送出，避免再次進入 TUN 而形成迴圈。

同時使用多張網卡、其他 VPN、企業專線與虛擬交換器時，自動偵測不一定會選中預期的出口。請先檢查路由與介面，再考慮依目前核心支援的 interface-name 等欄位指定出口。請勿照抄其他電腦的介面名稱；Wi-Fi 與有線網路切換後，介面也可能改變。

DNS 接管：dns-hijack 與 Fake-IP 的關係

dns-hijack 會將進入 TUN 且符合目標條件的 DNS 流量交給核心 DNS 模組處理。範例中的 any:53 對應 UDP 53，tcp://any:53 對應 TCP 53。這不代表攔截所有名稱解析方式，也不是將所有流量導向本機的 1053 連接埠。

在 Fake-IP 模式下，核心可回傳對應位址給應用程式，例如 198.18.0.2，並在後續連線中利用映射找回網域。這有助於比對網域規則，但不代表該位址是網站伺服器的實際 IP。範例中的 198.18.0.1/16 是映射位址池，不應當作一般公網目的位址測試連線。

部分區域網路服務或應用程式會自行檢查解析結果，遇到這種情況時，可能需要依實際問題設定 fake-ip-filter，讓特定網域回傳實際位址。請勿直接排除所有網域，否則會改變整體 DNS 運作方式。切換 Fake-IP 與實際 IP 解析後，請重新啟動測試應用程式並清除舊的 DNS 快取，避免應用程式繼續使用舊映射。

啟用步驟：依序確認各項相依條件

  1. 先確認基本網路：關閉 TUN，確認目前網路可正常使用；若已有代理設定，先透過系統代理確認節點與策略群組可用，避免將節點故障誤判為虛擬網卡問題。
  2. 處理權限：依用戶端提供的方式啟用服務或完成系統授權。Linux 請先確認 /dev/net/tun 存在；不要只看介面上的開關顏色。
  3. 儲存設定並重新載入：先檢查設定，再啟動核心。查看啟動記錄，確認是否有建立虛擬介面失敗、權限不足或欄位解析錯誤等訊息。
  4. 暫時關閉系統代理：排除瀏覽器沿用舊代理設定連線的干擾。TUN 可以與系統代理並用，但初次驗證時應分開確認兩種連線路徑。
  5. 建立新連線：結束並重新開啟測試應用程式，查看用戶端連線清單中的目標網域、目標 IP、網路類型與命中規則。
  6. 恢復實際使用的規則：透過精簡的直連設定確認功能正常後，再套用原有代理群組與規則，分別檢查直連和代理連線的出口。

如果用戶端啟動時會自動重新啟用系統代理，請再次檢查開關狀態。應用程式自行儲存的 SOCKS 設定、終端機環境變數 HTTP_PROXY 與 ALL_PROXY 也會改變測試路徑，因此不能只因系統代理已關閉，就認定連線一定經過 TUN。

檢查路由與解析結果

以下命令用於檢視狀態，無法直接修復問題。請比較啟用前後的介面與路由差異。路由可能由多條分段規則或策略路由組成，不一定會以替換單一預設路由的方式呈現。

# Windows：在 PowerShell 中執行
Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
Resolve-DnsName example.com

# macOS：在終端機中執行
ifconfig
netstat -rn -f inet
route -n get 1.1.1.1

# Linux：同時檢視主路由與策略路由
ip link show
ip rule show
ip route show table all
ip route get 1.1.1.1

解析測試回傳 Fake-IP，只能證明某次解析經過相應的 DNS 路徑，不能證明應用程式連線已正確代理。完整驗證時應同時檢查連線記錄與出口：確認新連線進入核心、命中預期規則、使用預期策略，再透過實際存取目標服務確認結果。

常見故障：依序檢查介面、路由、DNS 與出口

已啟用開關，但看不到虛擬介面

優先檢查服務是否正在執行、授權是否完成、啟動記錄是否有錯誤，以及實際執行的設定是否包含 tun.enable: true。圖形介面的開關可能遭設定覆寫，也可能因核心啟動失敗而未生效。此時更換 DNS 通常無法解決問題。

啟用後所有應用程式都無法連線

先關閉 TUN 恢復網路，再檢查其他 VPN、出站介面選擇與 DNS 上游是否可連線。如果記錄中反覆出現連往相同目標的連線，請留意是否發生路由迴圈。不要同時調整 stack、DNS、MTU 與規則；保留一份可重現的設定，每次只變更一個項目。

如果網域無法連線，但已知 IP 的連線正常，請優先檢查解析路徑。反之，若 DNS 能正常解析但連線逾時，則應檢查路由、策略與節點。直接以 IP 開啟 HTTPS 網站，可能因憑證或虛擬主機機制而失敗；不能只憑這項結果判定網路中斷。

瀏覽器正常，遊戲或語音仍無法使用

先確認失敗的連線是否進入核心。如果已進入且使用 UDP，請再確認代理協定、所選節點與伺服器端是否支援 UDP 轉發。TUN 能接收 UDP，不代表每個代理出口都支援 UDP。瀏覽器可能會改用 TCP，因此網頁可正常瀏覽不代表遊戲連線也正常。

無法存取區域網路裝置、印表機或企業資源

確認目標是否為私有網路位址，以及是否與其他 VPN 或路由網段重疊。IP-CIDR,192.168.0.0/16,DIRECT,no-resolve 是策略層的直連規則範例，但直連流量仍可能先經過 TUN 接收流程。若需要在路由層排除某個網段，請確認目前核心支援的路由排除欄位；這與新增一條 DIRECT 規則並不相同。

關閉後仍無法恢復網路

優先正常結束用戶端，讓核心清除虛擬介面與路由，接著檢查系統代理是否仍指向已停止監聽的 127.0.0.1:7890。必要時重新連線網路或重新啟動系統。不了解企業路由用途前，請勿大量刪除路由表項目。

什麼時候該用 TUN，什麼時候只用系統代理

如果只需要瀏覽器連線，系統代理通常更容易檢視與排除問題。若遇到不遵循系統代理的應用程式、需要統一處理更多 TCP 與 UDP 連線，或想透過系統層級路徑套用規則，再考慮使用 TUN。TUN 增加了流量接管能力，也代表需要自行處理權限、路由與 DNS 設定。

TUN 設定可依序檢查：介面存在、路由生效、解析正常、規則正確、出口可連線。按照這個順序逐層驗證，比反覆切換多個開關更容易找出故障原因。

下載 Clash