Clash Proxy Modes Explained: Rule, Global, and Direct Routing

Three modes, three ways to route traffic entering the core

Use Rule mode for everyday traffic. Switch briefly to Global mode to troubleshoot routing for a site, or use Direct mode to check whether your local network can reach it without a proxy. These are not speed settings; they determine how Clash or Clash Meta (mihomo) routes connections it has taken over.

First, separate two steps: System Proxy and TUN get traffic into the core; Rule, Global, and Direct determine what happens next. Switching to Global mode alone will not route a game through the proxy if it ignores the system proxy. Enabling TUN does not mean every connection will use a remote node.

Rule mode: first match wins—not the most specific rule

In Rule mode, the core matches against information available for each connection, such as the destination domain, destination IP, port, and—depending on platform support—process details. Once a rule matches, its policy is used; the core does not keep looking for a “more specific” match.

Start with an ordered rule list

This snippet illustrates rule order; it is not a complete subscription. The Web-Proxy policy group must already exist in your configuration. example.com is a sample domain—replace it with the domain you want to route.

mode: rule

rules:
  - DOMAIN,account.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,Web-Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,Web-Proxy

• account.example.com matches rule 1 and uses Direct.
• docs.example.com does not match rule 1, but it matches rule 2 and is routed through “Web-Proxy.”
• A connection to 192.168.1.20 matches rule 3, which is commonly used to reach devices on a local network.
• Connections that match none of the earlier rules fall through to the final MATCH rule and are routed through “Web-Proxy.”

If rule 2 comes before rule 1, the suffix rule will also catch the account domain, leaving rule 1 unable to handle it. Put narrow exceptions—such as account and work-system domains—before broader domain rules, and keep the fallback MATCH rule at the end.

A rule can target a policy group, not just a node

DIRECT sends traffic directly, while REJECT blocks the connection. Names like “Web-Proxy” usually refer to policy groups. A group may point to another group before traffic reaches a specific node or goes direct. If the log shows a group was matched, check its current selection too; that alone does not confirm that a remote node was used.

no-resolve prevents this IP rule from actively triggering a DNS lookup. If the connection already has a usable destination IP, it can still match the IP rule. If only the domain is available and there is no IP, the rule cannot obtain a match by resolving it. This does not “disable DNS for the entire configuration.”

Global and Direct modes: useful for comparison, not traffic-capture switches

In Global mode, check what GLOBAL actually selects

After switching to Global mode, open the client’s proxy or policy-group page and check what GLOBAL currently selects. If it selects DIRECT, traffic still goes direct. If it selects another group, check which node that group ultimately uses. Global mode cannot fix a dead node or add UDP support that the node does not provide.

A useful comparison: keep the same node selected, switch from Rule to Global mode, then open a new connection to the site that is failing. If Global works but Rule does not, check the matched rule and the group’s selection first. If neither works, investigate the node, DNS, traffic capture, and destination service. This narrows down the problem; a single test does not prove its cause.

Direct mode can still leave the local proxy listener active

In Direct mode, a browser can continue sending requests to the local proxy port, after which the core connects directly to the destination. This is not the same as “turning off the system proxy,” “disabling TUN,” or “exiting the client”: the local listener, DNS settings, and traffic capture may still be active.

To stop proxy capture completely, first turn off System Proxy or TUN in the client, then exit the app. Otherwise, the system may still point to a local port that is no longer listening, leaving the browser offline when the client exits. Be clear about whether you are testing “direct routing through the core” or “system networking that bypasses the core.”

System Proxy and TUN: first check whether traffic enters the core

System Proxy is mainly for apps that follow the operating system’s proxy settings. Browsers usually do, but games, apps with their own network stacks, and some command-line tools may not. TUN uses a virtual network interface to capture IP traffic that meets its routing criteria, covering more apps but remaining subject to route exclusions, other VPNs, permissions, and DNS settings.

1. Check the capture method first: In the client, check whether System Proxy or TUN is enabled. Menu names vary between clients; do not assume that selecting Rule mode enables the system proxy.
2. Then open a new connection: Visit a test site or reconnect to a game server while checking the client’s Connections page. Seeing the destination there is strong evidence that the traffic entered the core.
3. Finally, check the outbound route: Review the matched rule, policy group, and final outbound. A latency number in the node list only reflects that particular test; it does not prove that your browser is using that node.

Choosing a mode for browsing, gaming, and work

Node latency tests do not tell the whole story for games

A client’s latency test usually probes the test address specified in its configuration; it is not the same as the round-trip time to a game server. Even if the test succeeds, a game can still fail because UDP is unsupported, the server is in the wrong region, or the traffic never entered the core. Check the actual game connection and in-game network stats. Global mode is not a game-boost button.

Direct access to work resources depends on domains and DNS

Intranet services may use domains that resolve only within your organization. Adding a DOMAIN-SUFFIX rule for Direct does not guarantee that a public DNS server can resolve the domain. Use the DNS and VPN setup provided by your organization. If the domain is already failing to resolve, changing node selection is unlikely to help.

Verify that the mode is working with the proxy port and connection logs

The example below uses 127.0.0.1:7890 to test an explicit proxy. Port 7890 is an example, not a universal client default. Check the active configuration or the client’s port settings for the HTTP or mixed proxy port, then update the command. If the client only provides a SOCKS port, do not use the HTTP proxy syntax shown here.

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

Run the command above in Terminal on macOS or Linux. In Windows PowerShell, change the command to start with curl.exe to avoid a same-name alias interpreting the arguments differently. The connection timeout is capped at 10 seconds and the total request at 20 seconds. These are test settings, not guarantees of node performance.

1. Select Rule mode, run the command once, then find the example.com connection in the logs and note the matched rule and final outbound route.
2. Switch to Global mode, confirm that GLOBAL selects the intended node, run the command again, and compare the outbound route.
3. Switch to Direct mode, run the command again, and check whether it goes out through DIRECT.
4. After comparing the results, switch back to Rule mode and fix any incorrect rules in your persistent configuration instead of relying on Global mode long-term.

An explicit proxy test confirms that “this request entered the core through the specified local port.” It does not prove that System Proxy or TUN covers other apps. An HTTP response from the destination means the request reached a system that could respond, but use the connection logs to verify the outbound route. Some services reject HEAD requests, so a response status code alone does not prove the node is faulty.

Common misdiagnoses and how to recover

A page looks unchanged after switching modes

Mode changes usually affect new connections. Browsers may reuse HTTP/2, HTTP/3, or other persistent connections, so an existing connection may not switch routes immediately. Close the relevant page and make a new request; if needed, close the connection from the client’s Connections page. Do not repeatedly refresh over the same reused connection and conclude that the mode switch had no effect.

Rules revert after a subscription update

Direct edits to a configuration generated from a subscription download may be overwritten by the next update. Prefer the client’s override, merge, or persistent-rule feature, and check where the new rule is inserted. If it is placed after MATCH, the configuration may load successfully, but the rule cannot handle connections already caught by the fallback.

Global works, but Rule mode routes traffic directly

Check which rule the connection actually matched before deleting all your rules. Common causes include a broad suffix rule matching the domain first, the policy group currently selecting DIRECT, or a rule set covering a different range than expected. Move any necessary narrow exceptions ahead of the relevant broad rules, then retest with a new connection.

Once your everyday setup is ready, Rule mode is usually the most flexible option for handling local services, LAN traffic, and remote proxy needs. For full import and traffic-capture instructions, read the Getting Started guide. To check configuration structure and rule settings, see the full documentation.