Clash Proxy Modes: Rule vs Global vs Direct

Proxy modes and traffic capture are different

Clash's three proxy modes determine how connections entering the core choose an outbound route. Rule mode routes traffic according to rules, global mode uses the global policy, and direct mode connects straight to the destination. These are not three ways to capture device traffic, nor are they speed settings.

System proxy settings, in-app proxy settings, and TUN determine how connections reach the core. For example, when a browser uses 127.0.0.1:7890 as its HTTP proxy, the browser's matching requests go to that listening port. Apps that don't use the system proxy may still connect directly, and enabling global mode doesn't change that automatically.

How traffic flows in each mode

“Direct” still operates within the core's traffic-processing flow; it doesn't mean the client is bypassed. DNS, listening ports, and any enabled traffic-capture mechanisms may still affect the connection. These modes also won't add missing node details, repair a subscription, or change server-side settings.

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

Rule mode is suited to everyday use. The core checks rules from top to bottom and uses the target of the first match. A target can be DIRECT, REJECT, a proxy node, or a policy group already defined in the configuration.

Rule targets and policy group selection are separate steps

Suppose a domain rule points to “Proxy Selection.” The core first assigns the connection to that group, then determines the actual route based on the group's type and current state. A manual selection group uses its current choice, while an automatic test group follows its own settings. Matching a group doesn't guarantee that traffic will be relayed through a remote node: if the group selects DIRECT, the connection still goes direct.

This snippet illustrates rule order; it isn't a complete subscription. “Proxy Selection” must exactly match a name in the existing proxy-groups, and you should check whether other rules need to come before it.

mode: rule

rules:
  - DOMAIN-SUFFIX,home.arpa,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
  - MATCH,Proxy Selection

• DOMAIN-SUFFIX matches domain suffixes. The core needs the corresponding domain information; don't assume that every connection made directly to an IP address can match a domain rule.
• IP-CIDR matches destination IP ranges. These three ranges cover common private IPv4 addresses.
• no-resolve means this IP rule won't trigger an additional DNS lookup. Connections that already have a destination IP can still match.
• MATCH is the catch-all rule and should come after rules that need to take priority. Putting it first prevents later, more specific rules from matching.

What to check when a site uses the wrong route

Open the connection details and check the destination domain or IP, matched rule, policy chain, and final node. If the connection matches MATCH, none of the earlier rules caught it. If the correct policy group matched but the wrong node was used, change the group's selection rather than adding more rules of the same kind. For more configuration details, see the policy groups section in the advanced guide.

Global mode: bypass rule-based routing with GLOBAL

Global mode sends connections entering the core to the GLOBAL policy group instead of routing them through the regular rules list. Clients typically provide a way to choose the global policy; its label and location vary by client version.

After switching to global mode, check what is selected in GLOBAL. It could be a node, another policy group, or DIRECT. The label “Global mode” alone doesn't tell you the actual route. The “Proxy Selection” group used in rule mode may not be the global choice currently in effect.

Use global mode to separate rule issues from node issues

1. Note the URL that fails in rule mode and the matched rule shown in its connection details.
2. Switch to global mode and explicitly select the node you want to test in GLOBAL.
3. Close the existing connection for that URL, then make a new request and check the new connection record.
4. If global mode works but rule mode doesn't, start by checking the matched rule and policy group selection. If neither works, check the node, DNS, and traffic-capture path.
5. When testing is done, switch back to rule mode and verify the policy group used for everyday traffic.

Direct mode: troubleshoot local networking without disabling Clash

In direct mode, the core connects to the destination instead of relaying traffic through a proxy node. Use it to answer a specific question: can the same request succeed without a remote proxy route? For example, if you can't open your router's admin page, switch to direct mode, establish a new connection, and see whether access returns.

Direct mode doesn't fully recreate a “native” network connection. With TUN enabled, the connection may still pass through a virtual interface. If mihomo DNS or Fake-IP is enabled, the core may still handle DNS resolution and address mapping. To test whether an app completely bypasses the core, disable the relevant traffic-capture paths.

Compare in two stages to isolate the cause

