Clash Remote Work Setup: Smooth Zoom, Slack & Google Meet Calls

Separate Meeting Routing from Everyday Traffic

Video calls are unusually sensitive to network changes. A web page can pause while it loads and still feel usable; a meeting can become choppy as soon as packets are delayed, dropped, or sent along an unstable route. Slack adds a different mix of traffic: messages and files use web connections, while huddles and calls may use real-time media. Google Meet can run in a browser or an app, and its media connections do not always behave like ordinary page requests.

Clash rules can send traffic to a dedicated proxy group without changing the route used by every other website. For example, you can direct selected Zoom, Slack, and Meet domains to a group called Work-Meeting, while the final rule sends unmatched traffic to your normal group. This is a policy-routing arrangement, not a guarantee that every packet belonging to a meeting will match a domain rule. The result depends on the client, core, DNS and sniffing settings, operating system, and current service infrastructure.

First decide what “separate” means for your setup. It might mean using a more stable node for meeting services while leaving ordinary browsing on a different proxy group. It might instead mean sending meeting services directly to the internet and proxying other traffic. Those are different policies. Choose the one permitted by your network and service provider, then test it with a real call rather than assuming that a successful browser speed test proves call quality.

Goal	Typical policy	Main trade-off
Use a stable proxy for meetings	Match selected service domains to a dedicated proxy group	Meeting quality depends on that node’s latency, packet loss, and UDP support
Keep meetings direct	Match selected service domains to `DIRECT`	Direct routing may be blocked or unsuitable on some networks
Keep everyday browsing separate	Set the final catch-all rule to your normal browsing group	Unmatched meeting connections may follow the catch-all route

Clash is a name used for a family of clients and proxy cores. mihomo, the continuation of Clash Meta, supports many current routing features, but not every client bundles the same core or exposes the same settings. Before editing anything, check the core name and version in the client’s About, Core, or General screen. Also note whether the active profile is a local file or a remotely managed subscription. If subscription updates replace local edits, use the client’s supported override or merge mechanism instead of repeatedly editing a generated file.

Choose a Route and Understand What It Can Carry

A dedicated meeting group makes the routing decision visible and easy to change. A select group is a practical starting point because you can choose a node in the client and compare it with another node during testing. The group does not create a new connection or improve a node by itself; it only selects an outbound already defined in the configuration.

For interactive calls, a low and consistent round-trip time is generally more useful than a large download-speed number. A node that tests quickly but loses UDP packets or takes a detour through multiple regions may perform worse than a nearby node with a lower peak throughput. Some proxy protocols or network paths handle UDP differently from TCP. If a call connects but media is missing, choppy, or one-way, check whether the selected outbound and core support the traffic the app is using. Do not assume that a working web page confirms UDP support.

Check	What to look for	Why it matters
Latency consistency	Compare repeated measurements at different times, not only one test	Sudden variation can disrupt real-time audio and video
Packet loss	Check call diagnostics and client or operating-system network logs	Lost media packets can cause gaps even when pages load normally
UDP behavior	Verify the core, outbound protocol, and provider support the needed traffic	Some call media uses UDP; a TCP-only path may behave differently
Route scope	Review the connection log for the matched rule and selected group	Seeing a proxy active does not prove the meeting connection used it

Use the narrowest domain matches that cover the services you actually use. The example below is a starting point, not an authoritative list of every current Zoom, Slack, or Google Meet endpoint. Service domains and delivery infrastructure can change. Avoid routing a broad domain such as google.com simply to catch Meet: it may also move unrelated Google services onto the meeting route. Likewise, avoid adding guessed IP ranges or broad port rules without confirming their scope. A port rule can capture unrelated applications that happen to use the same port.

In a rule-based configuration, order matters. Put specific meeting rules before broad rules such as GEOIP, IP-CIDR, or a final MATCH. The policy name in a rule must exactly match the group name. If your profile already has groups, reuse an appropriate group or add one through the client’s supported merge settings; do not create duplicate top-level YAML keys.

Add a Dedicated Meeting Group: Step by Step

This example targets mihomo and shows a small policy group plus a set of domain rules. Replace the sample node name with an outbound that already exists in your profile. Keep the final catch-all rule appropriate for your normal browsing policy. If your configuration is subscription-managed, add the equivalent through its override or merge editor and inspect the merged configuration before applying it.

Make a backup. Save a copy of the active profile or record the current override. Confirm which profile is selected so that you do not edit an inactive file.
Check your available outbounds. Identify an existing proxy name that you can select for calls. A name in proxies or another group must match exactly, including capitalization and punctuation.
Add the policy group. Place the group under the existing top-level proxy-groups list. If that list already exists, add an item to it rather than defining a second proxy-groups: key.
Add the service rules. Insert the domain rules near the top of rules, before broad rules and before the final catch-all. Keep only domains that you can justify and test.
Validate and apply. Use the client’s configuration check or reload function. Read the core log for YAML errors, missing group names, and unsupported fields before starting a call.
Select the route and test. Choose the desired node in the meeting group, open a fresh app or browser session, and verify the connection log while joining a test meeting.

proxy-groups:
  - name: Work-Meeting
    type: select
    proxies:
      - Preferred-Node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,zoom.us,Work-Meeting
  - DOMAIN-SUFFIX,zoom.com,Work-Meeting
  - DOMAIN-SUFFIX,slack.com,Work-Meeting
  - DOMAIN-SUFFIX,slack-edge.com,Work-Meeting
  - DOMAIN-SUFFIX,slack-files.com,Work-Meeting
  - DOMAIN,meet.google.com,Work-Meeting
  # Keep your existing service and general rules here.
  # Keep the final catch-all rule last.
  - MATCH,Main

