Windows 11 Copilot、Edge 側欄連不上？Clash 分流對齊系統代理

為什麼「系統代理已開」，Copilot／Edge 側欄仍像壞掉？

許多使用者在 Windows 11 上已經讓 Clash 寫入系統代理，瀏覽器一般網站也正常，但Microsoft Copilot面板或 Edge右側欄（Discover／Copilot 類體驗）卻一直轉圈、顯示無法載入，甚至出現與帳號地區、服務可用性相關的文案。這種「一半正常、一半空白」並不罕見，因為桌面 Copilot 與側欄往往不是單一 https 請求，而是多個子網域、WebView2 行程、背景同步與登入權杖更新交錯的結果；只要其中一條鏈路被規則誤判為直連、被 DNS 解析到錯誤路徑，或被 Windows 內建的代理略過清單排除，體感就會像整個功能壞掉。

本文刻意與站內專談 Cursor／VS Code AI 分流、ChatGPT／Claude 等「純第三方 AI 產品站」區隔：那些文章聚焦 OpenAI、Anthropic 等主機形狀；而 Copilot 與 Edge 側欄更貼近 微軟服務帳號、Bing 與 Windows 元件生態，規則上若只寫了 openai.com 而沒覆蓋 microsoft.com、bing.com、live.com 等後綴桶，就會出現「一般分頁能開、內建面板不行」的落差。

先把流量地圖畫出來：行程、WebView 與典型主機

實務排查的第一步，是把「誰在連線」與「連到哪裡」分開看。Edge本體與內嵌面板多由 msedge.exe 與 Microsoft Edge WebView2相關行程承載；Copilot在桌面常透過 WebView2 載入網頁型內容，並在背景與帳號、搜尋與設定 API 互動。由於微軟會依版本調整端點，下列清單僅作為截至 2026 年常見連線主機的示意桶，實際環境請以你裝置上的連線紀錄、客戶端日誌或 DNS 查詢交叉驗證，再補上遺漏子域。

帳號與身分驗證：login.microsoftonline.com、login.live.com、account.microsoft.com 等，用於權杖與帳戶狀態；若被誤直連導致 TLS 逾時，側欄常整片空白。
Graph 與設定類 API：graph.microsoft.com、substrate.office.com（實際名稱與路徑可能隨租戶與 SKU 變動）等，常見於企業或 Microsoft 365 疊加情境。
搜尋與 Copilot 相關：bing.com、www.bing.com、edgeservices.bing.com、copilot.microsoft.com（產品改版時請以官方文件為準）等，與側欄對話、建議與內容聚合高度相關。
新聞／入口與 CDN：msn.com、assets.msn.com、microsoft.com、www.microsoft.com、edge.microsoft.com 等，負責版面資源、延伸模組與更新檢查類流量。
連線偵測與 captive portal：www.msftconnecttest.com、dns.msftncsi.com 等，若被過度代理或過度直連，有時會讓系統對「網路可用性」判斷異常，間接影響依賴網路狀態的殼層元件（視版本與政策而定）。

撰寫分流規則時，建議優先採用可維護的 DOMAIN-SUFFIX 桶，再針對特別敏感或常被第三方規則集提前命中的主機，用 DOMAIN 明確列出。若你使用社群維護的 RULE-SET，請務必檢查是否含有「將整段微軟 CDN 或 anycast IP 直連／拒連」的條目；那些條目若排序在自訂規則之前，會讓你以為 Copilot「怎麼換節點都沒用」。

規則順序：讓「微軟服務桶」贏在寬規則之前

Clash與 mihomo 系列核心的規則語意是先命中先贏。常見錯誤是把過寬的 GEOIP、巨型廣告攔截規則集、或「全機直連／全機代理」的 MATCH 放在前面，導致 Edge連到 bing.com 子域的流量根本沒機會進入你為微軟服務準備的策略組。另一種錯誤是反過來：為了省事把 *.microsoft.com 全部丟進高延遲線路，結果 Windows 更新、驅動或 Defender 定義檔下載也被迫繞遠路，體感變成「整台電腦變慢」，於是你又手動加了一堆直連例外，最後與 Copilot需要的出口互相打架。

