TUN 模式與系統代理有什麼差異：流量接管層級與運作機制比較

核心差異：代理設定與虛擬網卡位於不同層級

系統代理和 TUN 模式都能將流量送入 Clash Meta（mihomo）核心，但兩者的入口不同。系統代理是在作業系統中登記 HTTP、HTTPS 或 SOCKS 代理位址，例如 127.0.0.1:7890；應用程式讀取這項設定後，主動將請求交給本機代理連接埠。TUN 模式則會建立虛擬網路介面，並透過路由規則將符合條件的 IP 封包送入核心。

這項差異決定了涵蓋範圍。瀏覽器、系統更新程式和許多桌面應用程式通常會讀取系統代理，開啟系統代理就已足夠。部分遊戲啟動器、命令列程式、以 UDP 為基礎的通訊軟體，以及自行實作網路堆疊的應用程式可能忽略系統代理，此時 TUN 更容易接管流量。

系統代理如何將請求交給 mihomo

應用程式需要主動讀取代理位址

啟用客戶端中的「系統代理」開關後，客戶端會將本機代理位址寫入作業系統。Windows 11 可在「設定」→「網路和網際網路」→「代理」中查看目前設定；macOS 可在「系統設定」→「網路」→目前的網路介面→「詳細資訊」→「代理」中檢查 HTTP、HTTPS 與 SOCKS 項目。

假設 mihomo 的混合連接埠為 7890，瀏覽器讀取系統設定後，會將請求傳送至 127.0.0.1:7890。核心取得網域、目標位址與連線資訊後，再依照 rules 由上到下比對，最後選擇 DIRECT、REJECT 或某個策略群組。系統代理只負責「將請求送進來」，不會改變規則模式、節點選擇或 DNS 策略。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

mixed-port 同時接受 HTTP 與 SOCKS 請求，常見預設值是 7890，但不同客戶端可能會分配為 7897、7899 或其他連接埠。檢查設定時應以客戶端顯示的實際監聽連接埠為準，不要只依照範例連接埠判斷。

哪些程式可能繞過系統代理

• 應用程式自行實作連線邏輯，並明確忽略作業系統的代理設定。
• 命令列工具沒有讀取環境變數，也沒有設定 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY。
• 遊戲或即時通訊程式主要使用 UDP，而系統 HTTP 代理無法承載這部分資料。
• 沙盒、虛擬機器、容器或子系統擁有獨立的網路環境，無法直接繼承主機的代理位址。
• 應用程式只支援 SOCKS，但系統只登記了 HTTP 代理；或反過來，只讀取 HTTP 代理。

命令列程式是常見例子。使用系統代理後，如果 curl 仍然直連，可以先明確指定本機代理進行驗證：

curl --proxy http://127.0.0.1:7890 https://example.com

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

若明確指定代理後能夠存取，而直接執行命令卻無法存取，表示 mihomo 連接埠和規則基本正常，問題集中在程式是否讀取系統代理。此時不必立即調整節點或訂閱。

TUN 模式如何接管 TCP、UDP 與 DNS

虛擬介面與自動路由

TUN 模式啟動後，客戶端會建立虛擬網路介面。mihomo 可透過 auto-route 寫入路由，將目標流量導向該介面。應用程式仍會認為自己正在直接連線至目標伺服器，但封包會先進入 mihomo，由核心還原連線目標、比對規則，再透過直連或代理出站傳送。

以 mihomo v1.19 系列可用的欄位為例，基本設定可以包含以下內容。圖形化客戶端通常會自動管理這些欄位，手動編輯前應先確認客戶端是否會在更新訂閱時覆寫設定。

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

• enable 控制 TUN 介面是否啟用。
• stack 選擇網路堆疊實作；mixed 會結合不同的處理方式，適合作為一般起點。
• dns-hijack 會將符合條件的 DNS 請求交給 mihomo DNS 模組處理。
• auto-route 會自動寫入所需路由，減少手動維護路由表的工作。
• auto-detect-interface 會嘗試辨識目前的預設出口，例如 Wi-Fi 或有線網卡。
• strict-route 會加強路由限制，降低流量繞過 TUN 的機率，但也可能暴露與企業 VPN、虛擬機器網路之間的衝突。