Preferred-Node and Main are placeholders, not built-in names. Replace them with names present in your configuration. If you want meeting traffic to go direct, you can use DIRECT as the policy target in the service rules instead of a proxy group, but do not route both ways at once. The example includes several service domains to illustrate rule structure; it cannot guarantee complete coverage. In particular, do not add a broad Google suffix just because Meet is a Google service.

Some client editors use different labels for the same kind of change. In Clash Verge or Clash Verge Rev, look for the profile’s merge, script, or override controls and check the client documentation for the supported method. The exact menu and available override format depend on the client and core version. Do not assume that every field pasted into an editor becomes part of the active runtime configuration. After applying the change, inspect the final rules or connection log if the client provides those views.

Keep Domain Matching and Capture Settings in Perspective

Rule matching needs the core to associate a connection with a domain. DNS mapping and sniffing can help preserve or recover domain information in supported setups, but they are not interchangeable with a guarantee that all app traffic will be identified. A system proxy usually affects applications that honor the operating system’s proxy settings; it does not automatically capture every application or every UDP flow. TUN mode can capture more IP traffic through a virtual interface, but the result depends on permissions, routing exclusions, other VPNs, and client settings.

Enable TUN only when the system-proxy test is insufficient and you understand how the client captures traffic. On systems that already have another VPN, endpoint security filter, or network extension, two capture mechanisms can conflict. If using TUN, test one configuration change at a time and confirm the client reports that the interface is active. Do not turn off operating-system security controls simply to make a configuration load.

Test Zoom, Slack, and Google Meet with Real Calls

After reloading the profile, test each service separately. A single meeting result cannot establish that all three services follow the intended route, because their apps and connection types differ. For an initial comparison, keep the device, network, meeting participant, and approximate time as consistent as possible. Note the selected node, core version, whether system proxy or TUN is enabled, and the relevant rule shown in the connection log.

Zoom: Join a test meeting and check whether audio and video both work. Review Zoom’s in-meeting connection or statistics view where available. If joining works but media does not, investigate UDP support and the selected outbound rather than adding broad port rules as a guess.
Slack: Check workspace sign-in, message updates, file access, and a huddle separately. A message loading successfully does not prove that huddle media uses the same route.
Google Meet: Test the browser or app you actually use. Confirm that the meeting page and media work, then inspect the connection log for the domain and policy selected. Browser secure DNS or extensions may affect name resolution and make results differ from another browser.

For each test, compare at least two configurations: your normal routing and the dedicated meeting group. Keep the node choice fixed while comparing routes; then keep the route fixed while comparing nodes. Changing both at once makes it difficult to identify what helped. If the client provides a rule-match or connection table, filter for the service connection during the call and record the matched rule, outbound, destination, and whether the connection is TCP or UDP when that information is available.

Observed result	Likely area to inspect	Useful next test
The meeting page loads, but the call cannot connect	Media transport, UDP handling, firewall, or an unmatched destination	Check call diagnostics and logs during the call; compare a supported node
The service works, but the log shows the normal group	Rule order, domain visibility, or a profile that was not reloaded	Confirm the active profile and inspect which rule matched that connection
Only one app fails	App-specific domains, permissions, browser settings, or cached connections	Restart the app, test a fresh session, and compare its log entries
Calls become worse after enabling TUN	Conflicting VPNs, capture exclusions, DNS behavior, or route selection	Return to the previous setting, then test TUN alone with one change at a time

Do not judge a call solely by a public speed-test result. Upload stability, jitter, packet loss, Wi-Fi congestion, and the other participant’s network can all affect what you hear and see. If the same problem happens with the proxy disabled and on a different network, the cause may not be the Clash route. Conversely, if the connection log shows the intended rule but calls still fail, the policy may be matching correctly while the chosen node or transport remains unsuitable.

Maintain the Setup Without Overrouting

Keep the configuration small enough to explain. Each added domain or IP range increases the chance that unrelated traffic will follow a different route. Start with the narrow rules you can verify, then add an entry only when logs show that a specific required connection is missing the intended group. If a service changes its infrastructure, update the rule based on current service documentation or observed connection details rather than copying an unverified list.

After a client or core update, review the core version and test the same short checklist again. A client update does not necessarily mean that the core or runtime configuration changed, and a core update can affect supported fields or behavior. Keep a working backup and note which settings were changed: profile, group selection, rules, TUN state, DNS or sniffing configuration, and chosen node. That record makes rollback and troubleshooting much faster.

Use the system proxy first when the apps you need follow it reliably. Consider TUN when an application bypasses the system proxy or when you need broader traffic capture, but account for the additional routing and DNS variables. If a managed work device or corporate network has its own VPN and traffic policy, follow the organization’s requirements; overlapping proxy and VPN routes can cause both connectivity problems and policy violations.

The practical target is not “proxy every meeting packet at any cost.” It is a predictable route for the connections you can identify, a suitable outbound for real-time traffic, and a clear fallback for everything else. Verify each app while it is in use, keep rules before broad catch-alls, and change one variable at a time. That approach makes the setup easier to maintain when a node, client, core, or service endpoint changes.