Clash配置Notion、Figma、Miro：高效工作流优化指南

先拆清 Notion、Figma、Miro 的真实网络需求

Notion、Figma、Miro看起来都是浏览器里的在线协作工具，但它们在网络层面的请求并不完全相同。Notion 需要加载工作区页面、图片、文件附件、搜索索引以及实时编辑连接；Figma 除了打开设计文件，还会频繁同步缩略图、字体、评论、多人光标和版本数据；Miro 则更依赖白板资源、实时协作通道、图片上传和团队邀请链接。只给三个官网首页配置代理，往往只能解决「页面能打开」，却不能保证文件加载、编辑同步和评论通知都稳定。

Clash 分流的核心不是把所有国外网站粗暴地切换到全局代理，而是根据业务域名、连接类型和使用场景建立清晰的策略意图。国内办公平台、企业内网、网银和本地服务通常应该保持直连；Notion、Figma、Miro 及其实际使用到的静态资源和协作接口，则交给稳定的代理组。这样做可以减少无关流量占用节点，也能避免企业内网因为代理出口变化而出现登录、文件访问或安全校验异常。

ℹ 先记录再写规则：不要完全依赖网上复制的域名清单。打开 Clash 的连接日志，分别启动 Notion、Figma 和 Miro，执行打开工作区、加载大文件、发送评论、上传图片等动作，记录真实出现的 Host，再把重复出现的域名归纳到对应规则集中。

建议先定义三个层次的策略组。第一层是一个稳定的协作工具组，供 Notion、Figma、Miro 共同使用，便于统一切换节点；第二层是一个办公代理组，用于其他需要境外连接的服务；第三层保留机场原有的自动选择或故障转移组，作为上层策略的成员。这样在日常工作中只需要切换「COLLABORATION」组，而不必逐个修改三款应用的规则。若 Figma 大文件同步对延迟更敏感，也可以单独建立「FIGMA_SYNC」组，但不要一开始就把所有域名拆成十几个难以维护的组。

代理组与规则集：让三款工具可维护地分流

在 Mihomo 或其他兼容 Clash 配置的内核中，代理组负责决定出站方式，rules 负责把请求交给正确的组。对于远程办公场景，建议使用有明确含义的英文组名，避免机场订阅更新后出现中文符号、重复名称或引用失效。下面的示例只是结构参考，节点名称必须替换为你当前配置中真实存在的名称，域名也应以连接日志和官方服务实际请求为准。

协作工具策略组示例

proxy-groups:
  - name: COLLABORATION
    type: select
    proxies:
      - AUTO
      - HK-01
      - JP-01
      - DIRECT

  - name: FIGMA_SYNC
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    proxies:
      - HK-01
      - JP-01
      - SG-01

rules:
  - DOMAIN-SUFFIX,notion.so,COLLABORATION
  - DOMAIN-SUFFIX,notion.site,COLLABORATION
  - DOMAIN-SUFFIX,figma.com,COLLABORATION
  - DOMAIN-SUFFIX,miro.com,COLLABORATION
  - MATCH,DIRECT

select适合需要人工控制的工作组。你可以在早上选择延迟稳定的节点，遇到 Figma 导出或 Miro 上传异常时，再临时切换其他线路。url-test更适合节点质量变化明显的环境，但探测延迟并不等于真实的文件同步速度，因此不要把测速结果当成唯一判断标准。对于经常开大型 Figma 文件的用户，可以先让常用节点进入自动测试组，再观察连接日志中的握手耗时、下载速度和长连接是否中断。

规则优先级非常重要。更具体的域名规则应该放在宽泛规则之前，国内直连规则也不能放在一个会提前匹配的通用代理规则后面。若订阅已经提供了大量远程规则集，建议使用规则集完成大类匹配，再用少量本地规则修正特殊域名，而不是把订阅中的全部规则复制到本地。这样既能减少配置冲突，也能在服务商更新规则时继续获得维护。

规则集与本地覆盖的思路

rule-providers:
  WORK_COLLAB:
    type: http
    behavior: classical
    url: https://example.com/rules/work-collab.yaml
    path: ./ruleset/work-collab.yaml
    interval: 86400

rules:
  - RULE-SET,WORK_COLLAB,COLLABORATION
  - DOMAIN-SUFFIX,notion.so,COLLABORATION
  - DOMAIN-SUFFIX,figma.com,COLLABORATION
  - DOMAIN-SUFFIX,miro.com,COLLABORATION
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

这里的规则集地址只是占位示例，不建议直接使用未知来源的远程文件。更稳妥的做法是先确认规则内容、更新频率和维护者，再将其纳入配置。对于团队办公电脑，尤其要避免把整个DOMAIN-SUFFIX,com或DOMAIN-KEYWORD,work交给代理，否则会误伤大量无关站点。规则应该表达业务范围，而不是表达模糊的「看起来像国外服务」。

DNS、实时连接与文件同步：解决能开页面却不能协作

Notion、Figma 和 Miro 的常见故障，很多并非规则完全错误，而是DNS 解析路径与代理路径不一致。例如设备先通过本地网络解析出一个区域不合适的地址，Clash 再把连接交给代理；或者浏览器访问主站走了代理，但某个静态资源域名被系统 DNS 解析后直连。结果通常表现为页面外壳可以打开，图片一直转圈，评论发送失败，协作光标不更新，或者大文件加载到一半突然停住。

