📖 教學 ⏱ 約 20 分鐘閱讀

2026 Copilot 網頁打不開？Clash 網域分流與 DNS 分步實測

2026 年微軟把 Microsoft Copilot 與 m365、商務用 Microsoft 帳戶的整合往前推，搜尋「Copilot 網頁打不開、一直轉圈、登入完才閃退」的聲量也變高。與 ChatGPT／OpenAI 或純 Zoom／Teams 視訊相比，Copilot 路徑更常牽涉 登入層（例如 Microsoft 身分平台）、Graph 與 API 端點、以及分散在多個後綴上的靜態資產與 CDN；若只用一條過寬的 PROXY 或讓關鍵子綱域被早先的 DIRECT／GEOIP 規則帶走，就會出現「部分畫面能出現、但對話或授權永遠卡一半」的惱人狀態。以下用 Clash（含 Clash Meta／Mihomo 常見寫法）從連線觀測到 分流規則、DNS（含 fake-ip）整理成分步實測，協助你穩定存取產品面，並與本站 Netflix 串流解鎖這類以長連線邊緣與地區權利為主軸的題材做出區隔。文內僅討論網路可達性與設定，是否允許以代理方式存取以您與所屬組織政策為準。

先把症狀分桶：是企業或租戶策略，還是「規則與解析」失配？

在貼任何 DOMAIN 前，建議分三桶。第一桶是租戶或系統管理員關閉了 Copilot、或你的授權方案根本不包含，這類產品與帳戶層面限制，Clash 無法用規則「打開沒有買的服務」，頂多讓你更快確定是政策而非斷網。第二桶是瀏覽器能開首頁、按下一步就卡在 Microsoft 登入迴圈，或彈出視窗與本體分別走了不同路徑——常見於 OAuth／同意畫面與主分頁不在同一出站、或彈出視窗沒有吃到系統代理與 TUN 覆蓋。第三桶是登入成功後，Copilot 網頁的對話、檔案索引或 m365 延伸能力偶發失敗，而同一台機器上的 Outlook 用戶端卻沒事；這更偏向子綱域、API 主機名與 DNS 解析沒有跟著你預期的節點地區與證書鏈一致。接下來的關鍵字不是口號，而是日誌裡要一列列對上：Microsoft Copilot、m365、Clash、分流規則、DNS 與穩定存取。

若你剛從一鍵 VPN 換到規則型客戶端，建議先讀Clash 與 VPN 有什麼差別？，建立「每條連線都會被某條規則命中」的心智模型，後面讀 Copilot 網頁的日誌時才不會手忙腳亂。

和 ChatGPT、純 Teams 視訊、串流有什麼不同？

ChatGPT 與 API 一文偏重 OpenAI 端點；Zoom 與 Teams 視訊以 RTC、UDP 與會議邊緣為主。Microsoft Copilot 在瀏覽器場景中，則多了一層 Microsoft 身分與 m365 租戶邊界：同一企業內，有人只開 Copilot 網頁、有人從 Office 內嵌入口進入，兩邊實際命中的主機名與轉址鏈都未必一樣。和 Netflix 解鎖之類的串流需求相比，Copilot 更吃 TLS、登入前後完整網域鏈與可預測的 API 路徑，而不是單一影片 CDN 是否同一區。若你同時是開發者，可再與 Cursor 與 GitHub 分流對照：那裡偏 IDE 生態，本篇則是辦公入口與 m365 後端的域名維度。

第一步：用連線日誌證明「有進 Clash 核心」

在 Windows 或 macOS 上，僅啟用系統 Proxy時，UWP 與部分 Microsoft Store 下載的應用可能不經代理；讀者若遇過商店類行為，可延伸UWP 與 Clash 系統代理一文。針對瀏覽器型 Microsoft Copilot，請在重現問題時打開客戶端連線日誌，從點入 Copilot 網頁、完成 Microsoft 登入、到第一次送出提問，確認是否出現 copilot、microsoft、office、live、msft 等關鍵子字的主機名，以及實際出站。若日誌完全沒有動靜，優先處理 TUN 或等效全行程模式；概念可參考TUN 模式深度解析。

