Clash TUN 模式與系統代理差異：流量接管機制比較

先釐清層級：代理設定與虛擬網卡

系統代理和 TUN 模式都能將流量送入 Clash，但入口所在的網路層級不同。系統代理是在作業系統中登錄 HTTP、HTTPS 或 SOCKS 代理位址，應用程式讀取該設定後，主動將請求交給 Clash 的監聽連接埠。TUN 模式則建立虛擬網路介面，並配合系統路由將 IP 封包導向 Clash 核心。前者取決於應用程式是否遵循代理設定，後者主要取決於路由是否涵蓋目標流量。

這項差異會決定實際涵蓋範圍。瀏覽器、部分桌面通訊軟體，以及遵循系統網路介面的程式，通常可以直接使用系統代理。命令列工具、遊戲、獨立更新程式、採用自有網路堆疊的軟體，以及只傳送 UDP 的程式，可能會忽略系統代理。TUN 位於更低層，通常能接收這些程式產生的 TCP 或 UDP 流量，再由 mihomo 等核心依規則選擇代理、直連或拒絕。

這兩種模式也不是速度等級。開啟 TUN 不會自動提高節點頻寬，使用系統代理也不代表連線效能較差。速度仍取決於本地網路、節點負載、線路品質、傳輸協定、目標網站與 DNS 結果。模式選擇主要處理「哪些流量進入核心」以及「網域資訊如何與連線對應」這兩個問題。

系統代理：應用程式主動連線至本機連接埠

Clash 圖形化用戶端中的「系統代理」開關，通常會將作業系統的 HTTP 與 HTTPS 代理位址設為本機回送位址和核心監聽連接埠，例如 127.0.0.1:7890。如果用戶端使用 mixed-port，該連接埠可以同時接受 HTTP 和 SOCKS 連線。應用程式取得代理設定後，會先連線至這個本機連接埠，再由 Clash 讀取目標位址並執行規則比對。

以瀏覽器瀏覽 HTTPS 網站為例，瀏覽器通常會向 HTTP 代理傳送 CONNECT 請求，其中包含目標網域與連接埠。Clash 可以使用該網域比對 DOMAIN、DOMAIN-SUFFIX 或規則集。建立通道後，HTTPS 內容仍維持端對端加密；流量接管不等於解密網頁內容。對於一般 HTTP 請求，代理同樣可以從請求目標取得網域資訊。

系統代理的優點是變更範圍明確。只要程式遵循系統設定，就不必改寫系統路由，也不必建立虛擬網卡。首次設定、瀏覽器瀏覽、文件下載和常見桌面應用程式，通常可以先採用這種方式。關閉開關後，用戶端應恢復原本的系統代理狀態，因此也適合用來快速判斷問題出在代理鏈路還是本機直連鏈路。

系統代理常見的涵蓋缺口

• 應用程式忽略系統設定：部分程式內建獨立代理選項，未設定時會直接連線至網路。
• 命令列環境未繼承代理：終端機工具可能只讀取 HTTP_PROXY、HTTPS_PROXY 或自身的設定檔。
• UDP 流量不經過 HTTP 代理：遊戲、語音和部分即時通訊功能可能繼續直連。
• 背景服務執行於不同帳戶：系統服務未必會讀取目前桌面使用者的代理設定。
• 應用程式固定使用自己的 DNS 與連線策略：網域解析和後續連線可能繞過系統代理入口。

因此，遇到「瀏覽器正常，但某個程式無法連線」時，不應立即更換節點。先查看程式是否提供代理選項，再檢查它是否支援 HTTP 或 SOCKS5。如果程式完全不支援代理，或必須同時接管 UDP，才需要考慮 TUN 模式。

TUN 模式：路由將 IP 封包送入核心

TUN 是三層虛擬網路介面。啟用後，用戶端或 mihomo 核心會建立虛擬網卡，並依設定新增路由，讓符合範圍的 IP 封包進入該介面。核心會從封包中讀取來源位址、目標位址和協定類型，再結合 DNS 對應、連線嗅探及規則進行判斷。由代理節點負責轉送時，核心會將原始連線轉換為相應的代理協定連線；規則命中 DIRECT 時，則透過實體網路介面直連目標。

