Clash配置Notion、Figma与Miro：远程协作效率优化指南

先明确目标:只代理协作平台相关流量

Notion、Figma 与 Miro 都属于典型的远程协作服务。页面打开时,除了主站 HTML,还会请求静态资源、字体、图片、实时协作接口、文件上传接口以及身份验证服务。只把浏览器首页切到代理并不能保证这些请求全部走同一条链路,也不能解决国内网站被误送到代理节点的问题。

更稳妥的方案是使用 Clash 的规则模式:国内办公系统、企业内网、即时通信和本地开发服务保持直连;协作平台的主域名及相关资源域名统一交给一个“协作办公”策略组;其他没有明确归类的境外请求再进入通用代理组。这样做的价值不只是打开速度更快,还可以让 Figma 文件同步、Miro 白板实时编辑和 Notion 页面保存使用稳定的出口。

本文示例以 mihomo 内核为基础,适用于 Clash Verge、Clash Verge Rev 以及其他支持 Clash Meta 配置格式的客户端。不同客户端的菜单名称可能略有差异,但配置文件中的 proxy-groups、rules、tun 和 dns 结构基本一致。原版 Clash 不支持部分新字段时,应先确认客户端使用的内核版本。

代理组规划:把三个平台单独收口

不要把 Notion、Figma 和 Miro 的规则直接指向某个固定节点。节点名称经常随着订阅更新而改变,固定名称失效后会出现规则命中但无法连接的情况。更好的做法是新增一个策略组,让它包含节点选择、自动测速和故障切换三种能力,规则只引用这个策略组的名称。

下面是一段可直接作为结构参考的配置。节点选择、自动测速、故障切换 是示例策略组名称,需要替换成你的配置中真实存在的组名。若订阅已经提供“全部节点”或“自动选择”组,可以直接把现有组填入协作组的 proxies 列表。

proxy-groups:
  - name: 协作办公
    type: select
    proxies:
      - 自动测速
      - 节点选择
      - 故障切换
      - DIRECT

  - name: 自动测速
    type: url-test
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

  - name: 故障切换
    type: fallback
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 300

select 适合需要手动指定地区或节点的场景。Figma 与 Miro 的实时连接通常更在意稳定性,手动选择一个延迟不低但丢包少的节点,可能比频繁切换节点更好。url-test 会定期测试节点并选择延迟较低的出口,适合日常浏览和资源加载。fallback 更看重可用性,当前节点无法通过测试时才切换备用节点。

测速地址只用于测试节点是否能够建立连接,不代表它与协作平台的实际线路完全相同。测试间隔不建议设置得过短,例如 interval: 30 会产生频繁探测和节点切换。日常使用可从 300 秒开始,如果会议、评审或多人协作期间不希望切换出口,则手动固定节点更稳。

• Notion: 页面文字和数据库请求较多,优先选择延迟稳定、丢包较低的节点。
• Figma: 文件资源、缩略图和实时编辑连接并存,优先选择上行速度稳定的节点。
• Miro: 白板同步依赖持续连接,频繁更换出口可能导致重新连接或编辑状态刷新。

规则细化:主站、资源与实时连接一起覆盖

协作平台加载缓慢,经常不是主页面无法打开,而是某个静态资源、图片存储或实时接口没有命中代理规则。仅添加一个主域名规则通常不够。实际配置应优先使用官方文档列出的主域名后缀和服务域名,并把它们分别写成 DOMAIN-SUFFIX 规则。

以下配置使用保留的示例域名表示法,避免把不确定的第三方资源域名直接写进配置。使用时,请将示例后缀替换为服务商当前公布的真实域名;不要凭猜测批量添加关键词,否则可能把同名的国内站点或无关资源一并送进代理。

rules:
  - DOMAIN-SUFFIX,notion.example,协作办公
  - DOMAIN-SUFFIX,figma.example,协作办公
  - DOMAIN-SUFFIX,miro.example,协作办公

  - DOMAIN-SUFFIX,notion-static.example,协作办公
  - DOMAIN-SUFFIX,figma-static.example,协作办公
  - DOMAIN-SUFFIX,miro-static.example,协作办公

  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

DOMAIN-SUFFIX 会同时匹配主域名和它的子域名,适合覆盖登录、静态资源与接口入口。DOMAIN 只匹配一个精确域名,适合你已经确认某个固定接口必须代理的情况。DOMAIN-KEYWORD 会匹配域名中出现的关键词,误伤范围较大,不建议把“figma”“notion”这类短词直接写成主规则。

如果配置使用了 mihomo 的规则集,可以把协作平台域名维护成独立的 rule-provider,后续只更新规则集而不改主配置。规则集的核心仍然是域名后缀,不能因为使用了远程规则集就忽略匹配顺序。协作规则必须放在通用兜底规则之前,而 MATCH 必须放在整个列表最后。

规则顺序与国内服务共存

建议的顺序是:局域网和本机地址直连,明确拦截规则靠前,协作平台规则随后,国内域名与国内 IP 规则接着处理,最后进入通用代理。若把 GEOSITE,cn,DIRECT 放在协作平台规则前面,某些平台的登录或资源域名一旦被 geosite 数据标记为国内,就会提前直连,导致同一页面中的不同请求走了两条线路。

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

  - DOMAIN-SUFFIX,notion.example,协作办公
  - DOMAIN-SUFFIX,figma.example,协作办公
  - DOMAIN-SUFFIX,miro.example,协作办公

  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

内网规则中的 no-resolve 可以避免 Clash 为了匹配 IP 网段而额外解析域名。若企业内网使用特殊后缀,例如内部 DNS 才能解析的域名,应增加对应的 DOMAIN-SUFFIX 直连规则,否则 fake-ip 或代理 DNS 可能让内网服务无法访问。

