先依應用程式選擇接管方式

若只需讓瀏覽器及遵循系統代理設定的桌面應用程式連線，先使用系統代理。若要接管不讀取代理設定的程式、部分遊戲或 UDP 流量，再考慮使用 TUN。TUN 通常涵蓋範圍較廣，但能否成功接管仍受路由、權限、DNS 及其他 VPN 影響。

兩者解決的是「流量如何進入核心」，不是「流量最後透過哪個節點傳送」。流量進入 Clash 或 mihomo 後，仍會依規則與策略群組處理。啟用 TUN 不代表啟用全域代理；符合 DIRECT 規則的連線仍會直接連線。

系統代理與 TUN 的接管原理

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

系統代理通常會向作業系統登記代理位址，例如 127.0.0.1:7890。讀取這項設定的應用程式會將請求交給本機監聽連接埠。HTTPS 網站通常透過 HTTP 代理的 CONNECT 方法建立通道，這不代表網站連線降級為 HTTP。

應用程式是否讀取系統設定，取決於所使用的網路程式庫。有些命令列工具只讀取 HTTP_PROXY、HTTPS_PROXY 等環境變數；有些應用程式則使用自有的代理選項。在 Windows 中，常見的使用者代理設定與 WinHTTP 設定也屬於不同機制，服務程序不一定會遵循桌面使用者的代理設定。

TUN：透過路由將 IP 封包送入虛擬網卡

TUN 會建立第三層虛擬網路介面，再透過路由將符合條件的 IP 封包交給核心處理。應用程式不必識別 HTTP 或 SOCKS 代理，因此原本直接建立 TCP、UDP 連線的程式也可能納入分流。

這不代表所有流量都會自動納入接管。現有的更具體路由、其他 VPN 的策略路由、網卡綁定及 IPv6 設定，都可能改變實際路徑。TUN 也不代表所有協定都能透過代理傳送；UDP 仍須由所選的出站節點與伺服器支援，不能因 TCP 可用就推定 UDP 也可用。

比較項目系統代理TUN 模式
接管入口應用程式主動連線至 HTTP 或 SOCKS 監聽連接埠系統路由將封包送入虛擬網卡
應用程式需求必須支援代理設定，或能明確指定代理通常不要求應用程式提供代理選項
UDP 流量一般系統 HTTP 代理設定不會接管一般 UDP 流量可以接管，但仍取決於出站節點與路由支援
執行權限監聽一般本機連接埠通常不需要管理員權限通常需要提升權限、服務模式或網路管理權限
DNS 行為應用程式可能仍使用系統 DNS，也可能交由代理解析可搭配 DNS 劫持與內建解析器統一處理
主要衝突來源連接埠遭占用、應用程式忽略系統設定VPN 路由、虛擬網卡、DNS、防火牆

DNS 是兩種模式的關鍵差異

「網頁能開啟」不代表 DNS 也依預期運作。啟用系統代理後，有些應用程式仍會先向作業系統查詢網域名稱，再連線至代理；另一些應用程式則會直接將網域名稱交給代理。SOCKS 的本機解析與遠端解析也有所不同，測試時必須註明採用的方式。

53 埠劫持與加密 DNS 的適用範圍

mihomo 的 dns-hijack 可將符合條件的傳統 DNS 請求轉交內建 DNS。常見的 any:53 適用於 UDP 53；若也要處理 TCP 53，可另外加入 tcp://any:53。這不代表能自動識別所有網域查詢。

瀏覽器的 DoH 使用 HTTPS，DoT 通常使用 TCP 853，DoQ 通常使用 UDP 853。僅設定 53 埠劫持，不會讓這些查詢改由內建 DNS 解析。連線本身可能會進入 TUN，但加密查詢內容不代表會交由核心 DNS 處理；依網域分流的效果也取決於網域映射與嗅探設定。

fake-ip 回傳位址不代表解析錯誤

