Clash Rule Mode, Global Mode, and Direct Mode: Key Differences and Everyday Recommendations

Choose Rule mode first, then check whether traffic reaches Clash

For everyday use, choose Rule mode: requests that need a proxy go through a proxy group, while local devices and sites suited to a direct connection stay direct. Global mode is best for briefly troubleshooting routing issues; Direct mode helps you compare against your regular network connection. These modes change how the core handles connections it has already received—they are not speed settings.

First, distinguish between two layers: System Proxy, TUN, or the Android VPN determines how traffic enters the core; Rule, Global, and Direct determine what happens to it afterward. Switching to Global alone won't route a program through the proxy if System Proxy isn't enabled and the program isn't configured to use one.

How traffic flows in each proxy mode

Rule mode: connections use the policy selected by the matching rule

Rules are usually evaluated from top to bottom in the order they appear in the config. The first match determines the policy. A policy can be DIRECT, REJECT, a proxy node, or a proxy group. Rule mode does not mean that “all overseas sites are automatically proxied.” The result depends on the subscription's rules, rule sets, and fallback policy.

For example, a domain rule might route a service to PROXY, but if that group is currently set to DIRECT, the connection still goes direct. When troubleshooting, check both the matching rule and the group's current selection—not just the mode button.

Global mode: you still need to choose an egress in GLOBAL

When you switch to Global, the regular rule list no longer routes these connections. Instead, the core uses the current selection in GLOBAL. Clients may label this option “Global” or “GLOBAL.” If it's set to Direct, switching to Global won't give you a proxy route. If it's set to another proxy group, check which node that group ultimately selects.

Global mode won't fix an expired subscription, failed node authentication, or an unreachable server. Rules that previously allowed direct LAN access no longer apply in Rule mode, so access to a printer, NAS, or router admin page may change. Traffic excluded from TUN routing won't reach this stage in the first place.

Direct mode: no proxy node, but the core is still running

In Direct mode, connections that reach the core access their destinations directly over the local network. The client may still listen on ports, accept System Proxy requests, run TUN, and provide DNS services. So switching to Direct is not the same test as quitting the client and restoring system network settings. If you suspect a TUN routing or DNS issue, Direct mode alone won't rule it out.

How mode, rules, and proxy groups work together in YAML

The top-level config field is mode, with common values rule, global, and direct. The snippet below shows rules, not a complete subscription. Before using it, confirm your existing config has a node or proxy group named PROXY. If the actual group is named “Proxy Selection,” replace both instances of PROXY with that exact name.

# Merge this into your existing config; do not use this snippet to replace your full subscription.
mode: rule

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,PROXY

• DOMAIN-SUFFIX,example.com,PROXY: Matches the example domain and its subdomains. This illustrates domain-based routing; it is not a recommended rule for a real service.
• IP-CIDR: Covers three common private IPv4 ranges here. This is not a complete list of local address exceptions; account for loopback, link-local, IPv6, and other addresses based on your network.
• no-resolve: Does not trigger a DNS lookup to match this IP rule. It does not disable DNS for the entire client.
• MATCH,PROXY: Catches connections that didn't match earlier rules. If you put MATCH first, no later rules will get a chance to match.

To switch to Global, you can change the top-level field to the line below. The actual egress is still determined by the runtime selection in GLOBAL:

mode: global

To send connections received by the core directly to their destinations, use:

mode: direct

Clash and Clash Meta (now generally called mihomo) do not support exactly the same extended fields, particularly for DNS, TUN, and process matching. The three modes discussed here are core concepts. Before copying other advanced fields, check the core listed in the client's About or core information section—don't rely on the app name alone.

Choosing a mode for everyday use: why Rule mode helps

Rule mode lets different requests use the right egress; it doesn't guarantee that every site will load faster. The proxy node's bandwidth and route quality, the destination site, and your local network all affect performance. Well-designed rules keep LAN traffic, downloads that don't need a proxy, and services that require a specific egress from being forced through the same route.

