啟用結論：程式不走系統代理時，再使用 TUN

瀏覽器可以連線，但遊戲、命令列或桌面應用程式無法連線時，先確認該程式是否遵循系統代理設定。系統代理主要是提供 HTTP 代理設定，應用程式可以採用，也可以忽略。TUN 則在網路層接收路由至虛擬網卡的 IP 封包，不必為每個程式個別填寫代理位址。

本文設定以 Clash Meta 後續專案 mihomo 的欄位為準。Clash 是常用來稱呼一類核心與用戶端生態系的名稱；介面上出現「TUN」，不代表不同核心、不同系統的實作完全相同。請先在用戶端的「關於」或核心資訊中確認實際使用的核心，再套用對應設定。

  • 只使用瀏覽器：系統代理通常就足夠，排查流程也較簡單。
  • 程式沒有代理設定：較適合使用 TUN，但仍須確認該程式的 TCP、UDP 流量是否確實被接管。
  • 遊戲、語音或 QUIC：除了 TUN，也要確認代理協定及伺服器是否支援 UDP 轉送。
  • 公司 VPN、遠端桌面正在使用中：先儲存工作，記下原本的路由和 DNS 設定；若遠端連線是唯一入口，請勿貿然變更預設路由。

虛擬網卡原理：從 IP 封包到規則分流

接管流程分為四個步驟

  1. 應用程式發起連線。程式準備連線至網域或 IP，系統依據路由表決定透過哪張網卡傳送。
  2. 路由導向 TUN。用戶端建立虛擬網卡並安裝相應路由；符合條件的封包會進入 TUN 裝置。
  3. 核心處理連線。網路堆疊接收 IP 封包，擷取目的位址、連接埠及可取得的網域資訊，再交由規則引擎判斷。
  4. 套用出口策略。直連流量透過實體網路介面傳送；代理流量則經由所選代理連線傳送，回應再沿相應路徑返回應用程式。

這裡所說的「虛擬網卡」不是新增一條實體網路，而是作業系統與使用者空間網路程式交換封包的介面。用戶端還必須避免自己的代理出口再次進入 TUN，否則會形成路由迴圈；這也是出口介面識別與權限設定很重要的原因。

接管範圍受路由與排除項目限制

auto-route: true用於自動設定導向 TUN 的路由，auto-detect-interface: true用於自動識別出口介面。這些設定不保證「所有情況都能接管」。其他 VPN 的路由、綁定特定網卡的程式、用戶端排除項目，以及 IPv6 設定，都可能改變實際流量路徑。

若只接管 IPv4，而應用程式優先使用 IPv6，部分連線可能會透過另一條路徑傳送。別只憑「網頁能開啟」就判斷接管完整；也應查看目標程式的連線記錄、規則命中結果及實際出口策略。TUN 也不會自動代理同一個區域網路中的其他裝置；若要共用閘道，須另外設定轉送與路由。

system 與 gvisor：先選網路堆疊，再測試相容性

stack控制 TUN 封包採用哪種網路堆疊處理，不是節點協定，也不是代理加密方式。效能會受作業系統、核心版本、連線類型及裝置能力影響，不能一概認定某種堆疊「最快」。

網路堆疊 處理方式 選擇建議
system 使用系統網路堆疊處理連線，實際實作依平台而異。 可先採用此設定；遇到特定程式或 UDP 相容性問題時，再切換堆疊進行測試。
gvisor 使用以 gVisor 為基礎的使用者空間網路堆疊處理封包。 適合與 system 進行對照測試；在使用者空間處理可能增加 CPU 負載。
mixed 在 mihomo 中，TCP 使用 system，UDP 使用 gvisor。 可分別處理 TCP 與 UDP；請確認目前使用的核心和用戶端支援此選項。

對照測試時一次只變更一項

  1. 固定代理策略、規則模式與網路環境，先使用 system。
  2. 開啟目標應用程式觀察約 60 秒，記錄能否建立連線、是否中斷，以及 CPU 使用率是否持續偏高。
  3. 只將網路堆疊改為 gvisor，重新啟動核心後再重複相同操作。
  4. 若只有 UDP 應用程式異常，再檢查代理端是否支援 UDP，別把所有問題都歸咎於網路堆疊。

測試記錄可寫成「system：網頁正常、語音無法連線；gvisor：網頁正常、語音可連線」。這只是記錄格式，並非本文的實測結論。延遲測得 40 毫秒，也無法證明遊戲 UDP 已正確轉送。

mihomo 設定：一併檢查 TUN、DNS 與路由

