1 為何必須單獨談 Microsoft 365 與 Copilot，而不是沿用「AI 站全代理」
站內已有多篇「單一產品」分流文：例如 ChatGPT／OpenAI 著重在對話與 API 網域；GitHub Copilot 則對齊 GitHub、模型供應商與開發者工具鏈。若您只抄這兩類規則，Microsoft 365 Copilot 在 Word、Outlook 或瀏覽器裡仍可能出現功能按鈕轉圈、授權狀態不一致或企業租戶政策無法套用——因為同一套「Office + AI」背後還依賴Microsoft 登入、Office 365 前端與商務 API、Microsoft Graph、以及 OneDrive／SharePoint 檔案與 CDN，主機名橫跨多組後綴，與「單一聊天網域」重疊度有限。
本文定位是辦公 SaaS 主線：把與 Microsoft 365 Copilot、Office 365 雲端、身分與檔案同步直接相關的流量，在 Clash 分流裡收斂到同一策略組；若您的組織另有 Defender、Intune 或純 Azure 工作負載，請在覆蓋下列後綴後，再依實際日誌增補，而不是假設一條 PROXY 就能涵蓋整座微軟雲。
2 2026 年辦公場景：Entra ID、Graph 與「只有 Copilot 壞掉」為何常見
企業與個人訂戶混用瀏覽器版 Office、傳統桌面應用程式與 OneDrive 同步，授權又多與 Microsoft 帳戶或 Microsoft Entra ID（舊稱 Azure AD）綁在一起。2026 年使用者對 Microsoft 365 Copilot 的期待是「在既有文件流程裡即問即用」，但實際連線仍受出口節點品質、TLS、長連線與 HTTP/2、以及規則誤配影響。當 Clash 規則把同一商業流程的不同主機拆到直連與代理兩種路徑時，最常見的不是整站宕機，而是登入成功但功能半殘、Copilot 面板空白、或 OneDrive 佇列卡住——這類問題需要網域集合與規則順序一併檢視，而不是只換節點。
讀者最常描述的三種表象
- Microsoft 登入反覆跳轉或裝置註冊失敗：身分與權杖端點未穩定命中同一策略組，或 Cookie／工作階段在不同後綴間被拆開。
- Office 網頁或 App 載入不完整、授權顯示異常：Office 365 前端資源與商務 API（含 Graph）若部分直連、部分代理，容易出現間歇性錯誤。
- Microsoft 365 Copilot 可開啟但無回應、或 OneDrive 同步停滯：除了節點本身，也要確認大型物件與 CDN 路徑未被「CDN 直連」類規則提前分流到品質不穩的路徑。
3 流量型態：Microsoft 登入、Office 雲、Graph 與 Copilot 不是同一條線
從使用者角度，開啟 Outlook 或 Word 只是一個動作；從網路角度，背後可能同時發生：瀏覽器／應用程式登入與重新導向、取得存取權杖、載入 Office 網頁資源、呼叫 Microsoft Graph 讀寫行事曆／郵件／檔案中繼資料、OneDrive 與 SharePoint 大型檔案傳輸、以及 Microsoft 365 Copilot 觸發的後端推理與前端整合。任何一類主機被規則誤判，症狀都可能表現在「只有某個功能壞掉」——這正是要以 DOMAIN-SUFFIX 建立可複製心智模型的原因。
在 Mihomo／Meta 核心下，請把HTTPS SNI與嗅探納入同一張思考圖：若規則以為目的端是 A、日誌顯示的 SNI 卻是 B，就會出現難以重現的間歇故障。建議延伸閱讀Sniffer 與 SNI 路由，先排除「規則錯位」，再懷疑服務端或節點品質。
4 網域分類：規劃 DOMAIN-SUFFIX 與 Rule Provider 時怎麼想
以下分類協助您檢查既有 Rule Provider 是否涵蓋 Office 365 與 Microsoft 365 Copilot 主路徑；實務仍以連線日誌為準，微軟亦可能新增子網域或調整 CDN。
- 身分與登入：
microsoftonline.com、microsoftonline.cn（一般用於中國區服務）、live.com、microsoft.com底下常見的帳戶與授權相關主機（例如login.microsoftonline.com）。Microsoft 登入跳轉若在代理與直連之間不一致，最容易表現為反覆登入或裝置合規檢查失敗。 - Office 雲端與生產力：
office.com、office365.com涵蓋瀏覽器版商務入口與多數 Office 網頁體驗；桌面程式亦會向相關端點索取授權與設定。 - Microsoft Graph 與 API：諸如
graph.microsoft.com等主機承載大量商務 API；一般會落在microsoft.com後綴下，與「單純瀏覽微軟官網」流量共用同一後綴，需注意規則範圍（見小節下方提醒）。 - OneDrive 與 SharePoint：
onedrive.com、sharepoint.com、以及租戶專屬子網域（例如*.sharepoint.com）常同時出現在同步與共同編輯場景；OneDrive 大型上傳若命中錯誤策略，多表現為佇列長時間不動或反覆重試。 - Copilot 與延伸服務：
copilot.microsoft.com等主機常用於消費與商務情境的入口與整合；部分推理鏈路亦可能與 Bing／搜尋基礎設施共用，故若您同時使用站內其他「搜尋／助理」類規則，請注意先後順序避免互相覆寫。
microsoft.com 範圍
單一 DOMAIN-SUFFIX,microsoft.com 可能過寬（涵蓋下載、支援、行銷等大量站點）。實務上常見做法是：信任社群整理好的 Rule Provider「微軟雲／辦公」子集，或以日誌確認實際主機後再手寫補洞；若您必須整包走代理，請接受維護成本與非辦公流量一併命中的副作用。
5 與訂閱 Rule Provider 並存：優先順序與「同一策略組」原則
Clash／Mihomo 由上而下採用第一條符合的規則。實務上常見錯誤是：訂閱附帶的 Rule Provider 把「CDN 直連」「影片／下載直連」放在前面，導致您後面針對 office.com 或 microsoftonline.com 的手寫細則永遠輪不到；或過寬的 MATCH 讓您誤以為已全代理，實際僅命中部分子網域。
對 Microsoft 365 Copilot 與 Office 365 這類強依賴身分一致性的商務 SaaS，建議把「登入、Office 雲端入口、Graph、OneDrive／SharePoint 主要後綴」視為同一個子集合，在規則表中明確指向同一策略組，再銜接兜底規則。多份 Provider 並存時，請固定一份可信來源並關注更新；互相矛盾的重複集合只會讓 2026 年的除錯成本上升。
先確認實際連線的主機名在您設定檔裡命中哪一條規則，再談節點延遲；順序錯了，換再多出口也像在抽籤。
6 Clash 規則範例：DOMAIN-SUFFIX 與策略組
以下為教學用最小示例：假設已定義名為 PROXY 的策略組（請替換為實際名稱）。真實環境更建議以成熟的 Rule Provider 為骨架，再把與 Microsoft 365 Copilot、Office 365 衝突的缺口往前插。若尚未把訂閱轉成 YAML，可先參考訂閱轉換教學。
# Example only — replace PROXY with your policy group name
rules:
- DOMAIN-SUFFIX,microsoftonline.com,PROXY
- DOMAIN-SUFFIX,live.com,PROXY
- DOMAIN-SUFFIX,office.com,PROXY
- DOMAIN-SUFFIX,office365.com,PROXY
- DOMAIN-SUFFIX,onenote.com,PROXY
- DOMAIN-SUFFIX,sharepoint.com,PROXY
- DOMAIN-SUFFIX,onedrive.com,PROXY
- DOMAIN,copilot.microsoft.com,PROXY
- DOMAIN-SUFFIX,microsoft.com,PROXY
其中 DOMAIN,copilot.microsoft.com 可單獨凸顯 Copilot 入口（若已用 microsoft.com 後綴則常屬重複命中，可擇一維護）。最後一條 microsoft.com 屬於寬泛後綴，僅在您能接受「微軟主域名下大量站點一併走同一策略」時使用；否則請改採 Rule Provider 中的「Microsoft／Azure／Office」細分子集並以日誌補洞。rule-providers: 引入時，請確認插入於 rules: 的位置早於過寬兜底規則。
7 Mihomo（Clash Meta）脈絡下的實務點
Mihomo 使用者常啟用進階 DNS、嗅探與規則集快取；對 Office 365 與 Microsoft Graph 這類大量 HTTPS、混用 HTTP/2 與長連線的服務，請特別留意規則命中與真實 SNI 是否一致。若 geosite／geoip 過舊，也可能把部分雲端後綴誤分到意外類別，建議參考GeoIP／Geosite 手動更新。
同時開啟 TUN 與系統代理時，請確認 Office 應用程式沒有繞過其中一條路徑；細節可對照Clash Verge Rev TUN 模式指南。若本機另有企業安全軟體攔截 HTTPS，也會表現為與規則無關的偶發失敗，需一併排除。
8 Microsoft 登入異常、Copilot 逾時、OneDrive 卡住：建議排查順序
建議先固定變因：同一裝置、同一份設定檔、同一時間窗內對照日誌，再考慮更換節點或暫時用較單純的全域策略對照（僅作診斷，不建議長期當解法）。
- Microsoft 登入或裝置合規一直失敗：檢查
login.microsoftonline.com及權杖相關主機是否與其它 Office 流量命中同一策略組；並確認系統時間、憑證與本機 TLS 攔截未干擾。 - Office 網頁白屏或授權狀態反覆刷新：對照日誌中
office.com、office365.com與graph.microsoft.com是否被不同規則分流。 - Microsoft 365 Copilot 無回應或僅部分租戶可用：先確認同一帳戶在無代理或已知良好網路下正常，以隔離「租戶授權／政策」與「路徑」問題；若僅在代理環境出現，再回到規則與節點。
- OneDrive／SharePoint 同步停滯：篩選當下出現的主機名，確認沒有被「大檔直連」類規則提前打成
DIRECT卻撞到品質不佳的路徑。 - Rule 模式異常、Global 正常：優先檢視規則順序與 Rule Provider，而非先假設微軟服務故障。
需要圖形介面用戶端時，建議經本站下載頁取得與站內教學一致的版本，減少用戶端與核心行為不一致帶來的額外變因。
9 DNS、FakeIP、TUN 與企業／桌面環境
只寫規則卻忽略 DNS，容易出現「同一網址偶爾能開」的假像。請把 DNS 當成分流系統的一環，讓解析、Clash 分流規則命中與實際出口一致。使用 Meta 核心時，可參考DNS 防洩漏與 FakeIP。桌面版 Office 在部分環境下會偏好系統堆疊或自己的網路堆疊；若與 TUN／系統代理並存，請確認沒有「一半流量未進核心」。
若您同時使用公司 VPN，分流路由可能與 Clash 互相覆寫，建議閱讀企業 VPN 與分流路由，釐清哪些網段必須走企業隧道、哪些可以交給用戶端代理，避免 Office 365 相關流量落到錯誤介面。
10 與站內 GitHub Copilot、ChatGPT 文章如何分工
本文聚焦Microsoft 365 Copilot、Office 365 雲端與 Microsoft 登入／OneDrive 主線網域，刻意與 GitHub Copilot（IDE／GitHub／模型 API）及 ChatGPT（OpenAI 對話與 API）區隔——三者名稱都含 “Copilot” 或都與 AI 有關，但網域與使用情境不同，不宜混用規則集。
若您也需要 Google 筆記與研究場景的分流，可參考NotebookLM 與 Google 分流；若偏重 IDE 外掛與套件下載，可延伸閱讀Cursor 與 Clash 分流，與本文辦公文書與租戶授權場景互補。
11 總結
2026 年要在代理環境下穩定使用 Microsoft 365 Copilot 與 Office 365，關鍵在於讓 Microsoft 登入、商務 API（含 Graph）、生產力入口與 OneDrive／SharePoint 主要路徑，在 Clash 分流中長期命中同一策略，並以 DOMAIN-SUFFIX 與可信 Rule Provider 降低漏網。遇到問題時，先從日誌確認實際主機名與命中規則，再調整 DNS 或節點，通常比只切換全局模式更能對症。
相較於到處複製碎片規則，維護一份對齊自己辦公與租戶需求的分流表、並在 Mihomo 中保留連線紀錄，長期成本更低。若您尚未安裝或升級用戶端，可從本站下載頁取得與教學一致的版本，再依環境選擇系統代理或 TUN。
相較僅依賴瀏覽器外掛或單一快捷規則，讓 Clash／Mihomo 在系統層一致承接 HTTPS 與 DNS，對 Office 365 大範圍後綴與 Microsoft 365 Copilot 這類跨元件功能通常更穩定；您可依裝置與公司政策微調，重點仍是「同一身分與商務鏈路不要被判成兩種出口」。
