1. TUN 接管流量，不代表所有連線都會走代理

瀏覽器可以上網，遊戲或終端工具卻沒有出現在 Clash 的連線清單中，常見原因是這些應用程式沒有使用系統代理。系統代理只會提供 HTTP 或 SOCKS 代理入口；TUN 模式則會建立虛擬網路介面，再透過路由將 IP 封包送進核心，不必仰賴應用程式支援代理協定。

本文的設定欄位以使用 mihomo 核心的用戶端為主。Clash 是用戶端生態系中常見的名稱，不代表所有同名或舊版程式都支援相同的 TUN 功能。操作前，請先到「關於」或「核心」頁面記下用戶端版本、核心名稱與版本；若使用的是舊版 Clash 核心，請勿直接套用 mihomo 的選項。

「所有流量」仍有例外：排除的應用程式或網段、未設定接管的 IPv6 流量，以及其他 VPN 的專用路由，都可能繞過 TUN。區域網路存取、群播探索及系統保留流量，也不應一概視為必須經過遠端代理。確認是否生效時，請查看連線紀錄與實際路由，別只看開關狀態。

2. 啟用前檢查：節點、權限與其他 VPN

  1. 先確認現有設定可正常使用。匯入訂閱，選取設定檔與可用節點，再透過系統代理開啟已知可連線的 HTTPS 網頁。若節點本身無法連線，啟用 TUN 也無法解決。
  2. 先備份現有設定。備份設定檔，並記下系統代理、DNS、TUN 與服務模式原本的狀態。請勿將訂閱網址、存取權杖或節點密碼貼到公開紀錄中。
  3. 暫時關閉其他 VPN。包括網路加速器、企業隧道及其他代理用戶端。這些程式可能同時修改預設路由或 DNS；企業設備請先確認管理政策。
  4. 確認代理協定支援情況。TUN 能接收 UDP，不代表所選節點與伺服器支援 UDP 轉送。遊戲、語音通話與 QUIC 是否可用，須分別測試。

桌面用戶端首次建立網卡或新增路由時，通常需要管理員、root 權限或受控的特權輔助程序。Android 使用的是系統 VPN 授權，與桌面版的「服務模式」不同，通常也不需要 root。

3. 四大平台的啟用步驟與授權差異

以下桌面版操作路徑以 Clash Verge Rev 等 mihomo 圖形用戶端的常見介面為例；不同版本可能將「TUN 模式」稱為「虛擬網卡模式」。找不到相同選項時，請查閱目前版本的設定說明，勿下載來源不明的所謂通用驅動修補程式。

Windows：先安裝服務，再啟用虛擬網卡

  1. 前往「設定」→「服務模式」，執行安裝或啟用，並在 Windows 的 UAC 提示中確認授權。若該版本將服務選項放在「設定」→「系統設定」，請依實際介面操作。
  2. 確認服務狀態顯示為執行中，再前往「設定」→「TUN 模式」或「虛擬網卡模式」開啟功能。首次啟用後請稍候，讓網卡完成初始化，避免連續反覆切換。
  3. 開啟紀錄，確認是否有權限遭拒、介面建立失敗或新增路由失敗等訊息。Windows 用戶端可能會使用 Wintun 等元件，驅動程式的提供方式由用戶端決定。
  4. 開啟「連線」頁面，執行先前未使用系統代理的應用程式，查看是否出現新紀錄，並確認套用的規則與策略群組。

服務模式會讓受控的背景服務執行需要權限的操作，但不代表代理一定能成功啟動。若介面顯示「服務已安裝」但仍無法使用，請進一步確認服務是否正在執行、核心程序是否已啟動，以及安全軟體是否封鎖網卡元件。請勿把長期關閉防火牆當成修復方式。

macOS：授權輔助服務，檢查 utun 介面

  1. 在用戶端的「設定」→「服務模式」中安裝或修復輔助服務，並依系統提示輸入管理員憑證。請勿將管理員密碼填入訂閱匯入欄位或節點設定中。
  2. 啟用「TUN 模式」，並允許用戶端完成所需的系統授權。授權視窗會因用戶端實作方式及 macOS 版本而異。
  3. 在終端機執行 ifconfig 查看介面，執行 netstat -rn 查看路由；macOS 通常會使用 utun 介面。

