Clash proxy mode: which one should you use? Rules, Global, and Direct explained

The three modes change outbound routing decisions

Clash Meta, powered by the widely used mihomo core, first receives connections through a local proxy port or TUN virtual interface, then selects an outbound route. Rules, Global, and Direct modes change how that decision is made. They do not change the number of nodes in a subscription or automatically capture traffic that never enters the core.

For example, when a browser opens an HTTPS website, the connection may first enter the local HTTP or mixed port, such as the commonly configured 7890, or it may be intercepted by TUN through the system network stack. Only after the core identifies the destination domain, IP address, port, and network type can it choose a proxy node or the local network based on the active mode. If the system proxy is disabled, the app has no proxy configured, and TUN is not intercepting traffic, that app bypasses Clash; switching modes usually will not affect it.

Rule mode: choose an outbound route by match order

Rule mode is best suited to long-term use. It checks connections one by one against the configuration file's rules list; the first matching rule takes effect immediately, and later rules are ignored. Domain, IP, process, and rule-set entries can coexist, so order matters more than the number of rules.

mode: rule
mixed-port: 7890
external-controller: 127.0.0.1:9090

rules:
  - DOMAIN-SUFFIX,example.cn,DIRECT
  - DOMAIN,api.example.net,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,Proxy

This example first sends specified mainland China domains through a direct connection, then routes an API domain to the Proxy proxy group. The two private address ranges are sent directly to the LAN, while the final MATCH catches connections that matched nothing earlier. If MATCH,Proxy were placed first, none of the remaining rules could take effect.

Three practical checks in Rule mode

1. Which proxy policy did the rule match? Client connection pages usually show the rule name or route, such as DOMAIN-SUFFIX → DIRECT or MATCH → Proxy. The node name alone is not enough to determine whether routing is correct.
2. What is currently selected in the proxy group? After a rule sends traffic to Proxy, the final outbound route still depends on that group. A manual group uses the currently selected node; a url-test or fallback group chooses based on its health checks.
3. Has the domain been resolved to an IP address? Some connections expose only the destination IP, so domain rules may not participate. With DNS hijacking, sniffing, or a suitable TUN configuration enabled, the core can obtain more domain information, but the exact behavior depends on the configuration and protocol.

Rule mode also works well for LAN and development environments. Placing localhost, 127.0.0.0/8, 192.168.0.0/16, and corporate intranet domains near the top can prevent internal requests from being sent to remote nodes. Before debugging, still check whether a corporate VPN, virtual machine network, or container network overlaps these ranges.

Why Rule mode is the best default for everyday browsing

• Local services, printers, NAS devices, and router admin pages can stay on a direct connection.
• Different sites can use different proxy groups instead of being locked to one node.
• After updating rule sets, there is no need to change proxy settings in each app.
• Connection logs retain the matched rule, making it easier to find why a domain used the wrong outbound route.

Global mode: bypass normal rules to test a single outbound route

Global mode is often described as “forcing every device's traffic through a proxy,” but that is not accurate. It only handles connections that have entered the Clash core and usually sends them to the GLOBAL proxy group. Connections that never enter a proxy port, are not captured by TUN, or are excluded by routing still will not change simply because the mode name changed.

The main value of Global mode is fault isolation. If a site fails in Rule mode but immediately works in Global mode, the node can reach it, so the problem is more likely the rule match, proxy-group selection, or direct route. If it still fails in Global mode, continue checking node connectivity, DNS, TLS time settings, network firewalls, and the target service.

When Global mode is useful

• Test a single node. Pin one node in the GLOBAL group, then test page loading, TCP connections, and UDP requirements separately to prevent an automatic group from changing routes during the test.
• Temporarily rule out rule problems. If the same URL behaves differently in Rule and Global modes, return to the connection log and inspect the rule-match chain.
• Run a repeatable proxy speed test. Use the same server, node, and testing window to reduce differences caused by separate test domains being routed to different outbound paths.

A reproducible speed-test record

Start by establishing a local baseline in direct mode, then switch to global mode and test the same node. On one gigabit wired connection, direct mode recorded 742 Mbps down, 93 Mbps up, and 8 ms idle latency; with the same proxy node fixed, results were 186 Mbps down, 61 Mbps up, and 48 ms idle latency. These figures describe only that network, node, and test period, not expected speeds on other devices.

1. Close apps that are syncing files, downloading updates, or streaming video.
2. Run the same speed test server three times in Direct mode and record the median.
3. Switch to Global mode and pin one node in the GLOBAL group.
4. Close and reopen the speed-test page to create a new connection, then run the test three more times.
5. Record download, upload, idle latency, loaded latency, and packet loss.

Latency tests in a client's node list usually send a short HTTP request to a specified test URL to measure reachability and round-trip time. A displayed 52 ms does not mean the node can sustain full bandwidth, nor does it guarantee that UDP, long-lived connections, or large-file transfers will work reliably.

Direct mode: keep interception enabled while using the local network

Direct mode sends connections that enter the core through the DIRECT outbound. It is useful for measuring the network baseline without a proxy node, accessing LAN devices, debugging local services, or determining whether a fault originates from a remote node. Direct mode does not mean the client has exited: local listening ports, the TUN virtual interface, connection logs, and the DNS module may still be active.

