Clash Remote Work Setup for More Reliable Zoom and Slack

Plan the routing before changing settings

A reliable work-from-home setup is not simply “turn on the proxy and hope every call improves.” Zoom and Slack use multiple services for sign-in, messaging, file delivery, voice, and video. The desktop apps may also handle connections differently from a browser. A useful setup therefore has three parts: a working Clash configuration, a dependable proxy group for the services that need it, and a direct route for ordinary browsing that does not need the proxy.

Clash clients provide the interface for importing configurations, selecting nodes, and controlling the system proxy or TUN mode. The core, such as mihomo, evaluates rules and opens the connections. A client showing “connected” does not prove that Zoom’s audio or Slack’s file delivery is using the route you intended. Confirm the route in the client’s Connections or Logs view while making a real test call or sending a test file.

First decide what you want to change. If your work services are reachable but unstable, try a different node or route only those services through a proxy. If company policy requires a specific network path, follow that policy rather than adding an unapproved proxy. If the problem is a weak Wi-Fi signal, congestion, or a failing ISP connection, changing Clash rules will not repair the underlying network. Test one variable at a time so you can tell whether a change helped.

• Keep everyday browsing direct: Use Rule mode and add narrowly scoped service rules above the final catch-all rule. Don’t switch to Global mode just to test one app.
• Choose a stable route: Prefer a node with consistent loss and latency over one that only has a low displayed delay in a single test.
• Preserve a working fallback: Keep the original configuration or export a copy before editing rules, groups, DNS, or TUN settings.
• Check the application path: A browser, the Zoom desktop app, and Slack may not use the same proxy mechanism on your computer.

Choose a dependable node and the right traffic mode

For video meetings, stability matters more than a one-time speed-test result. A node with a slightly higher latency but fewer interruptions can be better for a call than a nominally faster node with packet loss, jitter, or overloaded capacity. Test from the same computer and network you use for work, and compare a few candidate nodes at different times of day. If your provider supplies a latency test, treat its result as a screening tool: it usually measures a particular request and does not reproduce a live Zoom meeting.

Use Rule mode when you want service-specific routing. In this mode, the core checks the rules in order and sends matching traffic to the named policy group or outbound. A proxy group may offer options such as manual selection, automatic selection, or fallback, but its behavior depends on the configuration. A group called “Auto” is not automatically a guarantee of a stable call; confirm which node it actually selected and whether it switches during a meeting.

Use Global mode only as a short diagnostic if you need to determine whether a particular connection works through the selected proxy. Global mode sends broadly matched traffic through the global choice, which can make ordinary browsing and unrelated work services take a different route. Return to Rule mode after the test. Direct sends traffic out without a proxy; it is useful for services that should use the local network or for comparing a direct connection, but it does not improve a remote service when the direct path is the source of the problem.

Zoom meetings use real-time media traffic, which may use UDP when the network permits it and can fall back to TCP in some conditions. Commonly documented Zoom network requirements include UDP ports 3478–3479 and 8801–8810, with TCP 443 and other documented ports used by particular services or fallback paths. These port numbers are not a recommendation to expose inbound ports on your home router, nor does adding a port rule ensure a successful meeting. Clash generally routes outbound connections; your local firewall, router, employer network, and the remote service still determine whether the traffic can pass.

Slack uses several services for its workspace, messaging, calls, and files. A rule for a single sign-in domain may let you sign in but fail to cover an image, download, or call. Conversely, sending every connection through one remote node can add delay or make a large file transfer slower. Start with narrowly scoped domain rules supported by your config, then use the Connections view to see which destinations the actual app contacts. Avoid copying a large, unofficial domain list into a live work configuration without checking what it matches.

Configure and test service-specific routing

Before editing, open the client’s Profiles or Config page and make a backup. Locate the active configuration and identify the exact proxy group name you want to use. Names are case-sensitive in YAML references in many contexts, and a rule that points to a group that does not exist can prevent the configuration from loading. If the client provides a rules editor or an override feature, use the method documented for that client rather than editing a generated subscription file that will be overwritten during the next update.

The following is an illustrative rules fragment, not a complete configuration. Replace WORK-PROXY with a policy group that already exists in your configuration. Add rules before a broad final rule such as MATCH. The domains are examples; verify the destinations seen in your logs and use service guidance for your region and organization.

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
  - MATCH,DIRECT

Do not paste this fragment over an existing rules section without reviewing it. Your current configuration may already contain provider rules, rule providers, or a different final policy. Preserve those entries and put new, specific rules before the catch-all that would otherwise match first. A rule for a domain suffix is not the same as a rule for every IP address used by that service; DNS resolution, shared hosting, and changes to service infrastructure can affect what appears in the connection list.