系統原本就可能有多個 utun 介面，因此「看到 utun」不代表目前的 Clash 已接管流量。請比對啟用前後的路由變化，並參考用戶端紀錄判斷。macOS 常見的 TUN 實作使用系統介面，不應套用 Windows 的 Wintun 安裝方式。

Linux：確認 TUN 裝置與網路管理權限

圖形用戶端建議優先使用內建的服務模式；若直接執行 mihomo，則依照 Linux 發行版文件設定 systemd 服務與權限。要檢查裝置是否存在，可執行：

ls -l /dev/net/tun
ip link show
ip route show
ip -6 route show

若 /dev/net/tun 不存在，請先檢查核心是否支援 TUN、模組是否已載入，以及容器是否有掛載該裝置。建立介面與調整路由通常需要 CAP_NET_ADMIN；容器中的程序即使以 root 執行，也可能缺少必要權限。請勿直接為整個圖形用戶端設定範圍過大的永久提權權限。

啟用後，檢查 ip rule show 與路由表，排查 NetworkManager、容器網路或其他 VPN 的規則衝突。部分 mihomo 版本提供 Linux 專用的 auto-redirect，但這不是跨平台設定的必要條件，請勿在所有裝置上照搬。

Android：允許建立 VPN，再檢查個別應用程式設定

  1. 在使用 mihomo 的 Android 用戶端匯入設定檔，點選首頁的啟動或連線按鈕。
  2. 首次啟動時，請在系統的「連線要求」視窗中允許建立 VPN。Android 用戶端通常透過 VpnService 建立虛擬介面，不需另外安裝桌面驅動程式。
  3. 查看用戶端「設定」中的「存取控制」或「個別應用程式代理」。若啟用「僅代理所選應用程式」，未勾選的應用程式就不會被接管。
  4. 若切換到背景後連線中斷，請檢查系統「設定」→「應用程式」→目前用戶端→「電池」中的背景限制；各系統的選項名稱可能不同。

同一個使用者設定檔下，Android 通常一次只能維持一個使用 VpnService 的 VPN。啟動另一個 VPN、廣告過濾器或加速器後，可能會取代目前的連線。「永遠開啟 VPN」與「封鎖未經 VPN 的連線」是系統層級的政策，設定錯誤可能直接導致斷網，建議完成基本測試後再考慮啟用。

4. stack 怎麼選：system、gvisor 與 mixed

stack 是 TUN 內部處理網路流量的協定堆疊選項，不是代理協定，也不是節點類型。mihomo 常見的選項有 system、gvisor 與 mixed；實際支援情況仍取決於核心版本與平台。

選項主要差異調整建議
system使用與系統協定堆疊相關的實作處理流量若用戶端預設使用此選項且連線正常，可維持不變。
gvisor使用使用者空間網路協定堆疊遇到相容性問題時，可用來進行對照測試。
mixed在 mihomo 中，TCP 使用 system，UDP 使用 gvisor請分別觀察 TCP 與 UDP 的表現，不能只靠網頁測試判斷。

不要把某種 stack 當成固定的「遊戲最佳設定」。先維持用戶端預設值；若特定應用程式連線異常，每次只修改一個選項，重新啟動 TUN 後再測試。MTU 也應比照辦理：先使用預設值，只有在大封包傳輸卡住、隧道封裝等線索明確時才調整，不要只因延遲偏高就隨意改成 9000。

5. DNS 劫持設定：接管 53 埠查詢

應用程式會先將網域名稱解析成 IP，再建立連線。若 DNS 查詢沒有進入預期的解析流程，可能導致網域規則無法正常套用、解析結果異常或連線逾時。TUN 的 dns-hijack 用來將符合條件的傳統 DNS 請求交由核心 DNS 模組處理；此處的「劫持」是將本機查詢轉向，並非修改遠端網站。

mihomo 設定片段

以下範例會啟用 IPv4 TUN、自動路由，以及接管 UDP/TCP 53 埠。這不是完整訂閱，不能取代整份設定檔。請先備份，再透過用戶端支援的覆寫或合併功能套用；若已有 tun 或 dns 欄位，應合併內容，不要在 YAML 頂層重複新增同名鍵。

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:
    - 223.5.5.5
    - 119.29.29.29
  • auto-route：讓核心自動設定接管流量所需的路由；但不保證能涵蓋已排除或被其他軟體搶先設定的路徑。
  • auto-detect-interface：自動選擇輸出介面；在多網卡、熱點或企業 VPN 環境中，仍須確認選擇結果。
  • any:53 與 tcp://any:53：分別比對傳統 UDP 與 TCP DNS 查詢；能否接管仍取決於流量是否進入 TUN。
  • 127.0.0.1:1053：本機 DNS 監聽位址。系統 DNS 設定通常不能直接填入含 1053 埠的位址；此範例是透過 TUN 轉送查詢。
  • nameserver：範例列出兩個具體的傳統 DNS 上游伺服器，實際選擇應考量網路連線能力、隱私需求與分流設計，並非所有網路都適用。

