Getting Started 9-minute read

Clash Rule, Global, and Direct Modes: How to Choose

Learn how Clash Rule, Global, and Direct modes route traffic, when to use each, and what to check when connections fail after switching modes.

The key difference: where connections go, not which traffic is captured

For everyday use with both local services and sites that need a proxy, start with Rule mode. Use Global mode to temporarily bypass routing rules and test a node. Choose Direct mode to compare how your local network performs without proxy nodes. These modes control what happens to traffic after Clash receives it—not which apps send traffic to Clash.

Clash clients may label these options Rule, Global, and Direct, or show their localized equivalents. Clash Meta was later renamed mihomo, and clients commonly retain the same three modes. Rule capabilities can vary by core, but it helps to distinguish traffic capture from route selection.

Mode How captured connections are handled Best for Common misconception
Rule Checks rules in order, then routes traffic to DIRECT, REJECT, or a policy group. Everyday use, routing local services and proxy-bound traffic differently. Selecting a node does not mean every site will use it.
Global Bypasses regular routing rules and sends traffic to the GLOBAL policy. Testing a node or checking whether a rule matched incorrectly. GLOBAL can select DIRECT, and Global mode does not capture traffic from every app.
Direct The core connects captured traffic directly to its destination. Comparing your local network or temporarily avoiding proxy nodes. The core, listening ports, and DNS features may still be running.

Rule mode: match rules in order, then use a policy group

Rule mode checks the configuration from top to bottom. When a regular rule matches, its target determines how the connection is handled. The target can be DIRECT, REJECT, or an existing policy group. That group then selects a node or another policy. To trace a connection, check two things: which rule matched and what the rule’s target group ultimately selected.

Rule order matters more than the number of rules

This is an example rule section, not a complete subscription you can import as-is. Replace “Node Selection” with the name of a policy group defined in your current configuration. Leaving the example name unchanged without a matching group may cause the configuration to fail to load.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,Node Selection
  • DOMAIN-SUFFIX,example.com matches the domain and its subdomains. It does not mean that any domain containing these characters will match.
  • 192.168.0.0/16 and 10.0.0.0/8 are common private IP ranges; this example does not cover every local address range.
  • no-resolve means not to actively resolve a domain just for this IP rule. The rule can still match when the destination is already an IP address.
  • MATCH is the catch-all rule. If you put it first, later rules will never get a chance to match.

A good fit for everyday use, but routing criteria need maintenance

For example, you can send local network storage directly, route specific external sites through a proxy group, and send remaining traffic to a fallback group. Rule mode can handle all of these. However, a site’s sign-in, images, and videos may use different domains. Matching the main page correctly does not guarantee that every request will take the same route.

If a page loads but its images do not, check the failed request’s domain and matched rule first. Don’t route all traffic through a proxy indefinitely, or add a rule based only on the main domain in the browser’s address bar. Check the rule source, subscription updates, and core support together.

Global mode: useful for testing nodes, but not a system-wide proxy

Global mode sends captured application traffic to the GLOBAL policy instead of applying regular routing rules. After switching, open the client’s proxy or policy group page and check what GLOBAL currently selects. Some interfaces hide the group or show a separate Global selector, so use the actual egress shown in the connection details as your reference.

Global mode does not guarantee that traffic goes through a remote node. If GLOBAL selects DIRECT, the connection still goes directly to its destination. If GLOBAL points to another policy group, check that group’s final selection too. The “Node Selection” group commonly used in Rule mode may not be linked to GLOBAL.

Use Global mode to tell node problems from rule problems

  1. Record the failed request’s domain, matched rule, and egress node in Rule mode.
  2. Switch to Global mode and set GLOBAL to the same node you want to test.
  3. Close the existing connection and make the request again. Don’t rely on a page connection that is still being reused.
  4. If Global works but Rule does not, check the routing rules, target policy group, and DNS differences first. If both fail, check the node and the local traffic capture path.

This comparison narrows down the cause; it is not a definitive diagnosis. Remote service rate limits, DNS caching, connection reuse, and differences in test timing can all affect results. Keep the network, destination, and node the same, and change only the mode.

Direct mode: useful for network comparisons, but it does not turn off the client

In Direct mode, application traffic that reaches the core usually connects to its destination directly instead of selecting a proxy node through regular rules. This mode helps answer a specific question: “Is the proxy node causing this failure?” For example, if the same resource works in Direct mode but fails through a specific proxy node, check that node’s connectivity or whether the destination restricts traffic from its egress IP.

