Start with Rule mode, then confirm traffic is reaching the core
For everyday use, start with Rule mode (Rule). Make sure your subscription is enabled and the intended proxy group has a node selected, then visit the site you want to test. If just one site is having trouble, briefly switch to Global mode for comparison. To check whether your current network can reach a destination directly, switch to Direct mode. Change one setting at a time so the results are easy to interpret.
These three modes determine how connections that have already reached the Clash or Clash Meta (mihomo) core are routed; they do not determine which applications are intercepted. System proxy settings, in-app proxy settings, and TUN route traffic into the core. Rule, Global, and Direct determine how traffic that reaches it is handled. Treat these as two separate layers.
| Mode | How the core handles traffic | Best for | Check first |
|---|---|---|---|
| Rule | Checks rules in order and sends traffic to the matching outbound or proxy group | Everyday traffic routing and separating direct from proxied connections | Matched rule and actual proxy group selection |
| Global | Usually sends traffic to the built-in GLOBAL proxy group | Temporarily troubleshooting missed rules or testing a single outbound route | The outbound selected in GLOBAL |
| Direct | The core connects directly to the destination | Comparing with your local network and ruling out proxy nodes | Local DNS and network reachability |
How traffic flows in the three modes: the same entry point, different routing decisions
The diagrams below follow the same connection from an intercepted application. “Proxy Select” is an example proxy group name, not a standard name found in every subscription. Your configuration may use names such as “Select Node,” “Auto Select,” or something else.
Rule mode: rules are checked top to bottom; the first match wins
Application connection
↓ System proxy / app proxy / TUN
Clash or mihomo core
↓ Check rules from top to bottom
├─ Matches a direct rule → DIRECT → destination
├─ Matches a proxy rule → Proxy Select → current node → destination
├─ Matches a reject rule → REJECT → connection terminated
└─ Reaches the MATCH fallback → specified policy → destination
Rules do not automatically prioritize the most specific match. They are usually checked from top to bottom, and the first match takes effect. If a broad rule appears near the top, more specific domain rules below it may never be reached. Rule sets in a subscription must also be considered in relation to where they are referenced in the rules list.
Global mode: bypasses normal rule-based routing
Application connection
↓ Intercepted
Clash or mihomo core
↓ Global mode
GLOBAL proxy group
↓ Currently selected node or another available outbound
Destination
After switching to Global, check GLOBAL on the Proxies page. Global does not mean “automatically choose the fastest node,” nor does it guarantee that traffic exits through a proxy node. If GLOBAL is set to DIRECT, or the selected nested proxy group ultimately routes directly, the connection still goes out directly. Some clients display a localized name for this group.
Direct mode: traffic can still pass through the core, but not through a proxy node
Application connection
↓ Intercepted
Clash or mihomo core
↓ Direct mode
DIRECT
↓ Network route available to the device
Destination
Direct mode does not mean quitting the client or turning off TUN. The core may still handle connections and DNS requests; only the outbound route changes to direct. So a successful direct connection shows that it can reach the destination directly with the current interception and DNS setup. It does not, by itself, prove that the system proxy, DNS, and routing have all returned to their pre-client state.
How rules and proxy groups work together: a minimal example
This YAML snippet illustrates rule matching order; it is not a complete subscription. “Proxy Select” must already be defined under proxy-groups. example.com and its subdomains demonstrate the syntax and do not imply that any particular service must use a proxy.
mode: rule
mixed-port: 7890
rules:
- DOMAIN-SUFFIX,example.com,Proxy Select
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- MATCH,Proxy Select
mode: rule: Handles traffic according to rules by default. A mode change in the client UI may override this value; after reloading the configuration, behavior depends on whether the client saves the mode override.mixed-port: 7890: Accepts HTTP and SOCKS5 proxy connections on the same port. 7890 is just an example, not a default port for every client.DOMAIN-SUFFIX: Matches the specified domain and its subdomains. Matching traffic goes to “Proxy Select,” where the proxy group determines the actual node.IP-CIDR: Matches traffic by destination IP range. The two common private network ranges shown here are examples, not a complete set of LAN direct-routing rules.no-resolve: Prevents DNS resolution solely for matching this IP rule; it does not mean the connection as a whole requires no DNS.MATCH: Acts as the final fallback. If placed earlier, it prevents subsequent rules from being matched.
After switching to Global or Direct, traffic is generally no longer routed by checking each entry in the regular rules list. So having a direct rule for a private network does not mean Global mode will follow that same rule. For local printers, router admin pages, and corporate intranet services, Rule mode is usually easier to control day to day.
When to switch to Global temporarily—and when to go back to Rule
A single site won't load: use Global for comparison
- In the client's Proxy Mode section, confirm that Rule is selected. Some clients put this option under Proxy Mode in the system tray menu; labels vary by client.
- Open the Connections page, visit the target site, and note its domain, matched rule, and final proxy chain.
- Switch to Global and select a known-working node in GLOBAL. If possible, use the same node you used in Rule mode so you change only one variable.
- Close the site's existing connections, then visit it again. If needed, disconnect only the connections for that domain; you don't have to disconnect every app right away.
- If Global works but Rule does not, switch back to Rule and check whether the domain is matching DIRECT by mistake, a rule set is missing, or the fallback points to a different proxy group.
This comparison is not conclusive on its own. Even with the same node, the two modes may be affected by configuration settings such as mode-specific DNS behavior. If DNS results change when you switch modes, include DNS in your troubleshooting rather than assuming the rules are the only issue.
Testing a single outbound route: use Global briefly
Global can reduce interference from rule-based routing when you want to check a proxy node's exit location or see whether a service is reachable through that node. During the test, though, other intercepted apps may use the same outbound route, including system updates and cloud drive sync. Keep background downloads in mind, especially with metered subscriptions.
Everyday browsing and local services: switch back to Rule
When you're done testing, switch back to Rule and check your usual proxy groups. Send domains that need a proxy through one, and route locally accessible services through DIRECT to avoid unnecessary detours. Global isn't a more advanced mode than Rule; it simply skips normal rule selection and is better suited to short-term comparisons.
System proxy, TUN, and DNS: what mode switching can't fix
If an app's traffic doesn't reach the core, Global can't intercept it
After enabling System Proxy in a desktop client, some apps follow the system settings, while others use their own network configuration. Command-line programs may also depend on environment variables. Once you've confirmed that the local mixed port is 7890, you can explicitly specify the proxy endpoint with the command below to avoid uncertainty around system proxy settings:
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/
In Windows PowerShell, start the command with curl.exe if you want to explicitly run the curl program provided by the system. Also check the client's connection log while it runs: if the request appears, it reached that proxy endpoint. An HTTP response alone does not prove that the request used a remote node; check the final proxy chain too. The 10-second value is the connection timeout, and 20 seconds is the overall time limit—not a latency result.
TUN uses a virtual network interface and routing to intercept more IP traffic, but coverage still depends on routes, exclusions, permissions, and the specific implementation. Enabling TUN does not automatically give a node UDP support or fix an unreachable node. If you need to intercept apps that ignore the system proxy, follow your client's guide to check TUN permissions and routing.
Switching modes does not clear DNS state
With Fake-IP, the core may return a virtual address to an app to map it to a domain, then use that mapping to identify the actual domain. This does not mean the connection was sent to a public IP address. DNS upstreams, Fake-IP filters, encrypted DNS in the app, and local caches can all affect troubleshooting.
If a site still won't load after switching to Global, don't immediately change DNS, TUN, and your subscription all at once. First check whether the connection appears, then inspect the domain and proxy chain, and finally check DNS results and node connection errors. Changing several layers at once can turn a reproducible problem into an intermittent one.
Nothing changed after switching modes? Check the connection log step by step
| What you see | Check first | What to do |
|---|---|---|
| Exit IP unchanged after switching to Global | An old connection is still in use, or GLOBAL is set to DIRECT | Check GLOBAL, disconnect the target connection, and send the request again |
| Browser works, game doesn't | The game ignores the system proxy, or the required UDP traffic isn't supported | First check whether the game's connections reach the core, then verify TUN and node support |
| Rule mode fails, Global works | The matched rule and final proxy policy differ | Use the same node for comparison; check rule order, rule sets, and the fallback |
| Direct works, Global fails | The selected node is unavailable, or the destination rejects that outbound route | Check for handshake or timeout errors, then try again with a working node |
| All three modes fail | The proxy entry port, DNS, network, or destination service is having an issue | First verify the local proxy endpoint and connection log, then troubleshoot each layer |
Mode changes usually affect new connections and do not guarantee that existing long-lived TCP connections or QUIC sessions will switch routes immediately. A page refresh may reuse an existing connection too. If the log still shows the old policy, close the relevant connection before sending a new request. Active downloads, calls, or remote sessions may be interrupted, so check the impact before proceeding.
Finish by checking three things: Did the connection reach the core? Which outbound route did it take? Did the new connection use the expected mode? Once you know, decide whether to fix a rule, change how traffic is intercepted, or switch nodes. Keeping Rule mode for everyday use and briefly using Global or Direct for troubleshooting is usually more effective than repeatedly reinstalling the client.