On this page
Switching to Global may get some apps working while others still do nothing. These results can coexist: the operating mode decides how connections are routed, while the system proxy or virtual network adapter determines which programs’ requests reach the client. Keeping the two roles clear makes mode switching a useful comparison and helps prevent a temporary test from becoming a permanent setting.
Rule, Global, and Direct determine where connections go
Use Rule for everyday rule-based routing. Use Global or Direct when you need a temporary outbound change or want to compare access results; changing the mode does not make a node itself faster.
| Mode | How connections are handled | Common uses |
|---|---|---|
| Rule | Match rules in order and apply the policy of the first matching rule | Route different services through different outbound paths in everyday use |
| Global | Send connections to the GLOBAL group; the actual outbound route depends on its selection | Temporarily use one outbound route, or select a node to compare access results |
| Direct | Use the local network as the outbound route | Check local network reachability, or temporarily connect directly |
These modes affect only connections that have already reached the core. Switching to Global does not automatically capture traffic from an app that has not reached it. If the app has no records in Connections, check whether the system proxy, app proxy, or TUN is active.
In desktop clients such as Clash Verge Rev, open the proxy mode control on the main screen, or right-click the tray icon and open the Mode submenu. On mobile, the mode control is usually on the home screen or the Proxies page.
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.
What the system proxy, TUN, policy groups, and DNS each do
The system proxy, TUN, and mobile VPN determine how traffic enters the core. select, url-test, and fallback determine how a policy group chooses an outbound route, while fake-ip and redir-host are DNS enhancement modes. These settings have different purposes; calling all of them "proxy modes" makes it easy to change the wrong switch.
What each setting controls
| Setting category | 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 |
Rule mode — rule order and connection checks
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. If a domain should use a proxy but matches a broader DIRECT rule first, later rules will not run. MATCH, commonly placed at the end, handles 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,DIRECTInspect one real request
Keep Rule mode
When testing proxying, pin a verified working node in the main policy group. Rules for direct connections or rejection do not require a proxy node.
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 — the GLOBAL group and node selection
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 — how direct connections differ from quitting the client
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
- If there is still no record after repeating the request, check whether the system proxy, the app’s own proxy, or virtual-adapter settings took effect. Do not judge traffic capture from mode switching alone.
Script mode — older clients versus current Mihomo
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 |
How to interpret connection results after switching modes
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.”