如果你使用的是 Mihomo，建议先理解当前配置的 DNS 模式、增强模式和 fake-ip 例外列表，再决定是否修改。不要在不了解局域网设备依赖的情况下直接开启严格的 fake-ip，打印机、NAS、公司内网域名和本地开发服务可能因此无法访问。更稳妥的排查顺序是：先确认目标域名被哪条规则命中，再确认 DNS 查询是否由 Clash 接管，最后观察代理连接是否能持续建立。

DNS 配置参考片段

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

上面的服务器只是示意，实际应结合网络环境、隐私要求和客户端支持情况选择。若开启 TUN，系统中不读取浏览器代理设置的应用也能被统一接管，适合 Figma 桌面端、Miro 桌面端、Electron 应用以及文件同步辅助进程。但 TUN 并不会自动修复所有问题：公司 VPN、虚拟机网卡、Docker 网络和安全软件可能与自动路由冲突。遇到内网地址打不开时，应先检查路由表和 TUN 排除项，而不是立刻更换节点。

对实时协作工具来说，短连接网页请求与长连接并不等价。页面首屏可能只需要几秒钟的 HTTP 请求，而多人编辑、评论推送和光标同步可能依赖持续时间更长的 WebSocket 或其他实时通道。若日志显示连接建立后周期性重置，可以先固定一个稳定节点，关闭自动切换，连续使用半小时观察；如果固定节点稳定而自动组频繁断开，问题更可能出在测速策略或节点切换，而不是域名规则。

文件同步还应单独验证。打开一个包含大量图片或组件的 Figma 文件，等待缩略图和字体全部完成；在 Miro 中创建便签、上传图片并刷新页面；在 Notion 中打开含附件的页面、编辑内容后从另一台设备检查是否同步。每项测试都要同时查看 Clash 日志，确认请求没有在代理组和直连之间来回跳转。只有「网页能打开、资源能加载、编辑能保存、刷新后数据仍在」四项都通过，才算完成有效配置。

多设备同步与远程办公验证流程

远程办公通常不是一台电脑独立工作：你可能在 Windows 笔记本上使用 Figma，在 macOS 台式机上整理 Notion，再通过 Android 或 iPhone 查看 Miro 白板。不同客户端对系统代理、TUN、证书和 DNS 的支持并不相同，因此不要简单地把一份完整配置文件复制到所有设备。更好的方法是统一策略组名称、规则意图和节点分层，再根据设备能力调整入站端口、TUN 开关与 DNS 设置。

桌面端优先采用规则模式，并为浏览器和原生客户端保持相同的协作策略组。若应用不遵循系统代理，可在 Clash Verge、Clash Verge Rev 或 Mihomo 中启用 TUN；启用前先确认管理员权限、虚拟网卡状态以及本地 VPN 是否会争用默认路由。移动端则要留意电量、后台限制和 Wi-Fi 与蜂窝网络切换，避免为了短时间查看白板而一直运行高耗能的全局代理。

配置同步时不要把订阅链接、访问令牌和个人工作区信息直接放进公开仓库。可以同步脱敏后的 YAML 模板，只保留组名、规则结构和注释；节点列表、订阅地址与私有规则通过密码管理器或受控文件单独分发。若团队共用一份配置，应明确谁负责更新规则集、谁负责验证节点、谁负责回滚错误版本。这样当 Notion 或 Figma 的域名结构发生变化时，团队不会因为每个人各自修改一份文件而出现不同步的故障。

建议建立一套固定的验收清单。第一步，在规则模式下确认国内办公系统、公司内网和常用支付服务仍然直连；第二步，分别打开 Notion、Figma、Miro 的登录页与工作区；第三步，完成一次搜索、评论、图片上传和页面刷新；第四步，切换到备用节点重复关键动作；第五步，关闭 Clash 后确认哪些失败属于预期代理依赖，哪些失败反而暴露了应用自身缓存或账号问题。每次修改规则后只改变一个变量，并保存修改前后的配置版本，排障效率会明显高于同时更换 DNS、节点和 TUN 模式。

页面加载慢：检查首个 HTML 请求、静态资源域名和 DNS 解析是否命中同一策略意图。
实时协作中断：固定节点，观察长连接持续时间，排除自动切组造成的连接重建。
文件上传失败：在日志中查找上传接口或对象存储域名，不要只检查官网主域。
国内服务异常：检查 GEOIP、局域网排除项和公司 VPN 路由是否被 TUN 接管。
多设备结果不同：比较各设备的内核版本、规则模式、DNS 模式与代理组选择。

与只开启全局代理的传统做法相比，全局模式虽然上手快，却容易让国内办公系统、局域网资源和企业安全验证受到影响；一些仅依赖浏览器扩展的方案又无法覆盖 Figma、Miro 原生客户端和后台同步进程，遇到长连接时也缺少统一日志。Clash V.CORE 可以把 Notion、Figma、Miro 的域名规则、代理组、DNS 与 TUN 接管放在同一套可观察的工作流中，既保留国内流量直连，也方便在连接日志里定位具体故障。若你希望把这套协作分流方案稳定地部署到多台设备，可以前往下载 Clash V.CORE，再按本文的验证顺序逐项迁移和确认。

先拆清 Notion、Figma、Miro 的真实网络需求

代理组与规则集：让三款工具可维护地分流

DNS、实时连接与文件同步：解决能开页面却不能协作

多设备同步与远程办公验证流程

Clash V.CORE — 规范退出系统代理与 TUN，少留残留