2026 年 Microsoft 365 Copilot 与 Office：Clash 登录与域名分流

1 办公场景：为什么要把 Microsoft 365 单独写进规则

Office 365与Microsoft 365 Copilot在 2026 年已深度嵌入邮件、文档、表格、团队空间与会议日程；用户侧看到的只是 Word / Excel / Outlook / Teams 几个图标，背后却是一条串联身份、存储、协作 API 与 AI 编排的长链路。若Clash 分流只按「境外网站」粗粒度匹配，常见结果是Microsoft 登录页在浏览器里能打开，但桌面 Office套件里令牌刷新失败；或网页端 Copilot 面板一直转圈，而其它站点正常。把这条链拆成可读的策略组 + 域名后缀，比在全局模式里反复切节点更符合办公排障节奏。

本文面向已在 PC / Mac 上使用Mihomo或 Clash Meta 系客户端的读者；若尚未安装图形客户端，可先前往本站下载页获取各平台安装包。下文中的 YAML 仅为示意，请与你现有 proxy-groups与地理/合规策略合并；开源仓库可用于核对协议，客户端分发请以站点为准。

心智模型 把流量拆成四层：① 身份与 OAuth（登录与令牌）、② Office 网页与 Copilot 入口、③ Microsoft Graph / 后端 API、④ OneDrive / SharePoint 存储与附件。Clash 分流的目标是让同一Microsoft 账号在多层请求上落在一致、低抖动的出向上，并在日志里能用 DOMAIN-SUFFIX对齐现象。

2 与 GitHub Copilot、ChatGPT 等专文如何分工

站内《2026 年用 Clash 分流稳定使用 GitHub Copilot：登录与模型请求代理设置》聚焦 GitHub与githubcopilot.com等开发者工具链域名；与本文讨论的 Office 云、Entra ID 与 SharePoint所涉主机名并非同一套，不应混在一条「Copilot」规则里望文生义。另一方面，《2026 年用 Clash 稳定访问 ChatGPT：OpenAI 域名分流与 API 代理设置》面向 OpenAI端点；Microsoft 365 Copilot商用能力由 Microsoft 365 租户与合规策略编排，连接日志里占主导的仍是 microsoft.com、office.com与 sharepoint.com等族，而不是 openai.com。

《2026 年 Notion AI 办公热：Clash 分流稳定登录与同步域名规则》与本文同属「办公协作 + AI」选题，但 Notion的数据面在 notion.so族，与 Office 365的 Microsoft 登录与 Graph路径仍然不同——读者可按正在使用的产品选型跳转，避免把一份通用 AI 站名单硬套到 Microsoft 工作流上。

3 Microsoft 登录、Entra ID 与 OAuth 跳转

个人与商业租户在登录环节普遍命中 login.microsoftonline.com、login.microsoft.com，历史上亦常见 login.live.com与 account.microsoft.com用于账户管理与许可展示。DOMAIN-SUFFIX层面可优先纳入 microsoftonline.com、microsoft.com（至少覆盖登录子域），但整域 microsoft.com极宽，容易把 Windows 更新、商店与其它微软服务一并卷入同一策略组。更务实的做法是：将明确用于身份的后缀放进独立Rule Provider或独立策略组（例如 PROXY_M365_LOGIN），再按本机连接日志增量补全。

企业 SSO常引入组织专属 IdP；若仅代理了 Office 网页而登录回调走了直连，会出现 Cookie 分区不一致或循环重定向。这不止是「再加一条域名」的问题，而要保证身份相关主机名与Office 应用主机名处于同一出口语义。DNS 与 FakeIP 协同请参阅《彻底防止 DNS 泄漏：Meta 内核 DoH + FakeIP 最佳实践配置》。

慎用过宽后缀 生产环境长期使用单一的 DOMAIN-SUFFIX,microsoft.com作为「万能代理」容易造成难以解释的路由；更推荐把 Microsoft 登录与 Office 云服务拆成可命名策略组，便于对照日志与团队内部分享。

4 Office 网页端与 Microsoft 365 Copilot 入口

网页版套件主要出现在 office.com、www.office.com及各类 *.office.com子域（如 Outlook、Word、Excel 的 Web App）；微软亦在推进 cloud.microsoft统一前缀下的应用启动与聚合体验（具体子域会随租户与发布通道调整）。你在浏览器里打开 Copilot面板时，多数请求仍会落在上述 Office 云与身份相关主机上，而不是独立的「小模型站」短名单。因而Clash 分流上应优先保证 office.com与已观察到的*.office.com、cloud.microsoft等与会话一致。

若某地区或网络策略对特定路径做了拆分调度，请以你本机 Mihomo连接日志为准做增量合并；不要假设「覆盖 office.com一条就够了」——附件与前端静态资源可能出现在其它注册域下，需要二次收录进Rule Provider。

5 Microsoft Graph、Teams 与实时协作

自动化、加载邮箱元数据、日历与团队资源时，客户端会访问 graph.microsoft.com所代表的 Microsoft Graph API 面；Teams 会议与消息亦有大量主机落在 teams.microsoft.com及其关联 CDN 上。若 Graph 与 Office 网页走了不同策略，典型故障是「界面已登录但列表空白」「保存失败但无明确报错」。在规则顺序上，建议把 Graph 与同一租户相关的 API 主机并入与 Office 主站相同或显式对齐的策略组命名体系（如 PROXY_M365_API与 PROXY_M365_WEB保持同一上游选择逻辑）。

实时音视频对抖动敏感；若你为 url-test自动测速组配置了频繁切换节点，可能被误解为「Teams 不稳定」。可对办公策略组固定较稳定线路或关闭不必要的自动切换，思路与《Clash URL-Test 与 Fallback：测速选节点与故障转移》中的策略组选型相呼应。

