为什么 Notion、Figma 与 Miro 会出现「能开启但不好用」 一文看懂

不同客户端的按钮名称也许略有差异，但底层思路基本相同：先确认请求目标，再决定代理范围，最后通过连接日志验证规则是否真的命中。不要一开始就开启全局模式或修改大批 DNS 参数，否则出现难点时很难判断究竟是节点、规则、解析还是本机应用导致的。

如果你搜索的是「Notion 加载慢」「Figma 图片出不来」「Miro 白板同步时延」「Clash 怎么给海外办公软件分流」，一般遇到的并不是单一网站完全无法连通，而是页面能开启、核心资源却加载不齐全。

比如 Notion 首页能够显示，数据库图片和附件却一直转圈；Figma 文件列表能进入，但字体、缩略图或多人协作光标刷新很慢；Miro 白板能够开启，拖动便签时却频繁时延，刷新后还要重新等待资源同步。

先看这一点：这类办公工具的请求链路比普通网页更复杂。一个工作区也许同时连通主站、静态资源域名、图片 CDN、字体服务、实时协作接口和登录鉴权服务。浏览器扩展或系统代理只处理了其中一部分请求，剩下的连接仍也许按照本地网络直连，最终形成网页开启路径与资源加载路径不一致的半通状态。

Clash 的价值不在于容易地把全部流量切换成全局代理，而是根据域名、进程和连通目的建立更细的规则，让 Notion、Figma、Miro 的海外服务走稳健节点，同时让国内视频、银行、政府网站和局域网资源保持直连。

这篇文章以 Clash Verge Rev、Mihomo Party 以及其他兼容 Mihomo 内核的客户端为例，说明如何从基础分流开始，逐步处理策略组、DNS、系统代理、TUN 模式和多设备同步。

先记住一个判断标准：如果浏览器页面能开启，但图片、字体、评论、光标或附件加载异常，首位核对连接日志中的真实域名；如果浏览器正常而桌面客户端异常，再核对系统代理继承、TUN 接管和应用自身的网络设置。

第一气：为 Notion、Figma 与 Miro 建立可维护的分流 核心要点

修改后要刷新配置，并在客户端的连接页面重新开启对应应用，确认目标域名旁边显示的是「海外效率工具」，而不是 DIRECT 或其他内置组。

  • Notion：先覆盖 notion.so、notion.site 以及你在连接日志中看到的工作区、图片和 API 相关域名。若团队运用自定义 Notion 域名，应将该域名单独加入同一策略组。
  • Figma：首位覆盖 figma.com、figma.site 及实际日志中出现的静态资源或协作服务域名。不要只测试文件首页，开启一个包含图片、字体和多人编辑的真实文件再观察。
  • Miro：首位覆盖 miro.com 及白板加载后新增的 CDN、媒体和实时连接域名。白板中的视频、图片和嵌入素材也许来自第三方站点，得按日志判断是否单独处理。
  • 鉴权与办公协作：如果企业工作区通过 Google、Microsoft 或其他身份平台登录，还要分别确认登录跳转域名。鉴权页面能够开启，不代表回调、头像和工作区 API 一定走了同一条路径。

补充说明：分流规则不宜只写一个主域名。Notion 的工作区页面、登录服务、图片附件和 API 请求也许运用不同的主机名；Figma 除了 figma.com，还会涉及静态资源、图片和协作连接；Miro 也也许把白板资源、媒体文件与实时同步拆到不同域名。具体域名会随产品版本、地区和 CDN 调整，所以下面的写法适合作为起点，而不是永远不变的齐全清单。

在 YAML 配置中，能够把三个产品放进同一个「海外效率工具」策略组，也能够拆成 Notion、Figma、Miro 三个独立组。前者维护容易，适合个人用户；

proxy-groups:
  - name: 海外效率工具
    type: select
    proxies:
      - 自动选择
      - 节点 A
      - 节点 B
      - DIRECT

rules:
  - DOMAIN-SUFFIX,notion.so,海外效率工具
  - DOMAIN-SUFFIX,notion.site,海外效率工具
  - DOMAIN-SUFFIX,figma.com,海外效率工具
  - DOMAIN-SUFFIX,figma.site,海外效率工具
  - DOMAIN-SUFFIX,miro.com,海外效率工具
  - MATCH,Final

后者更便于相当节点质量，比如 Figma 对稳健性和上传快慢敏感，Miro 对持续连接和抖动敏感，Notion 则更高频图片附件或 API 请求间歇超时。刚开始配置时，推荐先运用一个稳健的手工挑选组，确认全部域名都能正常工作后，再考虑切换到 url-test 或故障转移组。

