为什么 Notion、Figma 与 Miro 会出现「能打开但不好用」

如果你搜索的是「Notion 加载慢」「Figma 图片出不来」「Miro 白板同步延迟」「Clash 怎么给海外办公软件分流」，通常遇到的并不是单一网站完全无法访问，而是页面能打开、核心资源却加载不完整。例如 Notion 首页可以显示，数据库图片和附件却一直转圈；Figma 文件列表能进入，但字体、缩略图或多人协作光标更新很慢；Miro 白板能够打开，拖动便签时却频繁延迟，刷新后还要重新等待资源同步。

这类办公工具的请求链路比普通网页更复杂。一个工作区可能同时访问主站、静态资源域名、图片 CDN、字体服务、实时协作接口和登录认证服务。浏览器扩展或系统代理只解决了其中一部分请求，剩下的连接仍可能按照本地网络直连，最终形成网页打开路径与资源加载路径不一致的半通状态。Clash 的价值不在于简单地把所有流量切换成全局代理，而是根据域名、进程和访问目的建立更细的规则，让 Notion、Figma、Miro 的海外服务走稳定节点，同时让国内视频、银行、政府网站和局域网资源保持直连。

本文以 Clash Verge Rev、Mihomo Party 以及其他支持 Mihomo 内核的客户端为例，说明如何从基础分流开始，逐步处理策略组、DNS、系统代理、TUN 模式和多设备同步。不同客户端的按钮名称可能略有差异，但底层思路基本相同：先确认请求目标，再决定代理范围，最后通过连接日志验证规则是否真的命中。不要一开始就打开全局模式或修改大量 DNS 参数，否则出现问题时很难判断究竟是节点、规则、解析还是本机应用导致的。

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

第一步：为 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 三个独立组。前者维护简单，适合个人用户；后者更便于比较节点质量，例如 Figma 对稳定性和上传速度敏感，Miro 对持续连接和抖动敏感，Notion 则更常见图片附件或 API 请求间歇超时。刚开始配置时，建议先使用一个稳定的手动选择组，确认所有域名都能正常工作后，再考虑切换到 url-test 或故障转移组。

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

这段示例的重点不是照抄域名，而是理解规则顺序。Clash 会从上到下匹配规则，越具体、越需要优先代理的域名越应该放在前面。若前面存在一个宽泛的 GEOIP、国家地区或第三方规则集，可能在 Notion、Figma、Miro 的专用规则之前就把请求送入直连组。修改后要刷新配置，并在客户端的连接页面重新打开对应应用，确认目标域名旁边显示的是「海外效率工具」，而不是 DIRECT 或其他默认组。

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

第二步：处理 DNS、系统代理与 TUN 模式

规则写对后仍然卡顿，常见原因是域名解析结果与代理路径不匹配。例如本地 DNS 返回了不可用或距离较远的 CDN 地址，Clash 虽然识别出域名并选择了代理，但实际连接依旧反复超时；又或者 DNS 请求被其他软件接管，导致同一个域名在不同时间解析到完全不同的地址。对于同时使用 Notion、Figma 和 Miro 的用户，DNS 的目标应是减少污染和错误解析，而不是盲目追求某个固定公共 DNS。

如果使用 Mihomo 内核，可以从配置中的 DNS 模块检查以下方向：启用合理的远程解析方式，避免所有请求都由本地网络直接解析；根据客户端支持情况选择 fake-ip 或 redir-host；为局域网、公司内网和本地设备保留直连例外。启用 fake-ip 后，个别局域网应用、打印机、企业 VPN 或需要真实地址的程序可能出现兼容性问题，因此不要把所有异常都归因于 Clash，应该分别测试。

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'

示例中的远程 DNS 仅用于说明配置结构，实际可用地址应结合你的网络、节点和客户端版本选择。配置后建议清理系统 DNS 缓存，重新启动 Clash，再依次测试登录、打开文件、加载图片和持续编辑。若只有首次打开慢，可能是 DNS 或 TLS 建连问题；若编辑一段时间后才断开，则更应检查节点稳定性、策略组是否自动切换，以及实时连接是否被错误分流。

系统代理适合浏览器和大多数遵循操作系统代理设置的桌面应用。开启后，先确认 Clash 的混合端口存在，例如 7890 或客户端实际显示的端口，再检查系统代理地址是否为 127.0.0.1，端口是否一致。Windows、macOS 的系统代理入口不同，但判断方式相同：浏览器访问测试页，查看 Clash 连接列表是否出现对应域名。不要只看客户端界面上的「已启用」字样，因为端口被其他程序占用时，系统可能显示代理已设置，实际请求却没有进入 Clash。

如果 Figma 桌面版、Miro 桌面版、命令行工具或企业封装应用不遵循系统代理，才考虑 TUN 模式。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 的「快」并不只是首页首屏时间。真正影响工作体验的是连续操作时的稳定性：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/Figma/Miro 规则以及设备专属 DNS。
  • 节点命名：用地区、线路类型或用途标记节点，避免在手机小屏上看到一串无法区分的随机名称。
  • 日志留证：出现同步失败时记录时间、应用、域名、策略组和节点，便于判断是单一资源故障还是整体出口异常。
  • 逐步放宽：先代理主站和明确的资源域名，确认稳定后再处理第三方嵌入、字体或视频服务，避免规则越来越宽却无法维护。
现象 优先检查 处理方向
Notion 页面打开但图片转圈 图片 CDN 与连接日志 补充真实资源域名，确认其进入稳定策略组
Figma 文件能看但字体或缩略图缺失 静态资源、字体与缓存 检查资源请求是否直连失败，并清理异常缓存后重试
Miro 白板打开后同步延迟 长连接、节点抖动与自动切换 暂时固定节点，避免协作过程中策略组切换
浏览器正常，桌面客户端失败 系统代理继承与 TUN 状态 先确认客户端是否支持系统代理，再决定是否启用 TUN
开启 TUN 后内网或 VPN 异常 路由、DNS 与排除规则 关闭 TUN 回退验证，再为局域网和企业网段添加例外

完成调整后，建议按照固定顺序验收：先访问 Notion 工作区并打开包含图片的页面；再在 Figma 中打开一个包含字体、图片和多人协作的文件；最后进入 Miro 大型白板，移动对象、发送评论并等待同步。每一步都查看 Clash 连接日志，确认域名、规则和策略组一致。若某个请求返回 403、401 或权限错误，而 TLS 已成功建立，问题可能来自账户、工作区权限或产品服务本身，不应继续无休止地更换节点。

相比之下，许多同类代理工具要么只能依赖全局模式，容易把国内服务和局域网一起绕远；要么规则编辑入口分散，遇到 Notion 附件、Figma 资源或 Miro 长连接异常时，很难快速看出实际命中了哪条规则，部分工具对 TUN、DNS 和多设备覆写的中文说明也不够完整。Clash 官网 更适合这类需要持续维护的工作流：可以围绕真实连接日志逐步补规则，清楚区分系统代理与 TUN 的适用范围，并按本文的顺序保留可回退的配置。如果你正准备把 Notion、Figma 与 Miro 纳入一套稳定的 Clash 分流方案，不妨免费下载 Clash 官网，先用基础规则跑通，再根据自己的设备和协作场景逐项优化。