Clash Notion, Figma & Miro Workflow Setup Guide 2026

Why Notion, Figma, and Miro Need Split Routing

Notion, Figma, and Miro look like ordinary web applications, but a productive collaboration session rarely depends on one hostname or one type of connection. A Notion workspace may load its main interface from one domain, fetch images and file attachments from object storage, open real-time update channels, and synchronize page changes through long-lived HTTPS requests. Figma adds browser-based design files, fonts, thumbnails, multiplayer cursors, comments, and asset delivery. Miro combines a canvas editor with presence indicators, board snapshots, embedded media, and collaboration events. From the user’s perspective, each product is “one tab”; from Clash’s perspective, each tab is a collection of independent outbound flows.

That distinction matters when you configure a proxy for remote work. Sending every website through a proxy can make a meeting or design review feel stable at first, but it also adds latency to local news sites, banking pages, software updates, and domestic services that never needed the extra hop. The opposite mistake is routing only the obvious homepage domain. The dashboard may open while images remain blank, comments fail to post, or a Miro board stops receiving remote edits because a secondary API or WebSocket endpoint followed a different policy.

A better approach is to define a small collaboration policy: identify the service families you actually use, route their known domains through one deliberate policy group, and leave unrelated traffic on DIRECT. This is not a promise that one static list will cover every vendor change forever. SaaS providers add CDNs, rename API hosts, and move storage layers. Your configuration should therefore be narrow enough to audit, observable enough to troubleshoot, and easy to revise when the application’s network behavior changes.

Prepare the Clash Profile Before Adding Service Rules

Start with a maintained Clash-compatible client and a profile that already loads successfully. Depending on your platform, that may be Clash Verge Rev, Mihomo, ClashX, Clash for Android, or another maintained interface built around a compatible core. The labels differ between clients, but the important objects are the same: local listeners such as mixed-port, proxy groups, DNS behavior, rule providers, and a final fallback rule. Do not begin by copying a random list of Notion or Figma domains into a profile whose subscription is already failing to refresh. Establish a clean baseline first.

Open the client’s log panel and confirm that the core starts without YAML errors. Then verify that your selected proxy group contains usable nodes and that a simple test request can leave the machine through the intended path. A selector group is useful for collaboration because it gives you explicit control over the exit. If your provider has several regions, choose one with predictable latency and reasonable stability rather than changing nodes during every design review. Frequent manual switching can invalidate existing sessions or make it difficult to decide whether a failure belongs to the application or the route.

Create a dedicated group for collaboration traffic instead of pointing every rule directly to a provider group. A simple structure might contain a selector for manual choice, a url-test group for automatic health selection, and DIRECT as an intentional option when the service works better without tunneling. The exact YAML syntax depends on your core and subscription merge strategy, but the design principle is portable: name the group according to its purpose, keep it visible in the client, and avoid burying it inside several nested fallbacks that nobody can inspect during an incident.

proxy-groups:
  - name: COLLAB
    type: select
    proxies:
      - COLLAB-AUTO
      - PROXY
      - DIRECT

  - name: COLLAB-AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    proxies:
      - NODE-1
      - NODE-2

The example is intentionally conservative. A health probe measures whether a node can reach a small endpoint; it does not prove that Notion synchronization, Figma multiplayer sessions, or Miro WebSockets will behave identically. Treat url-test as a convenience for selecting a candidate, not as a complete application test. For a client or team that values consistency over automatic optimization, a selector with a known-good node is often easier to reason about than a group that silently changes exits while a board is being edited.

Define Scope and Keep a Recovery Path

Before editing rules, export or duplicate the working profile. A single misplaced indentation level, an invalid rule-provider reference, or a subscription update can make the whole configuration unusable. Keep one known-good copy with the original routing behavior, and make changes in small batches. If you add Notion, Figma, and Miro rules simultaneously and the profile stops working, you have created three variables and no useful comparison.

Also decide whether you need browser-only routing or device-wide routing. A browser extension may influence ordinary HTTP requests while leaving desktop Figma, the Miro application, command-line tools, and background sync untouched. System proxy mode covers applications that honor the operating system settings, but it does not guarantee that every native client does so. TUN mode can capture more traffic, yet it introduces virtual-interface permissions, DNS-mode decisions, and possible conflicts with corporate VPN software. Select the smallest mode that covers your actual workflow, then expand only when logs show an uncovered application.

Operational rule: do not equate a green “connected” badge with a complete collaboration path. Verify the application that matters, the hostname it uses, the policy group selected for that hostname, and the observed result in Clash logs.

Build Targeted Rules for Notion, Figma, and Miro

Add service rules above broad catch-all entries such as GEOIP, MATCH, or a large general proxy rule. Rule order is decisive: Clash evaluates from the top, so a generic rule placed earlier can capture collaboration traffic before your precise domain rules ever run. Use the narrowest domain patterns supported by your core. A suffix rule is convenient for a family of subdomains, while an exact domain rule is safer when you want to limit scope. Avoid routing an entire unrelated parent domain merely because one application uses a single subdomain beneath it.

rules:
  - DOMAIN-SUFFIX,notion.so,COLLAB
  - DOMAIN-SUFFIX,notion.site,COLLAB
  - DOMAIN-SUFFIX,figma.com,COLLAB
  - DOMAIN-SUFFIX,figmausercontent.com,COLLAB
  - DOMAIN-SUFFIX,miro.com,COLLAB
  - DOMAIN-SUFFIX,mirostatic.com,COLLAB
  - MATCH,DIRECT