啟用 fake-ip 後，內建 DNS 可回傳映射位址，常見範圍為 198.18.0.0/16，接著由核心將後續連線對應至原始網域名稱。看到 198.18.x.x 時，不必立刻更換 DNS。應確認應用程式是否仍由 TUN 接管，以及映射是否有效。

  • 切換 DNS 模式後，請關閉並重新開啟測試用的應用程式，避免沿用舊連線或快取。
  • Windows 可執行 ipconfig /flushdns 清除系統解析快取，但瀏覽器可能另有自己的快取。
  • 區域網路裝置名稱與企業內部網域應使用可連線的內部 DNS；不要將所有查詢一律交給公用解析器。
  • 若 IPv4 測試正常、IPv6 卻失敗，應分別檢查 IPv6 路由與 DNS 回應，不能只檢查 A 記錄。

mihomo 設定與啟用步驟

修改接管方式前，先保留一份可正常使用的設定。以下是欄位合併範例，並非完整訂閱內容；請保留現有的 proxies、proxy-groups 和 rules。若原檔已有 tun 或 dns，應合併至原有映射，不要重複建立同名的頂層欄位。

先確認本機代理入口

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

mixed-port 可讓 HTTP 與 SOCKS 共用連接埠。allow-lan: false 可避免將代理服務開放給其他區域網路裝置；TUN 接管本機流量，不需要啟用區域網路存取。此處的 mode: rule 保留規則分流功能，不能取代節點與規則本身。

接著合併 TUN 與 DNS 欄位

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

範例中的兩個公用 DNS 位址是明確的上游設定範例，不代表適用於所有網路。企業內網、校園網路或採用特定解析策略的環境，應依實際需求設定上游 DNS 與網域解析策略。listen 的 1053 是內建 DNS 的監聽連接埠，不是系統代理連接埠；單靠這個欄位也不會自動將系統 DNS 改為使用此連接埠。

  • stack: mixed 會選用混合式協定堆疊。支援情況以核心為準；遇到相容性問題時，再參照核心文件比較其他堆疊。
  • auto-route: true 會要求自動設定將流量導入 TUN 的路由，但不代表其他 VPN 的路由一定會讓出優先權。
  • auto-detect-interface: true 用於自動偵測出口介面。多張網卡、網路分享熱點與 VPN 同時使用時，應確認實際出口。
  • dns.enable 與 tun.enable 是不同的開關。啟用 TUN 不代表內建 DNS 一定也已啟用。

依序啟動並驗證

  1. 先確認現有節點在系統代理模式下可正常使用，再暫時關閉其他 VPN，並記錄原本的網路設定。
  2. 依用戶端要求安裝服務或授予管理員權限，再啟用 TUN。行動裝置通常須核准系統 VPN 權限。
  3. 重新載入設定，檢查啟動記錄是否出現欄位錯誤、權限不足、建立網卡失敗或連接埠遭占用等訊息。
  4. 暫時關閉系統代理，只保留 TUN，分別測試瀏覽器及原本不遵循代理設定的應用程式。
  5. 查看連線記錄中的目標、符合的規則與最終策略，確認流量不只進入核心，也確實流向正確位置。

透過兩組測試分辨連接埠與路由問題

測試時一次只變更一項條件。以下命令使用同一個 HTTPS 位址，比較明確指定代理與不使用應用層代理的連線路徑。Windows PowerShell 建議使用 curl.exe，避免部分環境中的 curl 別名影響參數。

測試一：只驗證 HTTP 代理入口

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

建議在關閉 TUN 時執行。--noproxy "" 會清除此請求的代理略過清單，並明確使用本機 7890 連接埠。若顯示連線遭拒，請先檢查連接埠是否正在監聽，以及核心是否已啟動；若代理已收到請求，但目標逾時，則再檢查節點、規則與目標網站。

測試二：只驗證 TUN 接管路徑

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

