核心差異：由應用程式主動連線代理，或由路由將流量導入虛擬網卡

系統代理仰賴應用程式配合，TUN 則依靠作業系統路由。這是判斷兩者涵蓋範圍的關鍵。系統代理通常會將本機 HTTP 代理位址寫入系統網路設定；支援這項設定的應用程式會連線至 Clash 的本機監聽埠，再由核心比對規則。忽略系統設定、使用獨立代理設定，或直接建立網路連線的程式，可能不會走這條路徑。

TUN 則會建立第三層虛擬網路介面，讓符合路由條件的 IP 封包進入核心處理。應用程式不必知道本機代理位址，因此能涵蓋更多直接連網的軟體。不過，「啟用 TUN」不等於「所有流量都經由遠端節點」：路由排除項目、其他 VPN、介面優先順序與代理規則，仍會影響實際路徑。

用戶端、核心與訂閱各自負責什麼

  • 用戶端：提供系統代理開關、服務管理、設定編輯與連線清單。不同專案的選單名稱和授權方式各不相同。
  • 核心：負責協定處理、DNS、規則比對與 TUN 網路堆疊。Clash、Clash Premium 與 Clash Meta（後續使用 mihomo 名稱）的功能不能直接視為相同。
  • 訂閱：提供節點或完整設定。訂閱可以影響策略群組、規則與 DNS，但無法取代作業系統所需的虛擬網卡權限。

本文以 mihomo 為例說明設定欄位。請先在用戶端的核心資訊或啟動記錄中確認實際執行的核心，再核對欄位支援情況；不要只憑應用程式名稱判斷是否支援 TUN。

系統代理：適合瀏覽器，命令列工具須另外確認

在 Windows 11 中，可依序前往「設定」→「網路和網際網路」→「Proxy」→「手動設定 Proxy」，確認系統代理位址。假設用戶端的 HTTP 或 mixed 監聽埠為 7890，位址通常填入 127.0.0.1，連接埠填入 7890。此處的連接埠僅為範例，必須與目前生效的設定一致。

瀏覽器通常會使用系統代理，但瀏覽器擴充功能、獨立代理選項與略過清單都可能改變結果。系統中的使用者代理設定與 WinHTTP 設定也不是同一套機制；不能因為瀏覽器已能連網，就推斷背景服務和所有桌面應用程式都會使用相同代理。

用 curl 區分「節點可用」與「系統代理已生效」

以下兩個指令適用於 Windows 終端機。第一個明確指定 HTTP 代理，第二個直接發出請求；第二個是否使用代理，仍取決於環境變數等設定，因此不能把它當成必定直連的對照組。

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com
curl.exe --connect-timeout 10 -I https://example.com
  • 明確指定代理後請求成功，一般請求卻失敗：先檢查終端機環境變數與應用程式的代理支援，不要立刻更換節點。
  • 顯示無法連線至 127.0.0.1:7890：請檢查監聽埠、核心狀態與本機防火牆。
  • 已連上本機代理，接著 TLS 或遠端連線失敗：請繼續查看節點交握、DNS 與規則比對記錄。

在 macOS 或 Linux 上，可為單一指令設定環境變數，例如 HTTPS_PROXY=http://127.0.0.1:7890 curl -I https://example.com。變數名稱代表 HTTPS 請求的代理設定，但代理位址仍可使用 HTTP 協定；這不表示本機監聽埠必須啟用 TLS。不同工具對變數名稱大小寫及 SOCKS 的支援各有差異，請以工具文件為準。

TUN 模式：涵蓋更多連線，但需要權限與路由配合

TUN 接收 IP 封包，再由核心透過網路堆疊處理 TCP、UDP 等流量，並依設定建立出站連線。遊戲或命令列工具不必主動連線至 HTTP 代理，因此適合無法設定應用程式代理的情境。用戶端通常需要管理員權限、服務模式或相應的系統授權，才能建立介面、調整路由與處理 DNS。

mihomo 最基本的欄位範例

以下是設定片段，並非完整訂閱。範例假設現有節點、策略群組、規則與 DNS 模組都已正確設定。用戶端可能透過覆寫機制產生最終設定，請檢查實際生效的內容，而不只是修改可能被訂閱更新覆蓋的來源檔案。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
  • enable：啟用 TUN 功能；若介面建立失敗，請先檢查權限與服務記錄。
  • stack：選擇網路堆疊實作。mixed 是 mihomo 提供的選項，不適用於所有舊版核心。
  • auto-route：自動設定接管流量所需的路由，不代表涵蓋所有介面與例外路徑。
  • auto-detect-interface：協助選擇出站介面；若同時執行多個 VPN，仍可能需要手動檢查。
  • dns-hijack：將符合條件的 DNS 請求交由核心 DNS 模組處理；上例比對 UDP 53 埠，不包含所有加密 DNS。

情境比較：命令列工具、遊戲與 UWP 應用怎麼選

情境系統代理的表現使用 TUN 的條件
瀏覽器網頁通常可用，請檢查擴充功能與略過項目可接管流量，但只瀏覽網頁通常不必啟用
curl、Git 等工具通常需要明確指定代理參數或設定環境變數依靠路由接管，可減少逐一設定應用程式
UDP 遊戲連線HTTP 系統代理通常無法涵蓋需要支援 UDP 出站，並設定正確規則
受隔離的 UWP 應用程式存取本機代理可能受到回環限制可能避開本機 HTTP 代理路徑，但仍須實際測試
區域網路與企業資源可透過代理略過清單排除須確認區域網路路由、DNS 與 VPN 是否衝突

遊戲：先確認 UDP，再比較延遲