换个角度：这段示例的要点不是照抄域名，而是理解规则顺序。Clash 会从上到下匹配规则，越具体、越得首位代理的域名越应当放在前面。若前面存在一个宽泛的 GEOIP、国家地区或第三方规则集，也许在 Notion、Figma、Miro 的专用规则之前就把请求送入直连组。

实用方法：不要凭搜索结果猜 CDN 域名。开启 Notion 数据库图片、Figma 真实设计文件和 Miro 大型白板，等待资源加载时观察 Clash 连接日志，把反复出现且状态异常的域名逐条记录，再用最小范围补规则。

第二步：处理 DNS、系统代理与 TUN 模式 逐条拆解

TUN 会在网络层接管更多 TCP 与 UDP 流量，适合处理「浏览器能用、桌面应用不能用」的状态，但它也会影响本地开发环境、虚拟机、Docker、WSL 和企业 VPN。启用前应先保存当前配置，确认客户端拥有安装服务或网络扩展所需的权限，并保留关闭 TUN 后恢复网络的办法。

规则写对后仍然卡顿，高频缘由是域名解析结果与代理路径不匹配。比如本地 DNS 返回了不可用或距离较远的 CDN 地址，Clash 虽然识别出域名并挑选了代理，但实际连接依旧反复超时；

又或者 DNS 请求被其他软件接管，导致同一个域名在不同时间解析到完全不同的地址。对于同时运用 Notion、Figma 和 Miro 的用户，DNS 的目标应是减少污染和失误解析，而不是盲目追求某个固定公共 DNS。

具体来说：如果运用 Mihomo 内核，能够从配置中的 DNS 模块核对以下方向：启用合理的远程解析方式，避免全部请求都由本地网络干脆解析；根据客户端兼容状态挑选 fake-ip 或 redir-host；

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.google/dns-query
    - https://cloudflare-dns.com/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'
    - '+.intranet.example.com'

为局域网、公司内网和本地设备保留直连例外。启用 fake-ip 后，个别局域网应用、打印机、企业 VPN 或得真实地址的程序也许出现兼容性难点，所以不要把全部异常都归因于 Clash，应当分别测试。

示例中的远程 DNS 仅用于说明配置结构，实际可用地址应结合你的网络、节点和客户端版本挑选。配置后推荐清理系统 DNS 缓存，重新拉起 Clash，再依次测试登录、开启文件、加载图片和持续编辑。若只有首次开启慢，也许是 DNS 或 TLS 建连难点；若编辑一段时间后才断开，则更应核对节点稳健性、策略组是否无人值守切换，以及实时连接是否被失误分流。

顺带一提：系统代理适合浏览器和多数数遵循操作系统代理设置的桌面应用。开启后，先确认 Clash 的混合端口存在，比如 7890 或客户端实际显示的端口，再核对系统代理地址是否为 127.0.0.1，端口是否一致。

Windows、macOS 的系统代理入口不同，但判断方式相同：浏览器连通测试页，查看 Clash 连接列表是否出现对应域名。不要只看客户端操作操作界面上的「已启用」字样，因为端口被其他程序占用时，系统也许显示代理已设置，实际请求却没有进入 Clash。

如果 Figma 桌面版、Miro 桌面版、命令行工具或企业封装应用不遵循系统代理，才考虑 TUN 模式。

  1. 先关闭全局代理并确认基础配置：确保系统代理端口、订阅配置和规则模式均正常，避免把多个变量同时改变。
  2. 安装 TUN 所需服务：在客户端设置中安装 Service Mode、增强服务或网络扩展；系统弹出权限请求时按当前账户权限完成授权。
  3. 开启无人值守路由：首位运用 auto-route: true 与 auto-detect-interface: true，让内核识别当前 Wi-Fi 或有线网卡。
  4. 逐个测试应用：先开启 Notion，再测试 Figma 和 Miro，观察连接日志是否出现新的域名与失误，不要一次拉起全部大型文件。
  5. 发现局域网异常就回退：如果打印机、NAS、企业 VPN 或开发服务失效，先关闭 TUN，记录受影响网段，再通过排除规则处理。

不要把 TUN 当作速度开关：TUN 的核心作用是扩大流量接管范围，不会无人值守提升节点带宽。节点本身抖动严重时，开启 TUN 只会让更多应用一起暴露在同一条不稳健链路上。

第三步：针对协作、图片和多设备情况优化稳健性 底层逻辑

