Clash Remote Work Setup: Stable Zoom, Slack, And Google Meet

Build a stable remote-work baseline

Video meetings and team chat do not require every connection to use the same proxy path. In fact, sending all traffic through a distant node can make a home-office connection less predictable: local websites become slower, file transfers consume unnecessary bandwidth, and a busy proxy may introduce jitter into an otherwise healthy meeting. A better Clash design separates work services, ordinary local traffic, and destinations that should never be intercepted.

The first decision is whether the client should use system proxy mode or TUN mode. System proxy mode is usually enough for browsers and desktop applications that respect the operating system proxy settings. TUN mode is more comprehensive because it creates a virtual network interface and can capture applications that ignore the system proxy, including some meeting clients, command-line tools, and background services. However, TUN also makes DNS, routing, permissions, and bypass behavior more important. Start with system proxy mode when you are testing a new configuration, then enable TUN only if a required application cannot connect through the system proxy.

Use a dedicated policy group rather than embedding one node directly into every rule. A group gives you a single place to switch between a low-latency node, a backup node, and a direct connection. If the group is named Work, the rules remain readable even when the actual server names change after a subscription update.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

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

  - name: Auto Work
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    proxies:
      - Singapore 01
      - Japan 01
      - United States 01

  - name: Backup Work
    type: select
    proxies:
      - United States 02
      - Japan 02

The names in this example are placeholders. Replace them with the exact proxy names generated by your subscription. A url-test group measures access to a probe URL; it does not guarantee that every Zoom media relay or Google Meet endpoint will have the same performance. For this reason, keep a manual backup and verify an actual call instead of trusting a single number.

Route Zoom, Slack, and Meet with deliberate rules

Application-specific routing can be implemented by domain rules, process rules, or a combination of both. Domain rules are generally the most portable because they work whether the application uses system proxy mode or TUN capture, provided the relevant DNS and traffic path are configured correctly. Process-name rules can be convenient on supported desktop platforms, but support depends on the client, operating system, and mihomo build. Do not assume that a process rule written for Windows will behave identically on macOS, Linux, Android, or iOS.

For collaboration software, begin with the service domains that you can observe in logs during sign-in, message loading, and a live call. Zoom may use several web and meeting-related domains, while Slack commonly depends on its workspace domain, API endpoints, file delivery, and real-time connection services. Google Meet uses Google account, meeting, media, and auxiliary Google services. A short list copied from a random configuration can become outdated or accidentally route unrelated Google traffic. Prefer provider-maintained rule sets when they are available and review their contents before importing them.

rules:
  - DOMAIN-SUFFIX,zoom.us,Work
  - DOMAIN-SUFFIX,zoom.com,Work
  - DOMAIN-SUFFIX,slack.com,Work
  - DOMAIN-SUFFIX,slack-edge.com,Work
  - DOMAIN-SUFFIX,google.com,Work
  - DOMAIN-SUFFIX,googleapis.com,Work
  - DOMAIN-SUFFIX,gstatic.com,Work

  - IP-CIDR,192.168.0.0/16,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,127.0.0.0/8,DIRECT,no-resolve
  - GEOIP,PRIVATE,DIRECT,no-resolve
  - MATCH,Final

This is a starting structure, not a universal domain allowlist. Routing all of google.com or googleapis.com through one work group may affect unrelated services, and some Google Meet media addresses can be selected dynamically. If normal browsing becomes unexpectedly slow, narrow the rules to the destinations visible in the Clash connection log instead of adding more broad suffixes.

Understand process rules and TUN limitations

A process rule can send an application to a policy group without maintaining a long domain list. On a supported desktop mihomo environment, an example may look like PROCESS-NAME,Zoom,Work or PROCESS-NAME,slack,Work. The executable name must match the operating system’s actual process name, not necessarily the label shown in the application launcher. Some applications also start helper processes for media, updates, crash reporting, or embedded web content. Routing only the visible main process may therefore produce an incomplete result.

When TUN is enabled, check whether the client has options such as auto-route, strict-route, stack selection, and DNS hijacking. These options influence whether traffic is captured, how private addresses are handled, and whether applications can resolve domains consistently. If a meeting client signs in successfully but cannot establish audio or video, inspect both the connection log and DNS log. A successful web login proves only that one HTTPS path works; it does not prove that real-time media traffic follows the same route.

Apply the setup and test it step by step

Make changes while you have a quiet period, not immediately before a customer meeting. Export or copy the current configuration first, and change one area at a time. The following sequence works in FlClash and in many other clients that expose profiles, rules, proxy groups, and connection logs under similar names.