However, the system proxy may still point to a local listening port, and the TUN virtual interface may remain active. The client’s DNS listener, cache, and related resolution paths may also stay enabled. Direct mode is therefore only a comparison that avoids proxy nodes; it does not fully represent your network with the client shut down.

  • To temporarily stop using proxy nodes: Switch to Direct mode, then confirm the connection details show DIRECT as the egress.
  • To test without the client handling traffic: Turn off the system proxy and TUN first, then exit the client if needed. Check that no manual system proxy settings remain.
  • If no sites load after you exit: Check whether the system still points to a proxy port at 127.0.0.1 whose listener has stopped.

Direct mode does not guarantee that every destination is reachable. Access still depends on your local network, routing, DNS, and the destination’s policies. A site failing in Direct mode alone does not prove the client is misconfigured.

System proxy and TUN: determine which connections reach the core

A system proxy uses the operating system’s proxy settings to send requests from apps that honor those settings to a local HTTP or SOCKS endpoint. Browsers usually support the system proxy, but command-line tools, games, and some standalone apps may use their own network settings. TUN captures matching traffic through a virtual network interface and routes; coverage still depends on routes, exclusions, permissions, and core configuration.

Check the listening port before testing traffic capture

The commands below assume the client’s HTTP or mixed-port listener is 7890. This is an example value, not a universal default. Check the port in the client’s settings before running them. On Windows, use curl.exe; on macOS and Linux, use curl.

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

The first command explicitly uses the local proxy endpoint; the second tells curl not to use an application-level proxy. If TUN is still enabled, the second request may still be captured by the virtual interface, so it is not a test that fully bypasses the client. Check the connection panel to see whether each request reached the core and what egress it used.

An HTTP response only confirms that this request received a response; it does not prove that video, game UDP traffic, or the whole system is being proxied correctly. Testing an HTTP proxy and capturing UDP are different things. UDP handling also depends on the entry method, node protocol, and server support.

Connection problems after switching modes: troubleshoot in five steps

1. Check the active configuration and final egress

First confirm which subscription or local configuration is active, then check the mode and policy group. A subscription update may change rules and group names; the node previously selected in the interface may no longer be the one used by the current connection. In Rule mode, check the matched rule; in Global mode, check GLOBAL; in Direct mode, check DIRECT.

2. Close existing connections before testing again

Switching modes usually affects new connections. Existing TCP connections and some UDP sessions may continue along their original route. Browser connection reuse over HTTP/2 and HTTP/3 can make this more noticeable. End the target connection in the client’s connection panel, then reload the page. Ending all connections will interrupt downloads, meetings, and other tasks, so save your work first.

3. Check DNS and application traffic egress separately

If DNS resolution fails, switching to Global mode may not help. Check the logs for DNS timeouts, destination resolution errors, or fake-IP issues. In mihomo, upstream DNS servers, resolution policies, and whether DNS follows routing rules all depend on the active configuration. Don’t assume that “Global mode sends all DNS through the node.” Back up your configuration before making changes, and avoid changing DNS, nodes, and mode all at once.

4. Check the system proxy, TUN, and other network tools

If an explicit proxy test works but the browser has no corresponding connection record, first check whether it uses its own proxy settings. If requests fail with TUN enabled, check permissions, route exclusions, and conflicts with other VPNs. Test one traffic capture path at a time to avoid confusing results from the system proxy and multiple virtual interfaces.

5. Record consistent test conditions instead of relying on latency

A node latency test usually probes a specific address once; it does not measure throughput to a destination website. On the same network, record the mode, node, destination domain, result, and error for each of three tests. For example, “Rule mode matched DIRECT; connection timed out. Global mode used Node A; returned HTTP 200” is more useful for troubleshooting than “node shows 80 ms.” The values here are an example format, not test results from this site.

Everyday recommendation: use Rule mode, and use Global or Direct for comparison

  • For work, browsing, and local network devices: Start with Rule mode and verify how private addresses and commonly used services are actually matched.
  • If you suspect a routing rule is wrong: Temporarily switch to Global, explicitly select the node you want to test, close existing connections, and compare the same destination.
  • If you suspect a node or remote route is having trouble: Use Direct mode for comparison. To establish a baseline without the client handling traffic, also turn off the system proxy and TUN.
  • If only one app is affected: First check whether its traffic reaches the core. Don’t keep switching among the three modes instead of checking how traffic is captured.

A reliable troubleshooting order is: does the traffic reach the core, how does the current mode handle it, and does the final egress match your expectations? Confirm all three before changing rules or nodes. For installation and import steps, see the Clash setup guide. To understand rule fields, see the protocol reference.

Download Clash