一、先對齊現象：登入、會中媒體與附件是三條不同的路

Teams 桌面程式同時依賴多種連線：Microsoft 365 帳號登入與授權、會議清單與頻道內容等控制面、載入介面與圖示所需的Teams CDN 靜態資源，以及真正承載語音、視訊與共享螢幕的媒體路徑（常涉及 UDP、ICE 候選與 TURN／中繼）。當你遇到Windows 視訊會議體感不佳時，請先分辨症狀落在哪一段：若卡在「登入或挑選帳戶」轉圈很久，瓶頸多半在 login.microsoftonline.com 一類鑑權網域、DNS 或 TLS 仍被錯誤直連；若已進會議但一開共享螢幕就失敗或黑畫面，常見是媒體或 TURN 與信令命中不同策略群組；若檔案縮圖與預覽長時間轉圈，則要同時懷疑 SharePoint／OneDrive 商業端點與 Teams 前端靜態 CDN 是否被拆散。

因此，請避免一開始就把所有問題都歸咎到「換一個節點」。較務實的做法是：先用連線日誌把「登入／授權」「會中操作與附件」「語音視訊媒體」三段分開觀察，確認各自命中的策略與 DNS 行為，再決定要不要把 Microsoft 365 控制面與 Teams CDN 拆到不同策略群組。若你尚未成功匯入訂閱或策略名稱不確定，建議先完成《Clash 訂閱連結怎麼用？機場設定檔案一鍵匯入完整教程》，避免在錯誤的群組名稱上反覆試錯。

二、兩類根因：全量代理誤傷 vs. M365／Teams CDN 鏈路沒走對

全量代理誤傷指的是：不區分服務類型，把所有 TCP／UDP 一律導向同一個遠端節點，或讓本可就近建立的 CDN 連線也繞一大圈。對 Teams 而言，這會表現為整體延遲上升、DNS 查詢變慢、甚至讓本該區域化的靜態資源下載與即時媒體搶佔同一節點頻寬。另一類是鏈路沒走對：登入與 Graph 走代理，但某條 Teams CDN 子網域仍落在 DIRECT，被公司防火牆或地區策略攔截；或反過來，媒體走了一個對 UDP 不友善的出口，而信令仍在另一個出口，導致協商看似成功、畫面卻頻繁重連。

要區分兩者，核心證據仍是連線日誌：同一分鐘內，是否出現大量 microsoft、office、teams、lync 相關主機名稱命中不同策略群組；以及在你關閉「全量」或改為分流後，症狀是否呈現「整體一起好轉」（偏誤傷）或「只有某一類子網域改善」（偏拆錯路）。釐清後再寫 Teams 代理專用規則，才不會越改越亂。

三、流量分層：Microsoft 365 鑑權、Teams 前端與媒體／TURN

實務上可把 Teams 相關連線粗分成三層。第一層是帳號與授權：login.microsoftonline.com、部分 microsoftonline.com 子域，以及與裝置註冊、條件式存取互動的端點；這一層若與其他層出口不一致，常出現「偶爾登入成功、隨即又被踢回登入畫面」的體感。第二層是Teams 應用程式本體與 CDN：teams.microsoft.com、設定與遙測相關主機、以及靜態資源常見的 statics.teams.cdn.office.net 等邊緣；這一層若被過寬的關鍵字規則或地區直連清單提前截走，介面可能半載入、圖示與字型缺失。第三層是商務協作與媒體：商業版常見的商務用 Skype／商務用 Teams 基礎設施後綴（例如 *.online.lync.com、*.infra.lync.com 家族）、以及會議中 ICE／TURN 與 UDP 相關連線；這一層若與前兩層出口不一致，最容易出現「看得到聊天、語音卻爆」或「一共享就掉線」。

撰寫 Clash 分流時，請記得 CDN 吞吐與即時媒體的優化目標不同：前者偏快取命中與大檔下載，後者偏抖動與封包遺失容忍。把兩者硬塞在同一個只看延遲數字的節點選擇裡，可能出現附件下載看起來正常、語音卻頻繁切換路由的現象。若你希望對照另一套「微軟登入＋GitHub CDN」的開發者場景，可參考《GitHub Copilot 與 Models 總斷連？用 Clash 分流微軟登入與 GitHub CDN》，理解「鑑權與 CDN 不宜被規則拆散」的共同原則，但請勿把 GitHub 專用網域抄進 Teams 規則。

四、Windows 重點：為什麼「只開系統代理」常常不夠

Teams 桌面程式並不等同於 Edge 或 Chrome；即使你已在 Windows 設定中開啟系統 HTTP 代理，仍可能遇到部分連線以不同方式發起，或被公司端點安全軟體、防火牆政策影響。實務上，若症狀主要發生在 Teams 客戶端而不是瀏覽器版，我們通常會優先建議你驗證 TUN 模式是否能讓 ms-teams.exe／相關程序一致進核心，因為它能在網路層統一接管符合條件的流量。

