Clash Notion and Figma Setup: Smarter Rules for Remote Work

1. Plan the routing: capture work apps without proxying everything

Notion and Figma do not need a proxy simply because they are used for remote work. The useful setup is narrower: send connections for those services to a policy group you can control, keep local destinations on DIRECT, and choose a proxy only when your network or the service requires it. This avoids turning a work-app problem into a whole-device routing change.

Clash evaluates rules in order for each connection that reaches its core. A domain rule can route a known service before a broader IP-based rule is considered. A final MATCH rule handles anything that did not match earlier rules. Therefore, a configuration that sends all remaining traffic to a proxy can still keep local traffic direct, provided the local rules appear above that fallback.

Separate three decisions that are often confused:

Traffic capture: The system proxy or TUN determines which app connections reach the core. A browser using the system proxy may be captured while a desktop app that ignores it is not.
Rule matching: The active configuration and core decide which rule applies. Rule mode is needed to test the rules below; Global mode does not provide the same rule-based behavior.
Outbound selection: A policy group chooses a proxy, another group, or DIRECT. A matching domain rule cannot make an unavailable node work.

Start with the client’s connection list. Open Notion or Figma, then check whether requests appear and which process, domain, rule, policy, and outbound are shown. If there is no connection record, changing domain rules is unlikely to fix the first problem: confirm system-proxy settings, app proxy support, or whether TUN is needed. Enabling TUN changes traffic capture and may require extra permissions, so do not turn it on as a substitute for checking the route.

2. Create a work-app policy and add narrow domain rules

A separate policy group makes it possible to change the route for Notion and Figma without editing the rest of the rules. In the example, Work Auto is the name of a proxy group that must already exist in the active configuration. Replace it with an actual group name, or list available proxy names directly. Policy names are exact references: a misspelling can make the configuration fail to load.

The following is a partial configuration example, not a complete subscription file. Merge it into the active configuration using the client’s supported editor or override feature. Keep only one top-level definition for each field, and do not overwrite subscription-provided nodes or groups accidentally.

mode: rule
log-level: info

proxy-groups:
  - name: Work Apps
    type: select
    proxies:
      - Work Auto
      - DIRECT

rules:
  # Keep local network destinations out of the proxy
  - DOMAIN,localhost,DIRECT
  - DOMAIN-SUFFIX,lan,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
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - IP-CIDR6,fe80::/10,DIRECT,no-resolve

  # Route known work-app domains through a selectable policy
  - DOMAIN-SUFFIX,notion.so,Work Apps
  - DOMAIN-SUFFIX,notion.site,Work Apps
  - DOMAIN-SUFFIX,notion-static.com,Work Apps
  - DOMAIN-SUFFIX,figma.com,Work Apps
  - DOMAIN-SUFFIX,figmausercontent.com,Work Apps

  # Add explicit company or local domains here, if required
  # - DOMAIN-SUFFIX,company.example,DIRECT

  # Route remaining destinations according to local IP geography
  - GEOIP,CN,DIRECT
  - MATCH,Work Apps

Domain suffix matching covers the named domain and its subdomains. For example, DOMAIN-SUFFIX,figma.com,Work Apps can match www.figma.com as well as the base domain. The list is a starting point, not a promise that every asset or API used by either product belongs to those suffixes. Services can change their endpoint domains, and a workspace may load content from additional infrastructure.

Use the connection list to discover what is actually missing. If the main page loads but images, comments, or collaboration features do not, note the unmatched destination domain and its selected rule. Add a narrowly scoped suffix only after confirming that the request belongs to the service. Avoid routing a broad cloud-provider domain through the work group just because one asset happened to use it; that could capture unrelated sites and applications.

Rule or policy	What it does	Check before using it
`DOMAIN-SUFFIX`	Matches a named domain and its subdomains	Confirm the observed domain belongs to the app
`GEOIP,CN,DIRECT`	Sends destinations identified as China by the GeoIP database directly	It is an IP-geography rule, not a general “local website” detector
`Work Apps`	Provides a selectable route for matched work-app traffic	Ensure its referenced groups or nodes exist
`MATCH,Work Apps`	Applies the chosen work-app policy to all remaining traffic	Use a different fallback if unmatched traffic should not use this group

If the intention is to proxy only Notion and Figma while sending all other unmatched traffic direct, change the last rule to MATCH,DIRECT. If a broader configuration already has a carefully designed fallback, preserve it instead of replacing it. The order of existing rules is part of the behavior, not cosmetic formatting.

3. Apply the rules: a practical setup and verification sequence

Use this sequence to avoid editing a file that the client later regenerates. Menu names vary between Clash Verge, Clash Verge Rev, Clash for Windows, ClashX, Clash for Android, and other clients. Look for the active profile’s configuration, edit, override, or rule-management controls rather than assuming every client has the same menu path.

