Clash Notion, Figma & Miro Setup Guide For Faster Workflows

Why Notion, Figma, and Miro Benefit from Selective Routing

Notion, Figma, and Miro are cloud-first work tools, but they do not all behave like ordinary websites. Notion continuously synchronizes pages, databases, images, and file attachments. Figma maintains a live connection for multiplayer editing, asset loading, comments, and font-related services. Miro relies on persistent browser connections while boards, cursors, images, and embedded documents are updated in real time. When one of these connections is slow or unstable, the visible symptom may be an incomplete workspace, missing assets, delayed comments, or a board that appears to freeze.

Sending every application through a proxy can appear to solve the problem, but it often creates new ones. Local intranet portals may become slower, company resources may reject an unfamiliar exit location, and video calls or large file transfers may consume proxy bandwidth unnecessarily. A better Clash setup is usually split tunneling: route the collaboration services that need a reliable path through a suitable proxy, while keeping local websites, office systems, and latency-sensitive traffic on a direct connection.

The objective is not to force Notion, Figma, or Miro into one permanent mode. The objective is to make their traffic predictable. You should know which domains use the proxy, which domains remain direct, which policy group chooses the node, and how to verify the result when a project workspace behaves differently from a normal webpage.

Practical principle

Start with Rule mode and a small, understandable rule set. Add domains only after confirming that the application actually needs proxy routing. A shorter configuration is easier to troubleshoot than a large list copied from an unrelated setup.

Prepare the Clash Client and Profile

This guide applies to current Clash-compatible clients such as Clash Verge Rev, Mihomo-based desktop clients, and other applications that expose profiles, proxy groups, rules, and system proxy controls. Menu names vary slightly between clients, but the concepts are the same. You need a working client, a valid subscription profile, and at least one usable proxy node. Clash does not provide nodes by itself, so obtain a subscription URL from a provider you trust and use it according to the provider’s terms and applicable law.

Before changing workflow rules, check these items:

The client opens without a core or profile error.
Your subscription has downloaded successfully and contains usable nodes.
The system date and time are correct, which is important for HTTPS connections.
The client’s core is current enough to support the rule format and features used by your profile.
You have recorded a backup of the original profile before editing it.

Import the subscription from the client’s Profiles, Subscriptions, or similarly named section. After the profile loads, activate it and open the proxy groups page. Most providers include groups such as Proxy, Auto, Fallback, or Select. Do not assume that the first listed group is the best choice. A group may be configured to select automatically, test latency, or inherit another group. Understanding that relationship will make later node troubleshooting much faster.

Next, enable Rule mode rather than Global mode. Global mode sends nearly all eligible traffic to the selected proxy group, which is useful as a short diagnostic test but is rarely ideal for a mixed work environment. Rule mode evaluates domains and network destinations in order. It can send Notion, Figma, and Miro through a dedicated policy while keeping company intranet addresses and local services direct.

System proxy and TUN mode are different controls. System Proxy affects applications that respect the operating system’s HTTP or SOCKS proxy settings. Browsers and many desktop tools follow these settings, but some applications do not. TUN mode creates a virtual network interface and can capture a broader range of traffic, including applications that ignore system proxy settings. TUN mode may require administrator permission and can influence DNS, VPN software, games, and corporate security tools, so enable it only when system proxy mode is insufficient.

Do not enable every mode at once

Test with system proxy first. If the browser works but the desktop application still cannot synchronize, compare the client’s connection log and then consider TUN mode. Running multiple VPNs, proxy clients, or virtual network adapters simultaneously can make a correct Clash rule look broken.

Build Policy Groups for Work Applications

A policy group is the decision point that determines how matching traffic leaves your device. For a remote team, a simple structure is normally more useful than dozens of individually named groups. You might have a primary work group, an automatic fallback group, and a direct option for testing. The primary group should contain nodes that are geographically and technically suitable for your team’s SaaS services, not merely nodes with the lowest raw ping.

