系統代理與 TUN：流量入口不同，分流規則照常生效

瀏覽器可以連線，終端機或遊戲啟動器卻連不上，常見原因是這些程式沒有使用 Windows 系統代理設定。系統代理會提供一個代理位址，例如 127.0.0.1:7890，由應用程式自行決定是否使用；它不會自動將電腦上的所有網路連線轉交給 Clash。

TUN 則會建立虛擬網路介面，透過路由將符合條件的 IP 流量送進核心。應用程式不必支援 HTTP 或 SOCKS 代理，連線也有機會被接管。本文適用於 Windows 10、Windows 11，以及使用 mihomo 核心的 Clash 用戶端；舊版 Clash 核心的欄位、驅動程式和介面可能不同，設定不一定能直接套用。

比較項目系統代理TUN 虛擬網卡
接管方式應用程式連線至本機 HTTP 或 SOCKS 連接埠系統路由將 IP 流量導向虛擬介面
應用程式配合必須讀取系統設定或手動設定代理通常不必在應用程式內設定代理
UDP 流量一般 HTTP 系統代理無法直接接管可以接管，但仍取決於節點與協定支援
權限需求通常可由目前使用者設定建立介面、修改路由通常需要提升權限
分流方式進入核心後依目前模式與規則處理進入核心後仍依目前模式與規則處理

啟用前準備：訂閱、核心與網路基準

不要在同一次操作中首次匯入訂閱、切換節點、修改 DNS 又啟用 TUN。先確認基本連線正常，遇到異常時才容易判斷問題出在哪一層。

  1. 記下用戶端與核心資訊。前往「設定」→「關於」或用戶端的核心資訊區查看版本。確認執行的是 mihomo，不要只憑用戶端名稱判斷功能。
  2. 確認訂閱可正常使用。更新設定並選擇可連線的節點；暫時啟用系統代理，用瀏覽器開啟一個需要代理的網站，再開啟一個直連網站。
  3. 記下本機連接埠。例如混合連接埠為 7890。這是 HTTP/SOCKS 入口，不是虛擬網卡的連接埠，也不是 DNS 監聽連接埠。
  4. 記下其他網路元件。包括企業 VPN、遊戲加速器、其他代理用戶端，以及 Hyper-V、WSL、Docker 建立的虛擬介面。
  5. 準備復原方式。記住 TUN 開關的位置；若使用遠端桌面，修改路由前應先確保有人能現場操作，或備妥其他管理管道，避免連線中斷後無法復原。

初次測試時，建議先關閉其他代理和加速器，只保留目前需要的網路連線。企業管理的裝置應先確認網路政策；不要為了讓開關變成啟用狀態，就關閉安全軟體、防火牆或組織規定的存取控制。

安裝服務模式，再啟用 TUN 虛擬網卡

第一步：授予核心所需權限

在 Windows 建立 TUN 介面和調整路由需要相應權限。常見做法是安裝用戶端提供的背景服務，由服務執行需要提升權限的操作。服務模式處理的是執行權限與背景管理，不會改善節點品質，也不會自動啟用 TUN。

  1. 開啟用戶端的「設定」，尋找「服務模式」、「Service Mode」或「Clash 服務」。部分用戶端會將選項放在「設定」→「Clash 設定」中；請以目前版本顯示的選單為準。
  2. 點選「安裝」或「安裝服務」，並確認 Windows 使用者帳戶控制提示。安裝期間不要移動用戶端所在資料夾。
  3. 等待介面顯示「已安裝」或「執行中」。若系統提示需要重新啟動核心或用戶端，請先儲存設定，再重新啟動。
  4. 若安裝失敗，先查看安裝記錄與安全軟體的紀錄。暫時以系統管理員身分啟動，可用來判斷是否為權限問題；但不要反覆安裝來源不明的驅動程式套件。

若要協助檢查服務狀態，可在 PowerShell 執行下列唯讀指令。不同用戶端的服務名稱不盡相同，因此篩選結果只能作為線索，最後仍須核對用戶端記錄與服務執行檔路徑。

Get-Service | Where-Object {
  $_.Name -match 'clash|mihomo|verge' -or
  $_.DisplayName -match 'clash|mihomo|verge'
} | Format-Table Status, Name, DisplayName -AutoSize

第二步：啟用 TUN，先維持 Rule 模式

  1. 在用戶端設定或首頁的開關區找到「TUN 模式」；若選項位於子頁面，請進入後啟用虛擬網卡。
  2. 初次使用時，保留用戶端建議的協定堆疊並啟用自動路由；先不要同時調整 MTU、介面名稱和介面綁定。
  3. 維持 Rule 模式，使用剛才確認可用的節點或策略群組。
  4. 查看記錄中是否出現介面建立、路由設定成功等訊息。只有介面上的開關亮起，並不能證明流量已成功接管。