由於涉及虛擬介面、路由表和網路堆疊，TUN 通常需要較高權限。Windows 用戶端可能要求以管理員身分安裝或啟動服務；macOS 可能要求核准網路擴充功能或輸入系統憑證；Linux 通常需要存取 /dev/net/tun、具備設定路由所需的權限，或由系統服務執行這些操作。具體方式取決於用戶端實作，不能只根據介面上是否出現開關，就判斷 TUN 已經生效。

mihomo 設定中的 TUN 區段通常包含堆疊類型、自動路由、介面偵測和 DNS 劫持選項。以下片段用於說明欄位關係，實際使用時仍應以用戶端產生的設定及目前核心文件為準：

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
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

auto-route 用於自動設定接管路由，auto-detect-interface 用於識別實際的出站介面，避免將代理節點本身的連線再次送回 TUN。不同作業系統和核心版本支援的堆疊類型可能不同，常見值包括 system、gvisor 與 mixed。堆疊類型會影響封包在本機的處理路徑，但不能取代節點品質與規則設定。

防止代理迴圈

TUN 接管範圍過大時，必須確保 Clash 連線至代理伺服器的流量能從實體介面送出。如果該連線再次被路由回虛擬網卡，就會形成代理迴圈，表現為啟用 TUN 後所有連線逾時、日誌重複建立相同目標，或系統網路在短時間內完全無法使用。自動路由與介面偵測通常會處理這項問題，但多網卡、VPN、虛擬機器、容器和手動路由環境仍可能需要明確排除。

DNS 處理：網域規則能否準確命中

代理規則經常依網域名稱編寫，但 TUN 接收到的原始封包主要包含目標 IP。為了讓 DOMAIN-SUFFIX 等規則正確運作，核心需要建立「DNS 查詢結果與後續連線」之間的對應關係。DNS 劫持、fake-ip 和連線嗅探都是解決這項問題的手段，但三者的職責並不相同。

在 fake-ip 模式下，Clash DNS 會為網域回傳保留位址範圍內的臨時位址，並儲存網域與該位址的對應關係。應用程式隨後連線至這個臨時位址時，核心可以還原原始網域，再執行網域規則並向遠端建立實際連線。常見的預設網段屬於基準測試用途的保留位址範圍，不是公網伺服器位址。這項機制可以減少「先在本機解析為某個 IP，再依 IP 規則誤判」的情況。

部分區域網路裝置探索、列印服務、遊戲平台或依賴真實 DNS 回應的程式不適合 fake-ip。此時可以使用 fake-ip-filter 排除相應網域，讓它們取得真實解析結果。過濾項目不宜任意擴大；如果排除大量一般網域，網域與連線的關聯會減弱，規則比對可能退回 IP 判斷。

redir-host 模式通常會回傳真實 IP，並由核心記錄解析關係。它與部分應用程式的相容方式更直接，但當一個 IP 對應多個網域、DNS 快取來自其他解析器，或應用程式繞過 Clash DNS 時，網域對應可能不夠穩定。連線嗅探可以從 TLS ClientHello 的 SNI 或 HTTP Host 等資訊補充網域，但無法保證每種協定都能取得網域，也不會解密 HTTPS 內容。

避免 DNS 請求繞過接管

1. 確認 Clash DNS 已啟用，並查看用戶端顯示的監聽位址。
2. 啟用 TUN 時，檢查 DNS 劫持規則是否涵蓋一般 53 連接埠的查詢。
3. 使用加密 DNS 的應用程式可能直接存取指定伺服器，需要依靠路由和網域規則繼續接管其連線。
4. 排查時清除作業系統與瀏覽器的 DNS 快取，避免舊結果影響判斷。
5. 區域網路網域解析異常時，請檢查 nameserver-policy、fallback 與 fake-ip-filter，而不是直接停用所有規則。

