迁移方案 预计阅读 11 分钟

Clash配置Notion、Figma、Miro：远程协作效率最优方案

针对远程办公和团队协作场景，本文介绍如何用Clash优化Notion、Figma与Miro的访问体验。通过应用分流、规则集和节点策略，让设计、文档与白板工具稳定运行，同时避免国内流量绕行代理。

先明确协作工具的分流目标

Notion、Figma 和 Miro 都属于典型的远程协作工具，但它们的网络行为并不完全相同。Notion 主要涉及文档页面、同步接口、图片与文件附件；Figma 同时包含网页编辑器、实时协作连接、字体资源和设计文件加载；Miro 则大量依赖白板数据同步、实时连接以及图片、视频和模板资源。只把三个网站的首页加入代理规则，往往只能解决登录或页面打开问题，进入工作区后仍可能出现加载缓慢、协作者状态不更新、画布资源缺失等现象。

比较稳妥的目标不是“所有流量都走代理”，而是让协作工具相关请求稳定使用代理，同时让国内网站、企业内网、打印机、局域网设备和常用国内服务保持直连。这样可以减少不必要的延迟、降低代理节点带宽消耗，也避免访问国内办公系统时因为出口地址变化触发额外验证。

工具 主要网络特征 常见异常 分流重点
Notion 网页、API、附件与图片资源 页面空白、图片不显示、同步延迟 主站、API、静态资源和附件域名
Figma 网页编辑器、实时协作、字体与资源服务 文件打不开、协作状态断开、字体加载失败 主站、实时连接、资源域名和桌面端代理
Miro 白板数据、实时同步、模板与媒体资源 白板加载慢、光标不同步、模板无法打开 主站、实时接口、静态资源和媒体域名

准备一个专用策略组

建议为远程协作工具建立独立的策略组，不要直接把规则写成固定节点。固定节点可能因为线路拥堵、地区限制或服务端维护而失效；独立策略组则可以在多个节点之间手动切换，或者使用 url-test 根据测试结果选择延迟较低的节点。策略组名称可以使用 Work-Tools、协作工具 等容易识别的名称。

proxy-groups:
  - name: Work-Tools
    type: select
    proxies:
      - Auto-Work
      - 节点选择
      - DIRECT

  - name: Auto-Work
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    proxies:
      - 节点A
      - 节点B
      - 节点C

上面的测试地址只能反映节点访问该地址时的连通性，不能代表 Notion、Figma 或 Miro 的实际体验。如果节点对某些服务存在区域限制，仍需要在工具实际打开后观察连接日志。办公场景更重视持续稳定、丢包率和长连接保持时间，不应只按一次测速结果选择节点。

为 Notion、Figma 与 Miro 建立规则

规则应尽量使用域名后缀匹配，并放在通用直连规则之前。以 mihomo 为例，DOMAIN-SUFFIX 会匹配指定域名及其子域名，适合处理同一服务下不断变化的 API、静态资源和附件主机。不要只写一个具体的完整域名，否则资源切换到新的子域名后可能再次出现加载失败。

rules:
  - DOMAIN-SUFFIX,notion.so,Work-Tools
  - DOMAIN-SUFFIX,notion.site,Work-Tools
  - DOMAIN-SUFFIX,notion-static.com,Work-Tools
  - DOMAIN-SUFFIX,api.notion.com,Work-Tools

  - DOMAIN-SUFFIX,figma.com,Work-Tools
  - DOMAIN-SUFFIX,figmausercontent.com,Work-Tools
  - DOMAIN-SUFFIX,figma.site,Work-Tools

  - DOMAIN-SUFFIX,miro.com,Work-Tools
  - DOMAIN-SUFFIX,mirostatic.com,Work-Tools

  - GEOIP,LAN,DIRECT
  - GEOSITE,cn,DIRECT
  - MATCH,DIRECT

示例中的域名用于说明规则结构，实际使用时应以当前客户端连接日志为准。服务商可能调整资源域名、接入 CDN 或把实时服务迁移到新的主机。尤其是 Figma 和 Miro 的资源请求，不能仅凭主页域名推断所有依赖项。登录后打开一个实际文件或白板，观察失败请求的主机名，再将确认属于该服务的域名加入规则。

规则顺序比规则数量更重要

Clash 规则通常从上到下匹配，命中第一条后就停止继续判断。如果把 GEOSITE,cn,DIRECT、GEOIP,CN,DIRECT 或某个宽泛的 DOMAIN-KEYWORD 规则放在协作工具规则之前，相关请求可能还没有到达代理规则就被直连。反过来，如果把过宽的域名关键词规则放在前面，也可能把与协作工具无关的国内网站一并送入代理。

DNS、实时连接与 TUN 的配合方式