Clash 更适合这类得持续维护的工作流：能够围绕真实连接日志逐步补规则，清楚区分系统代理与 TUN 的适用范围，并按这篇文章的顺序保留可回退的配置。如果你正准备把 Notion、Figma 与 Miro 纳入一套稳健的 Clash 分流方案，不妨免费下载 Clash，先用基础规则跑通，再根据亲手的设备和协作状态逐项优化。

先看这一点：Notion、Figma 和 Miro 的「快」并不只是首页首屏时间。真正影响工作运用感受的是连续操作时的稳健性：Figma 拖动图层时不能频繁重连，Miro 移动大型白板时不能长时间等待同步，Notion 编辑数据库时不能因为附件请求不成功而反复刷新。所以策略组不要只按测速时延挑选节点，还要观察丢包、抖动、连接持续时间和高峰期表现。

对于 Figma 和 Miro，推荐先固定一个稳健节点进行半小时到一小时的真实工作，再与无人值守挑选组相当。无人值守测速通常只测一个短请求，无法齐全反映多人协作长连接、图片上传和大文件下载的表现。如果策略组在连接建立后无人值守切换节点，旧连接也许被终止，用户看到的就是光标消失、评论发送不成功或白板状态回滚。得长期协作时，手工挑选一般比频繁测速更靠谱。

对于 Notion，图片和附件加载慢时，先区分是页面数据慢，还是媒体资源慢。能够开启浏览器开发者工具或 Clash 连接日志，分别观察主站请求、图片 CDN 和第三方嵌入素材。

补充说明：如果主站响应很快，只有某些图片打不开，首位补齐资源域名；如果整套页面 API 都时延，则核对节点、DNS 和浏览器缓存。不要干脆把全部第三方嵌入站点加入海外规则，因为这也许扩大代理范围，也也许让本来适合直连的素材变慢。

多设备运用时，推荐把通用规则、设备差异和本地覆写分开。手机通常只得 Notion、Figma、Miro 的基础域名规则；Windows 开启 TUN 后也许得排除 WSL、Docker 或局域网；

  • 配置分层：远端订阅负责节点和基础规则，本地覆写负责策略组名称、Notion/Figma/Miro 规则以及设备专属 DNS。
  • 节点命名：用地区、线路类型或用途标记节点，避免在手机小屏上看到一串无法区分的随机名称。
  • 日志留证：出现同步不成功时记录时间、应用、域名、策略组和节点，便于判断是单一资源故障还是总体出口异常。
  • 逐步放宽：先代理主站和明确的资源域名，确认稳健后再处理第三方嵌入、字体或视频服务，避免规则越来越宽却无法维护。
现象 首位核对 处理方向
Notion 页面开启但图片转圈 图片 CDN 与连接日志 补充真实资源域名，确认其进入稳健策略组
Figma 文件能看但字体或缩略图缺失 静态资源、字体与缓存 核对资源请求是否直连不成功，并清理异常缓存后重试
Miro 白板开启后同步时延 长连接、节点抖动与无人值守切换 暂时固定节点，避免协作过程中策略组切换
浏览器正常，桌面客户端不成功 系统代理继承与 TUN 状态 先确认客户端是否兼容系统代理，再决定是否启用 TUN
开启 TUN 后内网或 VPN 异常 路由、DNS 与排除规则 关闭 TUN 回退验证，再为局域网和企业网段添加例外

macOS 则要留意网络扩展、iCloud Private Relay 和企业 VPN；路由器或旁路由得额外考虑整套局域网的 DNS 与内置路由。不要把电脑上的齐全配置原封不动复制到手机，否则服务模式、端口、TUN 和局域网规则也许互相冲突。

换个角度：完成调整后，推荐按照固定顺序验收：先连通 Notion 工作区并开启包含图片的页面；再在 Figma 中开启一个包含字体、图片和多人协作的文件；最后进入 Miro 大型白板，移动对象、发送评论并等待同步。

每一气都查看 Clash 连接日志，确认域名、规则和策略组一致。若某个请求返回 403、401 或权限失误，而 TLS 已成功建立，难点也许来自账户、工作区权限或产品服务本身，不应继续无休止地更换节点。

相比之下，众多同类代理工具要么只能依赖全局模式，容易把国内服务和局域网一起绕远；要么规则编辑入口分散，遇到 Notion 附件、Figma 资源或 Miro 长连接异常时，很难高速看出实际命中了哪条规则，部分工具对 TUN、DNS 和多设备覆写的中文说明也不够齐全。