These examples are starting points, not universal domain guarantees. Notion workspaces can reference external image hosts, customer-managed domains, analytics services, or cloud storage providers. Figma may rely on asset and font delivery domains that are not obvious from the address bar. Miro boards can embed external content whose availability is governed by the embedded provider rather than Miro itself. If the main interface loads but a specific feature fails, inspect the live connection log while reproducing only that feature. Record the hostname, protocol, destination port, matched rule, and selected policy group before adding anything.

In practice, separate the three services logically even if they initially share one group. For example, use NOTION, FIGMA, and MIRO groups that inherit from the same stable node set. This gives you a way to test one service without changing the route for the others. It also helps when a provider performs well for ordinary HTTPS but poorly for Figma’s persistent sessions. If your profile becomes too large, keep one shared COLLAB group and document which domains belong to each service in comments outside the machine-generated subscription section.

• Notion: test page loading, database queries, image previews, file downloads, and edits made from two devices.
• Figma: test file thumbnails, font loading, comments, multiplayer cursors, prototype previews, and asset export.
• Miro: test board opening, cursor presence, sticky-note updates, image uploads, embedded media, and board history.
• Shared policy: keep DNS handling, node choice, and fallback behavior consistent while comparing results.

Do not automatically proxy identity providers, payment pages, or every third-party integration merely because a collaboration product links to them. Authentication can involve a browser redirect, a local callback, and a separate token endpoint. If you route one leg through a different exit, the login may appear to succeed but fail to persist. For work accounts, coordinate changes with your administrator rather than attempting to “fix” an enterprise sign-in by adding broad domains to a personal profile.

DNS, WebSockets, and Session Stability

Many collaboration problems are diagnosed too late because operators change proxy nodes before checking DNS. Clash may resolve a hostname through one DNS strategy while the application connects through another route. Fake-IP, redirection hosts, system DNS, and enhanced modes each have different interactions with browsers and native applications. The right choice depends on your client and operating system, but consistency is the goal. If a service resolves to an address that the core cannot map back to its hostname, domain rules may not match as expected. If local network DNS rewrites the answer, the connection may reach a different edge than the one you tested earlier.

Begin with the simplest DNS mode supported by your client, then confirm in logs that the target hostname is visible and matched. Avoid changing DNS mode, proxy group, and TUN mode in one experiment. Change one layer, restart the affected application, and reproduce one action. This slow method is more informative than toggling five settings and concluding that “Clash is random.” A browser may cache DNS and WebSocket state for several minutes, while a native editor can retain connections until it is fully quit. Close and relaunch the application when validating a routing change.

WebSockets and long-lived HTTPS sessions deserve special attention. A page can render successfully through a fast short request while live cursors, presence indicators, or real-time comments fail later because an intermediary closes idle connections or the selected node has unstable keep-alive behavior. Watch for repeated connection attempts, short intervals between disconnects, and a policy group that changes nodes during the session. If the client offers connection or proxy logs, compare the initial page request with the later persistent connection instead of relying only on the visual state of the web application.

For remote collaboration, stability often matters more than the lowest probe latency. A node that is 30 milliseconds faster but changes address frequently can be worse than a slightly slower node that preserves sessions. Set reasonable health-check intervals and avoid aggressive automatic switching. When several teammates share a board or design file, a route change in the middle of a save operation can create duplicate retries, delayed comments, or confusing conflict messages even though no data is permanently lost.

Test the Workflow and Maintain It Safely

Use a repeatable test matrix rather than checking only whether the homepage opens. First, test with the collaboration rule enabled and record the selected group. Second, test the same action with the group changed to another known-good node. Third, if policy permits, compare with DIRECT. This comparison tells you whether the failure follows the application, the node, or the proxy route. Keep the test small: open one Notion page, edit one property, load one Figma file, add one comment, open one Miro board, and move one object. Small actions produce clearer logs than a busy workspace full of extensions and embedded media.

Check the operating system and application layers separately. Confirm that the intended client is running only once, that another VPN or security agent is not intercepting the same traffic, and that the system proxy points to the correct local port. If you use TUN, verify that the virtual adapter is active and that DNS requests are handled by the intended core. If only a desktop application fails while the browser works, determine whether it honors system proxy settings or requires its own configuration. Do not assume a successful browser test validates a native Figma or Miro client.

Rule providers can improve coverage, but they also introduce change. A remote list may add a broad rule above your carefully designed entries, change a policy name, or become temporarily unavailable. Pin providers to trusted sources, review updates, and keep local service-specific rules above provider includes when your merge model allows it. After every profile refresh, verify that the collaboration group still exists and that the logs show the intended match. If the service suddenly breaks after an update, compare the rendered rules with your last working backup before adding more domains.

Finally, document exceptions. Write down why a particular asset domain was added, which application feature required it, and whether it should remain proxied or return to DIRECT later. Remove temporary troubleshooting rules after the test. A profile that grows through unexplained emergency additions eventually becomes impossible to audit, and broad routing can expose unrelated traffic to a route that was chosen only for one design tool. Good Clash maintenance is less about collecting every possible hostname and more about preserving a clear relationship between user intent, rule order, observed traffic, and policy group behavior.

Compared with browser-only proxy extensions, Clash offers a more coherent policy layer for native Figma, Miro desktop clients, background synchronization, and multiple browsers, while extensions often leave non-browser traffic untouched and make DNS behavior harder to inspect. Generic full-device VPNs can be simpler, but they commonly provide less granular control over which collaboration services use which node and may force local traffic through an unnecessary gateway. For this Notion, Figma, and Miro workflow, Clash V.CORE provides visible rules, selectable groups, detailed logs, and flexible system or TUN capture, so you can solve a synchronization problem without turning every website into proxy traffic; when you are ready to apply the profile, visit the Clash V.CORE download page and choose the client that matches your platform.