先選擇接管方式，再檢查分流規則

瀏覽器能開啟網頁，終端機卻連線逾時；開啟系統代理後，遊戲仍使用原本的網路出口。這些情況不一定代表節點失效，常見原因是應用程式沒有讀取系統代理設定。系統代理和 TUN 的主要差異，在於流量如何進入 Clash 核心，而不是節點速度或訂閱品質。

  • 主要使用瀏覽器：先開啟系統代理。設定簡單，遇到問題也容易還原。
  • 只想代理單一命令列工作：先為命令明確指定 HTTP 或 SOCKS 代理，不必急著啟用 TUN。
  • 應用程式不支援代理設定，或需要處理部分 UDP 流量：再考慮使用 TUN，並檢查路由、DNS 和節點協定。
  • 正在連線公司 VPN：先確認公司網路規範，避免兩套工具同時修改預設路由。

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

系統代理會將本機代理位址寫入作業系統的代理設定。支援這項設定的應用程式讀取位址後，便會將請求交給用戶端處理。例如，用戶端監聽 127.0.0.1:7890 時，瀏覽器就能透過這個本機連接埠建立代理連線。實際連接埠請以用戶端顯示為準，7890 僅為本文範例。

系統代理能接管哪些連線？

Edge、Chrome 等瀏覽器通常會遵循系統代理設定，但實際行為也會受到組織政策、擴充功能和啟動參數影響。Firefox 可選擇使用系統代理，也能另外設定連線方式。下載工具、開發工具和遊戲各有不同的實作方式，不能只看工作列顯示「系統代理已開啟」，就認定所有應用程式都已接管。

  • HTTP 代理常用於網頁請求；HTTPS 通常透過 HTTP CONNECT 建立通道。這不代表用戶端會解密 HTTPS 內容。
  • SOCKS5 可處理 TCP；若要使用 UDP，還需要應用程式、用戶端和節點連線都支援。
  • mixed-port 可在同一個連接埠接收 HTTP 和 SOCKS 代理請求，但不會讓未讀取代理設定的應用程式自動改走代理。

從系統設定確認代理位址

Windows 11 可前往「設定」→「網路和網際網路」→「Proxy」，檢查手動代理或設定指令碼的狀態。macOS 可前往「系統設定」→「網路」→目前使用的網路服務→「詳細資訊」→「代理伺服器」。這些位置適合用來確認系統設定；日常切換建議優先使用用戶端，避免兩邊反覆覆寫設定。

不要將 0.0.0.0 設為應用程式的代理伺服器位址。它通常表示監聽所有 IPv4 介面；同一台電腦上的應用程式一般應連線至 127.0.0.1。只有需要與區域網路共用代理時，才另外考慮監聽位址、防火牆和存取限制。

TUN 模式：透過虛擬網路介面接收 IP 流量

TUN 會建立或使用虛擬網路介面，再透過路由等機制將符合條件的 IP 封包交給核心處理。應用程式不必提供 HTTP 代理選項，因此適合無法手動設定代理的程式。Clash Meta 後續發展的 mihomo 核心提供相關功能，但不同用戶端使用的核心、服務安裝方式和介面開關並不完全相同。

「啟用 TUN」不代表一定會「攔截所有網路流量」。實際接管範圍取決於 IPv4 和 IPv6 路由、介面排除項目、略過區域網路的設定、其他 VPN 與系統防火牆。虛擬機器、容器和 WSL 也有額外的網路路徑，不能直接視同主機上的應用程式。

比較項目 系統代理 TUN 模式
流量入口 應用程式主動連線至代理監聽連接埠 透過虛擬介面和路由接收 IP 流量
應用程式需求 遵循系統設定或自行設定代理 通常不必支援代理協定
UDP 處理 一般 HTTP 系統代理不處理一般 UDP 流量 可處理已接管的 UDP 流量，仍須節點支援
權限與服務 通常不需要建立虛擬介面 通常需要提升權限或預先安裝特權服務
排查重點 位址、連接埠，以及應用程式是否讀取設定 路由、DNS、服務權限與介面衝突

為什麼 TUN 通常需要管理員權限？

建立介面和修改路由都屬於系統網路操作。Windows 用戶端可能透過服務模式執行；macOS 可能需要授權輔助程式；Linux 通常會用到 /dev/net/tun 及相應的網路管理權限。安裝特權服務後，圖形介面不一定每次都要以管理員身分啟動。

若記錄顯示權限不足，請依照所用用戶端的說明安裝或修復服務，不要反覆切換 TUN。也不要為了排查問題而長期關閉系統防火牆；先確認服務狀態，再檢查遭封鎖的程式和規則。

命令列與遊戲：逐一驗證應用程式，不要憑開關猜測

命令列連不上？先測試明確指定代理

終端機中的工具不一定會讀取作業系統的代理設定。部分工具支援 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，但支援範圍及大小寫處理方式不盡相同。排查時，明確傳入參數通常比修改全域環境變數更容易確認影響範圍。

# Windows PowerShell 使用 curl.exe，避免舊版別名干擾
curl.exe --proxy http://127.0.0.1:7890 --noproxy "" -I https://example.com

# macOS / Linux 使用 curl
curl --proxy http://127.0.0.1:7890 --noproxy "" -I https://example.com

# 使用 SOCKS5，並由代理伺服器解析目標網域
curl --proxy socks5h://127.0.0.1:7890 --noproxy "" -I https://example.com

這些命令假設 7890 是支援對應協定的混合連接埠。收到 HTTP 回應代表這次代理請求已成功建立，但不能只憑狀態碼判斷使用了哪個公開網路出口。若明確指定代理後可以連線，一般命令卻失敗，請先檢查該工具的代理參數或環境變數，不要急著更換訂閱。

