Clash TUN 模式與系統代理差異：流量接管原理完整解析

先選擇接管方式，再檢查代理規則

瀏覽器、一般網頁請求：先使用系統代理，確認應用程式有讀取作業系統的代理設定。
curl、Git、開發工具：先明確設定代理連接埠；若工具不支援代理或需要統一接管，再考慮使用 TUN。
遊戲、語音、UDP 應用程式：優先評估 TUN，並確認出口協定、節點伺服器及網路路徑皆支援 UDP。
公司 VPN、容器、虛擬機器並用：先檢查路由與 DNS，避免直接疊加多種接管工具。

Clash Meta 目前通常指 mihomo 核心生態系。用戶端介面負責匯入訂閱、管理設定及切換開關；核心則負責接收連線、比對規則並建立出口。系統代理與 TUN 是兩種不同的流量入口，不是兩份訂閱，也不是兩個節點。

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

系統代理開關通常會將本機代理位址寫入作業系統設定，例如 127.0.0.1:7890。會讀取這項設定的應用程式，便會將請求交給該連接埠。連接埠必須與用戶端目前生效的設定一致，不能將範例中的 7890 當成所有用戶端的固定值。

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

這段設定會讓 mihomo 在混合連接埠接收 HTTP 與 SOCKS 代理請求，但本身不會替作業系統啟用系統代理。用戶端的「系統代理」按鈕負責另一部分。系統代理介面通常填寫的是 HTTP 代理連接埠，也不代表系統中的每個程式都會自動使用 SOCKS。

為什麼瀏覽器通常能使用代理

在常見的桌面環境中，Chrome、Edge 通常會讀取系統代理。Firefox 則可能使用獨立的網路設定，可前往「設定」→「一般」→「網路設定」→「設定」，確認是否選取「使用系統代理設定」。瀏覽器擴充功能也可能覆寫代理設定，排查時應檢查擴充功能的代理權限。

為什麼終端機常常仍是直接連線

終端機中的程式各自決定如何存取網路，不能假設它們會讀取桌面代理設定。先用明確指定代理參數的方式測試，就能區分「工具未使用代理」和「節點連線失敗」：

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

若要在目前的 shell 工作階段使用代理，可以設定以下環境變數。這裡的 HTTPS 請求仍會透過 HTTP 代理的 CONNECT 通道傳輸，因此 https_proxy 的值也可以使用 http://。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

# 測試結束後清除目前工作階段設定
unset http_proxy https_proxy

以上指令適用於常見的 POSIX shell，不適用於 PowerShell。並非所有程式都會遵循這些環境變數；部分開發工具需要個別設定。若使用 SOCKS 測試時需要由代理端解析目標網域，可使用 curl --proxy socks5h://127.0.0.1:7890，其中 h 表示由代理端解析目標網域。

TUN：透過虛擬網卡接收 IP 流量

TUN 會在作業系統中建立第三層虛擬網路介面，再搭配路由規則，將符合條件的 IP 流量送入 mihomo。應用程式可以像平常一樣建立 TCP 或 UDP 連線，不必先理解 HTTP 代理協定。核心收到流量後，再依設定決定直接連線、封鎖，或交由代理節點處理。

與系統代理相比，TUN 的接管範圍通常較廣，但並非能在所有網路環境中「接管所有應用程式」。路由排除項目、其他 VPN、網路命名空間、虛擬機器網路及作業系統權限，都可能影響實際接管範圍。

最精簡的檢查片段

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
  nameserver:
    - https://dns.alidns.com/dns-query

enable：要求啟用 TUN；能否建立介面仍取決於權限與執行環境。
stack: mixed：選擇混合協定堆疊，通常由系統堆疊處理 TCP、gVisor 堆疊處理 UDP；這不是代理節點協定。
auto-route：自動設定所需路由；若與其他 VPN 衝突，不應盲目保留預設行為。
auto-detect-interface：協助識別出口介面；若同時使用多張網卡或 VPN，仍須確認實際選用的介面。
dns-hijack：將符合條件的傳統 DNS 請求送入核心 DNS 模組，不會直接解密應用程式內的 DoH 或 DoT。

Windows 通常需要系統管理員權限，或用戶端安裝的服務元件；Linux 通常需要相應的網路管理權限及 TUN 裝置；macOS 則需要用戶端提供的授權機制。各用戶端的選單名稱不盡相同，應先確認「服務模式」或權限提示已完成，再啟用 TUN。不要把「開關已開啟」當成「虛擬介面與路由已建立」的證明。

瀏覽器、命令列與 UDP 接管範圍比較

流量情境	系統代理	TUN 模式
瀏覽器 HTTP / HTTPS	應用程式讀取系統設定時可接管	符合路由條件時可接管
curl、Git 等命令列工具	通常需要參數、環境變數或工具設定	通常不必逐一設定代理連接埠
遊戲、語音 UDP	一般 HTTP 系統代理通常無法接管	可接收流量，但出口連線仍須支援 UDP
區域網路與印表機	取決於代理略過清單	取決於路由排除項目與直連規則
容器與虛擬機器	通常需要在各自的環境中設定	受虛擬網路拓撲與轉送路徑影響

能接管 UDP，不代表節點能轉送 UDP