啟用 TUN 會涉及路由與系統權限，請先閱讀《Clash TUN 模式開啟方法》再操作，並在開啟後回到連線清單確認 Teams 主程序相關連線是否出現在核心中。若你曾遇到「Microsoft Store 類 UWP 程式不吃代理」的狀況，也可對照《Windows 應用程式商店下載失敗？用 Clash 為 UWP 開啟回環代理完整步驟》理解部分微軟容器化應用的網路行為，但 Teams 桌面版多數情境仍以一般 Win32 連線為主，診斷重心仍在規則與 DNS。

五、建議排查順序（先證明流量進核心，再談節點）

下列順序刻意把「換節點」放在中後段：先確認 Teams 相關連線有經過 Clash，且規則命中符合預期，再談線路品質與 UDP。

  1. 確認 Clash 正在執行，並依場景選擇系統代理或TUN；若問題主要出在桌面客戶端，優先驗證 TUN。
  2. 在「登入」「加入會議」「開啟視訊」「開始共享螢幕」「開啟附件預覽」五個動作下，各開啟一次連線日誌，檢查主機名稱後綴是否一致命中預期策略，而非被過寬的 DIRECT 或地區清單提前截走。
  3. 檢查 DNS 模式（是否 fake-ip）、以及 microsoft.com、office.com、teams.microsoft.com 等反覆出現的後綴是否在 fake-ip-filter 或 nameserver-policy 中有合理設定，避免解析與連線策略互相打架。
  4. 若媒體仍異常，檢視是否有 UDP 相關連線被阻擋、或 ICE 候選是否反覆在「中繼」與「直連」之間切換。
  5. 在規則已正確命中的前提下，再為控制面與 CDN／媒體分別挑選穩定、掉包低的節點；若上游網路限制 UDP，語音與共享仍可能異常，此時才需要回到網路供應商或會議政策層面處理。

若出現埠號占用、訂閱無法拉取等通用錯誤，請併讀《Clash 常見報錯解決方案》；本文聚焦 Teams 場景下的 Microsoft 365 與 Teams CDN 對齊。

六、網域怎麼收集：以日誌為準，不要只抄過期清單

微軟會依租戶區域、版本與功能旗標調整邊緣與媒體主機命名；第三方整理的清單可作起點，但最可靠的方式仍是在你自己的環境收集主機名稱。Windows 上可搭配「工作管理員 → 效能 → 開啟資源監視器 → 網路」觀察連線時的遠端位址對應名稱，或在 Clash 用戶端的連線清單中依程序或關鍵字篩選 teams、skype、lync、office。

將觀察到的名稱依後綴分組後，優先使用 DOMAIN-SUFFIX 對齊子網域樹，比過寬的 DOMAIN-KEYWORD 更不易誤傷其他服務。若你看到下載或更新檔來自第三方公有雲邊緣，請只加入「該次失敗時間點實際命中」的後綴，避免把整個超大後綴一刀切進代理，拖慢其他網站。

七、實務上常見的網域方向（以實測為準）

下列為多數商業環境下登入、會議與附件會出現的典型後綴家族；實際是否全部需要、以及是否應走同一策略群組，請以你的連線日誌為準：

  • teams.microsoft.com：Teams Web／桌面共同依賴的控制面與 API 入口之一。
  • statics.teams.cdn.office.net：常見的靜態資源與前端片段 CDN，介面半載入時優先核對。
  • config.teams.microsoft.com：用戶端設定與功能旗標相關；若被錯誤直連，可能出現版本功能不一致。
  • login.microsoftonline.com 與部分 microsoftonline.com 子域：Microsoft 365 鑑權核心，不宜與其他層拆到互相矛盾的出口。
  • graph.microsoft.com：Graph API；頻道清單、搜尋與部分附件中繼資訊會用到。
  • *.sharepoint.com、*.onedrive.com：商業附件與檔案預覽常走 SharePoint／OneDrive 商業端點；若只代理 Teams 主網域卻讓檔案直連失敗，就會看到「聊天正常、附件轉圈」。
  • *.online.lync.com、*.infra.lync.com：商務用即時通訊與會議基礎設施常見家族；是否出現在你的日誌取決於租戶與產品組態。
  • 媒體與 TURN：日誌中常出現帶區域或營運前綴的媒體與中繼主機名稱；請以實際出現的完整名稱歸納後綴，再寫規則。

重點在於：登入與頻道載入很慢時，優先懷疑鑑權、Graph 與 DNS；進房後共享或視訊一開就爆時，優先核對媒體與 TURN 相關主機名稱是否與登入流量同一出口，並檢查 UDP 是否被阻擋；只有附件異常時，優先核對 SharePoint／OneDrive 商業後綴是否被地區直連或廣告規則誤傷。

八、DNS 與 fake-ip：別讓解析鏈放大「登入轉圈」的感受

在 fake-ip 模式下，Clash 會先回傳虛擬位址再在連線階段決策出口。若 DNS 與規則配合不當，可能出現「解析看起來成功、實際 TLS 對錯出口」或反覆重試。Teams 客戶端在登入與加入會議時會持續嘗試多個子網域，任一條解析被汙染或指向不理想的路徑，轉圈時間就會被拉長。

