Clash Rule mode, Global mode, and Direct mode: What’s the difference? A beginner’s guide

Separate call quality from proxy routing

A reliable remote-work setup is not simply “send Zoom and Slack through a proxy.” A call depends on several links working together: the app must reach its service, DNS must return usable addresses, the selected route must carry the required traffic, and the local network must be able to sustain the connection. A proxy can help when a service is unreachable or unstable on the direct route, but it can also add latency, introduce another failure point, or make real-time media worse.

Clash has two distinct jobs in this picture. A traffic-capture method, such as the system proxy or TUN mode, determines which connections enter the core. In Rule mode, the core then evaluates matching rules in order and sends each captured connection to a policy such as DIRECT or a proxy group. A rule for Zoom cannot affect traffic that never reaches the core, and changing the proxy mode does not by itself make every application use Clash.

• System proxy: Convenient for browsers and applications that honor the operating system’s proxy settings. Support for UDP and application-specific traffic varies, so it may not capture all voice or video media.
• TUN: Creates a virtual network interface and can capture more traffic, including traffic from apps that do not use the system proxy. It needs the required permissions and a compatible core and client configuration.
• Rules: Decide the route only after traffic enters the core. Domain rules can cover a service’s hostnames, while process-name rules can target an application when the core, operating system and capture mode support process matching.

Clash for Windows is no longer maintained. It is a graphical client, not a guarantee of a particular core feature set. The original Clash, Clash Premium and Clash Meta (now mihomo) do not support exactly the same fields. If you use process-name rules or TUN options, check the running core and its documentation; do not assume a configuration written for mihomo will work in an older core. Keep a copy of the working profile before editing it, especially when the profile is managed by a subscription.

Choose a capture method and a policy for work apps

Start with the least complicated method that captures the traffic you need. If Zoom, Slack and your browser already work through the operating system’s system proxy, test that first. If a call’s audio or video does not follow the expected route, or an app ignores system proxy settings, consider TUN mode only if your client and core support it. TUN can capture more traffic, but it also makes DNS, local-network access, permissions and route conflicts more important to check.

Use a dedicated work policy group when you want to control these services independently of general browsing. The group should contain known, usable nodes and should be easy to inspect in the client’s Proxies page. A manual selection is useful for a meeting that must remain on a known route; an automatic group can be convenient for routine use, but its health check is only a probe and does not prove that Zoom media or a Slack call will work.

For a work profile, a reasonable starting point is Rule mode with a dedicated work group, while leaving unrelated destinations on their existing routes. Avoid making every request use a proxy just because one meeting service needs a different path. Direct access can be preferable for company resources, local printers, file servers and internal meeting systems, subject to your organization’s network policy.

Google Meet needs an extra distinction: if Meet runs in Chrome, Edge or another browser, a process-name rule for that browser applies to the browser’s connections generally, not only to the Meet tab. A domain rule is more selective when destination matching is reliable. Conversely, if the browser uses shared connections, encrypted DNS, a VPN, or another network layer, the observed route may not match a simple expectation. Test with the actual browser and meeting account you use.

Configure and test work routing in a controlled order

Make changes incrementally so you can tell whether the problem is capture, rule matching, the policy group, or the remote route. The following example is illustrative, not a complete subscription. It assumes that a policy group named Work-Proxy already exists and that the running core supports the rule types shown. Check your core’s syntax and process-matching support before using a process rule.

mode: rule
rules:
  # Keep company and local resources on their approved route first.
  - DOMAIN-SUFFIX,corp.example,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

  # Optional process rules: supported only by compatible cores and capture modes.
  - PROCESS-NAME,Zoom.exe,Work-Proxy
  - PROCESS-NAME,Slack.exe,Work-Proxy

  # Domain rules are examples to review, not a complete service endpoint list.
  - DOMAIN-SUFFIX,zoom.us,Work-Proxy
  - DOMAIN-SUFFIX,slack.com,Work-Proxy

  # A browser process rule would route all matching browser traffic, not just Meet.
  # Add it only if that wider effect is intended.
  # - PROCESS-NAME,chrome.exe,Work-Proxy

  - MATCH,DIRECT

