Clash Notion, Figma & Miro Workflow Setup Best Practices

Why Notion, Figma, and Miro Need Deliberate Routing

Notion, Figma, and Miro are productivity tools, but they do not behave like ordinary websites. A single editing session may contact several application domains for authentication, document data, images, fonts, comments, real-time collaboration, analytics, and file delivery. Notion can open its workspace through one hostname and fetch an attachment from another. Figma may load the editor successfully while fonts, avatars, or asset previews use separate services. Miro can keep the board visible while collaboration events become unreliable because the WebSocket connection was sent through a poor route.

This is why simply turning on Global mode is rarely the best long-term solution. Global mode sends local services, cloud storage, package managers, video calls, and productivity traffic through the same proxy path. It may solve one access problem, but it can also add latency to every other application. A better Clash workflow uses Rule mode: domains that need the proxy use a suitable proxy group, while local services and trusted domestic destinations remain DIRECT.

The goal is not to force every Notion, Figma, or Miro request through one fixed server. The goal is to create a predictable policy that separates three types of traffic: collaboration services that need a stable international route, local resources that should remain fast, and unknown destinations that require a safe fallback. This arrangement makes troubleshooting easier because the Clash connection log can show exactly which rule and proxy group handled a request.

Before editing a profile, confirm that the client is based on a current Clash-compatible core such as Mihomo or another actively maintained distribution. Interface names differ between Clash Verge Rev, Mihomo clients, Clash for Android, and other front ends, but the important concepts remain the same: profiles, proxy groups, rule providers, DNS behavior, and system or TUN mode.

Build Proxy Groups for Real Work Sessions

A productivity workflow benefits from at least two useful groups rather than one enormous list of nodes. The first group should be a general selection group for normal web access. The second should be a stable work group intended for Notion, Figma, and Miro. You can use a manual select group when you want direct control, or a url-test group when the client should test candidates and select a responsive node. Some users also maintain a fallback group for cases where the preferred region is unavailable.

Latency alone is not enough to judge a node. A server may respond quickly to a short HTTP test but perform badly with sustained uploads, large Figma assets, or long-lived WebSocket connections. During selection, consider handshake time, packet loss, route consistency, and whether the node remains usable after ten or fifteen minutes. For team collaboration, a slightly slower but stable node is often better than a fast node that repeatedly disconnects while saving or synchronizing work.

If you edit YAML directly, keep group names simple and consistent. A policy group can refer to another group by its exact name, so a spelling difference can silently send traffic to the wrong destination. The following example is intentionally generic; replace the proxy names with names supplied by your subscription.

proxy-groups:
  - name: Work-Apps
    type: select
    proxies:
      - Tokyo-01
      - Singapore-02
      - Fallback
      - DIRECT

  - name: Fallback
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    proxies:
      - Tokyo-01
      - Singapore-02

  - name: Final
    type: select
    proxies:
      - Work-Apps
      - DIRECT

Do not add DIRECT to the work group merely because it is convenient. A direct option is useful for testing and for services that work reliably on the local network, but it can make an important collaboration domain bypass the intended route. If Figma loads through the proxy but fails in direct mode, the comparison is informative. Once you understand the behavior, choose the default that matches your actual network and subscription.

Use the client’s latency test as a first filter, then verify the selected node with a real task. Open a shared Figma file, move between frames, load remote fonts, and export a small asset. In Miro, open a board with images and invite another participant. In Notion, open pages containing images, databases, and comments. A node that passes a simple ping but fails these activities should not be the primary work node.

Route Notion, Figma, and Miro by Domain

Domain-based routing is more reliable than routing an entire desktop application by guesswork. Many desktop clients use browser components, shared system libraries, or separate helper processes. Process-based rules may therefore miss part of the session, while a domain rule can cover requests regardless of which application generated them. The trade-off is that you must maintain the list carefully and avoid assuming that every hostname containing a brand name belongs to the same service.

Begin by observing the connection panel while opening one application at a time. Clear or pause unrelated downloads, then load a Notion workspace, a Figma project, or a Miro board. Record the requested hostnames and the policy selected by Clash. Separate core application domains from telemetry, advertising, update, and content delivery domains. You do not need to route every analytics endpoint for the editor to work, and routing excessive third-party traffic can increase latency without improving collaboration.

A simple rules section might look like this:

rules:
  - DOMAIN-SUFFIX,notion.so,Work-Apps
  - DOMAIN-SUFFIX,notion.site,Work-Apps
  - DOMAIN-SUFFIX,figma.com,Work-Apps
  - DOMAIN-SUFFIX,figmausercontent.com,Work-Apps
  - DOMAIN-SUFFIX,miro.com,Work-Apps
  - DOMAIN-SUFFIX,mirostatic.com,Work-Apps
  - GEOIP,LAN,DIRECT
  - MATCH,Final

