Clash Mode Comparison

Use Rule mode day to day, Global for troubleshooting, and Direct as a baseline

Rule mode is the best fit for most everyday use. It sends traffic that needs a proxy to the appropriate policy, while letting local networks, selected websites, and work services connect directly according to your rules. Global mode is useful for briefly checking whether a proxy endpoint can reach a service; Direct mode helps test your local network. These modes are neither speed tiers nor security levels—they determine how the core routes connections.

There’s one important caveat: this guide covers traffic that has already entered the Clash or mihomo core. If an app doesn’t use the system proxy and its traffic isn’t captured by TUN or another method, switching to Global won’t automatically send it through a proxy node.

Rule mode: rule order determines the outbound

Rule mode processes connections in the order listed under rules. Once a rule matches, later rules are generally skipped. A rule can send a request to DIRECT, a reject policy, a node, or a policy group. Rule mode doesn’t inherently mean “direct in mainland China, proxy everywhere else”—that’s just one possible ruleset. Actual behavior depends on the active configuration.

Check the rules first, then the selected policy group

Here’s a rule snippet, not a complete subscription. It assumes your configuration already has a policy group named “Proxy Selection.” If you copy it into another configuration, the policy name must match an existing group exactly.

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,Proxy Selection

• DOMAIN-SUFFIX,example.com,DIRECT: Connects example.com and its subdomains directly. It won’t match notexample.com.
• IP-CIDR,192.168.0.0/16,DIRECT,no-resolve: Connects directly when the destination’s known IP is in this range. no-resolve means the core won’t perform an extra DNS lookup just to match this rule. This is not a complete list of private network ranges.
• MATCH,Proxy Selection: Sends any connection that didn’t match an earlier rule to “Proxy Selection” as the fallback.

If MATCH is the first rule, ordinary rules below it won’t get a chance to handle those connections. And if “Proxy Selection” currently points to DIRECT, a connection matched by that group will still go direct. So seeing “Rule mode” enabled isn’t enough: check the matched rule, policy group, and final outbound.

Subscription updates can change routing

Subscriptions often include more than nodes: they may also provide policy groups, rules, and DNS settings. If a website takes a different route after an update, the client may be working as intended—the rule order or policy group definitions may have changed. For custom routing you want to keep, use the client’s supported override or merge configuration. Direct edits to generated subscription files may be overwritten on the next update. Check your client’s documentation for the exact merge order.

Global and Direct modes: changing the outbound doesn’t change what the network can reach

Global mode uses GLOBAL, not just your everyday policy group

Global mode typically stops choosing an outbound by evaluating ordinary routing rules and uses the built-in GLOBAL group instead. After switching, open the proxy page and check what that group actually selects: it could be a node, another policy group, or DIRECT. Changing nodes in your usual “Auto Select” group doesn’t necessarily change the Global outbound.

Global mode is useful for testing one variable at a time. For example, if a website fails in Rule mode but loads in Global mode with the same working node selected, first check the rule match and policy group in your original setup. This isn’t definitive proof of a routing problem: DNS caching, reused connections, or the remote service can also affect the result. Establish a new connection and change as few settings as possible.

Direct mode doesn’t mean the client is closed

Direct mode connects to destinations directly for connections that have entered the core, but the client’s listening port, DNS module, or TUN capture may still be active. So “works in Direct mode” and “works after fully quitting the client” are different tests. The first keeps the capture path in place and changes only the outbound; the second may also change system proxy settings, virtual network interfaces, and DNS routing.

Direct mode can’t make a destination reachable if it’s already inaccessible on your local network. On the other hand, printers, internal admin pages, and systems that only allow access from a company network often need direct routing. If these services stop working through a global proxy, restore rule-based routing before trying a succession of remote nodes.

How the system proxy and TUN relate to the three modes

Think of the full route in two steps: app request → capture method → mode and outbound selection. The system proxy usually registers settings such as an HTTP proxy with the operating system; only apps that honor those settings will use it. Some games, command-line tools, and apps with their own networking stack don’t automatically follow the system proxy. In particular, the system proxy isn’t a universal way to capture UDP traffic.

TUN uses a virtual network interface and routing rules to capture IP traffic, making it useful for apps that don’t support an explicit proxy. Which connections it captures still depends on routes, exclusions, permissions, and the platform implementation. Enabling TUN won’t choose the right rules for you or guarantee that a remote node supports the UDP forwarding a game needs.

Keep the listening port separate from the outbound