這一步的產出是一張可重現的 hostname 表，而不是在社群抄一大段後綴卻從沒在本地命中過。

第二步：Microsoft 相關網域的起手式（務必用日誌擴充與重排）

下方 YAML 只作教學起手式；實際產品與地區、租戶設定會變，請以你當下日誌為準補齊，並把條目放在會誤傷的寬條目（例如過早的 GEOIP 或 MATCH）之前。MS-OUT 請換成你設定檔內實際存在的 proxy-group 名稱，群組觀念可參考Clash 代理群組指南。

# Example starter — extend from your live connection log
rules:
  - DOMAIN-SUFFIX,copilot.microsoft.com,MS-OUT
  - DOMAIN-SUFFIX,bing.com,MS-OUT
  - DOMAIN-SUFFIX,microsoft.com,MS-OUT
  - DOMAIN-SUFFIX,microsoft365.com,MS-OUT
  - DOMAIN-SUFFIX,office.com,MS-OUT
  - DOMAIN-SUFFIX,office.net,MS-OUT
  - DOMAIN-SUFFIX,office365.com,MS-OUT
  - DOMAIN-SUFFIX,sharepoint.com,MS-OUT
  - DOMAIN-SUFFIX,azureedge.net,MS-OUT
  - DOMAIN-SUFFIX,live.com,MS-OUT
  - DOMAIN-SUFFIX,msauth.net,MS-OUT
  - DOMAIN-SUFFIX,msftauth.net,MS-OUT
  - DOMAIN-SUFFIX,msidentity.com,MS-OUT
  - DOMAIN,login.microsoftonline.com,MS-OUT
  - DOMAIN,login.live.com,MS-OUT
  - DOMAIN,graph.microsoft.com,MS-OUT
  - MATCH,Main

說明：① bing.com 有時仍出現在搜尋與延伸能力關聯的請求中，但不應把整包「所有搜尋」都永久綁死在同一組規則；請以日誌中是否屬 Copilot 網頁觸發路徑為準。② 若 microsoft.com 寫得過寬，可能帶到與 Copilot 無關的其他微軟屬性流量；若你遇到誤傷，改成較精準的 DOMAIN-SUFFIX 或 DOMAIN-KEYWORD 時，務必搭配日誌驗證，必要時參考Clash Meta 嗅探與分流例外，釐清日誌主機名與 SNI 是否一致。③ m365 與 SharePoint 場景有時還需要租戶專屬子綱域，請從實際錯誤畫面與日誌補上，不要一次性仰賴 DOMAIN-KEYWORD,microsoft 之類的過寬寫法。

第三步：規則順序、企業裝置與條件式存取

教學訂閱包裡常見「中國大陸或局域直連、或依 GEOIP 推斷」的條目。若 login.microsoftonline.com 或租戶相關主機在錯誤的順序被送往 DIRECT，可能出現你以為是「Copilot 網頁掛了」、實際卻是身分驗證與實際 API 不落在同一觀測地區的錯亂。做法是把你確認用來重現問題的主機名對應規則上移到會誤傷的條目之前，並在變更後用同一帳戶、同一瀏覽器設定檔重試一次。若屬學校或企業 AAD 條件式存取、裝置合規，官方可能要求特定網路與裝置狀態，Clash 只能協助觀測路徑，不能繞過合規。若你需把特定 App 固定到群組，可再讀自訂規則教學，但 m365 場景多數仍建議以網域為主、避免把整機長期掛在全域與實務需求不符的出站。

第四步：DNS、fake-ip 與「登入轉圈」的對齊方式

當 DNS 回傳的位址、證書所屬的入口與你出口節點所屬地區在邏輯上「各說各話」時，很容易看到登入轉完圈又回到空白、或 m365 服務斷斷續續。啟用 fake-ip 時，要特別收斂本機、路由器與 Clash 內建解析是否只剩一套決策，避免快取中殘留舊紀錄；測試期可清一次系統與瀏覽器 DNS 快取後重開工作階段。若你採 DoH，也請確保沒有第二套在背景覆寫。這一步的關鍵是讓主機名、解析結果與實際連線在整段驗證鏈中說同一件事，也是本篇反覆用「分流規則＋DNS」兩字並提的原因，因為兩者缺一角都會讓人誤以為是節點爛了。

