Clash配置Notion、Figma与Miro高效协作实用指南

Notion、Figma 与 Miro 为什么需要单独设计 Clash 分流

Notion、Figma 与 Miro 都属于在线协作工具，但它们的网络行为并不完全相同。Notion 通常同时涉及工作区页面、登录授权、图片与文件附件、实时同步以及第三方字体或静态资源；Figma 除了网页端编辑器，还会建立实时协作连接、加载字体、读取团队资源，并可能使用桌面客户端或开发者模式；Miro 则经常在白板页面中持续加载图片、评论、嵌入内容与实时光标数据。把三个产品简单归为“国外网站”后全部交给同一个全局策略，虽然容易验证是否能打开，却会让国内办公网站、企业内网和视频会议流量也绕到代理节点，增加延迟和管理成本。

更稳定的做法是先把协作工具的访问意图拆出来，再决定哪些域名走代理、哪些域名保持直连。日常使用推荐采用 Clash 的规则模式，为 Notion、Figma、Miro 分别或合并建立清晰的策略组，例如 WORK_COLLAB。国内搜索、企业 OA、代码仓库镜像和局域网地址继续交给 DIRECT，协作平台的主域、登录域和实际日志中出现的静态资源域则进入同一个代理策略。这样做的重点不是堆积一份看似完整的域名清单，而是让连接日志能够回答三个问题：请求访问了什么主机、命中了哪条规则、最终使用了哪个出站。

还要区分“网页能打开”和“协作功能完整可用”。页面首页可能只需要普通 HTTPS 请求，但实时编辑常依赖长连接、WebSocket 或持续的分块传输。如果主页面走代理、实时通道却直连，表现通常不是完全打不开，而是评论延迟、光标不更新、协作者状态消失、白板内容保存缓慢，甚至在编辑几分钟后才弹出连接中断提示。因此分流验证必须包含实际工作动作，而不能只在浏览器地址栏输入产品首页。

客户端、系统代理与 TUN：先选对接入方式

使用 Clash Verge、Clash Verge Rev、Mihomo 或其他支持 Mihomo 内核的客户端时，最先要确认的是当前配置是否已经激活、内核是否正常运行，以及系统代理是否指向 Clash 的入站端口。浏览器通常会读取系统代理，所以“浏览器里的 Notion 能打开”并不能证明桌面客户端、插件、上传程序或命令行工具也一定经过 Clash。Figma 桌面端和 Miro 桌面端尤其值得单独验证，因为它们可能采用独立的网络栈，行为会受到系统代理、应用自身代理设置和操作系统权限的共同影响。

如果主要在浏览器中使用协作平台，开启系统代理加规则模式通常已经足够。若你需要覆盖桌面客户端、Electron 应用、开发工具插件或不读取系统代理的程序，可以考虑启用TUN 模式。TUN 会在更底层接管符合路由条件的流量，减少应用逐个配置代理的麻烦，但同时也会影响更多网络连接，必须提前规划局域网、企业 VPN、打印机、NAS 和办公内网的直连策略。不要把 TUN 当成“开启后所有问题自动消失”的开关；它解决的是流量接入问题，不能替代正确的规则、DNS 和节点选择。

在 Windows 上，开启 TUN 后应检查网卡是否成功创建、系统是否弹出管理员权限提示，以及 Clash 日志是否能看到 Figma 或 Notion 的连接。macOS 用户需要留意网络扩展或系统权限，部分客户端还会把增强模式、服务模式和 TUN 分成不同开关。Android 端则要确认 VPN 权限与电池后台限制，避免设备锁屏后代理服务被系统暂停。无论使用哪一种客户端，建议先在不启用 TUN 的情况下跑通系统代理，再逐步打开增强模式，这样排错时变量更少。

代理端口也要保持一致。Clash 的 mixed-port 可以同时接受 HTTP 与 SOCKS5 请求，适合多数桌面场景；若手动给某个应用填写端口，必须确认协议类型与端口实际对应。常见错误是把 SOCKS5 端口填入只接受 HTTP 代理的设置框，或者配置文件中的端口已经改变，应用仍指向旧端口。连接日志没有任何记录时，应先排查应用是否真的把流量交给 Clash，而不是立即更换节点。

Notion、Figma 与 Miro 的域名规则设计方法

规则设计可以采用“主域优先、日志补充”的顺序。对于官方主域，优先使用 DOMAIN-SUFFIX，它能够覆盖同一组织下的子域，维护成本低于逐条填写完整主机名。示例中的策略组名称仅供参考，必须结合你当前订阅中的实际组名替换；如果机场配置已经提供了“自动选择”或“海外服务”等策略，可以直接引用已有组，避免创建重复的节点池。

proxy-groups:
  - name: WORK_COLLAB
    type: select
    proxies:
      - 自动选择
      - 节点手动选择
      - DIRECT