Latency testing is helpful, but it is not the whole story. A node can respond quickly to a test URL and still perform poorly when loading Figma assets or maintaining a long-lived collaboration connection. Consider stability, packet loss, TLS handshake time, download throughput, and whether the node remains available during your team’s working hours. If your client supports URL testing, choose a test URL that is reachable and relevant to the region where your tools operate.

Work-Proxy: a manually selected group containing reliable nodes for Notion, Figma, and Miro.
Work-Auto: an automatic or fallback group that checks several nodes and switches when the active node fails.
DIRECT: used for local services, internal domains, and comparison testing.
Reject: optional, and best reserved for known tracking or unwanted traffic rather than broad application domains.

Keep a manual selection available even when you prefer automatic switching. Automatic groups are convenient during normal work, but a manual group is valuable when you need to reproduce a problem on the same node as a teammate. It also lets you distinguish a policy problem from a node-quality problem. If the same domain works through one node and fails through another, the rule is probably correct and the node deserves investigation.

When editing YAML, avoid replacing the provider’s entire proxy group section unless you understand the profile structure. Subscription providers may regenerate groups during updates. A safer approach is to use the client’s override or merge feature where available, or maintain a small local configuration layer that references the provider’s existing proxies. The exact syntax differs between Clash cores, so validate the profile after every structural change.

mode: rule
log-level: info

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

The example demonstrates the idea, not a universal copy-and-paste profile. Some services use additional content delivery, authentication, telemetry, or API domains. A rule that includes only the main homepage may allow the workspace to open while images, comments, fonts, or real-time updates fail. Add domains based on observed logs rather than guessing from a large third-party list.

Add and Tune Notion, Figma, and Miro Rules

Notion routing

Notion workspaces commonly involve the main Notion domain, page synchronization endpoints, file previews, and externally hosted attachments. Begin with the domains shown in the Clash connection log when you open a page, search a database, upload a file, and download an attachment. Route the core Notion domains through Work-Proxy, then test a normal page, a database view, a shared page, and an attachment. If the page loads but an embedded service remains unavailable, inspect the embedded service separately; not every iframe belongs to Notion.

Do not automatically proxy every link stored inside Notion. A workspace can contain documentation, customer portals, design files, and internal tools hosted on unrelated domains. Routing the Notion application and routing every destination opened from Notion are separate decisions. Keeping that distinction prevents a useful work rule from becoming an uncontrolled global rule.

Figma routing

Figma is particularly sensitive to inconsistent routing because editing sessions are interactive. A document may load through one path while assets or live collaboration traffic use another. After adding the primary Figma domain, open a file in the browser, wait for layers and thumbnails to finish loading, edit a text object, add a comment, and invite or observe another collaborator if possible. Watch the connection panel while performing each action. If the file opens but multiplayer updates lag, check whether the relevant connection is going DIRECT or switching between groups.

Figma also interacts with fonts and plugins. A missing local font is not necessarily a proxy issue, and a plugin’s API may use a domain that is independent of Figma. Test the base editor first. Only after the editor is stable should you decide whether a plugin or external asset domain belongs in the work policy. This staged method prevents you from hiding an application bug behind an unnecessarily broad proxy rule.

Miro routing

Miro boards can generate many requests because they contain images, documents, previews, comments, and real-time cursor or board events. Test a board with several object types rather than an empty board. Confirm that you can pan and zoom smoothly, create a shape, upload a small image, open a comment, and refresh the page without losing the session. If the board is visible but changes do not synchronize, the connection log is more useful than repeatedly changing DNS settings.

Keep Miro’s static asset domains aligned with its main application policy when the logs show that they are required for the board. The same principle applies to mirostatic.com or other asset hosts: confirm the domain in your own traffic before adding it, and review it after major service changes. A policy group should solve a current workflow problem, not become a permanent list that nobody can explain.

Verify the Setup Without Disrupting Your Team