1. Record the baseline. Note the current mixed port, active mode, TUN state, selected policy, and whether the system proxy is enabled. Run one ordinary speed test and record the approximate idle latency and upload speed. You do not need laboratory precision; the purpose is to recognize a meaningful regression.
2. Create or identify the work group. In the profile or YAML editor, add a select group with at least one preferred route and one backup. If you use url-test, set a moderate interval such as 300 seconds instead of probing every few seconds. Excessive health checks can create noise and unnecessary requests.
3. Add local bypass rules first. Place private ranges, loopback addresses, and local discovery exceptions before work-service rules. Test the router page, a network printer, and a local file share. If any of them fail, fix the bypass before continuing.
4. Add narrow service rules. Start with the domains required for sign-in and messaging. Open Zoom, Slack, and Google Meet separately, then watch the connection log while loading a workspace or joining a test meeting. Add only confirmed domains and avoid copying every destination opened by the application’s update checker.
5. Reload the profile and clear stale state. Update or reload the configuration, restart the affected application, and, if necessary, restart the system proxy or TUN service. A client can retain existing connections after a rule change, so testing without restarting may give a misleading result.
6. Test one service at a time. Send a Slack message, open a Google Meet test call, and join a Zoom test meeting. Confirm that the connection log shows the intended policy group and that local services still use DIRECT.

Measure more than a single ping value

Latency is useful, but meeting quality depends on jitter, packet loss, upload stability, and route consistency. A node reporting 80 ms in a simple HTTP probe can still perform poorly for audio if its path experiences bursts of loss. Conversely, a route with a slightly higher average latency may feel better when it has stable jitter and reliable upload capacity.

Run at least two tests for each candidate route: one during a quiet period and one during the time when your household network is busy. If video becomes unstable only when another device uploads a large file, the problem may be bufferbloat or an upstream bandwidth limit rather than a Clash rule. In that situation, changing nodes repeatedly will not solve the underlying congestion. Enable appropriate quality-of-service controls on the router, reduce competing uploads, or reserve sufficient upstream capacity for meetings.

# Example diagnostic record
Date: 2026-08-31
Mode: rule
TUN: disabled during first test
Work policy: Auto Work
Probe result: 92–108 ms over 5 minutes
Meeting result: 0.4% loss, stable upload
Local NAS: DIRECT, reachable
Fallback tested: Backup Work

Keep this record private if it contains node names, public IP addresses, workspace domains, or subscription details. The goal is to compare routes objectively and to make rollback easy. If the work group performs worse than direct access on your network, leave the group available but do not force every collaboration domain through it. Some regions and organizations have direct routes that are already faster and more reliable.

Maintain split tunneling without creating new failures

Split tunneling is not a one-time switch. Applications add domains, cloud providers change endpoints, subscriptions replace node names, and operating-system updates can alter TUN behavior. Review the configuration after a major client or mihomo update, especially when moving between system proxy mode and TUN mode. Keep a dated backup of the last known-good YAML and document which policy group was selected for work.

Use rule order as a deliberate safety mechanism. Private address rules should normally precede broad matching rules. Specific service exceptions should precede a general regional or geolocation rule. A final rule such as MATCH,Final should always be present so that unmatched traffic has a known destination. Without a final rule, behavior can depend on the client’s defaults and become difficult to explain.

• Meeting connects but audio fails: Check whether media-related connections are being blocked, sent to a dead node, or routed through a process that bypasses the proxy. Compare the connection log during sign-in with the log during an active call.
• Slack messages arrive late: Look for repeated reconnects, WebSocket failures, DNS delays, or an overloaded work node. Test the backup group manually before adding broad new rules.
• Google Meet works in a browser but not in the desktop environment: Confirm whether the desktop app or embedded browser uses the system proxy. If it ignores that setting, test TUN with local bypass rules enabled.
• Local devices stop working after enabling TUN: Check private CIDR rules, route exclusions, DNS hijacking, and the client’s auto-route setting. Do not solve a local-network problem by adding random public DNS rules.
• Everyday browsing becomes slow: Inspect whether broad suffix rules route all Google, Microsoft, or cloud traffic through the work group. Narrow the match scope and keep ordinary local destinations on DIRECT.
• A configuration update breaks the group: Check whether the subscription renamed or removed the proxy members referenced by your manual group. Rebuild the group with current names and retain the old YAML as a rollback copy.

Finally, protect the meeting itself from unnecessary changes. Avoid manually switching nodes while a call is in progress unless the current route has clearly failed; a policy change can interrupt existing TCP, WebSocket, or media connections. Choose a preferred route before the meeting, verify it with a short test call, and keep the backup route ready. A focused configuration with explicit work routing, direct local traffic, moderate health checks, and repeatable diagnostics is usually more dependable than a large collection of untested rules.