Clash TUN 模式完全指南：透明代理與系統級流量接管

TUN 是什麼？跟「系統代理」有什麼不一樣？

在 Clash 生態裡，常見兩種讓流量進入核心的方式：一種是透過系統代理（System Proxy），把瀏覽器或支援讀取系統代理設定的應用程式導向本機的 HTTP／SOCKS 連接埠；另一種則是TUN 模式——核心會建立一張虛擬網路介面（常稱 TUN／TAP），作業系統把符合路由規則的IP 封包送進這張網卡，再由 Clash／mihomo 依你的 rules 決定要走代理還是直連。

差別在於：系統代理多半只影響「願意遵守系統代理」的程式；許多桌面軟體、遊戲、命令列工具或自行解析 DNS 的 App，可能完全不理會系統代理設定。TUN 則是在路由層攔截流量，只要封包依系統路由被送進 TUN，核心就有機會處理，因此常被稱為透明代理或全系統接管——更接近「整台機器預設都先經過分流規則」的體驗。

若你使用 mihomo（原 Clash Meta）核心，TUN 與 DNS、規則集（如 RULE-SET）的整合已相當成熟；核心升級與設定欄位演進可一併參考 mihomo 遷移與升級指南，避免沿用已廢止的 TUN／DNS 寫法。

工作原理：封包怎麼進到 Clash？

簡化來說，開啟 TUN 並設定 auto-route 等選項後，系統會把特定目標的流量導向虛擬網卡。核心在使用者空間收到這些封包後，再依規則決定是否轉送到某個代理節點、是否走直連，以及要如何處理 DNS。不同作業系統底層實作不同：Windows 可能搭配系統路由表與驅動／服務；macOS／Linux 則常見透過路由與防火牆規則配合；行動裝置則多由 VPN／Network Extension 類機制承載，細節依客戶端而定。

由於發生在 IP／路由層，TUN 通常能涵蓋不依 HTTP 代理運作的流量，這也是它和「只設系統代理」最大的體感差異。相對地，你也更需要關心路由是否繞回（loop）、區網與本機服務是否要排除，這些我們在後文會說明。

與系統代理、Mixed Port 的取捨

系統代理設定簡單、相容性問題少，適合主要以瀏覽器上網、且環境不允許動路由／虛擬網卡的場景。缺點是覆蓋範圍受限，遇到不走系統代理的程式就會「繞過」代理。

TUN適合需要整機一致分流、遊戲／開發工具／二進位程式都要納管的情況。缺點是需要較高權限、與路由／DNS 設定綁得更緊，除錯時要看的環節也更多。

Mixed Port（單一連接埠同時提供 HTTP 與 SOCKS）只是入站形式，與「要不要開 TUN」是正交選擇：你可以 Mixed 給本機瀏覽器用，同時又開 TUN 接管其餘流量；實務上依客戶端介面與核心版本整合即可。

如何在設定裡開啟 TUN？

以下以 mihomo 相容寫法為例（實際鍵名請以你所用核心版本文件為準）。重點是 tun.enable: true，並依環境打開路由與介面偵測：

# Example: TUN section (mihomo-compatible)
tun:
  enable: true
  stack: mixed
  dns-hijack:
    - any:53
  auto-route: true
  auto-detect-interface: true
  strict-route: true

stack: mixed在許多環境下能兼顧相容與效能；若遇特定程式異常，可再嘗試 system 或 gvisor 對照測試。

GUI 客戶端通常會提供「TUN 模式」開關與堆疊選項，本質上仍是寫入或覆寫上述設定。若你以視覺化介面管理規則與策略組，建議仍稍微了解 YAML 結構，遇到無法啟動或與訂閱模板衝突時會更好排查。規則撰寫與策略組觀念可搭配 Clash 規則分流詳解一併閱讀。

DNS、fake-ip 與「防洩漏」在 TUN 下的意義

開 TUN 後，DNS 若仍繞過核心，可能出現解析走本地／遠端不一致，或某些應用程式先解析再連線導致規則誤判。常見做法是開啟核心的 DNS 模組、搭配 enhanced-mode: fake-ip（或依需求改用 normal），並在 TUN 內做 DNS 攔截（dns-hijack），讓查詢盡量經過核心，與規則引擎一致。

