为什么 Notion、Figma 与 Miro 会出现「能启用但不好用」 要点速览

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

如果你搜索的是「Notion 加载慢」「Figma 图片出不来」「Miro 白板同步响应时间」「Clash 怎么给海外办公软件分流」，多数现状下遇到的并不是单一网站完全无法访问到到到，而是页面能启用、核心资源却加载不完备。

举个小例子 Notion 首页得以显示，数据库图片和附件却一直转圈；Figma 文件列表能进入，但字体、缩略图或多人协作光标升级很慢；Miro 白板能够启用，拖动便签时却频繁响应时间，刷新后还要重新等待资源同步。

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

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

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

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

第一口气：为 Notion、Figma 与 Miro 建立可维护的分流 关键信息

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

这里要多说一句：分流规则不宜只写一个主域名。Notion 的工作区页面、登录服务、图片附件和 API 请求或许采用不同的主机名；Figma 除了 figma.com，还会涉及静态资源、图片和协作连接；

Miro 也或许把白板资源、媒体文件与实时同步拆到不同域名。具体域名会随产品版本、地区和 CDN 调整，于是下面的写法适合作为起点，而不是永远不变的完备清单。

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

换个说法：在 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 或故障转移组。

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

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

第二步：处理 DNS、系统代理与 TUN 模式 关键点梳理

如果 Figma 桌面版、Miro 桌面版、命令行工具或企业封装应用不遵循系统代理，才考虑 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 连接列表是否出现对应域名。不要只看客户端UI UI 界面上的「已启用」字样，因为端口被其他程序占用时，系统或许显示代理已设置，实际请求却没有进入 Clash。

TUN 会在网络层接管更多 TCP 与 UDP 流量，适合处理「浏览器能用、桌面应用不能用」的现状，但它也会影响本地开发环境、虚拟机、Docker、WSL 和企业 VPN。启用前应先保存当前配置，确认客户端拥有安装服务或网络扩展所需的权限，并保留关闭 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 只会让更多应用一起暴露在同一条不平稳链路上。

第三步：针对协作、图片和多设备使用场景优化平稳性 完备说明

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

这里要多说一句：Notion、Figma 和 Miro 的「快」并不只是首页首屏时间。真正影响工作上手感觉的是连续操作时的平稳性：Figma 拖动图层时不能频繁重连，Miro 移动大型白板时不能长时间等待同步，Notion 编辑数据库时不能因为附件请求无法完成而反复刷新。

于是策略组不要只按测速响应时间选定节点，还要观察丢包、抖动、连接持续时间和高峰期表现。

对于 Figma 和 Miro，不妨先固定一个平稳节点进行半小时到一小时的真实工作，再与全全自动选定组颇为。全全自动测速多数现状下只测一个短请求，无法完备反映多人协作长连接、图片上传和大文件下载的表现。

换个说法：如果策略组在连接建立后全全自动切换节点，旧连接或许被终止，用户看到的就是光标消失、评论发送无法完成或白板状态回滚。要长期协作时，人工选定经常比频繁测速更可信。

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

如果主站响应很快，只有某些图片打不开，第一顺位补齐资源域名；如果全部页面 API 都响应时间，则排查节点、DNS 和浏览器缓存。不要径直把各个第三方嵌入站点加入海外规则，因为这或许扩大代理范围，也或许让本来适合直连的正文变慢。

落到实处：多设备采用时，推荐把通用规则、设备差异和本地覆写分开。手机多数现状下只要 Notion、Figma、Miro 的基础域名规则；Windows 开启 TUN 后或许要排除 WSL、Docker 或局域网；

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

现象 第一顺位排查 处理方向
Notion 页面启用但图片转圈 图片 CDN 与连接日志 补充真实资源域名，确认其进入平稳策略组
Figma 文件能看但字体或缩略图缺失 静态资源、字体与缓存 排查资源请求是否直连无法完成，并清理异常缓存后重试
Miro 白板启用后同步响应时间 长连接、节点抖动与全自动切换 暂时固定节点，避免协作过程中策略组切换
浏览器正常，桌面客户端无法完成 系统代理继承与 TUN 状态 先确认客户端是否适配系统代理，再决定是否启用 TUN
开启 TUN 后内网或 VPN 异常 路由、DNS 与排除规则 关闭 TUN 回退验证，再为局域网和企业网段添加例外

配置分层：远端订阅负责节点和基础规则，本地覆写负责策略组名称、Notion/Figma/Miro 规则以及设备专属 DNS；节点命名：用地区、线路类型或用途标记节点，避免在手机小屏上看到一串无法区分的随机名称；日志留证：出现同步无法完成时记录时间、应用、域名、策略组和节点，便于判断是单一资源故障还是全局出口异常；逐步放宽：先代理主站和明确的资源域名，确认平稳后再处理第三方嵌入、字体或视频服务，避免规则越来越宽却无法维护。

别忽略了：完成调整后，不妨按照固定顺序验收：先访问到到 Notion 工作区并启用包含图片的页面；再在 Figma 中启用一个包含字体、图片和多人协作的文件；最后进入 Miro 大型白板，移动对象、发送评论并等待同步。

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

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