Why Remote Work Needs Split Routing

A remote-work setup has a different network profile from an ordinary browsing session. A browser may open local news sites, documentation, and company dashboards while Zoom maintains a long-lived meeting connection, Slack exchanges WebSocket events, and a terminal downloads packages or reaches a private Git service. Sending every connection through the same proxy group is simple, but it often creates the exact problems remote workers want to avoid: local websites become slower, video calls fluctuate when a distant node is busy, and chat notifications arrive late because a proxy group is repeatedly testing or switching.

The practical goal of a Clash remote work setup is not to proxy everything. It is to classify traffic by destination and transport, then give each class a predictable path. Zoom media, Zoom sign-in services, Slack workspaces, Slack file storage, local websites, operating-system services, and ordinary international websites do not necessarily belong in one rule. A good profile keeps local traffic on DIRECT, places work applications on a stable proxy group when required, and reserves automatic latency testing for destinations where a small delay does not interrupt an active session.

This matters because Zoom is not just a web page. Depending on the client and meeting, it can use HTTPS for account and meeting control traffic, persistent connections for signaling, and UDP media flows for voice and video. Slack similarly combines web requests, persistent event connections, file uploads, link previews, and notification services. If the browser works but the desktop client does not, the likely cause is not that Clash is completely offline. More often, the application is bypassing the system proxy, using a hostname that your rules do not cover, or opening a UDP flow that only TUN mode can capture reliably.

Build a traffic map before editing YAML

Write down what must remain local and what needs a proxy. For many people, local banking, government services, printers, NAS devices, company resources on a domestic network, and local search engines should use DIRECT. Zoom and Slack may require a proxy because the service or part of its infrastructure is unreachable or unreliable on the current network. International package registries, source-control hosts, and documentation sites may need a separate general-purpose group, but they should not automatically share the same group used for a live meeting.

Do not assume that one domain represents an entire application. Zoom may contact authentication, configuration, telemetry, meeting, and media-related endpoints. Slack may use your workspace hostname plus API, CDN, file, and notification destinations. The exact set changes with desktop-client versions, regional infrastructure, and enabled features such as huddles or screen sharing. Use the log while signing in, joining a meeting, sending a message, opening an attachment, and uploading a file. Record repeated hostnames, then group them conservatively under the smallest useful domain suffix.

Design a Stable Profile for Zoom and Slack

Start from a current Mihomo-compatible profile rather than forcing an old Clash configuration to handle modern application traffic. The profile should contain a clear proxy-group structure, a DNS section that matches your fake-IP or redirection strategy, and rules ordered from specific application domains to broad regional rules. If a broad GEOIP or DOMAIN-SUFFIX rule appears before your Zoom or Slack entries, it can win first and send work traffic to DIRECT or to an unsuitable group.

A useful group design separates Work Stable from General Proxy. The work group can be manually selected or use a small fallback list containing only reliable nodes. The general group can use url-test or another latency-based strategy for ordinary browsing. This separation prevents a background speed test from switching the node used by an active call. A fast response to a tiny test URL does not guarantee stable UDP, upload, or long-lived WebSocket performance.

proxy-groups:
  - name: Work Stable
    type: select
    proxies:
      - Work Primary
      - Work Backup
      - DIRECT

  - name: Work Primary
    type: fallback
    proxies:
      - Node A
      - Node B
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: General Proxy
    type: url-test
    proxies:
      - Node A
      - Node B
      - Node C
    url: https://www.gstatic.com/generate_204
    interval: 300

The names above are examples, not universal node names. Replace them with names that exist in your subscription. If your provider already supplies groups, use an override or mixin instead of duplicating the entire profile. Keep the work group small enough that you know which nodes are appropriate. A fallback group should not contain every available server: a large list increases test traffic, makes behaviour harder to explain, and may select a node that is technically reachable but poor for voice or video.

