Clash Proxy Modes Explained: Rule, Global, and Direct

The three modes choose an outbound route, not whether traffic reaches the core

Clash proxy modes determine how traffic is handled after it reaches the core. rule selects a policy based on rules, global routes traffic through the built-in GLOBAL policy, and direct connects directly. These three basic mode values remain the same in Clash Meta and its successor, mihomo.

Keep two things distinct: system proxy settings, app proxy settings, and TUN determine whether connections reach the core; the proxy mode determines where connections go once they arrive. So “global mode” does not mean every program on your computer is being intercepted. An app that ignores the system proxy and is not routed through TUN will not automatically use a proxy node just because you switch to global mode.

Rule mode: matches in order and stops at the first match

mode: rule routes traffic according to your configuration. Common rules match domain suffixes, destination IP ranges, or a final catch-all policy. Rules are typically checked from top to bottom; the first match determines the policy for that connection. Later rules do not choose a different route for it.

A minimal, readable traffic-routing example

This configuration snippet uses only the built-in DIRECT policy to make the syntax easier to understand. It does not create any proxy nodes.

mode: rule
log-level: info

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,DIRECT

• DOMAIN-SUFFIX,example.com,DIRECT matches example.com and its subdomains, but not notexample.com.
• 192.168.0.0/16 and 10.0.0.0/8 are private address ranges. This example sends connections to those addresses directly. It illustrates how local network routing works, but does not cover every local network scenario.
• no-resolve means the core will not resolve a domain just to match this IP rule. If the destination is already an IP address, it can still be matched by address.
• MATCH is the catch-all rule and should go last. Connections that do not match any preceding rule use the policy specified here.

In a real subscription, if a proxy group named Proxy already exists, you can change the last line to MATCH,Proxy. The name must exactly match the group in your configuration, including capitalization. Do not add a rule without its corresponding group, or the configuration may fail to load because the policy does not exist.

Matching a proxy group does not mean a proxy node is selected

A rule points to a policy, which could be a node, a selector group, an automatic latency-testing group, or DIRECT. For example, if a rule matches Proxy but that selector group currently points to DIRECT, the connection still goes direct. When troubleshooting, check both which rule matched and what the policy group ultimately selected; the rule name alone is not enough.

Global mode: uses GLOBAL, but only for intercepted traffic

mode: global sends ordinary connections that reach the core through the built-in GLOBAL selection policy instead of routing them through the usual rules list. After switching modes, open the client's proxy selection screen, find GLOBAL, and confirm that it points to the node or policy you intend to use.

The client may label this option “Global” or “Global Selection.” Menu names vary by client; what matters is that the current mode is global and the global policy has an explicit selection. If GLOBAL still points to DIRECT, global mode will not send traffic through a proxy node.

Useful for quick, temporary comparisons

1. In rule mode, note which rule and policy a site with connection problems matches.
2. Switch to global mode and select a node you have confirmed is working.
3. Close the site's existing connections and make a new request.
4. If the new connection works, review rule order, domain coverage, and the original policy group's selection.

This result only shows that the two tests followed different handling paths; it does not prove that the “rules file is broken.” Different nodes, changed DNS results, or an old connection that stayed open can all affect what you observe. For a fair comparison, keep the node, destination, and interception method consistent, and change only the mode.

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

mode: direct sends connections that reach the core straight to their destinations without using a proxy node. System proxy settings, the TUN virtual network interface, and the core's DNS service may still be active, so direct mode is not the same test as exiting the client and disabling traffic interception.

For example, a browser may still send requests to the local address 127.0.0.1:7890, where the core receives them and connects directly to the destination. The port 7890 is just a common example; check mixed-port or port in the active configuration for the actual port.

When to use direct mode for comparison

• Check the proxy route: If a destination works in direct mode but not through a proxy, check node connectivity, outbound restrictions, and policy selection.
• Check the local network: If direct mode also fails, check Wi-Fi, the gateway, DNS, and the destination service itself.
• Isolate interception issues: If direct mode fails but the connection works after disabling the system proxy and TUN, check the local interception path or the core's DNS.

