系統代理與 TUN 模式差異：為什麼有些軟體無法走代理？

先釐清：接管流量與選擇出口是兩回事

瀏覽器能開啟網頁，遊戲卻連不上；Clash 已切換到「全域」，終端機下載仍然直連。這類情況通常不是按鈕失靈，而是流量根本沒有進入代理核心。排查時先確認「連線有沒有進來」，再確認「進來後套用哪條規則」。

系統代理、TUN：處理應用程式流量如何進入核心。
規則、全域、直連：決定核心收到連線後要選擇哪個出口。
策略組與節點：決定最後使用哪台代理伺服器，或由本機直連目標。

因此，啟用 TUN 不代表所有連線都會走代理。TUN 接管後，規則中的 DIRECT 仍可讓連線直連。反過來說，只切換到「全域」，也無法強制接管完全忽略系統代理的程式。

系統代理：由應用程式主動將連線交給本機連接埠

HTTP 與 HTTPS 請求如何進入 Clash

啟用用戶端的「系統代理」後，用戶端通常會修改作業系統的代理設定，讓支援此設定的應用程式連線至本機代理連接埠。流程可簡化為：應用程式 → 127.0.0.1:7890 → 核心比對規則 → 直連或代理出口。

HTTP 請求可透過 HTTP 代理轉送；HTTPS 通常會先使用 CONNECT 建立通道，再於通道中進行 TLS 通訊。一般 HTTPS 代理通道不需要安裝解密憑證，Clash 也不會只因啟用系統代理就讀取加密網頁內容。

為什麼有些軟體完全不受影響

系統代理是供應用程式讀取的設定，不是能強制接管所有網路連線的開關。瀏覽器可能會讀取這項設定，也可能使用擴充功能或自己的代理選項；命令列工具通常讀取環境變數或專屬設定；遊戲則經常直接建立 TCP、UDP 連線。

Windows：前往「設定」→「網路和網際網路」→「Proxy」查看使用者代理設定。部分服務使用獨立的 WinHTTP 設定，不能只憑這裡的狀態判斷。
macOS：前往「系統設定」→「網路」→目前的網路服務→「詳細資訊」→「代理伺服器」查看；不同網路服務的設定可能不同。
Linux：桌面環境的代理選項、Shell 環境變數與應用程式自己的設定不一定相通，需分別確認。

系統代理的優點是影響範圍較小，也方便逐一排查應用程式。如果平常只需要讓瀏覽器和支援代理的開發工具連線，通常可先用這種方式，更容易釐清問題。

TUN 模式：透過虛擬網卡接收 IP 封包

TUN 是第三層虛擬網路介面。支援 TUN 的核心會透過作業系統路由，將符合接管條件的 IP 封包導入虛擬網卡，再辨識其中的連線並交由規則引擎處理。應用程式不必主動支援 HTTP 或 SOCKS 代理協定。

但這仍有一項前提：封包必須實際路由至 TUN 介面。自動路由、排除網段、介面繫結，以及其他 VPN 的路由優先順序，都會影響接管範圍。不能把「TUN 已啟用」理解為任何程序、任何介面的流量都一定會被接管。

比較項目	系統代理	TUN 模式
應用程式配合	應用程式需讀取系統代理設定，或手動填入代理資訊	通常不需要應用程式支援代理協定
主要接入位置	本機 HTTP、SOCKS 等監聽連接埠	虛擬網卡與作業系統路由
UDP 流量	一般 HTTP 系統代理通常無法接管；SOCKS5 也需要應用程式支援 UDP 轉送	可接收路由至此的 UDP 封包，出口仍須支援
執行權限	通常只需修改目前使用者的代理設定	通常需要服務模式、管理員或網路管理權限
常見問題	應用程式忽略設定、連接埠填錯、代理設定殘留	路由衝突、DNS 異常、權限不足、出口不支援 UDP

如何理解 mihomo 的設定項目

Clash 是用來泛稱用戶端與核心生態的常見名稱；Clash Meta 後續以 mihomo 之名持續發展。不同核心支援的功能不盡相同。以下是 mihomo 的 TUN 設定片段，用來說明各欄位的關係，需合併至現有設定，不要直接取代整份訂閱設定。

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

