Start with a Routing Plan
A dependable remote-work setup is not simply a matter of turning on Clash and sending every connection through one proxy. Video meetings, chat, file uploads, company portals, and ordinary browsing have different network needs. A remote node can help when a service is unreachable or your local international route is poor, but it can also add distance, jitter, and another point of failure. The right setup is therefore selective: decide which traffic should use a proxy, which should connect directly, and how you will verify that each decision improves the workday.
This guide focuses on Zoom, Slack, and Google Meet, using Clash clients powered by Mihomo, such as Clash Verge Rev. The exact interface differs between clients, but the underlying idea is the same: Clash evaluates rules in order and sends each connection to a policy such as DIRECT or a proxy group. A policy group lets you choose a node, rather than hard-coding one server into every rule.
Before changing anything, note your current working configuration and make a backup of the profile. If your profile is managed by a subscription, avoid editing the source file in a way that will be overwritten at the next update. Use the client’s supported override, merge, or script feature where available, or keep a separate local profile. Make one change at a time so that you can identify the cause if calls or company access get worse.
Practical Goal
Route only the services that need a proxy, keep local networks and internal company resources reachable directly, and choose the path that produces the most stable call—not merely the lowest ping number.
Choose the Right Clash Mode
For day-to-day work, Rule mode is usually the easiest mode to maintain. It applies your domain and IP rules while leaving unrelated traffic to the rest of your profile. Global mode sends nearly everything through the selected proxy and can make printers, local file shares, banking sites, or corporate VPN tools behave unexpectedly. Direct mode is useful as a temporary diagnostic, but it does not test your proxy path.
Also check whether system proxy mode or TUN mode is active. System proxy mode generally captures applications that respect the operating system’s proxy settings; some programs, background services, and UDP flows may not follow those settings. TUN mode can capture more system traffic, but it may require administrator permission and can interact with endpoint security, an existing VPN, or a company network agent. Do not enable multiple capture mechanisms just to make a rule appear to work. Confirm which mode your client supports and test one configuration at a time.
Respect Company Network Policies
A personal proxy configuration should not bypass your employer’s required VPN, monitoring, access controls, or data-handling rules. If your company specifies a network path for meetings or internal services, follow that guidance or ask IT before changing routing.
1Build Rules for Zoom, Slack, and Meet
In a rule-based profile, the order of rules matters: Clash uses the first matching rule. Put deliberate work-service rules above broad rules that could catch the same traffic, such as a general regional rule, a large proxy rule set, or the final catch-all. The following is a starting point, not a complete service-domain inventory. Providers can change endpoints, and a meeting may use domains or IP addresses not listed here. Review your client’s connection log when a specific request does not follow the route you expect.
The example uses a policy group named WORK. Replace it with a group that already exists in your profile, such as your own work selector or general proxy group. If your profile has no group with that name, the configuration may fail to load. Do not assume that every provider’s subscription uses the same group names.
These rules send matching hostnames to WORK; they do not guarantee that every media packet for a call will match a domain rule. Real-time audio and video can use UDP, changing endpoints, or infrastructure shared with other Google services. Some desktop clients may also make connections that are not visible to a browser-based domain rule in the way you expect. Treat the list as a practical first pass, then use Clash’s connection view to see whether the application is producing matched connections and which policy handled them.
Decide When to Use DIRECT or a Proxy
Do not automatically send every meeting service through a distant node. If Zoom, Slack, or Meet is already reachable and stable over your local connection, set its work policy to DIRECT or select a direct-capable policy as appropriate. A nearby proxy may be better when the local route is congested or the service cannot connect directly. A node in another region can make the route longer, and a proxy that handles ordinary web requests well may still struggle with sustained real-time media.
A good approach is to keep a selectable WORK group and compare the available paths. Test direct access first where permitted. If direct access is unreliable, select a nearby, stable node and repeat the same meeting test. For company services that require a corporate VPN or private route, use the route specified by your organization instead of assuming that DIRECT or a consumer proxy is appropriate.
Keep local networks and private company resources out of a general proxy route unless your administrator has instructed otherwise. If your profile does not already handle local destinations, common private IPv4 ranges can be routed directly with rules like these. Add them before a broad proxy rule and preserve any existing LAN, VPN, or intranet-specific rules that your setup needs.
Private-network rules are not a substitute for your organization’s network design. A company may use overlapping private ranges, route internal traffic through a VPN, or require a particular DNS resolver. If an intranet address stops working after a change, inspect the matched rule and consult IT rather than adding broad exceptions at random. IPv6, DNS handling, and system-level routing can also affect the result, so verify them separately if your environment uses them.
Rule-Order Check
After editing, inspect the complete rules list—not just the lines you added. Confirm that your work rules appear above rules that would otherwise match them, that each policy name exists, and that the profile still ends with its intended catch-all rule.
2Choose a Node for Real-Time Work
For calls, consistency matters more than a single attractive speed-test result. Latency is the time a packet takes to travel to a destination and back. Jitter is variation in that delay. Packet loss means that some packets do not arrive at all. A route with a slightly higher but steady latency can sound better than one that alternates between fast and slow or drops packets during busy periods.
When comparing nodes, start with a server geographically close to both your location and the meeting service’s likely route, while respecting any regional requirements that apply to your account or workplace. A farther node may still perform better if its transit route is cleaner, so use actual calls rather than geography alone. Avoid switching nodes in the middle of a meeting unless you have to: changing the route can interrupt sessions or cause an application to reconnect.
- Prefer stable latency: Run the same node test several times, including at the hours when your team usually meets. A one-off result does not reflect rush-hour conditions.
- Watch loss and jitter: If your client or meeting application exposes these measurements, track them alongside ping. Persistent loss or large variations can cause clipped speech, frozen video, and repeated reconnects.
- Check UDP support: Real-time media often benefits from UDP. If you proxy meeting traffic, confirm that your Mihomo core, selected node, and provider path support the required UDP traffic. A TCP-only path can behave differently from a direct call.
- Keep a backup: Identify one alternative node or direct route that is known to work. A backup is useful only if you have tested it before a high-stakes meeting.
- Consider capacity: A node shared by many users may perform well at quiet times and degrade when demand rises. Re-test during normal work hours instead of relying only on a subscription label or advertised bandwidth.
Avoid Over-Optimizing
Adding a long list of guessed IP ranges is rarely the best first response to a call problem. Service providers change infrastructure, and IP addresses may be shared across unrelated products. A broad IP rule can route more traffic than intended or accidentally override an existing company rule. Start with a small set of domain rules, observe the connection log during a real test, and add a narrow exception only when you have evidence that the current rules miss a necessary destination.
Likewise, do not judge a work node solely by a generic download benchmark. Large file transfers and interactive audio exercise different parts of the route. A speed test can report high throughput while a call still suffers from intermittent loss. If possible, compare the meeting application’s own network statistics and ask a colleague on the same call whether they hear interruptions. This gives you more useful evidence than repeatedly refreshing a speed-test page.
A Useful Comparison
Keep the meeting, device, room, and time window as similar as possible when comparing DIRECT with a proxy node. Changing several variables at once makes it hard to know whether Clash improved the route.
3Test the Setup and Troubleshoot Calls
After saving your profile, reload it and make sure Clash reports no YAML or policy-group errors. Then open the connection or log view in your client. Start one target application at a time, make it load or join a test call, and locate its connections in the log. Check the matched domain, rule, and policy. If a connection is using an unexpected policy, first verify rule order and the actual hostname; do not assume that a product’s visible brand name is the only hostname it contacts.
- Confirm the baseline: With your normal work configuration, note whether the call connects, whether audio is clear, and whether messages and files load. Record the time and any error messages.
- Test one route: Select DIRECT or one work node, then run a short test meeting. Avoid changing DNS, TUN mode, and several rules at the same time.
- Inspect matched connections: Confirm the relevant requests appear in Clash and are handled by the expected policy. A browser’s successful page load alone does not prove that the meeting media stream followed the same route.
- Check the application: Use the built-in network diagnostics where available. Look for reconnects, packet loss, audio warnings, or repeated device changes in addition to the displayed connection status.
- Repeat at a representative time: A five-minute test during a quiet period may not reveal congestion that appears during the team’s regular meeting hours.
Common Symptoms and What to Check
- The meeting cannot connect: Confirm that the active profile loaded, the policy group exists, and the service’s matching connection is visible. Test the direct route if permitted, then compare with a known-good node. Also check whether a corporate VPN, firewall, or endpoint security tool is controlling access.
- Audio is robotic or cuts out: Compare jitter and packet loss, not just ping. Test a closer or less-loaded node, check UDP support, and verify that Wi-Fi signal quality is not the actual cause. A wired connection can help distinguish a local wireless problem from a proxy-routing problem.
- Slack messages work but files do not: File delivery may use separate hostnames or content-delivery endpoints. Inspect the connection log while opening a file, then add a narrowly scoped domain rule only if needed. Avoid routing every cloud-storage service through the same rule based on one failed upload.
- Meet works in a browser but not in the desktop app: The applications may use different proxy settings, DNS behavior, or network transports. Confirm whether the client’s capture mode covers the desktop process and its UDP traffic. Do not assume browser proxy settings automatically apply to every application.
- Internal tools or printers stop working: Review local and company network rules, the operating system’s routing table, and any required corporate VPN. Restore the previous profile if necessary, then add only the specific rule confirmed by your organization’s network guidance.
When a change makes the setup worse, roll back the most recent edit instead of stacking additional exceptions on top of it. Keep a short record of the previous policy, node, and rules, especially if you manage multiple profiles. Once calls are stable, leave the configuration alone unless there is a measurable problem. A simple setup that you understand is easier to recover than a large collection of untested service-specific rules.
Finally, recheck the configuration after a core or subscription update. Provider groups, domain lists, and client options can change, and an update may alter how traffic is captured. A quick test of one Zoom, Slack, and Meet connection—and a glance at the matching rules—can confirm that the intended routes remain in place before an important workday.