Build a Reliable Remote-Work Setup
Video meetings and team messaging place different demands on a network. A Zoom or Google Meet call needs steady, low-latency traffic; a brief delay or packet loss can make voices sound choppy even when a speed test looks fast. Slack is less sensitive to momentary latency, but its live updates, file uploads, and calls can be disrupted by an unstable route. The goal is not to send every work application through one distant server. It is to make traffic routing predictable, then choose the least problematic path for each service.
Clash is a rule-based traffic controller, not a proxy service. The client uses the rules and proxy groups in your configuration to decide whether a connection goes DIRECT or through a selected node. In Clash Verge Rev and other clients powered by Mihomo, you can usually inspect the active profile, switch a group from the dashboard, and review matched rules in the connection or log view. Interface labels vary by client version, but the underlying routing logic is the same.
Start by deciding what you actually need. If Zoom, Meet, or Slack already works reliably over your local connection, DIRECT may provide the lowest delay. If a service is unavailable, heavily throttled, or unreliable on the direct route, proxy only the relevant traffic through a nearby, stable group. Company VPNs, endpoint security, and workplace policies may also govern how work traffic must travel; do not bypass those controls or place confidential traffic on an unapproved service.
Practical Goal
Keep local and private resources direct, route only the services that need a proxy, and test meeting quality under real working conditions.
1Choose How Work Apps Should Route
Before editing YAML, check the current behavior rather than assuming every work service should be proxied. A video call may use several domains and media endpoints, and some clients use UDP for real-time audio and video. A rule that catches the sign-in page does not necessarily catch every media connection. Conversely, a broad rule for a company or cloud provider can capture unrelated services and send them along an unexpected route.
| Traffic or situation | Starting route | What to verify |
|---|---|---|
| Local intranet, printer, or private IP | DIRECT | Internal hostnames still resolve and local devices remain reachable. |
| Zoom or Google Meet works normally on the local connection | DIRECT | Audio, video, screen sharing, and reconnects work during a real call. |
| A work service needs a proxy on this network | A selected work proxy group | Sign-in, media, notifications, and file transfers all use the intended route. |
| Unknown or unmatched traffic | Your existing final policy | The fallback does not unintentionally expose or disrupt work traffic. |
For a straightforward setup, use the provider’s existing proxy group where possible. If your profile has a group such as Proxy, Global, or 手动选择, reference the exact name in the rules. Group names are case-sensitive in YAML, and a rule that points to a group that does not exist can make the configuration invalid. The example below illustrates a policy group, but it is not a complete profile: retain your provider’s proxy definitions and make sure the referenced group is present.
Replace Nearby-1 and Nearby-2 with actual proxy names from your configuration, and replace the final placeholder with the policy already used at the bottom of your rules. If the existing profile has a provider-managed group that you prefer, you can point the domain rules directly to that group instead of creating Work. Do not paste the sample as a full profile or delete the profile’s existing rules. In Clash, rule order matters: a matching rule near the top is applied before later rules, so place specific work and local-network rules above broad domain, region, or catch-all rules.
Keep Google Rules Narrow
Avoid routing every Google domain through a work proxy just to reach Meet. Broad Google rules can affect unrelated browsing, mail, and other apps. Add a domain only when logs or a controlled test show it is needed, and keep a record of each custom rule.
2Configure the Profile and Test the Route
Make changes in a copy of your profile or in a supported override, rather than modifying a subscription that will be overwritten on its next update. In Clash Verge Rev, open the profile area, identify the active configuration, and use the available edit or merge feature. Other clients may call this section Profiles, Config, or Rules. If the profile is managed by a provider, check whether it supports rule providers or script-based overrides before changing it. Keep a backup so you can revert quickly if a YAML indentation error prevents the core from starting.
- Record the current mode, selected proxy group, and whether TUN mode is enabled. Export or copy the active profile before editing.
- Add or adjust only the required work rules. Preserve the existing proxy definitions, DNS settings, and final rule unless you have a specific reason to change them.
- Use spaces consistently in YAML. Validate or reload the configuration in the client and resolve any reported parse errors before starting a meeting.
- Open the connection list or logs, start the target application, and look for the domains being matched. Confirm that the displayed policy is the intended group or DIRECT.
- Run a short test call. Check microphone and speaker behavior, camera stability, screen sharing, and reconnects—not just whether the meeting website loads.
A browser test alone is not enough if you use the desktop client. The browser and application may have different processes, DNS behavior, or connection patterns. Mihomo supports process-name rules in suitable configurations, but process matching depends on the operating system, core, and mode, and should not be assumed to work in every client. Start with observable domain rules and inspect live connections. If you add process rules, confirm in the client’s documentation that the active core and operating system support them, then test them explicitly.
UDP support deserves attention for conferencing. If a call is proxied, the selected node and core must handle the relevant traffic correctly. A configuration that sends TCP web pages through a proxy does not prove that real-time media is taking the same path or that UDP is available. Check the client’s connection view during a call and review the provider’s protocol limitations. If media becomes unstable only when proxied, compare with DIRECT on the same network; this helps separate a proxy-path problem from a local Wi-Fi, device, or service issue.
Test one variable at a time. First compare DIRECT and the work group using the same device, network, and meeting. Then try a second nearby node if the first has high latency or packet loss. Avoid choosing a node solely by its displayed ping: a quick latency probe does not measure sustained upload capacity, congestion, or UDP performance. For a useful comparison, place a short call, share a screen, and upload a small non-sensitive test file. Never use confidential documents to test a service that your organization has not approved.
3Make Everyday Switching Predictable
Once the routing rules work, keep the daily routine simple. Leave the client in Rule mode unless you have a specific, temporary reason to use another mode. In the Work selector, choose a stable nearby node when the work domains need a proxy, or choose DIRECT when local routing performs better and workplace policy permits it. A group with a manual selector is often easier to troubleshoot than several hidden nested groups because you can see exactly which node is active.
Do not switch nodes in the middle of an important presentation unless the connection has already failed. Changing a route can interrupt a call, trigger a new login, or cause the meeting application to reconnect. If you need to switch, tell other participants if appropriate, pause screen sharing, change the group, and wait for the client to settle before rejoining or resuming. For a planned workday, test the preferred route before the first meeting and keep a known-good fallback available.
| Symptom | Useful first check | Low-risk next step |
|---|---|---|
| Meeting page loads, but audio or video is choppy | Check the live connection policy, node load, and whether UDP is supported. | Compare a short call on DIRECT and on one nearby node. |
| Sign-in works but screen sharing fails | Check the logs for additional domains or connections used by the desktop app. | Add only a confirmed missing rule, then retest sharing. |
| Slack shows reconnecting or delays notifications | Check whether its matched traffic is using the expected route. | Try a stable alternative node or compare with DIRECT. |
| Local devices or intranet stop responding | Verify private IP rules and the client’s system-proxy or TUN behavior. | Restore the backup if necessary, then retest local access before adding rules. |
When diagnosing a problem, use the Clash connection list and logs as evidence. Note the time, application, domain, selected policy, and whether the connection succeeded. If a domain is matched by an earlier broad rule, adding another rule lower down will not fix it; move the specific rule above the broader match. Be cautious with IP-CIDR rules for large service networks, because addresses can change and may be shared by unrelated services. Domain rules are usually easier to maintain, but they also need verification against actual traffic.
Keep company internal services distinct from public collaboration tools. Private address ranges such as 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 commonly cover local networks, but an organization may use additional ranges or internal DNS names. Follow the company’s network documentation rather than guessing. If you are required to use a corporate VPN, avoid stacking it with Clash TUN mode unless your IT team supports that arrangement; overlapping virtual adapters and DNS handlers can cause loops, dropped routes, or inaccessible internal resources.
Finally, document the working setup in a short note: which group is used, which rules are custom, how to restore the backup, and which route passed the call test. Recheck after a core, profile, operating-system, or network change, since any of these can alter traffic handling. A configuration that works at home may behave differently on office Wi-Fi or a mobile hotspot. Prefer the smallest set of rules that meets your needs, and remove experimental rules once they are no longer useful.
Need a compatible client for your device? Download Clash for Free – Get Started Now →