1. 系統代理與 TUN 接管流量的位置不同

瀏覽器能開啟網站，終端機工具、遊戲或更新程式卻連不上時，首先要確認應用程式是否有使用代理。系統代理只是將代理伺服器位址寫入作業系統設定；應用程式必須主動讀取並遵循這些設定，才會將請求交給 Clash。程式若自行建立 TCP 或 UDP 連線，單純開啟系統代理通常不會改變其連線路徑。

TUN 是第三層虛擬網路介面，處理的是 IP 封包。啟用後，作業系統核心會與用戶端協同建立介面、調整路由，將符合條件的封包送進代理核心。應用程式不必理解 HTTP 代理或 SOCKS 代理，但流量仍須符合路由、權限與核心支援等條件。

方式流量進入位置適合驗證的情境
系統代理應用程式讀取系統代理設定瀏覽器、遵循系統設定的桌面應用程式
明確指定代理應用程式指定本機代理位址curl --proxy、終端機環境變數
TUN 模式虛擬網卡與系統路由不讀取系統代理的程式、受支援的 UDP 流量

本文的 YAML 欄位以 mihomo 為準。舊版 Clash 核心、不同分支及行動版封裝的功能並不完全相同。排查前，請先在用戶端的「關於」或核心資訊頁面確認目前使用的核心名稱，不要只看應用程式名稱是否包含 Clash。

2. 封包、路由與 DNS 如何協同運作

從應用程式到對外連線

  1. 應用程式解析網域名稱，並向目標 IP 發起連線。
  2. 作業系統查詢路由表，符合 TUN 路由條件的封包會進入虛擬介面。
  3. mihomo 讀取封包，依據目標位址、網域對應資訊及規則比對結果選擇策略。
  4. 核心透過實體網卡建立直連或代理連線，再將回應交給應用程式。

實體網卡仍負責連接路由器、無線網路或行動網路。TUN 不會取代實際網路連線，也不會憑空提升節點頻寬。核心本身的對外流量必須避免再次進入 TUN 而形成迴圈；自動判斷出口、介面綁定與路由處理都與此有關。同時執行另一個 VPN 時，兩套程式也可能互相競爭預設路由或策略路由。

為什麼 DNS 往往是能否正常使用的關鍵

規則可能依網域名稱比對，但網路封包本身主要帶有 IP 位址。如果 DNS 請求繞過核心，網域對應資訊可能不完整。啟用核心 DNS，並將一般 DNS 請求導入核心，有助於讓網域規則與連線紀錄相互對應。

fake-ip 模式會回傳合成位址給應用程式，例如從 198.18.0.1/16 範圍配置位址，之後由核心透過對應資訊還原目標網域。這個位址不是目標網站的真實位址，也不應視為節點 IP。部分裝置探索、區域網路服務或高度依賴真實解析結果的應用程式需要設為例外，請依實際網域調整 fake-ip-filter。

  • dns-hijack 接管的是符合條件的 DNS 流量，並非所有加密 DNS。
  • 瀏覽器內建的 DoH 通常使用 HTTPS，無法只靠接管 53 連接埠處理。
  • 應用程式已快取的解析結果不會立刻消失。調整 DNS 後，請重新啟動測試用的應用程式，必要時清除系統 DNS 快取。

3. mihomo 設定與啟動前檢查

先關閉 TUN，使用本機混合連接埠確認訂閱、節點與規則都能正常運作。以下以 127.0.0.1:7890 作為本機代理位址；如果用戶端顯示的是其他連接埠，測試指令也要一併修改。若節點本身無法連線，應先修復節點或訂閱，避免誤以為是虛擬網卡故障。

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

在 Windows PowerShell 中可使用 curl.exe，避免舊版環境將 curl 解讀為其他指令。收到 HTTP 回應，代表這次代理請求已抵達目標服務；但不表示所有網站、UDP 或 TUN 都運作正常。

合併至現有設定的範例

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

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
    - 1.1.1.1