實務上可以分兩步：第一，確認你的 DNS 上游對目標區域可信且可達；第二，對反覆出問題的後綴在用戶端支援的欄位中設定較穩定的解析策略（例如指定 DoH），並在調整後用連線日誌比對命中是否與預期一致。若改 DNS 後登入或加入會議明顯變快，代表瓶頸有相當比例在解析鏈路，而非單純節點速度。

九、分流設計檢查清單（請以你的日誌為準）

下表整理撰寫 Teams 代理與 Clash 分流規則時的檢查角度；欄位中的後綴會隨租戶與版本調整，務必以實測主機名稱為準。

類型常見主機名稱方向設定提示
鑑權與帳戶login.microsoftonline.com 等與條件式存取、裝置註冊同一策略脈絡，避免登入走代理、Graph 直連。
Teams 控制面與 CDNteams.microsoft.com、statics.teams.cdn.office.net 等介面與靜態資源不宜被拆到互相矛盾的出口。
商務檔案與附件*.sharepoint.com、*.onedrive.com 等附件預覽異常時優先核對；與 Teams 主網域策略應可預期地共存。
媒體與商務用基礎設施*.online.lync.com 等與 UDP、TURN 關聯高；需同步確認 TUN 與防火牆是否阻擋媒體埠位。

十、分流規則範例（請替換為你的策略群組名稱）

下列 YAML 片段示範「把 Microsoft 365 與 Teams 常見後綴明確指向代理群組」的寫法；請將 PROXY 替換為實際策略群組名稱，並維持規則順序：更具體的條目應放在過寬的 MATCH 與地區直連清單之前。若你希望「鑑權／Graph」與「CDN／媒體」分流到不同群組，可定義 PROXY_ID 與 PROXY_MEDIA，再依日誌微調。

# Example only — replace PROXY with your policy group names
rules:
  - DOMAIN-SUFFIX,login.microsoftonline.com,PROXY
  - DOMAIN-SUFFIX,microsoftonline.com,PROXY
  - DOMAIN-SUFFIX,teams.microsoft.com,PROXY
  - DOMAIN-SUFFIX,statics.teams.cdn.office.net,PROXY
  - DOMAIN-SUFFIX,config.teams.microsoft.com,PROXY
  - DOMAIN-SUFFIX,graph.microsoft.com,PROXY
  - DOMAIN-SUFFIX,sharepoint.com,PROXY
  - DOMAIN-SUFFIX,onedrive.com,PROXY
  - DOMAIN-SUFFIX,online.lync.com,PROXY
  - DOMAIN-SUFFIX,infra.lync.com,PROXY

若日誌中出現其他媒體專用或租戶專屬主機名稱，請以 DOMAIN-SUFFIX 逐條補上；不確定時寧可先記錄完整主機名稱，再查後綴歸屬，避免關鍵字規則過寬。

十一、UDP 與 TURN：規則正確之後仍要檢查「能不能通」

即使 Teams CDN 與控制面網域都已命中代理群組，若你的網路環境或節點型態對 UDP 不友善，語音與共享螢幕仍可能表現為高延遲或頻繁重連。此時請把觀察重點從「延遲數字」轉成「UDP 是否實際可到」與「ICE 候選是否穩定」。部分公司網路會阻擋非標準埠或非 HTTP 流量，這不是 Clash 規則能單獨解決的範疇。

協定層面也可參考《Shadowsocks vs Trojan vs Hysteria2》，理解不同傳輸方式對 UDP 與長連線的差異。請記得：節點再快，若規則讓某一條商務用媒體子網域直連失敗，使用者體感仍會是「看得到介面、一開會就掉線」。

十二、圖形用戶端中如何少踩坑

在 Clash Verge Rev 等用戶端中，建議開啟即時連線清單，篩選 teams、office、microsoft 或上述後綴關鍵字，逐條確認策略。若某條顯示 DIRECT，請回到規則表檢查是否有廣告攔截、地理分流或「繞過區域網」類規則前置命中。

若桌面端基礎設定尚未完成，可先依《Clash Verge Rev 完整設定教學》跑通訂閱與模式，再回到本文補 Teams 專用規則，可節省大量試錯時間。

十三、小結：把「掉線與共享失敗」變成可驗證的規則問題

2026 年在 Windows 上使用 Microsoft Teams 遇到音視訊卡頓、共享螢幕異常或附件預覽轉圈時，可依序確認：客戶端流量是否進核心、DNS 與 fake-ip 是否一致、Microsoft 365 鑑權與 Graph 是否與 Teams CDN／商務檔案端點對齊同一套出口，以及UDP 與節點型態是否支援你的會議型態。當連線日誌能清楚對應主機名稱與策略，你就不需盲目更換節點卻無法改善體驗。

當你希望把觀測、規則與核心更新集中在同一套成熟用戶端時，官方維護方案通常能降低手寫 YAML 的低階錯誤；相較其他同類工具，Clash 在規則透明度與日誌對照上往往更一致。→ 立即免費下載 Clash，開啟流暢上網新體驗