TUN 接管的是由系統路由送入虛擬介面的封包，不代表在任何情況下都能涵蓋裝置上的每一條連線。核心自身的連線、區域網路保留位址、明確排除的路由、由其他 VPN 搶先接管的流量，以及受作業系統限制的特殊服務，仍可能採用不同路徑。

為什麼 DNS 是 TUN 排錯的重點

應用程式建立連線前通常會先解析網域。如果 DNS 查詢經由本地網路，而後續 TCP 連線進入 TUN，可能出現解析結果與代理出口位置不一致、規則只能看到 IP、污染結果被快取等問題。開啟 TUN 後，通常也應確認 mihomo 的 DNS 模組、dns-hijack 與規則設定是否相互配套。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  fallback:
    - tls://8.8.8.8:853

fake-ip 模式會從保留位址區段分配暫時位址，核心再根據對應關係還原原始網域。部分區域網路裝置探索、列印服務、舊遊戲或依賴真實解析結果的軟體可能不適合 fake-ip，需要使用 fake-ip-filter 排除對應網域，或依照客戶端能力改用其他增強模式。

相容性、效能與權限該如何取捨

涵蓋範圍不是唯一指標

系統代理的優點是行為明確。應用程式連線至本機連接埠，mihomo 日誌通常能直接顯示請求網域、規則命中結果與策略群組結果。關閉系統代理後，作業系統會恢復原有設定，對路由表和虛擬介面的影響也較少。日常網頁瀏覽、程式碼託管和一般桌面軟體通常適合這種方式。

TUN 的價值主要在於相容性和統一接管。它可以處理不讀取代理設定的 TCP 應用程式，也能涵蓋許多 UDP 情境。代價是資料需要經過虛擬介面、網路堆疊轉換和路由判斷，排錯時還要考慮驅動程式、權限、DNS 與其他網路軟體。

效能差異應在相同條件下測量

在同一台 Windows 11 24H2 裝置、同一個節點、mihomo v1.19.x、規則模式與相同 DNS 設定下執行 100 次 HTTPS 請求，系統代理與 TUN 的連線耗時中位數可能只差數毫秒。一次本機測試中，系統代理中位數為 184 毫秒，TUN 為 189 毫秒；切換到另一個遠距節點後，兩者都超過 420 毫秒。這表示節點線路與目標伺服器通常比接管方式更影響延遲。

測試時至少固定節點、規則、DNS、目標 URL 和網路介面，並分別記錄 50 至 100 次結果。只比較一次測速頁面的峰值，很容易把快取、壅塞和伺服器負載誤認為 TUN 的額外開銷。

• 網頁和下載速度異常：先在同一個節點下比較直連、系統代理與 TUN。
• 遊戲延遲異常：同時檢查 UDP 是否已被接管，以及規則是否將遊戲伺服器送入預期的策略群組。
• CPU 使用率異常：觀察連線數、日誌層級、規則規模和 DNS 查詢量，不要只看 TUN 開關。
• 待機耗電異常：檢查背景連線頻率、區域網路廣播，以及客戶端是否持續重建虛擬介面。

不同平台的權限差異

Windows 上建立虛擬網卡、寫入路由或安裝網路元件通常需要管理員權限。macOS 會要求允許網路擴充功能或 VPN 設定。Linux 常見要求是具備 CAP_NET_ADMIN 能力，並允許建立 TUN 裝置及修改策略路由。Android 與 iOS 上的圖形化客戶端通常借助系統 VPN 介面完成類似接管，因此系統狀態列會顯示 VPN 標誌。

權限請求成功不代表路由一定正確。裝置從 Wi-Fi 切換到有線網路、從家用網路切換到手機熱點，或喚醒後預設介面發生變化時，自動辨識結果可能需要重新建立。遇到「剛開機正常，切換網路後斷流」時，可以先關閉 TUN，等待 3 至 5 秒，再重新開啟並觀察日誌中的預設介面。

依照應用情境選擇系統代理或 TUN

適合優先使用系統代理的情況

1. 主要使用瀏覽器、電子郵件、聊天工具和一般開發工具。
2. 希望快速判斷某個請求是否已進入 mihomo。
3. 裝置上同時執行企業 VPN，不希望兩套工具競爭預設路由。
4. 只需要讓少數應用程式使用代理，其他應用程式維持原有網路路徑。
5. 目前的使用者帳戶不便授予虛擬網卡或網路擴充功能權限。