遊戲使用 UDP；TUN 也不保證降低延遲

遊戲可能同時使用 TCP 登入、UDP 對戰，以及獨立的語音連線。啟用 TUN 後，只有路由已接管且節點支援的連線才可能經過代理。節點協定、伺服器設定、規則比對結果和地區限制都可能影響連線狀況。

  1. 先在用戶端的連線清單中尋找遊戲程序或目標位址，確認連線是否進入核心。
  2. 檢查命中的規則和代理群組，避免登入連線走代理，對戰連線卻意外套用直連規則。
  3. 確認節點是否支援 UDP 轉發，不要只看網頁測速結果。
  4. 在相同伺服器和時段比較直連與代理的表現，記錄遊戲內延遲、封包遺失和斷線情況。

繞道較遠的節點可能增加延遲。TUN 的作用是擴大可接管的流量範圍，不會自動加速遊戲；也請另外確認遊戲服務條款和反作弊機制的限制。

DNS 處理：區分代理解析與系統解析

系統代理和 TUN 的另一項重要差異，在於網域查詢會經過哪裡。使用 HTTP 代理連線至 HTTPS 網站時，應用程式可以將目標網域交由代理處理；但應用程式自行預先解析的網域、其他背景連線和安全 DNS 功能，仍可能採取不同路徑。因此，「網頁已經走代理」不代表所有 DNS 查詢都使用相同出口。

TUN 可搭配 DNS 接管，將符合條件的 53 連接埠查詢交給核心 DNS 模組處理。mihomo 中常見的 dns-hijack 就是用於這類情境。它不是能解密任意加密 DNS 的工具：應用程式自行發出的 DoH 使用 HTTPS，DoT 通常使用 853 連接埠，不能期待針對 53 連接埠的設定自動辨識並改寫這些流量。

如何閱讀 mihomo 設定片段？

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

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

這是用來說明欄位的局部片段，並非可獨立執行的完整設定。auto-route 用來自動設定相關路由，auto-detect-interface 用來自動偵測出口介面。listen 中的 1053 是本機 DNS 監聽連接埠，不是節點連接埠；DNS 接管和這個監聽連接埠也是不同概念。

Fake-IP 模式會為網域指派對應位址，再利用映射關係處理後續連線。198.18.0.1/16 是此模式使用的位址池，並非實際網站伺服器的位址。既有設定還需要合適的上游 DNS 等項目；不要直接用這段內容覆寫訂閱檔案，也不要在同一層重複加入第二個 dns 或 tun 鍵。

啟用順序：先建立基準，再新增 TUN

同時開啟系統代理和 TUN 不一定會衝突，但也不代表效果會加倍。HTTP 代理連線和虛擬介面接管可能同時存在，用戶端通常需要妥善處理自身流量與路由排除。排查問題時，先只保留一種流量入口，更容易判斷問題發生在哪一層。

  1. 確認節點和設定：匯入訂閱、選定一個節點並使用 Rule 模式，先透過系統代理成功開啟一次網頁。
  2. 記下本機連接埠：在用戶端確認 HTTP、SOCKS 或混合連接埠，不要把控制面板 API 連接埠誤認為代理連接埠。
  3. 準備服務權限：依照用戶端說明安裝服務或完成授權，並關閉其他正在接管網路的代理工具。
  4. 單獨測試 TUN：暫時關閉系統代理、啟用 TUN，重新啟動目標應用程式，並查看連線清單和記錄。
  5. 檢查日常服務：測試網頁、命令列、區域網路裝置及公司內部網站，確認規則沒有誤判原本需要直連的位址。

Android 用戶端通常透過系統 VPN 介面接管流量；同一個使用者下通常只能有一個 VPN 服務處於啟用狀態。這和在電腦上填寫 HTTP 系統代理並非相同操作。iOS 的網路延伸功能也採用獨立機制，不要將桌面版的 YAML 欄位和開關位置直接套用到行動裝置。

啟用 TUN 後無法上網？依照現象逐步縮小範圍

系統代理正常，只有 TUN 無法使用

  • 確認服務是否正在執行，並查看記錄中是否出現建立介面、設定路由或權限錯誤。
  • 檢查其他 VPN、虛擬網卡和安全軟體是否也在修改路由；每次只停用一項，再重新測試。
  • 確認 IPv6 接管設定。IPv4 請求成功，不代表所有連線都走相同路徑。

部分網站正常，部分應用程式顯示網域錯誤

  • 確認 DNS 模組是否啟用、上游 DNS 是否可連線，以及應用程式是否另行設定 DoH。
  • 檢查 Fake-IP 過濾和直連規則，特別留意區域網路網域、企業內部網域，以及需要真實位址的服務。
  • 比對連線記錄，確認問題是解析失敗、規則選錯，還是節點連線失敗；不要把所有逾時都歸因於 DNS。

關閉用戶端後仍然無法上網

先正常關閉 TUN 和系統代理，再結束用戶端。若程式異常結束，請檢查系統代理是否仍指向已停止監聽的 127.0.0.1:7890，以及原有 VPN 或網路服務是否已恢復。重新啟動相關網路服務或系統前，請先儲存工作內容；未記錄原始設定前，不要大量刪除路由。

若仍找不到問題，可繼續參閱無法上網疑難排解和設定檔檢查。提交記錄時，請隱藏訂閱連結、節點密碼和存取權杖，只保留錯誤時間、核心資訊、錯誤訊息和重現步驟。