Clash Rule, Global, and Direct Modes Explained: A Beginner’s Guide

Mode Basics

The three modes decide the exit path

When Clash Verge Rev uses the mihomo core to handle connections, rule, global, and direct modes determine which exit path traffic already inside the core should use. They do not directly determine whether an application sends traffic to Clash, nor are they the same as the system proxy or the TUN switch. Understanding this distinction is key to choosing the right mode.

In rule mode, the core checks the rules in the configuration from top to bottom. Based on conditions such as domain, IP, port, process, or rule-set membership, it sends each connection to a specified proxy group, proxy node, DIRECT, or REJECT. In global mode, ordinary connections entering the core are generally sent to the global proxy group, where the user chooses a node or policy. Direct mode sends those connections through the DIRECT exit without using a proxy node.

Rule Mode

Rule mode: fine-grained routing by connection characteristics

Rule mode is usually the best choice for everyday use. It allows multiple exit paths at the same time: LAN addresses can connect directly, specific services can use dedicated proxy groups, advertising or tracking domains can be rejected, and unmatched connections can fall back to a default policy. Compared with sending everything through one node, rule-based routing makes it easier to balance access paths, latency, and local network resources.

When mihomo handles a new connection, it matches rules in the order defined by the configuration. Once a rule matches, mihomo applies its target policy and stops checking subsequent ordinary rules. More conditions do not necessarily make a rule set better, and rules cannot be arranged arbitrarily. Narrow, clearly targeted rules usually belong near the top, broader rules later, with MATCH as the final fallback.

rules:
  - DOMAIN-SUFFIX,example.cn,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

This example means that the specified .cn domains connect directly, the specified .com domains use the policy group named PROXY, common private network ranges connect directly, and all remaining connections go to PROXY. In an actual subscription, policy groups may be named “Proxy Selection,” “Auto Select,” or something else. Rule targets must match nodes, policy groups, or built-in actions already defined in the configuration.

Rule mode depends on three layers

1. Rule matching: Determines which policy group or built-in exit receives the connection. Domain, IP, rule-set, and process rules use different matching conditions.
2. Policy-group state: If a rule points to a manually selected group, the final exit depends on the currently selected node. If it points to an automatic latency-testing group, the group’s tests and tolerance settings decide the result.
3. Node availability: Even when the rule and policy selection are correct, requests can still fail if the node itself times out, its protocol parameters have changed, or the network path is unstable.

Therefore, “rule mode cannot access this site” does not mean rule mode itself has failed. A more useful check is to open the connection log, find the target domain, and see which rule matched, which policy group it entered, and which exit was ultimately used. If the destination was incorrectly sent to DIRECT, check the rule order or rule-set contents. If it reached the expected proxy group, inspect the node selected by that group.

DNS results can also affect rule matching

A domain connection can directly match DOMAIN, DOMAIN-SUFFIX, or a domain entry in a rule set. Some connections expose only a destination IP, so the core may need DNS mappings, sniffing results, or IP-based rules to determine where they should go. The decision path varies when Fake IP, real-IP resolution, or domain sniffing is enabled, but the basic principle remains the same: first determine whether the core actually identified a domain or an IP, then check the corresponding rule type.

Do not infer the matched route from the visible address in the browser alone. A page may request its main domain, image domains, API domains, and third-party content delivery domains at the same time; each may use direct access, a proxy, or rejection. When part of a page loads and another part fails, the connection list is usually more useful for diagnosis than repeatedly switching modes.

Global Mode

Global mode: one exit path for short-term testing

Global mode bypasses normal per-rule routing and sends ordinary connections entering the core to the global policy. After the user selects a node in the client’s global policy group, most intercepted traffic uses that node. Its advantage is a simple, observable path, making it useful for determining whether a problem comes from the rules or the node.

For example, if a site is unreachable in rule mode but opens normally after switching to global mode and selecting a confirmed working node, the local proxy entry point and node path are probably working. The next step is to inspect which rule matched the site in rule mode. If global mode fails as well, the issue is more likely related to node status, protocol settings, DNS, traffic interception, or the destination service’s connection requirements.

Global mode is generally not a good long-term default. LAN services, mainland China websites, software updates, and latency-sensitive applications may also be sent to a remote node, resulting in longer routes, slower speeds, or region and sign-in checks by the service. When accessing a router admin page, printer, network storage, or other local resource, check whether the client or core is configured to bypass private LAN addresses.

Global mode also cannot turn a poor-quality node into a usable one. If a manually selected node is used, all relevant connections are concentrated on that exit. Packet loss or latency fluctuations at the node can affect websites, video, and messaging at the same time. During testing, verify the current option in the global policy group rather than looking only at the “Global” label in the interface.

Direct Mode

Direct mode: traffic can still pass through the core, but not through a proxy node

