On this page
First distinguish runtime mode, the system proxy, and TUN
Current Mihomo documentation lists Rule, Global, and Direct as runtime modes, with Rule as the default. They process connections that have entered the core and determine whether each connection follows rules, goes uniformly to the GLOBAL policy group, or directly uses the local network.
The system proxy, TUN, and mobile VPN determine how traffic enters the core. select, url-test, and fallback determine how a policy group selects an outbound route. fake-ip and redir-host are DNS enhancement modes. Calling all these layers “proxy mode” makes it easy to change the wrong setting during troubleshooting.
Which layer each term belongs to
| Level | Common option | What it actually determines |
|---|---|---|
| Runtime mode | Rule / Global / Direct | Which outbound route a connection already inside the core ultimately uses |
| Traffic capture method | System Proxy / TUN / mobile VPN | Which application or system traffic can enter the core |
| Policy-group type | select / url-test / fallback | How a policy group selects a node or another policy |
| DNS enhancement mode | fake-ip / redir-host | How name-resolution results enter rules and connection handling |
Three runtime modes change outbound decisions, not node speed
In a desktop client such as Clash Verge Rev, open “Proxy Mode” on the home screen or use the tray icon's Mode submenu. On mobile, it is usually on the home screen or the “Mode” row of Proxies. Start with Rule for everyday use. If you need to determine whether a rule sends a site to the wrong outbound route, switch briefly to Global or Direct.
All three modes receive the same connections that enter Clash; the difference is how they select the next outbound route. Rule matches rules from top to bottom, Global sends connections to the global policy group, and Direct uses the local network. They do not change a node's own bandwidth or latency.
Perform one real mode switch in the client
Open Mode / Proxy Mode
Use the home-screen mode control or tray menu; do not edit the mode field in the remote YAML.
Select Rule
Open the target page and record the current matched rule and outbound route in Connections.
Select Global or Direct for comparison when needed
Keep the same node and target; change only the mode and establish a new connection.
Return to Rule after the comparison
Request the target again and confirm that new connections once again follow rules.
Modes and real uses
| Mode | How connections are routed | When to use it |
|---|---|---|
| Rule | Applies the policy for the first matching rule | Everyday use, with different services using different outbound routes |
| Global | Sends every connection entering Clash to the global group | A brief comparison to determine whether rules cause the issue |
| Direct | Every connection entering Clash goes directly | Validate the local network or temporarily avoid proxying |
Modes affect only traffic that has entered Clash. If an app completely ignores the system proxy and has no record in Connections, switching from Rule to Global will not make it appear. Address the system proxy, app proxy, or TUN first.
Rule mode — the first matching rule determines the outbound route
Rule is Mihomo's default runtime mode and suits everyday configurations where direct access, proxying, rejection, and several policy groups coexist. It does not inherently mean “domestic direct, international proxied.” Actual behavior depends entirely on the current rules, rule-providers, and their order.
Mihomo checks rules from top to bottom and stops at the first match. A domain that should use a proxy may first match a broader DIRECT rule, so nothing later executes. MATCH at the end commonly catches connections not matched earlier.
Open Connections, find the request, and inspect the rule type and policy group. Labels such as DOMAIN-SUFFIX, RULE-SET, or MATCH show exactly where the decision was made. Switching modes by intuition hides rule-order problems instead.
rules:
- DOMAIN,api.example.com,DIRECT
- DOMAIN-SUFFIX,example.com,REJECT
- MATCH,DIRECTUse Rule for daily operation and be able to answer, “Which rule did this connection match?”
Inspect one real request
Keep Rule mode
Pin one known-good node in the primary policy group.
Repeat the target action
Open the same page, refresh the same endpoint, or launch the same app.
Find it in Connections
Locate the new connection by domain, process, or time.
Read the rule and outbound route
Confirm whether it is DIRECT, REJECT, or a proxy policy group.
If the result is expected, Rule is working normally. When one site fails, change only its related rule or policy group; do not switch the whole setup to Global because of one connection.
Global mode — sends captured connections to the GLOBAL group
Global changes only connections that have entered Mihomo; it does not automatically capture every app on the device. After entering this mode, inspect the GLOBAL policy group and confirm whether it currently selects a specific node, another policy group, or DIRECT. The Global label at the top alone does not reveal the actual outbound route.
In Global mode, first select a specific node in the GLOBAL policy group. If the target request fails by matching DIRECT under Rule but succeeds through that node under Global, the network and node are at least usable; return to the Rule match order.
If it still shows timeout under Global, rules are not the only cause; compare the node, DNS, and local network. Return to Rule after testing because system updates, local-network traffic, and domestic services that originally connected directly may all use the same outbound route under Global.
Direct mode — uses the local network after traffic passes through the core
Direct mode lets requests entering Clash connect directly. If a locally reachable site succeeds in Direct but fails under a proxy policy, the node or proxy connection is the more likely problem. If Direct also fails, inspect local DNS, the network, or the target service.
Direct is not exactly equivalent to “turning off Clash.” Requests may still enter the core while the outbound selection is DIRECT. To determine whether an app passes through Clash, inspect Connections instead of only whether the page opens.
- Direct succeeds, while Rule fails through a proxy
- Determine whether that proxy policy should use the current node and rule arrangement.
- Both Direct and Global fail
- Inspect the local-network and proxy logs separately; do not attribute the results to the mode labels.
- None of the three modes shows a connection record
- The app bypasses Clash; fix the traffic entry first.
Why older clients also have Script mode
Some historical Clash clients, older cores, or specific configurations offered Script mode for routing decisions more complex than ordinary rules. Current Mihomo general configuration documentation lists only Rule, Global, and Direct as runtime modes, so do not describe Script as a universal fourth mode in all modern clients.
Seeing Script in an old client does not mean the new client still has a toggle with that name; not finding it does not indicate installation failure. When migrating an old configuration, identify which domains, networks, or processes the script evaluated, then rewrite that intent using current rules, rule-providers, or client-supported overrides.
How to interpret Script
| Where it appears | How to understand it | Next step |
|---|---|---|
| Mode menu in a historical client | A compatibility feature of that version or core | Preserve the old environment record and consult its version-specific documentation |
| Script block in an old configuration | May contain custom routing logic | Understand its conditions before deciding whether to migrate it |
| A new Mihomo client has no Script option | An interface aligned with the current three standard runtime modes | Do not force an unverified mode value into the current core |
| Merge, override, or JavaScript screen | A client-side configuration-processing capability | Do not conflate it with core runtime modes |
Choosing among three modes: change only one variable for comparison
Choose a runtime mode for the scenario
| Current purpose | Recommended mode | What to observe |
|---|---|---|
| Route services differently during everyday use | Rule | The matched rule, policy group, and actual outbound route in Connections |
| Determine whether a rule sends the request to the wrong route | Use Global briefly | The GLOBAL group selection and new connections after recreating them |
| Determine whether the local network can reach the target directly | Use Direct briefly | Local DNS, target reachability, and connection records |
| The app has no connection record | Do not switch modes yet | System proxy, app proxy, TUN, or mobile VPN |
Rule fails, but Global succeeds
Compare the rule and outbound route in Connections for both attempts, then correct the Rule match.
The Global screen still shows DIRECT
Inspect the current selection in the GLOBAL policy group, not just the mode at the top.
The local network returns after switching to Direct
Add a direct rule for the local subnet instead of relying on mode switching permanently.
The page result does not change after switching modes
Close reused connections, issue the request again, and inspect the new records.
After a comparison, restore the intended mode and repeat the same action. If Rule now matches the correct policy and works, there is no need to retain Global as a “fix.”