How Traffic Flows Differently Across the Three Modes
Clash and its derivative core Clash Meta (mihomo) typically offer three operating modes in client settings: Rule mode, Global mode, and Direct mode. These three modes don't determine the nodes themselves — they determine "what evaluation happens after a network request is sent, and where it goes next." Understanding this evaluation logic matters more than just memorizing the mode names.
- Rule mode: Each request is matched against the
ruleslist in the config file one by one, based on domain names, IP ranges, GEOIP location, and other conditions, routing traffic to the corresponding proxy group or direct connection. Requests that don't match any rule fall through to the default policy at the end of the rules list (usuallyMATCHorFINAL). - Global mode: Skips rule matching entirely. All traffic (regardless of domain or IP) is uniformly routed to the currently selected proxy group or node — outbound behavior is highly consistent but lacks differentiation.
- Direct mode: Skips the proxy entirely. All traffic goes directly out through the local network, effectively equivalent to temporarily disabling the proxy.
The key difference between these three lies in "whether an evaluation step exists" and, if it does, "how granular that evaluation is." Rule mode retains fine-grained evaluation; both global mode and direct mode skip it — the difference is where the traffic ends up after skipping. One destination is a proxy node; the other is the local network.
| Mode | Matches rules? | Traffic destination | Typical latency characteristics |
|---|---|---|---|
| Rule mode | Yes | Routed to direct connection or different proxy nodes based on rules | Requests matching direct rules have low latency; requests matching proxy rules depend on node quality |
| Global mode | No | Uniformly sent to the currently selected node | All requests have consistent latency, depending on that node's line quality |
| Direct mode | No | Direct outbound through the local network | Bypasses the proxy entirely; latency matches the raw network as if Clash weren't in use |
Note: Direct mode is not the same as "everything routed through direct connection under rule mode." Direct mode disables the entire proxy evaluation logic at the client level — even if the config file contains extensive proxy rules, they won't take effect. Under rule mode, on the other hand, even if a specific rule explicitly specifies a direct connection, the remaining rules still route traffic to proxy nodes normally.
Typical Use Cases for Rule Mode
Rule mode is the recommended setting for the vast majority of everyday use cases, because it can simultaneously satisfy both "keep local services on a low-latency direct connection" and "route overseas or specific services through a proxy" without requiring users to manually switch modes. Common rule dimensions include:
- Domain suffix and keyword matching: For example, routing common domestic video, payment, or government service domains to a direct-connection policy to avoid unnecessary detours.
- GEOIP location matching: Routing IPs resolved to a specific country or region to the corresponding policy — commonly used to distinguish domestic CDNs from overseas servers.
- LAN and private address ranges via direct connection: Ensuring that access to router admin pages, printers on the local network, or NAS devices doesn't go through the proxy — these rules are usually placed near the top of the rules list.
- Process- and port-level rules (supported by some Clash Meta cores): Matching based on the name of the application making the request, enabling fine-grained control such as "only route this one app through the proxy while everything else connects directly."
A typical rule snippet looks something like this:
rules:
- DOMAIN-SUFFIX,cn,DIRECT
- GEOIP,CN,DIRECT
- DOMAIN-KEYWORD,examplecdn,Proxy
- IP-CIDR,192.168.0.0/16,DIRECT
- MATCH,Proxy
The core idea behind this kind of config is: intercept traffic that should clearly go direct first, then hand off everything uncertain to the final MATCH rule. Rule mode is well suited for long-running everyday use where you need to balance speed and stability — daily work, browsing, using messaging apps, and so on. Rule sets are typically maintained by the subscription provider, and users can view the currently active rule set on the client's "Config" page, or use the "override" feature to append custom rules without modifying the original subscription content.
Typical Use Cases and Risks of Global Mode
The value of global mode lies in "predictability": all traffic takes the same route, so there's no risk of a specific site behaving oddly due to a rule mismatch. This makes it a better fit than rule mode in the following scenarios:
- Diagnosing whether rules are working as expected: When you suspect that slow access or connection failures on a specific site are caused by a rule-matching error, switch to global mode to force all traffic through the proxy node. If the problem persists, the issue lies with the node itself or the network environment, not the rule configuration.
- Needing a consistent egress point for domestic and overseas access: Some corporate intranet testing or cross-border data comparison scenarios require all requests to originate from the same egress address. Global mode guarantees this, whereas under rule mode, domestic traffic going direct would result in an inconsistent egress address.
- Temporarily benchmarking a specific node's overall performance: If you want to concentrate on testing connectivity and speed for a newly added node across various sites, global mode avoids the interference variable introduced by rule-based traffic splitting.
Caution: Under global mode, access to domestic sites also gets routed through the proxy node, which usually means added latency, and some services that rely on the device's real IP location (such as map positioning or certain payment verification steps) may behave unexpectedly. Using global mode long-term isn't a way to save bandwidth or improve speed — it's best enabled only briefly for troubleshooting or when you have a clear need for a consistent egress point.
It's also worth noting that the "currently selected node" under global mode is a single node or single proxy group. If that node is unstable, all traffic is affected simultaneously, which is a more concentrated risk compared to the distributed traffic splitting of rule mode.
Cache and Connection State Issues to Watch for After Switching Modes
Switching modes may look like flipping a simple toggle in the client interface, but under the hood it involves rebuilding the connection table, DNS cache, and core state. Mishandling this can lead to symptoms like "the page won't load after switching" or "it shows connected but nothing actually works." Here are a few details worth keeping in mind:
- Already-established long-lived connections don't automatically re-route: TCP connections opened before the mode switch (such as an ongoing video stream or a file download in progress) typically continue using their original outbound path until that connection naturally ends. If you need the change to take effect immediately, manually disconnect the relevant app's connection or restart the app.
- DNS cache may cause a domain to still resolve to old results: Rule mode relies heavily on GEOIP evaluation for traffic splitting, and GEOIP evaluation depends on domain resolution having already completed. If the client or system-level DNS cache still holds resolution results from before the mode switch, rule matching may briefly continue to evaluate based on the old IP location. In this case, you can manually clear the DNS cache in the client, or wait for the cache to expire naturally.
- Health-check status for proxy groups isn't reset by a mode switch: If a proxy group was marked unavailable under rule mode due to a failed latency test, switching to global mode while that group is still selected will still result in a connection failure — this has nothing to do with the mode itself and requires first confirming node connectivity.
- Browsers and some apps maintain their own connection pools: For performance reasons, browsers reuse already-established HTTP/2 or HTTPS connections, so a browser won't necessarily notice a mode switch right away. If you run into page-loading issues, try a hard refresh or restart the browser process first, rather than immediately assuming the proxy configuration is broken.
Tip: After switching modes, open a fresh browser tab and visit a known test address first, then check whether the current protocol and node info shown on the connection status card have updated to the expected values. Once confirmed, proceed with other tasks — this avoids being misled by leftover state from old connections.
How to Switch and Verify Quickly in the Client
Different clients (such as Clash Verge, Mihomo Party, and FlClash) look slightly different, but the workflow is essentially the same:
- Open the client's main interface and find the "Mode" or "Running Mode" segmented control, usually presented directly as three options: "Rule / Global / Direct."
- Click the mode you want to switch to. Most clients will simultaneously display the currently active mode name in the status bar or on the connection status card — for example, the protocol info at the top of the connection status card labeling
ruleorglobal. - After switching, open the log panel and check which specific rule or policy the most recent requests matched, to confirm traffic is flowing as expected. This step is especially useful for verifying whether a rule configuration is actually taking effect.
- If you're only temporarily verifying a node's connectivity, remember to switch back to rule mode once you're done, to avoid the added latency and egress inconsistency risks of staying in global mode long-term.
For everyday users, rule mode paired with a well-maintained subscription rule set covers the vast majority of scenarios without needing frequent manual mode switching. Global mode is more of a diagnostic tool or a temporary choice for special situations, while direct mode works well as a quick on/off switch for when you don't need the proxy at all.