为什么常表现为网页白屏、Copilot 卡住或反复重登

在 Chrome、Edge 或其它 Chromium 内核浏览器里打开 Office 网页版时，最刺眼的故障往往是：邮箱能进首页、正文区长时间空白；Word 网页版编辑器骨架出来了，协作或自动保存却一直转圈；侧边 Microsoft 365 Copilot 面板提示加载失败，刷新后又被要求重新登录。它们并不总是「节点彻底不可用」单因，而经常是一批主机名没有稳定走同一条出口，或浏览器侧 DoH、系统侧解析与 Clash 路由决策互相打架。把现象对应到连接日志里的「哪条主机、dial 卡在哪一跳」，比盲目换节点更接近解决办法；分层思路可与 规则分流最佳实践一起用在维护性上。遇到握手或中断类报错时，再结合 从日志读懂 timeout 与 TLS 逐层对照。

一次完整的 微软服务会话通常横跨 office.com 与 office365.com 系页面壳层、microsoft.com 下脚本与静态资源、microsoftonline.com / login.microsoftonline.com 的身份票据交换，以及大量 *.azureedge.net、*.akamaized.net 等 CDN 长尾（具体以你当前租户区域与产品形态为准）。若壳层走了代理、某段 AJAX 或 WebSocket 仍直连，或 TLS 在某一跳被中间策略改写，就会出现「看起来像登录成功、Copilot 却始终饿死」的半截症状。

Clash 的价值在于：用可读的域名分流把这些连接对齐到同一策略意图上，而不是依赖反复清 Cookie。本文只讨论在合法合规、且你已被允许使用相应代理出口的前提下如何配置；若单位明令禁止个人代理或要求专用隧道，请勿用本文思路绕过组织安全边界。

ℹ 先分层：把「身份是否真失败」「DNS / DoH 是否抢答」「哪些主机名命中哪条规则」「浏览器进程有没有被 TUN 接住」分开看。Office 网页版与 Copilot 一次交互往往涉及十几条连接，任一层错位都会表现为白屏或频繁重登。

与「GitHub Copilot + VS Code」专文：浏览器办公 vs 开发者扩展

本站已有一篇面向 VS Code 扩展市场与 GitHub Copilot 插件链路的 GitHub Copilot × VS Code 域名分流：那里强调 marketplace.visualstudio.com、github.com 与 microsoft.com 在桌面 IDE进程里的组合。本篇面向浏览器内的 Microsoft 365 Copilot 与 Office 网页版：身份与前端资源同样落在 *.microsoft.com / *.office.com 等后缀下，但不会经过 VSIX 或扩展市场那一条链路，规则若从 IDE 文章照搬而不看浏览器连接日志，仍可能漏掉只出现在网页里的 CDN 主机。选型与日志能力上，也可先对照 如何选择适合自己的 Clash 客户端，优先挑能按域名筛连接、便于核对命中规则的发行版。

先辨别：企业 SSO、条件访问与「不是 Clash 能单方面修复」的情况

企业 SSO、条件访问、设备合规策略、或租户侧关闭某地区 Copilot 功能时，症状也可能表现为登录页循环、侧栏灰掉、或组织中干脆看不到 Copilot 入口。这类约束属于身份与许可证层面，单纯「把代理打开」无法替代合规设备或管理员放行。排障时建议先在同一浏览器用无痕窗口排除缓存与扩展干扰，再与 IT 控制台里对该用户是否启用 Copilot、是否限制办公网络出口等信息交叉验证，避免把组织策略误当成路由问题。

若确认身份侧无异常、但仍怀疑解析路径不一致，可对照 Clash Meta DNS：nameserver、fallback 与 fake-ip 过滤，检查内置 DNS、fallback 链与 fake-ip-filter 是否把 microsoftonline.com 等主机挡在错误模式里，而不是急于堆宽后缀规则。

M365 域名分层：microsoft.com、office.com、登录与 CDN

入口与文档壳层

Office 网页版常见入口落在 office.com、www.office.com，邮件与日历可能经 outlook.office.com、outlook.office365.com 等主机加载。只写主域而漏掉 office365.com 系子域，常表现为外壳有了、邮箱正文区一直转圈。