遊戲下載通常使用 TCP/HTTPS，但遊戲對戰可能使用 UDP；啟動器下載成功，不代表對戰連線已被接管。請在連線清單中依處理程序、目標位址與網路類型查看規則比對結果，再確認策略群組最終選擇的節點支援 UDP。部分遊戲也會受到 NAT、地區配對與反作弊機制影響，TUN 無法保證改善這些條件。

節點清單中的 HTTP 延遲測試，也不能直接代表遊戲延遲。可在相同伺服器、相近時段，分別記錄直連與代理各 5 分鐘的遊戲內延遲和封包遺失率。例如「網頁探測 80 毫秒、對戰 140 毫秒」只是兩種測量對象的示例，不能據此判定設定錯誤；應比較相同指標的前後變化。

UWP：區分回環限制與網路故障

某些受 AppContainer 隔離的應用程式無法直接存取本機回環代理，必須依應用程式設定回環豁免。排查問題時，請勿一次對所有應用程式開放權限；先確認目標應用程式是否受此限制，再使用用戶端提供的工具或 Windows 相應的管理方式。TUN 可能讓應用程式不再直接連線本機 HTTP 代理，但無法保證解決登入服務、憑證、應用程式自身 DNS 或遠端地區限制。

DNS 與 Fake-IP：啟用 TUN 不代表已確認沒有 DNS 洩漏

DNS 決定網域名稱如何解析，也會影響核心能否依網域規則比對。Fake-IP 模式會為網域名稱回傳虛擬位址，並在後續連線中透過對應資訊還原網域名稱；它不是遠端節點，也不是加密協定。Fake-IP 常與 TUN 搭配使用，但兩者是不同功能。

使用系統代理時，HTTP CONNECT 請求通常能將目標網域名稱交由代理處理，但應用程式仍可能自行預先解析，或使用獨立 DNS。使用 TUN 時，傳統 DNS 可透過路由與 DNS 劫持交由核心處理；瀏覽器內建 DoH、Android 私人 DNS 或其他加密解析方式，不會只因設定了 any:53 就全部納入同一套解析策略。

  1. 確認用戶端最終設定中的 DNS 模組已啟用，並檢查 enhanced-mode 與上游解析設定。
  2. 檢查系統解析器、瀏覽器安全 DNS 與其他 VPN，釐清各類請求分別由哪一方處理。
  3. 切換模式後，請重新建立應用程式連線；必要時清除 DNS 快取，避免舊的解析結果影響判斷。
  4. 搭配 DNS 記錄與連線記錄確認流量路徑，不要只依賴檢測網頁顯示的解析器地理位置。

檢測頁面顯示本地電信業者的解析器，是值得進一步調查的訊號，但不能據此下定論。分流設定可能刻意讓直連網域使用本地解析；關鍵在於原本應透過指定路徑解析的網域，是否真的偏離預期。

驗證順序：每次只調整一項流量接管設定

初次排查時，不建議同時切換 TUN、系統代理、DNS 模式與節點。變動項目過多，即使恢復連線也無法確認真正原因。請先固定一個已知可用的節點，再依照下列順序檢查。

  1. 確認本機入口：關閉 TUN，使用明確指定代理的參數連線至測試網址，確認範例連接埠 7890 確實由目前的核心監聽。
  2. 確認系統代理：啟用系統代理，以瀏覽器建立新連線，查看連線清單是否出現目標網域與符合的規則。
  3. 單獨測試 TUN：暫時關閉系統代理與應用程式的明確代理設定，啟用 TUN 後重新啟動目標應用程式，避免沿用舊連線。
  4. 確認出站路徑：查看符合的規則、策略群組與最終節點。只確認連線進入核心，還不足以證明流量經由遠端代理。
  5. 檢查實際使用情況：用瀏覽器測試網頁、用遊戲測試實際對戰、用終端機測試目標儲存庫或 API；不要用單一速度測試取代所有情境的驗證。

啟用 TUN 後無法連網

先關閉 TUN，確認基本網路能否恢復。接著依序檢查介面是否建立、服務權限是否正常、預設路由是否被其他 VPN 取代，以及 DNS 是否可連線。若記錄中反覆出現連線重試，也要檢查節點伺服器位址解析，以及出站路徑是否形成迴圈。不要持續增加路由規則來掩蓋介面選擇錯誤。

無法連線至區域網路印表機或企業內網

記下實際內網網段，例如 192.168.10.0/24，再檢查直連規則與路由排除設定。代理規則中的 DIRECT 表示流量進入核心後直接出站；路由排除則可能讓封包根本不進入 TUN，兩者作用於不同層次。企業 VPN 也可能需要專用 DNS，不能只新增一條 IP 規則就認為問題已排除。

選擇建議：依照流量涵蓋需求逐步增加複雜度

  • 主要用來瀏覽網頁：優先使用系統代理，並透過瀏覽器連線記錄確認是否生效。
  • 只需要代理少數開發工具：優先為工具明確設定 HTTP 或 SOCKS 代理，設定範圍清楚，也方便重現問題。
  • 多個應用程式不遵循系統代理：可考慮使用 TUN，並優先檢查權限、DNS、UDP 與區域網路存取。
  • 同時執行企業 VPN：先確認組織的網路要求，再測試路由與 DNS 能否共存；不要預設兩個虛擬網路可以直接疊加使用。

穩定運作後，可依用戶端設計同時啟用系統代理與 TUN，但排查問題時應分開測試。兩者同時開啟不一定會重複代理，也不代表涵蓋範圍更完整；應用程式可能直接連線本機代理，其他連線則走虛擬網卡。保留一條清楚且可驗證的接管路徑，比單純開啟更多開關更重要。