Use Rule mode day to day; switch to Global or Direct for troubleshooting

For everyday browsing, use Rule mode: traffic that needs a proxy goes through the selected proxy policy group, while other traffic connects directly according to your configuration. If a site won’t load, briefly switch to Global mode to see whether the routing rules are the cause. Use Direct mode to check whether your local network can reach the site without a proxy. These modes determine how connections are routed—not three speed settings or levels of encryption.

This guide applies to clients that use Clash configuration syntax, including clients built on the Clash Meta (now mihomo) core. The interface typically labels the modes “Rule / Global / Direct”. In the configuration file, the corresponding values are mode: rule, mode: global, and mode: direct.

How the three proxy modes route traffic

Mode How traffic is handled by the core Typical use What to check
Rule Matches rules in rules order and applies the selected policy Everyday split routing, direct access to local networks, and different routes for different services Matched rule, current policy group selection, fallback rule
Global Usually routes all traffic through the built-in GLOBAL group Temporarily testing proxy access or diagnosing a rule mismatch The node or policy currently selected in GLOBAL
Direct Connects to the destination over your local network, without a remote proxy node Testing local network access or checking whether a proxy node is affecting connectivity Local network, destination reachability, DNS resolution

“Global” applies to traffic that has already entered the core. If a game ignores the system proxy, switching to Global does not automatically route its connections through a proxy node. The Global group can also be set to DIRECT; in that case, traffic may still go direct even when the interface shows Global. Check both the mode and the selected route—don’t rely on the mode label alone.

Rule mode: match a rule, then apply its policy

Rules are matched from top to bottom

Rule mode doesn’t guess how to route traffic based on a website’s name. It follows the rules in the active configuration. A connection is typically handled as soon as it matches an applicable rule; later rules aren’t checked for a “better” match. Putting a broad rule too early can prevent a more specific domain rule from matching.

The snippets below can be added to an existing configuration; they are not a complete subscription. Replace Proxy Selection with the name of a policy group that actually exists in your configuration. example.com is a sample domain used to illustrate the syntax; adjust it to suit your needs.

mode: rule
mixed-port: 7890

rules:
  - DOMAIN-SUFFIX,example.com,Proxy Selection
  - 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,example.com matches the domain and its subdomains—not any domain that happens to contain this text.
  • These three IP-CIDR rules cover common private IPv4 address ranges and are useful for showing how to route local network traffic directly. Whether a rule matches still depends on the destination address information available for the connection.
  • no-resolve means the IP rule won’t trigger an extra domain lookup. It does not mean the connection never needs DNS.
  • MATCH is a fallback rule and belongs at the end. This example sends unmatched connections to a proxy group, but you can use DIRECT instead if that suits your needs.

A policy group isn’t a fixed proxy node

When a rule matches “Proxy Selection,” check what’s selected inside that group. If it’s a manual select group, it may point to a node, another policy group, or even DIRECT. So a rule matching a proxy group doesn’t necessarily mean traffic is using a remote node.

In the client’s “Connections” page, find the request you just made and check its destination domain, matched rule, and proxy chain. If the rule is correct but the proxy chain goes direct, check the policy group selection first instead of adding duplicate rules.

Global mode: useful for comparisons, but not a substitute for capturing traffic

Global mode usually bypasses routing decisions in the regular rules list and sends connections that enter the core to GLOBAL. After switching, open the client’s proxy selection page and confirm that the Global group points to a working node. Some clients display the Global group in a separate section, and its selection may not sync with the policy groups you normally use in Rule mode.

  1. Note which sites fail in Rule mode and when. Avoid changing DNS, nodes, and configuration at the same time.
  2. Under “Mode,” select “Global,” then choose a specific node for GLOBAL.
  3. Close the site’s existing connections, then revisit the same URL.
  4. If Global works but Rule doesn’t, switch back to Rule mode and check the connection’s matched rule and actual route.

This comparison can narrow down the cause, but it can’t prove on its own that a rule is wrong. If the two modes use different nodes, the results may differ because of their exit routes. For a more reliable comparison, point both the Global group and the policy group matched in Rule mode to the same node.

Direct mode: bypasses proxy nodes, but doesn’t turn off the client

Direct mode routes connections that have entered the core through your local network. It answers a specific question: can this destination be reached without a remote proxy node? If Direct works but a selected node doesn’t, check the node, its remote exit, or support for the relevant protocol. Don’t take a successful direct connection as proof that the rest of your configuration is correct.