身份与令牌

组织账号登录往往涉及 login.microsoftonline.com、*.microsoftonline.com，有时还有 live.com / microsoft.com 上的账户管理页。若身份请求与文档域名分流不一致，浏览器可能拿到半套票据，表现为刷新后又回到登录页。

Copilot 与静态资源 CDN

Microsoft 365 Copilot 侧栏与建议接口除 microsoft.com 子域外，还常拉取 *.azureedge.net、各类第三方 CDN 名（以连接日志为准）。此处正是「抄了 microsoft.com 仍白屏」的高发区：需要在日志里补全漏网主机，再决定是否放宽到 DOMAIN-SUFFIX,azureedge.net 等更宽后缀——宽后缀会影响面广，务必与团队策略一致。

核心思路：为微软服务单独建策略组，再收紧规则粒度

与「全局代理」相比，更贴近企业办公的是分流：内网、常用大陆站点与视频会议等直连，将微软服务与Office 网页版相关主机送入名为 M365_PROXY（示例名）之类、与其他跨境业务可区分的策略组。这样便于在日志里单独观察 Microsoft 365 Copilot 是否始终命中同一出口，也方便在节点波动时只切这一组而不动默认流量。

Clash 自上而下匹配规则，命中即执行；未命中落入 MATCH。因此默认直连或默认代理必须与真实办公网络一致。实务上建议在复现时打开连接日志，把失败瞬间出现的主机名原样记下，再映射到 DOMAIN / DOMAIN-SUFFIX，必要时使用 rule-providers 维护远程规则集，减少手写漂移。

规则示例：DOMAIN-SUFFIX 与可选规则集

下面是一段仅作说明的极简示意（策略组名随订阅与客户端而异，请替换为你的实际组名；慎用过大后缀以免误伤无关微软流量）：

Illustrative YAML fragment

rules:
  - DOMAIN-SUFFIX,office.com,M365_PROXY
  - DOMAIN-SUFFIX,office365.com,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_PROXY
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

实战往往在「补具体 DOMAIN」与「放宽后缀」之间取舍：DOMAIN-SUFFIX,microsoft.com 会覆盖极广，若与个人其它微软服务期望冲突，可优先锁 substrate.office.com、graph.microsoft.com 等在日志里反复出现的主机，再配套规则集更新。出现 dial、RST 或证书报错时，继续用 从日志读懂 timeout 与 TLS 区分是出口问题还是 SNI/链问题。

浏览器 DoH、Clash DNS 与 fake-ip 混用时的错位

现代浏览器可单独开启基于 HTTPS 的 DNS（DoH），而 Clash 也可能启用 fake-ip、或自建 nameserver / fallback。三者同时生效时，常见假象是「地址栏能解析、规则却匹配不到真实域名」，侧栏脚本因此卡在半开连接。排障时应选定一条主解析路径：要么短期关闭浏览器 DoH 做对照，要么在 Clash 侧为 microsoftonline.com 等加入 fake-ip-filter、统一走真实解析，并再次核对 DNS 与 fallback 配置。泛化的 DNS 概念也可扫一眼站点 常见问题。

与此同时，不要把「本机 hosts 或安全软件过滤」排除在外：它们同样会让浏览器拿到与 Clash 规则假设不一致的解析结果，表现形式与单纯漏规则非常像。

系统代理、浏览器进程与 TUN：谁真正覆盖 Office 网页流量

若仅开启系统代理并指向 Clash 的混合或 HTTP 端口，多数 Chromium 内核浏览器会把 HTTPS 交给代理；但若你在浏览器里另配了独立 HTTPS 代理、或使用仅对部分站点生效的扩展，仍可能出现「主站走了 Clash、某段子资源直连」的分裂。Edge 与 Chrome 对企业配置文件与扩展权限的策略也不尽相同，排障时宜用连接日志确认浏览器进程发出的目标主机是否真的进入内核。

