Clash Setup For Notion, Figma, And Miro Productivity

What This Setup Should Achieve

Notion, Figma, and Miro are all collaboration tools, but they do not behave like a single website. A page may load from one domain, authentication may use another, images and fonts may come from a content-delivery domain, and real-time editing may use persistent WebSocket connections. If Clash sends only the visible main domain through a proxy, the application can open while login, thumbnails, comments, or live cursors fail in the background.

A reliable productivity setup therefore needs more than a single DOMAIN-SUFFIX rule. It needs a predictable proxy group, explicit rules for the three workspaces, direct access for local services, and a maintenance routine for subscriptions and rule providers. The objective is not to proxy every connection. The objective is to give collaboration traffic a stable path while keeping domestic websites, printers, file shares, and other local resources on DIRECT.

There are four practical requirements:

• Separate work traffic from general traffic. Notion, Figma, and Miro should use a dedicated policy group instead of sharing an unstable automatic group with video, downloads, and miscellaneous browsing.
• Cover the full service family. Match the product's root domain and subdomains, then add only the supporting domains confirmed in Clash logs. Avoid copying huge third-party rule lists without checking what they contain.
• Keep local traffic direct. Private IP ranges, localhost, router addresses, and office devices should not be sent through a remote node.
• Verify long-lived connections. A successful page load does not prove that comments, presence indicators, multiplayer boards, or Figma file updates are using the intended outbound.

Build a Dedicated Productivity Proxy Group

Start by creating a group whose purpose is clear. A group named Work or Productivity is easier to inspect than a generic group containing dozens of unrelated nodes. In a GUI client such as Clash Verge, Clash Verge Rev, or another mihomo-based client, the exact menu names vary, but the relevant configuration is normally under the profile editor, proxy groups, or YAML configuration.

A manual selector is the best starting point because it makes testing transparent. Choose a node yourself, open a Notion page, edit a Figma file, and move objects on a Miro board. Once the workflow is stable, you can replace the selector with url-test or keep the selector as the parent group for more control.

proxy-groups:
  - name: Productivity
    type: select
    proxies:
      - Work-A
      - Work-B
      - Work-C
      - DIRECT

  - name: Proxy
    type: select
    proxies:
      - Productivity
      - Work-A
      - Work-B
      - DIRECT

The node names above are placeholders. Replace them with names that already exist in your imported profile. A configuration fails validation when a proxy group references a name that is not defined in the proxies section or supplied by a proxy provider.

If you want automatic selection, use a small test group rather than testing every node in the subscription. A large subscription may contain nodes that respond quickly to an HTTP request but perform poorly with WebSocket traffic or sustained file transfers.

proxy-groups:
  - name: Productivity Auto
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    proxies:
      - Work-A
      - Work-B
      - Work-C

The test URL measures reachability to that URL, not the actual quality of Notion, Figma, or Miro. The interval: 300 value means the group checks every five minutes, while tolerance: 80 prevents frequent switching when two nodes have similar results. For collaborative work, avoiding sudden node changes is often more valuable than selecting the absolute lowest ping.

Select Nodes for Stability, Not Just Ping

For document editing and design collaboration, evaluate three things separately. First, check whether the application loads consistently over several minutes. Second, create a harmless test change and confirm that it saves or synchronizes. Third, leave the application open while observing whether the connection remains active when the network is idle. A node with a 90 ms test result but repeated reconnects is worse for a two-hour design session than a stable node with a 160 ms result.

• Prefer a node with consistent latency rather than one occasional minimum result.
• Test during the hours when the team actually works; evening congestion can change the result substantially.
• Keep at least two backup nodes in the same general region or route family.
• Do not use a download-optimized or heavily shared node as the default for real-time editing.
• When a service offers region-specific content or storage behavior, test a node in the intended region before standardizing it.

Write Rules for Notion, Figma, and Miro

Clash evaluates rules from top to bottom. The first matching rule wins, so service-specific rules must appear before broad rules such as GEOSITE,cn,DIRECT or a final MATCH,Proxy. Use DOMAIN-SUFFIX for a product root domain because it matches both the root and its subdomains. A plain DOMAIN rule matches only one exact hostname.

The following example sends the three primary service families to Productivity. It also keeps local networks direct and leaves the rest of the profile's normal routing behavior intact.

rules:
  - DOMAIN-SUFFIX,notion.so,Productivity
  - DOMAIN-SUFFIX,notion.site,Productivity
  - DOMAIN-SUFFIX,figma.com,Productivity
  - DOMAIN-SUFFIX,miro.com,Productivity

  - DOMAIN,localhost,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

  - MATCH,Proxy

The exact supporting domains can vary with the product, login method, browser, and current service architecture. Do not assume that every request displayed while the application is open belongs to the same provider. Analytics, fonts, error reporting, payment pages, and embedded content may be separate services. If a primary page opens but a specific function fails, inspect the Clash connection or log panel while reproducing only that function. Add a narrow domain rule only after identifying a repeated and necessary request.

Do not add DOMAIN-KEYWORD,figma or similarly broad keyword rules unless there is a specific reason. Keyword matching can catch unrelated hostnames that merely contain the same text. It can also make later troubleshooting difficult because you no longer know why a request entered the productivity group.

Understand DNS and TUN Effects