规则写对后仍然打不开，常见原因是 DNS 解析路径与代理路径不一致。系统先通过本地 DNS 得到一个被污染、不可达或地区不合适的地址，Clash 再把连接交给代理，也可能导致握手失败。对于需要稳定访问的海外协作工具，DNS 配置应与分流策略保持一致，并避免在同一配置中混用互相矛盾的 fake-ip、直连解析和远程解析行为。

如果主要使用浏览器和支持系统代理的桌面软件，可以先从系统代理模式开始。常见的混合代理端口是 127.0.0.1:7890，但必须以当前配置的 mixed-port 为准。控制端口例如 127.0.0.1:9090 只用于客户端控制和状态查询，不能填入浏览器的 HTTP 或 SOCKS 代理设置。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

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

这段配置只能作为结构示例，DNS 服务地址、网络可达性和客户端支持情况需要结合实际环境调整。某些企业网络会拦截 DoH，某些校园网或办公网要求使用指定 DNS；如果启用后所有域名都解析失败，应先恢复原有 DNS，再逐项测试，而不是继续增加 nameserver。

什么时候需要启用 TUN

如果只在浏览器中使用 Notion、Figma 和 Miro，系统代理通常足够。Figma 桌面端、Miro 桌面端、命令行工具或某些内嵌运行时不一定完整读取系统代理；当日志显示浏览器有请求、桌面应用却完全没有连接记录时，才需要考虑 TUN。TUN 通过虚拟网卡接管更底层的 IP 流量，能够覆盖不遵循系统代理的程序，但也会扩大影响范围。

实时协作通常依赖长连接，可能使用 WebSocket 或其他持续连接机制。规则命中代理并不等于长连接一定稳定：节点丢包、代理服务端超时、UDP 受限以及浏览器扩展拦截，都可能让 Figma 的多人光标、Miro 的白板状态或 Notion 的同步提示反复断开。测试时应保持一个文件或白板打开至少 5 到 10 分钟，并观察是否出现重连，而不是只检查首页能否打开。

客户端设置与完整验证流程

在 FlClash 或其他支持 mihomo 的客户端中，建议先导入订阅，再通过配置覆写或本地配置增加策略组和规则。不要直接修改订阅生成的原文件，因为下一次更新可能覆盖手动修改。若客户端提供“覆写”“Mixin”“配置补丁”或“扩展配置”入口，应将自定义的 proxy-groups、rules 和 DNS 内容放在可重复应用的位置，并确认覆写执行顺序。

推荐的验证顺序

  1. 确认核心状态：检查 mihomo 是否正常运行、混合端口是否监听，以及客户端是否显示当前配置已加载。
  2. 确认策略组：在代理页面找到 Work-Tools，先手动选择一个稳定节点，不要一开始就使用自动测速。
  3. 检查规则命中：打开 Notion 页面、Figma 文件和 Miro 白板，在连接或日志页面搜索对应域名，确认策略显示为 Work-Tools。
  4. 检查静态资源：滚动页面、打开图片、导出一个小文件或加载模板，确认资源域名没有被错误地分配到 DIRECT。
  5. 检查实时协作：邀请同事同时编辑，观察光标、评论、版本状态和白板对象是否持续同步。
  6. 检查国内直连：打开企业 OA、国内搜索、银行或本地 NAS，确认这些连接没有意外经过代理。
现象 优先检查项 处理方向
主页打不开 DNS、主域名规则、节点可用性 确认域名解析结果和代理连接错误
主页能开，文件或白板打不开 静态资源、API、附件域名 查看日志并补充明确的域名后缀规则
多人协作不断断线 长连接、丢包、节点稳定性 切换节点并进行持续连接测试
浏览器正常，桌面端失败 桌面端是否读取系统代理 检查应用代理设置，必要时启用 TUN
国内办公系统变慢 规则顺序、GEOIP 与局域网规则 把国内和内网规则放在默认代理规则之前

通过日志而不是猜测补规则

打开客户端的连接记录后，先清空旧日志，再只操作一个工具。例如先刷新 Notion 页面并打开一张图片，记录新增的域名及其策略；然后关闭页面，单独打开一个 Figma 文件，最后测试 Miro 白板。这样可以把不同服务的请求分开。对于陌生域名，不要因为名称中出现 cloud、static 或 cdn 就立即加入代理，应结合请求来源、响应结果和实际功能确认。

完成验证后，可以把节点策略从手动选择改为自动选择，并保留一个稳定节点作为故障切换。远程协作日常最重要的是可预测性：规则少而明确、国内流量不绕行、工作时段节点不频繁切换、TUN 只在确有必要时启用。按照“先系统代理、再专用规则、最后 TUN”的顺序配置，通常比直接打开全局代理更容易获得稳定且可维护的工作体验。

FlClash 下载入口 查看各平台客户端