Clash TUN 模式與系統代理有什麼差異：接管範圍、DNS 路徑與適用情境

Clash 用戶端裡的「系統代理」和「TUN 模式」不是兩種規則模式，也不會決定連線最終選擇哪個節點。它們處理的是更前端的同一個問題：應用程式產生的流量如何進入 Clash 或 mihomo 核心。流量進入核心後，才會繼續經過網域嗅探、DNS、規則比對、策略群組選擇與出站連線。

系統代理位於應用程式與作業系統提供的代理介面這一側。瀏覽器及支援系統代理的桌面軟體會讀取代理位址，再主動將請求交給 Clash。TUN 模式則建立虛擬網路介面，透過系統路由將 IP 封包送進核心，因此能涵蓋更多未設定代理的軟體。兩者可以使用相同訂閱與相同規則，但接管範圍、DNS 路徑、權限需求及故障表現並不相同。

兩種模式的請求路徑

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

啟用系統代理後，圖形化用戶端通常會將作業系統的 HTTP、HTTPS 或 SOCKS 代理位址指向本機監聽連接埠，例如 127.0.0.1:7890。瀏覽器讀取這項設定後，不再直接連線至目標網站，而是先連線到本機 Clash 連接埠。核心取得目標主機名稱或目標位址後，再依目前規則決定使用 DIRECT、REJECT 或某個代理策略群組。

這條路徑仰賴應用程式配合。大多數主流瀏覽器及讀取系統網路設定的桌面程式都能正常進入代理，但以下流量可能繞過系統代理：

• 軟體自行實作網路堆疊，並明確忽略作業系統的代理設定。
• 遊戲、語音、同步工具等直接使用 UDP，且沒有 SOCKS 或應用程式內建代理支援。
• 終端機程式只讀取 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 等環境變數。
• 虛擬機器、容器或子系統擁有獨立的網路環境，無法將主機的回送位址視為自身的代理位址。
• 應用程式使用硬編碼位址、私有協定或獨立的安全 DNS 通道。

因此，系統代理已啟用不代表所有程序都已被接管。它更像是一份供應用程式讀取的連線指示，而不是強制改道系統所有資料封包。

TUN：系統路由將封包交給虛擬介面

TUN 模式會建立虛擬第三層網路介面。系統依路由表將符合條件的 IPv4 或 IPv6 封包傳送到該介面，mihomo 等核心再透過使用者空間網路堆疊還原連線、執行規則並建立出站連線。應用程式通常仍會認為自己正在直接存取目標位址，不需要另外支援 HTTP 或 SOCKS 代理。

典型路徑可簡化為：應用程式發起連線 → 作業系統選擇路由 → TUN 虛擬介面 → Clash 核心 → 規則與策略群組 → 直連或代理出站。由於入口位於 IP 層，TUN 對 UDP、命令列程式、部分遊戲啟動器及忽略系統代理的軟體涵蓋得更完整。涵蓋更完整不代表所有流量都會自動代理，最終動作仍取決於規則。區域網路、保留位址及特定程序仍可設定為直連。

DNS 路徑為何會影響結果

許多「節點能連線但網站打不開」、「規則沒有依網域命中」、「關閉 Clash 後無法解析」的問題，實際上都出在 DNS 路徑。判斷 DNS 是否經過 Clash，不能只看介面中的 DNS 開關，還要確認應用程式將查詢送往何處、系統使用哪個解析器、53 連接埠是否遭到攔截，以及瀏覽器是否啟用了獨立的加密 DNS。

系統代理下可能存在本機解析

應用程式透過 HTTP CONNECT 或 SOCKS 傳遞網域時，Clash 可以看見目標主機名稱並執行網域規則。但並非所有連線都會保留網域。有些程式先呼叫系統 DNS 取得 IP，再將 IP 位址交給代理；另一些程式則直接使用瀏覽器內建的 DNS over HTTPS。此時，系統解析器、瀏覽器解析器與 Clash DNS 可能同時存在。

如果請求在進入核心前已被解析為 IP，網域規則的命中能力就會受到影響。核心可能透過嗅探恢復部分 HTTP、TLS 或 QUIC 主機資訊，但嗅探並非對所有協定都有效，也不應被視為錯誤 DNS 設定的替代方案。

TUN 下通常搭配 DNS 劫持