In system proxy mode, many desktop applications follow HTTP or SOCKS settings, but not every process does. TUN mode captures traffic at the network layer and is usually more suitable when a browser or application ignores the system proxy. When TUN is enabled in a mihomo-based client, options such as automatic route installation, interface detection, and DNS hijacking determine how completely traffic is captured.

DNS handling also affects rule matching. Fake-IP mode may return addresses from the 198.18.0.0/16 range, which is normal for a Clash DNS design. If the application resolves a hostname outside Clash, domain rules may not behave as expected, especially when the program opens direct IP connections. Enable TUN and DNS interception only after confirming that the client has the required administrator or system permissions, and exclude local networks if the client provides a suitable setting.

Verify Editing, Sync, and Fallback Behavior

Testing should reproduce the real workflow instead of checking only whether the homepage loads. Use one service at a time and keep the Clash log panel visible. The log normally shows the requested hostname, the selected rule or rule provider, and the outbound policy. This is more useful than guessing from the browser address bar.

1. Import or update the profile, select the Productivity group, and enable the intended system proxy or TUN mode. Confirm that no second VPN or proxy application is active.
2. Open a Notion workspace, navigate between two pages, edit a small sentence, and wait for the saved or synchronized state. Refresh only after the change appears to be stored.
3. Open a Figma file, zoom and pan around a large frame, make a reversible change, and observe whether assets and collaborators update without repeated loading indicators.
4. Open a Miro board, move an object, add a temporary note, and invite no one for the test. Confirm that the board remains interactive after several minutes of inactivity.
5. Inspect the Clash logs and verify that the main service requests match the intended domain rules and use Productivity, not an unexpected fallback group.
6. Turn the productivity group off temporarily or select a known backup node, then repeat one small action. This distinguishes a routing problem from a node-specific problem.

When a function fails, record the hostname and timing before changing several settings at once. If the page loads but the editor cannot connect, the missing request may be a WebSocket endpoint or a separate API domain. If the editor works but images are absent, inspect the image request separately. If everything works until TUN is enabled, check route conflicts, DNS hijacking, and another VPN driver rather than adding random domain rules.

Browser extensions can complicate this test. Disable extensions that provide their own VPN, DNS, privacy relay, or proxy behavior, and check whether the browser has secure DNS enabled independently of Clash. On desktop systems, a browser may also preserve connections from before a rule change. Close the relevant tabs or restart the browser after editing the profile.

Maintain the Profile Without Breaking Workdays

A productivity profile should be easy to update and easy to roll back. Before changing a provider URL, save a copy of the working configuration without exposing the subscription credential. Keep the provider URL private; it commonly contains an account token and should not be pasted into screenshots, issue reports, or shared configuration files.

Update the subscription when the provider publishes a new node list, but do not assume that an update improves the selected route. After each update, inspect whether the Productivity group still exists, whether its referenced proxy names are unchanged, and whether rule providers have finished downloading. Some profiles replace group names or overwrite local additions during a full update.

• Use an interval that fits your usage. A daily update is usually enough for a work profile. Very short intervals create unnecessary requests and can make troubleshooting harder.
• Keep local overrides separate. If the client supports a patch or merge section, place custom rules and groups there instead of editing generated provider data directly.
• Review rule order after updates. A broad domain or geosite rule placed above the productivity rules can silently send collaboration traffic to the wrong outbound.
• Remove dead nodes. A group full of expired entries makes automatic testing slower and increases the chance of selecting a node that accepts connections but cannot sustain them.
• Retest after core changes. A new mihomo version, TUN implementation, or DNS mode can change behavior even when the YAML file is unchanged.

Use a Small Change-and-Rollback Process

Change one variable at a time: first the node, then the group, then a rule, and finally TUN or DNS settings if needed. After each change, repeat one Notion save, one Figma file operation, and one Miro board interaction. If the result becomes worse, revert the last change instead of adding another exception.

For a team computer, keep a fallback profile that uses the normal proxy group and standard system proxy mode. It may not be optimized for these applications, but it gives you a known comparison point. If both the primary and fallback profiles fail, the issue is more likely to be the network, account, service, or subscription than the productivity rule set.

Recommended Configuration Checklist

Before relying on Clash for a deadline or client meeting, run through this short checklist:

• The imported profile loads without YAML or proxy-name errors.
• The dedicated Productivity group contains at least one tested primary node and one tested backup node.
• Notion, Figma, and Miro rules appear above broad domestic, geosite, or catch-all rules.
• Published pages and supporting domains are added only when logs show they are required.
• Private IP ranges, localhost, local hostnames, and office devices use DIRECT.
• System proxy and TUN are not enabled simultaneously in conflicting clients.
• DNS requests are handled by the intended Clash DNS path when TUN mode is active.
• A subscription update does not remove the custom group or change its proxy references.
• The workflow has been tested on the actual browser and operating system used for work.

For a client-specific installation walkthrough and platform permission notes, view the tutorial. To choose or install a suitable Clash client, go to downloads.

Use the Right Clash Client

A current mihomo-based client provides the rule groups, TUN controls, DNS handling, and log visibility needed for this workflow. Select the platform build first, then import your subscription and apply the productivity rules from a local override or profile editor.

Get Clash View Tutorial