第五步：用 A／B 測單一變因，而不是只換節點心態

在規則與 DNS 沒有先對齊前，不斷更換 Microsoft Copilot 出口節點往往只能得到「有時可、有時不可」的體感。實測上建議固定：同一日誌片段、同一份設定檔、同一步驗證，只更換一個變因（要嘛只改規則順序、要嘛只改解析策略、要嘛只換兩到三顆目標地區的節點）。若多顆節點在同一份規則下行為都失敗，偏向帳戶、租戶或服務面；若只有特定節點群組沒事，則要檢查該地區到 Microsoft 的線路品質。上游不穩時可一併參考訂閱連結常見問題，避免把單次節點擁塞當成規則寫錯。

分步實測清單：建議照順序做

同時改三處再問哪裡有效，多數人得不到答案。建議照下列步驟，讓每次都能留截圖或日誌。

  1. 可觀測性：從開啟 Copilot 網頁到送出一則測試提問，確認日誌出現預期主機名與出站。
  2. 命中哪條規則：對照規則表，是否被寬條目提前帶到 DIRECT 或意料外的群組。
  3. DNS 收斂：測試期只保留一條解析路徑，關掉會打架的第二套 DNS 或衝突的系統外掛。
  4. 假設驗證：在規則不變下抽換少數幾顆節點，看錯誤是否隨節點變化。
  5. 帳戶面核對：以同一帳戶在無代理或官方建議的網路下試一次，排除純產品或租戶關閉功能。
  6. 可維護性：把本輪新補的 DOMAIN 在設定檔裡寫上日期註解，供下次 m365 改版時追蹤（註解請用簡短英文，避免用中文註解混進 YAML 造成編碼爭議）。

若你希望讓特定瀏覽器設定檔只走某個群組，仍須以不與 TUN 或作業系統層衝突為前提；在 Windows 上若曾動過迴路豁免，也請與 UWP 與系統代理的敘事對照，避免兩邊敘事打架。

合規、授權與隱私提醒

代理會改變端對端路徑，上與中繼節點在技術上可能觀察到流量外觀。請遵守所在地法律、租戶與學校的使用政策；是否允許在受管理裝置上安裝 Clash 類工具、是否允許以私人節點處理公司內容，必須以內部規範為準。本文只提供觀測與 分流規則撰寫思路，不鼓勵違反合約或內部資安。需要安裝或更新客戶端，建議一律從本站 下載頁取得對應平台安裝檔；需要討論授權與原始碼，可另行前往專案頁，與下載 CTA 分開看待。

常見問題

已經把 copilot.microsoft.com 代理了，為什麼 Copilot 網頁還是轉圈？

多數實例中，實際請求還落在登入、Graph、靜態資產與 m365 相關子域上。請以出錯當下的連線日誌裡的主機名為準，把漏掉的後綴補進規則，並檢查是否有更早的規則把其中一段送去直連。

只有公司帳戶不行、個人 Microsoft 帳戶卻可以，是 Clash 壞了嗎？

不一定。很多情況是企業的條件式存取、合規與地區政策要求不同。請先在同一部裝置、關閉核心後用官方建議方式登入，若仍失敗，偏向租戶政策而非 分流規則能單方面修復。

DNS 沒關 fake-ip 就一定不能玩 m365 與 Microsoft Copilot 嗎？

沒有絕對說法；重點是不要多層解析互相覆寫。若你同時在路由器、作業系統與 Clash 內各有一套策略，fake-ip 反而最不容易除錯。實測階段收斂到單一路徑通常最有效。

在 2026 年讓 Microsoft Copilot 與 m365 相關流程在 Clash 後方穩定存取，本質是建立一條能反覆執行的觀測管線：先看見 Copilot 網頁實際命中的主機名，再整理分流規則與 DNS（含 fake-ip）是否一致。這和純 串流解鎖、或只盯 RTC 的會議專文，是同一套規則代理邏輯下針對不同產品面的落地。若你正在找能清楚顯示規則命中、並能負載現代系譜功能的客戶端，歡迎先從本站取得適合的安裝檔實測整段流程——→ 立即免費下載 Clash，開啟流暢上網新體驗。