Clash Remote Work Setup: Stable Zoom and Slack Split Tunneling Guide

Map your remote-work traffic before changing rules

When a video call freezes, the instinct is often to switch every device into Global mode and hope for the best. That can hide the original problem, send local services through a distant relay, and make it harder to tell whether the issue was DNS, a weak node, or an incorrectly matched rule. A more useful Clash remote work setup starts with a small traffic map: identify which services should use a proxy, which should stay direct, and how you will verify the decision while Zoom or Slack is active.

For many people, the practical goal is selective rather than all-or-nothing routing. Zoom and Slack may need a stable outbound route on a particular network, while local banking, company intranet pages, printers, and nearby services should continue to use the ordinary connection. Keeping local browsing on DIRECT also avoids adding relay latency to sites that do not need it. However, an employer’s network policy takes priority: use only routing methods your organization permits, and do not route company traffic through an unapproved third-party service.

Start by listing the applications and outcomes you care about. For a Zoom meeting, that usually means joining reliably, maintaining clear audio, and avoiding abrupt changes in route during a call. For Slack, it means messages, workspace sign-in, file previews, and calls all behave consistently. These are not always one network flow each. A desktop app can contact several service hostnames, and a browser-based sign-in can use a different hostname from the main product page. A rule that matches only the homepage may therefore appear to work while leaving file transfers or authentication on another route.

Also record what “local browsing” means in your environment. It might include local-language news sites, a company intranet, a home router page, a printer, or devices addressed by private IP ranges. Do not assume all traffic with a local-looking domain will be classified correctly just because a profile has general private-network rules. Check the actual rule list and the Connections view in your client. A clear policy is easier to troubleshoot than a collection of copied rules whose order and purpose are unknown.

Choose a node for calls, then define the routing policy

For live audio and video, a low and consistent round-trip time is more useful than a headline download-speed figure. A node that delivers a fast file test but has fluctuating latency, congestion at meeting time, or unreliable UDP handling can still produce poor calls. Compare a few available nodes at the time you normally work. Prefer one with steady response and enough capacity, and avoid repeatedly changing nodes during a meeting unless the current route has clearly failed.

Check the client’s proxy groups before editing rules. In Clash Verge, Clash Verge Rev, or another Mihomo-based client, group names and menus vary by version and profile. A common arrangement is a selectable group for work services, with a default node chosen from that group. Keep the group name in your rules consistent with the name that actually exists in your configuration; the example below uses Work as a placeholder, not a built-in group name.

Where your profile supports domain rules, place the specific work-service rules before broad catch-all rules. The final rule should preserve the behavior you intend for all other traffic. For example, a simplified rule section might look like this:

rules:
  - DOMAIN-SUFFIX,zoom.us,Work
  - DOMAIN-SUFFIX,zoom.com,Work
  - DOMAIN-SUFFIX,slack.com,Work
  - DOMAIN-SUFFIX,slack-edge.com,Work
  - DOMAIN-SUFFIX,slack-files.com,Work
  - DOMAIN-SUFFIX,slack-msgs.com,Work
  - GEOIP,LAN,DIRECT
  - MATCH,DIRECT

Treat this as a starting point for investigation, not a complete vendor endpoint inventory or a universal production configuration. Service infrastructure can change, organizations may use custom domains, and some client profiles generate or override rules elsewhere. Zoom and Slack can also rely on related sign-in, content-delivery, or calling endpoints that are not covered by a few suffixes. Do not add broad rules for entire cloud providers merely because one connection appears in a log; that can route unrelated traffic through the proxy and weaken the separation you wanted.

Rule order matters. A domain-specific rule placed below a broad rule that already matches the connection may never be reached. Likewise, an existing rule that sends all traffic to a proxy group can defeat a later attempt to leave local browsing direct. After editing, reload the profile if needed, inspect the active rules in the client, and confirm that the selected Work group is available. If your setup uses a remote subscription that refreshes rules, keep a local backup of changes and understand whether a profile update will overwrite them.

Apply the setup and test it before a meeting

Make one change at a time. First choose the node or work group you want to test. Then apply the domain rules, reload the configuration, and open the client’s Connections or Logs view. With Slack open, check which hostnames appear and which rule or proxy group handled them. Repeat while joining a Zoom test meeting or another permitted test call. The objective is not to collect every connection forever; it is to verify that the traffic you observed is being classified as intended.