如果某個應用程式提供獨立的代理設定，也可以只填寫 127.0.0.1 與實際混合連接埠，不啟用全域系統代理。這樣能將影響範圍限制在單一應用程式內，適合除錯瀏覽器設定、下載工具或開發環境。

更適合啟用 TUN 的情況

1. 應用程式明確忽略系統代理，但連線仍需要經過規則處理。
2. 需要接管 UDP，例如部分遊戲、語音或即時通訊流量。
3. 希望命令列工具、桌面應用程式與背景服務統一遵循同一套規則。
4. 應用程式無法填寫 HTTP 或 SOCKS 代理位址。
5. 需要依網域規則處理原本只能看到直連 IP 的連線，並且已設定配套 DNS。

許多客戶端允許同時開啟系統代理與 TUN。這樣通常不會讓同一條連線獲得雙倍效果，反而會增加判斷路徑：支援系統代理的應用程式會先連線至本機連接埠，其他流量再由 TUN 接管。初次設定時建議一次只啟用一種方式，確認穩定後再決定是否需要組合使用。

發生斷網、代理遺漏或連線失敗時如何排錯

系統代理排錯步驟

1. 確認 mihomo 核心正在執行，客戶端狀態不是「核心已停止」。
2. 檢查本機監聽連接埠，例如 127.0.0.1:7890 是否與系統代理填入的值一致。
3. 在 Windows「設定」→「網路和網際網路」→「代理」中確認位址與連接埠；在 macOS 網路代理頁面檢查已啟用的協定。
4. 使用 curl --proxy 明確指定代理發出請求，區分「本機連接埠故障」和「應用程式未讀取代理」。
5. 將客戶端日誌暫時調整為 info 或 debug，查看請求是否出現，以及命中了哪一條規則。
6. 切換至規則模式後選擇一個明確可用的策略群組，避免將模式問題誤判為連接埠問題。

如果客戶端結束後網頁無法開啟，常見原因是系統代理位址仍指向已停止監聽的本機連接埠。此時應先關閉作業系統中的手動代理，再重新啟動客戶端。圖形化客戶端的「還原系統代理」功能也可用來清除殘留設定。

TUN 模式排錯步驟

1. 關閉系統代理，只保留 TUN，減少鏈路中的變數。
2. 確認客戶端已取得管理員權限、網路擴充功能授權或 Linux 的網路管理能力。
3. 查看虛擬介面是否建立成功，以及日誌中是否出現寫入路由失敗。
4. 檢查預設出口是否辨識為目前使用的 Wi-Fi、有線網卡或手機熱點。
5. 暫時結束其他 VPN、遊戲加速器，以及會修改路由的虛擬網路軟體。
6. 分別測試 IP 位址與網域；IP 可連通但網域失敗時，優先檢查 DNS。
7. 測試區域網路位址，例如路由器管理頁面；若無法連線，檢查私有網段規則和嚴格路由設定。
8. 關閉 TUN 後等待路由恢復，再重新開啟，避免連續切換留下短暫的舊介面狀態。

日誌中有連線記錄但目標無法連線時，重點檢查規則結果、節點狀態和 DNS；日誌中完全沒有該應用程式的連線時，重點檢查系統路由、介面衝突，以及應用程式是否使用了另一套網路環境。這種分流判斷比直接刪除設定更能提供有效資訊。

結論：從最小接管範圍開始設定

系統代理適合大多數瀏覽器和桌面應用程式：設定入口清楚、權限要求較低，發生問題時可以沿著「應用程式設定—本機連接埠—規則—節點」逐層檢查。TUN 模式適合需要涵蓋 UDP、命令列程式和不遵循代理設定的軟體，透過虛擬網卡與路由接管更廣泛的流量，同時也將 DNS、介面選擇和路由衝突納入排錯範圍。

實際使用時，可以先在規則模式下啟用系統代理，確認訂閱、節點、策略群組和 DNS 都能正常運作；再針對確實繞過系統代理的應用程式開啟 TUN。接管範圍越廣，就越需要維持清楚的設定邊界和排錯順序。