為什麼網頁版 Office 與 Copilot 常「各走各的」故障

在瀏覽器裡使用Microsoft 365時，你看到的其實是多條並行的 HTTPS 請求：Outlook 網頁版要連到郵件與行事曆後端、Word 網頁版要載入編輯器腳本與共同作業服務，而Microsoft 365 Copilot面板又會另外呼叫語意與建議相關端點。它們可能落在 *.office.com、*.microsoft.com、*.microsoftonline.com、圖形 API、CDN 與靜態資源等不同主機名上。當 Clash 的預設規則或過寬的第三方清單把其中幾類流量送到延遲高或不穩的節點、另幾類卻直連，你就會得到很「玄」的表象：首頁能開、編輯器卻一直載入；Copilot 圖示出現、點下去卻逾時；或登入看似成功、幾分鐘後又被導回登入頁。

這與單純「清除快取／重登一次」不同，因為權杖交換與 API 呼叫必須落在同一條可預測的出口鏈路上。若瀏覽器因擴充套件、系統代理或 TUN 造成請求分裂，微軟身分系統常會判定為風險或狀態不一致，表現成你理解的「一直要重登」。排障時請先從 規則順序與策略組命名著手，讓每一條與辦公相關的主機名都能對上可解釋的命中，而不是先懷疑帳號本身。

ℹ 先對齊目標：你要的是「office.com 前端能穩定載完」「login.microsoftonline.com 等身分端點握手不中斷」「Graph／Copilot 相關 API 不落在被節點限流的出口」。把它們拆開看延遲與丟包，再用網域分流綁到合適的策略組，會比只切一個全局 PROXY 開關更接近真相。

先把流量分桶：office.com、登入、Graph 與前端資源

實務上可先畫出下列族類（主機名隨改版與區域而變，以下僅示意分桶邏輯；請務必以你當下連線日誌為準）：

分桶之後，你才能判斷在你的網路下哪一桶適合 DIRECT、哪一桶必須走低延遲且穩定的自訂策略組。若你希望節點能自動汰換，別忘了為該策略組搭配 url-test／fallback 類健康檢查，避免 Copilot 請求長期卡在同一顆不健康節點上。

用規則與規則集為 M365 網域分流

Clash／Mihomo 系核心通常支援 DOMAIN-SUFFIX、DOMAIN-KEYWORD 等條件，把流量導向命名策略。對微軟辦公場景，實務上仍是兩層：（1）本地 rules: 頂端放少量高優先後綴，鎖定你確定要如此走的出口；（2）其餘交給訂閱規則集處理大類，再在本地用更細的規則覆蓋。請絕對注意規則由上而下的命中順序：一條過寬的 GEOIP 或 MATCH 若先吞掉微軟流量，後面針對 office.com 的細則就不會生效。

建議你為「M365-BROWSER」之類的自訂策略組單獨準備一條註解區塊，只放與瀏覽器辦公相關的後綴，和 VS Code／市集那組規則分文件或分區段維護，避免改訂閱時互相覆蓋卻難以追查。

設定示意：後綴規則與獨立策略組

下列片段僅示範結構；實際策略名稱、是否直連與是否需嗅探，請依你的核心版本、訂閱與節點品質調整。程式註解使用英文。

rules fragment (illustrative — adjust to your profile) 
# Pin Microsoft 365 web / identity before broad rules & MATCH
DOMAIN-SUFFIX,office.com,M365_PROXY
DOMAIN-SUFFIX,office.net,M365_PROXY
DOMAIN-SUFFIX,microsoft.com,M365_PROXY
DOMAIN-SUFFIX,microsoftonline.com,M365_PROXY
DOMAIN-SUFFIX,live.com,M365_PROXY
DOMAIN-SUFFIX,azureedge.net,M365_CDN
# Optional: split CDN bucket if one node fits web API but not large blobs
# ... your rule-providers and remaining rules ...

上例中 M365_PROXY、M365_CDN 代表你在 proxy-groups 裡自訂的名稱，可分別綁到不同節點池：例如一個偏重延遲、一個偏重頻寬。若你發現只有大檔下載慢，卻不影響編輯器互動，就可以只調整 CDN 那組，而不動主 Web API／登入桶。釐清「哪一桶在拖后腿」，比一次把 *.microsoft.com 全丟進單一海外節點更符合日常維運。

系統代理、TUN 與瀏覽器 DoH 誰先蓋誰

系統代理模式讓支援讀取 OS 設定的 App（含多數 Chromium 系瀏覽器）把 HTTPS 流量送往本機 Clash 埠。好處是改動面小；壞處是並非每個瀏覽器子資源或外掛行徑都一致，尤其是同時開著「瀏覽器內建 VPN／廣告攔截／另有分流套件」時，優先順序會變得難以用常識預測。

