Windows 11 上 Copilot 打不開？Clash 分流 Microsoft 與 Copilot 網域實測步驟（2026）

1. 為什麼要單獨談 Copilot：Windows 原生場景與其他 AI 專文的邊界

與單開瀏覽器分頁使用雲端聊天不同，Windows 11 上的 Copilot 體驗同時涉及：產品前端（copilot.microsoft.com 一類）、Bing／Edge 後端服務、Microsoft 帳戶與 Entra ID 登入，以及系統內嵌 WebView 或 Edge 元件對憑證、Cookie、地區偵測的組合判斷。若只用「AI 分流」這種粗標籤把少數幾個聊天網域丟進策略組，很容易出現面板框架出現了，內容區卻卡在載入：實際上是某個 edgeservices.bing.com 或登入子域仍命中直連／錯誤節點。相較之下，ChatGPT 分流偏重 OpenAI 網域與固定出口；Gemini 篇承擔 Google 生態與傳輸層對照。本篇把重心放在 Microsoft 與 Copilot 相關網域集合，並與本站 Windows 11 Verge Rev 首配銜接，方便你從「系統代理／TUN 是否生效」一路查到「規則是否命中」。

責任界線先說清楚：Clash 無法替你繞過 Microsoft 服務條款、租戶政策、裝置相容性或官方地區策略；它能做的是讓連線穩定落在你指定的策略組，並在日誌中還原「命中哪條網域規則、實際從哪個節點出去」。若錯誤訊息已明確指向帳戶權限、組織原則停用 Copilot、或硬體不相容，請先排除平台層，再回頭調 mihomo 與 DNS。

2. 典型現象：側欄、Edge 內嵌與「地區」提示

實務上常見的不是整站 404，而是側欄或 Edge 內嵌面板持續轉圈、首屏文字出現後後續請求失敗；或登入 Microsoft 帳戶正常，開啟 Copilot 却跳出與地區／可用性相關的提示。另一種典型是網頁版 copilot.microsoft.com 能開，系統側欄却空白：這往往代表瀏覽器與系統 WebView／背景行程沒有共用同一組代理或 TUN 路由，或某個 Bing 後端子域仍被「國內直連」規則提前帶走。還有一類「看似 Copilot 壞掉」，其實是 login.microsoftonline.com 與 login.live.com 登入鏈路與 Copilot 主體命中不同策略，導致權杖無法銜接。

排查時請優先看開發者工具 Network 分頁裡失敗請求的 Host（Edge 對 copilot.microsoft.com 場景尤為重要），再對照 Clash／mihomo 日誌的 DOMAIN 命中。不要只用「工作列圖示能不能開」當唯一指標；多段請求裡任何一個 Microsoft 或 Bing 子域漏規則，體感就會像間歇性故障。

3. Microsoft、Copilot 與 Bing 後端：網域清單起點

下列為 2026 年在 Copilot 網頁、Windows 側欄與 Edge 場景中仍常見的主機名類別；官方可能新增實驗子域或調整入口，實際以你環境的 Network 與日誌為準。撰寫規則時，若希望一次覆蓋 Copilot 產品頁與對話 API 路徑，通常會至少涵蓋 copilot.microsoft.com；若側欄或 Edge 仍請求 Bing 後端，則需一併考慮 bing.com 與 edgeservices.bing.com 等主機。

• Copilot 產品與網頁體驗：copilot.microsoft.com、www.bing.com（部分入口與搜尋整合仍會交會）。
• Bing／Edge 後端與服務：edgeservices.bing.com、www2.bing.com、th.bing.com（縮圖／靜態資源類主機常見，實際以 Network 為準）。
• Microsoft 帳戶與身分：login.microsoftonline.com、login.live.com、account.microsoft.com。
• 廣義 Microsoft 資產（常與更新、設定頁、擴充功能商店交會）：microsoft.com、edge.microsoft.com、microsoftedge.microsoft.com。