欄位實際用途檢查要點
stack: mixed在 mihomo 中搭配使用系統與使用者空間網路堆疊不是 mixed-port；兩者不是同一個概念
auto-route自動新增指向 TUN 的路由需要系統權限，也可能與現有 VPN 路由衝突
auto-detect-interface自動偵測對外介面多張網卡、虛擬機器及 VPN 環境仍須確認實際出口
dns.listen提供本機 DNS 監聽服務1053 不代表系統會自動改用這個連接埠，仍須設定 DNS 接管或其他轉送方式

圖形介面用戶端通常會產生最終設定。直接修改訂閱快取檔案，可能在更新訂閱後失效；建議優先使用用戶端提供的覆寫、合併設定或 TUN 設定入口。不要重複加入兩個頂層 tun 或 dns 鍵；修改後請檢查實際執行的設定與啟動記錄，而不只是編輯器中的文字。

4. 各平台的啟用步驟與權限

Windows：先設定服務權限，再啟用虛擬網卡

  1. 在使用中的用戶端設定裡，尋找「服務模式」或安裝服務的入口，並依提示授予系統管理員權限。部分用戶端也支援直接以系統管理員身分執行，請以用戶端說明為準。
  2. 確認服務正常執行後，再啟用「TUN 模式」或「虛擬網卡模式」。Clash Verge Rev 的相關選項可在「設定」中尋找「服務模式」及「虛擬網卡模式」；不同版本的分類名稱可能有所不同。
  3. 開啟記錄，檢查是否出現權限不足、建立裝置失敗或新增路由失敗等訊息。介面上的開關亮起只代表已送出操作，不代表核心已成功接管流量。
  4. 使用 Get-NetAdapter 檢查網路介面，並以 route print 比較啟用前後的路由。部分實作採用分段路由或策略處理，不一定會直接取代可見的預設路由。

如果組織管理的裝置禁止安裝虛擬網卡或背景服務，請由裝置管理員調整權限政策。不要為了測試而關閉整個系統防火牆。請先檢查用戶端及核心的允許規則，再透過記錄找出實際失敗的步驟。

macOS：授權輔助服務並確認出口

桌面用戶端通常需要安裝或授權特權輔助服務，才能建立 TUN 介面、調整路由與 DNS。請依應用程式提示完成系統授權，再啟用 TUN。使用 ifconfig 可查看 utun 介面，但 macOS 本身及其他 VPN 也會建立同類介面；介面存在本身不足以證明它是由目前的用戶端建立。

ifconfig
route -n get 1.1.1.1
scutil --dns

請搭配啟動記錄、路由查詢與連線紀錄判斷結果。如果有企業 VPN、其他網路延伸功能或網路過濾工具，先記錄原有狀態，再逐一比較；不要只憑 utun 編號判定衝突來源。

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

桌面圖形介面用戶端可能透過服務取得所需權限；以命令列執行的 mihomo 則必須具備建立介面及設定路由的權限。以 root 身分執行服務是常見做法，也可依部署需求設定能力集，但不能認定只要替執行檔增加一項權限，就適用於所有 DNS 與路由環境。

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

resolvectl 僅適用於使用 systemd-resolved 的系統。容器除了需要程序權限，也必須掛載 TUN 裝置並設定相應的網路能力；只在容器內設定 enable: true 並不足夠。遠端伺服器變更路由前，請保留第二條管理連線或主控台入口，避免新的規則影響 SSH 回程流量。

Android 與 iOS：使用系統 VPN 接入機制

在 Android 上，Clash 類用戶端通常透過系統 VPN 授權接管裝置流量，不必套用桌面版的安裝服務步驟。首次連線時，請確認系統 VPN 授權對話框，並檢查應用程式的分應用代理清單：被排除的應用程式不會因規則設為全域模式就自動進入用戶端。若另一個 VPN 應用程式正在連線，也可能導致目前的連線無法建立。

Android 的「一律開啟 VPN」與「封鎖未使用 VPN 的連線」會改變中斷連線時的行為。啟用封鎖後，用戶端結束可能導致裝置暫時無法上網，請先確認如何恢復連線。iOS 則由支援相關功能的用戶端透過 Network Extension 建立 VPN 設定，並依系統提示授權；桌面版 mihomo 的 TUN 欄位不能直接視為所有 iOS 用戶端通用的設定。

