TUN 模式與系統代理怎麼選：兩種流量接管機制的運作原理比較

先看結論：瀏覽器優先使用系統代理，需要全域接管再啟用 TUN

系統代理與 TUN 模式並不是兩種不同的代理協定，而是將本機連線交給 Clash 或 Mihomo 核心處理的兩種方式。最終是否直連、使用哪個節點，仍由設定中的規則、策略群組與目前運作模式決定。兩者真正的差異，在於流量從哪裡進入核心，以及哪些應用程式會納入處理範圍。

如果主要需求是瀏覽網頁，或使用支援系統代理的桌面應用程式，通常先啟用系統代理會更合適。它啟動快速、權限要求低，關閉後也容易恢復。遇到命令列工具、遊戲啟動器、部分商店客戶端或不讀取系統代理的 UDP 應用程式時，再啟用 TUN 模式擴大接管範圍。

系統代理如何運作：應用程式主動將連線交給本機連接埠

啟用系統代理後，Clash 客戶端會將作業系統的 HTTP、HTTPS 或 SOCKS 代理位址指向本機監聽連接埠。常見設定使用 mixed-port: 7890，同一個連接埠可接收 HTTP 與 SOCKS5 連線；部分舊設定則會分別使用 port: 7890 與 socks-port: 7891。這些連接埠只代表本機應用程式與代理核心之間的入口，並不是遠端節點連接埠。

應用程式必須主動讀取並遵循系統代理設定，連線才會進入 Clash。Chrome、Edge、Safari，以及許多採用系統網路框架的桌面軟體通常都會如此運作。應用程式連線至 127.0.0.1:7890 後，核心會讀取目標網域或目標位址，再依據 DOMAIN-SUFFIX、IP-CIDR、規則集與最終規則選擇 DIRECT、REJECT 或某個代理策略群組。

如何確認系統代理已寫入

• Windows 11 可開啟「設定」→「網路和網際網路」→「代理」，確認手動代理伺服器是否指向 127.0.0.1 與客戶端顯示的連接埠。
• macOS 可開啟「系統設定」→「網路」→目前網路→「詳細資訊」→「代理伺服器」，確認網頁代理與安全網頁代理項目。
• ClashX 可從選單列圖示檢查「設定為系統代理」狀態，同時確認目前設定檔已啟動。
• 使用 Mihomo 圖形客戶端時，也應核對「設定」→「Clash 設定」中的混合連接埠；不同客戶端版本的選單名稱可能略有差異。

為什麼瀏覽器能使用，終端機卻不行

curl、Git、npm、pip 等命令列工具對系統代理的處理方式並不一致。有些版本會讀取環境變數，有些則需要另外設定。臨時測試時，可在目前終端機設定 HTTP_PROXY、HTTPS_PROXY 與 ALL_PROXY，並明確指定本機連接埠：

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5h://127.0.0.1:7890

curl -I https://example.com

socks5h 中的字母 h 表示由 SOCKS 代理端處理網域解析，可減少終端機先在本機解析網域造成的結果差異。Windows PowerShell 可使用 $env:HTTPS_PROXY="http://127.0.0.1:7890"，為目前工作階段設定變數。關閉終端機後，臨時變數不會繼續影響新的工作階段。

TUN 模式如何運作：虛擬網卡接收 IP 流量

TUN 模式會建立虛擬三層網路介面，並透過路由表將符合條件的 IP 封包導向該介面。Mihomo 核心讀取封包中的來源位址、目標位址與傳輸協定，還原連線資訊後再執行代理規則。應用程式看到的仍是一般網路連線，因此不必理解 HTTP 或 SOCKS 代理，也不必主動讀取系統代理設定。

這也是 TUN 能涵蓋更多程式的原因。採用自有網路堆疊的遊戲啟動器、忽略系統代理的命令列程式，以及使用 UDP 的應用程式，都有機會進入 TUN 接管路徑。不過，「啟用 TUN」不等於「所有資料一定經由遠端節點」：區域網路位址、排除路由、DIRECT 規則、程序規則以及客戶端設定，都會改變最終路徑。

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
  listen: 0.0.0.0:1053
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query

auto-route 用於自動新增必要路由，auto-detect-interface 會嘗試識別實際的出站網卡，dns-hijack 則將符合條件的 53 連接埠 DNS 請求交給核心的 DNS 模組。stack: mixed 是 Mihomo 常用的選擇，會結合系統堆疊與使用者態處理能力。不同作業系統、核心版本及客戶端可能支援 system、gvisor 或 mixed，不能直接照搬其他核心中同名的選項。

