A practical network model for remote work
Remote work depends on more than whether a browser can open a page. A video meeting, a chat client, a file upload, and an internal company portal may use different domains, transport methods, and connection lifetimes. When Clash is configured as one large on-or-off switch, it becomes difficult to tell whether a poor meeting is caused by the selected node, an incorrect rule, local congestion, or the application itself. A better approach is to define the traffic you want to route, the traffic that should remain local, and the evidence you will use to verify each decision.
This guide focuses on Zoom, Slack, and Google Meet, while keeping local websites and ordinary work services responsive. The goal is not to force every packet through a remote server. The goal is to create a predictable split policy: collaboration services use a stable proxy group when your network requires it, local services use DIRECT, and unknown traffic follows a controlled fallback instead of silently bypassing your policy.
Before changing anything, close duplicate VPN clients or other proxy applications. Two programs may both attempt to manage the system proxy, DNS, TUN interface, or virtual network adapter. The result can look random: Zoom may connect through one route while Slack follows another, and a configuration that appeared correct may be overwritten after a reconnect. Keep one traffic controller active while testing, and record the original system proxy settings so you can restore them if needed.
You also need a valid Clash-compatible profile and at least one proxy group that is suitable for interactive work. A node that performs well for downloading a large file may still be poor for meetings because of jitter, packet loss, or weak UDP support. Prefer a group with several nearby and reliable options rather than a single server selected only by its headline speed. Never publish a subscription URL in screenshots or issue reports; many URLs contain private access tokens.
Choose the client, profile, and work-friendly proxy group
The exact interface depends on your platform. Clash Verge Rev and other Mihomo-based desktop clients expose profiles, proxy groups, modes, connections, and logs in a way that is useful for troubleshooting. On macOS, Windows, and Linux, begin with the client that matches your operating system and confirm that it can load the profile without validation errors. If you are using an Android client, look for the equivalent sections for profile selection, rule mode, logs, and VPN or TUN permissions.
Import the profile through its normal subscription or profile-management screen. Do not paste fragments from several different YAML files into a live profile unless you understand their inheritance and syntax. A profile may define proxy names, groups, DNS behavior, rule providers, and ports that are expected to work together. If you replace only the proxy list while leaving groups that reference old names, the group can appear empty even though the import completed.
For remote meetings, start with Rule mode rather than immediately choosing Global mode. Global mode is useful as a diagnostic test because it answers one question quickly: can this device reach the required service when nearly all traffic uses the selected group? It is not always the best daily policy. Routing every banking page, printer portal, corporate intranet, and local video service through a distant node can add latency and create authentication or compliance problems.
Create or identify a group intended for collaboration traffic. A useful group might contain two or three stable nodes and use manual selection while you test. Automatic URL testing can help remove obviously dead nodes, but a low latency result from a short HTTP probe does not guarantee a good meeting. Keep one preferred node and one fallback node, then compare them during an actual call. Note whether audio remains clear, screen sharing starts promptly, and the connection survives ten or fifteen minutes rather than judging it after a single page load.
- Stable first: prioritize low packet loss and consistent latency over an impressive maximum-speed number.
- Interactive traffic: check whether the route handles long-lived HTTPS sessions and, where applicable, UDP-based media reliably.
- Geographic fit: choose a region that gives the collaboration service a practical route without unnecessary distance.
- Fallback readiness: keep a second group member available before an important client call begins.
- Policy clarity: know whether company rules permit the use of a proxy for work traffic and follow your organization’s security requirements.
After selecting a group, open the client’s connection or log view and generate a small amount of ordinary traffic. This confirms that the profile is active and that the selected group is not merely displayed in the interface without being used. The connection list is also where you will later discover hostnames that were not covered by your first set of rules.
Build targeted rules for Zoom, Slack, and Google Meet
Domain rules should be specific enough to cover the services you use without claiming unrelated traffic. The exact hostnames can change by application version, region, feature, or authentication flow, so use your live Mihomo Connections view as the source of truth. Start with the provider’s primary domains and then observe what appears when you sign in, join a meeting, send a message, upload a file, or start screen sharing.
For Zoom, the visible application may contact more than one host family. Meeting signaling, account authentication, update checks, cloud recording, and media relay functions can be separated. A rule that only covers the main website may not affect the desktop meeting process. Test the complete workflow: launch Zoom, sign in, join a meeting, enable camera and microphone, share a window, and leave the meeting. Watch for connections that unexpectedly use DIRECT while the main Zoom hostname uses your intended group.
Slack also uses multiple surfaces. Workspace access, authentication, message synchronization, file previews, notifications, and calls may not all appear under one simple hostname. If messages load but file previews remain blank, or notifications arrive late while the browser version works, inspect the relevant connection rows instead of adding a broad catch-all immediately. Route only the domains demonstrated by your client’s logs, and review the result after Slack updates.
Google Meet may involve Google account authentication, meeting pages, static assets, signaling, and media endpoints. A successful Google search is not proof that Meet is correctly routed. Join a test meeting, turn the camera on, share a tab, and observe whether the meeting remains stable when another participant speaks. If the page loads but joining stalls, compare the connection list before and after you switch to Global mode. This controlled comparison helps distinguish a missing rule from a general node or DNS problem.
A conceptual rule order might look like this:
- Private network and local corporate domains use DIRECT when your organization requires local access.
- Explicit Zoom, Slack, and Google Meet service domains use the collaboration proxy group.
- Other approved work services follow their documented corporate route rather than an improvised rule.
- Local country or intranet rules remain above a broad regional rule when that behavior is intentional.
- A final fallback rule handles everything else according to your privacy, performance, and organizational policy.
Rule order matters because Mihomo evaluates rules from top to bottom. A broad rule placed above a specific service rule can capture traffic before the intended group is reached. Conversely, a local rule placed too low may never take effect. After editing a profile or override, reload the configuration and confirm that the active profile is the one you changed. A common mistake is editing a downloaded file while the client continues to use a remotely managed profile.
Use the narrowest practical domain matching method. A suffix rule can cover changing subdomains, but it may also include services you did not intend to route. A keyword rule is usually even broader and should be used carefully. If your profile uses rule providers, check the provider’s update time and content. A provider that has not refreshed for months may explain why a newly introduced collaboration endpoint falls through to DIRECT.
Tune DNS, TUN, and system proxy behavior
Many apparent routing failures are actually name-resolution or application-integration failures. A desktop browser commonly respects the system proxy, while a meeting application may use its own network stack. Some applications also cache DNS answers, maintain persistent connections, or use UDP paths that are not affected in the same way as ordinary browser HTTPS traffic. Therefore, changing a rule without checking how the application enters the network can produce no visible improvement.
First decide whether your daily workflow needs ordinary system-proxy mode or TUN mode. System-proxy mode is less invasive and is often sufficient for browsers and applications that honor operating-system settings. TUN mode can capture traffic from applications that ignore those settings, but it may require elevated permissions, a virtual interface, or an operating-system network extension. It can also interact with endpoint security software, enterprise VPNs, virtualization tools, and local development environments.
Enable TUN only when you have a reason to capture traffic that system proxy mode misses. Test one change at a time. If you enable TUN, leave the rule mode unchanged, reconnect the client, and repeat the Zoom or Slack workflow. If behavior changes, compare the Connections view to identify which application traffic was previously absent. Avoid enabling every experimental DNS and sniffing option at the same time; otherwise you will not know which setting solved or created the problem.
DNS behavior deserves special attention. A DNS answer obtained outside the intended path can send an application toward an unreachable address or expose a split-routing mismatch. On the other hand, aggressive fake-IP or redirection behavior may confuse software that expects local address semantics, device discovery, or enterprise authentication. If local portals stop opening after you change DNS mode, temporarily restore the previous DNS behavior and inspect whether those domains need a DIRECT or fake-IP exception according to your environment.
For a work laptop, protect local resources deliberately. Company printers, file shares, internal Git servers, device enrollment pages, and single sign-on portals may depend on local DNS or private IP ranges. Do not assume that routing all work-related words through one proxy group is safe. Ask which services are externally hosted and which are reachable only through a corporate network or approved VPN. Clash can express a policy, but it cannot replace the company’s access controls.
When testing, clear only the caches that are relevant to the symptom. Restarting the application is often enough to discard a stale connection pool. Restarting the whole computer can hide the sequence that caused the issue. If you use a corporate VPN, test Clash either before or after it according to the supported architecture; stacking two tunnels without documentation can cause route conflicts, MTU problems, or authentication loops.
Measure meeting quality and troubleshoot with evidence
Do not evaluate a remote-work setup only by opening a web page. A meeting is sensitive to jitter, packet loss, reconnection behavior, and upstream performance. During a test call, note the time, selected group, node name, rule mode, and whether TUN is active. Then perform the same test with a second node or with the proxy disabled where permitted. This simple record makes it easier to identify a route problem instead of blaming the application without evidence.
If the meeting connects but audio breaks up, check the client’s connection list for repeated reconnects, changing destinations, or a route that switches between the proxy group and DIRECT. A stable-looking browser session does not prove that media traffic is stable. If screen sharing fails while voice works, look for additional upload or signaling connections created only when sharing begins. If Slack messages work but calls fail, treat the call feature as a separate traffic path and inspect it during the failure.
- Everything fails in Rule mode but works in Global mode: suspect rule order, missing domains, DNS behavior, or an application that bypasses the system proxy.
- Only one node fails: compare latency, packet loss, TLS connection behavior, and the node’s support for the traffic type used by the application.
- Desktop client works but browser does not: check the system proxy port, browser-specific proxy settings, extensions, and cached secure DNS behavior.
- Browser works but desktop application fails: test TUN or the application’s own proxy settings, then inspect whether its process appears in Connections.
- Local websites stop working: review private-network rules, local DNS, corporate VPN order, and broad proxy rules that may be catching intranet traffic.
- Problems begin after sleep or Wi-Fi changes: reconnect the profile and check whether the virtual interface, system proxy, or network permission was disabled.
Use logs as a decision tool, not as a wall of technical text. Filter by the application name when the client supports process filtering, then inspect the requested hostname, rule match, selected proxy, and connection result. A failed DNS lookup points to a different layer than a successful connection followed by a timeout. A direct connection that should have used the proxy indicates policy or matching trouble, while a failed connection through the correct group points toward the node, upstream service, or transport path.
Once the setup works, save a known-good copy of the profile or export only the relevant overrides according to your client’s supported workflow. Keep notes about the selected group and the date of the last successful test. Update profiles during a low-risk period rather than minutes before a customer presentation. After every update, repeat a short meeting test, send a Slack message, open a file preview, and join a Google Meet room. This small regression check catches broken group names and changed provider rules before they become an urgent incident.
Compared with all-in-one VPN applications that often force every website through one tunnel, or ad hoc proxy tools that expose few logs and offer limited rule control, Clash gives remote workers a more observable split-routing workflow: Zoom, Slack, and Google Meet can use a deliberate group, local services can remain DIRECT, and Connections can show which rule actually handled a request. If you want that balance of targeted routing, cross-platform control, and practical troubleshooting, the next step is to choose the client for your device and test it with your own work services.