What This Clash Workflow Is Designed to Solve
Notion, Figma, and Miro are all browser-friendly collaboration tools, but they do not behave like ordinary static websites. A Notion workspace may load its page shell from one group of domains, retrieve images and files from a content delivery network, and keep realtime editing traffic open through another endpoint. Figma combines authentication, project metadata, fonts, thumbnails, comments, and live multiplayer events. Miro adds board assets, embedded media, cursors, and persistent collaboration channels. When one part of that chain is sent through a slow or unstable route, the application can appear half-working: the dashboard opens, but a board remains blank; text loads, but images show placeholders; a Figma file opens, but live cursors stop moving.
The practical goal of a Clash split-tunneling setup is not to proxy every connection indiscriminately. It is to create a predictable policy: collaboration traffic uses a node that can reach the required services reliably, while local websites, banking pages, printers, company resources, and domestic services stay on DIRECT. This reduces unnecessary latency and prevents a broad global proxy rule from making local browsing slower. It also makes troubleshooting easier because the connection log can answer three useful questions: which hostname was contacted, which rule matched, and which outbound group handled the request.
This guide is written for desktop users running a modern Mihomo-based client such as Clash Verge Rev, Mihomo Party, or another Clash-compatible application. The interface names vary, but the underlying ideas remain the same: import a working profile, place specific rules before broad rules, choose a stable proxy group, and enable TUN only when ordinary system proxy coverage is not enough. You do not need to edit every generated line in a provider profile. In most cases, a small override or ruleset is safer than rewriting the subscription manually.
Important distinction: Notion, Figma, and Miro are commercial services with changing infrastructure. Treat hostname examples in this article as a starting point, not a permanent guarantee. Confirm the actual domains in Clash’s connection log, especially after a desktop app update or when a team uses custom fonts, cloud storage, SSO, or embedded content.
Prepare the Client, Profile, and Proxy Group
Before writing rules, make sure the Clash client itself is in a known state. A surprising number of “Notion is slow” or “Figma cannot connect” reports are really caused by an expired subscription, an overloaded default node, two proxy engines fighting over the same mixed port, or a TUN service that lost permission after an operating system update. Start with one active Clash-compatible client and temporarily close other VPNs, DNS filters, and transparent proxy tools. Multiple network interception layers can make the final route impossible to interpret.
- Update the profile: refresh the subscription and confirm that the YAML loads without an error. Check that the profile contains usable
proxies,proxy-groups, andrulessections rather than only a partial provider fragment. - Choose a collaboration group: select a stable proxy group for Notion, Figma, and Miro instead of blindly using the fastest latency result. A node with slightly higher ping but consistent packet delivery is usually better for large Figma files and long Miro sessions.
- Test the group: open each service and watch the Clash connection panel. Record the hostnames that appear during login, workspace loading, image retrieval, and realtime editing. Do not rely only on the first page URL shown in the browser address bar.
- Save a backup: export the current profile or copy the override rules to a separate text file. Provider updates can replace manual edits, and a backup makes it easy to compare a working configuration with a later broken one.
For a first pass, create a dedicated group named something like COLLAB. It may contain several suitable nodes and a fallback option, but avoid putting every available node into the group. If the group changes nodes frequently, a persistent WebSocket or realtime session can be interrupted even though ordinary page loads continue. A manual selector is useful while diagnosing problems; after you identify reliable nodes, a health-tested group can reduce maintenance.
A minimal conceptual group might look like this:
proxy-groups:
- name: COLLAB
type: select
proxies:
- Preferred-Node
- Backup-Node
- DIRECT
The exact names must match the proxy names generated by your provider. Never paste this example over a complete subscription profile without checking its structure. If your client supports a graphical group editor, use that editor instead. The key idea is the separation of purpose: a collaboration group should not silently inherit an unstable streaming node simply because it scored well in a short speed test.
Build Domain Rules for Notion, Figma, and Miro
Rule order determines the result. Clash evaluates rules from top to bottom and stops at the first matching entry. A broad rule such as GEOIP,CN,DIRECT, a provider-specific shortcut, or a catch-all MATCH,DIRECT can therefore win before your collaboration domains are reached. Put service-specific rules above broad geographic, ad-blocking, and final-match rules. If a provider profile is regenerated, confirm that your override is still inserted in the effective configuration rather than merely saved in a local editor.
For many users, the following domain families are a reasonable initial policy:
- Notion: start with
DOMAIN-SUFFIX,notion.so,COLLABandDOMAIN-SUFFIX,notion.site,COLLAB. If your workspace uses a custom domain or external file services, inspect the connection list and add only the additional hosts that are genuinely required. - Figma: begin with
DOMAIN-SUFFIX,figma.com,COLLAB. Check separate connections for authentication, font loading, thumbnails, comments, and file assets before adding a CDN domain. Avoid copying a large community list that routes unrelated analytics and advertising hosts through the same node. - Miro: use
DOMAIN-SUFFIX,miro.com,COLLABas the first rule. Boards may contact asset, authentication, or collaboration endpoints that are not obvious from the visible board URL, so verify those endpoints through the live log.
In an override section, the rules could be represented as follows:
rules:
- DOMAIN-SUFFIX,notion.so,COLLAB
- DOMAIN-SUFFIX,notion.site,COLLAB
- DOMAIN-SUFFIX,figma.com,COLLAB
- DOMAIN-SUFFIX,miro.com,COLLAB
- MATCH,PROXY
This is a deliberately conservative example. Your existing profile may already define a rule provider or use a different final group. Keep the original policy for other traffic and insert the collaboration rules at the highest safe position. If your provider uses a ruleset, prefer a local ruleset or mixin that is explicitly designed to be loaded after the provider’s base rules. Avoid editing a subscription URL response directly because the next update may erase your changes.
Inspect Actual Hostnames Before Expanding the List
When a workspace opens but a particular feature fails, open Clash’s connections view and reproduce one action at a time. First sign in, then open a document, then upload an image, then start a comment or move an object. Filter the list by notion, figma, or miro, and note the rule that matched. A connection labelled DIRECT is not automatically wrong; it may be a local API, a harmless telemetry endpoint, or a resource that works better without a proxy. The useful signal is whether the failed feature corresponds to an endpoint that was routed inconsistently or closed during a node switch.
Use the narrowest matching rule available. DOMAIN-SUFFIX is normally easier to maintain than a long collection of individual subdomains, while DOMAIN is safer when a provider owns a broad domain with unrelated services. Do not add an IP address unless you have a strong reason. Cloud services change addresses frequently, and IP-based rules can become stale or accidentally capture other tenants hosted on the same network.
Debugging habit: change one rule at a time, reload the affected page, and compare the connection log. If adding ten domains fixes the issue, you still do not know which domain mattered. A smaller rule set is easier to audit, faster to update, and less likely to route unrelated traffic through a distant node.
Tune DNS and TUN Mode Without Creating New Problems
DNS is part of the routing decision, not a separate afterthought. If the operating system resolves a hostname through a local resolver while Clash expects to inspect the request through its own DNS engine, the client may receive an address that does not align with your rules. This is especially confusing when fake-IP mode, redirection, or a TUN stack is enabled. You may see a browser request going to an apparently local address even though the original hostname should have matched DOMAIN-SUFFIX,figma.com,COLLAB.
Start with a simple DNS design. Let the Clash-compatible core handle DNS when you use TUN or enhanced redirection, and avoid running several competing “secure DNS” layers during diagnosis. If your client supports fake-IP, make sure the fake-IP filter does not exclude the collaboration domains unintentionally. If you prefer redir-host or direct resolution, use it consistently enough that the connection log still shows meaningful hostnames. The correct choice depends on your operating system, client, and provider; the important point is that DNS mode and rule mode must agree.
System proxy mode is often sufficient for browser-based Notion, Figma, and Miro use. It is less reliable for desktop applications, helper processes, WebView components, background uploaders, and embedded tools that ignore operating system HTTP proxy settings. Enable TUN when you need broader coverage, but treat it as a controlled troubleshooting step rather than an automatic performance upgrade.
- Confirm ordinary proxy mode first: enable the client’s system proxy, select
COLLAB, and test the web versions in a clean browser window. - Enable TUN only if necessary: grant the requested administrator or system extension permission, then verify that the virtual interface is running and that no other VPN owns the default route.
- Review DNS settings: keep the Clash DNS engine, fake-IP settings, and TUN stack aligned. Clear the browser or application DNS cache after changing modes.
- Test non-browser traffic: open the Figma or Miro desktop app, perform a small edit, and watch whether the application process appears in the connection view.
- Return to a simpler mode if needed: if TUN introduces broken local printing, corporate access, or unstable DNS, disable it temporarily and add only the missing application coverage after identifying the cause.
Use exclusions carefully. Local network ranges, loopback addresses, printer subnets, and company resources may need to remain direct. At the same time, an overbroad bypass list can send collaboration traffic outside Clash without making that fact obvious. Check both the destination rule and the process or interface route. A TUN adapter can be active while a desktop app still uses its own proxy setting, and a browser can appear to work through system proxy while a background sync process remains direct.
Validate Performance With Real Collaboration Tasks
A successful homepage load is not enough to declare the setup finished. Notion performance should be tested by opening a page with images, toggling between subpages, uploading a modest attachment, and editing text for several minutes. Figma should be tested with a real design file rather than only the community gallery: load a file with fonts and images, zoom repeatedly, move an object, add a comment, and observe whether multiplayer presence stays current. Miro needs a board with several frames or embedded objects, plus a short period of simultaneous editing if your team is available.
Record the result in a small table or note. Useful measurements include the selected node, whether the feature worked, the matched rule, approximate delay before assets appeared, and whether the session survived a few minutes without reconnecting. Do not compare only raw ping. A node that answers an ICMP test quickly can still have poor international peering, congested upload capacity, or aggressive connection timeouts. Collaboration applications care about sustained delivery and connection stability as much as they care about the first byte.
| Test | What to observe | Likely interpretation |
|---|---|---|
| Workspace login | Authentication completes without repeated redirects | Identity and browser capture are working |
| File or board load | Images, fonts, and assets appear rather than placeholders | CDN and secondary endpoints are reachable |
| Live editing | Cursors, comments, and changes synchronize continuously | Long-lived collaboration connections are stable |
| Local browsing | Domestic pages and internal resources remain responsive | Split routing is avoiding unnecessary proxy use |
If a page works only after repeatedly refreshing, inspect node stability before expanding rules. If the connection log shows the same hostname switching between DIRECT and COLLAB, fix rule order or DNS consistency. If everything uses COLLAB but uploads stall, test another node and check whether the provider limits long connections or large transfers. If only the desktop app fails while the browser succeeds, enable TUN or configure the application’s own proxy support rather than adding random domains.
Do not use a node switch as a permanent fix. Changing nodes can hide a DNS, rule-order, or TUN-capture problem for one session. Once the service works, reproduce the same task twice and confirm the selected group, matched rule, and application process remain consistent.
Maintenance Checklist for Shared Desktops
Collaboration workstations are often shared by several people, so a configuration that works for one browser profile may still cause confusing support requests for everyone else. Keep the policy readable and add a short note explaining the purpose of COLLAB. If a team member sees a blank Figma canvas, ask them to capture the Clash connection log and the selected node before changing multiple settings. This preserves evidence and prevents a working rule from being replaced with a much broader proxy-all policy.
- Refresh the subscription on a schedule, but export or preserve local overrides before refreshing.
- Review the connection log after major Notion, Figma, Miro, or desktop client updates.
- Keep collaboration domains above broad
GEOIP, ad-blocking, and final-match rules. - Use one stable group for long editing sessions and avoid automatic node changes during active meetings.
- Check TUN permissions after operating system updates and confirm that local printers and internal services still work.
- Remove obsolete domains after testing so the configuration does not slowly become an unreviewed global proxy list.
The most useful Clash configuration is the one you can explain six weeks later. For Notion, Figma, and Miro, that usually means a small service-focused group, explicit domain rules, DNS settings that match the chosen capture mode, and TUN enabled only when browser proxying leaves a real gap. Many competing VPN-style tools hide these decisions behind a single global switch, which is convenient at first but makes local-route exceptions, desktop-app coverage, and failed realtime sessions difficult to diagnose. Clash Official Site keeps the workflow visible: readable rules, practical split-tunneling guidance, and client setup notes that help you verify each step instead of guessing. If you want to apply this collaboration-focused configuration with a compatible desktop client, you can download Clash Official Site and use this guide as your setup checklist.