較穩定的做法是：先為「確定與 Bing／帳號／Copilot 體驗直接相關」的後綴建立專用策略組（下節示例用 MSFT_AI），把規則放在你自己的精確 DOMAIN 規則區，並確保它們在「會誤傷的微軟 IP 規則」與過寬的 MATCH 之前。想補齊 RULE-SET、GEOIP 與最終 MATCH 的層級關係，可回到 Clash 規則分流詳解對照閱讀。

# Example: place Microsoft Copilot / Edge sidebar hosts before broad RULE-SET / MATCH
rules:
  - DOMAIN-SUFFIX,login.microsoftonline.com,MSFT_AI
  - DOMAIN-SUFFIX,login.live.com,MSFT_AI
  - DOMAIN-SUFFIX,graph.microsoft.com,MSFT_AI
  - DOMAIN-SUFFIX,bing.com,MSFT_AI
  - DOMAIN-SUFFIX,microsoft.com,MSFT_AI
  - DOMAIN-SUFFIX,live.com,MSFT_AI
  - DOMAIN-SUFFIX,msn.com,MSFT_AI
  - DOMAIN-SUFFIX,edge.microsoft.com,MSFT_AI
  # ... observe and add hosts your client logs show; keep before MATCH

若你同時啟用廣告或追蹤攔截規則集，請特別留意是否攔截了 bing.com 或 microsoft.com 底下的追蹤子域；攔截規則若與內容請求共用同一後綴策略，可能導致側欄腳本載入一半失敗，畫面看起來像「永遠載入中」。

策略組：給 Copilot／側欄一個「專用出口桶」

為 Microsoft Copilot與 Edge側欄建立獨立策略組（示例 MSFT_AI）的好處，是把「長連線、串流式回答、頻繁重試」與下載、遊戲、影音流量拆開。你可以為這個桶挑 TLS 與 HTTP／2、HTTP／3 路徑穩定的節點，而不必整機鎖在同一條 fallback 鏈上。除錯階段建議優先用 select 手動固定節點，確認規則確實命中後，再考慮 url-test；過短的測速間隔可能在回答串流中途切換節點，前端會以為連線被中斷。

也要避免「為了 AI 面板」把整個 microsoft.com 都塞進同一個高價線路：更新與大型二進位下載可能不適合與對話流量共用節點。折衷做法是先把與 Bing／登入／Graph 明確相關的後綴收斂到 MSFT_AI，其餘微軟服務維持你原本的更新／直連策略，並用連線紀錄逐步補洞。

TUN 與系統代理：建議「擇一為主」，避免雙重接管

Windows 11上，Clash常見兩種接管方式：系統代理（由系統 WinHTTP／使用者代理設定指向本機 mixed-port）與 TUN（虛擬介面＋路由表層級接管）。兩者同時開啟且設定不當時，可能出現「部分行程走 TUN、部分走系統代理、DNS 却由另一路徑解析」的分裂狀態，WebView2與殼層元件特別容易暴露這種不一致。

若你主要依賴系統代理，請確認 Clash 客戶端寫入的連接埠與協定（HTTP／SOCKS）與實際規則一致，且沒有被其他 VPN 軟體覆寫。若你改用 TUN，請理解透明代理對路由與 DNS 的要求更高，並建議閱讀 Clash TUN 模式完全指南中的 strict-route、DNS 與權限段落，再回頭微調本篇的微軟服務主機清單。原則上：先選定一種主路徑把問題收斂，再談細部規則，會比同時調兩套模式更有效率。

Windows「代理伺服器略過」清單：最常見的誤傷來源

在「網際網路內容」或現代「代理」設定中，Windows 允許填寫略過清單（以分號分隔的主機或網段）。許多教學為了讓區網或內網不走代理，會加入 <local>、*.local、甚至過寬的 10.* 類條目；若你的規則或訂閱曾建議把某些微軟主機加入略過，也可能讓 Copilot相關流量刻意繞過 Clash，在本機網路環境下直接撞牆。

建議你在故障當下比對三份設定是否一致：Clash 內「系統代理」頁顯示的略過欄位、Windows 設定 App 內的代理例外、以及瀏覽器是否另有獨立代理外掛。任何一處把 microsoft.com、bing.com 或 login.microsoftonline.com 類主機排除，都可能呈現與「規則明明寫對」完全不符的症狀。清理時請逐步還原最小略過集合，確認側欄恢復後，再按需加回區網條目。

