Clash TUN 模式與系統代理差異：流量接管方式、適用情境與取捨

先分清流量入口與代理模式

系統代理和 TUN 解決的是「應用程式流量如何進入 Clash 核心」；規則、全域、直連模式則決定「流量進入核心後如何選擇出口」。這兩組設定位於不同層級。啟用 TUN 後仍可使用規則模式，連線至中國大陸網站時可命中 DIRECT，其他目的地則依策略組處理；啟用全域模式，也不會自動讓未讀取代理設定的遊戲流量進入核心。

本文設定片段適用於 Clash Meta 後續發展的 mihomo 核心。Clash 常用來泛指核心與用戶端生態系，圖形介面提供的功能則取決於實際使用的核心與作業系統。舊版 Clash 設定與新版 mihomo 的 TUN 欄位不一定完全相容，請先在用戶端的核心資訊中確認名稱，再參考相應文件。

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

啟用系統代理後，用戶端通常會將本機代理位址寫入作業系統，例如 127.0.0.1:7890。遵循這項設定的瀏覽器會先連線至該連接埠，再由核心選擇直連或代理出口。HTTPS 通常透過 HTTP CONNECT 建立通道；系統代理本身不會解密 HTTPS 內容，普通代理轉送也不需要安裝憑證。

接管範圍取決於應用程式

• 瀏覽器：許多瀏覽器預設會讀取系統代理設定，但擴充功能、企業政策或瀏覽器的個別設定都可能覆寫它。
• 命令列工具：curl、Git、套件管理器是否採用系統設定，取決於工具與建置方式；明確指定參數或環境變數會比較容易確認。
• 遊戲與語音通訊：不少程式會直接透過通訊端傳輸資料，不會讀取系統 HTTP 代理；只開啟系統代理通常不會改變它們的 UDP 流量路徑。

mixed-port 是同時接受 HTTP 與 SOCKS 代理連線的監聽連接埠。以下設定表示本機應用程式可透過 7890 連接埠存取核心，不代表系統代理已自動設定，也不代表其他裝置能連線至此連接埠。

mixed-port: 7890
allow-lan: false
mode: rule

系統代理的主要優點是影響範圍較小：一般網頁代理不必建立虛擬網卡，關閉後通常只要還原系統代理設定即可。限制也很明確：應用程式若不使用這個入口，核心就看不到相應的連線。

TUN：透過虛擬網卡與路由接管連線

TUN 會建立第三層虛擬網路介面，接收作業系統路由至該介面的 IP 封包。核心處理這些流量後，再依規則建立實際連線。因此，即使應用程式沒有代理選項，流量也可能被接管。TUN 並非讓所有程式都支援 HTTP 代理，而是在較低的網路層改變流量路徑。

在桌面作業系統中，建立虛擬網卡與修改路由通常需要管理員權限、特權服務或相應的系統能力。Android 用戶端通常透過系統 VPN 介面接管流量；同一使用者空間一般無法同時啟用兩個這類 VPN。實際行為仍以平台與用戶端的實作為準。

mihomo TUN 欄位範例

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

• stack: mixed 會選用 mihomo 支援的混合協定堆疊實作；不要只看名稱就認定它一定比其他堆疊快。
• auto-route 用於要求自動設定接管路由；auto-detect-interface 用於自動辨識出口介面，支援情況與實際效果因平台而異。
• dns-hijack 會將符合條件的傳統 DNS 請求交由核心 DNS 處理；需同時啟用並正確設定 DNS 模組。此範例未涵蓋所有加密 DNS 路徑。

系統代理與 TUN 差異比較

兩種方式都不會憑空增加節點頻寬。TUN 還會增加封包處理流程，資源耗用則受協定堆疊、作業系統與連線數量影響。如果瀏覽器原本就已正確使用代理，單純改用 TUN，不應預期下載速度自動加倍或延遲必然降低。

遊戲、終端機與 UWP 的選擇建議

瀏覽網頁與一般下載：先用系統代理

如果需求主要是瀏覽器和可明確設定代理的下載工具，系統代理通常就足夠。先確認瀏覽器的請求有出現在連線面板，再查看命中規則與實際出口。若某個網站無法開啟，應先檢查節點、DNS 與規則，而不是立刻增加 TUN 這個變因。

終端機工具：少數工具優先明確指定代理

