Clash Workflow Setup for Notion, Figma, and Miro

Define the workflow before writing rules

Notion, Figma, and Miro are not single-domain applications. Each one may use separate web domains, API endpoints, authentication services, file storage, telemetry, fonts, update services, and embedded content providers. A rule that matches only notion.so, figma.com, or miro.com may therefore appear to work while some pages, images, comments, or synchronization requests still fail.

A reliable Clash workflow starts with a clear traffic policy rather than a long list of guessed domains. The usual goal for remote work is to send collaboration traffic through a stable proxy group, keep domestic services direct, and avoid forcing every connection through the proxy. This reduces latency for local services and prevents unrelated applications from consuming proxy bandwidth.

Before changing the configuration, write down the behavior you actually need:

• Work applications: Notion, Figma, Miro, and their browser tabs should use a dependable proxy group.
• Domestic services: Local banking, government, payment, delivery, and nearby media services should normally use DIRECT.
• Other international services: They can use a general proxy group, but should not automatically inherit the collaboration group unless that is intentional.
• Uncertain traffic: It should go to a final fallback policy instead of being silently rejected.
• Local network traffic: Private IP ranges, printers, file shares, and router interfaces should remain direct.

Choose the traffic capture method

System proxy mode is a good starting point on Windows and macOS when the applications respect HTTP or SOCKS proxy settings. It is easy to inspect, easy to disable, and usually sufficient for browser-based Notion, Figma, and Miro sessions. A common mihomo configuration uses mixed-port: 7890, allowing HTTP and SOCKS5 clients to connect through the same local port.

TUN mode captures traffic from applications that ignore the system proxy, including some desktop clients, helper processes, command-line tools, and embedded network components. It can improve coverage, but it also introduces a virtual interface, route handling, DNS interception, and additional permissions. If TUN is enabled, verify that local network access and DNS behavior still match your requirements.

Build a dedicated collaboration policy

Do not place all nodes directly in every application rule. Create a policy group with a meaningful name, such as Collaboration, and put suitable nodes or an automatic selection group inside it. This gives Notion, Figma, and Miro one control point. If a node becomes slow during a design review, you can change the group once instead of editing several rules.

A practical configuration often has three layers: a manually selectable group for emergency switching, an automatic health-check group for normal use, and a collaboration group that points to either of them. The exact group names may differ between subscriptions, so adapt the example to the names already present in your imported configuration.

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

  - name: Collaboration
    type: select
    proxies:
      - Auto Select
      - Node-A
      - Node-B
      - DIRECT

  - name: Global Fallback
    type: select
    proxies:
      - Auto Select
      - Node-A
      - DIRECT

The url-test group measures reachability and delay to its test URL, not the actual response time of Notion, Figma, or Miro. A node with the lowest test latency may still perform poorly with a large Figma file or a Miro board containing many images. Use automatic selection as a starting point, then switch manually when real work shows a difference.

Separate application rules from general rules

Clash evaluates rules from top to bottom and uses the first matching rule. Application-specific rules must therefore appear before broad rules such as country-based direct rules, large catch-all proxy rules, or MATCH. If a broad rule is placed first, the later Notion, Figma, and Miro entries will never be reached.

For domain-based routing, use DOMAIN-SUFFIX for the primary service domains and add known supporting domains only when logs confirm that they are required. Avoid copying an unverified domain list from an unrelated configuration. Service infrastructure changes over time, and an unnecessarily broad suffix can route unrelated traffic through the proxy.

rules:
  # Collaboration services: keep these above country and fallback rules
  - DOMAIN-SUFFIX,notion.so,Collaboration
  - DOMAIN-SUFFIX,notion.site,Collaboration
  - DOMAIN-SUFFIX,figma.com,Collaboration
  - DOMAIN-SUFFIX,figmausercontent.com,Collaboration
  - DOMAIN-SUFFIX,miro.com,Collaboration

  # Private and local networks
  - 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

  # Your normal domestic rules or rule providers follow here
  - GEOIP,CN,DIRECT
  - MATCH,Global Fallback

The example is a starting structure, not a complete production rule set. If the subscription already supplies rule providers and a final MATCH rule, add local overrides in the supported way rather than duplicating the whole configuration. Some clients regenerate subscription files during an update, so hand-editing the downloaded YAML may be temporary.

Keep domestic traffic direct without breaking collaboration

A common split-tunneling structure uses application rules first, private-network rules next, domestic rules after that, and a final fallback at the bottom. This ordering matters because a collaboration service may resolve to an address associated with a local network or a shared content provider. The application rule should decide the route based on the requested domain before a broad IP or geography rule overrides it.

Private-network exclusions are especially important with TUN. Without them, a request to a router such as 192.168.1.1, an office NAS, or a local printer may be captured by the virtual interface and sent toward a proxy group. Add the correct private ranges for your environment, but do not assume that every corporate network uses the same subnet.

Configure DNS and connection behavior