4. mihomo 規則範例：整包後綴與優先順序

在 mihomo（Clash Meta）裡，對 Copilot 最常見的兩種寫法是：① 以產品主域為核心（DOMAIN-SUFFIX,copilot.microsoft.com 或更寬的 microsoft.com，視你的風險承受度而定）；② 把 Bing 後端一併納入（DOMAIN-SUFFIX,bing.com）。兩者都必須放在會「誤傷」的 GEOIP 或大型規則集之前，否則日誌看起來會像「規則寫了卻完全不生效」。下列片段中策略組與節點名稱請替換為你環境中的實際字串；YAML 註解使用英文以利版本控管。

proxy-groups:
  - name: 🪟 Microsoft Copilot
    type: select
    proxies:
      - Stable-Node-A
      - Stable-Node-B
      - DIRECT

rules:
  - DOMAIN-SUFFIX,copilot.microsoft.com,🪟 Microsoft Copilot
  - DOMAIN-SUFFIX,bing.com,🪟 Microsoft Copilot
  # Optional: split login traffic if your node breaks Microsoft auth:
  # DOMAIN-SUFFIX,login.microsoftonline.com,DIRECT
  # DOMAIN-SUFFIX,live.com,DIRECT
  # ... GEOIP DIRECT and MATCH below

5. DNS、Fake-IP 與「解析路徑不一致」

Copilot 場景與 Claude 篇類似：使用者常遇到 DNS 先經由本機或另一組伺服器處理，連線卻由代理承載，表現為憑證異常、無限重試，或「只有某個子域失敗」。實務上請同步檢查：Clash DNS 模組是否啟用、是否使用 fake-ip、以及 nameserver-policy 是否為 microsoft.com／bing.com 指定了與策略組不一致的解析路徑。當你發現「解析結果看起來正確、TLS 或 HTTP 階段仍失敗」時，優先懷疑DNS 模組與規則的銜接，而不是急著換節點。

若你希望對照 Google 生態裡 QUIC 與瀏覽器實驗旗標的寫法，可交叉閱讀 Gemini 篇；本篇刻意不把篇幅花在空泛 AI 論述，只保留與「Edge／WebView 是否走同一隧道」相關的邊界提醒。

6. Edge、系統代理、TUN 與 UWP 迴環

在 Windows 11 上，瀏覽器分頁與系統側欄不一定共用同一網路堆疊：你可能已依 Verge Rev 教學開啟系統代理，但某些系統元件仍繞過本機代理，此時需要改為 TUN 模式讓流量進入 Clash 虛擬介面。若你已開 TUN，側欄仍異常，請再對照 UWP 迴環與 TUN 專文，確認是否為「系統 App／沙箱行程」與一般 Win32 程式的路由差異。

另一個實務坑是：登入與 Copilot 對話若刻意拆成不同出口，可能觸發權杖或風控鏈路不一致。上節規則範例中示範了可選的 DIRECT 註解行；是否採用取決於你的節點對 Microsoft 身分服務的相容性，請以能穩定完成登入與對話為最高優先，再微調分流粒度。

7. 驗證清單與常見誤區

完成設定後，建議依序確認：① copilot.microsoft.com 與實際對話請求是否命中同一策略組；② Bing 相關子域是否在大型規則集之前被正確覆蓋；③ 登入鏈路（login.microsoftonline.com 等）若刻意直連，是否仍與 Copilot 流量在體感上可並存；④ 系統側欄與 Edge 是否與 Clash 的系統代理或 TUN 設定一致。若 Microsoft 官方狀態頁或社群公告明示大範圍故障，請先等待恢復再調整本地規則。

常見誤區包括：只加 copilot.microsoft.com 却忽略 bing.com 後端；把「地區不可用」一律誤判成純網路問題（實際可能是帳戶、租戶或裝置政策）；以及忽略 DNS 與規則優先序，把「其實沒命中規則」誤認為節點品質不佳。