Microsoft Copilot 與 Office 網頁卡頓？用 Clash 分流穩住 2026 辦公存取

為什麼 Copilot 與 Office 網頁版特別吃「路由品質」

傳統靜態網頁多半是一次性拉完 HTML 就結束；Office 網頁版與內嵌的 Copilot 更像長生命週期的應用：開啟文件時要連到多個 API、CDN、遙測與共同作業服務，還要在背景維持權杖更新與即時同步。只要其中一條鏈路延遲飄高、走了不適合的出口，或與其他大流量（例如 4K 串流、遊戲更新、雲端備份）擠在同一節點，主執行緒就會表現成「整個 Office 變慢」，而不是單一請求失敗。

• 身分與文件分離：登入、授權刷新、圖形介面與實際編輯後端可能落在不同主機名與 CDN 邊緣；規則只覆蓋一半時，常出現「看得到選單、文件卻打不開」的半殘狀態。
• AI 側邊欄是額外並行流：Microsoft Copilot 可能同時向推論端、內容安全與說明頁面發請求；任一條被誤判為直連或走錯策略組，體感就是側邊欄永遠載入中。
• 地區策略與帳戶歸屬：微軟系服務會依區域與租戶設定導向不同接入點；若 DNS 與實際出口地區長期不一致，可能觸發更多重新導向與重試，外觀上像「網路不穩」。

Clash 的強項在於依域名與規則順序決定每一條連線的出口。把辦公／微軟系相關主機名提前、單獨綁定到穩定延遲的策略組，就能避免它們在晚高峰與影音流量搶同一條隧道。

這些現象更像「分流與節點」問題

在責怪機房或微軟之前，可先對照下列模式；若符合多條，值得優先檢視 Clash 規則與策略組。

此時打開 Clash 的連線檢視或日誌，對照故障當下的主機名與命中的策略，通常比盲目換節點更有效。

DNS 與身分鏈：先對齊解析，再談分流

微軟登入與租戶導向高度依賴正確的 DNS 結果。若瀏覽器啟用了獨立的 DNS-over-HTTPS，而 Clash 內部仍走另一套解析器，可能出現「同名解析到不同邊緣」的情況，讓後續規則匹配與 TLS 握手變得不穩定。

• 優先讓工作階段期內的解析策略一致：要麼由 Clash 統一處理相關查詢，要麼在排障時暫時關閉與 Clash 衝突的瀏覽器 DoH 對照測試。
• 使用 fake-ip 時，留意 fake-ip-filter 是否涵蓋區域網與本機服務；辦公場景常見的印表機、內部入口網若被誤套 fake-ip，會間接拖慢整機網路體感。
• 認證相關域名一旦在握手前長時間無回應，多半要先查 DNS 與規則互動，而不是立刻從東京換到法蘭克福。

分流規則：建議獨立的「微軟辦公」規則組

具體 YAML 會因訂閱與核心版本而異，重點是意圖：把身分驗證、Microsoft 365 前端、Copilot 相關與常見附件／同步域名，集中指向同一個策略組（例如 PROXY-OFFICE），並把該組放在過於寬鬆的 GEOIP 或「境外全代理」規則之前，以免被粗放規則提前截胡或誤直連。

不建議無差別寫一條過寬的 DOMAIN-SUFFIX,microsoft.com 就把整棵樹丟進代理：Windows 更新、商店與部分 CDN 或許更適合直連或另一組策略。較穩的做法是：只加日誌證明確實影響體驗的主機名，每次小步增量。

做法	優點	風險
精確子域／字尾規則 + 獨立策略組	辦公流量與影音下載分離，節點切換可針對性優化。	需偶爾依產品更新補規則。
全部走同一「自動選擇」組	設定簡單。	晚高峰易被大流量拖垮，Copilot 與文件儲存易卡頓。
長期 Global	排障時可快速對照。	本地與內網體感變差，日誌難讀，不適合日常辦公。

策略組與節點：讓辦公出口「別跟遊戲搶隊」

為辦公網路單獨準備一個策略組，並與「串流」「下載」「遊戲」等組分流到不同節點或不同 url-test 探針，是 2026 年很實用的折衷：您不必買第二條寬頻，只需在邏輯上把 Microsoft Copilot 與 Office 網頁版的出口與 P2P、大檔下載隔開。

