Clash Rules, Global, and Direct Modes: Differences and How to Choose

Where the mode fits in the traffic path

Clash, Clash Meta (mihomo), and graphical clients built on these cores typically offer rule, global, and direct modes. These modes mainly determine which policy handles a connection after it enters the core; they are not the same as the system proxy, TUN, or DNS switches.

Before a mode can control a connection, the traffic must first enter Clash. When the system proxy is enabled, browsers and apps that honor system proxy settings send requests to the local HTTP or SOCKS port. With TUN enabled, the core can intercept a broader range of TCP and UDP traffic at the network layer. Manually entering a proxy address for an application can also let it connect directly through mixed-port. Connections that use none of these entry points will not automatically enter the proxy path when you switch modes.

Only after traffic enters the core does the mode take part in routing decisions. Rule mode reads the rule list and selects a policy; global mode generally sends the connection to the GLOBAL policy group; direct mode sends it to DIRECT. The core then performs domain resolution, policy-group selection, node connection, and other steps.

Mode changes usually affect only new connections. Existing HTTP/2, HTTP/3, or WebSocket sessions in a browser may continue using their previous path, while downloads and messaging apps may keep long-lived connections open. To test a mode change, close and reopen the target page; if necessary, terminate the app's connections or briefly restart the client.

Rule mode: route traffic by destination, source, and protocol

Rule mode is the most common choice for everyday use. The core checks the rules in the configuration file from top to bottom. Once the first matching rule is found, matching stops and the connection is handed to the policy group or built-in policy specified by that rule.

Rules can match full domains, domain suffixes, IP ranges, geographic data, processes, inbound sources, or network types. Supported rule types vary between core versions, and process rules are also limited by operating-system permissions and implementation details. Always follow the documentation for the core used by the current client.

rules:
  - DOMAIN-SUFFIX,example.net,Proxy
  - DOMAIN,printer.lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

This example handles specified domains first, sends local-network ranges directly, then processes geographic IP rules, and finally uses MATCH for connections that matched nothing earlier. MATCH generally belongs at the end of the rule list; if an overly broad rule comes first, more specific rules later may never run.

Key advantages of rule mode

Local and proxied traffic can coexist. Devices on the local network, services in mainland China, or corporate intranet resources can stay direct, while destinations that need a proxy go through a node.
Policy groups can be selected independently. You can assign separate policy groups to streaming services, developer tools, and messaging apps instead of sending every connection through one node.
It helps control bandwidth and node usage. Large downloads such as software updates and cloud synchronization can be routed through a proxy only when the rules call for it.
It works well for long-term use. Once the rules are stable, you usually do not need to switch modes manually.

Common misconceptions about rule mode

Rule mode does not guarantee that every domain will be classified as expected. Rule sets need updates, domains can change, and apps may connect directly by IP address. If the fallback policy is a proxy, unmatched connections still use the proxy; if the fallback is direct, uncategorized destinations connect directly. To understand the result, inspect the matched rule, policy chain, and final node in the connection details rather than relying only on the displayed mode name.

DNS also affects matching. When a domain request enters the core, the core can usually apply domain rules directly; connections that expose only an IP may require IP rules, sniffing results, or a mapping mechanism. With fake-ip, redir-host, or domain sniffing enabled, exact behavior also depends on the DNS configuration and core version.

Global mode: send everything to the GLOBAL policy

Global mode bypasses normal rule matching and sends every connection that enters Clash to the GLOBAL policy. Graphical clients usually expose GLOBAL on the proxy or policy page, where you can choose the actual egress from available nodes, proxy groups, or DIRECT.

So “global mode” does not necessarily mean that every connection uses a remote node. If GLOBAL currently points to DIRECT, the final result is still a direct connection. If it points to an automatic selection group, the egress depends on that group's health checks and selection logic. After switching to global mode, verify what GLOBAL currently points to.

When global mode is useful

Quickly determine whether rules are causing the problem. If a site is unreachable in rule mode but works in global mode, the node itself may be usable; next, inspect the matched rule, policy group, and DNS path.
Use one egress temporarily. When testing a node's connectivity, latency, or public IP address, global mode reduces interference from rule matching.
The configuration is not organized yet. After importing a basic configuration containing nodes but no usable rules, you can temporarily use global mode to verify the nodes. Before using it long term, complete the routing configuration.
An app uses several related domains. When troubleshooting login flows, CAPTCHA checks, or resource loading across domains, a single egress makes it easier to determine whether routing is inconsistent.

Important considerations for global mode

A single egress also sends services that could have connected directly through the same policy, which may increase latency and node traffic. Although LAN printers, router admin pages, and network storage often have additional bypass mechanisms, do not rely on the mode name alone. Check TUN route exclusions, the system proxy bypass list, and the client's LAN settings.

Some corporate intranets, campus-network login pages, and addresses reachable only on the local network should not go through a remote node. If these services stop working in global mode, switch back to rule mode and assign the relevant domains or ranges to DIRECT. Rules for private addresses should be explicit; common ranges include 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.

Direct mode: send connections entering the core through DIRECT

Direct mode sends connections intercepted by Clash straight to their destinations through DIRECT, without selecting a proxy node through the normal rules. It is useful for temporarily disabling proxy forwarding, comparing local-network behavior, or accessing resources available only from the current network.

Direct mode does not mean the client has fully exited. The system proxy port may still be listening, the TUN virtual adapter may remain enabled, and Clash may continue handling DNS requests. The difference is that the final forwarding policy becomes DIRECT. To restore the operating system's original network path, disable the system proxy or TUN and confirm that system DNS has been restored as intended by the client, rather than merely switching to direct mode.

Typical uses for direct mode