rules:
  - DOMAIN-SUFFIX,notion.so,WORK_COLLAB
  - DOMAIN-SUFFIX,notion.site,WORK_COLLAB
  - DOMAIN-SUFFIX,figma.com,WORK_COLLAB
  - DOMAIN-SUFFIX,miro.com,WORK_COLLAB
  - DOMAIN-SUFFIX,mirostatic.com,WORK_COLLAB
  - GEOIP,LAN,DIRECT
  - MATCH,DIRECT

上面的片段不是可以无条件直接覆盖订阅的完整配置。Notion 的工作区可能使用自定义域名，Figma 的资源请求可能出现新的静态主机，Miro 的白板附件也可能由独立资源域承载。实际操作时打开 Clash 的连接日志，在登录、打开文件、邀请协作者、上传图片和刷新页面等动作之间观察新增请求。若主页面命中 WORK_COLLAB，但某个附件或实时连接仍命中 DIRECT，先记录该主机名，再判断它是否确实属于协作功能，而不是立即使用宽泛的关键词规则。

DOMAIN-KEYWORD 可以快速验证方向，却不适合长期作为主要规则。例如用关键词匹配“fig”可能误伤无关网站，也可能把企业内部名称相似的域名交给代理。长期配置应优先使用官方后缀、明确的完整域名和可维护的 Rule Provider。对于订阅会周期更新的用户，建议把本地自定义规则放在覆写文件或独立规则集内，而不是直接修改每次都会被远程配置覆盖的原始 YAML。

DNS 也会影响域名分流的结果。若启用了 fake-ip，某些需要局域网解析、企业内网访问或特殊证书校验的域名可能表现异常；若采用 redir-host，则要确认 DNS 请求本身没有被不合适的策略转发。遇到“页面偶尔打开、刷新后又失败”的情况，可以同时查看 DNS 解析日志与代理连接日志，判断是解析到了不可达地址，还是解析正常但出站握手失败。不要在没有证据时同时修改 DNS、规则和节点，否则很难知道真正有效的改动是什么。

四步验证协作链路，并保持规则可维护

1. 验证登录：退出当前账户后重新登录 Notion、Figma 或 Miro，观察授权页面、验证码、重定向和登录回调是否都能完成。若浏览器显示登录成功但应用仍停留在登录页，重点检查应用自身是否没有继承系统代理。
2. 验证核心页面：打开一个已有工作区、设计文件或白板，等待文字、图片、缩略图和字体加载完成。不要只测试首页，因为首页可用不代表文件资源域全部可用。
3. 验证实时协作：邀请另一台设备或同事进入同一文档，分别测试文字修改、评论、光标同步和撤销操作。如果变化要等待很久才出现，查看连接日志中是否有长连接失败、重复重试或规则命中直连的情况。
4. 验证文件操作：上传一张图片、导入一个附件或导出设计文件，观察进度是否稳定。上传和下载可能使用不同主机，必须分别记录，不要因为页面加载成功就跳过这一项。

测试时建议固定一个节点和一套规则，连续完成上述流程后再比较其他节点。若只更换节点而不改变规则，能够判断是线路质量问题；若只调整规则而保持节点不变，则更容易确认某个域名是否漏分流。对办公场景来说，稳定性通常比单次测速的最低延迟更重要。一个延迟稍高但长连接稳定的节点，往往比测速第一却频繁重连的节点更适合 Figma 多人编辑或 Miro 大型白板。

规则维护也应围绕真实变化进行。每隔一段时间查看连接日志，清理已经不再出现的临时域名，把长期稳定的域名移入规则集，并为策略组保留一个可手动切换的备用节点。国内网站、企业内网和局域网资源不要为了“保证能打开”而全部塞入代理；可以使用 GEOIP,CN,DIRECT、GEOIP,LAN,DIRECT 或你所在组织提供的专用域名规则，但要意识到地理库并不等于绝对准确，企业域名仍应以明确的自定义规则优先。

排障顺序建议：先确认应用是否进入 Clash，再看 DNS 是否正确解析，然后核对规则命中和策略组，最后才比较节点质量。只看到“Notion 打不开”就反复切换节点，往往会掩盖系统代理未生效、TUN 权限不足或资源域漏分流等更基础的问题。

相比只提供全局开关的简单代理工具，部分浏览器代理扩展无法覆盖 Figma、Miro 桌面端，也不容易统一处理实时连接、附件上传和国内办公网站直连；一些旧客户端的规则编辑与日志能力较弱，遇到半连接问题时只能凭感觉切换线路。Clash V.CORE 则能在规则模式、TUN 接管、策略组选择和连接日志之间建立完整的排障链，既能让 Notion、Figma、Miro 按需走稳定出站，也能保留国内网站与办公内网的直连效率。若你希望把本文的协作分流方案落地到 Windows、macOS、Android 或其他支持 Mihomo 的环境，可以前往下载页获取 Clash V.CORE，再按照“系统代理验证、最小规则集、四步协作测试”的顺序逐项配置。