Clash's Three Proxy Modes

First, separate traffic entry from proxy mode

Use Rule mode for everyday traffic routing, switch to Global briefly for troubleshooting, and choose Direct when you need connections to go straight from your device. These modes determine how the Clash core selects an outbound route after a connection reaches it. They do not determine which apps can send traffic to the client in the first place.

For example, a browser can connect through the system proxy, or an app can be configured to use the local 127.0.0.1:7890 HTTP proxy. The core only handles the connection once it reaches it. TUN mode provides another way in, typically using a virtual network interface and routes to capture more traffic. The actual coverage still depends on the operating system, routing, exclusions, and permissions.

These explanations apply to common Clash configuration semantics and the Clash Meta (mihomo) core. Clients may label the setting “Proxy mode,” “Operation mode,” or simply “Mode,” but Rule, Global, and Direct typically correspond to the same set of mode values.

The mode Field: Comparing the Three Modes

At the top level of a configuration file, mode sits alongside fields such as mixed-port and rules; it should not be nested under dns or a policy group. Here is a common example. It shows only the mode and listening port, not a complete subscription configuration that can run on its own.

mixed-port: 7890
mode: rule
log-level: info

When you switch modes in the client, it usually changes the core's current runtime state through its control interface; it may not edit the subscription file itself. Whether your selection persists after reloading the configuration, restarting the client, or updating the subscription depends on the client's persistence and override behavior. To set a lasting default, check the client's override settings rather than editing a subscription copy that may be replaced on the next update.

Rule mode: first match wins

In Rule mode, the core checks connections against the rules list in order. The first matching rule determines the target, which can be DIRECT, REJECT, or the name of a policy group. Rule mode does not mean “proxy everything”; it lets different connections follow different routes.

A readable rules snippet

The snippet below assumes the configuration already has a policy group named “Proxy”. The name must exactly match the name in proxy-groups; these rule lines alone do not create a proxy node or policy group.

mode: rule

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - 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

• DOMAIN-SUFFIX,example.com matches the domain and its subdomains, provided the core can obtain the domain information associated with the connection.
• These three IP-CIDR rules cover common private IPv4 ranges and are useful for sending connections to local services through the direct outbound.
• no-resolve means the core will not trigger an extra DNS lookup just to check this IP rule; it does not mean the connection never needs DNS.
• The final MATCH catches connections that did not match any earlier rule and sends them to “Proxy.”

Rules are not automatically sorted with the most specific first. If you put MATCH,DIRECT on the first line, later domain rules will never get a chance to match. Likewise, a broad rule placed before a more specific one can prevent the latter from taking effect.

The policy group's selection still determines the final route

Matching the “Proxy” group is only the first step. If that group currently selects DIRECT, the connection still goes directly. If it selects another policy group, follow that reference to determine the final outbound. If a connection matches a proxy rule but does not use the expected node, check the matched rule, its target group, and the group's current selection—not just the mode button.

MATCH fallback: where unmatched connections go

MATCH needs no domain, IP, or port condition; it matches every connection that reaches that line. To keep the configuration easy to understand, it is usually placed at the end of the rules list. It is not a retry mechanism and will not switch to direct access automatically if a node cannot connect.

To send known local services direct and route everything else through a proxy group, use the structure shown above. To proxy only explicitly listed domains and send everything else direct, change the last line to MATCH,DIRECT. The difference is the default outbound, not Rule mode itself.

Global mode: useful for comparing outbound routes

When you set mode to global, connections handled by the core go to the built-in GLOBAL policy group instead of being routed one by one through the regular rules list. Check the current selection in the client's proxy view. Switching modes without checking the global group does not guarantee that traffic will use the node you expect.

The options available in the global group depend on the core and how the client presents them. If the current selection is DIRECT, connections may still go direct even when the interface says “Global.” Global describes how a single outbound is selected; it does not guarantee that a remote proxy will be used.

When Rule mode fails but Global mode works