5. 驗證流量是否已接管，而不只看開關

測試 TUN 時，請暫時關閉系統代理，並移除測試終端機的代理環境變數，避免請求其實仍透過明確指定的代理成功。測試完成後請還原原本設定。以下指令會讓這次 curl 請求略過代理設定，但作業系統路由仍可將它送入 TUN。

curl --noproxy "*" --connect-timeout 10 -I https://example.com
  1. 查看連線紀錄：執行指令後，在用戶端的「連線」頁面尋找目標網域或 IP 位址，確認命中的規則與實際對外連線策略。
  2. 檢查路由變化：比較關閉與啟用 TUN 時的路由及策略路由，確認沒有誤將另一張虛擬網卡選為出口。
  3. 測試實際應用程式：啟動原本不支援系統代理的程式，觀察它新建立的連線。已建立的持續連線應先中斷再重新建立。
  4. 單獨測試 UDP：使用確實會產生 UDP 流量的應用程式驗證。HTTP 請求成功，不代表遊戲、語音或 QUIC 一定正常。

如果連線紀錄顯示 DIRECT，表示流量可能已進入核心，只是規則選擇直連，並非接管失敗。反過來說，若瀏覽器能開啟網頁，但連線紀錄中沒有對應請求，請先排除瀏覽器擴充功能、內建代理、快取或其他 VPN 的影響。

6. 常見故障分層排查

現象優先檢查項目下一步處理方式
啟用後完全無法上網權限、出口介面、DNS 與路由迴圈關閉 TUN 恢復網路，再依啟動記錄逐項檢查
網域連不上，部分 IP 位址則正常DNS 監聽、接管設定與上游連線狀況確認核心 DNS 記錄，並檢查瀏覽器的安全 DNS 設定
網頁正常，遊戲或語音無法使用UDP 支援、規則指定的對外策略與伺服器設定確認節點支援 UDP，並查看對應連線是否進入核心
區域網路裝置連線異常私有網路規則、DNS 對應資訊、路由排除設定依實際網段設定直連；需要避開 TUN 接管時，再設定路由排除
只有少數 IPv6 連線異常系統 IPv6 路由與核心設定分別測試 IPv4 與 IPv6，檢查是否繞過接管或出口不支援

直連規則與路由排除是兩回事

例如 IP-CIDR,192.168.0.0/16,DIRECT,no-resolve 表示流量進入核心後，依規則選擇直連；這不是作業系統層級的 TUN 排除。若有印表機探索、廣播或多點傳送需求，也要考慮應用程式的探索機制及用戶端的實際支援，不能只新增一條 TCP 直連規則就認為問題已完全解決。

不要把 MTU 當成第一個調整項目

少數網站載入卡住、大型檔案傳輸中斷，但小型請求正常時，排除 DNS、節點與規則問題後，才值得檢查路徑 MTU。如果目前值是 1500，可以先記錄原值，再暫時改用 1400 比較；這只是用於診斷的測試值，不是所有網路都適用的建議值。若沒有改善，請恢復原值，避免同時修改網路堆疊、DNS 與 MTU，導致無法判斷問題來源。

關閉後的還原順序

  1. 先在用戶端關閉 TUN，等待介面與自動路由清除完成。
  2. 還原原本的系統代理、DNS 及其他 VPN 設定，重新建立測試連線。
  3. 若仍無法連線，請檢查殘留路由與 DNS；優先正常重新啟動用戶端或其服務，不要直接刪除來源不明的系統路由。

穩定的設定應能清楚回答三個問題：哪些流量會進入虛擬網卡、DNS 在哪裡解析，以及每條連線最後採用哪種策略。將這三項與記錄相互核對，比反覆切換全域模式或更換節點更容易找出故障原因。只有在需要接管不遵循系統代理的程式時，才有必要承擔 TUN 所需的權限與路由變更；若瀏覽器與明確指定代理已符合需求，則可繼續使用原有的接入方式。