• Stage 1: Leave the system proxy or TUN settings unchanged and switch to direct mode. This helps determine whether the issue involves proxy nodes or route selection.
• Stage 2: Use the client's controls to turn off the system proxy and TUN, then check whether the browser has a separate proxy configured. This helps determine whether the issue involves traffic capture by the core, DNS, or an app-level proxy.

If the first test still fails but the second works, you can't conclude that the local network is broken. Check DNS settings, virtual interface routes, proxy listening ports, and the firewall. Conversely, if direct mode fails but proxy mode works, the local network may simply take a different route to the destination service; that doesn't necessarily mean rule mode is misconfigured.

Where to switch modes and how to set the configuration field

Desktop clients usually offer a “Proxy Mode” option on the main screen or a “Rule / Global / Direct” choice in the tray menu. On mobile, it may be on the home screen or in a side menu. Layouts differ by client, so don't assume one client's menu path applies to every Clash client.

Check the mode actually selected and the core's runtime state. If you edit YAML directly, the mode field belongs at the top level, not inside dns, tun, or proxy-groups:

# Top-level field; valid values are rule, global, and direct
mode: rule

After editing the file, you'll usually need to reload the configuration. Some clients merge UI settings, overrides, or runtime state into the final configuration, so “the file says rule” and “the core is using rule” may not always match. After a subscription update, check that your local changes are still in place.

Ports and modes are separate settings

mixed-port: 7890 opens a mixed HTTP and SOCKS proxy listener on port 7890. It is a separate setting from mode. If your browser still connects to the old port 7890 while the listener has moved to 7891, switching modes won't fix the mismatch. Update the address and port in your app or system proxy settings.

Choose a mode for the task instead of toggling at random

Everyday browsing: rule mode

When you use local services, LAN devices, and sites that need a proxy, choose rule mode. Start by checking that rules are ordered correctly and point to the intended policy groups, then add rules based on actual connection records. There's no need to route all traffic entering the core through the same remote node just to access one site.

Quick node testing: global mode

To rule out rule behavior, use global mode and explicitly select a node. Keep the URL, traffic-capture method, and DNS conditions constant, changing just one variable at a time. A successful node latency test only shows that its test destination was reachable at that moment; it doesn't guarantee that another domain will load in your browser.

Troubleshooting routers, NAS devices, and local services: compare with direct, then return to rule mode

For 192.168.1.1 or a local development service, use direct mode for a quick comparison. If the global proxy route is causing the failure, the long-term fix is usually to return to rule mode and add direct rules for the relevant LAN ranges. Excluding routes in TUN is a separate configuration layer; don't confuse it with DIRECT in the rules.

Don't assume every private IP is reachable. Corporate VPNs, remote work networks, and local networks can use overlapping IP ranges. In those cases, use the routing table and your organization's network requirements to choose the route instead of applying a generic snippet blindly.

No change after switching? Check existing connections, DNS, and traffic capture

1. Start with the connection record. If no new connection appears, check whether the app uses the system proxy or whether TUN captures its traffic. System proxy settings don't cover every app or all UDP traffic.
2. Then check the actual route. Verify the active mode, matched rule, and policy chain. In global mode, check GLOBAL; in rule mode, check the matched target group.
3. Start a fresh test connection. Existing downloads, long-lived connections, and browser connection pools may not switch routes when the mode changes. Close the relevant connection in the client, then revisit the site. If needed, fully quit and reopen the browser.
4. Check DNS separately. A domain lookup failure doesn't mean the rules are wrong. Check that DNS queries succeed and return the expected results. Switching modes won't necessarily clear an app's cache or change its DNS upstream.
5. Finally, verify the active configuration. Check that the subscription loaded successfully, overrides are applied, and the UI mode isn't overriding the YAML setting.

Choosing a mode is about isolating variables: use rules for everyday traffic, global mode to test a specific proxy route, and direct mode as a comparison. After each switch, check the actual path of a new connection; this is more useful than repeatedly toggling several settings. For help setting up a system proxy or TUN for the first time, see the proxy modes section in the user guide.