When using Clash for the first time, or a client built on the Clash Meta (mihomo) core, the interface options “Rule,” “Global,” and “Direct” can be confusing. They are not three different subscriptions or independent proxy servers. They are runtime modes that determine how connections are routed. After you switch modes, the client may handle domains, IP addresses, and application connections through different paths, so the same website can behave differently in each mode.
The key to understanding these options is not memorizing where a button appears, but separating three layers: whether the client receives the traffic, how the traffic is matched against rules once it arrives, and whether the result is sent through a proxy or the local network. This guide focuses on the workflow most common in desktop clients, explaining how each mode works, when to use it for testing, and how to troubleshoot connection problems in a systematic order.
1. What the three modes actually change
A Clash configuration typically includes proxy nodes, proxy groups, rules, and rule providers. After the core starts, the client listens on the HTTP, SOCKS, mixed, or other proxy ports specified in the configuration. Applications that support the system proxy can send requests to these ports. For programs that do not use the system proxy, enabling TUN may also capture some traffic that would not normally use proxy ports, provided the required system permissions, routes, and DNS settings are in place.
Once traffic reaches the core, the selected mode determines how it is processed. Rule mode checks the rules in the configuration file one by one, in order. The matching policy may be a proxy group, DIRECT, REJECT, or another policy. Global mode bypasses ordinary domain and IP rules and sends capturable connections to the currently selected global proxy group. Direct mode sends connections through the local network, typically using DIRECT. Keep in mind that a mode only affects traffic within Clash’s handling scope. If an application is not using the system proxy, TUN has not captured the traffic successfully, or the client is not running, switching modes will not change those connections.
Rule mode: let the configuration decide where connections go
Rule mode is the everyday choice for most users. The configuration determines where connections go based on conditions such as domain suffixes, full domain names, geographic databases, IP addresses, processes, or rule sets. For example, rules can send local-network addresses and services in mainland China through DIRECT, route selected domains to a proxy group, and use MATCH as the final fallback. The actual behavior depends on the current configuration, not the label of the button in the client.
Rules are ordered. Rules near the top get the first chance to handle a connection; later rules only process connections that have not matched yet. As a result, a broad domain rule placed too early can prevent a more specific rule below it from taking effect. If a site does not use the proxy as expected in Rule mode, check the connection details and the matched rule before repeatedly switching modes.
Global mode: send everything to the selected proxy group
Global mode is designed to reduce rule-related variables. After switching to Global, the client typically uses the global proxy or proxy group selected in the interface to handle connections. Names vary slightly between clients: some call it “Global Proxy,” while others show the current proxy group. The underlying idea is the same—concentrate the traffic path around one explicit proxy choice.
Global mode does not mean that 100% of all system traffic automatically enters the proxy. It still depends on the system proxy, the client’s capture scope, the application protocol, and the state of TUN. Results are usually easy to interpret when a browser is using the system proxy. Games, command-line tools, virtual machines, and system services that ignore the system proxy may still require TUN, an application-level proxy setting, or an additional routing solution.
Direct mode: send connections through the local network
Direct mode sends connections within Clash’s handling scope to their destinations through the DIRECT path, without using a proxy node. It is useful for checking local DNS, broadband, corporate networks, routers, and the application itself. It can also restore access to ordinary local services when proxy nodes are temporarily unavailable.
Direct mode does not mean “Clash is turned off.” The client may continue running, and the system proxy or TUN may remain enabled; the core simply chooses the local exit for the connections it receives. To remove client capture from the test entirely, confirm the current configuration and operating state, then disable the system proxy or stop the relevant capture feature before running a comparison.
2. Which mode should you use day to day?
For a subscription configuration with working rules, Rule mode is usually the best long-term choice. It can send different types of traffic through a proxy, directly over the local network, or to other policy groups, reducing the need for manual switching. For example, frequently used sites in mainland China can keep lower latency through a direct connection, selected domains outside China can use a proxy group, and local-network devices can remain reachable through local addresses. The convenience of Rule mode depends on configuration quality: rule-set update times, policy-group names, DNS behavior, and fallback rules all affect the final result.
Global mode works more like a diagnostic tool, and it is useful when you temporarily want a browser or a specific application to use one node consistently. For a test, select a known-working node or proxy group, switch to Global, open the target site, and inspect the connection details. If the site works in Global but not in Rule mode, the problem is often rule matching, proxy-group selection, or an outdated rule set rather than the node itself.
Direct mode is useful as a reverse comparison. If a site does not open in Rule mode, switch to Direct and visit the same address to help distinguish a local network problem from a proxy-path problem. If Direct works but Global does not, check the node, proxy group, remote DNS, or proxy protocol. If neither Direct nor Global works, continue checking DNS resolution, network connectivity, application status, and the target service itself.
| Mode | How it handles traffic | Best suited for |
|---|---|---|
| Rule | Match rules in order, then apply the corresponding policy | Everyday use, site-based routing, and mixed local-network and proxy access |
| Global | Send capturable connections to the current proxy group | Verifying a node, temporarily routing everything through a proxy, and removing rule variables |
| Direct | Access destinations through the local network for capturable connections | Checking the local network, comparing proxy failures, and accessing local services |
3. Locate access problems with a three-step comparison
When a webpage will not open, an application times out, or a login API behaves unexpectedly, keep the test target and conditions consistent. Do not change the node, DNS, mode, and browser at the same time. Otherwise, even if the result changes, it will be difficult to tell which setting caused the difference.
- Test Direct first. Keep the destination, browser, and network environment unchanged, then switch to Direct mode. Confirm that the domain resolves, check whether the page can establish a connection, and record the browser error. If Direct also fails, address the local network, DNS, system time, or target-service problem first.
- Test Global next. Select a proxy node or proxy group with a healthy status, then switch to Global mode. Check whether the target domain appears in the client’s connection list, and inspect the policy, outbound type, and error details used by the connection. If the connection does not appear in the list, focus on the system proxy or the TUN capture scope.
- Return to Rule mode last. Revisit the same destination in Rule mode, open the connection details, and check the matched rule. If it matches DIRECT, the rules assigned it to a direct connection. If it matches a proxy group, check that group’s current selection and node latency. If it matches MATCH, inspect where the fallback policy actually points.
This order introduces variables gradually: Direct confirms the basic network, Global confirms the proxy path, and Rule confirms the routing logic. For command-line tools, run a separate test with the proxy arguments or environment variables supported by the application. For browsers, confirm that the system proxy is actually taking effect. Also watch for browser cache, connection reuse, and DNS cache; close and reopen the page when necessary.
4. Common misreadings in Rule mode
A DIRECT match does not mean the rules are broken
DIRECT is an explicit outbound choice. Many configurations intentionally send local-network domains, local-network IPs, sites in mainland China, or specific services through a direct connection. When the connection details show DIRECT, compare the result with the intended configuration first. If the domain is supposed to connect directly, the result is normal. If it should use a proxy, check whether an earlier rule matched it or whether the rule set is outdated.
A proxy-group match does not guarantee that the node works
Rules only hand a connection to a policy. A policy group may contain multiple nodes, an automatic-selection group, a failover group, or a chained proxy group. Global mode likewise requires selecting a specific node or confirming the proxy group’s current choice. A successful latency test does not mean every target protocol is reachable, because latency checks and actual HTTPS, WebSocket, or UDP traffic may use different paths.
Domain rules and IP rules can produce different results
Some requests begin with a domain, while other connections appear as IP destinations after resolution. Domain rules, GeoIP rules, logical rules, and DNS modes can all affect the match. When a service behaves differently in its website, desktop app, and API, compare each connection’s destination domain, destination IP, port, and matched rule instead of relying only on the browser address bar.
5. How TUN mode relates to the three proxy modes
TUN is a system-level traffic-capture method. The client creates a virtual network interface and passes eligible network traffic to the core. It answers “which traffic can enter Clash,” while Rule, Global, and Direct answer “which exit should that traffic use afterward.” These are separate layers: enabling TUN does not automatically send every connection through a proxy, and switching to Global cannot replace the permissions, routing, or DNS configuration required by TUN.
If a browser works in Rule mode but an application that ignores the system proxy has no connection records at all, consider whether the application needs TUN to be captured. Before enabling TUN, confirm that the client has the required system permissions and avoid conflicts with other VPNs, virtual network adapters, enterprise security software, or network-acceleration tools. TUN DNS handling, automatic routing, LAN bypass, and IPv6 behavior can also affect the result. Change one option at a time and keep the original settings available for comparison.
Even with TUN enabled, Direct mode may still reach the destination through the local network, Global mode still requires a working proxy node, and Rule mode still processes connections in configuration order. If the entire network becomes unstable after enabling TUN, first switch to Direct and observe the connections, then temporarily disable TUN for comparison. If service returns after disabling it, narrow the investigation to the virtual interface, routes, DNS, and conflicts with other network software.
6. Checklist before and after switching modes
- Confirm that the client is using the intended configuration file, not one that was just imported but has not been activated.
- Confirm that the subscription updates normally, the policy groups still exist, and the node list is not empty.
- Record the current system proxy ports. Some programs support only HTTP proxies, while others support SOCKS, so use the corresponding port.
- Confirm that the system proxy toggle matches the client’s running state, so the browser is not still connecting to an old port.
- Check whether another VPN, proxy application, network filter, or virtual network adapter tool is running at the same time.
- Use the same domain and application for every test, and record the connection details in Direct, Global, and Rule modes.
- After returning to Rule mode, confirm which proxy the group is actually using. The latency results from an automatic-selection group do not replace a test against the target site.
After troubleshooting, everyday configurations should usually return to Rule mode. Add sites that clearly require a proxy to the appropriate rules or rule sets, and keep local networks and services on direct connections. Use Global mode long term only for diagnostics or temporary needs. This preserves controllable traffic splitting and avoids sending services that do not need a proxy through remote nodes, reducing uncertainty in the access path and the scope of failures.
7. Conclusion: identify the problem before choosing a mode
There is no universally “best” choice among Rule, Global, and Direct. Rule mode means “route traffic according to the configuration.” Global mode means “use the current proxy consistently within the capture scope.” Direct mode means “return to the local network within the capture scope.” When something goes wrong, compare Direct, Global, and Rule in that order, using connection records and matched rules to interpret the results. This is usually faster than repeatedly clicking through mode buttons.
For stable everyday use, start with a clearly structured configuration, confirm that the subscription and policy groups update normally, then check whether the system proxy or TUN covers the target application. Once this approach becomes familiar, switching modes is no longer guesswork; it becomes a repeatable network troubleshooting procedure.