DNS 與 fake-ip：解析看起來對、規則卻對不上

與站內其他 AI 分流文類似，DNS與規則判定不在同一條路徑時，會出現「瀏覽器偶爾正常、內建面板永遠失敗」。在 mihomo／Clash Meta 常見的 enhanced-mode 下，fake-ip 與 redir-host 取捨會影響 WebView2 與系統解析行為。若你懷疑 DNS 造成異常，請依序檢查 dns.enable、nameserver／fallback 延遲、以及 fake-ip-filter 是否把不該納入的假位址主機錯誤涵蓋或遺漏。

另須留意 IPv6：若系統優先走 IPv6 直連，而你的規則只在 IPv4 路徑上生效，也可能表現為「代理開著卻像沒開」。此時應檢查系統與核心的雙棧設定是否一致，必要時在測試階段暫時對齊單一協定族，縮小問題範圍。

區域限制訊息與單純連線失敗的區別

若介面顯示的是與帳號區域、方案可用性或合規政策相關的說明，調整 Clash可能無法改變產品行為；此時應以微軟帳號設定、訂閱方案與官方支援文件為準。相反地，若錯誤呈現為長時間載入、逾時、或憑證／DNS 類失敗，較可能仍是規則、DNS、略過清單或雙重代理模式造成。實務上建議先用連線紀錄確認請求是否命中預期策略組，再判斷是否屬於產品層限制。

請遵守 Microsoft 服務條款、帳號與裝置管理政策，以及所在地法規。本文僅討論網路設定層面的連線穩定性與本機代理對齊，不提供規避服務商區域或授權限制的方法。

與 Windows 入門文對照：系統代理從哪裡寫入

若你尚未熟悉在 Windows 上匯入訂閱、啟用系統代理與基礎故障排除，建議先閱讀 Clash for Windows 使用教學，把「客戶端如何把連接埠寫進系統」與「防火牆是否擋住本機迴環」等底層步驟補齊，再回到本篇微調微軟服務主機與略過清單。底層沒通時，上層規則再漂亮也難以驗證。

排查捷徑：依症狀收斂

側欄整片空白，但一般分頁正常

優先檢查 login.microsoftonline.com、bing.com 相關子域是否命中 MSFT_AI（或你自訂的微軟桶），並比對 Windows 代理略過清單是否排除這些主機。其次檢查是否有 HTTPS 解密、企業憑證中介或安全軟體對 WebView2 單獨攔截。

Copilot 可開啟但回答永遠轉圈

常見於長連線或串流 API 子域未覆蓋、或 url-test 在對話中途切換節點。請在測試階段改 select 固定節點，並在日誌中確認實際連線主機是否落入微軟服務桶。若懷疑 HTTP／3（QUIC）路徑問題，可與 Sniffer／QUIC 分流文對照，檢視 SNI 還原與規則命中是否一致。

登入微軟帳號頻繁失敗

將 login.live.com、account.microsoft.com 與相關驗證主機一併納入同一策略組，避免權杖取得與後續 Graph 請求走不同出口。若使用拆分 DNS，請確認帳號相關網域未被錯誤導向本機或廣告黑箱。

總結

在 Windows 11上讓 Microsoft Copilot與 Edge側欄穩定可用，關鍵不是盲目堆疊規則，而是把帳號驗證、Bing 與 Copilot 相關主機、WebView2 實際連線收斂到同一條可驗證的路徑：精準的分流規則順序、獨立策略組、與系統代理或 TUN 擇一為主的接管方式，並逐一排除 Windows代理略過清單與 DNS／雙棧不一致的誤傷。相比只調整訂閱或只更換節點，這套對齊流程更能解釋「為何一般網頁正常、內建面板卻異常」這類高頻問題。

若你希望用整合 mihomo 核心的現代客戶端在圖形介面管理規則與策略組，整體可維護性通常優於手刻零散片段；持續更新的版本也能較快跟上 DNS 與規則引擎修正。站內 Clash 功能與文件總覽可協助從功能面挑選合適工具，再把本篇的微軟主機思路套進自己的 YAML。

→ 立即免費下載 Clash 官方客戶端，在 Windows 上安裝並匯入設定後，依本文對齊微軟服務網域與系統代理，通常能更快讓 Copilot與 Edge側欄恢復可用。