關閉系統代理並啟用 TUN 後執行。--noproxy "*" 會讓 curl 不使用應用層代理，但無法略過作業系統的 TUN 路由。執行後查看核心連線記錄；命令成功本身不代表流量透過代理傳送，目標也可能是直接連線。

這兩個命令只會測試 HTTPS 請求，不會驗證遊戲 UDP、語音通話或 QUIC。測試這些情境時，應使用實際應用程式建立連線，並確認是否出現相應的 UDP 連線、符合哪項規則，以及出站節點是否支援 UDP。

檢查路由與 DNS 狀態

# Windows
route print
ipconfig /all
netsh winhttp show proxy

# Linux
ip rule show
ip route show table all
resolvectl status

# macOS
scutil --proxy
scutil --dns
netstat -rn

這些命令只會讀取狀態，不會修改網路設定。Linux 的 resolvectl 僅適用於提供此工具的系統；若找不到工具，請檢查目前網路管理工具的 DNS 設定。自動路由可能會寫入獨立的路由表，因此只檢查主要路由表並不足夠。

常見故障與相容性處理

系統代理正常，啟用 TUN 後卻無法連線

優先檢查 TUN 權限、網卡建立狀態與出口路由。先關閉 TUN，確認網路是否恢復，再單獨啟用 TUN。若只有連線企業 VPN 時才會失敗，通常應協調路由與內部 DNS，而不是一再更換節點。

不要任意刪除預設路由或停止不明網路服務。在遠端桌面環境中修改 TUN 路由可能中斷控制連線，應先準備本機操作方式或還原方案。

瀏覽器正常，命令列或遊戲卻無法連線

只啟用系統代理時，這通常表示應用程式沒有使用該代理入口。可先在命令列明確指定代理進行驗證；遊戲則應檢查是否使用 UDP，以及節點是否支援相應流量。啟用 TUN 後仍無法連線時，應查看連線記錄，而不是一概認定為「接管失敗」。

無法連線至內網裝置、印表機或公司網域

先分辨是連線路由還是名稱解析問題。若可透過裝置 IP 存取，卻無法使用名稱連線，請優先檢查內部 DNS；若 IP 也無法連線，再檢查區域網路路由與規則。將特定目標設為 DIRECT，只會決定流量進入核心後的出站方式，不一定能解決應用程式的廣播或多播探索問題。

能否同時啟用兩種模式？

部分用戶端支援同時啟用系統代理與 TUN。正常情況下，核心會處理自身的出站連線以避免迴圈，但不應因此認為同時啟用兩者會更穩定。排除問題時，先分別驗證每種方式；長期使用則依實際接管需求保留必要的開關。同時執行其他代理軟體或 VPN，更容易造成入口歸屬不明與路由競爭。

Android 與 iOS 能否直接沿用桌面設定？

不行。行動用戶端通常透過系統 VPN 介面接管流量，授權、排除應用程式及背景執行規則皆由平台與用戶端決定。一般行動裝置通常一次只能保留一個使用者層級的 VPN 連線。本文的 YAML 無法取代行動作業系統授權，也不保證其他用戶端支援相同欄位。

依使用情境保留最精簡設定

  • 瀏覽器與常見桌面應用程式：優先使用系統代理，並確認應用程式確實讀取設定。
  • 開發工具與終端機：先使用工具本身的代理參數；若需統一接管多種工具，再評估 TUN。
  • 遊戲、語音與不支援代理的程式：可使用 TUN，但務必分別驗證 UDP、節點支援與規則。
  • 企業 VPN、多張網卡與複雜內網：先記錄路由與 DNS，再決定哪些連線需要接管，避免一次變更多個網路層。

判斷設定是否穩定，應確認目標應用程式進入預期入口、DNS 解析符合網路環境、規則判斷正確，且關閉接管後網路能恢復。需要查閱欄位時，可前往設定參考；遇到一般連線問題，可參照常見問題逐項排查。