These examples are starting points, not a universal list. Service infrastructure changes, regional endpoints differ, and a provider may rewrite or merge rules. Check the actual connection log before adding a hostname. Prefer DOMAIN-SUFFIX when you control the scope and the entire domain family should use the same policy. Use an exact DOMAIN rule for a single known hostname. Avoid broad rules such as routing every cloud storage or content delivery domain through the proxy, because that can unintentionally capture unrelated services.

Rule order matters. Clash evaluates rules from top to bottom and uses the first matching rule. A broad direct rule placed above a specific Figma rule can prevent the Figma request from ever reaching Work-Apps. Similarly, a broad proxy rule near the top can capture local traffic that should remain direct. Put specific work-service rules before broad geographic, private-network, or final-match rules, and review the effective configuration if your client supports a rendered profile view.

Notion, Figma, and Miro may also rely on WebSocket connections for live updates. If the initial page opens but edits do not synchronize, inspect long-lived connections rather than only ordinary HTTPS requests. Confirm that the relevant hostname follows the same stable policy and that the selected node supports the required transport. Frequent node switching can interrupt a WebSocket even when ordinary page loads appear normal.

Keep DNS, TUN Mode, and Local Traffic Predictable

Domain rules depend on correct name resolution. If the operating system, browser, and Clash use different DNS paths, the connection log may not match what you expect. A browser can use its own secure DNS, an operating system can retain a stale answer, and a TUN interface can redirect traffic differently from a system-proxy-only setup. These differences are especially confusing when the editor loads but remote images or collaboration events fail.

For a clean test, decide which traffic-capture model you are using. System proxy mode is lightweight and works well for applications that respect the operating system proxy settings. TUN mode captures a wider range of traffic, including applications that ignore system proxy settings, but it requires more careful handling of DNS, virtual interfaces, permissions, and conflicts with other VPN tools. Do not enable multiple tunnel drivers at once while diagnosing a problem.

Local traffic should stay local whenever possible. Private network ranges, printers, local development servers, and internal dashboards often need DIRECT. If your team uses a local Git service, staging environment, or NAS, create explicit rules for those destinations rather than relying only on GeoIP classification. A domain hosted abroad can still point to an internal service through split DNS, while a locally hosted domain can be incorrectly treated as foreign by a generic rule set.

• Use GEOIP,LAN,DIRECT or the equivalent private-network rules supported by your core.
• Keep local development domains and RFC1918 addresses above the final catch-all rule.
• Check whether browser secure DNS is bypassing the resolver path during testing.
• Exclude competing VPN adapters or old proxy helpers if they intercept the same traffic.
• After editing DNS or rules, reload the profile and restart the affected application.

Performance tuning should be measured against real collaboration actions, not only a speed-test result. Record how long a board takes to open, whether a Figma file finishes loading its assets, whether Notion comments appear without a refresh, and whether a large export completes. If direct local traffic is slow, solve that separately instead of routing everything through the work node. If only one service is slow, inspect its domain policy and test a different node before increasing global timeouts.

Finally, document the working setup for your team. Note the preferred group, the fallback group, the domains that required explicit rules, and the date on which the profile was tested. Keep provider-specific secrets out of shared screenshots and repositories. When a provider changes nodes or a service changes its infrastructure, a short record lets another team member reproduce the test instead of rebuilding the configuration from memory.

A Repeatable Daily Checklist

A stable Clash workflow should require very little attention after the initial setup. Before an important design review or workshop, select the known work node, confirm that the client is in Rule mode, and open one representative Notion page, Figma file, and Miro board. This quick check catches expired subscriptions, overloaded nodes, and accidental mode changes before they interrupt a meeting.

When a problem appears, classify it before taking action. If every service is slow, test the selected node and local network first. If only one application fails, inspect its domains and policy. If the editor loads but synchronization stops, focus on WebSocket-related connections and node stability. If local websites become slow, review rule order and confirm that broad proxy rules have not captured domestic or private traffic.

Update subscriptions on a sensible schedule rather than repeatedly refreshing them during a live task. Frequent updates can replace node names, reset manual selections, or introduce a new rule provider while you are working. Keep a known-good profile export when your client supports it, and change one policy component at a time. This is particularly useful for teams that share a workflow across Windows, macOS, and Android but use different interfaces.

Compared with simple VPN applications that expose only one global switch, or browser extensions that cannot consistently handle desktop collaboration clients, Clash gives you transparent rule matching, selectable proxy groups, configurable DNS behavior, and a useful connection log. Those controls take a little more setup, but they prevent the common trade-off between reliable international collaboration and fast local traffic. If you want to apply this workflow with a maintained client and practical defaults, download Clash for free and build your work profile around the services you actually use.