Clash配置Notion、Figma、Miro：设计协作效率优化指南
在日常使用中，我们经常会遇到只有 PC 端开启了代理，但手机、电视盒或其他移动设备也需要科学上网的情况。通过 Clash Verge Rev 的「允许局域网连接（Allow LAN）」功能，你可以轻松地将电脑的代理网络共享给同一 Wi-Fi 下的所有设备。本文将手把手带你完成从软件开关到 Windows 防火墙策略的完整配置流程。
为什么 Notion、Figma、Miro 需要单独优化分流
Notion、Figma 和 Miro 经常同时出现在同一个工作流中：Notion 用来记录需求、会议纪要和项目进度，Figma 负责界面设计与原型协作，Miro 则承担头脑风暴、用户旅程和远程白板任务。它们看起来都是网页应用，但实际连接的域名、静态资源、实时通信接口和文件存储服务并不相同。只为某个主域名添加代理规则，往往只能打开首页，图片加载、评论同步或实时画布仍然会卡住。
这类问题通常表现为「页面能打开，但使用体验不稳定」。例如 Notion 页面文字已经显示，图标和附件却迟迟不出现；Figma 可以进入文件列表，但画布中的字体、图片或组件加载失败；Miro 能打开白板，却无法及时看到其他成员的光标和编辑内容。原因可能是部分请求走了直连、DNS 解析结果不一致、WebSocket 连接被错误分流，也可能是当前节点到协作平台 CDN 的线路质量不足。
因此，Clash 配置的重点不是简单地把所有流量切换到代理，而是建立一套「协作平台走代理、国内办公服务保持直连、局域网资源不受影响」的规则。这样既能改善 Notion、Figma、Miro 的访问稳定性，也不会让企业邮箱、国内网盘、视频会议或内部系统平白增加延迟。
小提示
先在 Clash 的连接日志中观察实际请求域名，再决定规则范围。不要只根据浏览器地址栏里的域名猜测全部依赖服务，也不要一开始就使用 Global 全局模式，否则很难判断问题究竟来自规则、节点还是本地网络。
配置前的准备：客户端、节点与测试方法
本方案适用于 Clash Verge、Clash Verge Rev、Mihomo 以及其他支持规则组和 YAML 配置的客户端。不同客户端的菜单名称可能略有差异，但核心概念基本一致：Profiles 或配置文件负责加载订阅，Proxies 或代理页面负责选择节点，Rules 页面用于检查匹配结果，Logs 或连接面板则用于定位请求是否按照预期转发。
开始前建议准备一个有效的 Clash 订阅链接，并选择一个对海外 SaaS 平台访问稳定的节点。节点延迟并不是唯一指标：协作平台经常需要持续下载字体、缩略图和项目资源，因此丢包率、TLS 握手速度和长连接稳定性同样重要。可以分别打开一个 Notion 页面、一个 Figma 文件和一个 Miro 白板，记录首屏打开时间、图片加载情况以及编辑同步是否连续，后面每次调整规则都用相同页面复测。
配置清单
- Clash 客户端：建议使用仍在维护、支持 Mihomo 或兼容内核的图形客户端。
- 有效订阅：确认订阅中包含可用节点，并且节点协议与当前内核兼容。
- 规则模式：日常办公优先选择
Rule，不要长期使用Global。 - 测试页面：准备一个含图片、评论、嵌入内容或多人协作记录的真实项目。
导入订阅后，先确认 Clash 能正常启动并显示节点列表，再开启系统代理。Windows 用户可检查 System Proxy 和 TUN 是否重复启用；macOS 用户要留意系统代理、网络扩展与其他 VPN 工具的冲突；Android 用户则应检查电池优化是否会在后台暂停 Clash。若电脑上同时运行多个代理客户端，建议只保留一个程序接管系统代理，避免端口占用和规则链路混乱。
代理模式方面，Rule 更适合日常办公：国内域名匹配 DIRECT，协作平台匹配指定代理组，未命中的请求再交给兜底策略。只有在排查规则是否生效时，才适合临时切换到 Global 做对照测试。测试结束后应切回规则模式，否则国内服务可能绕远路，上传下载和内部系统访问都会变慢。
Notion、Figma、Miro 的分流规则设计
规则设计建议遵循「先具体、后通用；先平台、后兜底」的顺序。平台专用规则应放在通用的 GEOIP、MATCH 或 FINAL 规则之前，否则请求可能提前被判定为直连。下面的示例使用常见的策略组名称，你需要根据自己的配置文件把 Work-Proxy 替换为实际存在的代理组。
proxy-groups:
- name: Work-Proxy
type: select
proxies:
- Auto
- Singapore
- Japan
- DIRECT
rules:
- DOMAIN-SUFFIX,notion.so,Work-Proxy
- DOMAIN-SUFFIX,notion.site,Work-Proxy
- DOMAIN-SUFFIX,figma.com,Work-Proxy
- DOMAIN-SUFFIX,figmausercontent.com,Work-Proxy
- DOMAIN-SUFFIX,miro.com,Work-Proxy
- DOMAIN-SUFFIX,mirostatic.com,Work-Proxy
- GEOIP,CN,DIRECT
- MATCH,Work-Proxy
Notion 的核心域名通常包括 notion.so 和用于公开页面的 notion.site。如果团队使用自定义域名发布 Notion 页面，不能只依赖这两个后缀，还应在日志中查找页面实际请求的域名。Notion 的图片、附件和导出文件可能来自独立的 CDN 或对象存储域名，遇到「正文正常但附件打不开」时，重点观察这些请求是否被误判为 DIRECT。
Figma 除了主站 figma.com，还常见 figmausercontent.com 等资源域名。设计文件中的图片、头像、缩略图和字体加载失败时，往往不是 Figma 主页面的问题，而是资源域名没有使用同一个策略。Figma 的多人协作还依赖持续连接，若节点频繁切换或网络对长连接不友好，可能出现光标延迟、评论发送失败和文件状态反复同步。建议先选择一个稳定节点固定使用，不要让自动测速组在编辑过程中频繁切换出口。
Miro 的白板内容包含大量实时画布数据、缩略图和附件资源，常见域名包括 miro.com 与 mirostatic.com。如果白板可以进入但贴纸、图片或模板显示不完整，可以从连接日志中确认资源请求是否命中了代理组。对于团队自建的图片、文档或企业单点登录域名，应根据实际域名补充规则，而不是盲目扩大到所有相关顶级域。
规则编写时要注意
不要把 notion、figma 或 miro 作为模糊关键词直接匹配所有域名。过宽的关键词规则可能误伤国内站点，也可能把不相关的下载链接交给代理。优先使用 DOMAIN-SUFFIX 或明确的 DOMAIN，并通过日志逐条确认。
使用规则集时如何避免重复和冲突
如果订阅已经内置了海外服务规则，可以先查看规则命中顺序，再决定是否添加自定义规则。重复添加同一域名不会自动提高速度，反而会增加排查难度。比较稳妥的做法是建立一个小型的本地规则覆写区，只放 Notion、Figma、Miro 及其经过验证的资源域名，并将它放在 GEOIP 和通用规则之前。
使用规则提供者时，还要确认客户端支持当前配置使用的格式。有些订阅采用传统 Clash 语法，有些则面向 Mihomo 使用更丰富的规则集字段。若导入后出现配置解析错误，不要直接复制网络上完全不同版本的 YAML；先查看客户端内核版本和订阅生成格式，再逐项迁移。配置文件能够启动，比一次性加入大量规则更重要。
验证效果与延迟优化：从能打开到稳定协作
规则加载完成后，按照「国内服务、协作平台、实时功能、异常回退」四个维度测试。首先访问常用的国内搜索、邮箱或企业系统，确认它们仍然直连；随后打开 Notion、Figma 和 Miro 的真实项目，检查页面资源、图片、字体和评论是否完整；最后进行一次多人编辑或发送评论，观察同步是否延迟。不要只用首页判断配置成功，因为首页通常只验证了少数静态请求。
- 确认策略命中：在 Clash 的连接面板搜索目标域名，查看它实际使用的规则和代理组，确认没有被
GEOIP,CN,DIRECT提前截走。 - 确认资源完整：打开包含图片、附件、嵌入内容和自定义字体的页面，检查是否出现空白占位符或反复加载。
- 确认长连接：在 Figma 或 Miro 中移动对象、添加评论，观察其他窗口是否能及时收到变化。
- 确认国内直连：测试国内办公网站、局域网 NAS 和打印机，避免为了海外协作而破坏本地工作流。
- 记录节点表现：对两个或三个节点做相同测试，记录打开速度、同步延迟和断线次数，而不是只看测速页面上的延迟数字。
如果页面打开速度仍然不理想，先不要继续增加规则。可以在同一个策略组中手动切换节点，判断问题是线路质量还是配置匹配。某个节点能打开 Notion 却无法稳定同步 Figma，说明它对不同服务的线路质量可能不同；此时可以把协作平台拆成多个策略组，例如为 Figma 单独设置 Design-Proxy，为 Notion 和 Miro 使用另一组更稳定的出口。
DNS 也会影响协作平台的访问体验。启用 Fake-IP 时，确认 fake-ip-range 没有与局域网地址冲突，并将局域网域名、打印机名称和内部解析后缀加入排除列表。若切换 Fake-IP 与 Redir-Host 后出现旧连接残留，应刷新系统 DNS 缓存并完全重启浏览器。浏览器自身的安全 DNS 也可能绕过 Clash 的 DNS 处理，排障阶段可以暂时关闭该功能，待链路稳定后再根据客户端能力重新启用。
推荐的日常维护方式
- 把协作平台规则和其他复杂规则分开维护，后续修改时更容易回滚。
- 订阅更新后重新测试三个平台，确认策略组名称没有变化。
- 自动选择节点时设置合理的测速间隔，避免编辑文件时频繁切换出口。
- 遇到单个平台异常，先查看日志和节点状态，不要立刻把所有流量改成全局代理。
与一些只提供全局开关的网络加速工具相比，面向协作办公时最常见的问题是无法区分 Notion、Figma、Miro 与国内服务，配置一旦生效就很难知道哪些请求经过了代理；另一些客户端虽然支持规则，却缺少清晰的连接日志、策略组和订阅管理，遇到资源加载失败时排查成本较高。Clash 通过规则分流、节点策略组、实时连接记录和可编辑配置，把「哪些平台走代理、哪些服务保持直连」交给用户控制，既能减少协作平台同步异常，也能保留国内网络的速度。如果你希望按本文方案建立更透明、可回滚的办公网络环境，可以前往下载 Clash，导入订阅后逐项验证体验。