• Websites and work services: Route by domain. Services accessible directly from your location can usually stay direct, while services that need a proxy use the designated proxy group.
• NAS devices, printers, and routers: Set your actual local subnets to use a direct connection, and check TUN route exclusions so local traffic isn't sent through a remote egress.
• Account sign-ins: Keep related domains for the same service on a consistent egress when possible. Switching nodes repeatedly during sign-in may trigger extra verification.
• Downloads and data-heavy tasks: Check the egress in the Connections panel first. In Global mode, these tasks may also use up your proxy plan's traffic allowance.

Don't keep Global enabled just because it seems “more thorough.” It only removes rule-based routing as a variable; it doesn't improve node quality or expand the traffic captured by System Proxy. If one site fails in Rule mode, it's usually better to fix that site's matching rule or proxy group than to change the egress for every connection.

A site works in Global but not Rule mode? Try these five checks

This is a good situation for a short test in Global mode. Keep the node, URL, and network the same, and change only the mode. Otherwise, you won't know whether the issue is the rule or the route.

1. Note your current settings. Record the active mode, the group matched by the rule, and the node selected in that group. Open the client's “Connections” page and get ready to watch new connections.
2. Reproduce the issue in Rule mode. Close tabs for the affected site and reopen it. Check the destination domain, matched rule, and final route. Look for an unexpected match to DIRECT, REJECT, or the wrong fallback group.
3. Switch to Global and select the same node. Find GLOBAL on the “Proxies” page and choose the egress you want to compare. Menus vary by client, so follow the options shown in your UI. Don't confuse the System Proxy toggle with the mode selector.
4. Start a fresh connection, then compare. Switching modes usually doesn't move existing TCP connections to another egress. Close the target connection in the Connections panel, or fully quit and reopen the app. Don't accidentally close a download that's still in progress.
5. Restore Rule mode and fix the cause. If Global works but Rule doesn't, check the rule order, whether remote rule sets loaded successfully, whether group names match, and whether any relevant subdomains are missing. Once you've made changes, switch back to Rule mode and test again.

Verify that requests reach the core using an explicit proxy port

If your configuration uses mixed-port: 7890, run the command below in a desktop terminal to send a single HTTPS request through the local HTTP proxy. In Windows PowerShell, use curl.exe to avoid argument differences caused by aliases for commands with the same name in older environments.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

Windows command:

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

If the actual listening port is 7891, update the command to match. This test only proves that this request used the specified port; it doesn't prove that all apps are being captured, and a response status code alone can't confirm that the request used a remote node. Check the policy chain in the Connections panel to identify the final egress. If the connection is refused, first check whether the core is running and the port matches—don't rush to change the rules.

Still having issues after switching modes? Check DNS, TUN, and existing connections

Global mode doesn't fix DNS automatically

Proxy mode and DNS configuration are separate settings. With mihomo, DNS resolution may also be affected by fields such as dns.enhanced-mode, nameserver, and nameserver-policy. Switching to Global doesn't prove that all DNS requests go through the proxy, nor that the core captures an app's own encrypted DNS.

If a domain won't load but your connection otherwise seems fine, check the logs for DNS timeouts, then see whether your DNS settings have been overridden. Don't change the mode, DNS server, and node all at once. Change one variable at a time so you can identify the cause.

TUN is an entry point, not a fourth proxy mode

With TUN enabled, you can still choose Rule, Global, or Direct. On desktop, check that the virtual network adapter and routes are set up. On Android, confirm VPN permission is active. Apps on the exclusion list may bypass the core even when Global mode is selected. Conversely, TUN can continue receiving and forwarding traffic in Direct mode.

A failed direct connection doesn't necessarily mean there's a proxy rule issue

If Rule, Global, and Direct all fail, first check your local network, the destination service, listening ports, and core logs. To test without the client involved, turn off System Proxy and TUN, then quit the client normally and make sure no proxy settings remain on the system. Switching to Direct alone won't rule out issues in the core's DNS or routing layers.