Clash Setup for Notion, Figma, and Miro: Smarter Work Routing

Route only the work services you need

Notion, Figma, and Miro can all be useful in a remote-work setup, but that does not mean every website or application on your computer should use the same proxy. A more predictable approach is to route only the collaboration services you want through a dedicated proxy group, while leaving the rest of your configuration’s routing behavior intact.

Clash and mihomo evaluate rules in order. The first rule that matches a connection determines its policy, so the position of a rule matters as much as the domain it names. A rule for a work service must appear before a broader rule that would already match it, such as a catch-all or a general rule sending traffic to another group. The final MATCH rule is commonly used as the fallback and should normally remain at the end.

Start by checking the configuration you already use. A subscription may provide its own rules, proxy groups, or rule providers. If you append a new rule below a rule that already captures the same traffic, the new rule may never be reached. Avoid replacing a working subscription configuration with a small example: use the example as a guide for a supported override or merge workflow, and keep a backup before editing.

Add narrow domain rules for Notion, Figma, and Miro

For ordinary domain-based routing, mihomo supports rules such as DOMAIN-SUFFIX and DOMAIN. A suffix rule matches the named domain and its subdomains; an exact-domain rule matches only the specified host. These rules do not mean “proxy the whole website” in every possible sense: a service can load resources from several hosts, and those hosts can change as a product evolves.

As a starting point, the following example routes commonly associated domains through a group named Work-Proxy. Treat the domain list as a testable baseline, not a permanent allowlist of every endpoint used by each service. Confirm which domains your current version and workflow actually contact before adding more.

proxy-groups:
  - name: Work-Proxy
    type: select
    proxies:
      - "Region A"
      - "Region B"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,notion.so,Work-Proxy
  - DOMAIN-SUFFIX,notion.site,Work-Proxy
  - DOMAIN-SUFFIX,notion-static.com,Work-Proxy
  - DOMAIN-SUFFIX,notionusercontent.com,Work-Proxy
  - DOMAIN-SUFFIX,figma.com,Work-Proxy
  - DOMAIN-SUFFIX,figmausercontent.com,Work-Proxy
  - DOMAIN-SUFFIX,figma-files.com,Work-Proxy
  - DOMAIN-SUFFIX,miro.com,Work-Proxy
  - DOMAIN-SUFFIX,mirostatic.com,Work-Proxy
  - DOMAIN-SUFFIX,miroapp.com,Work-Proxy
  # Keep the configuration's existing rules below this point.

This is a fragment to adapt, not necessarily a complete configuration file. If your profile already defines proxy-groups or rules, do not create a second key with the same name at the same YAML level. Duplicate keys can be rejected, ignored, or handled inconsistently by parsers. Add the group to the existing group list and insert the service rules into the existing rule list using your client’s supported merge or override feature.

The proxy names Region A and Region B are placeholders. Replace them with names that exist in your actual configuration, preserving spelling and punctuation. A rule that refers to a nonexistent group may fail validation or behave differently from what you intended. If you already have a suitable group, you can use that group name instead of adding another one.

Avoid broad rules for shared infrastructure

When an application fails to load, it can be tempting to add a rule for a large hosting, analytics, or content-delivery domain. That can send unrelated websites through the work proxy and make future troubleshooting harder. First inspect the client’s Connections view or logs while opening the affected feature. Note the requested hostname and the rule or policy that matched it. Add a new rule only when you have a reasonable basis for associating that host with the service.

If a product uses a host shared with other services, consider whether an exact DOMAIN rule is safer than a broad suffix. If the host is an unstable third-party endpoint, check whether the client or subscription supports maintained rule providers rather than accumulating guesses in a local list. Keep any provider or custom rule ahead of broad fallbacks, and check its update behavior before relying on it.

Apply the rules safely in your Clash client

Clash Verge Rev and other mihomo-based clients can differ in how they handle profiles, overrides, merges, and core settings. Menu labels and available features can also change between releases. The important distinction is between editing the source subscription and changing the configuration that the core actually runs. A subscription refresh may overwrite direct edits to a downloaded profile, so use a persistent local override or merge mechanism when your client provides one.

1. Export or copy the current working configuration, and record the profile name and current proxy group selections.
2. Open the profile’s configuration or override controls in the client. Check the current client documentation if you are unsure whether a field is merged, replaced, or generated.
3. Add or update the Work-Proxy group using real proxy names from the profile. Add the service rules near the top of the existing rules, before any rule that would capture the same domains.
4. Save or apply the change, then check the client’s configuration validation or core log for YAML errors, missing groups, or unsupported fields.
5. Confirm the running core is using the updated profile. A saved edit that was not activated will not affect live connections.

