Clash Proxy Modes Explained: Rule, Global, and Direct

First, separate two questions: does traffic enter the core, and how does it leave?

Clash rule, global, and direct are outbound decision modes, not three ways to capture traffic. The system proxy, an app's manual proxy settings, and TUN route connections into the core; the mode determines where those connections go next. Connections that never enter the core won't be proxied just because you switch to global mode.

For example, a browser that follows the system proxy settings can send requests to the local proxy port, while a game that ignores those settings may still connect directly through the physical network adapter. When both are running, Clash's “global” mode applies only to connections it has captured. TUN can capture more traffic, but coverage still depends on routing, exclusions, permissions, and platform-specific implementation.

The mode concepts below apply to common Clash and Clash.Meta (later renamed mihomo) cores. A GUI client may label the setting “Mode,” “Proxy Mode,” or “Outbound Mode”; names and locations vary. Check the active mode, connection logs, and actual outbound chain rather than relying on the label alone.

The three modes compared: rule-based routing, one outbound policy, and direct connections

Rule mode does not mean all traffic is proxied

Rules can point to a proxy node, a proxy group, DIRECT, or REJECT. So rule mode can proxy, connect directly, or reject traffic. The route for any given request depends on the rule it matches and, if that rule points to a proxy group, the group's current selection.

Global mode does not capture traffic from every device

Global mode typically sends captured connections to the built-in GLOBAL selector. If it selects a proxy node, connections go out through that node; if it selects DIRECT, they still connect directly. Seeing “Global” does not confirm that your traffic is using a different route—check the policy selected in GLOBAL.

Direct mode does not turn off the client

In direct mode, the system proxy or TUN may remain enabled, and the core may still handle connections and DNS. Direct mode only changes the outbound policy to direct connections. To remove the client from the network path entirely, turn off traffic capture separately and verify that system proxy, routing, and related settings have been restored. Selecting direct mode alone does not do this.

Rule mode: decide which connections go direct by rule order

Standard rules are checked from top to bottom, and the policy for the first matching rule is used. Put specific domain exceptions before broader conditions, and leave MATCH as the final fallback. The number of nodes in a subscription says nothing about whether its rules are complete: proxy nodes, proxy groups, and rule lists are separate components.

This is a configuration snippet, not a complete subscription you can import on its own. It assumes your existing configuration defines a proxy group named “Node Selection.” Replace that name with a policy that exists in your configuration, and keep your existing nodes, DNS settings, and other fields.

mode: rule

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
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Node Selection

• DOMAIN-SUFFIX,example.com matches example.com and its subdomains. This is only an example; it does not represent a list of any particular type of website.
• These three private IPv4 ranges illustrate direct routing for LAN traffic. They do not cover every local address, IPv6, loopback addresses, or special-purpose ranges.
• no-resolve means the rule will not trigger a DNS lookup just to match an IP address. It can still match if the connection already has a destination IP.
• GEOIP,CN uses an IP geolocation database. It does not mean “all Chinese-language websites,” and it may not identify every service in mainland China accurately.
• MATCH catches connections not matched earlier, then passes them to the “Node Selection” proxy group to choose an outbound route.

Global mode: test nodes and compare routing behavior

Global mode can remove one variable while troubleshooting: it temporarily bypasses ordinary rule-based routing so test connections use one outbound policy. It cannot fix an expired subscription, invalid credentials, an unreachable node, or DNS problems, and it does not guarantee that every app will work.

1. Note the destination domain that failed in rule mode and the node currently selected in the proxy group.
2. Switch to global mode and select the same node in GLOBAL so you change the mode without changing the node.
3. Close the existing connection and visit the same destination again. Existing browser connections may continue using their original outbound route.
4. Check the Connections or Logs page to confirm the new connection entered the core and that its outbound chain includes the expected node.

If the same node works in global mode but fails in rule mode, first check the matched rule, proxy-group selection, and fallback rule instead of immediately replacing the subscription. If both modes fail, check node connectivity, authentication, DNS resolution, and the destination service. These checks help narrow down the cause; use the logs to confirm it.

When to use a temporary single outbound route

Global mode may also send captured LAN connections, software downloads, and video traffic through a proxy node, increasing data use and latency. It can also block access to a company intranet, NAS, or router admin page. If you routinely need most traffic proxied and some traffic direct, add explicit exceptions in rule mode rather than repeatedly switching to global.

Direct mode: check local network and LAN access

Direct mode answers a specific question: can the current network reach a destination without a remote proxy node? It can help when accessing a LAN printer, troubleshooting a captive portal, or comparing access to a service in mainland China. If a destination requires a proxy, failure in direct mode does not mean the client is broken.

Troubleshooting LAN devices in order

1. First, test the device's actual IP address, such as 192.168.1.1. This is a common example; use the address of your current gateway or device.
2. If the IP address works but the device name does not, check DNS, search domains, and name discovery. .local often uses mDNS, so ordinary DNS rules alone may not explain the issue.
3. If the device is reachable in direct mode but not in rule mode, check whether private IP ranges are being sent to a proxy policy and whether an earlier rule is matching first.
4. If both modes fail, check Wi-Fi client isolation, the device firewall, subnet differences, and routing conflicts with other VPNs.

With TUN enabled, distinguish between “traffic enters TUN and exits via DIRECT” and “traffic bypasses TUN because of a route exclusion.” These are different paths. For enterprise VPNs or specialized intranets, configure capture exclusions as supported by your client, and avoid changing multiple route sets at once so you can still identify the cause.

Combining the system proxy, TUN, and mode settings

Traffic-capture methods and routing modes can be combined independently. The system proxy with rule mode works well for desktop apps that honor proxy settings; TUN with rule mode can handle more connections from apps that do not. TUN with global mode still does not guarantee connectivity: node UDP support, DNS routing, and operating-system routes all affect the result.

When setting a proxy port manually, use the value shown by the client. For example, an app should use the corresponding local mixed-proxy port only if the configuration explicitly sets mixed-port: 7890. 127.0.0.1:7890 is not a universal address for every client. Do not enter the external-controller control-interface port in your browser's proxy settings, and do not confuse a local listening port with a remote node port.

Still having trouble after switching modes? Check the connection logs

Clash mode changes usually apply to new connections. Reused browser connections, long-lived video streams, downloads, and an app's built-in DNS cache can make it look as if nothing changed. Note your original settings before testing, change one variable at a time, and retest the same destination.

• The destination is missing from the connection log: First check whether traffic is entering the core. Confirm that the system proxy is enabled, check whether the app has its own proxy settings, and verify that TUN started successfully.
• Rule mode matches DIRECT: Check whether the matching condition is expected. If traffic should be proxied, adjust the specific rule or its order rather than just switching nodes.
• A rule matches a proxy group, but traffic still goes direct: Check whether that group or one of its nested groups selected DIRECT; do not rely on the group name alone.
• Global mode still fails: Confirm the actual selection in GLOBAL, then check the logs for node handshake errors, authentication failures, connection timeouts, and other issues.
• The domain fails, but the IP responds: Continue troubleshooting DNS. HTTPS also depends on certificates and SNI, so opening a site by IP is not a complete substitute for testing it by domain name.

For your first setup, see the installation and setup guide. To check system proxy, TUN, and platform support across clients, see the client comparison. These capabilities depend on the specific client and core, not just the “Clash” name.