適用範圍比較：TCP、UDP、區域網路與程序識別

TCP 與 UDP 的差異

系統 HTTP 代理主要面向以 TCP 為基礎的 HTTP 與 HTTPS 連線。SOCKS5 本身可擴充處理 UDP，但前提是應用程式明確支援 SOCKS5 UDP 轉發；作業系統的一般「網頁代理」開關不會自動將所有 UDP 資料交給 SOCKS 連接埠。因此，語音、即時遊戲、QUIC 與部分 DNS 請求可能會繞過系統代理。

TUN 在 IP 層可看到 TCP 與 UDP，更適合需要統一處理這兩種傳輸協定的情境。即使如此，遠端節點協定也必須支援相應的 UDP 轉發，策略群組中的實際節點還要啟用 UDP 能力。若日誌顯示 UDP 連線命中規則後仍然失敗，應繼續檢查節點協定、伺服器設定與網路 MTU，而不是只反覆切換 TUN 開關。

區域網路裝置與私有位址

印表機、NAS、路由器管理介面常使用 192.168.0.0/16、10.0.0.0/8 或 172.16.0.0/12。啟用 TUN 後應保留區域網路直連規則，並確認自動路由沒有將這些網段導向錯誤介面。常見規則可以放在代理規則之前：

rules:
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - MATCH,PROXY

如果企業內網也使用這些私有位址，僅靠網段直連仍不夠，還要確保公司 VPN 介面的路由優先順序正確。出現「公網正常、內網網域無法開啟」時，應先比較啟用 TUN 前後的路由表，而不是直接修改代理節點。

程序規則的可靠性

在 TUN 模式下，核心可在支援的平台上嘗試識別發起連線的程序，並比對 PROCESS-NAME 或 PROCESS-PATH。但程序識別會受到系統權限、應用程式沙盒、子程序模型與核心實作影響。瀏覽器的網路服務可能在獨立程序中執行，容器流量也可能只顯示主機端程序。關鍵分流仍建議以網域、IP 與規則集為主，程序規則作為補充。

DNS 處理比較：網域在哪個階段解析

在系統代理情境中，DNS 行為取決於應用程式與代理類型。瀏覽器可能自行啟用加密 DNS，也可能先交由作業系統解析，再連線至解析出的 IP；SOCKS5 客戶端則可選擇將網域交給代理端。如果網域在進入 Clash 前已經轉換成 IP，核心可能只能依目標 IP 進行比對，網域規則的可見性也會受到嗅探與對映狀態影響。

TUN 通常會搭配 Mihomo DNS 模組、DNS 劫持與 Fake IP 使用。Fake IP 模式會從保留位址範圍回傳暫時位址，例如常見的預設值 198.18.0.0/16，之後再依對映關係還原原始網域。如此一來，即使應用程式只發起 IP 連線，仍能繼續套用網域規則，並減少本機解析路徑與代理路徑不一致的問題。

Fake IP 不等於遠端 DNS

Fake IP 是由本機核心維護網域對映的機制，真正向上游查詢時仍須視 nameserver、proxy-server-nameserver、規則 DNS 與目前代理設定而定。節點伺服器的網域本身也需要可用的解析鏈路，否則會形成「必須先連上節點才能解析節點位址」的循環依賴。

• 網頁出現憑證網域錯誤時，請檢查 DNS 是否遭其他軟體改寫，以及 Fake IP 對映是否仍然有效。
• 區域網路裝置無法透過主機名稱存取時，可將相關網域加入 Fake IP 排除清單，或為區域網路網域設定專用 DNS。
• 應用程式內建 DoH 時，一般 53 連接埠劫持不一定能接管該查詢；請檢查瀏覽器的安全 DNS 設定與規則命中情況。
• 從休眠狀態恢復後，大量網域暫時無法連線時，可先重新載入設定並清除作業系統 DNS 快取，再判斷是否需要重建 TUN 介面。

如何比較權限、相容性與效能負擔

權限需求

系統代理通常只需修改目前使用者的網路代理設定。TUN 則需要建立虛擬網卡、調整路由表或呼叫系統網路延伸功能，因此 Windows 可能需要系統管理員授權，macOS 可能要求核准網路延伸功能或輔助服務，Linux 通常需要 CAP_NET_ADMIN、root 權限，或由 systemd 授予程序相應能力。