For example, if the configuration uses mixed-port: 7890, 127.0.0.1:7890 is the local HTTP/SOCKS mixed-proxy endpoint—not a remote node address or a port reserved for Rule mode. Other clients and configurations may use different ports, so check the active configuration.

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

This command specifies the proxy endpoint explicitly, so it doesn’t depend on whether the terminal inherits system proxy settings. It sets a 10-second connection timeout and a 20-second total timeout, and requests the response headers; these are test parameters, not measured latency. If the connection is refused, first check that the core is running and listening on port 7890 rather than assuming the node is down. If your port is different, update the command to match your configuration.

Choosing a mode for browsing, gaming, and work

Global mode doesn’t automatically make games faster

Game latency depends on the server location, your ISP’s route, the path to the remote node, and network congestion. Global mode can’t improve an outbound that already takes a longer route, or add UDP support that a node lacks. If the game’s traffic never reaches the core, switching between the three modes may make no difference. Check the connection log first to see whether the game is being captured; that’s more useful than blindly switching to Global.

For work, prioritize internal network access and company policies

Both corporate VPNs and TUN can modify routes and DNS, so check carefully where internal domains are resolved when both are enabled. If a work app relies on internal DNS, adding a direct rule for an IP address may not help—the domain could already have resolved to the wrong address. Follow your organization’s network requirements and clarify which addresses are handled by the corporate VPN and which traffic uses the local proxy. Avoid having both capture mechanisms compete for the same network ranges.

Where to switch modes and how to verify they’re active

Clash refers to a core and configuration ecosystem, and desktop clients don’t all share the same layout. Clash Meta later continued development under the name mihomo, but clients using mihomo don’t necessarily use the same controls. Look for the setting by what it does; an old screenshot isn’t a reliable guide to every client’s menus.

1. Find the mode selector. Desktop clients often show Rule, Global, and Direct options at the top of the Proxies page or in the system tray menu. In Clash Verge Rev, for example, look for the mode selector on the Proxies page; its location may vary by version.
2. Check the traffic capture settings. In Settings or on the home page, check System Proxy and TUN mode. Don’t confuse these switches with the mode selector. Enabling Rule mode alone doesn’t mean the system proxy is enabled.
3. Check the policy group. In Rule mode, check the policy group matched by the traffic; in Global mode, check GLOBAL. Note the selected node or subgroup rather than relying only on which mode is highlighted.
4. Establish a new test connection. Refreshing a page may not close all persistent connections. If needed, close and reopen the relevant tab, or end the connection on the client’s Connections page. This will interrupt any transfer in progress on that connection.
5. Review the connection log. On the Connections page, find the target domain or IP and check the matched rule, policy chain, and outbound; labels may vary between clients. Logs can provide additional context, so don’t judge only by whether a webpage loads.

The mode field in a configuration file

# Keep only one of the three; this sets Rule mode
mode: rule

# For Global mode: mode: global
# For Direct mode: mode: direct

This is a top-level field; don’t indent it under a rule or node. A graphical client may override it on startup or reload based on its UI settings, so check the active mode in the client after editing the file. The mode value direct and the rule action DIRECT serve different purposes: the former selects a runtime mode, while the latter specifies a built-in outbound for a rule.

Troubleshooting steps when switching modes doesn’t help

1. Confirm the configuration is loaded and the core is running. Successfully importing a subscription doesn’t mean the core loaded it successfully. Check for configuration parsing errors first, then confirm that the proxy listening port is active.
2. Confirm the request reaches the core. Open the Connections page and make a new test request. If no record appears, first check the app’s proxy settings, TUN routes, and exclusions.
3. Confirm the mode and outbound. Note the current mode, matched rule, and final node. If a rule matches DIRECT, changing nodes in other proxy groups usually won’t affect that connection.
4. Compare Rule and Global modes. Keep the node unchanged and establish a new connection. If Global works but Rule doesn’t, check the rules and policy groups first. If both fail, check the node, subscription status, DNS, and destination service.
5. Compare Direct mode with disabling traffic capture. If Direct still fails but the connection works after capture is disabled, investigate the capture path, DNS, or routing. Note your original settings and restore them after the test so the system proxy isn’t left pointing to a local port that’s no longer active.

Three common questions

Here’s the simplest way to choose: Use Rule mode day to day, Global mode to test the outbound when something fails, and Direct mode to test the local network path. Whichever mode you choose, check the connection log to see where traffic actually went. For more on rule types and configuration fields, see the protocol handbook. To choose a graphical client, compare platform and core support in the client comparison.