1. Confirm the baseline: Start with a working config and a known-good node. In Rule mode, note the active group, local proxy port, core status, and whether system proxy or TUN is enabled.
2. Apply one change: Add only the required service rules through the supported editor or override mechanism. Save or update the profile, then check that the client reports a successful config load.
3. Test Zoom: Join a test meeting or a low-risk call. Check microphone and speaker selection, video, reconnect behavior, and the client’s network statistics. In Clash, inspect new Connections entries and confirm the matched policy and selected outbound.
4. Test Slack separately: Sign in, send a short message, load an image, and download a small test file if your workplace permits it. Check whether each request is routed as intended; a successful text message alone does not verify file delivery or calls.
5. Check ordinary browsing: Open a site that should remain direct, then inspect its connection entry. If it uses the proxy, review rule order, the final catch-all, and whether the app or browser is using a different proxy configuration.
6. Record the result: Note the time, selected node, mode, client and core versions, and any relevant log error. Change one setting at a time and repeat the same test before deciding whether to keep the change.

Windows and macOS system-proxy controls usually affect applications that honor the operating system’s HTTP or SOCKS proxy settings. They do not guarantee that every desktop application sends all traffic through that proxy. If Zoom or Slack does not appear in Clash Connections while the system proxy is enabled, first check the application’s own proxy settings and the client’s system proxy status. If the app still bypasses the proxy and your configuration and network policy allow it, TUN mode can capture traffic at the network-interface level. TUN setup may require administrator approval, a background service, or a system extension; grant only the permission explained by the client and keep LAN access disabled unless you have a specific need for it.

Desktop-specific checks for Windows and macOS

Windows: separate system proxy, app behavior, and TUN

In a Windows Clash client, check the main dashboard or General settings for the system proxy toggle, then verify the configured mixed or HTTP port under the client’s port settings. A common local address is 127.0.0.1, and a port such as 7890 is only an example; use the value shown in your client. Do not substitute the controller port, which is used for management rather than ordinary proxy requests.

If a browser works but Zoom does not, that is evidence that the browser’s route is available, not that Zoom is configured identically. Check the client’s Connections page while starting a meeting. If no Zoom-related connection appears, confirm whether the app honors system proxy settings. If connections appear but use DIRECT, review the matched rule and rule order. If they use the intended group but fail, test another node and inspect logs for timeouts or DNS errors before changing ports or disabling firewall protections.

Some Windows clients offer TUN through a service or virtual network adapter. Follow the client’s own installation prompt, verify that the service belongs to the installed client, and avoid running the whole application as administrator for routine use unless the product specifically requires it. If an employer-managed VPN, endpoint protection, or another virtual adapter is active, check for a routing conflict with the IT administrator before changing adapter priority or routes.

macOS: verify the active network service and permissions

On macOS, confirm that the client has applied its system proxy to the network service currently in use, such as Wi-Fi or Ethernet. A setting applied to one service may not cover another interface. If you change networks, reopen the client’s status view and verify the proxy state again. Also check whether a browser extension or manually configured proxy overrides the operating system’s settings.

When using TUN, macOS may show a permission prompt for a network extension or ask to approve a system component, depending on the client and operating-system version. Read the prompt and the client’s documentation before approving it. If the app does not capture Zoom or Slack traffic, check the TUN status, relevant permission, and Connections page rather than repeatedly toggling the system proxy. A working browser test is not enough to confirm that a native app’s UDP media path is being handled correctly.

On either platform, leave everyday browsing on DIRECT only when that is your intended policy and the direct path is available. If ordinary traffic must also use a company-approved route, follow that policy instead of using the sample catch-all. For more platform setup guidance, see the Clash tutorial; for compatible client options, use the client comparison.

Diagnose call and message problems without changing everything

When a call breaks up, a Slack file will not load, or the selected route seems wrong, start with the client’s evidence. Open Connections and Logs, note the time of a fresh attempt, and look for the destination, matched rule, policy group, selected outbound, and connection error. Temporarily using the info log level is often sufficient; turn on more detailed logging only when needed, and avoid sharing logs that expose workspace names, addresses, subscription details, or other private data.

For a fair comparison, keep the same Wi-Fi or Ethernet connection, meeting, device, and test duration. Compare direct and proxied behavior only if workplace policy permits both. A speed test measures a different mix of connections from a live call, and a ping result alone does not measure jitter, loss, or the quality of Zoom audio. Use the application’s meeting statistics when available, and look for repeated patterns rather than drawing a conclusion from one momentary fluctuation.

If a direct route works but the proxy route fails, focus on the node, policy group, or configuration match. If the proxy route works but direct does not, check the local network, ISP path, or whether the service requires an approved egress. If neither works, confirm the general network connection and service status before rewriting the config. When the client reports a parse error after a rule edit, restore the backup and validate YAML indentation, commas, group names, and rule order before trying again.

A practical final configuration is one you can explain and reproduce: Rule mode is active, the work-service rules match the intended group, ordinary sites follow the intended direct or approved route, and both applications have been tested in the features you actually use. Save a copy of the working config and record the client, core, node, and test results. That gives you a useful baseline when a future app update, subscription refresh, network change, or policy change alters the behavior.