TUN在路由層接管符合條件的封包，對「就是不讀系統代理」的行程覆蓋較完整；與 Office 網頁版搭配時，較容易得到「同一進程內請求出口一致」的結果。缺點是要虛擬網路權限，也常與公司全隧道 VPN、零信任客戶端搶路由。建議延伸閱讀 TUN 模式深度解析，理解 bypass 與路由細節後再與企業網路並存測試。

瀏覽器內建 DoH（Secure DNS）會讓 DNS 查詢繞過你為 Clash 設定的 nameserver 鏈路，若再疊 fake-ip 或遠端解析設定，容易出現「Clash 以為會走代理、瀏覽器卻自力解析到另一組 IP」的假逾時。對照做法是：短暫關閉瀏覽器 DoH 做 A／B 測試，或改為讓系統 DNS 與 Clash DNS 同源；細節可搭配 Meta DNS、fallback 與 fake-ip filter 一併檢查。

若你不確定目前哪種模式最利於觀察命中，可先閱讀 如何選擇適合自己的 Clash 客戶端，挑一個連線紀錄易讀、規則除錯成本低的圖形介面，減少在三種模式之間盲目切換。

與企業 SSO、條件式存取混淆時怎麼辨

許多公司為 Microsoft 365 啟用 Azure AD／Entra ID 與條件式存取，要求特定國家 IP、裝置合規或僅能在受管網路登入。當你把微軟流量統一走某個第三方節點，可能觸發「看起來像異地登入」「裝置不合規」或 MFA 迴圈，表面上像 Copilot「壞掉」，實際上是身分政策攔截而非純路由逾時。

辨識方式：若在關閉 Clash、改連公司規定的網路或 VPN 後問題立刻消失，就應優先與 IT 確認政策，而不是再把規則加長。另一方面，若瀏覽器顯示的錯誤頁帶有明確的政策代碼或僅在特定子網域失敗，也多指向 SSO／CA，而不是單純 TLS 逾時；後者可再對照 連線日誌與 TLS 排查 區分。

和 VS Code／GitHub Copilot 專文有什麼不同

本站 GitHub Copilot 與 VS Code 市集一文，聚焦編輯器擴充、github.com／API 與市集 CDN；本則專文聚焦瀏覽器內的 Microsoft 365 網頁版與Microsoft 365 Copilot，主機名重疊度有限、但同屬微軟生態，容易在搜尋與除錯時混在一起。兩篇可以共用同一套「分桶＋日誌」方法，但建議在設定檔裡分區註解，避免改訂閱時一次動到兩種辦公型態。

⚠ 合規提示：請遵守當地法規、公司資訊安全政策與 Microsoft 服務條款。本文僅協助在合法授權網路下對齊路由決策，不鼓勵未經許可繞過組織管控或未授權使用服務。

合規情境下的自檢清單

  1. 確認你有權在目前網路使用 Clash，且存取 Microsoft 365／Copilot 未違反公司政策。
  2. 在 Clash 連線日誌記錄卡住當下的主機名、策略命中與延遲，拆成 office／login／Graph／CDN 四類檢視。
  3. 檢查規則順序：是否有寬規則先於 M365 細則命中；必要時參考 規則分流最佳實踐 調整區塊順序。
  4. 分次測試僅系統代理與僅 TUN，觀察瀏覽器內是否仍「各請求出口不一」。
  5. 暫時關閉瀏覽器 DoH 或改為與 Clash DNS 對齊，排除解析鏈分裂。
  6. 若曾反覆開關代理，依 關閉代理後無網路 一文檢查是否殘留系統代理或路由，避免量測結果被污染。
  7. 若懷疑身分配件而非延遲，先在不改 Clash 的前提下用公司規定網路驗證，再與 IT 對照條件式存取紀錄。

結語

Office 網頁版與Microsoft 365 Copilot在瀏覽器裡同時依賴多組微軟網域與身分鏈路；只要其中一段被送到錯誤或擁塞的出口，UI 上就會放大成載入失敗、面板空白或反覆登入。與其賭運氣重裝外掛或清 cookie，不如用 Clash 把 office.com、microsoft.com、microsoftonline.com 等與情境相符的策略組綁定，再對照系統代理、TUN、DoH 與企業 SSO 逐層排除。

真正能省下時間的做法，是把每一個你關心的主機後綴都寫成可讀、可版本化的規則段落，並讓節點健康檢查與日誌能互相印證。這比追求神秘一鍵配置更無聊，卻是長期穩定使用微軟雲端辦公服務與 Copilot 的日常功課。

→ 立即免費下載 Clash，開啟流暢上網新體驗，用一致的分流與可追蹤的連線紀錄，把心力放在文件與協作本身，而不是卡在瀏覽器轉圈與重登迴圈。