TUN 在系统层接管 IPv4/IPv6 路由，通常比「只靠系统代理」更完整地覆盖未自觉跟随环境变量的进程；代价是需要虚拟网卡权限，且可能与单位 VPN、其它零信任客户端抢路由。部署前建议阅读 TUN 模式深度解析。小结：在配置正确的前提下，TUN 对进程覆盖更完整；系统代理更轻，但依赖应用与扩展是否遵循系统设置。先确认日志里已出现浏览器连接，再调域名分流细节。

规则顺序、抢跑与 MATCH

规则自上而下，第一条命中生效。若一条过宽的 GEOIP 或「国内列表」抢在 office.com 相关规则之前命中，就会出现时好时坏的登录或 Copilot 空白。建议把明确的微软服务后缀放在容易误判的宽规则之前，并定期用日志核对 Office 网页版加载时各自主机到底落在哪个策略组。

MATCH 兜底决定「漏网流量」的去向。与其一味把 MATCH 改成全局代理，不如补齐主机名与规则集，国内体验与可预期性都会好得多。

订阅与规则集更新通道

当系统代理或 TUN 已指向 Clash，而拉取远程订阅或规则集的域名本身又被送进不稳定代理链时，会出现「规则永远停在上个月」的现象，新出现的 微软 CDN 主机便长期进不了配置。宜为订阅源、GitHub Raw、规则 CDN 保留直连或独立更新策略，与日常 M365 分流拆开。操作习惯可与 订阅管理与节点维护中的流程对齐。

⚠ 合规提示：请遵守所在地法律法规与微软、租户管理员制定的服务条款与网络策略。本文仅作路由与 DNS 层面的技术说明，不鼓励未授权访问、绕过组织安全边界或任何违法用途。

合规环境下的自检清单

  1. 确认当前环境与租户策略允许你以当前方式访问 Microsoft 365 与 Copilot（含许可证与地区）。
  2. 校准系统时间，排除 TLS 与证书链误报。
  3. 在 Clash 连接日志中抓取白屏或重登瞬间的完整主机名与策略组。
  4. 核对 office.com、office365.com、microsoft.com、microsoftonline.com、以及相关 CDN 是否已被 DOMAIN-SUFFIX 或规则集覆盖，并按日志补漏。
  5. 对照浏览器是否开启 DoH、与 fake-ip / nameserver 是否冲突。
  6. 确认拉取订阅与规则集的通道无循环代理。
  7. 在系统代理与 TUN 两种模式下各测一遍，确认浏览器进程流量确实进入内核。
  8. 本地因素排除后，再评估节点质量与微软服务状态。

将每一步对应的主机名与策略组记在备忘录里，可复现的实验比反复清空 Cookie 更有用。

结语：把 M365 域名写进可维护的分流清单

Office 网页版与浏览器侧 Microsoft 365 Copilot 的高频故障，本质上会反映在域名与 CDN 长尾的持续变化上：微软调整静态资源路径、身份端点升级、或租户启用新的体验子域，都会让「昨天还能用」的个人配置突然失灵。Clash 提供的是可验证的域名分流与策略组语言：把日志、规则与节点质量拆开看，才能把「白屏」还原为「哪条主机、哪条规则、哪一跳 超时」。

相比全局开关，把 *.microsoft.com、*.office.com 及日志中反复出现的 CDN 主机纳入可读、可更新的清单，其余办公流量保持直连，通常更省带宽，也更贴合混合使用大陆与跨境协作的现实。厘清系统代理、浏览器 DoH 与 TUN 的覆盖关系，还能少踩「主站通了、Copilot 仍饿死」的坑。

在同类工具里，把策略编辑与连接日志放在手边、用现代内核承载规则集与策略组，往往更利于企业办公场景下快速自证；若你希望以可重复的方式收敛问题而不是反复试错，Clash 的这条路径通常更省心。

→ 立即免费下载 Clash，开启流畅上网新体验，用可维护的域名分流为 Microsoft 365 Copilot 与 Office 网页版对齐微软服务相关主机出口，在正当合规的前提下少受白屏与重登困扰，而不是交给一次次盲目刷新。