What a good Clash workflow setup should accomplish
Notion, Figma, and Miro are all browser-based collaboration tools, but they do not behave like three copies of the same website. Notion loads workspaces, images, file attachments, authentication pages, analytics endpoints, and real-time editing services. Figma combines a web interface with large design assets, font discovery, multiplayer presence, comments, and file exports. Miro adds shared whiteboards, cursor updates, media previews, and collaboration traffic that can feel sluggish when latency or packet loss increases. A profile that makes one application usable can therefore create a poor experience in another.
Searches such as Clash Notion setup, Figma proxy routing, and Miro connection slow usually describe the same underlying problem: the user has enabled a proxy but has not designed a policy for different traffic types. Global mode may make a blocked workspace load, yet it can also send local services, banking pages, package registries, and nearby content through a distant node. Direct mode preserves local speed but may leave collaboration services unable to authenticate, load assets, or maintain a stable WebSocket session.
The practical objective is not to force every request through a proxy. It is to create a predictable split: route services that genuinely need the proxy through a responsive node group, keep local and trusted services on DIRECT, and observe the result in Clash or Mihomo logs. This approach reduces unnecessary latency, protects available subscription traffic, and makes troubleshooting much easier because every connection has an explainable policy decision.
Before changing rules, write down the workflow you need to protect. A designer may need Figma editing, Google Fonts, image exports, and a video call at the same time. A product team may use Notion for documentation while Miro is open in a second monitor. A student may need local university portals and cloud design tools together. Each case has a different tolerance for delay, but all of them benefit from separating application traffic from unrelated browsing.
Prepare the profile, node groups, and local exceptions
Start with a Clash-compatible profile that you are allowed to use and that includes current proxy nodes. Import the profile into Clash Verge, Clash Verge Rev, Clash for Windows, ClashX, Clash for Android, or another Mihomo-based client. Keep the subscription URL private: it may contain an account token, and publishing it can allow someone else to consume your traffic quota or access your provider account.
After importing the profile, open the proxy or groups view and identify how traffic is selected. A well-organized profile normally contains a primary selector, an automatic health-check group, a fallback group, and sometimes separate groups for streaming, work, or regions. Do not assume that the first node listed is the best node for design applications. A node with impressive speed-test bandwidth may still have high round-trip latency, unstable international transit, or poor support for long-lived connections.
For Notion, Figma, and Miro, stability is usually more important than peak download speed. Editing a document or board creates many small requests and may keep sessions alive for a long time. A node that briefly reaches a high benchmark score but resets connections every few minutes is worse than a moderately fast node with consistent latency. Test at least two or three candidates while the applications are actively open.
- Use an automatic group for convenience: health checks can remove unreachable nodes, but they cannot measure the complete user experience inside Figma or Miro.
- Keep a manual fallback: when a group selects an unsuitable node, a manual selector lets you confirm whether the problem is policy-related or node-related.
- Prefer nearby reliable regions: choose a node with a sensible network path to your location and the service region, rather than selecting a region solely because it is popular.
- Avoid excessive group nesting: a selector inside an auto group inside another selector makes it harder to determine which node actually handled a request.
- Check UDP requirements separately: most web traffic is TCP or HTTPS, but calls, embedded media, and certain real-time features may behave differently when UDP support is limited.
Next, review the profile mode. Rule mode is normally the best starting point because it allows you to route collaboration services selectively. Global mode is useful as a diagnostic control: if Notion, Figma, or Miro immediately becomes healthy in Global mode, the node is probably reachable and your rules, DNS behavior, or local exceptions deserve inspection. It is not automatically the best permanent configuration.
Preserve local traffic deliberately. Common examples include company intranet domains, local development hosts, printer interfaces, router addresses, domestic services, and private IP ranges. If you use a corporate VPN or campus network, ask whether its DNS names and authentication endpoints must remain direct. A careless catch-all proxy rule can make local login pages loop, prevent access to internal tools, or cause a browser to report that a service is unavailable even though the proxy itself is working.
Use the client’s profile editor or an override mechanism rather than repeatedly editing a provider-owned file that will be replaced during the next subscription update. Put your custom rules in a documented layer, give the layer a clear name, and record why each exception exists. When a service changes its hostname, you will then know which custom rule to review instead of searching through an unstructured YAML file.
Route Notion, Figma, and Miro with evidence
Begin with a small policy rather than a large copied domain list. Open Notion, Figma, and Miro in separate tabs, sign in normally, and watch the Connections panel while each application loads. Search for hostnames associated with the active session, then note which requests are using the intended proxy group and which are going DIRECT. The exact hostnames can change over time, so live connection evidence is more dependable than a static list copied from an old forum post.
For Notion, test more than the first page render. Open a workspace, search for a page, load an image or attachment, edit a block, and wait for synchronization to finish. A rule that only fixes the login screen is incomplete. If the page opens but edits remain stuck on “Saving,” inspect the long-lived connections and asset requests. Authentication, API calls, file delivery, and telemetry may not share one hostname. Route the domains observed during the failing action, not every domain that appears in a search engine.
Figma requires a similar layered test. Open a file with several pages, zoom through a frame, inspect a component, add a comment, and observe whether fonts and images arrive normally. Then duplicate a small object or make a harmless edit and confirm that multiplayer presence and saving remain responsive. Large design files can expose a weak route that a simple landing page does not. If only thumbnails fail, investigate asset delivery. If the canvas loads but edits do not synchronize, investigate persistent connections, node stability, and browser extensions before adding broad rules.
Miro should be tested as a collaborative board rather than a static website. Open a board with several objects, move the viewport, create a temporary shape, and watch whether another participant sees the change without a long delay. Media previews and embedded content may come from separate services. If the board itself works but an embedded video or document does not, identify that resource’s hostname and decide whether it should share the collaboration route or remain direct.
A useful rule design separates broad service families from narrow exceptions:
- Service rules: route confirmed Notion, Figma, and Miro application domains to a selected collaboration group.
- Authentication rules: include identity providers only when the login flow demonstrably fails without them. Do not proxy every account or productivity service by default.
- Asset rules: handle image, font, file, and export hosts after observing them in Connections. Asset delivery can be geographically different from the application interface.
- Local rules: keep private networks, internal domains, local development servers, and approved regional services on DIRECT.
- Fallback behavior: decide whether an unavailable proxy should fail closed, use a backup group, or go DIRECT. For work data, an explicit backup group is often easier to reason about than silent fallback.
Rule order matters. A broad regional or final rule placed above a specific application rule can capture the request before the intended policy sees it. Put precise domain rules before broad geolocation rules and place the final catch-all decision at the bottom. When using domain suffix matching, check that the pattern is not wider than intended. A rule aimed at one service should not accidentally capture an entire parent domain used by unrelated local tools.
After each rule change, reload the configuration if your client requires it, close stale tabs, and repeat the same action. Browser connections can remain alive after a profile update, which may make a fixed rule appear broken. For a clean test, quit the browser or application, confirm that the old connections have disappeared, then start a new session and inspect the first requests again.
Tune DNS, TUN mode, and performance without overcorrecting
Routing rules cannot fully solve a DNS design that contradicts them. If DNS resolution happens outside the intended path, a service may resolve to an unexpected address, trigger a regional endpoint, or appear as a direct connection in the logs. If the client uses fake-IP behavior, some applications may also react differently from a normal browser. The correct settings depend on the client, operating system, and profile, so change one DNS option at a time and test the complete workflow after each change.
When only the browser works but a desktop design application fails, inspect whether that application actually honors the system proxy. Some applications use system settings, some read environment variables, and some need TUN mode or a compatible network extension to capture traffic. Enabling TUN can help with applications that ignore ordinary HTTP and SOCKS proxy settings, but it also increases the importance of exclusions. A poorly configured TUN setup can capture local printers, virtual machines, Docker networks, corporate VPN addresses, or other traffic that should never leave the local path.
Use TUN as a targeted troubleshooting step, not as a substitute for understanding the policy. First test Figma or another application with the system proxy enabled. If its browser counterpart works but the native client does not, compare the Connections view with and without TUN. If traffic appears only after TUN is enabled, the capture layer was the missing piece. If traffic appears but remains slow, focus on node quality, DNS resolution, MTU, or the remote service rather than repeatedly toggling modes.
Do not treat every delay as a proxy failure. Figma may spend time processing a large local file, Miro may render many embedded objects, and Notion may synchronize a workspace with a large attachment history. Compare several actions: initial login, opening a small document, opening a large file, saving an edit, and downloading an asset. A routing problem usually produces a repeatable pattern across a particular hostname or action. Local CPU pressure, browser memory pressure, an extension, or a large project may affect only one workload.
For a more reliable comparison, record a few simple observations:
- How long the application takes to reach an interactive state.
- Whether edits save immediately, after a delay, or only after a refresh.
- Whether comments, cursors, and board changes remain synchronized.
- Which node group and actual node appear in the connection details.
- Whether the same action fails in Rule mode but succeeds in Global mode.
- Whether a second node produces the same symptom.
These observations prevent random configuration changes. If two nodes show the same failure while Global and Rule mode differ, inspect rule order or DNS. If only one node fails, replace it or move it out of the automatic group. If the browser succeeds but the native application creates no connection entry, investigate proxy inheritance or TUN capture. If all routes fail during a provider outage, preserve the known-good configuration and wait for a service-side or subscription-side recovery instead of rewriting every rule.
Maintain a responsive team workflow
Once the three applications work, document the setup for the people who will use it. Record the client name and version, the selected mode, the collaboration proxy group, the local exceptions, and a short verification checklist. A teammate should be able to confirm that Notion saves an edit, Figma loads a shared file, and Miro synchronizes a temporary object without learning the entire profile format.
Review the configuration after subscription updates. Provider updates can change group names, rule providers, DNS defaults, and node availability. If your custom layer refers to a group that no longer exists, the client may silently fall back to another policy or show an error that looks like an application outage. Keep custom rules small enough to review in a few minutes and remove experiments after they have been disproved.
For shared work, avoid sending credentials, private subscription URLs, exported profiles, or screenshots that expose workspace names and tokens to public channels. A rule set can be shared as a redacted concept—service category, intended group, and test result—without distributing secrets. Teams should also agree on whether sensitive company traffic may use a third-party proxy and whether local or corporate VPN policies take precedence.
When a collaboration session is important, test before the meeting rather than during it. Open the relevant workspace, verify that the selected node is healthy, and avoid switching nodes while files are saving. Node changes can reset long-lived connections and create duplicate sessions. If a node becomes unstable, switch to a known-good manual choice, wait for the application to reconnect, and confirm that edits are synchronized before continuing.
Compared with simple VPN clients that provide little visibility, limited per-domain control, or one route for every application, Clash gives you a practical way to separate local services from Notion, Figma, and Miro traffic, inspect real connections, and change a node without rebuilding the entire workflow. Compared with manually exporting proxy variables to each design or notes application, rule-based routing and optional TUN capture provide a more consistent desktop experience while preserving direct access where it is faster and safer. If you want to apply this setup across your devices, start with the appropriate Clash client and build the profile around observable tests rather than a blanket Global switch.