遊戲與語音常使用 UDP；瀏覽器的 HTTP/3 也採用 QUIC，通常透過 UDP 443 連接埠傳輸。TUN 可以提供流量入口，但節點協定、用戶端節點設定、伺服器支援及電信業者網路都必須符合需求。一般 HTTP 代理通常無法直接轉送這類 UDP 流量；支援 UDP 的 SOCKS 用戶端則是另一種明確指定代理的路徑。

因此，「網頁正常、遊戲失敗」不一定是 TUN 出錯。應先在連線記錄中找出遊戲的目標位址、協定與最終策略，再檢查該節點是否支援 UDP。節點延遲測試通常只代表對特定測試目標的請求結果，不能據此證明遊戲 UDP 連線可用。

DNS、fake-ip 與規則比對的關係

系統代理與 TUN 都需要處理網域名稱，但取得資訊的方式不同。HTTP CONNECT、SOCKS 網域名稱請求可以直接將目標網域提供給代理；TUN 接收的則是 IP 封包。若要穩定套用網域規則，核心需要透過 DNS 對應、流量嗅探等機制關聯網域，而非只根據目標 IP 猜測網站名稱。

在 fake-ip 模式下，核心可以向應用程式回傳 198.18.0.1/16 範圍內的合成位址，並記錄該位址與實際網域的對應關係。連線進入核心後，再依網域比對規則。這個位址範圍不是節點的出口位址，不能只因「DNS 回傳保留位址」就判定解析失敗。

三種常見限制

應用程式內建加密 DNS：瀏覽器透過 HTTPS 查詢 DNS 時，一般的 53 連接埠攔截無法直接讀取查詢內容。排查期間可暫時統一使用系統 DNS，再比較結果。
舊 DNS 快取：切換模式後，應用程式可能仍使用先前快取的實際 IP 或合成位址。應重新啟動測試應用程式，必要時清除系統 DNS 快取，再建立新連線。
區域網路名稱：路由器管理頁面、NAS 與企業內網網域可能需要指定內網 DNS，或依實際網域設定 fake-ip 過濾；只新增直連規則不一定能解決解析問題。

Windows 可使用 ipconfig /flushdns 清除系統 DNS 快取，但這不會自動清除所有應用程式的內部快取。若瀏覽器與命令列的結果不一致，應分別查看兩者的 DNS 設定與連線記錄，不要一次修改 DNS、節點及規則這三項變數。

用四個步驟確認接管是否生效

1. 固定規則與節點

先維持 Rule 模式，並手動選擇一個可用節點。測試期間暫停策略群組的自動切換，避免結果因節點更換而改變。記下用戶端目前生效的連接埠，例如 7890，同時確認訂閱中的策略群組名稱與規則引用一致。

2. 單獨測試系統代理

關閉 TUN，啟用系統代理。開啟新的瀏覽器連線，再執行前述明確指定代理的 curl --proxy 指令。查看連線面板是否出現測試請求、符合哪條規則，以及最後採用哪個策略。若瀏覽器可以連線，但一般 curl 沒有連線記錄，通常表示命令列沒有主動使用代理。

3. 單獨測試 TUN

關閉系統代理，清除測試終端機中設定的代理環境變數，再啟用 TUN。若先前設定過 ALL_PROXY、all_proxy 或工具專用代理，也應一併檢查。接著執行不帶代理參數的指令，避免把明確指定代理後的成功誤認為 TUN 生效：

curl --connect-timeout 10 -I https://example.com

Windows 可使用 route print、Linux 可使用 ip route 與 ip rule，macOS 可使用 netstat -rn 輔助檢查路由。各平台的自動路由實作不同，不必要求都出現同一條預設路由；重點是虛擬介面已建立，且目標流量會依預期進入核心。

4. 確認規則與出口

先在連線記錄中確認請求已進入核心，再查看最終策略。若規則指定代理，可透過可信任的 IP 查詢服務比較出口；若規則指定直連，出口沒有變化就是預期結果。單次開啟網頁、狀態列圖示或節點延遲，都不足以單獨證明整條路徑正常。

模式選擇與故障排除

系統代理和 TUN 可以同時啟用嗎？

可以，但排查時建議只保留一種接管方式。兩者同時啟用時，部分應用程式會先連到本機代理連接埠，其他應用程式則走 TUN，連線入口會變得不易判斷。正常設定下，不代表同一個請求必然經過兩次遠端代理；真正需要留意的是其他 VPN、錯誤的出口路由或 DNS 設定造成的迴圈。

啟用 TUN 後，無法連線至 NAS 或公司 VPN

先關閉 TUN，確認網路恢復正常，再檢查區域網路網段、企業 VPN 路由及內網 DNS。代理規則中的 DIRECT 決定核心如何建立出口，路由排除則決定流量是否進入 TUN，兩者位於不同層級。應依實際網路拓撲選擇處理方式，不能隨意將所有私有位址範圍都指向同一個節點。

關閉用戶端後仍無法連線

檢查系統代理是否仍指向已停止監聽的 127.0.0.1:7890；必要時關閉殘留的手動代理設定。
透過用戶端正常關閉 TUN，確認虛擬介面與自動路由已移除，再結束程式。
檢查 VPN、網路介面與 DNS 設定，還原測試前記錄的狀態；不要直接清除所有系統路由。

進一步設定前，可參閱完整文件中的規則、DNS 與 TUN 說明。保留可還原的原始設定，每次只修改一個設定區段，能更快找出問題所在的層級。