Direct mode does not guarantee that every website will be reachable, and it does not automatically switch DNS to your ISP's servers. Name resolution may still use encrypted DNS, a configured resolver, or other DNS rules. To troubleshoot DNS, check the dns configuration separately rather than treating the mode switch as a DNS reset.

How to verify a mode change: check config, connections, and outbound route separately

Editing mode in a YAML file does not mean the running core has adopted the new value. Some clients override subscription fields with UI state or override settings; subscription updates may also replace manual edits. Check the mode currently shown by the client and the records for new connections.

Follow a consistent checklist instead of relying on whether a webpage loads

1. Record the current state. Note the mode, selected node, and system proxy or TUN status, and keep a copy of the configuration you can restore.
2. Change one variable. Switch only the mode; leave DNS, nodes, and rules unchanged. If you need to select an outbound route in global mode, note what you selected.
3. Start a new connection. Close the test app's existing connections; if needed, end the relevant connections in the client's connection panel. Existing TCP connections usually do not move to a new route automatically.
4. Inspect connection details. Look for the destination domain, destination IP, matched rule, and policy chain on the “Connections” page. The fields shown vary by client.
5. Check the outbound IP. Use a trusted service to look up your outbound IP, then compare it with a direct-connection baseline. The same outbound IP does not necessarily mean the configuration had no effect; both routes may share a public IP.

Use curl to keep the test entry point consistent

If the active configuration has mixed-port: 7890, explicitly specify the local proxy to reduce interference from browser extensions and system proxy settings:

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 uses the specified local HTTP proxy; the current mode then determines the outbound route. It does not force traffic through a remote node. The second command skips curl's explicit proxy, but if TUN is still intercepting traffic, the request may still reach the core. Do not treat it as a baseline that bypasses the client. In Windows PowerShell, if curl behaves differently because it is an alias, use curl.exe.

The 10-second connection timeout and 20-second total timeout in the example are test limits, not speed benchmarks. An HTTP status in the response confirms that a response was received, but not that the outbound route was the one you expected. Check the core's connection records as well. If the destination does not support HEAD requests, retry with a regular GET request.

Choose by use case: everyday routing, quick troubleshooting, or a direct baseline

For everyday use, start with rule mode: specify which connections should go direct and which should use a proxy group. Global mode is useful for temporarily routing everything through one selection or comparing against your rules; direct mode is useful when you do not want to use a node or need a partial test baseline. There is no fixed speed ranking—the result depends on the actual route, node quality, destination service, and local network.

Common misconceptions: issues that switching modes will not fix

If global mode works but rule mode does not, do I have to leave global mode on?

Not necessarily. First check which rule the failed connection matched in rule mode, then confirm that the relevant group has a working node selected. A domain may also depend on related domains; covering only the main domain may leave login, static asset, or API requests unrouted. Use connection records to add the missing rules rather than bypassing all traffic routing indefinitely, so local network access is preserved.

Why are new entries still appearing in the log after switching to direct mode?

Direct mode does not stop the core. As long as the system proxy or TUN continues sending traffic to it, connections will still appear in the log. To tell whether a remote node is being used, check the final policy and outbound route—not whether the client still shows traffic activity.

Does global mode mean all UDP traffic can be proxied?

No. Whether UDP reaches the core depends on how traffic is intercepted; whether it can be forwarded depends on the entry point, the selected node's protocol, and its configuration. Setting only the HTTP system proxy used by browsers does not guarantee that game or voice app UDP traffic is intercepted. Switching to global mode cannot restore a missing route into the core.

For more settings, see the User Guide. To check the mode, rules, port, and DNS fields, consult the Configuration Reference. Follow the same order: confirm traffic reaches the core, verify the policy selection, then check the actual outbound route.