先确定分流目标，再判断是否需要 TUN

Notion、Figma 和 Miro 都可能通过多个域名提供页面、接口、图片或实时协作功能。只让主站域名走代理，有时会出现首页能打开、登录卡住、图片不加载或协作内容更新延迟等情况。配置时应先把“哪些请求需要代理”说清楚，再用日志确认实际命中的域名，而不是一次性把所有流量都塞进代理。

Clash 图形客户端负责选择配置、切换策略组和设置系统代理；mihomo 内核负责解析规则并转发流量。通常可以先用系统代理测试浏览器中的协作网站。系统代理只对遵循 Windows 代理设置的应用生效；如果桌面应用没有使用系统代理，再评估 TUN。TUN 会通过虚拟网卡接管更多流量，也会增加 DNS、路由和公司 VPN 共存方面的排查复杂度，并非分流配置的必选项。

现象优先检查建议处理
浏览器里的页面打不开系统代理状态、规则模式、目标域名命中策略先确认浏览器是否使用 Clash 代理，再查看连接记录
页面能开，但图片或文件缺失资源域名、CDN 域名及相应连接记录根据实际请求补充域名规则，不要只增加主站域名
浏览器正常，桌面应用异常应用是否遵循系统代理、是否有独立网络设置先尝试应用内代理设置；有需要时再评估 TUN
能连接但协作状态不同步实时连接、DNS 解析、节点稳定性和应用日志分开测试，不要把延迟测速结果当作实时协作成功的证明

在开始修改前，记下当前模式、系统代理开关、正在使用的配置名称，以及 Notion、Figma、Miro 的具体故障表现。这样每次只改一项，才能判断变化来自规则、节点、DNS 还是客户端代理模式。

先确认策略组和规则模式可用

域名规则需要指定一个动作或策略组，例如 DIRECT、REJECT，或者配置中已有的代理组名称。示例中的「办公代理」只是占位名称，必须替换为自己的配置里真实存在的组名；如果组名不存在，内核可能在加载配置时报告规则引用错误。规则模式下，规则才会按顺序参与匹配；全局模式会按全局选择转发，直连模式则不会按下面的域名规则分流。

在 Clash Verge Rev、Clash Verge 或其他 mihomo 客户端中，先选择要测试的订阅配置，打开规则或代理设置页面，将运行模式切到「规则」。菜单名称会随客户端版本变化，关键是确认当前运行状态，而不是只编辑了 YAML 就认为配置已经生效。修改配置前建议导出或复制一份当前可用配置，出现错误时可以立即回退。

  • 确认组名：在配置的 proxy-groups 中查找用于选择节点的组，规则中引用的名称必须与其完全一致。
  • 确认策略组可用：如果策略组下没有可用节点，规则命中它也无法建立正常连接。先在客户端切换到一个可用节点进行基础测试。
  • 确认规则模式：按域名分流依赖规则匹配；不要在测试期间同时切换到全局或直连模式。
  • 保留国内直连：仅对明确需要代理的协作域名指定代理组，其余流量交给原有规则和末尾规则处理。

如果使用的是订阅托管的完整配置，不要为了几条域名规则重写整个订阅。优先使用客户端提供的规则覆写、合并配置或本地配置入口，并确认订阅更新后这些本地规则仍被保留。不同客户端的覆写语法并不相同，不能把一个客户端的脚本直接粘贴到另一个客户端。

按域名添加规则，并保留国内网站直连

可以先从协作服务的主域名及常见资源域名开始，再根据连接日志补充缺失项。以下是 mihomo 配置中的规则片段，不是完整配置；请把「办公代理」换成实际存在的代理组，并将规则放在可能提前匹配它们的宽泛规则之前。域名列表只是起始检查范围，不保证覆盖所有版本、区域或第三方登录方式。

rules:
  - DOMAIN-SUFFIX,notion.so,办公代理
  - DOMAIN-SUFFIX,notion.site,办公代理
  - DOMAIN-SUFFIX,notion-static.com,办公代理
  - DOMAIN-SUFFIX,notionusercontent.com,办公代理
  - DOMAIN-SUFFIX,figma.com,办公代理
  - DOMAIN-SUFFIX,figmausercontent.com,办公代理
  - DOMAIN-SUFFIX,miro.com,办公代理
  - DOMAIN-SUFFIX,mirostatic.com,办公代理
  - DOMAIN-SUFFIX,mirousercontent.com,办公代理
  # 在这里保留配置原有的国内直连规则和其他规则
  - MATCH,原有默认策略

示例中的 DOMAIN-SUFFIX 可匹配目标域名及其子域名，例如 api.notion.so 会匹配 notion.so 后缀规则。它不等于“把所有可能关联的第三方服务都自动找出来”：登录提供方、图片存储或实时连接可能使用其他域名。发现具体请求被错误分流时，再按日志中的实际主机名增加规则，而不要凭猜测加入大范围云服务域名。