6 OneDrive、SharePoint 与大附件

个人与家庭场景常见 onedrive.live.com与 *.live.com下的存储主机；企业文档协作大量依赖 sharepoint.com与租户子域。OneDrive同步客户端与浏览器上传会混合使用 API 请求与大对象传输，后者可能显现为 CDN或对等域上的长连接。若仅代理了网页却漏掉同步子域，会表现为「网页能查看、客户端始终 pending」。

不建议靠极宽的 DOMAIN-KEYWORD长期顶替；更安全的路径仍是：DOMAIN-SUFFIX,live.com、DOMAIN-SUFFIX,sharepoint.com配合可更新的Rule Provider吸收日志中出现的新主机名。地理类误判时可参照《Clash Meta 手动更新 GeoIP 与 Geosite》做例行刷新。

7 DOMAIN-SUFFIX 与 YAML 示意

下面是一段示意性片段，演示如何把 Office 365相关后缀放在通用「全球站」规则之前。名称与时间间隔请按你的环境改写。

config.yaml (snippet)

# Example only — merge with your full profile
proxy-groups:
  - name: PROXY_M365
    type: select
    proxies: [AUTO-BEST, DIRECT]

rule-providers:
  m365-extra:
    type: http
    behavior: classical
    url: "https://example.com/rules/m365-extra.txt"
    path: ./ruleset/m365-extra.yaml
    interval: 86400

rules:
  - DOMAIN-SUFFIX,office.com,PROXY_M365
  - DOMAIN-SUFFIX,microsoftonline.com,PROXY_M365
  - DOMAIN-SUFFIX,live.com,PROXY_M365
  - DOMAIN-SUFFIX,sharepoint.com,PROXY_M365
  - DOMAIN-SUFFIX,cloud.microsoft,PROXY_M365
  - DOMAIN-SUFFIX,microsoft.com,PROXY_M365
  - RULE-SET,m365-extra,PROXY_M365

再次强调：microsoft.com很宽，可能与非 Office请求重叠；若你只想收敛到Microsoft 365 Copilot与Office 云服务，宜通过Rule Provider维护更精确的名单，并把泛后缀作为兜底前的临时手段而非终态。

8 Rule Provider：跟上微软域名演进

云服务商会持续调整边缘节点与主机命名；把易变条目放入可拉取的Rule Provider，比在每台办公电脑上手工改 rules:更可维护。建议团队维护一份说明文档：哪些后缀属于身份、哪些属于存储、哪些仅用于排障临时放行，并记录更新人与日期。

9 TUN、系统代理与「半代理」登录

桌面 Office与「新型 Outlook」等应用在系统代理与TUN 全流量上的行为并不总一致：仅浏览器配置了代理、而系统其余流量直连时，最容易出现Microsoft 登录在浏览器成功、客户端仍要求验证。启用 TUN 或在应用层显式指向 Mihomo监听端口，可减少这一类半代理状态；步骤级说明见《Clash Verge Rev TUN 模式完全指南》。HTTPS 场景下的 SNI 与嗅探边界可参考《Clash Meta Sniffer：HTTPS 嗅探与 SNI 分流修正》。

10 建议排错顺序

在连接日志中过滤 microsoft、office、sharepoint，确认是否命中预期策略组。
核对 login.microsoftonline.com与 Office 主站是否同一出口语义。
检查 Graph（graph.microsoft.com）是否与 Web 应用分流一致。
对照 DNS/FakeIP 设置，排除解析与证书问题。
短暂固定节点或关闭自动测速切换，验证是否抖动导致会话中断。

最小验证 ① 浏览器完成Microsoft 登录；② 打开网页版 Word 并新建文档；③ 观察 OneDrive或库保存是否成功；④ 再试用 Microsoft 365 Copilot侧边栏。四步通过后再推广到全团队。

11 常见问题

只配 office.com 够不够：往往不够；Microsoft 登录与 Graph、OneDrive还分布在其它后缀下，需按日志补全。
Copilot 按钮灰色：除网络外，多与租户许可、区域策略与管理员开关有关；应优先对照组织合规与账号权限。
与 GitHub Copilot 规则合并：可以共存，但请分策略组维护，避免一锅煮导致排障困难。
旧版内核：本文语法面向 Meta / Mihomo系；旧内核请核对 RULE-SET支持情况。

12 总结

2026 年要在办公场景稳定使用 Microsoft 365 Copilot与 Office 365全套能力，网络侧的关键是对齐身份、Office 网页、Graph API 与 OneDrive / SharePoint 存储四类流量，用Clash 分流写出可解释的 DOMAIN-SUFFIX与Rule Provider，并在 Mihomo日志里验证Microsoft 登录与业务请求落在一致的策略语义下。与站内 GitHub Copilot、ChatGPT、Notion AI等专文并列时，各方域名集合职责清晰，读者可按实际栈组合规则，而不必把不相干的「AI 站清单」合并成难以维护的一团。

相比没有规则引擎的单一 SOCKS 出口，Clash 系在策略命名、Provider 更新与连接可视化上的积累，更贴合企业办公的长期运维；需要安装或升级客户端时，请使用本站下载页获取各平台安装包。

作为收尾对比：在许多场景下，把规则写清楚比单纯追求「测速第一的节点」更能改善登录与协作稳定性；当Copilot与文档编辑路径共用一致、低抖动的出向时，日常感知到的卡顿与异常会明显减少。

→ 立即免费下载 Clash，开启流畅上网新体验

2026 年用 Clash 分流稳定使用 Microsoft 365 Copilot：
Microsoft 登录与 Office 云服务域名