1. Save a working baseline. Export or copy the current profile before making changes. Note the active mode, selected group, and any existing local-network exceptions so you can restore them quickly.
2. Select a candidate node. Compare a small number of nodes during the same general time of day. Favor stable latency and reliable call behavior over a single speed-test result. If your provider labels routes by location, treat those labels as hints rather than proof of performance.
3. Add narrow rules. Put only the verified Zoom and Slack domain rules ahead of broader matches. Keep private network and local-service rules intact, and make sure the final fallback matches your intended default behavior.
4. Reload and observe. Restart or reload the profile using the client’s normal controls. Open Slack and a Zoom test session, then inspect the active connections. Confirm that the matched rule and group are the ones you expected.
5. Check direct traffic too. Visit a trusted local site or internal resource and confirm that it remains DIRECT. If it is sent through the work group, inspect rule order and the actual hostname rather than adding exceptions blindly.
6. Test after a profile update. If the profile is remotely managed, refresh it only when you can verify the result. Some updates replace local edits or change proxy-group names, which can leave rules pointing at a group that no longer exists.

For a dependable test, compare like with like. Join a test call using the candidate route, then—if policy and circumstances allow—compare with the ordinary connection. Note whether audio breaks up, video freezes, or joining takes unusually long. A browser page loading quickly does not prove that a real-time call is healthy: web pages can tolerate retries and buffering that interactive audio cannot. Conversely, one brief glitch does not prove the proxy is at fault; Wi-Fi interference, a busy access point, a headset issue, or a remote participant’s connection can produce similar symptoms.

When checking Logs, avoid sharing screenshots that expose subscription URLs, account identifiers, workspace names, or private addresses. Hostnames and rule names are often enough for a useful diagnosis. If an employer manages the device, consult its IT team before changing system proxy settings, installing a TUN driver, or redirecting traffic. A desktop client’s routing capability does not override an organization’s security requirements.

Separate routing failures from call quality problems

Use the symptom to decide what to inspect first. If Slack loads but file previews fail, compare the connections generated by the preview with those generated by the main workspace. If sign-in loops, look for authentication-related hostnames that are being sent DIRECT while the rest of the app uses the proxy, or vice versa. If Zoom joins but media quality is poor, check node latency, packet loss, and whether the route supports the transport the call is using. Do not assume that adding more domain suffixes will repair congestion or a weak Wi-Fi signal.

Zoom calls may use UDP for real-time media when the network and client allow it, with other paths or transports used in different conditions. A proxy path that works well for ordinary HTTPS browsing may not perform equally well for interactive audio and video. If your client, mode, or node does not handle the required traffic reliably, test an approved alternative or use the organization’s supported connection method. Avoid forcing a transport setting from an old forum post without confirming that the current client and network support it.

Connections that appear to bypass a rule deserve careful inspection. Confirm the hostname shown by the client, whether the rule uses a domain match or an IP-based match, and whether DNS handling gives the rules the information they expect. A connection displayed only as an IP address may not match a domain rule in the way you assumed. Check the client’s DNS mode and profile documentation before changing it; switching DNS behavior can affect local network access and other applications.

When a problem starts immediately after a profile update, compare the active configuration with your saved baseline. Look for renamed groups, new catch-all rules, or a changed ordering. If only one service is affected, test a narrow adjustment and observe the result before changing the whole routing policy. If every application becomes slow, return to the baseline and investigate the node or local connection first. This controlled approach saves time and avoids turning a small Slack issue into a household-wide networking problem.

Build a repeatable pre-call routine

A small routine is more useful than emergency configuration changes five minutes before a client presentation. Before an important call, open the Clash client and confirm that the profile is loaded, the intended work group has a live node, and the active mode has not changed unexpectedly. If you have recently updated the profile, do a short test before relying on it. Check that Slack can sign in and load a representative channel, then join a Zoom test meeting or use the organization’s approved call test.

Keep a brief record of known-good behavior: the profile version, selected group, time of day, and whether local sites stayed direct. You do not need a complex spreadsheet. A few notes can show whether failures correlate with one node, one network, or one recent configuration change. When reporting an issue, include the relevant hostname, timestamp, rule result, and client version—but redact access tokens, subscription links, and personal data.

Have a safe fallback. If a call is about to start and the proxy path is failing, use the connection method approved by your organization rather than improvising broad routing changes. If the ordinary network works and policy permits it, a temporary direct route may be preferable to an unstable node; if company policy requires a managed route, contact IT instead. Once the meeting is over, investigate with a controlled test rather than leaving an emergency Global-mode change in place.

Compared with one-toggle VPN apps, Clash can make the decision more explicit: you can inspect which connections matched a rule, choose a work-specific proxy group, and keep unrelated local traffic on a direct path. That flexibility also means the policy needs maintenance—service hostnames and profiles can change, and a rule that was once accurate may become incomplete. If you want a client that supports this kind of visible, rule-based workflow, compare the available Clash clients for your operating system and choose the one that fits your setup.

Download Clash for free and browse freely →