Fake-IP 回傳保留位址，是一種映射機制

使用上述設定時，DNS 可能會回傳 198.18.0.0/16 範圍內的映射位址，再由核心將連線對應回網域名稱。這不是目標網站的真實公網 IP。若區域網路裝置探索、特定遊戲或內部網域發生相容性問題，可針對特定網域設定 fake-ip-filter，或改用用戶端支援的其他 DNS 模式，不要刪除整份 DNS 設定。

Android 的「私人 DNS」也需另外考量。若應用程式繞過核心 DNS，改走其他解析路徑，請檢查其連線與分流結果。IPv6 也需要端到端設定：本範例未提供 IPv6 接管方案，因此不能據此認定 IPv6 已涵蓋。啟用雙堆疊前，請確認核心、路由、DNS 回應與節點能力。

6. 三步驟驗證：介面、連線紀錄與 DNS

  1. 確認介面與路由。紀錄中應顯示 TUN 已成功啟動，而非不斷重試。Windows 可用 route print、macOS 用 netstat -rn、Linux 用 ip route show 檢查路由變化。不同實作可能建立分段路由或政策路由，不一定會直接取代預設路由。
  2. 確認非系統代理應用程式已進入核心。關閉該應用程式本身的代理設定後重新連線，再查看 Clash 的「連線」頁面。桌面環境也可暫時關閉系統代理，只保留 TUN 進行比對；企業設備請勿任意變更受管理的設定。
  3. 確認 DNS 解析與規則結果。查詢尚未快取的網域名稱，檢查紀錄、DNS 回應及後續連線是否一致。Fake-IP 模式出現映射位址本身並非錯誤，重點是連線能否建立，以及是否套用預期策略。

例如可執行以下命令測試一次 HTTPS 請求。此操作僅用來驗證連線路徑，不代表測速或任何實測效能結果：

curl --noproxy "*" -I --connect-timeout 10 https://example.com

--noproxy "*" 可略過 curl 的一般代理設定，方便觀察 TUN 路徑；在 Windows PowerShell 中，建議明確使用 curl.exe，以免受命令別名影響。測試後應在連線清單中核對目標網域、符合的規則與輸出策略；命令成功回應本身不足以證明流量經過遠端代理。

7. 常見故障與安全復原

啟用 TUN 後所有網頁都無法開啟

先關閉 TUN，確認基本網路已恢復，再檢查服務權限、目前設定、DNS 上游是否可連線，以及是否有其他 VPN。若關閉後仍無法解析，請檢查是否留下手動 DNS 或系統代理設定，並還原成操作前記錄的狀態。不要同時重裝用戶端、更換節點、stack 和 DNS，否則難以找出真正原因。

網頁正常，但遊戲或語音仍無法使用

先確認相關程序是否出現在連線清單，再檢查節點是否支援 UDP。瀏覽器能開啟網頁，通常只能證明部分 TCP 或 HTTPS 路徑正常。Android 還要確認遊戲是否被個別應用程式規則排除；桌面環境則檢查遊戲是否綁定特定網卡，以及是否有其他加速器路由。

區域網路印表機、NAS 或企業網域無法使用

先確認目標應直連，還是需要透過企業 VPN 路由，再調整對應規則、DNS 解析策略或 TUN 路由排除設定。規則中的 DIRECT 與路由排除並不相同：前者仍由核心處理後直連，後者則讓指定流量不進入 TUN。若內部網域依賴企業 DNS，通常無法用公共 DNS 上游取代。

關閉用戶端後網路沒有恢復

建議先重新開啟用戶端，正常關閉 TUN 並退出，讓程式完成清理；接著檢查系統代理、DNS 與殘留服務狀態。遠端操作伺服器時尤其要留意：修改預設路由可能會中斷 SSH，請預先準備主控台或帶外管理方式，勿直接在唯一的管理連線上嘗試。