The example uses reserved or illustrative destinations where appropriate; replace corp.example and Work-Proxy with values that actually exist in your environment. A rule referring to a policy group that is not defined can prevent a configuration from loading or cause a policy-selection error. Do not paste a list of guessed service domains and assume it covers all call media. Service endpoints can vary by region, account, client version and product configuration. Use connection logs and the service provider’s current network requirements to identify destinations when needed.

1. Save a backup. Export or copy the active configuration, note the selected profile and record the current system-proxy or TUN state. This gives you a known rollback point if a subscription update or edit changes the effective configuration.
2. Confirm the core and policy. Check the client’s General or Logs page for the running core. On the Proxies page, confirm that Work-Proxy exists, that its selected node is connected, and that the group is not currently set to DIRECT by mistake.
3. Test capture before adding app rules. Enable the chosen capture method, open a new request in the target app, and look for it in the connection log. If nothing appears, investigate system-proxy support, TUN permissions, application proxy settings or another VPN before editing domain rules.
4. Add one rule at a time. Start with one application or a small set of confirmed domains. Reload the configuration, verify that the app’s new connections match the intended rule, and check the selected policy in the log or connection detail view.
5. Run a real call test. Join a short Zoom or Meet test meeting and check microphone, speaker and camera behavior. In Slack, test a huddle as well as ordinary messaging. A successful text message confirms neither the UDP media path nor the quality of a live call.
6. Compare routes. If permitted, compare the same test on the intended work route and on the direct route. Change only one variable at a time: selected node, capture method, policy rule or client network. Record whether the call connects, whether media stays stable and whether other work services remain reachable.

For mihomo configurations that use UDP proxying, check the relevant core and proxy settings rather than assuming that a rule automatically enables UDP. A node or protocol may not support UDP, and a client may not capture it in system-proxy mode. If your configuration has a top-level UDP option or node-specific UDP setting, confirm its meaning for that core and provider. Do not add fields copied from another client until you have verified that the active core accepts them.

Diagnose call failures and keep a rollback path

Separate the symptom into stages. If the app cannot sign in, first check DNS resolution, account access and basic connectivity. If chat works but a meeting cannot connect, check whether media traffic is captured and whether UDP is supported along the selected path. If the meeting connects but audio or video freezes, compare latency, loss and stability on the current route; a low latency probe alone is not enough to establish call quality.

• No matching connection in Clash: The app may ignore the system proxy, use a separate network interface, or be outside TUN capture. Check the client’s capture status and the operating system’s proxy settings. Do not keep adding domain rules for traffic the core never sees.
• The wrong policy appears in the log: Inspect the matched rule and its position. Check for an earlier broad rule, a domain rule that is too general, or a policy group that selects a different child group than expected.
• Chat works, but voice or video fails: Check UDP capture and proxy support, then compare with the service’s documented network requirements. A TCP-only success does not prove that real-time media can pass through the same route.
• Only the browser is affected: A process rule for Chrome or Edge covers the browser process, not just Google Meet. Prefer verified domain matching where appropriate, or accept the broader browser route deliberately and test other browser-based work services.
• Company or local resources stop working: Review private IP and internal-domain rules, TUN route settings and the organization’s approved access method. Do not bypass company controls; ask the administrator whether a proxy or VPN is required.
• Calls become less stable after a node switch: Test one known node and keep it selected for the meeting. Frequent automatic changes can interrupt long-lived connections even if the group’s health check continues to succeed.

When checking logs, use a fresh connection where possible. Existing connections may keep their original route until they close, so changing a rule may not immediately move an active call. Avoid exposing subscription URLs, authentication tokens, meeting links or private company domains when sharing diagnostic screenshots. If a configuration stops loading, restore the saved version before trying additional edits.

A dependable setup is the narrowest one that captures the required app traffic, sends it to a tested policy, and leaves unrelated traffic on an appropriate route. Recheck after a client, core, subscription or operating-system update, because process names, rule support and service endpoints can change. Keep a record of the chosen capture method, group, node and working rules so you can return to a known-good state before an important meeting.