Clash Setup for Remote Work: Route Zoom and Slack Better

Route Work Apps Selectively, Not Your Entire Connection

For a smoother workday, it is usually better to route only the services that need a proxy than to send every connection through one. In Clash, rule mode lets you choose an outbound policy for each connection: a Zoom or Slack rule can use a proxy group, while local devices, ordinary websites, and other destinations can follow their existing rules. This keeps the setup focused and makes unexpected behavior easier to diagnose.

Keep the two parts of traffic handling separate. The system proxy or TUN determines which app connections enter the Clash core; the active mode and rules determine what happens next. A browser may follow the system proxy while a video-call app uses its own networking stack. TUN can capture more traffic without requiring each app to use an HTTP proxy, but it does not automatically make every connection use a proxy. A connection that matches a DIRECT rule still goes direct.

Zoom, Slack, and Google Meet also do not behave like a single webpage. A call can involve sign-in, web requests, file or image delivery, signaling, and real-time audio or video. These connections may use different hostnames and transports. A rule for one visible website can therefore be a useful start without covering every component of a meeting.

Choose Rules and a Proxy Group That Fit the Call

Clash checks ordinary rules from top to bottom and uses the first matching rule. Put a targeted rule before broader rules that could match the same destination, and keep the existing catch-all rule, commonly MATCH, at the end. The policy named on each rule must exist in the active configuration. Group names are configuration-specific, so replace the example name below with the exact spelling used by your current proxy group.

These are starting points, not a complete or permanent inventory of every hostname each product may use. A domain-suffix rule matches that domain and its subdomains; it does not match an unrelated domain merely because the text looks similar. For example, DOMAIN-SUFFIX,zoom.us can match zoom.us and api.zoom.us, but not zoom-example.net.

Avoid routing all of google.com or every Google-owned domain through the proxy just to make Meet work. That can redirect Gmail, search, software updates, and unrelated services, and may make troubleshooting more confusing. If a meeting component is still direct, inspect the connection log to identify the actual destination before adding a narrower exception. Do not copy a hostname from an unfamiliar online list without checking whether it is relevant to your own connection.

Consider How the Proxy Group Behaves

A selector group gives you a manual choice, which is useful when you want to keep the same outbound route for a meeting. An automatic or latency-testing group can select a node based on its configured test, but a quick HTTP latency result does not prove that a video call will have low jitter, stable UDP, or a reliable route to the meeting server. Test the group under the conditions in which you actually work.

For Zoom and Meet, confirm whether the selected outbound supports UDP if the service is trying to use UDP media. A proxy node may connect successfully over TCP while real-time media is slow, unstable, or falling back to another transport. Availability depends on the core, proxy protocol, node configuration, and route; a rule alone cannot add UDP support to an outbound that does not provide it.

Add and Test the Rules Step by Step

This hands-on example adds app-specific domain rules that send the listed domains to an existing proxy group. It is a merge example, not a complete subscription configuration: it does not define proxy servers, DNS settings, or the group itself. Use the configuration editor or override mechanism supported by your client, and do not assume that directly editing a generated subscription file will survive its next update.

1. Record the active setup. In your Clash client, note the active configuration, mode, core name and version, and the existing proxy-group names. Export or copy the configuration before editing. Subscription URLs can contain access tokens, so keep both the URL and any exported file private.
2. Confirm rule mode and traffic capture. Select rule mode in the client. Check whether the apps use the system proxy or whether TUN is needed to capture connections that ignore it. If another VPN or network-filtering app is active, test without it where practical; overlapping VPN routes can change which connections reach Clash.
3. Choose a real policy name. Replace Work-Proxy below with a proxy group that exists in your active configuration. If the group is missing, the configuration may fail to load or the intended route will not be available. Do not create a new group name in the rules without also defining that group.
4. Insert the rules in the correct place. Put them above broader rules that would otherwise match these domains, but preserve existing local-network and service-specific exceptions where they are intentional. Keep the final fallback rule last.
5. Reload and verify. Apply the configuration using your client's reload or update function. Check for parse errors, confirm the intended group is selectable, then open the connection log while signing in and starting a test call.