DNS 与 TUN:解决资源能开但协作异常

当 Notion 主页面能打开,但图片迟迟不显示,Figma 缩略图空白,或者 Miro 白板一直显示正在连接时,问题可能不在规则本身,而在 DNS 或应用流量没有真正进入 Clash。系统代理只接管遵循 HTTP 或 SOCKS 设置的应用,部分桌面客户端、命令行工具和实时连接可能绕过系统代理。

在 mihomo 内核中,可以先使用较保守的 DNS 配置,让需要分流的域名由 Clash 统一解析。fake-ip 模式适合规则分流,因为 Clash 可以保留原始域名并在连接阶段匹配规则;局域网域名和本地设备则应放入 fake-ip-filter。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.internal"
  respect-rules: true
  nameserver:
    - https://192.0.2.53/dns-query
  fallback:
    - tls://192.0.2.54:853
  fallback-filter:
    geoip: true
    geoip-code: CN

示例中的解析地址是文档保留地址,不能直接当作生产 DNS 使用。请换成当前网络可达、并且符合服务商要求的真实 DNS 上游。respect-rules: true 会让 DNS 查询参考分流规则,避免所有域名都用同一条解析路径。若开启后出现启动慢或循环解析,先检查 DoH/DoT 上游的域名解析依赖,并为代理服务器域名配置可用的 proxy-server-nameserver。

需要整机接管时开启 TUN

如果 Figma 桌面客户端、Miro 桌面客户端或命令行上传工具仍然不遵守系统代理,可以在客户端设置里开启 TUN。Windows 通常需要服务模式或管理员权限,macOS 需要允许网络扩展,Linux 需要相应的路由权限。先确认普通规则模式稳定,再开启 TUN,这样更容易判断问题来自权限还是规则。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

TUN 开启后,所有应用的连接都会经过虚拟网卡,包括不读取系统代理的程序。dns-hijack 用于把发往 53 端口的 DNS 查询交给 Clash,可减少应用绕过客户端直接使用系统 DNS 的情况。若局域网打印机、NAS 或企业 VPN 出现异常,先临时关闭 TUN 做对照,再通过 fake-ip 过滤、局域网直连规则或 VPN 路由设置逐项恢复。

验证与优化:用可重复的方法比较效果

配置完成后不要只凭一次打开速度判断好坏。协作平台会缓存静态文件,第一次打开慢、第二次打开快并不一定代表代理线路改善。建议关闭页面后重新启动客户端,分别在规则模式、指定协作节点和临时全局模式下测试,每次记录相同操作所需时间。

1. 确认 Clash 当前配置已启用,模式设置为“规则”,协作策略组已经选择一个可用节点。
2. 打开连接日志,访问一个 Notion 页面、一个 Figma 文件和一个 Miro 白板,记录主域名、资源域名与实时连接是否命中“协作办公”。
3. 观察首屏加载、图片或缩略图出现、文件编辑同步、白板成员状态更新四个阶段,不要只看页面是否最终打开。
4. 切换两个不同地区或不同线路的节点,每个节点至少测试两次,排除偶然的缓存和瞬时拥塞。
5. 恢复国内网站与企业内网测试,确认规则没有把内部系统、代码仓库、网盘或视频会议服务误送到代理。

• 加载慢但日志显示代理命中:优先更换节点或地区,再检查出口带宽、丢包和连接复用,不要立刻增加更多域名规则。
• 主页面正常但图片缺失:查看日志中是否出现独立的静态资源域名,将确认属于该平台的资源后缀补充到协作组。
• 编辑时频繁断线:固定一个稳定节点,关闭过短的自动测速间隔,并确认 TUN 没有与其他 VPN 或网络加速器同时运行。
• 只有桌面客户端异常:开启 TUN 做对照;如果 TUN 后恢复,说明原应用没有遵守系统代理,不是域名规则失效。
• 国内网站变慢:检查 GEOSITE,cn,DIRECT 和 GEOIP,CN,DIRECT 是否仍在协作规则之后、通用兜底之前。

协作场景不适合盲目追求最低延迟。实时编辑更怕丢包和重连,一个延迟略高但连接稳定的节点,通常比延迟很低却频繁切换的节点更适合长时间工作。可以先用 select 固定节点完成重要评审或交付,日常浏览再切回 url-test 自动选择。

最终检查清单:稳定共存而不是全量代理

一份可长期使用的协作配置,应当具备清晰的出口、有限的规则范围和可回滚的排查路径。规则只覆盖已经确认的协作平台域名,不要为了“保险”加入大量关键词;策略组只负责选择线路,不要把复杂的域名判断混在策略组里;DNS 与 TUN 则分别负责解析接管和应用流量接管。

• 协作平台规则位于国内直连规则之前,通用 MATCH 位于最后。
• Notion、Figma、Miro 的主域名、静态资源域名和实时接口域名经过日志确认后再添加。
• 协作策略组至少保留手动选择和自动测速两种方式,重要工作期间固定稳定节点。
• DNS 使用 Clash 模块统一处理,局域网和企业内部域名加入 fake-ip 过滤或直连规则。
• 桌面客户端绕过系统代理时,再启用 TUN,并避免与其他 VPN、代理软件重复接管。
• 每次修改后执行配置检查,重启或重新加载配置,再通过连接日志确认实际命中结果。

完成这些步骤后,办公协作流量会进入独立策略组,国内服务仍然保持直连,其他流量则按原有规则处理。遇到平台改版或资源域名变化时,先从连接日志定位未命中的域名,只补充必要规则,不要直接切换全局模式作为长期方案。