Clash TUN 模式與系統代理差異：流量入口、涵蓋範圍與選擇方式

系統代理和 TUN 模式解決的是同一個入口問題：如何將裝置產生的連線送入 Clash 或 mihomo 核心。兩者都不會直接決定某個網站使用代理還是直連。流量進入核心後，仍須依目前的運作模式、規則集、策略組與節點狀態完成匹配。因此，「啟用 TUN」不等於切換至 Global 全域模式，「啟用系統代理」也不代表所有應用程式都會被接管。

流量入口：系統代理讀取設定，TUN 接收網路封包

系統代理的運作路徑

啟用系統代理時，Clash 用戶端通常會將作業系統的 HTTP、HTTPS 或 SOCKS 代理位址寫入本機回環位址，並指向核心監聽的連接埠。例如核心運作於 127.0.0.1:7890，支援系統代理的瀏覽器或桌面應用程式讀取這項設定後，便會主動將請求交給該連接埠。用戶端關閉系統代理時，則會還原先前的作業系統設定。

這種方式位於應用程式層。應用程式必須讀取系統代理，或明確使用作業系統提供的網路介面，流量才會進入 Clash。常見瀏覽器、辦公軟體與部分桌面用戶端通常可以直接運作；自行實作網路堆疊、忽略代理設定，或只支援特定協定的程式，則可能繼續直接連線。命令列工具也各有差異：有些會讀取環境變數，有些則需要另外指定 HTTP_PROXY、HTTPS_PROXY 或 SOCKS 位址。

TUN 模式的運作路徑

TUN 模式會建立虛擬網路介面，並透過系統路由將符合條件的 IP 流量送入該介面。mihomo 核心從虛擬介面讀取網路封包，辨識目標位址與協定，再依規則決定直連、拒絕，或轉送至代理節點。由於入口更接近作業系統網路層，應用程式通常不需要理解 HTTP 或 SOCKS 代理，也不必主動讀取系統代理設定。

因此，TUN 更適合接管遊戲啟動器、終端機程式、部分商店應用程式、使用 UDP 的程式，以及忽略系統代理的桌面軟體。不過，TUN 的涵蓋範圍仍會受到路由表、排除項目、核心協定支援與作業系統限制影響。區域網路網段、預設網卡、虛擬機網卡、容器網路或其他 VPN 都可能改變實際路徑，不能只根據開關狀態判斷是否已完成接管。

四項關鍵差異：涵蓋範圍、協定、DNS 與權限

比較項目	系統代理	TUN 模式
工作層級	應用程式讀取作業系統代理設定後，連線至本機代理連接埠	虛擬網路介面接收經由系統路由的 IP 流量
應用程式涵蓋範圍	主要涵蓋遵循系統代理的程式	可涵蓋更多忽略系統代理的程式
協定範圍	取決於應用程式支援的 HTTP、HTTPS、SOCKS 代理能力	通常可統一處理 TCP，並依核心與設定處理 UDP
DNS 路徑	取決於應用程式、代理協定與 Clash DNS 設定	可搭配 DNS 劫持與增強模式，統一送入核心
系統權限	通常只需修改系統代理設定	通常需要系統管理員權限、系統服務或網路延伸功能
衝突來源	瀏覽器擴充功能、手動代理、殘留的代理位址	其他 VPN、虛擬網卡、安全軟體、路由優先順序

應用程式相容性不只是簡單的「瀏覽器與非瀏覽器」

瀏覽器通常會遵循系統代理，但實際行為還會受到安全 DNS、QUIC、瀏覽器擴充功能與企業原則影響。部分基於 Chromium 的應用程式會沿用系統網路設定，另一些則內建獨立的代理選項。遊戲平台可能由啟動器、更新程式、登入元件與遊戲程序共同組成，其中只有部分元件會讀取系統代理。此時網頁可以開啟，並不能證明下載、登入與即時通訊都經過同一條連線路徑。

TUN 模式能從更低層接收這些連線，涵蓋範圍通常更完整。對於 UDP 流量，能否正常轉送仍取決於節點協定、代理服務端、策略規則與核心設定。啟用 TUN 只提供流量入口，不會自動補足上游節點不支援的能力。

DNS 處理決定網域規則能否穩定匹配