權限只應授予來源與版本已確認的客戶端。若點擊 TUN 開關後立即恢復關閉狀態，請先查看客戶端服務狀態與核心日誌；若提示建立介面失敗，再檢查系統權限。反覆重新安裝設定檔通常無法解決驅動程式、服務或能力授權問題。

與 VPN、虛擬機器及容器共存

企業 VPN 與 TUN 都可能建立虛擬介面並寫入預設路由。後啟動的軟體可能改變路由優先順序，造成連線迴圈、內網中斷或流量從錯誤網卡送出。常見的處理順序是先連線企業 VPN，再啟動 Clash TUN，並透過 auto-detect-interface 或客戶端的介面選項確認實際出口。若公司政策不允許修改路由，改用系統代理會更穩妥。

WSL2、Docker Desktop、Parallels 與 VMware 都會維護自己的虛擬網段。主機上的 TUN 不一定會自動涵蓋虛擬機器內部的所有流量，虛擬機器也可能將主機視為閘道。需要分別檢查主機系統、虛擬網卡與來賓系統的預設路由，不能只根據主機瀏覽器的結果判斷。

效能負擔取決於具體環境

TUN 會增加一次虛擬介面的收發、協定堆疊處理與規則判斷，理論上的路徑比應用程式直接連線至本機代理連接埠更長，但日常網頁使用的差距通常小於遠端節點延遲。以下資料是固定環境下的比較範例，不代表所有裝置：Windows 11 24H2、Mihomo 1.19.8、Ryzen 7 7840U、有線千兆網路，在相同節點與規則下連續測試 10 次。

在此範例中，TUN 的首個封包延遲增加約 0.8 ms，下載吞吐量下降約 4.2%；但遠端節點負載、加密協定、網卡卸載與 MTU 都可能造成更大波動。低功耗裝置更應關注連續傳輸時的 CPU 使用率與溫度，而不是只看單次測速的峰值。

依步驟選擇與排查：不要同時變更多個開關

方案一：先驗證系統代理

1. 啟動客戶端並載入設定，確認本機混合連接埠為 7890，或確認介面顯示的實際值。
2. 選擇規則模式，先將測試網域對應的策略群組固定至一個可用節點。
3. 開啟系統代理，用瀏覽器存取測試頁面，同時觀察連線日誌是否出現網域與策略名稱。
4. 若瀏覽器運作正常，再分別測試終端機、商店客戶端或目標應用程式，記錄哪些程式沒有出現在日誌中。
5. 只有在確實存在涵蓋缺口時，才關閉系統代理測試項目並啟用 TUN，避免兩條路徑同時存在而干擾判斷。

方案二：啟用 TUN 後檢查四個位置

1. 查看日誌中是否成功建立 TUN 介面，以及是否出現權限、路由或裝置佔用錯誤。
2. 檢查預設路由與實際出口介面，確認沒有將代理伺服器連線再次送回 TUN 而形成迴圈。
3. 檢查 DNS 日誌，確認查詢已進入 Mihomo DNS 模組，並能符合預期的網域規則。
4. 分別測試 TCP、UDP、區域網路位址與休眠恢復情境，不能只以單一網頁能否開啟作為完成標準。

常見現象與對應處理方式

最終選擇：依應用程式範圍，而不是「模式強弱」

系統代理更適合明確支援代理設定的瀏覽器與桌面應用程式。它對路由表的影響較小，適合作為日常預設方案，也方便快速判斷節點與規則是否正常。終端機工具若只是偶爾使用，可以另外設定環境變數，不必因此長期啟用 TUN。

TUN 更適合需要涵蓋 UDP、忽略系統代理的程式、複雜 DNS 分流，或希望統一接管多種類型應用程式的情境。它帶來的不是節點速度提升，而是更完整的流量入口；相對地，也需要處理權限、虛擬網卡、DNS 與路由衝突。

實際設定可以採用「系統代理常開，TUN 依需求啟用」的策略。首次部署時，先讓系統代理、節點選擇與規則命中正常運作，再啟用 TUN 擴大範圍。發生問題時，依流量入口、DNS、路由、規則、節點能力的順序逐層檢查，比在全域模式、規則模式與多個開關之間反覆切換更容易找出原因。