enable：啟用 TUN，但仍須具備作業系統要求的權限。
stack：選擇協定堆疊實作方式。mihomo 提供 system、gvisor、mixed 等選項，實際支援情況請以目前使用的核心為準；沒有任何一種設定適用於所有裝置並且速度最快。
auto-route：自動新增接管流量所需的路由，但不代表會忽略所有路由例外。
auto-detect-interface：自動偵測出口介面；同時使用公司 VPN 時，仍須確認實際出口。
dns-hijack：此處的 any:53 用於接管符合條件的 UDP 53 DNS 請求，前提是請求已進入相應的接管路徑。

桌面用戶端可能會透過介面設定產生這些欄位，更新訂閱時也可能覆蓋手動修改。請優先使用用戶端提供的 TUN 設定、設定覆寫或合併功能，並確認最後生效的設定。

DNS 差異：網頁走代理，不代表 DNS 查詢也走同一路徑

使用系統代理時，網域名稱可能在哪裡解析

DNS 的處理方式取決於應用程式與代理協定。HTTPS 的 CONNECT 可以傳送目標網域名稱，由代理端繼續處理；但應用程式也可能事先呼叫系統 DNS。SOCKS5 同樣可以傳送網域名稱或已解析的 IP，關鍵在於應用程式選擇哪種方式。

這就是為什麼使用同一個 SOCKS5 連接埠時，命令列測試的 socks5:// 和 socks5h:// 可能得到不同結果：在 curl 中，後者會明確要求代理端解析目標網域。不能只憑公網出口 IP 改變，就認定所有 DNS 請求都已進入 Clash。

TUN 的 DNS 劫持與 Fake-IP 是不同的功能

DNS 劫持會將符合條件的 DNS 請求交由核心 DNS 模組處理；Fake-IP 則是一種回應方式：先回傳對應位址給應用程式，再由核心將後續連線對應回原始網域。mihomo 常見的 Fake-IP 位址池為 198.18.0.1/16，實際設定請以目前設定檔為準；它不是代理伺服器的公網位址。

使用前述 DNS 接管設定片段時，也要確認現有的 dns.enable、上游解析器與相關路由，避免 DNS 模組未啟用。
any:53 不會自動解密瀏覽器的 DoH，也不會將 TLS 加密的 DoT 請求視為一般 DNS 查詢。
網域規則仰賴核心取得網域資訊；如果核心只看到目標 IP，規則比對結果可能與預期不同。
如果區域網路裝置探索、公司內部網域或特定應用程式不相容於 Fake-IP，應針對性調整過濾與解析規則，而不是直接清除所有 DNS 設定。

依應用程式選擇：瀏覽器、命令列工具和遊戲該如何設定

瀏覽器：先檢查自己的代理選項

瀏覽器通常可以先使用系統代理。如果只有某個瀏覽器無法使用代理，請檢查代理擴充功能、獨立代理設定、安全 DNS，以及是否沿用切換前建立的連線。Firefox 可前往「設定」→「一般」→「網路設定」→「設定」，確認是否選擇「使用系統代理設定」。

命令列：明確指定連接埠，先進行可重複的測試

以下指令用來比較直連、HTTP 代理，以及由代理端解析網域的 SOCKS5。在 Windows PowerShell 中建議使用 curl.exe，避免舊版環境將 curl 解讀為其他指令別名。測試網站能否連線，無法單獨證明代理已成功；也要同時查看用戶端的連線紀錄。

curl --noproxy "*" -I --connect-timeout 10 https://example.com
curl --noproxy "" -x http://127.0.0.1:7890 -I --connect-timeout 10 https://example.com
curl --noproxy "" --proxy socks5h://127.0.0.1:7890 -I --connect-timeout 10 https://example.com

第一個測試會略過明確指定的代理，但若 TUN 正在接管流量，連線仍可能進入 TUN。因此，驗證系統代理時請先關閉 TUN；驗證 TUN 時再移除明確指定的代理參數，避免混淆兩種連線路徑。

如果要讓目前 Shell 中支援環境變數的工具使用代理，可以暫時設定下列變數。這些變數只會影響讀取它們的程序，並不會更改整台裝置的網路出口。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1