How Direct mode differs from fully quitting Clash

Therefore, when troubleshooting DNS, switching to Direct mode alone may not produce a result that is completely outside Clash. If dns.enable, TUN DNS hijacking, or fake-ip is enabled, queries may still be handled by the core. To establish a raw operating-system network baseline, record and restore the system proxy, TUN, DNS, and routing states one by one.

Recommended order for LAN debugging

1. First, use Rule mode to see which rule matched the destination.
2. Confirm that the destination belongs to a real internal network, such as 192.168.1.0/24, and check whether a public domain with the same name exists.
3. Switch to Direct mode, close existing connections, and access the service again.
4. If it still fails, check the local routing table, corporate VPN, container network, and service listening address.
5. If Direct works but Rule mode fails, add an earlier DIRECT rule for the domain or network range.

In local development, also distinguish the listening address. If a service listens only on 127.0.0.1:3000, other devices cannot access it through the LAN IP; that is not caused by the Clash mode. If it listens on 0.0.0.0:3000, check the system firewall, LAN isolation, and the DIRECT rule for the relevant network range.

Switching modes does not automatically reroute existing connections

Clash usually decides the outbound route when a connection is established. Existing TCP connections do not move to another node when you switch from Rule to Global mode. This is especially noticeable with WebSockets, SSH, video streams, cloud-drive sync, and long-lived HTTP/2 connections. The new mode shown in the interface only guarantees that newly created connections use the new logic.

Make test results reflect the new mode

• Before refreshing a page, close its tab; if necessary, fully quit and restart the browser.
• Terminate old connections on the client's connection page; when testing SSH, establish a new session.
• Wait for the app's connection pool to be released, or restart apps that remain active in the background.
• After switching nodes, issue a new DNS query so old resolution results are not mixed with the new outbound route.
• Restart the session when testing a UDP app, because some apps reuse mappings for long periods.

In common graphical clients, the mode selector is usually under “Proxies” → “Mode,” with options for “Rules,” “Global,” and “Direct.” Some clients place it under “Settings” → “Clash Settings” → “Operating Mode,” and the tray menu may offer the same options. Menu labels vary by client version, but the corresponding core values remain rule, global, and direct.

If mihomo's external controller is enabled, such as 127.0.0.1:9090, the control panel changes the mode through the controller API. The request body uses the same lowercase English values:

PUT /configs
Content-Type: application/json

{"mode":"rule"}

The external controller should listen only on trusted interfaces and require access credentials. After making a change, reload the running configuration and create a new request in the connection log to confirm that the active mode and match chain agree. When editing the configuration file manually, reload it as well; changing the file on disk alone does not guarantee that the running core will immediately adopt the new value.

Choose a mode for the task at hand

Everyday browsing and long-running background use

Choose Rule mode. First ensure that LAN traffic, commonly used direct services, and proxy services match the expected rules, then let proxy groups handle node changes. Rule mode provides clearer traffic records and prevents every connection from being concentrated on one remote outbound route.

A website suddenly stops opening

Stay in Rule mode and inspect the connection log, noting the matched rule and proxy group. Then switch to Global mode and establish a new connection with the same node. If Global works, revisit the rules; if it still fails, check the node, DNS, and target service. Restore Rule mode when testing is complete.

Compare local-network and node performance

Measure the local baseline three times in Direct mode, then pin the node and measure three times in Global mode. Keep the test server, device connection, and time window consistent. Do not directly compare several speed-test domains in Rule mode because they may match different rules or proxy groups.

Access a NAS, router, or development service

Start with the LAN DIRECT rules in Rule mode. A temporary switch to Direct mode can confirm whether the proxy route contributes to the problem, but the long-term fix is to complete the internal-domain and network-range rules. If TUN routing conflicts with a corporate VPN, adjust route exclusions; simply selecting Direct mode cannot repair the routing table.

Pause remote proxy routing while keeping the client available for observation

Selecting Direct mode preserves connection logs and the local interception structure, making request behavior easier to compare. If the goal is to restore the operating system's raw network state, also disable the system proxy and TUN, and confirm that DNS, the default route, and the virtual interface have been restored.

An actionable mode troubleshooting checklist

1. Confirm that the app's traffic enters Clash through the system proxy, a manual proxy, or TUN.
2. Record the current operating mode; do not confuse the mode with the proxy-group name.
3. On the connection page, check the destination domain, destination IP, matched rule, and actual route.
4. When Rule mode behaves unexpectedly, use Global mode with the same node pinned for comparison.
5. For a local baseline, switch to Direct mode and remember that DNS may still be handled by the core.
6. After every switch, close old connections and reopen the page or restart the test app.
7. Once the issue is identified, return to Rule mode and correct the rule order, rule set, or proxy-group selection.

There is no universal speed ranking among the three modes. Rule mode depends on the matched rule and proxy group, Global mode depends on the node selected in GLOBAL, and Direct mode depends on the local ISP route. Choose a mode based on what you are testing: rule decisions, a remote node, or the local network. Record them separately to reach reproducible conclusions from the connection logs.