DNS is part of the routing workflow. If the resolver returns an unsuitable address, the rule engine may appear to be wrong even when the policy is correct. A stable setup should answer three questions: which component resolves the domain, whether the DNS request is intercepted by TUN, and whether the returned address is used directly or only for rule matching.

For a mihomo-based configuration, fake-IP mode can provide consistent domain-based routing and is often useful with TUN. Redir-host mode may be easier to understand in some environments, but it can expose different DNS behavior across applications. Do not switch modes casually while troubleshooting because the change affects caches, exclusions, and application behavior.

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback:
    - https://1.0.0.1/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'

The DNS values above are examples, not universal recommendations. Select resolvers that are reachable and acceptable in your network. If encrypted DNS endpoints themselves are inaccessible, the proxy core may repeatedly retry and make ordinary browsing feel slow. A configuration should also account for local hostnames and services that must not receive fake IP addresses.

Understand proxy DNS and direct DNS

When a collaboration domain is routed through a proxy, resolving it through a local ISP resolver can produce a result that is unsuitable for the remote connection. Conversely, sending every domestic lookup through a remote resolver may add delay and expose more queries than necessary. The correct balance depends on the network and the provider’s routing policy.

When testing, compare the behavior of the application rule with and without DNS changes. If switching the proxy node fixes the connection but changing DNS does not, the problem may be node quality or remote routing. If every node fails for the same domain while unrelated sites work, inspect DNS, certificate errors, and the response shown in the connection log.

• Clear the browser’s DNS cache after changing fake-IP or resolver settings.
• Restart the desktop application if it caches resolved addresses internally.
• Check that fake-ip-filter includes local domains used by printers, intranet pages, or office tools.
• Do not add a domain to the fake-IP filter merely because one request failed; confirm the domain’s actual role first.
• Keep IPv6 disabled only when the network or rule set cannot handle IPv6 consistently.

Test Notion, Figma, and Miro in real sessions

Testing only whether the home page opens is not enough. A collaboration workflow uses authentication, API requests, WebSocket or long-lived connections, file downloads, image previews, comments, and synchronization. Test each application with the exact actions performed during a normal workday.

Keep the Clash connection log open while performing each test. Confirm that the domain is matched by the intended rule and that the selected policy is actually Collaboration. A page that loads from browser cache can hide a routing problem, so use a hard refresh or open a private window when checking sign-in and asset delivery.

If the browser works but a desktop client fails, compare system proxy mode and TUN mode. The client may use a helper process, QUIC, WebSocket, or a platform networking API that does not follow the browser’s proxy settings. Do not immediately add every observed domain to the rules. First identify whether the request is an authentication endpoint, an asset host, a telemetry endpoint, or an unrelated browser extension.

Diagnose slow synchronization and random disconnections

Slow synchronization is not always caused by insufficient bandwidth. A remote-work session can degrade when the selected node has unstable packet loss, the health-check URL does not represent the application, DNS changes between requests, or a rule sends part of one workflow direct and another part through the proxy. Check the timestamp of the failure and inspect the requests immediately before it.

• Only one node fails: Switch the Collaboration group to another node and compare packet loss, handshake time, and file transfer behavior.
• All nodes fail: Check DNS, the service status, local firewall rules, and whether the application requires TUN.
• Pages load but edits do not sync: Inspect WebSocket or long-lived connection entries and confirm that the selected rule covers the relevant host.
• Images or exports fail: Look for separate asset or download domains rather than assuming the main application domain handles them.
• Local services fail after TUN is enabled: Recheck private CIDR exclusions, DNS filters, and the client’s LAN access option.

For reproducible testing, change one variable at a time. Keep the same browser, network, account, and file while comparing two proxy nodes. Then compare system proxy mode with TUN only after the node test is complete. This prevents a DNS change, node change, and routing change from being mixed into one inconclusive test.

Maintain the configuration after import

Subscriptions can replace generated YAML, update proxy names, or change the structure of policy groups. A local override that refers to Auto Select may stop working if the provider renames that group. After every subscription update, verify that the collaboration group still exists, the rules still appear in the expected order, and the final fallback remains present.

Keep a small change record with the date, the edited group name, the rules added, and the reason for each exception. This makes later troubleshooting much faster than relying on memory. Do not store complete subscription URLs in screenshots, public notes, or shared design documents; the token is usually sufficient to access the account’s proxy configuration.

Workflow: Remote collaboration
Mode: rule
Capture: system proxy; TUN only for desktop clients
Collaboration policy: Collaboration
Domestic policy: DIRECT
Local exclusions: 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
Last test: Notion edit, Figma file sync, Miro comment
Last change: added confirmed asset domain after connection-log review

Use the smallest rule set that satisfies the workflow. Three accurate domain rules and a reliable fallback are easier to maintain than hundreds of copied entries. Review the configuration after major application updates, browser changes, subscription refreshes, or network migrations. If the workflow remains stable for several sessions, avoid changing DNS, TUN, and proxy groups without a concrete reason.