• url-test／fallback：為辦公組選延遲穩定、丟包低的節點；探針目標盡量選 HTTPS 且與實際用途相近的站點，而不是隨意娛樂測速網。
• 容差與切換頻率：過於頻繁的節點輪換會讓登入與長連線會話不斷重建，外觀像「一直斷線」。適當遲滯比「毫秒級賽跑」更重要。
• 手動粘性：重要會議或簡報前，可暫時鎖定已知穩定的節點，結束後再交回自動組。

若訂閱內建「辦公」「AI」等標籤組，仍請以日誌實際命中為準；巢狀策略有時會讓介面上顯示的組名與最終出站不一致。

Edge 與內嵌 Copilot：注意多進程與擴充套件

Edge 將 Copilot 與分頁、延伸模組拆在不同進程與連線池。若僅系統代理生效，部分元件仍可能嘗試直連或走不同解析路徑。當「同一瀏覽器裡一般分頁正常、側邊欄異常」時，可嘗試：

1. 在 Clash 連線檢視中篩選與 copilot、microsoft、office 相關主機，確認是否誤為 DIRECT 或落入不想走的組。
2. 暫停廣告攔截／隱私類規則集，排除誤殺特性開關或腳本域名。
3. 若桌面應用程式（如 Teams、新版 Outlook）行為與瀏覽器不一致，可評估 TUN 模式 做對照測試；但 TUN 與公司 VPN、零信任客戶端常衝突，需先確認合規與 IT 政策。

設定片段思路（示例，請依核心語法調整）

下列片段僅示意規則與策略的接線方式，實際鍵名、錨點與訂閱合併方式請對照您使用的 Clash Premium／Meta 與機場模板。

# Example only — adapt proxy group names to your profile
proxy-groups:
  - name: PROXY-OFFICE
    type: url-test
    proxies:
      - 你的低延遲節點A
      - 你的低延遲節點B
    url: https://www.microsoft.com
    interval: 300
    tolerance: 50

rules:
  - DOMAIN-SUFFIX,login.microsoftonline.com,PROXY-OFFICE
  - DOMAIN-SUFFIX,login.live.com,PROXY-OFFICE
  - DOMAIN-SUFFIX,office.com,PROXY-OFFICE
  - DOMAIN-SUFFIX,office365.com,PROXY-OFFICE
  - DOMAIN-SUFFIX,sharepoint.com,PROXY-OFFICE
  - DOMAIN-SUFFIX,onedrive.com,PROXY-OFFICE
  - DOMAIN-SUFFIX,copilot.microsoft.com,PROXY-OFFICE
  # ... then broader GEOIP / MATCH rules

規則順序必須高於會把「微軟流量」一把抓錯的更粗規則；新增遠端規則集時注意更新間隔，避免過期列表誤傷 SaaS。

常見問題速查

只有 Word 網頁版慢，其他網站都快

高度懷疑分流規則漏配或部分子域仍走直連。抓日誌對照文件載入瞬間出現的主機名，逐條補到辦公組。

Copilot 側邊欄一直空白

先排除擴充套件與攔截規則，再查是否有 copilot／bing／microsoft 相關域名落入 REJECT 或錯誤策略組；企業租戶可能還有額外條件控管。

公司 VPN 與 Clash 同開就亂

分隧道與路由表衝突很常見。優先採用 IT 核准方案；不建議為了「能上」而硬疊 TUN 造成安全與稽核風險。

OneDrive 同步與瀏覽器 Office 可否同一組

可以先用同一組觀察；若大檔上傳與即時協作互相影響，再拆成「重傳輸」與「互動式」兩組並分別綁節點。

2026 微軟辦公分流檢查清單

下載可維護的客戶端，長期跟進域名變化

微軟產品迭代快，域名與接入點會調整；選擇核心較新、社群活躍的 Clash 系客戶端，搭配誠實的日誌習慣，比一次性「複製巨型規則集」更耐用到 2026 年以後。

立即免費下載 Clash，從乾淨、可維護的設定起步，穩定辦公網路與 Microsoft Copilot 體驗