按下 Win + R，輸入 ncpa.cpl，即可開啟「網路連線」查看新增介面。介面名稱由用戶端或設定決定，不一定會叫做「TUN」。不要修改介面的共用設定，也不要手動填入預設閘道。

DNS 劫持與 fake-ip：為什麼也要檢查網域解析

流量進入 TUN，不代表 DNS 一定會依預期處理。應用程式可能仍向路由器送出 DNS 查詢，也可能透過瀏覽器的安全 DNS 使用 HTTPS 解析。若核心無法將目標 IP 與網域名稱連結，部分依賴網域的分流規則就可能無法如預期套用。

mihomo 的 dns-hijack 可以將經過 TUN 的指定 DNS 流量交由內建 DNS 模組處理。常見設定會攔截 UDP 53 和 TCP 53；這並非能攔截所有解析方式的通用作法。DoH 通常使用 HTTPS 的 443 連接埠，DoT 通常使用 853 連接埠，兩者都不同於一般使用 53 連接埠的 DNS。

mihomo 設定欄位範例

以下設定片段用於說明各欄位，並非完整訂閱內容，也不包含節點、策略群組和分流規則。如果現有設定已有 tun: 或 dns:，請合併至原有區塊，不要在同一層重複貼上相同名稱的鍵。

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
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  • auto-route：讓核心設定接管所需的路由。若停用，就必須自行規劃路由，不適合作為初次排查的設定。
  • auto-detect-interface：嘗試識別流量出口。在多網卡或企業 VPN 環境中，可能仍須依實際使用的介面調整，無法保證所有環境都能正確識別。
  • stack: system：使用系統協定堆疊。若目前用戶端建議使用其他堆疊，請先採用預設值；切換堆疊主要用於相容性排查，不代表固定的速度排名。
  • listen: 127.0.0.1:1053：內建 DNS 的本機監聽位址。一般 Windows DNS 位址欄位不能填寫連接埠，因此不能直接將它當成「附有連接埠的系統 DNS 位址」使用。
  • fake-ip：為網域配置映射位址，方便將連線與網域建立關聯。範例中的 198.18.0.0/16 是預期的映射範圍，不是遠端網站的真實位址。

範例中的 DNS 伺服器使用一般 DNS，是否能連線取決於目前網路，且不提供加密解析。實際使用時應沿用已確認可用的 DNS 方案；節點伺服器網域解析、企業內部網域和分流 DNS 可能還需要分別設定，單靠替換這兩行伺服器位址無法解決所有問題。

套用設定後清除快取

優先使用用戶端提供的覆寫、擴充設定或 TUN/DNS 設定入口，避免直接修改每次更新訂閱都會被覆寫的檔案。套用後重新啟動核心，再於命令提示字元清除 Windows DNS 快取：

ipconfig /flushdns

接著完全關閉並重新開啟要測試的應用程式。瀏覽器可能會保留自己的 DNS 快取；若結果仍不一致，可暫時關閉瀏覽器的「安全 DNS」進行對照，記錄結果後再還原所需設定。不要把永久關閉所有加密 DNS 當成啟用 TUN 的必要步驟。

驗證流量接管：同時檢查終端機、遊戲與連線記錄

終端機測試：略過明確代理，但保留 TUN

在 Windows PowerShell 中，建議明確執行 curl.exe，避免某些環境將 curl 解讀為其他指令。先關閉用戶端的系統代理，再執行：

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

--noproxy "*" 會讓這次 curl 要求不使用明確代理，包括常見的代理環境變數；它不會略過系統路由，也不會略過 TUN。因此，這項測試適合用來確認「不支援或不使用系統代理的程式」能否經由 TUN 進入核心。收到 HTTP 回應只代表要求有結果，不能單憑這點判斷最後使用了哪個節點。

  • 開啟用戶端的「連線」頁面，依目標網域、目標 IP 或處理程序資訊篩選這次要求。
  • 檢查套用的規則和策略鏈。若顯示 DIRECT，代表目前策略要求直連，不一定是 TUN 失效。
  • 關閉 TUN 後再次執行相同指令，作為對照。原本就能直連的網站，在兩次測試中都連線成功是正常的。
  • 若要驗證代理鏈，請使用已知必須透過代理且允許存取的目標，同時確認對應規則確實選用了代理策略。

若要查看介面與路由，可執行下列唯讀指令。輸出結果用來觀察變化，不必參照其他電腦的介面編號手動新增路由。

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status -AutoSize
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object InterfaceIndex, DestinationPrefix |
  Format-Table InterfaceIndex, DestinationPrefix, NextHop, RouteMetric -AutoSize

