Clash Remote Work Setup: Better Zoom and Slack Connections

1. Plan the route: improve calls without proxying every work app

A reliable work-from-home setup is not simply “turn on Clash and select the fastest node.” Zoom, Slack, and Google Meet use a mix of web requests, persistent connections, and real-time audio or video traffic. The route that works for a sign-in page may not be the route that gives a call stable audio. Start by deciding which services should use a proxy, which local destinations should remain direct, and how you will check the actual route.

This guide uses a mihomo-based Clash configuration and a low-latency proxy group for selected work services. The group chooses among nodes already available in your configuration; it does not create nodes or guarantee call quality. A health-check result measures a request to a test URL at a particular time. It does not measure packet loss, jitter, upload capacity, or the network path from a node to a meeting participant.

Keep traffic routing separate from traffic capture. In Rule mode, a matching rule selects an outbound only after the client has handed the connection to the core. System Proxy normally captures applications that honor the operating system’s proxy setting, often including browsers, but may not capture every desktop app or UDP media flow. TUN mode can capture more system traffic, including many UDP connections, but requires additional permissions and should be tested with your organization’s network and security policies in mind.

2. Prepare the client and choose a node for real-time work

Before changing rules, confirm that your subscription is current and that at least two candidate nodes connect. Export the active configuration or make a backup through the client’s profile or configuration page. Subscription-generated files can be replaced on update, so put persistent changes in a supported override or merge layer rather than assuming a direct edit will survive.

1. Open the client’s About or Core Information page and confirm that it is running mihomo or another core that supports the YAML fields you plan to use.
2. In Settings, note the HTTP or mixed port, current mode, TUN status, and whether the system proxy is enabled. Menu names differ between Clash Verge Rev, Clash Verge, and other clients.
3. Open the Proxies or Connections view and confirm that candidate nodes are available. For work calls, prefer a nearby, stable route that reaches the services you need; a node name alone is not evidence of its location or performance.
4. Run a short baseline call before editing the configuration. Note whether the issue is slow connection setup, audio gaps, video quality, or file transfer. Changing one variable at a time makes the comparison useful.

A url-test group can help select a responsive node automatically. The example below assumes the three proxy names already exist under proxies. Replace them with names from your configuration, preserving exact spelling. If your client manages nodes through a proxy provider, use the provider mechanism supported by that configuration instead of adding nonexistent names.

proxy-groups:
  - name: Work Low Latency
    type: url-test
    proxies:
      - Nearby Node 01
      - Nearby Node 02
      - Backup Node 01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

• interval: 300 checks the candidates every five minutes; it is not a 300-millisecond interval.
• tolerance: 50 discourages switching for a small measured difference. It does not eliminate packet loss or stabilize an overloaded node.
• lazy: false requests regular checks rather than waiting for the group to be used, where supported by the running core.
• Keep a manually selectable backup group or node available. If automatic selection changes during an important call, compare the current outbound with the backup before concluding that the rule is at fault.

Latency is only one selection signal. A node that answers the probe quickly may still have limited upload bandwidth or a poor route to a meeting media server. Test at the time and on the network where you actually work, and keep the candidate set small enough that the results are easy to interpret.

3. Add focused rules and preserve direct routes

Clash checks rules from top to bottom and uses the first match. Put specific work-service rules above broad rule sets and the final MATCH rule. Keep existing local and intranet exceptions above the work rules, or add them explicitly if your current configuration does not already handle them. The following is a merge example, not a complete configuration: retain your existing DNS, proxy, provider, and policy-group definitions, and keep only one top-level rules key.

rules:
  # Keep private and local destinations direct
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,home.arpa,DIRECT

  # Selected work-service domains
  - DOMAIN-SUFFIX,zoom.us,Work Low Latency
  - DOMAIN-SUFFIX,zoom.com,Work Low Latency
  - DOMAIN-SUFFIX,slack.com,Work Low Latency
  - DOMAIN-SUFFIX,slack-edge.com,Work Low Latency
  - DOMAIN-SUFFIX,slack-files.com,Work Low Latency
  - DOMAIN,meet.google.com,Work Low Latency

  # Preserve the policy used by the rest of your configuration
  - MATCH,Proxy Selection