Rules should be explicit and ordered. Put observed Zoom and Slack domains above generic rules, then define local bypasses and general proxy behaviour. The correct syntax depends on your profile and rule-provider format, but the logic usually resembles this:

rules:
  - DOMAIN-SUFFIX,zoom.us,Work Stable
  - DOMAIN-SUFFIX,zoom.com,Work Stable
  - DOMAIN-SUFFIX,slack.com,Work Stable
  - DOMAIN-SUFFIX,slack-edge.com,Work Stable
  - DOMAIN-SUFFIX,local,DIRECT
  - GEOIP,PRIVATE,DIRECT
  - GEOSITE,cn,DIRECT
  - MATCH,General Proxy

Do not paste domain examples blindly into production. Confirm them in the live connection panel, because a rule that is too broad may proxy unrelated Slack links, while a rule that is too narrow may leave file uploads or event streams outside the intended path. If your organization uses a custom Slack workspace domain, add that hostname only after verifying it belongs to the service. For company-owned domains, follow your employer’s VPN and security instructions instead of routing sensitive traffic through a personal proxy.

Step-by-Step Setup and Verification

The following workflow works conceptually in Clash Verge Rev, Mihomo Party, Clash for Android, and other Mihomo-based clients. Labels vary, but the sequence is the same: save the subscription, import the profile, select a core, verify groups, enable the appropriate capture mode, and test each application separately.

1. Back up your current profile: Export the active YAML or save a copy of your override settings before changing rules. Record the currently selected node and proxy mode so you can return to a known state.
2. Import or update the subscription: Use the client’s Profiles or Subscriptions page and confirm that the downloaded profile contains the nodes and groups you expect. Never publish the subscription URL in screenshots or support posts because it commonly acts as a bearer credential.
3. Choose the Mihomo-compatible core: Check the client’s Core, Kernel, or Runtime setting. Modern rule providers may use features that an obsolete Clash core cannot parse, including newer proxy types, rule providers, or TUN options.
4. Create or select a work group: Add two or three dependable nodes to a manual or fallback group named something clear such as Work Stable. Avoid using a rapidly changing url-test group for an ongoing meeting.
5. Add specific rules: Place the verified Zoom and Slack domain rules above broad regional, geographic, or final-match rules. Keep local and private-network bypasses explicit, and check that rule-provider updates do not overwrite your local additions.
6. Enable system proxy first: Turn on the client’s HTTP or mixed-port system proxy and test Slack sign-in, message delivery, and the Zoom web flow. This establishes whether ordinary HTTPS traffic is correctly classified before you introduce TUN variables.
7. Enable TUN only when capture requires it: If the desktop applications or media streams bypass the system proxy, turn on TUN mode, grant the requested administrator or VPN permission, and restart the client if required. Select the correct stack and auto-route options for your operating system rather than copying settings from another platform.
8. Test one action at a time: Join a short Zoom meeting, check audio, camera, screen sharing, and reconnect behaviour separately. In Slack, send a message, receive a reply, open a file, and upload a small attachment while watching the connection log.
9. Lock the working node: After finding a stable path, select it manually for the work group during important meetings. Re-enable fallback testing later, outside active calls, and compare results over several workdays instead of judging one five-second latency sample.

DNS, TUN Mode, and Call Quality

DNS is part of routing, not a separate cosmetic setting. If the operating system resolves a hostname directly while Mihomo expects to see it through fake-IP or redirection, the rule engine may receive an address without the context needed to apply your domain rules. This can produce confusing results: Slack’s main page follows the work group, but a file endpoint is classified by IP and goes direct; Zoom sign-in works, but the meeting client cannot establish media.

Choose one DNS strategy and understand its trade-offs. Fake-IP can make domain-based policy consistent and is often useful with TUN mode, but local devices, printers, captive portals, and software that expects real address records may need exclusions. Redir-host or normal resolution can be easier to troubleshoot in some environments, but it may expose more DNS requests to the operating system or local resolver. Whichever mode you choose, verify that private ranges, your router, company DNS, and local suffixes are excluded where necessary.