After you switch to Direct, the client can still accept connections, the system proxy may still point to a local port, and the TUN virtual adapter may remain active. Whether built-in DNS, Fake-IP mappings, and other components are used for resolution depends on your DNS and traffic capture settings. So Direct mode doesn’t fully reproduce a network environment where the client was never running.

How to test your local network without the client’s routing

  1. Switch to Direct and test the same destination.
  2. To isolate the client’s effect further, turn off the system proxy or TUN and make sure no other proxy tool is capturing traffic.
  3. Start a new connection. If needed, close and reopen the browser to avoid reusing an existing connection.
  4. Compare the results, then restore your original traffic capture settings and Rule mode.

Don’t exit the client listening on 127.0.0.1:7890 while your system proxy still points to it. Apps that follow the system proxy settings may lose their connection. Port 7890 is just a common example; check the HTTP or Mixed listening port under “Settings” in your client.

Mode changes have no effect: check each step in the connection path

Step 1: Confirm the request reaches the core

Open “Connections” and visit a new page. If you don’t see a corresponding connection, first check whether the system proxy is enabled, whether the app has its own proxy settings, and whether a browser extension overrides the system settings. On Windows 11, go to Settings → Network & internet → Proxy. On macOS, go to System Settings → Network → select your network service → Details → Proxies.

The system proxy is mainly for apps that follow proxy settings; it does not capture all system traffic. If you need to capture traffic from more apps, consider TUN. TUN also involves routing, permissions, and DNS settings, so don’t change everything just to test one webpage.

Step 2: Use an explicit proxy request to rule out system settings

If your current configuration is listening on local Mixed port 7890, use the commands below for comparison. On Windows, use curl.exe to avoid PowerShell environments that interpret curl as a different command. On macOS and Linux, use curl as usual.

# Windows: use the local HTTP proxy explicitly
curl.exe --noproxy "" -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/

# Windows: bypass the proxy
curl.exe --noproxy "*" -I --connect-timeout 10 --max-time 20 https://example.com/

# macOS / Linux: use the local HTTP proxy explicitly
curl --noproxy "" -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/

These commands set the connection timeout to 10 seconds and the total time limit to 20 seconds to avoid waiting too long; they are not performance benchmarks. To diagnose a specific issue, replace the sample URL with the actual destination. The direct command only bypasses curl’s proxy setting. If TUN is still enabled, the underlying connection may still be captured, so this doesn’t prove that traffic bypassed the client entirely.

Step 3: Check existing connections, DNS, and configuration overrides

  • Reused connections: A mode change usually affects new connections; existing HTTP/2, WebSocket, or download connections may keep using their current route. Close the connection to the destination and try again. You don’t need to restart the whole device as a first step.
  • DNS failures: If the logs show a DNS timeout, first check whether the resolver is reachable. Switching to Global won’t automatically fix DNS, and Fake-IP mode doesn’t mean the real domain name never needs to be resolved.
  • Configuration not applied: Make sure the active subscription configuration is selected and reloaded after your changes. Client overrides, merges, or scripts may alter the final mode and rules.
  • Connection refused: If the connection details show REJECT, check why the rule matched. If a connection to a local port is refused, first confirm that the core is running and the port number is correct.

For more troubleshooting, see Troubleshooting. Record the destination domain, mode, actual route, error message, and time to make the problem easier to reproduce than simply saying “switching modes did nothing.” Before sharing screenshots, hide subscription URLs, node credentials, and personal connection details.

Common questions and everyday setup tips

Is Global mode always faster than Rule mode?

No. Speed and latency mainly depend on your local network, proxy route, destination service, and congestion. Global mode may also send connections that would work better directly through a remote node. To compare speeds, keep the destination, node, and test conditions the same—mode names alone don’t tell you which is faster.

Do I still need Rule mode if TUN is enabled?

Choose a mode based on your routing needs. TUN captures traffic; Rule mode determines how connections are routed. You can use them together: after TUN sends a connection to the core, rules can route it directly, through a proxy, or reject it. Switching to Global changes the route selection that follows.

Can updating a subscription change the mode or selected node?

It depends on how the client preserves interface state, loads configuration, and applies overrides. After an update, check the current mode, whether the policy groups still exist, and whether the selected node is still available. For custom routing you need to keep, use the client’s supported override or merge mechanism. Direct edits to generated subscription files may be replaced during an update.

For everyday use, keep “Rule mode + an explicit policy group selection.” When something goes wrong, check traffic capture, the matched rule, the exit node, and DNS in that order. Change one variable at a time and restore your settings after testing. For more on policy groups, Fake-IP, and TUN, see the glossary. If you’re setting things up for the first time, start with the Getting Started guide.