為什麼「開了 Clash」卻仍像走直連？先把期待校準
在 Windows 11 上，多數圖形化 Clash 用戶端預設會提供一個開關，名稱多半是系統代理（System Proxy）。打開它的意思並不是「從此所有網路封包都會自動變成走代理」，而是請 Windows 把「HTTP／HTTPS 類、且願意遵守系統代理」的程式，導向你在本機監聽的代理埠（常見如 127.0.0.1:7890 或 SOCKS 埠）。
因此你會遇到兩種很常見、但原因完全不同的現象：第一種是瀏覽器顯示 IP 沒變，其實可能是瀏覽器自己另有代理設定、擴充套件、或「安全 DNS／HTTPS-only 模式」讓你誤判；第二種是Microsoft Store、內建小工具、或從商店安裝的 UWP 應用完全不生效，這往往與 UWP 的沙箱與 localhost 回環（loopback）限制有關，並不是單純「規則寫錯」就能解釋。
若你希望先把名詞與整體架構整理清楚，建議先瀏覽站內的說明文件總覽，再回到本文依序排查。接下來我們會把問題拆成三條線：系統是否真的寫入代理、瀏覽器是否覆寫、UWP 是否被回環擋下。
第一步：確認 Windows 真的拿到代理設定
不要只用「感覺網路變慢或沒變」來判斷。請在 Clash 類用戶端確認幾件事：混合埠（mixed-port）或 HTTP 埠是否已啟用、系統代理開關是否真的為 ON、以及是否有「僅對特定使用者／僅對目前工作階段生效」之類的進階選項被你忽略。
接著到 Windows 本機驗證：開啟「設定 → 網路和網際網路 → Proxy」，檢查「使用 Proxy 伺服器」是否被自動勾選，位址是否為 127.0.0.1，埠是否與用戶端顯示一致。若這裡始終是關閉或數值不對，代表問題在用戶端沒有成功寫入系統代理，常見原因包括：權限不足、被其他軟體搶著改回、或企業／MDM 政策鎖定。
另一個高頻誤解是把「工作列顯示已連線」等同於「系統代理已寫入」。某些情境下核心程序有在跑，但系統代理寫入失敗；此時你會看到訂閱更新正常，但瀏覽器仍走直連。建議把「設定頁的 Proxy 狀態」當成第一真相來源。
第二步：Edge 與 Chrome——誰覆寫了系統代理？
Chromium 系瀏覽器通常預設會遵循系統代理，但它也提供獨立的 Proxy 設定入口，而且非常容易被外掛或企業政策覆寫。若你安裝過「去廣告／隱私／腳本管理」類擴充套件，其中部分會插入自己的連線策略，導致你在 IP 查詢網站上看到「仍是本地電信出口」。
建議用最小化方式驗證：先以InPrivate／無痕視窗開啟（預設會停用多數擴充套件），只保留乾淨分頁測試；或在瀏覽器設定中暫時停用所有擴充套件後再試一次。若無痕就正常、一般視窗不正常，幾乎可以鎖定是擴充套件或快取造成的假象。
Edge 另有一類常見干擾是「Microsoft Defender SmartScreen／安全連線」相關功能與企業設定檔：它們不一定會把流量導去你的本機代理，但會讓你以為「我已經開代理為什麼還被攔」。這時請交叉比對：同一台電腦上用另一款瀏覽器、或直接用 curl 測試（下一段會談到終端機與系統代理的關係）。
若你確認瀏覽器乾淨、系統代理也正確，但只想讓「特定網域」走代理，其實已進入規則與策略組的範疇。可延伸閱讀站內的規則分流教學，避免把「系統層不生效」與「規則把目標判成直連」混在一起除錯。
第三步：UWP 與「回環代理」——為什麼商店 App 特別難搞
從 Microsoft Store 安裝的應用程式，多數屬於 UWP（或具 UWP 特性的封裝）。這類程式在網路層有一個桌面 Win32 程式較少遇到的限制：預設情況下，UWP 可能無法連線到本機的 loopback 位址（例如你的 Clash 監聽在 127.0.0.1）。換句話說，不是 Clash 沒開，而是UWP 被系統政策擋住，無法把流量送到本機代理埠，外觀就像「完全不生效」。
社群常把這類情境稱為UWP 回環代理或 loopback 問題。實務上會看到：Edge（視安裝與通道而定）或 Chrome 可能仍可用，但 Store、Xbox App、或某些內建元件始終直連；這並不一定是矛盾，因為不同封裝與通道走的網路堆疊不完全相同。
處理思路分兩類：第一類是解除特定 App 的 loopback 限制（進階使用者會以系統工具或指令為特定套件解除）；第二類是改走 TUN／虛擬網卡，讓流量在更底層進入 Clash，而不依賴 UWP 是否能連到本機 127.0.0.1。第二類通常更省心，但也更需要你理解路由與 DNS 的基本設定。
什麼時候該改走 TUN，而不是死磕系統代理？
若你的目標是「讓不讀系統代理的程式也納入同一套規則」，或你反覆遇到 UWP 相關限制，與其在 loopback 政策上打游擊，不如評估TUN 模式：它透過虛擬網卡在更接近系統堆疊的位置接管流量，對「本機代理埠是否可被某個 App 連上」這件事依賴較低。站內的TUN 模式詳解已從原理、權限到常見斷線原因整理過一輪，建議搭配閱讀。
但 TUN 也不是無成本：它需要驅動與較高權限，錯誤的 DNS 或路由設定可能讓整台電腦「看似全斷線」。因此比較務實的順序會是：先把系統代理與瀏覽器變因排除掉，確認問題真的卡在 UWP／非 HTTP 流量，再決定是否開 TUN。
可操作的排查清單（建議照順序做）
為了讓你可直接把本文當檢核表使用，下面用「由淺入深」排列。每一項都請你記錄結果，避免同時改太多變因而無法回溯。
（1）用戶端層：確認系統代理開關、本機埠、以及是否允許區網／LAN 連線等選項與你的使用情境一致。若你使用第三方防火牆或「網路管理」類軟體，暫時關閉後再測一次，排除攔截本機回環連線的可能。
（2）Windows 設定層：在 Proxy 設定頁確認位址與埠是否被寫入；若會被自動改回，請觀察是否有其他 VPN／加速器／企業安全用戶端與你搶奪系統代理。
（3）瀏覽器層：用無痕視窗比對、暫停擴充套件、檢查是否啟用安全 DNS。若只有特定瀏覽器異常，請優先懷疑瀏覽器自身設定，而不是 Clash 核心。
（4）UWP／商店應用層：若只有 Store 類 App 異常，先把它們視為可能的 loopback 限制案例；再決定要採用解除回環限制的路線，或改走 TUN。
（5）規則與模式層：當系統代理確定生效、但「特定網站」仍直連，請回到規則優先順序與策略組預設值，而不是一直重裝用戶端。
安裝來源與長期維護：先把工具準備好，再談排查
最後一個常被忽略、卻會讓你「怎麼調都像不生效」的因素，其實是用戶端版本過舊或安裝來源不明，導致系統代理寫入行為與新版 Windows 11 不相容。建議固定從可信的下載入口取得安裝包，並保持與核心（例如 Mihomo／Clash Meta）版本同步更新。
你可以先從本站用戶端下載頁取得目前平台可用的版本，再回來依序完成本文的檢查。相比在論壇碎片式搜尋，先把「系統代理 → 瀏覽器 → UWP → TUN」這條路走一遍，通常能最快定位問題落在哪一層。
結語：先把「哪一層失效」說清楚，修復就會快很多
Clash Windows 11 系統代理不生效這件事，本質上往往不是單一開關壞掉，而是系統寫入、瀏覽器覆寫、UWP 回環限制、以及規則分流其中一環在誤導你的判斷。把它們拆開後，你會發現大多數案例都能用很樸實的檢查找到原因，而不是靠重開機或重裝碰運氣。
相較於不斷堆疊來路不明的設定檔，更重要的是選擇一個介面清楚、能把系統代理與 TUN 的風險說明白、並在出問題時容易還原預設的用戶端。當你把「可連線」當成底線、把「可驗證」當成習慣，長期使用代理工具的成本會明顯下降。→ 立即免費下載 Clash，開啟流暢上網新體驗