Testing should follow the same sequence that a remote worker follows during a real session. First check that local websites and company resources still use the intended direct route. Then open Notion, Figma, and Miro in separate tabs or applications. Look at the Clash connection view and identify the matched rule, selected policy group, and final node for each important hostname. If a domain is marked DIRECT when it should use the work group, the issue is usually rule order, a missing domain, or a client that bypasses the system proxy.

Test the profile: verify that the active configuration is the one you edited and that the client reports no YAML parsing error.
Test the route: open each service and confirm that its main requests match the intended policy group.
Test real actions: synchronize a Notion page, edit a Figma file, and update a Miro board instead of checking only the landing pages.
Test failure recovery: switch to another node and repeat one action. A change in behavior identifies node instability.
Test direct traffic: visit an internal site or local service and make sure it has not been unnecessarily sent through the proxy.

Use logs at an informative level while diagnosing, but avoid leaving extremely verbose logging enabled indefinitely. Logs can contain URLs, workspace identifiers, or other sensitive details. When sharing diagnostics with a provider or teammate, remove subscription tokens, account names, document URLs, and private IP addresses. A screenshot of a policy result is often enough; there is rarely a reason to publish a complete profile.

A reliable troubleshooting order:

Confirm the subscription has not expired and the node is online.
Confirm the system clock and certificate validation are correct.
Confirm the client is in Rule mode and the expected profile is active.
Read the connection log for the exact failing hostname.
Test a known-good node before changing DNS, TUN, or firewall settings.
Only then widen a domain rule or switch between system proxy and TUN mode.

DNS deserves special attention when a service partially loads. Browser DNS-over-HTTPS, operating-system resolvers, router filtering, and TUN DNS handling can all produce different answers. During diagnosis, use one clear resolution path and avoid changing several DNS features simultaneously. If a browser works but a desktop client fails, the desktop client may ignore system proxy settings and require TUN mode. If every application fails after TUN is enabled, temporarily disable it and check for conflicts with another VPN, endpoint security product, or virtual adapter.

Finally, document the working arrangement for your team. Record the client name, profile source, policy group purpose, preferred nodes, and the domains that were intentionally added. Do not distribute a private subscription URL in a public ticket or repository. A short internal note can save hours when a teammate reports that Figma opens but does not synchronize or that Miro assets remain blank after an update.

Maintain a Stable Workflow Over Time

Cloud applications change their infrastructure, and subscription profiles change their node lists. Treat the configuration as a small operational system rather than a one-time switch. Update the subscription on a reasonable schedule, but keep a known-good backup before applying major changes. After an update, run a quick smoke test: open one Notion page, edit one Figma object, and make one Miro board change. This catches broken groups before they affect an important meeting.

Prefer meaningful group names and comments over clever but opaque configuration. A teammate should understand why a domain uses Work-Proxy and why an internal domain uses DIRECT. Review rules that have not matched any traffic for several weeks. Removing obsolete entries reduces maintenance and makes future debugging more direct. At the same time, do not remove a rarely used domain without checking whether it supports file downloads, authentication, or a seasonal project workflow.

There are also privacy and compliance considerations. A proxy changes the network path and may expose traffic metadata to the proxy provider. Use a provider with clear retention and security practices, avoid putting sensitive tokens into shared configuration files, and follow your employer’s policy for company data. Clash can improve connectivity and routing control, but it does not replace access controls, encrypted application sessions, or a company-approved security process.

Some competing proxy clients hide routing decisions behind a single global switch or require repeated manual changes for each application. That approach may be adequate for occasional browsing but becomes frustrating for teams that move between local services and several collaborative SaaS platforms every day. Clash offers a more transparent alternative: policy groups make node selection explicit, rule mode keeps unrelated traffic direct, connection logs show what actually happened, and TUN support covers applications that ignore system proxy settings. If you want that balance of control and workflow-friendly defaults, download Clash for free and start with a small, testable profile.