A Practical Clash Setup for Remote Work
When you work from home, a proxy configuration needs to do more than open websites. A useful setup should keep video and voice calls stable, make team chat and file sharing dependable, and leave ordinary local traffic on the shortest route. Sending every connection through one distant server can add delay to a meeting, while routing everything directly may not work well on networks with poor international connectivity. Clash lets you choose a route by rule, so you can make these decisions per service instead of switching the entire client between modes.
This guide covers a measured approach for Zoom, Slack, and Google Meet. The right choice depends on your location, network, organization’s requirements, and the quality of the available nodes. Direct routing is often a good first test for calls when the services work reliably on your local connection. If a service is unavailable or its international route is poor, try a nearby, stable proxy instead. Do not assume that one policy is best for every app or every office network.
Setup Goal
Route collaboration traffic deliberately, test call quality on both direct and proxied paths, and keep local or private-network destinations direct where appropriate.
Clash clients such as Clash Verge Rev provide a graphical interface for importing a profile, selecting a mode, and inspecting connections. Exact labels differ between clients and versions, but the underlying ideas are consistent. This article uses Mihomo-style rule examples; check that your core supports the syntax before adding it. Back up your profile first, and follow your employer’s security policy before changing how work traffic is routed.
1Prepare the Client and Choose Rule Mode
Start with the profile you actually use for work. In Clash Verge Rev, for example, open Profiles, confirm that the intended configuration is active, and check that the core starts without errors. In another client, look for the equivalent profile or configuration screen. A profile supplied by a provider may include its own rule providers, proxy groups, DNS settings, and final catch-all rule. Understanding those pieces before editing prevents a small change from breaking unrelated browsing.
For rule-based split routing, select Rule mode rather than Global mode. Global mode typically sends most traffic through one selected proxy and is useful as a temporary diagnostic, but it is not a good default for a work setup that should keep local traffic direct. Direct mode is also not a substitute for carefully ordered rules if some services need a proxy. In Rule mode, Clash checks rules from top to bottom and applies the first matching policy.
Check Your Profile’s Groups and Final Rule
Before pasting an example, inspect the names of the proxy groups in your profile. A rule that refers to a group called Work will fail if that group does not exist. Many configurations instead use a group such as Proxy, Global, or 🚀 Select. Replace the example policy names below with names that appear in your own configuration. Also check the end of the rule list: a final rule such as MATCH,Proxy catches traffic not matched earlier, while MATCH,DIRECT sends unmatched traffic directly.
Make a Reversible Change
Duplicate or export your current profile before editing. Add a few rules at a time, reload the configuration, and verify that the core reports no YAML or policy-group errors.
If the profile is managed by a subscription, a provider update may overwrite manual edits. Prefer the client’s supported override, script, or merge feature when available, and keep your customization separate from the downloaded profile. If you cannot use an override, record your changes and recheck them after each profile update. Do not edit a generated file if the client warns that it will be replaced.
2Route Zoom, Slack, and Google Meet
There is no universal rule list that captures every connection made by a collaboration app. A desktop client may use several domains for sign-in, signaling, media, updates, crash reports, and file delivery; a browser-based meeting may use additional services. Domain patterns can also change. Begin with the simplest policy that addresses the problem you have observed, then use Clash’s connection or log view to see which rule actually handled the relevant traffic.
Add Targeted Rules Above the Catch-All
The following is an illustrative starting point for a Mihomo-compatible profile. It routes common service domains to a group named Work-Proxy, while leaving local and private destinations direct. This is not a complete vendor-maintained domain list, and matching a service domain does not guarantee that every media connection will match it. Replace Work-Proxy with an existing group or define a suitable group in your profile.
Place any service rules above the final catch-all rule. If your final rule points to a proxy group instead, unmatched connections will use that group, so local and private exceptions need to appear before it. The examples use a proxy policy to make the services easy to test on a network where direct access is unreliable. If direct access is better in your location, change the relevant service policy to DIRECT, or create separate policies so you can switch routes without editing YAML each time.
Do not treat google.com as a precise Google Meet-only match. It is broad and may affect other Google services that share that domain. Likewise, routing all of Slack through a proxy may include sign-in, messages, and file-related connections, not just calls. For more selective behavior, use the client’s connection log to identify the actual hostnames involved, then add only the narrow rules you need. Avoid adding guessed IP ranges: service IPs can change, shared hosting can make ranges overbroad, and an incorrect IP rule may capture unrelated traffic.
Test Direct and Proxy Paths Separately
Change one service at a time. Start a short test meeting or use your team’s approved test channel, and compare DIRECT with the selected proxy group under similar network conditions. Look beyond whether the app connects: check whether voice is clear, video remains steady, screen sharing works, and messages or files complete reliably. If a proxy fixes access but makes audio worse, try another nearby node or return media traffic to direct routing if your organization allows it.
Do Not Assume Domain Rules Cover All Media
Video and voice may use UDP or dynamically selected endpoints. A domain rule can route the app’s web requests while a media stream follows another path. Verify actual connections and call behavior instead of relying on a single hostname rule.
3Select a Node for Calls and Collaboration
For real-time calls, raw download speed is only one part of node quality. Latency is the time it takes for traffic to make a round trip, while jitter describes how much that delay varies. Packet loss can make a call sound choppy even when a speed test looks impressive. A nearby node with consistent performance is often a better candidate than a distant node with a higher advertised bandwidth.
Use the proxy-group selector in your client to compare several nodes that are permitted by your subscription and network policy. If the client has a latency test, treat its result as a quick filter, not a guarantee of call quality: it may test a website over TCP rather than the same route and protocol used by meeting media. Confirm the result with a real test call. Avoid repeatedly switching nodes during an important meeting, since changing the public IP or breaking a session may interrupt the call or trigger a new sign-in check.
- Prefer consistency: Compare latency more than once, at different times of day. A node that fluctuates less may feel better than one with a slightly lower best-case result.
- Consider geography: Test a node near the service region or your team when it provides a shorter, stable route. The nearest location is not automatically the fastest if its upstream routing is congested.
- Check media support: If you need to proxy calls, confirm that the core and node support the required traffic, including UDP when applicable. A successful browser page load does not prove that a video call can use the same route.
- Keep a fallback: Identify one tested alternative node and know how to return the service to direct routing. This is more reliable than changing several rules under pressure.
Some office Wi-Fi networks, hotels, and corporate security systems restrict tunneling or UDP. Do not try to bypass an organization’s controls. If a route fails only on a managed network, contact the network administrator or use an approved connection method. For company accounts, a proxy can also affect sign-in risk checks, access policies, and data-location requirements; confirm that your selected route is permitted before routing work traffic through it.
Keep a Simple Test Record
Note the date, service, route, node, approximate latency, and observed call quality. A short record helps distinguish a bad node from a temporary home-network issue or a service outage.
4Keep Local Traffic Direct and Verify the Result
Remote work often depends on resources that should not take an unnecessary trip through a proxy: a local printer, a home router, a NAS, a company VPN gateway, or an internal hostname. Private IPv4 ranges are commonly used for these destinations. The example rules above send the standard private ranges directly, but your organization may use custom routes, split DNS, or a separate VPN client. Follow its instructions rather than assuming that all private addresses should bypass every security layer.
On a device that is not connected to a company network, add only the exceptions you need. Some profiles already include rules such as GEOIP,LAN,DIRECT or a private-network rule set, so check for duplicates before adding more. A local domain suffix rule is useful only if your device actually uses that suffix. Do not add broad domain keywords such as work or google as shortcuts; keyword matches can catch unrelated websites and make troubleshooting difficult.
Use the Connection View to Confirm Matching
After reloading the profile, open the client’s Connections or Logs panel while launching the target app. Find the relevant host and inspect the matched rule and policy. If a connection is handled by the catch-all rule instead of your service rule, check the hostname, rule order, and spelling of the proxy group. If a connection is not visible, confirm that system proxy or TUN mode is configured for the traffic you are testing. Not every client captures the same traffic in every mode.
DNS behavior can also affect rule matching and reachability. Keep the profile’s DNS configuration coherent with its routing rules, and avoid mixing manual DNS changes with profile changes unless you understand how the client handles them. If a domain resolves but the application still fails, test a fresh app session, review the connection log, and compare direct and proxied paths. Do not disable security features or change multiple DNS and routing settings at once; that makes it difficult to identify the cause and may expose queries outside the intended path.
Before a scheduled call, confirm that Clash is running, Rule mode is selected, the active profile has loaded, and the chosen policy group has a working node if proxy routing is needed. Test microphone, camera, and screen sharing in the meeting app itself. If the problem affects every route, check home Wi-Fi, bandwidth contention, and the service’s status before changing Clash rules. A local network problem can look like a proxy issue, and adding more rules will not repair a weak wireless signal.
5Maintain a Reliable Work Profile
A stable setup is usually a small setup. Keep only the rules that solve a verified problem, document why each custom rule exists, and periodically check that your profile still uses the same group names and rule behavior. When a subscription or core update changes the configuration, review the result before your next important meeting. If the client reports a parse error, restore the backup first and reintroduce changes in smaller batches.
Use this order when troubleshooting. First, confirm whether the affected service is available without Clash, if that is permitted on your network. Next, check the active mode and profile, then inspect the connection log for the destination, matched rule, and selected policy. Test a known-good node only if the current route requires a proxy. Finally, compare another device or network when possible. These checks help separate a rule-order mistake from a node problem, DNS issue, local Wi-Fi congestion, or an outage at the service provider.
If only one feature fails—for example, Slack messages work but file previews do not—avoid switching the entire device to Global mode as a permanent fix. Look for the specific connection involved, test a narrow rule, and verify that unrelated destinations still use the intended route. If the affected host is undocumented or changes frequently, a broader service policy may be more maintainable than a long list of fragile individual IP addresses. Keep the trade-off in mind: broader rules are easier to maintain but may route more traffic than intended.
Finally, be cautious with automatic selection and latency-test intervals. A group that changes nodes frequently can interrupt long meetings or cause repeated authentication checks. For work hours, choose a tested node and keep automatic switching conservative if your client offers that option. Re-evaluate your choice when call quality changes, when your home connection changes, or when your organization updates its network requirements—not simply because another node has a lower single test result.
Final Checklist
Use Rule mode, confirm rule order and group names, test each collaboration service on the route you intend to use, preserve local-network access, and keep a backup before profile edits.
With these checks, Clash can support a predictable remote-work routine without forcing every application onto the same route. Treat the examples as a starting point, verify behavior in your own environment, and choose the least complicated configuration that meets your connectivity and security needs.