Check whether a website is directly reachable on the current ISP network.
Access a router, printer, network storage, or a local service in a development environment.
Temporarily use the local network egress while downloading a large system update.
Troubleshoot cases where the proxy node works but a particular application still fails.
Pause proxy forwarding while keeping the client interface and configuration available for a later switch back.

If the destination is still unreachable in direct mode, the problem is usually not the proxy node. Check local DNS, the system firewall, the destination service, the ISP path, and the app's own settings. If direct mode works but rule mode fails, inspect the matched rule. If direct works and global fails, focus on the node selected by GLOBAL and its network capabilities.

Complete comparison of rule, global, and direct modes

Comparison	Rule mode	Global mode	Direct mode
Primary decision method	Match rules in order and select a policy	Send everything to the GLOBAL policy	Send everything to DIRECT
Uses the standard rule list	Yes	Usually bypassed	Usually bypassed
Does traffic ultimately use a proxy	Depends on the matched rule and policy group	Depends on the current GLOBAL selection	Does not use a proxy node
Suitable for everyday long-term use	Suitable	Suitable for a short-term unified egress or diagnostics	Suitable for temporarily disabling forwarding or testing
Access to LAN resources	Can be made direct with explicit rules	Check bypass settings and the GLOBAL egress	Usually accessed directly
Troubleshooting value	Inspect the rules and policy chain	Isolate rule-matching factors	Establish a local-network baseline
Must traffic enter Clash first	Yes	Yes	Yes

There is no fixed performance ranking among the three modes. Connection speed mainly depends on the local network, destination server, node load, transport protocol, DNS results, and route quality. Rule mode adds a matching step, but matching a normally sized rule set is rarely the main source of noticeable latency. Global mode also does not automatically choose the fastest node unless GLOBAL points to a policy group with speed-testing and selection logic.

Choose the right mode for your use case

Everyday browsing with multiple apps online

Use rule mode by default. It can separate LAN resources, local services, and destinations requiring a proxy onto different paths. The configuration should have a clear fallback rule, and its rule sets should be updated regularly. If a type of service is frequently routed incorrectly, add a more specific domain rule and place it before broader rules.

Testing nodes after importing a configuration

First confirm that the system proxy or TUN is enabled. Then switch to global mode and select a specific node in GLOBAL. Visit several destinations and watch the connection log. If global mode works, switch back to rule mode and inspect the routing. If global mode also fails, first check the node, subscription contents, system time, and network connectivity.

A webpage opens, but login or images fail

You can briefly switch to global mode and test again. Modern webpages often request the main site, static assets, authentication services, and API domains at the same time. Rule mode may send these requests through different egresses, causing inconsistent session regions or IP addresses. If global mode fixes the issue, inspect the domains behind the failed requests and create a consistent policy for them instead of relying on global mode long term.

Accessing a router admin page, NAS, or development server

For temporary diagnosis, use direct mode. For a lasting configuration, add direct rules for LAN domains and private ranges in rule mode. When TUN is enabled, also check route exclusions and auto-route settings so the local subnet is not mistakenly sent to a remote egress.

You only want to pause proxying for a while

If you want to keep Clash's traffic interception and DNS handling, switch to direct mode. If you want the system to return fully to its original network path, disable the system proxy or TUN. Before quitting the client, also check whether it will restore the system proxy settings automatically, so the operating system does not continue pointing to a local port that is no longer listening.

You need every request to use the same egress

Use global mode and explicitly choose a node or policy group in GLOBAL. After testing, decide whether to return to rule mode based on your needs. Long-term global forwarding can affect local-service access, latency, and node traffic, so it should not be treated as a permanent fix for every problem.

Troubleshooting order when switching modes has no effect

When the mode appears correct but network behavior does not change, start by checking the traffic entry point instead of repeatedly changing nodes. The following order works for most desktop clients and mihomo core configurations.

Confirm that the target app enters Clash. Check the client's connection list or live log. If no new connection appears at all when you access the destination, the app likely does not use the system proxy or the traffic is not being intercepted by TUN. Some games, command-line tools, and apps with their own network stacks do not automatically read system proxy settings.
Confirm that the current mode was written to the core. The graphical interface may briefly be out of sync with the core state. After switching, check the mode value in the log or control panel; restart the core if necessary instead of merely refreshing the page.
Check GLOBAL's actual selection in global mode. GLOBAL may still point to DIRECT, or it may point to a policy group that is currently unavailable. Expand the policy chain level by level and confirm the final egress node.
Check the matched rule in rule mode. Connection details usually show the rule type, rule content, and target policy. If the result is unexpected, check rule order, rule-set update status, and where the trailing MATCH sends traffic.
Check the DNS path. When domain resolution fails, all three forwarding modes may appear unable to connect. Review the DNS log, confirm that the upstream server is reachable, and check fake-IP filters, IPv6 settings, and domain-sniffing configuration.
Rebuild existing connections. Close the page or session in the target app and wait for old connections to close before testing again. In a browser, open a new private window to reduce the effects of caching, connection reuse, and extension settings.
Check for other proxy settings in the operating system. Browser extensions, environment variables, corporate proxies, VPNs, and other network tools can create a second forwarding layer. Keep only one explainable test path at a time.

Locate the problem quickly with a three-step comparison

First, test in direct mode to establish a local-network baseline. Second, use global mode with a specific node to verify the proxy path. Third, return to rule mode and observe the matched rule. Failure in direct mode points to the local network; failure in global mode while direct works points to the node or proxy entry point; failure only in rule mode points to rule order, policy groups, or DNS classification.

After testing, everyday use will usually return to rule mode. Global and direct modes work better as temporary tools for specific purposes: the former provides a unified egress while isolating rule-related factors, and the latter establishes a local-network comparison. Understanding the relationship between the traffic entry point, mode decision, and final policy is more reliable than repeatedly switching buttons.