The sample private-address rules cover common IPv4 private ranges, not every possible local network or IPv6 setup. Keep your own LAN, intranet, printer, and company VPN exceptions if they use other addresses or domains. Do not copy a private-range rule over an existing policy without checking how your network handles DNS, IPv6, and private services.

These domains are a starting point, not an exhaustive list of every service endpoint. A service can use additional hostnames, content-delivery networks, or IP addresses. Google Meet is a particularly important case: the meeting page’s hostname does not prove that every real-time media connection uses that hostname. Slack messages and file previews may work while Slack calls still have a separate media-path problem. Inspect the client’s Connections view during the exact action that fails, and add only verified destinations that you are permitted to route.

4. Hands-on test: apply the rules and verify each service

Make this test with one device and one change set. Save the edited configuration, then use the client’s configuration check or reload action. If the configuration fails to parse, restore the backup and inspect indentation, duplicate top-level keys, group names, and proxy names before trying again. A rule that refers to an undefined policy group may not behave as intended even if the YAML appears visually correct.

1. Check Rule mode. Select Rule mode in the client. Global mode can route traffic according to a different policy; Direct mode bypasses the routing intent of these rules. Keep the system proxy or TUN setting unchanged for the first comparison.
2. Check the selected group. Open Proxies, select Work Low Latency, and confirm that the chosen node is available. If the group has no candidates, verify that the names in the group exactly match existing proxies.
3. Test web traffic separately. Open Zoom, Slack, and Meet sign-in or landing pages. In Connections, filter by the service domain and check the matched rule, policy group, and final outbound. If nothing appears, the app may not be using the capture method currently enabled.
4. Test the actual call. Join a short test meeting and check Connections while audio and video are active. Note whether new UDP connections appear, what destination they use, and whether the selected route changes. Do not infer the media route from a successful login page.
5. Compare with a controlled alternative. If calls are unstable, switch only the selected node or test another approved capture mode, then repeat the same call. Record whether latency, audio gaps, and video recovery improve rather than changing DNS, rules, and TUN settings simultaneously.
6. Test direct traffic. Open an intranet page or access a local device that should remain direct. Confirm that its connection is not sent to the work group and that local name resolution still works.

For an explicit HTTP proxy check, first confirm the port shown in the client’s Settings. The following example assumes that the HTTP or mixed listener is on 127.0.0.1:7890; use your actual port. This tests a web request through the local listener, not the complete route used by a desktop call or UDP media.

curl -v --connect-timeout 10 --max-time 20 --noproxy "" \
  --proxy http://127.0.0.1:7890 https://meet.google.com/ -o /dev/null

Read the output together with the client’s Connections or Logs view. A refused connection usually points to a stopped core, wrong port, or listener bound to a different address. If the local proxy accepts the request but the destination fails, check the selected node, matched rule, DNS behavior, and service availability. A successful curl request demonstrates that an HTTP request can traverse the listener; it does not establish that Zoom, Slack, or Meet will send every connection through it.

5. Troubleshoot call quality without broadening rules blindly

When a service is partly working, identify the failing layer before adding more domains. A sign-in failure, a slow file preview, a call that connects without audio, and intermittent video are different symptoms. Use timestamps and the destination shown in Connections to compare one failed attempt with one successful attempt. Avoid sharing subscription URLs, authentication headers, meeting links, or logs containing account details when asking for help.

Some real-time services attempt UDP and may fall back to TCP when UDP is unavailable or unsuccessful. TUN can capture more traffic than a conventional system proxy, but behavior depends on the client, core configuration, operating system, and service. Do not assume that enabling TUN automatically produces the best route. Confirm that the virtual adapter starts correctly, that local and company networks remain reachable, and that the service’s actual media connections appear in the core.

Port-based rules are a possible diagnostic tool, but they have a wider impact than a domain rule. A rule such as DST-PORT,8801,Work Low Latency affects matching traffic from any application, not only Zoom. Zoom may use different transport and port combinations depending on the network and client version. Before adding a port rule, verify the destination port in the connection details and check that the rule will not redirect unrelated traffic. If the capture layer never sends the connection to Clash, a port rule cannot fix that capture problem.

When the change does not help, roll back the last adjustment and restore the known-working configuration. Preserve a direct fallback for local resources and a manual node choice for urgent meetings. A focused setup is easier to maintain: route only the work traffic you have verified, keep the rest of your policy intact, and use the client’s connection records to distinguish rule selection from media capture and node quality.