以下是可合併至完整設定檔的基礎片段，不含代理伺服器資訊或策略群組。現有訂閱中的 proxies、proxy-groups 和 rules應予保留。建議優先使用用戶端的覆寫或合併功能；直接修改訂閱產生的檔案，更新時可能會被覆蓋。

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

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

各連接埠的用途

  • 7890：HTTP 與 SOCKS 共用的混合代理監聽連接埠，供系統代理或手動設定代理的應用程式連線；TUN 接管並不是把所有 IP 封包送至此連接埠。
  • 127.0.0.1:1053：本機 DNS 監聽位址，避免直接佔用系統的 53 連接埠；不代表系統 DNS 已自動改用此位址。
  • any:53與 tcp://any:53：比對進入接管路徑的一般 UDP、TCP 53 連接埠 DNS 查詢，並交由內建 DNS 處理。
  • 198.18.0.1/16：fake-ip 使用的位址池，協助核心建立網域與虛擬位址的對應，並非代理伺服器位址。

DNS 劫持的適用範圍

應用程式內建的 DoH、DoT 不會透過一般 53 連接埠查詢，因此無法只靠上述 dns-hijack改寫其 DNS 內容。這些連線仍可能經過 TUN，但內建 DNS 不一定知道最終網域。網域規則能否命中，還取決於 fake-ip 對應、嗅探設定及實際使用的協定。

在 fake-ip 模式下，外部網域解析到類似 198.18.0.23的位址可能是正常現象；這是對應結果，不是目標網站的真實 IP。若區域網路印表機、NAS 或內部網域發生相容性問題，應依實際網域設定過濾或 DNS 分流。不要只為了解決一個內部網域，就把所有網域都排除在 fake-ip 之外。

依平台啟用：先授權，再啟動核心

選單名稱可能隨用戶端版本而異。以下說明常見入口及其操作目的；若找不到同名選單，可搜尋「服務」、「權限」、「TUN」或「虛擬網卡」等功能，不要把其他用戶端的操作路徑當成目前版本的固定設定。用戶端選擇可先參考用戶端比較。

Windows：服務模式與虛擬網卡驅動程式

  1. 匯入設定後，先透過系統代理確認相同代理策略能連線至目標服務。混合連接埠例如設為 7890時，應與應用程式中的設定一致。
  2. 以 Clash Verge Rev 常見介面為例，進入「設定」→「服務模式」，依畫面提示安裝或啟用服務；過程中可能會要求系統管理員授權。
  3. 返回首頁啟用「TUN 模式」，或在相應版本的網路設定中啟用 TUN。若服務無法使用，請先排除服務狀態問題，不要反覆切換開關。
  4. 查看核心記錄，確認虛擬網卡與路由初始化沒有權限或驅動程式錯誤，再測試原先不走代理的程式。

Windows 用戶端通常需要搭配虛擬網卡驅動程式，例如 Wintun；請透過用戶端支援的流程取得並安裝。不要從不明來源複製驅動程式檔案。可在 PowerShell 中查詢目前的網卡與 IPv4 路由：

Get-NetAdapter
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object RouteMetric |
  Format-Table DestinationPrefix, InterfaceAlias, NextHop, RouteMetric

虛擬網卡名稱由用戶端或設定決定，不一定叫做 Clash。看到網卡存在，只能表示裝置建立成功，還要檢查路由與連線記錄。若電腦同時執行其他 VPN，請先關閉其中一個再測試，避免兩套接管機制互相爭用流量。

macOS：輔助服務權限與 utun 介面

  1. 確認用戶端及其核心支援 TUN；只有系統代理功能的用戶端，無法只靠新增 YAML 欄位取得完整的 TUN 能力。
  2. 在用戶端的服務或權限設定中，依提示安裝輔助服務並完成系統管理員授權。
  3. 啟用 TUN，檢查記錄中的裝置、路由與 DNS 初始化資訊。
  4. 使用終端機查詢介面與路由，接著啟動目標程式進行驗證。
ifconfig
netstat -rn -f inet
scutil --dns

macOS 常見的虛擬介面名稱為 utun加上編號，但其他 VPN 或系統服務也可能建立 utun。不能只因為看到 utun3就認定它屬於目前的用戶端。從睡眠喚醒或切換 Wi-Fi 後發生異常，應重新檢查出口介面，而不只是更換代理節點。

Linux：TUN 裝置與網路管理權限

Linux 通常需要可用的 /dev/net/tun，以及建立介面、修改路由所需的網路管理權限。桌面用戶端可能透過服務取得權限；直接執行核心時，請依發行版和服務部署方式設定權限。不要授予不明來源的可執行檔高權限，也不要為了省事而遞迴變更整個用戶端目錄的權限。