Some clients let you edit a profile directly; others generate a runtime configuration from a subscription and separate overrides. Do not assume that a menu called “Merge” accepts an entire configuration file, or that a script designed for one client will work in another. If you are editing a generated configuration, check the preview or runtime configuration after applying the change. Verify that the new group exists once, that each rule references the correct name, and that the original fallback rules remain present.

Menu paths vary, but the checks are consistent: look for the profile’s edit, rules, merge, or override controls; find the generated configuration preview if available; and review the core logs after activation. If the client reports a parse error, revert to the backup and correct the reported YAML location before making other changes. Changing DNS, TUN, and routing rules all at once makes it difficult to identify which change caused a failure.

For an initial browser test, you usually do not need to enable TUN. System proxy mode can route traffic from applications that honor the operating system’s proxy settings. TUN mode can capture more application traffic, but it also introduces virtual-adapter, routing, permission, and DNS considerations. If you do use TUN, test it separately and check compatibility with corporate VPN software and endpoint-security policies.

Test matching and fix common workflow problems

Test one service at a time so you can tell whether the expected rule is being used. Select a known node in Work-Proxy, open the service in a fresh browser tab, and inspect the client’s Connections view or logs. Look for the requested host, the selected policy, and the resulting connection status. A page that happens to load is not enough to prove that every relevant connection followed the intended route.

• Notion: Open a page, sign in if required, and check whether the page content and attached images load. If the page shell appears but images or embedded content do not, inspect the failed hostnames before extending the rules.
• Figma: Open a file and test a change that should save. Check that the file loads, collaboration features connect, and the save state updates. A cached file may appear usable even when a new network request is failing.
• Miro: Open a board, then test loading a new board or making a small reversible edit. Check connection logs if the board opens but collaboration or media content does not update.

If a connection shows DIRECT or another group instead of Work-Proxy, check rule order first. Then confirm that the actual requested hostname matches the rule and that the core is running the profile you edited. If the expected rule appears but the connection fails, test another node in the same group before changing the domain list. The cause may be the selected route, the service, an authentication issue, or a network restriction rather than a rule mismatch.

Browser DNS and connection reuse can make a rule change appear inconsistent. A browser may keep an existing connection open after the profile changes, or show cached content without making a new request. Apply the profile, close and reopen the affected tab, and inspect fresh connections. If needed, restart the browser after confirming that doing so will not interrupt unsaved work. Avoid clearing all browser data as a first troubleshooting step.

Also distinguish a routing failure from an account or application failure. A successful TCP connection does not prove that sign-in, WebSocket activity, file uploads, or real-time collaboration are working. Check the application’s own status indicators and logs alongside Clash’s connection details. Do not disable security checks or change system-wide DNS simply because one page did not load.

Choose a reliable work route and maintain it

A low latency-test number is useful for narrowing down candidates, but it does not guarantee that Notion, Figma, or Miro will perform well. The test URL may use a different destination from the application, and results can vary with server load, time of day, routing, and your local network. Compare a few available nodes using the same test method, then validate the actual work tasks that matter: opening a board, loading assets, saving a change, and maintaining a live collaboration session.

For a small team or individual setup, a manual select group is often easier to understand than an automatic strategy. It lets you compare two or three provider nodes and use DIRECT as a diagnostic option, where direct access is appropriate. If your subscription already supplies an automatic group, check how it selects nodes and whether that group is stable before adding another layer. Avoid nesting groups without a clear reason: it can make logs harder to interpret and manual troubleshooting slower.

Keep the number of work-specific rules small and documented. Record why each extra domain was added, which service or feature needed it, and the date you last verified it. After a client or core update, confirm that the profile still validates and that the three services still match the intended group. After a subscription refresh, check that the override remains active and that provider-supplied rules have not changed the effective order.

For organization-managed devices, follow your company’s proxy and VPN policies. A routing rule is not a substitute for access approval, and sending work traffic through an unapproved node can expose connection metadata to an unintended provider. Keep subscription URLs, authentication tokens, private board links, and exported configurations out of public logs or screenshots. Redact credentials before sharing diagnostic information.

If you are setting up a client for the first time, review the installation and profile-import steps before adding custom routing. Keep the initial setup simple, confirm that the subscription works, and add one work-service rule at a time. For broader configuration syntax, consult the YAML reference; for a guided setup, see the setup tutorial.