在系統代理情境下，DNS 可能由應用程式本機查詢，也可能透過代理協定交由核心處理。不同程式的行為並不一致。如果網域在進入 Clash 前已解析成 IP，核心取得的資訊可能與直接接收網域請求時不同，規則匹配結果也可能隨之改變。瀏覽器自有的加密 DNS 設定還可能繞過作業系統的 DNS 路徑。

TUN 常與 mihomo 的 DNS 模組、dns-hijack、Fake-IP 或 Redir-Host 模式搭配使用。DNS 請求先進入核心後，核心便能將網域映射關係與後續連線關聯，再執行網域規則。Fake-IP 回傳的是供本機映射使用的虛擬位址，實際目標解析與代理選擇則由核心繼續完成。區域網路裝置探索、遊戲平台，以及依賴特殊 DNS 結果的應用程式，可能需要加入 Fake-IP 排除清單，或改用更適合目前環境的 DNS 增強模式。

權限與系統變更範圍不同

系統代理主要修改作業系統儲存的代理位址，所需權限相對較少。TUN 需要建立虛擬介面並調整路由，因此 Windows 用戶端常透過系統管理員權限或背景服務運作，macOS 可能要求核准網路延伸功能，Android 與 iOS 則通常藉由系統 VPN 介面完成接管。首次啟用時出現權限確認，是建立網路入口的正常步驟。

完成權限申請後，仍須確認服務是否實際啟動。用戶端介面顯示 TUN 已開啟，不一定代表路由寫入、DNS 劫持與預設介面辨識都成功。mihomo 日誌中的介面建立、路由設定與監聽錯誤，比單獨觀察開關更具判斷價值。

選擇方式：依裝置與應用程式範圍判斷

日常瀏覽與辦公：先使用系統代理

如果主要需求是瀏覽器存取、文件同步與遵循系統代理的桌面應用程式，系統代理通常更直接。它對路由表的影響較小，開啟與關閉路徑清楚，也方便判斷某個應用程式是否主動使用代理。發生問題時，可以先檢查本機連接埠、作業系統代理位址與策略組，不必同時處理虛擬網卡與路由衝突。

遊戲、命令列與獨立網路堆疊：優先檢查 TUN

若應用程式明確忽略系統代理，或包含 UDP、更新程式、子程序與獨立登入元件，可以使用 TUN 作為主要接管入口。常見情境包括終端機套件管理器未讀取代理變數、遊戲平台下載正常但遊戲連線直連、商店應用程式無法使用系統代理，以及同一程式的不同元件採用不一致的連線路徑。

行動裝置：系統 VPN 介面通常扮演 TUN 角色

行動系統中的 Wi-Fi 手動代理通常只對目前的無線網路生效，而且應用程式是否遵循該設定仍取決於應用程式本身。行動網路也不會使用這項 Wi-Fi 代理設定。需要裝置層級接管時，支援 Clash 或 mihomo 的用戶端一般會透過系統 VPN 介面建立通道。系統狀態列顯示 VPN 後，仍應在用戶端日誌中確認連線確實由規則處理。

開發環境、虛擬機與容器：先確認路由邊界

虛擬機與容器通常擁有獨立網卡、閘道或網路命名空間。主機啟用 TUN 後，來賓系統的流量是否進入該介面，取決於橋接、NAT 與預設路由關係。容器存取主機回環位址時，127.0.0.1 指向容器本身，並不等於主機上的 Clash 連接埠。這類環境應先繪製主機、虛擬網卡、容器網橋與出口網卡之間的路徑，再決定使用 TUN、區域網路監聽或應用程式層級代理。

系統代理和 TUN 是否需要同時開啟

多數情況下，選擇一個主要入口會更容易排查。TUN 已穩定接管目標應用程式時，系統代理並非必要；只使用瀏覽器與一般桌面應用程式時，也不必為了擴大涵蓋範圍而固定開啟 TUN。部分用戶端允許兩者同時運作，核心通常會處理本機連線與路由排除，但複雜環境可能出現流量繞行、回環或難以判斷實際入口的問題。

需要同時開啟時，應確認系統代理指向目前核心的連接埠，TUN 已排除必要的本機位址，並檢查日誌中同一連線是否只被接收一次。切換接管方式進行測試時，建議先關閉舊入口，再啟動新入口，避免殘留的系統代理或舊路由干擾結果。

設定順序：先驗證設定，再擴大接管範圍