1. Using the same destination address, start a new connection in Rule mode and note the matched rule, policy chain, and outbound shown on the connections page.
2. Switch to Global mode, explicitly select the same node in GLOBAL, then start a new connection.
3. If only Global mode works, first check rule order, whether the rule set loaded, and the selection in the policy group used by Rule mode.
4. If both modes fail, check the node status, local connection method, DNS, and destination service instead of continuing to adjust rules.

Global mode has its limits. LAN access may normally rely on direct rules, but those regular routing rules no longer determine the outbound after you switch modes. If a printer, NAS, or internal site stops working, switch back to Rule mode and check the access path rather than using Global as a permanent fix.

Direct mode: the client stays on

mode: direct sends connections handled by the core to their destinations through the DIRECT outbound. The client may still listen on local ports, receive system-proxy traffic, or run TUN; the core's DNS module may also continue resolving names. This is different from exiting the client, disabling the system proxy, or turning off TUN.

This distinction matters when troubleshooting. Direct mode lets you compare connections through a remote proxy with those made directly from your device, but it does not prove that the client has no effect on traffic. To test the operating system's usual network path, also disable the system proxy and TUN separately, and make sure the app does not specify a proxy address manually.

Three use cases for Direct mode

• Test a local service: Check whether the current network can reach the destination directly, then decide whether to add a direct rule.
• Compare nodes and routes: Start separate connections to the same address through Direct and a proxy outbound to compare reachability, rather than relying only on the speed test shown in the interface.
• Temporarily restore the default route: Keep the client running while temporarily sending connections handled by the core directly to their destinations.

Direct mode also bypasses the regular rules list, so REJECT rules in that list will not continue to block traffic. If you rely on those rules to restrict access, understand the behavior change before switching.

What to check: system proxy, TUN, and DNS

If switching modes seems to make no difference, troubleshoot in this order: traffic entry, mode, rules, then outbound. First confirm that the connection appears on the client's connections page, then check its match details. This narrows things down more effectively than repeatedly restarting the client.

1. Check the listening port: If the active mixed-port is 7890, the app should use the corresponding local proxy address. If the port has changed to 7891 but the app still points to 7890, the connection may fail or reach a different process.
2. Check the active mode: Verify the selected option in the client's mode menu rather than relying only on the mode value in the file on disk. The interface may have changed the runtime state.
3. Check the policy chain: In Rule mode, check the matched rule and policy group; in Global mode, check GLOBAL; in Direct mode, confirm the DIRECT outbound is being used.
4. Start a new connection: A mode switch usually affects new connections. Existing downloads, video streams, and long-lived connections may not move immediately. Close and reopen the test page, or, if needed, end only the relevant connection.
5. Check DNS separately: Switching modes does not automatically rewrite all DNS settings. An app's encrypted DNS, the system cache, core DNS, and DNS handling by TUN can all affect the address ultimately returned.

Choosing a mode and restoring your settings

For a client with subscriptions, policy groups, and rules set up, Rule mode is usually the best everyday default. It can preserve direct LAN access, proxy selected sites, and apply necessary reject rules. Global mode is useful for briefly testing an outbound route; Direct mode helps compare the local network path.

• Everyday use: Choose Rule mode and make sure the final MATCH points to the target that suits your needs.
• Routing issues: Switch to Global briefly and explicitly select a node for comparison. Once you confirm the difference, return to the rules list to find the cause.
• Test the baseline network: Start with Direct mode. If you still need to rule out traffic capture, disable the system proxy and TUN and test again.
• When testing is done: Restore the original mode and policy group selection, then check LAN services and frequently used sites so temporary settings are not left in place.

Keep two separate questions in mind to avoid confusion: the system proxy or TUN determines how a connection enters the client; mode determines how the outbound is selected once it gets there. In Rule mode, remember to check that rules are evaluated from top to bottom and that MATCH is the final fallback. This explains most mode-switching and routing behavior.