TUN 設定通常會將一般 UDP 或 TCP 53 連接埠的查詢送到核心的 DNS 模組。mihomo 的具體欄位會隨版本與用戶端封裝而變動，常見結構如下，實際使用時應以目前用戶端產生的設定為準：

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

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

fake-ip 會向應用程式回傳保留位址範圍內的映射位址，核心據此保留網域與連線之間的對應關係。資料封包進入 TUN 後，核心再使用原始網域比對規則並連線至實際目標。部分區域網路裝置、連線能力檢測、遊戲平台或依賴真實位址回傳值的服務不適合 fake-ip，需要加入過濾清單，或依用戶端能力改用其他增強模式。

DNS 劫持主要針對傳統 53 連接埠查詢。應用程式自行存取 DoH 或 DoT 服務時，這些查詢會表現為一般 HTTPS 或加密連線，不會只因寫入 dns-hijack 就自動轉換成 Clash DNS 請求。可以透過規則控制已知解析服務的出站，也可以關閉應用程式內建的安全 DNS，讓解析路徑統一交由系統與核心處理。

權限、路由與平台差異

系統代理通常只會修改目前使用者的網路代理設定，關閉時恢復原值即可。TUN 需要建立虛擬介面、加入路由、調整 DNS 或呼叫系統服務，因此權限要求較高。不同用戶端可能透過以管理員身分啟動、特權輔助服務或安裝網路延伸功能來完成這些操作。

Windows

Windows 用戶端啟用 TUN 時，通常需要管理員權限，或事先安裝並執行具備相應權限的服務。若介面顯示 TUN 已開啟，但流量仍經由原本的網路傳送，應檢查虛擬網卡是否建立、預設路由是否寫入，以及安全軟體或防火牆是否攔截核心程序。休眠、網路切換及異常結束後，也應確認系統 DNS 與路由是否已恢復。

macOS

macOS 上的實作可能使用系統網路延伸功能、虛擬介面或授權輔助程式。首次啟用時通常會出現系統授權提示。公司裝置的管理政策可能限制網路延伸功能安裝。若只有瀏覽器可用，而終端機或 UDP 應用程式無法使用，應先確認目前實際開啟的是系統代理還是 TUN，不要直接更換節點。

Linux

Linux 建立 TUN 介面與寫入路由需要 root 權限或相應能力，例如授予服務網路管理權限。命令列部署還要處理預設出口辨識、策略路由、systemd 啟動順序及 DNS 管理器之間的關係。NetworkManager、systemd-resolved 與容器網路可能同時修改路由或解析設定，需要明確由哪個元件負責最終狀態。

容器與虛擬機器是常見的邊界。主機啟用 TUN 後，來賓流量是否經過該介面，取決於橋接、NAT、轉送規則與路由設計。不能只憑主機瀏覽器的測試結果，就推斷容器流量也已進入 Clash。

如何選擇適用情境

優先使用系統代理的情況

• 主要處理瀏覽器、程式碼編輯器及支援系統代理的桌面軟體。
• 希望減少網路變更，方便隨時開關及定位故障。
• 目前帳戶沒有安裝虛擬介面或修改路由的權限。
• 區域網路、VPN、虛擬機器或企業網路環境較複雜，需要避免額外的路由衝突。
• 只需讓少數應用程式使用代理，且能在應用程式內明確設定 HTTP 或 SOCKS 位址。

開發工具需要另外確認。Git、套件管理器、Docker 用戶端及終端機下載工具不一定會讀取圖形介面的系統代理。可依工具文件設定代理環境變數，或直接為工具填入本機 SOCKS/HTTP 監聽位址。系統代理模式適合將接管範圍維持在清楚且可控的應用程式層。

優先使用 TUN 的情況

• 應用程式忽略系統代理，或沒有提供代理設定入口。
• 需要處理 UDP、遊戲連線、命令列程式或多種協定混合的流量。
• 希望讓網域解析、規則比對與應用程式連線採用較一致的路徑。
• 需要依程序、目標網段或複雜規則處理全域網路流量，且用戶端核心支援相應能力。
• 可以管理管理員權限、系統服務、路由恢復與區域網路繞過規則。

