为什么「系统代理开了」，Copilot 与 Edge 侧栏仍不正常
在 Windows 11 上，Microsoft Copilot、Edge 侧边栏、发现（Discover）与部分内置搜索，会同时依赖：微软账号登录态、Bing 与相关 API、以及基于 Chromium 的 msedgewebview2 运行时。很多用户已经让 Clash 打开系统代理，浏览器普通网页能打开，但 Copilot 面板长时间空白、侧栏只转圈、或提示区域/服务不可用。
这类现象常被误判为「单纯锁区」，实际上在中文桌面环境里，更常见的是路径不一致：系统层认为流量走了代理，但 Clash 侧把微软域名判成了直连；或 TUN 与系统代理同时启用导致环路；再或是 Windows 的代理绕过列表把关键主机名排除在代理之外。下面按「先对齐出口，再谈账号与区域」的顺序拆开。
若你尚未在 PC 上完成 Clash 首次安装与订阅导入，可先对照 Windows 安装与配置指南 把 mixed-port、系统代理开关与基础策略组跑通，再回到本文做微软服务专项对齐。
先把症状分类：账号/区域提示 vs 纯网络超时
若界面明确提示「当前区域不可用」「服务未开通」等文案，且同一台机器用手机热点或境外网络立刻恢复，那优先是微软服务策略与账号账单区域问题，代理只能改变出口，不能凭空抹掉合规提示。反之，若是无限加载、TLS 握手失败、或偶发「无法连接」，才更像分流规则、DNS 或绕过列表把部分主机名留在了错误路径上。
实务上可以做一个粗分：在 Edge 地址栏打开 bing.com 与 account.microsoft.com，观察是否与 Copilot 同时异常。若普通 Bing 可开而 Copilot 不行，往往要盯 copilot.microsoft.com、edgeservices.bing.com 一类专用主机名是否被规则集提前送到了 DIRECT。
TUN 与系统代理：建议二选一作为主路径
Clash 在 Windows 上常见两种接管方式：系统代理（把 WinHTTP/「使用代理服务器」指向本机 mixed-port）与 TUN 虚拟网卡（内核级路由分流）。两者都能工作，但同时全开时，最容易出现「部分进程走 TUN、部分走系统代理、DNS 却仍在另一条管道解析」的错位，表现为 WebView2 与外壳进程行为不一致。
对桌面办公场景，一个稳妥做法是：选定一种主模式，另一种关闭或在客户端里显式互斥。需要透明接管游戏、UWP 或不明进程时，倾向 TUN；只关心浏览器与少数支持系统代理的应用时，系统代理往往更轻。更细的字段与权限说明见 TUN 模式完全指南，本文只强调「不要叠床架屋」这一原则。
copilot、bing、microsoft 等关键字，确认连接是否仍落在 DIRECT 上，而不是只看托盘图标「已连接」。
Windows「代理绕过」与 PAC：别把微软服务误排除
在「设置 → 网络和 Internet → 代理」中，若使用手动代理，往往还有一段不使用代理的地址列表（或企业环境用 PAC 脚本下发绕过规则）。常见误伤包括：把 *.microsoft.com、*.bing.com 写进绕过，以为「微软服务应直连更快」，结果在当前运营商或公司网络下这些域名根本不可达，Copilot 与侧栏就会一直等握手。
处理顺序是：先备份现有列表，再临时清空或最小化绕过项，仅保留真正的内网段（如 192.168.0.0/16、公司域）与 localhost，复测 Copilot。若清空后恢复正常，再逐项加回，找出误伤条目。企业域环境若必须保留长绕过表，可与网管确认是否对微软 AI 入口单独放行。
需要重点覆盖的微软服务域名（示例级，非穷举）
微软与 Edge 相关流量主机名会随版本迭代变化，下列名称用于写规则时的起点，请在实际日志中补充你的订阅环境真实出现的 SNI。优先用 DOMAIN-SUFFIX 或规则集维护，避免手写过长列表难以同步。
- Copilot / Bing 服务：
copilot.microsoft.com、www.bing.com、edgeservices.bing.com、bingapis.com、bing.net（部分子域用于 API 与静态资源）。 - 账号与 Store：
login.microsoftonline.com、login.live.com、account.microsoft.com、storage.live.com。 - Edge 更新与组件：
edge.microsoft.com、msedge.api.cdp.microsoft.com（名称可能变动，以日志为准）。
若你使用社区规则集中自带的「微软服务」分类，请留意有些规则集会把 microsoft@cn 或国内 CDN 域名导向 DIRECT。在「Copilot 必须出境」的网络里，这类条目会把 AI 入口留在直连路径上——需要你在更高优先级插入专用策略组覆盖，而不是只改最后一个 MATCH。
Clash 分流规则顺序：专用策略组放在「微软服务直连」之前
Clash 自上而下匹配，第一条命中的规则决定出口。常见错误是把 GEOSITE:microsoft 或类似大集合放在很靠前，且指向 DIRECT，导致后面专门为 AI 写的节点策略永远轮不到。正确思路是：为 Copilot / Bing 建一个专用策略组（例如 微软服务-AI），在规则表靠前位置用 DOMAIN-KEYWORD / DOMAIN-SUFFIX 指向该组，再保留后面的「微软服务走直连」给真正的下载与更新 CDN。
下面是一段示意配置（策略组名与节点名请替换为你自己的；仅演示顺序思想）：
# Illustrative snippet — replace proxy group names with yours
rules:
- DOMAIN-SUFFIX,copilot.microsoft.com,MS_AI
- DOMAIN-SUFFIX,edgeservices.bing.com,MS_AI
- DOMAIN-SUFFIX,bingapis.com,MS_AI
- DOMAIN-SUFFIX,bing.net,MS_AI
- DOMAIN-SUFFIX,login.microsoftonline.com,MS_AI
- DOMAIN-SUFFIX,account.microsoft.com,MS_AI
# ... your broader Microsoft DIRECT rules below ...
- MATCH,FINAL
关于 GEOIP、DOMAIN-SUFFIX 与策略组负载方式（select、url-test 等）的系统说明，可结合 Clash 规则分流详解 对照阅读，避免只抄域名却不懂顺序语义。
DNS 与 fake-ip：网页能开、WebView2 仍断的典型坑
开启 fake-ip 时，若 DNS 与规则映射不一致，浏览器主窗口与内嵌 WebView2 可能拿到不同的解析路径：一个命中了代理，另一个仍在本地直连查询，表现为「Edge 能搜索，Copilot 面板空白」。处理上要保证 Clash DNS 段、fake-ip-filter 与规则中的域名类匹配一致，并在切换 TUN / 系统代理后清 DNS 缓存复测（管理员命令行 ipconfig /flushdns）。
若你使用 DoH/第三方解析器，确认它们没有把微软相关域名解析到「仅国内可达」的地址；必要时在 Clash 内为微软服务指定可信的上游，并在日志里核对最终解析结果与出口节点是否一致。
进程视角：Edge、WebView2 与系统搜索
任务管理器里常见 msedge.exe、msedgewebview2.exe、以及带搜索字样的宿主进程。系统代理模式下，这些进程通常尊重 WinINET/系统代理；TUN 模式下则看路由表与 Clash 是否接管了对应 UID/进程（视客户端实现而定）。若你只对浏览器可执行文件做了「绕过」或「直连」，却忘了 WebView2，也会出现侧栏与主窗口行为分裂。
排障时不必死记进程名，抓住一条：在 Clash 连接日志里对失败请求看域名与规则名，再反推是规则还是绕过列表的问题，比盲目加白名单更高效。
自检清单（建议按顺序执行）
- 确认只保留一种主模式：TUN 或系统代理，避免双开造成环路。
- 检查 Windows 代理设置中的绕过列表是否包含
microsoft/bing相关条目，必要时临时清空复测。 - 在 Clash 中为 Copilot / Bing 主机名设置靠前规则，指向可用节点，避免被「微软服务直连」提前吃掉。
- 查看日志，确认 TLS 握手失败是「解析问题」还是「出口被 RST」，针对性调整 DNS 或节点。
- 若网络侧已正常仍提示区域限制，再切换到账号/区域与合规维度排查。
小结
Windows 11 桌面上的 Copilot 与 Edge 侧栏，本质是「系统组件 + WebView2 + 微软云服务」的组合拳；Clash 只把系统代理开关拨到 On 远远不够，还要保证分流规则顺序、代理绕过列表与 DNS 与之一致。把专用域名前置到独立策略组、避免 TUN 与系统代理打架、并用连接日志验证而不是凭感觉加规则，大多数「代理已开却仍空白」的案例都能收敛。
若你希望用图形界面统一管理订阅、系统代理与规则可视化，而不是在多个设置页之间来回试错，可以从本站分发页获取已打包的客户端；相比手工维护长串域名表，一体化工具在连接日志与策略切换上往往更省心。