在系統代理模式下，瀏覽器透過 CONNECT 提交網域時，Clash 可以直接取得目標名稱，因此通常較不依賴 fake-ip。不過，如果應用程式先自行解析，再只向 SOCKS 代理提交 IP，仍可能遺失網域資訊。SOCKS5 支援提交網域，但是否採用這種方式取決於應用程式。

使用情境：依涵蓋需求選擇入口

日常瀏覽網頁和支援系統代理的桌面軟體，可以優先啟用系統代理。它對網路的變更較少，出現問題時也容易透過關閉開關恢復直連。對於剛完成訂閱匯入的使用者，這種方式方便先驗證節點、策略組和規則是否正常，再決定是否增加 TUN 層。

如果需要接管不支援代理設定的軟體、UDP 應用程式、遊戲平台、背景更新程式或多個命令列程式，TUN 會更合適。它可以減少逐一為應用程式填寫代理位址的工作，並讓不同網路堆疊的連線統一經過規則系統。使用前應確認用戶端搭載支援 TUN 的核心；目前常見實作主要是由 Clash Meta 延續而來的 mihomo，不同用戶端公開的選項名稱與權限管理方式會有所差異。

伺服器和開發環境還需考慮容器、遠端連線與管理鏈路。透過 SSH 遠端修改預設路由時，一旦 TUN 路由設定錯誤，管理連線可能立即中斷。這類環境應先保留獨立終端機、設定自動復原工作，並明確排除管理網段。容器流量是否進入 TUN，取決於主機路由、網路命名空間與轉送規則，不能只看主機瀏覽器是否成功使用代理。

建議的漸進式設定順序

1. 匯入有效訂閱，選擇可連線的節點或策略組。
2. 以規則模式啟用系統代理，驗證瀏覽器與常見應用程式。
3. 查看連線日誌，確認網域規則、直連規則和代理規則符合預期。
4. 確實存在涵蓋缺口時，再啟用 TUN，並授予用戶端所需的系統權限。
5. 分別測試 TCP、UDP、區域網路存取、DNS 解析，以及系統休眠與恢復。
6. 保留可正常運作的原始設定，修改路由或 DNS 選項後逐項重新測試。

一般不需要為了「更徹底」而同時依賴兩套入口。許多桌面用戶端在開啟 TUN 後仍保留系統代理開關，這不一定會造成錯誤，但會讓部分應用程式先走顯式代理，其他應用程式再走 TUN，排障時難以判斷實際入口。如果用戶端文件沒有特殊要求，可以先只啟用一種接管方式，確認穩定後再評估是否需要組合。

故障排查：從入口到出站逐層檢查

切換模式後無法連線時，應依資料路徑檢查，而不是一次修改多個 DNS、節點和規則選項。第一步確認 Clash 核心正在執行，本機 mixed-port 或其他監聽連接埠沒有被佔用。第二步確認目前使用的入口：系統代理位址是否指向正確連接埠，或 TUN 虛擬介面是否已建立。第三步再查看請求是否出現在連線記錄中。

最後再比較節點。如果同一節點在系統代理下可用、在 TUN 下不可用，問題更可能出在虛擬介面、路由、DNS 或權限；如果兩種模式都無法建立代理連線，應檢查訂閱狀態、策略選擇、節點可達性和本地網路。如果只有某個目標異常，則查看它命中的具體規則與策略組，避免將單一網站問題誤判為整個 TUN 功能失效。

結論：涵蓋範圍決定模式，不由名稱決定

系統代理位於應用程式層的入口，設定直接、排障路徑短，適合遵循作業系統代理設定的程式。TUN 位於 IP 路由入口，可以涵蓋更多 TCP、UDP 以及不提供代理選項的應用程式，但需要處理權限、虛擬介面、路由、DNS 對應及代理迴圈。兩者最終都會將連線交給 Clash 或 mihomo 的規則引擎，並不會改變訂閱本身的節點品質。

合理的順序是先使用系統代理驗證基本設定，再依明確的應用程式涵蓋需求啟用 TUN。遇到異常時，依序檢查應用程式入口、DNS、規則、策略組、代理出站和實體網路介面。每次只修改一個選項，通常比頻繁切換節點和網路堆疊更快定位問題。