ls -l /dev/net/tun
ip link show
ip rule show
ip route show table all

檢查路由時要查看所有路由表，因為自動接管可能使用策略路由；單獨執行 ip route未必能顯示完整規則。容器環境還需要主機提供 TUN 裝置與必要權限；在容器內啟用開關，不代表能接管主機上的應用程式。

Android 與 iOS：使用系統 VPN 授權機制

常見的 Android Clash 用戶端會透過 VpnService接管流量，首次啟用時會出現系統 VPN 連線授權提示，通常不需要 root。請檢查應用程式的 VPN 模式、略過應用程式清單，以及系統的背景執行限制。一般而言，同一使用者下只能有一個一般 VPN 服務處於啟用狀態；啟動另一個 VPN 可能會取代目前的連線。

iOS 用戶端必須自行提供並獲准使用 Network Extension 等系統功能，無法只靠桌面設定中的 TUN 欄位憑空建立這項能力。請依用戶端流程新增 VPN 設定並授權，再確認其支援的設定語法。不要將完整的 mihomo TUN 設定片段直接套用到語法不同的 iOS 用戶端。

驗證流量接管：別只看 TUN 開關

先交叉檢查三個項目

  1. 裝置與路由：虛擬介面已建立、接管路由已安裝，且記錄中沒有持續出現權限錯誤或裝置開啟失敗。
  2. 目標程式連線：開啟原先忽略系統代理的程式，在用戶端的「連線」頁面查看相應的目標位址與連接埠。例如 HTTPS 常見連接埠為 TCP 443，QUIC 常見連接埠為 UDP 443，但不能只憑連接埠判斷應用程式類型。
  3. 規則與出口：確認連線符合預期規則與策略。需要代理的目標若命中 DIRECT，即使 TUN 正常，結果仍不會符合預期。

若要區分兩種流量入口，可暫時關閉系統代理，並清除目標程式自行設定的 HTTP、SOCKS 代理，只保留 TUN 進行測試。瀏覽器仍可連網並不足以證明接管正常，因為直連網路也可能連得上該網站。應交叉核對連線記錄和出口策略；測試後再還原所需設定。

依症狀縮小排查範圍

症狀 優先檢查項目
啟用後所有程式都無法連網 服務權限、出口介面識別、DNS 可連線性，以及其他 VPN 的路由衝突。
網頁正常，但語音或遊戲異常 UDP 接管、代理端的 UDP 支援、應用程式排除清單，再對照測試網路堆疊。
外網正常，但 NAS 或印表機無法使用 區域網路路由、內部 DNS、fake-ip 過濾，以及目前網路實際使用的網段。
切換 Wi-Fi 後失效 檢查出口介面是否更新、舊路由是否殘留；重新啟用 TUN 後再查看記錄。
連線記錄中沒有目標程式 檢查程式是否遭排除、是否使用未接管的 IPv6 或特定介面，以及記錄是否被篩選。

排查時可暫時將記錄層級調整為 debug，記下啟用 TUN 與啟動目標應用程式的準確時間。例如 14:32:10 啟用、14:32:20 啟動程式，就從這 10 秒前後查找裝置、路由、DNS 與連線錯誤。確認問題後恢復為 info；分享記錄前，請遮蔽訂閱網址、權杖及個人網路資訊。

關閉與還原：先恢復網路，再繼續排查

若整台裝置無法連網，請先關閉 TUN，讓用戶端撤銷自動路由，再視需要恢復系統代理。正常結束用戶端，比直接強制終止核心更有助於完成清理。退出後仍有異常，請檢查系統代理是否仍指向已停止監聽的 127.0.0.1:7890，以及 DNS、虛擬介面與路由是否已還原。

  • 不要隨意刪除整張路由表；企業網路、容器與其他 VPN 可能仰賴其中的規則。
  • 不要盲目停用所有虛擬網卡；先透過用戶端記錄和介面變化，確認哪些裝置屬於目前的用戶端。
  • 若 fake-ip 快取仍讓應用程式取得虛擬位址，請關閉並重新開啟該應用程式；必要時依系統方式清除 DNS 快取。
  • 網路恢復後，依照「權限與裝置 → 路由與出口 → DNS → 規則與策略 → 應用程式協定」的順序重新測試，每次只變更一項設定。

最後保留的設定應該能說明、能驗證，也能還原：TUN 負責流量入口，DNS 提供網域資訊，規則決定出口，代理服務承載實際連線。完整欄位說明請參閱進階設定中的 TUN 設定；首次匯入訂閱則可依照快速入門先建立基本連線。