When a call connects but quality is poor, do not immediately select the node with the lowest displayed ping. Zoom media is sensitive to jitter, packet loss, upload congestion, and route changes. A node with a slightly higher but consistent latency can sound much better than a node whose test result is excellent while its real path is congested. During testing, watch CPU load, Wi-Fi signal, VPN interference, and whether another device is uploading large files. Clash cannot repair an overloaded home uplink.

TUN mode is valuable when an application ignores HTTP system-proxy settings or uses UDP. On Windows, macOS, and Linux, enabling TUN may require a service helper, administrator approval, or a virtual interface permission. On Android, the equivalent is usually a VPN permission prompt. Read the client’s status panel after enabling it: confirm that the TUN interface is running, auto-route is active, and traffic is not being captured twice by another VPN, corporate security agent, or virtualization tool.

Keep DNS and routing logs private. Workspaces, meeting IDs, file names, and internal hostnames can appear in connection histories even when message contents are encrypted. Clear exported logs before sharing them, remove subscription tokens, and avoid sending a complete YAML profile to a public forum. Troubleshooting data should show only the minimum hostname, rule, and error needed to reproduce the issue.

Troubleshooting the Common Failure Patterns

Zoom connects, but audio or video fails

First check whether the Zoom desktop process appears in the client’s connection list after TUN is enabled. If only browser traffic is visible, the application is probably outside the system proxy path. Next, compare TCP control traffic with UDP media traffic. Some networks or proxy paths handle HTTPS correctly but cannot provide a usable UDP route. In that case, test the client’s supported transport or network mode, use a node and protocol known to handle sustained traffic, and avoid switching groups during the meeting. Also inspect whether a local firewall, endpoint-security product, or corporate VPN blocks the virtual adapter.

Slack opens, but messages or notifications are delayed

Slack’s initial page load can succeed even when its persistent event connection fails. Filter the log for the workspace hostname and related Slack endpoints, then leave the client open for several minutes. If the event connection repeatedly reconnects, test a fixed work node and confirm that the WebSocket destination matches your rules. A sleep-resume cycle can also leave a stale connection behind; fully quit Slack, refresh the profile, and reopen it after the proxy group is selected. If only file previews fail, inspect CDN or storage hostnames separately rather than broadening every rule to slack.com.

Local websites became slow after the change

Look for a broad MATCH,Work Stable rule or a DNS mode that sends local names through a remote resolver. Add private-network and local-domain exclusions where appropriate, and place regional direct rules before the final match. Test both a local website and a LAN device by hostname and IP address. If the IP works but the hostname does not, DNS handling is the stronger suspect. If both are slow only while a meeting runs, your uplink or Wi-Fi may be saturated by video rather than misrouted by Clash.

A subscription update removes the work rules

Many providers regenerate the complete YAML file during every update. Editing the downloaded profile directly can therefore appear to work for one day and disappear after the next refresh. Use the client’s rules, script, mixin, or profile-override feature when available. Keep custom rules in a small separate block, document why each domain exists, and recheck the generated configuration after updates. If the provider changes group names, update your override references instead of creating several near-duplicate groups that are difficult to select correctly.

A dependable remote-work configuration is ultimately a repeatable process: observe the real destinations, keep local traffic direct, give Zoom and Slack a stable route, capture bypassing applications with TUN only when necessary, and validate DNS alongside rule order. Compared with many generic VPN applications that expose no rule matching, and with older Clash clients whose cores and documentation no longer match current subscriptions, a modern Clash Official Site workflow gives you clearer profile organization, visible connection diagnostics, and practical cross-platform guidance without requiring you to rewrite the entire YAML file. Once the rules have been tested on your own network and approved for your workplace, you can download Clash Official Site and apply the same measured setup to keep meetings steady, Slack responsive, and local browsing direct.