Direct mode sends intercepted traffic directly to the destination over the local network. It is useful for temporarily stopping proxy routing, testing whether the carrier network can reach a destination directly, or checking whether a proxy node is causing the problem. Direct mode is not an internet kill switch and does not necessarily mean Clash has been fully exited.

When the system proxy remains enabled, a browser may continue sending requests to the local proxy port; mihomo simply chooses DIRECT after receiving them. When TUN remains enabled, system traffic may still pass through the virtual network interface before the core sends it directly to the destination. Thus, “passing through the core and then connecting directly” is not the same as an application bypassing Clash completely.

Questions direct mode can help answer

• Is a problem with a mainland China website caused by the proxy node or remote exit?
• Can the current local network reach the target domain or IP directly?
• Is the application actually being intercepted by the system proxy or TUN?
• Is the change in download speed related to the route through a remote node?

If a destination normally requires a proxy route, failure after switching to direct mode is expected. Direct mode also does not bypass account restrictions, regional policies, certificate issues, or the local firewall imposed by the destination service. During troubleshooting, record the connection logs and error types before and after the switch instead of treating “opens” or “doesn’t open” as the only conclusion.

To stop the client from participating in the network path completely, disable the system proxy and TUN according to the current configuration, and make sure the relevant applications do not have a local proxy port configured separately. Some applications cache proxy settings or keep existing connections alive. After switching, establish a new connection or restart the affected application rather than immediately concluding that the mode change had no effect.

Traffic Entry

Proxy modes and the system proxy and TUN mode are separate switches

A common beginner misconception is to treat “rule mode” as the interception scope and “TUN mode” as a routing rule. In fact, they operate at different layers: the system proxy and TUN bring traffic into the core, while rule, global, and direct modes decide the exit after it enters the core.

Browsers usually read the system proxy, so enabling only the system proxy covers common web access. Games, command-line tools, some app stores, and software using a custom network stack may not follow it. In those cases, configure a proxy in the application, or use TUN after understanding its routing, DNS, and permission requirements.

TUN expands the interception scope but does not automatically fix incorrect rules. With rule mode under TUN, connections are still routed according to the rules. With global mode, intercepted connections generally enter the global policy; with direct mode, they are generally sent directly by the core. UDP success also depends on the node protocol, the node server, the network environment, and UDP support at every layer of the policy chain.

Selection Guide

A beginner’s method: rules for daily use, global for diagnosis, direct for verification

If the subscription includes complete policy groups and rules, beginners can use rule mode as the everyday default. It lets different services use different exits while preserving LAN and common direct routes. After importing a subscription for the first time, select a working node on the proxy or policy page, then confirm rule mode, the system proxy status, and whether the browser produces connection records.

Choose by use case

• Everyday browsing, video, and software: Prefer rule mode and let the configuration handle regional and service-based routing.
• Check whether a node works: Switch to global mode briefly, explicitly select the target node, and visit a test destination.
• Check direct local access: Switch to direct mode, establish a new connection, and compare the error type and response speed.
• Applications that ignore the system proxy: First determine whether TUN or an in-app proxy is needed, then choose the appropriate routing mode.
• Unexpected LAN device access: Check private-address rules, TUN routes, and LAN bypass settings instead of repeatedly changing proxy nodes.

A repeatable troubleshooting sequence

1. Confirm that the configuration has loaded, that the policy group contains selectable nodes, and that at least one latency or connectivity test has completed.
2. Confirm that the target application enters the core through the system proxy, an in-app proxy, or TUN, and look for the corresponding record in the connections panel.
3. Stay in rule mode and check the rule, policy group, and final node matched by the target domain.
4. Switch to global mode, select a known working node, and establish a new connection to rule out the effect of rule-based routing.
5. Switch to direct mode and test again to determine whether the local network can reach the destination directly.
6. If all three modes fail, check DNS, the system clock, the firewall, node protocol parameters, subscription validity, and local network restrictions.

During testing, change only one variable at a time whenever possible. For example, compare rule and global modes with the same node, or compare two nodes in the same mode. If you change the node, enable TUN, modify DNS, and switch modes simultaneously, even a successful result will not reveal which change fixed the problem.

Do not treat a mode switch as a permanent fix

If a service is reachable only in global mode, staying there may work temporarily, but a better solution is to return to rule mode and inspect the matched route. Check whether service-related domains were incorrectly sent direct, whether the rule set is up to date, whether the policy group selected a suitable node, and whether the fallback rule behaves as expected.

If a service is reachable only in direct mode, check whether rule mode is sending it to an unsuitable proxy group. For services that should keep a local exit, add a more specific direct rule after understanding the configuration structure, and place it before broader proxy rules. Before editing a subscription-generated configuration, remember that subscription updates may overwrite local changes. Clients that support overrides, scripts, or merged configurations can manage custom rules in a separate configuration layer.