此處的 https_proxy 仍可使用 http:// 作為值，代表透過 HTTP 代理建立 HTTPS 通道。Git、套件管理工具和容器工具也可能有各自的代理設定。容器中的 127.0.0.1 指向容器本身，不能直接當成主機的位址。

遊戲與語音：重點檢查 UDP 出口

遊戲登入可能使用 HTTPS，但對戰和語音可能使用 UDP。遇到「可以登入、卻進不了房間」時，不能只檢查網頁。TUN 可以接收相關 UDP 封包，但所選節點、代理協定、伺服器端與連線路徑都必須支援相應的 UDP 轉送。

代理不保證能降低延遲。對戰伺服器所在區域、繞路程度、封包遺失和抖動，比節點名稱更值得參考。測試時固定伺服器與節點，分別記錄直連和代理的結果；不要把單次測速網站的頻寬數字當成遊戲體驗的結論。

軟體無法走代理：依連線紀錄分成兩條排查路徑

建立最精簡的測試環境。暫停其他 VPN、加速器和代理擴充功能，只保留一個用戶端。先記錄目前設定；若涉及公司網路，請先確認網路管理規範。
確認核心已啟動。確認混合連接埠是否確實為 7890。Windows 可執行 netstat -ano | findstr :7890 查看監聽狀態，但連接埠存在不代表監聽程序一定是目前使用的用戶端，還要確認程序。
只測試系統代理。關閉 TUN，啟用系統代理，使用瀏覽器或前述明確指定代理的指令建立新連線，同時查看「連線 / Connections」和「記錄 / Logs」。
再單獨測試 TUN。關閉系統代理，啟用用戶端要求的服務模式或管理員權限，再開啟 TUN。Android 通常需要取得系統 VPN 授權；Linux 通常需要相應的網路管理權限，不能照搬 Windows 的操作方式。
查看命中規則與實際出口。若已有連線紀錄但出口顯示 DIRECT，請優先檢查規則順序、程序比對與策略組選項。規則會依序比對，前面的規則可能比預期的規則更早生效。
最後再處理 DNS 與相容性。如果記錄出現解析逾時、Fake-IP 對應異常或特定 UDP 連線失敗，再針對這些現象修改設定，每次只改一項。

觀察到的現象	優先排查方向
操作軟體時，核心沒有對應的連線紀錄	應用程式忽略系統代理、TUN 路由未涵蓋、程序或介面遭到排除
有連線紀錄，出口為 DIRECT	規則順序、直連模式、策略組目前的選擇
有連線紀錄，代理出口逾時	節點連線狀態、協定設定、伺服器狀態、目標限制
網頁可用，遊戲語音失敗	UDP 接管與轉送支援、相關網域解析、遊戲專用規則
啟用 TUN 後無法連上公司內網	VPN 路由衝突、內部 DNS、私有網段排除設定

短連線可能很快結束，導致連線面板看不到紀錄；必要時請開啟記錄後再次重現。分享記錄前，請移除訂閱網址、存取權杖、節點憑證和私人網域；不要為了截圖公開整份設定。

最後選擇：從最小接管範圍開始

如果只需要處理瀏覽器和少數支援代理的軟體，先使用系統代理；開發工具若需要穩定且可重現的行為，優先設定工具本身的代理參數；遊戲、語音或不讀取代理設定的應用程式確實需要接管時，再考慮使用 TUN。

系統代理與 TUN 可以同時啟用，不一定會互相衝突，但排查時最好分開測試。遇到無法上網，也不必立刻重新安裝：先關閉 TUN，確認路由恢復，再關閉系統代理，檢查系統是否仍保留指向已關閉用戶端的本機連接埠。如果 TUN 已接收連線，但出口無法連通，切換接管方式通常無法解決節點本身的問題。

只要記住以下排查順序：是否接管入口 → DNS 是否正確 → 命中哪條規則 → 出口能否連線。依照這四個步驟，就能把「代理開著卻沒效果」拆解成可驗證的問題。更多規則欄位資訊請參閱設定與協定手冊；首次安裝請從快速入門教學開始。