Separate the Two Switches: Traffic Capture and Proxy Mode
In a Clash client, System Proxy, TUN mode, and Rule, Global, and Direct are settings at different layers. System Proxy or TUN sends traffic into the Clash core; proxy mode determines whether connections already inside the core use a proxy node, DIRECT, or REJECT. Switching proxy modes does not enable System Proxy automatically, and enabling TUN does not mean every connection will use a remote node.
In a typical configuration, the mixed-port shared by HTTP and SOCKS may be set to 7890, while the external-controller may be set to 127.0.0.1:9090. A request enters the core when the browser explicitly uses 127.0.0.1:7890 or the operating system proxy points to that port. With TUN enabled, more apps that do not read system proxy settings, UDP traffic, and some command-line programs can also be captured. Ports are configuration values, so the actual numbers may differ by client; check Settings → Port Settings or the active configuration file.
All Three Modes Process the Same Captured Connections
- Rule mode: Matches the configured rules in order and selects a policy group, DIRECT, or REJECT based on the first match.
- Global mode: Skips ordinary routing rules and sends connections to the GLOBAL policy entry, which then uses the selected node or policy group.
- Direct mode: Lets captured connections access their destinations directly, normally without passing through a remote proxy node.
The phrase “skip rules” has limits. The core still handles connection acceptance, destination detection, DNS, and other fundamentals; the client may also retain LAN bypasses, process exclusions, or loopback protection. Direct therefore does not mean Clash has been exited. To stop traffic capture completely, disable System Proxy and TUN separately and stop the core if necessary.
Rule Mode: The Best Default for Everyday Use
Rule mode is designed for long-term use. It checks rules from top to bottom, and the first matching rule takes effect immediately; later rules are ignored. A typical setup keeps LAN and mainland-China sites on DIRECT, sends specified domains or traffic outside mainland China to proxy policy groups, and uses MATCH to catch anything left unclassified.
mode: rule
mixed-port: 7890
rules:
- DOMAIN-SUFFIX,example.com,Proxy
- DOMAIN-SUFFIX,cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,Proxy
In this example, requests to example.com match the first rule and go to Proxy; other domains ending in .cn connect directly; unmatched IPs in mainland China are handled by GEOIP,CN; and all remaining requests enter Proxy. Rule order matters. If MATCH is placed first, the DOMAIN-SUFFIX and GEOIP rules below it will never run.
Practical Use Cases for Rule Mode
- Everyday browsing: Keep mainland-China services on DIRECT and route external services through rules to avoid unnecessary detours through remote nodes.
- Video and download routing: Create separate policy groups for streaming services, game platforms, or large downloads, then choose nodes by workload.
- LAN device access: Keep private ranges such as 192.168.0.0/16 and 10.0.0.0/8 on DIRECT so router and NAS access is not sent through a proxy.
- Long-running TUN capture: When system traffic comes from many sources, use rules to control the egress path for TCP, UDP, domain, and IP requests.
With subscription configurations, rule-mode behavior depends on the supplied rule sets and policy groups. Two similarly named configurations may use GEOIP, GEOSITE, rule-providers, or many DOMAIN-SUFFIX entries, producing different routing results. If a site uses the wrong egress, first inspect the matched rule and policy in the connection details instead of assuming rule mode has failed.
Troubleshooting Order for Unexpected Rule Matches
- Search for the target domain on the Connections page and confirm the matched rule name and outbound policy.
- Check the policy group’s current selection. If the rule points to Proxy, make sure Proxy itself has not been set to DIRECT.
- Check whether the domain was resolved to an IP too early; with fake-ip and redir-host enabled, the destination information visible to the core may differ.
- Check rule order, especially MATCH, FINAL, broad DOMAIN-KEYWORD rules, and wide IP-CIDR ranges.
- After updating remote rule sets, reload the configuration and confirm the logs show no rule-provider download or parsing errors.
Global Mode: Full-Traffic Validation and Temporary Rule Bypass
Global mode is useful for testing but is not always suitable as a permanent setting. After switching to global, ordinary routing rules no longer choose the egress; connections enter the GLOBAL policy entry. You must also select an available node in GLOBAL. If GLOBAL is currently set to DIRECT, the interface may show global mode while connections still go direct.
| Use Case | Recommended Mode | What to Watch |
|---|---|---|
| Determine Whether Rules Are Preventing a Site from Opening | Temporarily switch to global | Does access recover immediately with the same node? |
| Check the complete egress path for a specific node | global | Is GLOBAL set to the target node? |
| Everyday mixed access to mainland-China and external sites | rule | Domain, GEOIP, and fallback rules |
| Determine Whether the Proxy Node Is Causing the Problem | direct | Can the target be reached directly? |
For example, if a site times out in rule mode, note the current node, switch to global, and select that same node in GLOBAL. If global mode restores access, the node is usually working; the problem is more likely a rule match, policy-group target, or DNS split. If global mode still fails, check node connectivity, handshake logs, UDP support, and restrictions imposed by the destination service.
Global Mode Does Not Mean Every Program Uses the Proxy
Only traffic that enters Clash is controlled by global mode. A browser using the system proxy enters the core, but some games, virtual machines, containers, and programs with their own network stacks may bypass it. To cover them, check that TUN is running, the operating system has granted administrator privileges, and the client’s process exclusion list is configured correctly. On Android, confirm that VpnService authorization is still valid and that the target app has not been excluded by per-app proxy settings.
Direct Mode: Isolate Proxy Effects, Not an Exit Button
Direct mode makes new connections already inside Clash attempt to reach their destinations through the local network. It is best used for controlled comparisons: does switching to direct restore access on the same device and DNS environment? If so, the problem may be the proxy node, policy group, or remote path. If it still fails, continue checking the local network, destination service, DNS, and the app itself.
Direct mode cannot make a destination reachable if the local network could not reach it in the first place. If the ISP network cannot connect to an address directly, direct mode will still time out. It also does not disable DNS handling: when Clash’s nameserver module captures DNS requests, domain resolution may still use the configured local or encrypted DNS server even in direct mode.
Three Good Times to Switch to Direct
- Local services suddenly become unavailable: Determine whether proxy routing is affecting a corporate intranet, campus network, NAS, or router admin panel.
- Compare download speeds: Test the same mainland-China mirror in rule and direct modes to see whether a remote detour reduces bandwidth.
- Troubleshoot node failures: When several nodes show the same error, use direct mode to determine whether the issue actually comes from the destination site or local DNS.
Do not treat direct mode as a substitute for turning off the client. System Proxy may still point to 127.0.0.1:7890, and the TUN virtual adapter may continue running; connection records and DNS caches may still be managed by the core. To restore the original network path, turn off Settings → System Proxy, turn off Settings → TUN Mode, and confirm that the operating system proxy settings have been restored.
Why Old Connections Do Not Change Immediately After Switching Modes
Mode switching mainly affects new connections. Established TCP sessions usually continue using their original egress until the app closes them, the server disconnects, or the core terminates them. This is especially noticeable with HTTP/2, WebSocket, QUIC, and long-lived connections: refreshing a page may reuse the old connection, making it appear that the mode did not change.
After switching, wait 3 to 10 seconds before sending a new request. If the result is unchanged, close the corresponding connection on the client’s Connections page or fully quit and reopen the target app. For browser tests, a new private window may not be enough because the browser process can still share a connection pool; fully quit the browser process before reopening it for more reliable results.
DNS Caches Can Also Distort Comparisons
Apps, the operating system, and the Clash core may all cache DNS results. On Windows, run ipconfig /flushdns in a terminal to clear the system DNS cache. macOS refresh procedures vary by version, so restarting the target app and Clash core is usually safer. With fake-ip enabled, addresses in the 198.18.0.0/16 range are core mappings and do not mean the site’s real server is located in that network.
When testing the same site, record the mode, policy-group node, matched rule, target domain, connection protocol, and elapsed time. For example, rule mode may match DIRECT in 42 ms, while global mode reaches the destination through the target node in 186 ms. That makes a meaningful comparison; relying only on perceived page-load speed is easily affected by caching, connection reuse, and changes in CDN endpoints.
How to Switch Modes in the Client and Save Them in the Configuration
Entry names vary slightly across graphical clients. Commonly, the top of the Proxy or Proxies page in the sidebar offers Rule / Global / Direct, while some clients place the setting under Settings → Run Mode. After switching, return to the Connections page and make a new request to confirm that mode matches the actual outbound path. If the client supports a tray menu, the Proxy Mode submenu may provide a quick way to switch.
In mihomo or compatible Clash configurations, the mode field sets the default mode loaded with the configuration:
mode: rule
The usual values are rule, global, and direct. Some clients save the runtime selection in their own settings database and override the configuration file’s mode at the next launch. After editing YAML manually, check whether the change survives a client reload. Subscription updates may also replace the active configuration, so long-term customizations should not be stored only in generated subscription files.
Switching mihomo Mode Through the Control API
Environments with external-controller enabled can modify the runtime configuration through a REST API. The example below assumes the control address listens only on 127.0.0.1:9090 and no secret is configured:
curl -X PATCH http://127.0.0.1:9090/configs \
-H "Content-Type: application/json" \
-d '{"mode":"rule"}'
Change rule to global or direct to switch modes. If a secret is configured, send an Authorization: Bearer secret-value request header. The control API should never be exposed directly to the public internet; for LAN administration, also restrict the listen address, firewall sources, and authentication secret.
A Repeatable Mode Troubleshooting Workflow
The most useful purpose of mode switching is controlled comparison, not random clicking back and forth. Keep the network, destination, and node unchanged, then follow the steps below to narrow down the cause quickly.
- Confirm that System Proxy or TUN is enabled and that the target request appears in the connection list.
- Use rule mode to start a new connection, recording the matched rule, policy group, and specific node.
- Switch to global, select the same node in GLOBAL, close the old connection, and retry.
- Switch to direct, close the old connection again, and test the result over the local network.
- Compare DNS results, connection protocols, handshake errors, and timing across all three logs.
- When testing is complete, restore rule mode and confirm that the policy-group selection and TUN status match your everyday setup.
| Rule Result | Global Result | Direct Result | Check First |
|---|---|---|---|
| Failed | Succeeded | Failed | Rule match and policy-group routing |
| Failed | Failed | Succeeded | Proxy node, protocol, and remote path |
| Succeeded | Succeeded | Failed | A normal proxy-reachable scenario |
| All Failed | All Failed | All Failed | Traffic capture, DNS, local network, or destination service |
The final choice can stay simple: use rule mode every day; temporarily use global to validate a node or bypass complex rules; use direct to determine whether the local network or proxy path is affecting the connection. After switching, always check the exact GLOBAL selection, close old connections, and treat System Proxy and TUN as separate switches. This keeps the three modes distinct and predictable.