在 Windows PowerShell 使用 curl.exe，可避免部分環境中 curl 別名造成的差異。以下兩個指令分別透過 HTTP 代理與 SOCKS5 代理測試；第二個指令會由代理端解析目標網域。連接埠必須與用戶端實際監聽的值一致。

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com
curl.exe --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

如果只有 Git 或套件管理器需要代理，可直接在該工具中設定；如果許多命令列程式、子程序與開發工具都需要統一接管，再考慮 TUN。環境變數只會影響讀取它們的程序，而且可能需要重新啟動終端機才會生效。

遊戲與語音通訊：先確認 UDP 與伺服器區域需求

TUN 適合接管沒有代理選項的遊戲，但「成功接管」和「遊戲連線可用」是兩回事。節點協定、節點設定與伺服器端都必須支援所需的 UDP 轉送。也應確認遊戲實際連線的伺服器區域與命中策略，避免原本可直連的鄰近伺服器被繞送至遠端出口。延遲測試顯示 50 毫秒，不代表遊戲伺服器的往返延遲也會是 50 毫秒；這只是數值意義的示例，並非實測結果。

UWP 應用程式：分清代理設定與迴環限制

Windows 上的部分 UWP／AppContainer 應用程式，會受到存取本機迴環位址的限制。即使系統代理指向 127.0.0.1:7890，應用程式也可能無法正常使用。TUN 可避免依賴應用程式主動連線至本機 HTTP 代理這個入口，但並非所有 UWP 網路問題都是迴環限制造成的。若使用用戶端提供的迴環豁免工具，僅對確實需要且受支援的應用程式操作，請勿將批次豁免當成預設步驟。

啟用 TUN 後的驗證與故障排除

建議先確認系統代理正常運作，再單獨驗證 TUN。兩者同時啟用不一定會造成迴圈，但會讓請求從哪個入口進入難以判斷。尤其是明確設定過代理環境變數的終端機，即使關閉系統代理，仍可能透過本機連接埠連線。

1. 確認原始網路連線。暫時關閉兩種接管方式，檢查本機網路、閘道與直連網站是否正常，排除基本連線故障。
2. 驗證系統代理。開啟系統代理，使用明確指定的 --proxy 發出請求，確認 7890 監聽連接埠、節點與規則是否正常。
3. 單獨測試 TUN。關閉系統代理，清除測試程式的個別代理設定，再啟用 TUN；使用未明確指定代理參數的程式建立新連線。
4. 確認接管證據。在連線面板或記錄中搜尋相應目標，檢查規則、策略組與出口。Windows 可使用 Get-NetAdapter 查看介面，並以 route print 檢視路由；不要只根據系統匣圖示判斷。
5. 檢查 DNS 與 IPv6。若網域名稱連線失敗，但既有連線仍正常，請優先查看解析記錄。若 IPv4 正常但部分應用程式仍繞過代理，應確認 IPv6 路由與設定是否也涵蓋在內。

有連線記錄，但仍無法存取

這表示至少有部分請求已進入核心，接著應檢查是否命中 REJECT、選到無法使用的節點，或遭伺服器端拒絕連線。若 UDP 遊戲失敗但 HTTPS 正常，請優先確認是否支援 UDP；HTTP 測試成功並不能證明所有協定都可用。

完全沒有相應的連線記錄

先確認面板連線至目前正在執行的核心，再檢查 TUN 服務權限、自動路由是否生效、應用程式是否綁定實體網卡，以及是否有其他 VPN 佔用預設路徑。在 Windows 上，可前往「設定」→「網路和網際網路」→「Proxy」檢查是否殘留系統代理設定；此路徑適用於 Windows 11，其他版本的名稱可能不同。

最後怎麼選：依應用程式涵蓋範圍決定

• 只需要瀏覽器連線：先使用系統代理並維持規則模式，確認本機連接埠與目前的策略組。
• 少數終端機工具：優先使用明確指定的代理參數或工具本身的設定，方便個別驗證與還原。
• 遊戲、語音通訊或不支援代理的應用程式：可考慮使用 TUN，並確認 UDP、DNS、IPv6 與路由涵蓋範圍。
• 已有企業 VPN 或複雜的虛擬網路：先評估路由衝突；系統代理的影響範圍通常較容易控制。

選擇依據應是應用程式的連線方式，而不是哪個開關看起來比較「全域」。保留一條已驗證可用的接管路徑，每次只調整一項設定，再從連線記錄與規則命中情況確認結果，通常比同時啟用所有選項更容易找出問題。初次設定可先閱讀入門指南；想了解規則與設定的組織方式，再參閱新手到進階。