更新訂閱。確認設定能夠成功載入，代理節點與策略組均已顯示，避免將訂閱錯誤誤判為接管失敗。
選擇規則模式。日常使用通常先設定為 Rule，並確認預設策略組已有可用節點。Global 與 Direct 可用於短時間定位問題，不適合當作判斷 TUN 是否生效的唯一依據。
先測試系統代理。開啟系統代理後，使用明確遵循系統設定的瀏覽器存取目標網站，並觀察 Clash 連線記錄是否出現網域、規則與策略組。
辨識未接管的應用程式。如果特定程式完全沒有連線記錄，請確認它是否提供獨立代理設定、是否需要環境變數，或是否使用 UDP 與獨立網路堆疊。
再啟用 TUN。完成系統權限確認，檢查虛擬介面、自動路由、預設網卡辨識與 DNS 設定。
逐項恢復其他網路工具。先在單一網路環境下驗證，再啟動其他 VPN、虛擬機或安全軟體，以便找出路由衝突來源。

mihomo 設定中常見的 TUN 基本結構如下。不同用戶端可能透過圖形介面產生這些欄位，實際支援項目以用戶端整合的核心版本為準。

mixed-port: 7890
mode: rule

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

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

auto-route 用於自動寫入必要路由，auto-detect-interface 用於辨識目前的預設出口，dns-hijack 用於將符合條件的 DNS 請求送入核心。stack 的可用值與實作方式會隨核心版本、作業系統及用戶端封裝方式而變化，不應在不了解目前版本的情況下，直接複製整段設定來覆寫用戶端產生的項目。

系統代理側主要需要核對監聽連接埠。設定使用 mixed-port 時，同一連接埠可以接收常見的 HTTP 與 SOCKS 代理連線。用戶端寫入系統設定的連接埠必須與核心實際監聽的值一致。如果修改了設定中的連接埠，但作業系統仍保留舊連接埠，通常會表現為所有遵循系統代理的應用程式突然無法連線，而由 TUN 接管的程式可能仍可正常使用。

故障檢查：依入口、DNS、規則與出口四層定位

第一層：流量是否進入核心

開啟用戶端連線清單或即時日誌，再啟動目標應用程式。如果完全沒有新連線，優先檢查系統代理位址、TUN 服務狀態、應用程式獨立代理、路由表與防火牆。此時不要先更換節點，因為節點只會影響已進入核心且被分配至代理策略的連線。

第二層：網域是否正確解析

連線記錄只有 IP、網域規則未命中，或應用程式在網域解析階段逾時時，應檢查 DNS 模組是否啟用、TUN 的 DNS 劫持是否生效、瀏覽器是否使用獨立安全 DNS，以及 Fake-IP 排除規則是否過於寬鬆。區域網路網域與裝置探索協定仍需保留本機解析路徑。

第三層：規則與策略組是否選擇正確

流量已出現但走向不符合預期時，請查看最終命中的規則、策略組與節點。規則通常會依設定中的順序匹配，較寬泛的規則放在前面，可能覆蓋後續的精確規則。更新訂閱也可能重建策略組選擇，因此需要重新確認目前群組中選取的節點。

第四層：節點與實體網路是否可達

規則命中代理但連線逾時時，才進行出口檢查。依序確認節點狀態、節點協定對 TCP 或 UDP 的支援、目前網路對目標連接埠的限制，以及預設出口網卡是否正確。裝置從有線網路切換至 Wi-Fi，或從 Wi-Fi 切換至行動熱點後，TUN 可能需要重新辨識預設介面。

結論：以最小涵蓋範圍滿足目前裝置需求

系統代理依靠應用程式主動讀取作業系統設定，結構簡單，適合瀏覽器與一般桌面軟體。TUN 透過虛擬介面接收網路封包，涵蓋範圍更廣，適合忽略系統代理、使用 UDP 或包含多個網路元件的應用程式，但也增加了權限、路由、DNS 與虛擬網卡衝突等檢查項目。

選擇時不必固定追求某一種模式。先用系統代理驗證訂閱、節點與規則鏈路；確認目標應用程式未進入核心後，再啟用 TUN 擴大接管範圍。無論使用哪種入口，都應透過連線日誌確認流量已進入核心，並繼續核對 DNS、規則、策略組與實際出口。依這四層逐步檢查，比只切換開關更容易找出具體故障點。