Record the current setup. Note the client and core versions, active profile, current mode, and whether system proxy or TUN is enabled. Export or copy the active configuration before editing so you can revert if the core reports a parsing error.
Check the actual core. Confirm that the selected core supports the fields and rule types in use. A client name alone does not establish core compatibility. If the configuration uses a subscription, make changes in a supported override or merge location; a temporary edit to a generated runtime file may disappear at the next update.
Set Rule mode and confirm the entry path. Enable the system proxy for apps that honor it. Consider TUN only when a needed app does not use the system proxy and the client/core supports the required operating-system permissions. After applying the change, confirm that a test request appears in the connection list.
Add the policy group and rules. Verify that the referenced group name exists, put local and work-app rules above broad GeoIP or catch-all rules, and retain the configuration’s intended final fallback.
Validate and reload. Use the client’s configuration check if available, then reload the profile. Watch startup logs for YAML indentation, duplicate-key, missing-policy, or unsupported-field errors. A successful parse confirms syntax, not node reachability.
Test each route separately. Open Notion, then Figma, and inspect the connection list for the destination, matched rule, policy group, and final outbound. Test one known local destination as well. Make one change at a time so a result can be tied to the rule that caused it.

For a controlled test, first select DIRECT in Work Apps, then open the app and note whether the connection succeeds. Next select a known working proxy and repeat the same test. This comparison helps separate an access restriction or routing requirement from a general app, DNS, or account issue. If only one node fails, keep the rule and test a different node before changing the domain list.

Do not use a broad browser test as the only verification. A browser may have its own proxy settings, cached connections, or DNS cache, while the desktop client uses a different network path. Close and reopen the app between tests if it keeps existing connections. A connection that was established before a policy change may continue using its original outbound until it is closed.

4. Choose a node based on the work task, not just a speed label

Notion and Figma use more than one network request during a session. A page may load from one endpoint while fonts, images, file previews, or collaborative updates use others. A successful homepage therefore does not prove that every feature has a suitable route. When comparing nodes, keep the app, destination, and test conditions constant; otherwise, changes in Wi-Fi, service load, or an existing connection can make the comparison misleading.

Start by choosing a node that is reachable and stable from the current network. Then test a representative task: open a Notion page with the content you need, or load a Figma file and check whether its assets and collaboration features behave normally. Prefer consistent response and completed transfers over a single low latency number. A node with a slightly higher ping may be a better work choice if it avoids intermittent stalls or reconnects.

Observation	Possible interpretation	Next check
App does not appear in connections	The app may bypass the system proxy, or traffic capture may not include it	Check app proxy support, system proxy, and whether TUN is appropriate
Domain matches the work rule but fails on one node	The rule may be correct while that outbound or route is unavailable	Keep the rule and compare with another known working node
Main page loads but some assets fail	An additional domain may be unmatched, blocked, or using a different route	Inspect failed connections and add only verified domains
Direct works, proxy does not	The selected node or its path may be the problem	Test a different node and check its connection logs
Proxy works, direct does not	The service may be unreachable directly from the current network	Keep the work policy selectable and use a suitable proxy when needed
Both routes fail	The cause may be outside node selection, such as DNS, app state, or service availability	Check the specific error, DNS result, and another network path

A URL-test group can help identify nodes that respond to a chosen test URL, but it does not guarantee that a node will perform best for every Notion or Figma endpoint. Test URLs, interval, and tolerance affect how often the group changes its selection; frequent switching can make results harder to interpret. For a stable work session, a manually selected node may be easier to diagnose than an aggressively changing automatic group.

Also distinguish a slow first load from a slow ongoing session. DNS lookup, TLS setup, proxy handshakes, the service’s response, and large file transfers contribute different delays. If only the initial connection is slow, record that separately from repeated actions within an already open workspace. Avoid changing DNS mode, TUN, node, and rules all at once: that removes the evidence needed to isolate the cause.

5. Keep local traffic direct and the work profile easy to maintain

GEOIP,CN,DIRECT is useful for routing destinations whose IP addresses are classified as being in China, but it does not mean “all local websites.” A locally operated site may use an address classified elsewhere, and a globally hosted service may resolve to an address classified as local. Add explicit direct rules for known company portals, intranet domains, or local services when necessary, and place them before the broad fallback. Use reserved example domains only in documentation; replace them with domains that actually belong to your organization.

Private address rules help keep local devices and local services direct when their traffic reaches the core. They do not replace DNS configuration or guarantee that every LAN device is accessible. If a hostname such as printer.lan resolves through a local DNS server, verify that the client can still reach that DNS server after changing the proxy setup. If an IP-based local rule is involved, confirm that the destination address is actually inside the intended private range.

Maintain the configuration as a small, reviewable set of decisions:

Keep a copy of the original active profile and document any override separately from subscription-provided content.
Use one work-app policy name consistently. Do not create near-duplicate groups such as Work, Work Apps, and Work Proxy unless they have distinct purposes.
Add a domain only after the connection list or logs show that it is needed. Record why it was added and whether it should use the selectable work policy or always use DIRECT.
After a subscription update or core change, recheck that policy references resolve and that the active rules still appear in the intended order.
Return temporary diagnostic logging to info after testing. If you share logs, remove subscription tokens, node credentials, controller secrets, and personal workspace details.

When a connection behaves unexpectedly, inspect the effective configuration rather than relying only on the file originally imported. Clients may merge subscription data, local overrides, and generated settings before starting the core. Check the startup log for the running core and profile, then compare the rule order shown in the effective configuration with the rule reported for the connection. This distinction is especially important when a profile refresh silently replaces manual edits.

The result should be simple to explain: Notion and Figma match a specific policy; that policy can select a working proxy or DIRECT; known local destinations stay direct; and the final fallback follows the rest of the configuration’s needs. If a new app endpoint appears, update only the narrow rule set and retest. This is easier to maintain than sending all traffic through one node or adding broad domain rules without evidence.