rules:
  - DOMAIN-SUFFIX,zoom.us,Work-Proxy
  - DOMAIN-SUFFIX,zoom.com,Work-Proxy
  - DOMAIN-SUFFIX,slack.com,Work-Proxy
  - DOMAIN-SUFFIX,slack-edge.com,Work-Proxy
  - DOMAIN-SUFFIX,slack-files.com,Work-Proxy
  - DOMAIN-SUFFIX,slack-imgs.com,Work-Proxy
  - DOMAIN-SUFFIX,slack-msgs.com,Work-Proxy
  - DOMAIN,meet.google.com,Work-Proxy
  # Keep your existing rules below these entries,
  # including the configuration's final fallback rule.

The list is intentionally conservative. Add domains only when the connection log or a controlled test shows that a required service component is taking the wrong route. If you use rule providers or a client-specific merge feature, follow that client's supported format instead of pasting a top-level rules: block into a section with a different structure. Core capabilities and override behavior vary; an interface accepting a configuration does not guarantee that every field or provider format is supported by its current core.

Check Calls and Diagnose Routing in Order

Test one service at a time. First confirm that the app can sign in and load its ordinary interface; then test a call, file transfer, or Huddle. While doing so, watch Clash's connection log and note the destination, matched rule, selected policy, and whether the connection is TCP or UDP when that information is available. This is more informative than repeatedly changing modes and guessing which change helped.

• The app works but the call does not: The web or signaling connection may be routed correctly while the media path uses another host or transport. Check whether the media connection is captured, whether the outbound supports UDP where required, and whether the app has fallen back to TCP.
• The log shows the expected domain but the wrong policy: Check rule order and the active configuration. A broader rule above the new entry may match first, or the client may still be using a different profile than the one you edited.
• The call app does not appear in the log: The connection may not be entering the core. Check the system proxy setting, the app's own proxy options, and whether TUN is required. TUN involves operating-system routing and permissions; enabling its switch is not proof that every app connection is being captured.
• A domain rule appears not to match: The app may be connecting to another hostname, or the core may have only an IP address available for rule matching. Check DNS handling and domain sniffing settings supported by your core. Do not assume that adding a suffix for the website's main domain will also match a separate CDN or media endpoint.
• Everything becomes slow after adding rules: Confirm that the selected group and node are reachable, then compare a fresh connection using a different node or a direct test if appropriate. Existing connections may persist after a rule change, so fully quit and reopen the app or start a new call before comparing results.

For a controlled comparison, keep the same network and meeting conditions, change only one variable, and use a fresh connection for each test. For example, compare the current work group with another available node while leaving the rule list and capture method unchanged. A brief global-mode test can help compare policy behavior, but restore rule mode afterward; global mode bypasses the ordinary rules and can route unrelated captured connections through one policy.

Also check local causes before blaming the proxy. A weak Wi-Fi signal, a loaded access point, a busy upload link, a restrictive office firewall, or another VPN can cause audio and video issues. Compare the app's connection diagnostics and call statistics where available. A successful page load proves only that a web request completed; it does not establish that a real-time media path is stable.

Keep Work Routing Narrow and Maintainable

Service domains and network behavior can change, so treat a list of routing rules as a small, documented part of your configuration rather than a one-time guarantee. Add a short comment or keep a private note explaining why each exception exists, which app behavior it fixes, and which proxy group it uses. After a subscription update or core change, verify that the group name still exists and the rules still load.

Prefer a small set of rules over a large copied list. A hostname that was once needed may later be unused, while a broad suffix can unintentionally include unrelated services. If an exception stops being necessary, remove it only after testing on the network and app version you use. Keep a backup so you can revert quickly if the updated configuration changes other traffic.

For a workday baseline, use rule mode, route only confirmed work-service destinations through an available group, and leave local resources and unrelated traffic under the rules you already trust. Use TUN only when the apps you need are not covered by the system proxy, and check both capture and outbound support for real-time media. This approach gives you a clear path to troubleshoot: identify the connection, confirm its matched rule, confirm the selected policy, then test the actual call.