TUN 更適合「應用程式無法控制，但系統網路可控制」的環境。它不是提升速度的開關。延遲與吞吐量主要仍受節點線路、壅塞、傳輸協定、MTU、DNS 回應及目標服務影響。若啟用 TUN 後速度下降，應檢查是否發生路由迴圈、錯誤的 IPv6 路徑、MTU 不相容或 DNS 回退等待，而不是直接將問題歸因於虛擬網卡本身。

兩者可以同時啟用嗎

不少用戶端允許同時啟用系統代理與 TUN。這樣可以兼顧明確讀取代理設定的應用程式與其他流量，但疑難排解變數也會增加。某些連線可能先進入本機代理連接埠，而該連接埠產生的出站連線又會受到 TUN 路由影響。成熟的實作通常會設定介面排除與程序繞過以避免迴圈，但用戶端服務異常、手動路由或外部 VPN 仍可能破壞這些條件。

日常使用不必為了「涵蓋更多」而固定同時啟用兩者。先依應用程式類型選擇一個入口。系統代理已能滿足需求時，維持單一入口會更容易維護；確實有不讀取代理的應用程式時，再測試 TUN。

依入口、解析、規則、出站分層排查

切換代理模式後發生故障，應依資料路徑逐層確認，而不是不斷更換節點。以下順序可以將問題限制在較小範圍。

1. 確認核心正在執行。查看用戶端狀態、本機監聽連接埠與最新日誌。若核心未啟動，系統代理與 TUN 都不會產生有效轉送。
2. 確認流量已進入核心。造訪測試網站或執行一次明確請求，觀察連線清單是否出現目標。沒有記錄通常表示應用程式未讀取系統代理，或 TUN 路由尚未生效。
3. 確認 DNS 請求路徑。比較系統解析結果、用戶端 DNS 日誌與瀏覽器安全 DNS 設定。不要只根據單一網頁測試下結論。
4. 確認規則命中。查看目標連線符合哪條規則、進入哪個策略群組。規則順序通常由上至下，最先命中的規則會決定動作。
5. 確認策略群組的實際選擇。策略群組名稱顯示為代理，不代表其中的節點可用。請檢查目前選取的節點、延遲測試結果及失敗日誌。
6. 確認出站介面。啟用 TUN 時尤其要檢查核心是否選取正確的實體網卡，避免將代理伺服器連線再次送回 TUN。

在系統代理模式下，可以分別測試「不使用代理」與「明確指定本機代理」的結果。以下連接埠只是常見範例，應替換為用戶端目前顯示的監聽連接埠：

curl https://example.com
curl --proxy http://127.0.0.1:7890 https://example.com
curl --proxy socks5h://127.0.0.1:7890 https://example.com

socks5h 會將主機名稱解析交由 SOCKS 代理端處理，適合與本機解析結果比較。若明確指定代理時可用，而一般請求不可用，問題多半位於系統代理讀取或環境變數。若兩者都已進入核心但規則不同，則應檢查請求攜帶的是網域還是已解析的 IP。

在 TUN 模式下，先查看系統是否存在對應的虛擬介面與路由，再觀察一次請求是否出現在 Clash 連線記錄中。若 TCP 可用但 UDP 不通，應核對核心、節點協定、規則與目標服務是否支援該 UDP 路徑。若區域網路印表機或路由器管理頁面失去連線，應檢查私人網段是否維持直連，以及自動路由是否涵蓋本機網路。

選擇結論：先最小化接管，再補足涵蓋範圍

只處理瀏覽器與一般桌面應用程式時，系統代理通常是更直接的起點。它的權限要求較低，連線入口清楚，也方便判斷應用程式是否已讀取代理設定。遇到命令列程式時，可以補充環境變數或工具本身的代理設定。

當應用程式忽略代理設定、需要 UDP、需要更一致的 DNS 路徑，或希望透過路由接管更多程序時，再啟用 TUN。啟用後應同步檢查管理員權限、虛擬介面、自動路由、實體出口辨識、DNS 劫持、區域網路繞過及 IPv6 行為。

兩種模式最終都會將連線送入同一套 Clash 或 mihomo 規則體系。系統代理解決的是「應用程式是否願意交給核心」，TUN 解決的是「系統是否將資料封包送給核心」。先確認故障位於入口、DNS、規則還是出站，再調整相應設定，就能避免將所有連線問題都歸咎於節點或訂閱。