MATCH 是兜底规则，通常放在规则列表末尾。若原配置已有国内直连规则，应保留其原有顺序与策略；不要为了插入办公规则而删除整套规则集。新增的协作域名规则应放在会覆盖这些请求的宽泛规则之前。若前面已有命中范围很大的规则，规则顺序不当时，后面的办公域名规则可能永远不会被执行。

需要查阅规则类型和 DNS 字段时，可参考规则语法与DNS 配置。如果还不确定订阅如何导入或如何验证客户端是否实际使用新配置，可先查看订阅配置步骤。

在客户端应用配置并逐项验证

建议按“备份—编辑—检查—运行—验证”的顺序操作。不同客户端的菜单名称可能不同，但验证目标一致：新规则已加载、命中的策略组存在、请求确实经由预期路径转发。

  1. 在客户端定位当前启用的配置，导出或复制一份备份，记录当前运行模式和代理组选择。
  2. 通过客户端支持的覆写入口添加规则，或修改本地 YAML 中的 rules。确认缩进使用空格、列表项以短横线开头，且策略组名称与配置定义一致。
  3. 保存后应用配置或重载内核。打开日志查看配置解析结果；如果出现未知策略组、YAML 行号错误或规则字段错误，先修正并重新加载。
  4. 在客户端的「连接」或「日志」页面打开记录窗口，再分别访问 Notion、Figma、Miro。查看请求目标域名和匹配策略，确认协作域名命中预期代理组，而国内网站仍按原规则直连。
  5. 逐项检查登录、页面内容、图片与文件加载、编辑保存和实时协作。记录哪一步失败以及对应的目标域名，不要仅以首页能否打开作为验收。

连接记录可以帮助区分问题发生在哪一层。若目标请求显示命中 DIRECT，可能是规则没有加载、规则顺序不合适，或实际域名不在规则范围内；若命中代理组但连接失败，应进一步检查节点状态、域名解析和网络可达性。若根本没有看到相应请求，则问题可能发生在应用发起连接之前，例如登录状态、浏览器扩展或应用自身错误。

DNS 也会影响域名解析和连接，但不要因为网站异常就立刻更换所有 DNS 字段。先确认代理模式、规则命中和节点可用；随后再观察日志中的解析错误，并核对当前配置的 DNS 行为。若开了 TUN，额外检查虚拟网卡是否正常、系统中是否存在其他 VPN 或网络过滤软件。每次只改变一个变量，便于找出真实原因。

桌面版 Notion、Figma 或 Miro 与浏览器表现不同，可能是因为应用没有遵循 Windows 系统代理设置，也可能使用了额外的网络连接。先检查应用设置中是否提供代理选项，并用浏览器确认规则本身有效；确实需要接管未遵循系统代理的流量时，再单独测试 TUN。涉及公司 VPN、内网 DNS 或受管理设备时，先按组织网络要求确认兼容性，不要贸然覆盖企业路由。

根据日志补全规则，避免过度分流

规则覆盖不是越多越好。把整个云服务商、公共 CDN 或所有 HTTPS 流量都交给代理，可能让国内网站变慢，也会让问题更难定位。补规则时优先使用服务明确使用的域名后缀；如果日志只提供 IP 地址，不要随意把共享 CDN 的 IP 段整体加入代理规则，因为同一地址可能承载多个无关网站。

排查结果可能原因下一步
规则未命中，显示默认策略目标域名不在规则内，或更早规则已经匹配查看连接详情中的主机名，核对规则顺序并只补充必要域名
命中代理组但连接超时当前节点不可用、目标服务连接异常或 DNS 解析失败更换一个已验证节点做对照，查看同一时间的内核日志
网站主页面正常，某个功能失败功能请求使用其他域名，或实时连接受到网络限制在复现故障时查看连接记录，按实际域名定位，不盲目扩大规则
国内网站也进入代理宽泛规则覆盖范围过大，或规则顺序与预期不符恢复备份，检查规则匹配顺序和默认策略
改完规则后内核无法启动YAML 缩进错误、策略组名称不存在或覆写入口不兼容回退到备份，再按客户端支持的配置方式逐项重加

完成测试后，再用一次订阅更新确认本地规则没有被覆盖，并重新检查配置是否成功加载。可以保留一份简短记录：客户端和内核版本、规则修改日期、使用的策略组、验证过的服务功能，以及仍未解决的域名。以后节点或订阅变化时，这份记录能帮助区分是线路变化还是规则配置变化。

最终目标不是让所有协作应用都无条件走同一条线路，而是让需要代理的请求有明确规则，让国内网站继续使用原有直连逻辑，同时保留足够的日志信息用于复查。完成后可在连接验证步骤中继续核对系统代理与规则命中；如果需要更换或安装客户端，可前往客户端下载页查看适用版本。