遊戲測試：先區分 TCP 登入與 UDP 對戰

啟動器、登入、下載和實際對戰可能使用不同的網域與協定。登入成功但無法進入遊戲時，應檢查對戰使用的 UDP，不要只看瀏覽器測速。TUN 能將 UDP 連線送進核心，但所選節點、傳輸協定、伺服器和設定也都必須支援相應的 UDP 轉送。

  1. 完全關閉遊戲和啟動器，啟用 TUN 後再重新啟動，讓新連線使用目前的路由。
  2. 在「連線」頁面查看遊戲相關的 TCP、UDP 記錄、目標位址和套用的規則。
  3. 確認遊戲流量是否被區域網路規則、目標 IP 規則或處理程序規則分流至 DIRECT。
  4. 換用一個明確支援 UDP 的節點進行對照；節點延遲測試成功，不代表遊戲的 UDP 連線可用。

TUN 不是專用的遊戲加速線路。跨區路徑、節點壅塞、遊戲伺服器位置和反作弊相容性都會影響結果，不應承諾啟用後就能降低延遲。受管理的遊戲或工作環境，也應遵守相關服務規範。

常見問題：依權限、路由、DNS、策略順序排查

狀況優先檢查下一步
開關自動關閉，或提示建立介面失敗服務狀態、權限、核心啟動記錄重新啟動已安裝的服務，檢查安裝路徑與安全軟體記錄
瀏覽器可以連線，終端機無法連線確認瀏覽器是否仍在使用系統代理關閉系統代理，以 curl.exe 進行對照並檢查連線記錄
啟用後大多數網域都逾時DNS 設定、上游伺服器可連線性、出口路由還原先前可用的 DNS 設定，每次只修改一項
遊戲登入成功，但無法進入對戰UDP 支援、分流規則、其他加速器查看 UDP 連線，換用支援 UDP 的節點重新測試
公司內網或印表機無法連線區域網路路由、內部 DNS、嚴格路由選項恢復內網直連與企業 DNS，必要時停用 TUN
部分 IPv6 網站異常IPv6 位址、路由與 DNS 是否一致比對 A/AAAA 解析與連線狀況，不要只檢查 IPv4

WSL、Docker 和其他 VPN 的網路行為不同於一般桌面應用程式

WSL 2、容器和虛擬機器可能透過獨立的虛擬交換器、NAT 或鏡像網路連線。主機上的應用程式進入 TUN，不代表來賓環境一定使用相同路徑。請分別在各環境測試 DNS、預設路由和連線記錄；不能只因 Windows 瀏覽器連線成功，就判定所有流量都已接管。

如果企業 VPN 啟用後才無法連線，先確認兩者是否同時修改路由或 DNS。不要隨意啟用嚴格路由來「強制覆蓋」另一套網路，這可能影響區域網路和其他介面的連線能力。多網卡環境應先確認要保留的內網路徑，再決定介面綁定和略過規則。

無法連線時的復原順序

  1. 關閉 TUN，等待介面與路由復原，再測試一般直連網路。
  2. 若準備退出用戶端，也要關閉系統代理，避免 Windows 繼續使用已停止監聽的 127.0.0.1:7890。
  3. 還原剛才修改的 DNS 或覆寫設定，再重新啟動用戶端核心。
  4. 若問題仍未解決，先儲存記錄與介面資訊，再重新啟動 Windows。不要一開始就解除安裝所有網卡或重設整個網路堆疊。

啟用後檢查清單

可用的 TUN 設定必須同時符合「介面已建立、應用程式進入核心、規則套用正確、日常網路可用」四項條件，而不是只看開關狀態。完成以下檢查後，再考慮讓用戶端隨 Windows 啟動。

  • 權限：背景服務正常執行，核心記錄中沒有重複出現介面建立失敗或權限錯誤。
  • 流量接管：關閉系統代理後，仍能在用戶端的連線頁面找到測試終端機送出的要求。
  • 策略：需要代理的目標套用預期策略群組，直連目標和區域網路資源則維持預期路徑。
  • DNS：常用網域解析正常，內部網域不會被錯誤送往公共 DNS 解析器。
  • 協定：需要使用 UDP 的應用程式應個別驗證，不要用 TCP 下載速度取代遊戲測試。
  • 復原：關閉 TUN 並退出用戶端後，系統代理與網路連線狀態都符合預期。

之後若只有單一應用程式異常，先檢查該應用程式的連線與規則，不要馬上更換整套設定。基礎連接埠、訂閱和分流設定可參閱Clash 使用教學；需要核對設定欄位時，可查閱協定手冊。