fake-ip-filter 請務必保留區網、本機名稱、NTP、部分遊戲或裝置管理相關網域，避免「該直連卻拿到假 IP」造成連線異常。若你發現只有瀏覽器正常、其餘程式怪怪的，優先檢查 DNS 與 fake-ip 相關段落，再回頭看 TUN 是否成功啟用。

# Sketch: DNS + fake-ip (adjust nameservers for your region)
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "+.lan"
    - "+.local"
  nameserver:
    - 1.1.1.1
    - 168.95.1.1

strict-route 與路由：避免繞過 TUN

strict-route: true 的目的，是盡量避免流量沒走預期路徑而從實體介面「漏」出去。與 auto-route、auto-detect-interface 搭配時，能減少多網卡環境下選錯出口或策略路由造成的非預期直連。若你在公司網路、同時連線 VPN 或有多張網卡，開啟後仍異常，可記錄當下路由表與核心日誌再逐步收斂設定。

權限與平台差異

Windows：部分情境需要系統管理員權限或客戶端協助的驅動／服務安裝，否則 TUN 無法建立。若安全軟體阻擋虛擬網卡，需自行加入允許清單。

macOS：通常需使用者授權網路延伸或系統層級權限；建議使用會引導授權流程的現代客戶端，避免手動拼指令卻卡在簽章與隱私權設定。

Linux：常見需求是讓核心執行檔具備建立介面所需能力（例如 CAP_NET_ADMIN），實際指令依發行版與安裝方式而定。

任何需要提高權限的步驟，請只從可信任來源取得軟體；本站下載請使用官方頁面，勿輕信第三方改裝包。

常見問題與排查方向

開 TUN 後全機斷網或 DNS 繞圈

先確認 DNS 模組已啟用、fake-ip-filter 合理，並避免把核心自己的管理連線誤判進代理。可暫時改 enhanced-mode: normal 做對照，縮小問題是否在 fake-ip；同時確認沒有手動靜態路由與 TUN 搶同一批前綴卻指向矛盾下一跳。

區網印表機、NAS 或區網串流異常

請在規則中明確放行區網段（例如私有 IP 範圍）為 DIRECT，並把相關網域／IP 類規則放在合適優先順序；必要時在 fake-ip-filter 補上裝置名稱或內網網域後綴。

遊戲與 UDP／延遲變差

遊戲封包對延遲與路徑敏感，不一定適合強制走代理。可透過規則讓遊戲伺服器或整個進程相關流量直連，並關閉不必要的雙重 NAT 或錯誤的節點協定。若僅 TUN 開啟後才出現問題，可交叉測試 stack 選項與節點類型。

什麼情況其實不必開 TUN？

若你只用瀏覽器、且環境禁止虛擬網卡或不便給予權限，用系統代理往往更單純。又或你已用其他 VPN 類產品接管全系統路由，再疊加 TUN 可能衝突，需評估誰為「主路由」。簡而言之：TUN 強在覆蓋面，但不是每個場景都值得付出複雜度。

想從全站功能面了解代理模式與文件導覽，可見 Clash 功能與文件總覽，再回來對照本篇 TUN 相關設定，會更容易拼出完整圖像。

總結

TUN 模式讓 Clash／mihomo 有機會在系統路由層接手流量，達成接近「全系統透明代理」的效果；但要發揮穩定，必須一併處理好 DNS、路由與權限，並依環境微調 stack、strict-route 等選項。相比僅依賴系統代理，它能涵蓋更多類型的應用程式，卻也更需要耐心除錯——一旦規則與 DNS 收斂，長期使用上的一致性與可預期性通常會明顯優於「只靠瀏覽器走代理」的拼湊方案。

若你希望用現代客戶端視覺化開關 TUN、減少手刻 YAML 的負擔，不妨選擇與 mihomo 深度整合、且持續維護的版本；相較零散工具拼裝，整合型方案在穩定性與更新節奏上通常更省心。

立即免費下載 Clash 官方用戶端 →，全平台皆可取得，多數使用者能在短時間內完成安裝並依教學開啟 TUN 與分流。