Menus and layouts vary across Clash clients, but the core interface usually revolves around the same tasks: loading a profile, starting the core, taking control of system traffic, choosing an exit through proxy groups, and using logs and connection records to troubleshoot problems. Understanding how these sections relate to one another matters more than memorizing where a particular button appears in one client.

Common desktop clients may label their pages Overview, Proxy, Profiles, Connections, Logs, and Settings. Android clients may place some features in a sidebar or bottom navigation. Clients using the mihomo core may also add entries for rule providers, external control, profile overrides, or runtime settings. The names differ, but the data flow can be summarized as follows: the profile supplies rules and nodes, the core performs matching and forwarding, the system proxy or TUN sends application traffic into the core, and the Logs and Connections pages show the results.

Overview: confirm whether the client is actually handling traffic

The Overview page may also be called Home, Dashboard, or Status. It typically summarizes the core status, current proxy mode, system proxy toggle, TUN toggle, upload and download rates, active connection count, and memory usage. It answers the first question: is the client merely open, or has it started processing network traffic?

Core status

A graphical client and its proxy core are separate layers. The interface process handles profile management and system integration, while the Clash or mihomo core listens on ports, matches rules, and establishes connections. A window opening normally does not prove that the core started successfully. If the Overview page shows Stopped, Core not running, or an immediate exit after startup, first check for port conflicts, configuration syntax errors, and problems with the core files.

After the core starts successfully, it usually exposes local listening ports such as HTTP, SOCKS, or mixed-port. A mixed-port accepts both HTTP and SOCKS5 requests on the same port. Most users do not need to change ports frequently, but other proxy tools, development environments, or older clients may already be using the same port, causing startup to fail.

System proxy vs. TUN

The system proxy primarily changes the operating system's proxy settings. Browsers and apps that follow system proxy settings send requests to Clash, but some games, command-line programs, and software with its own network stack may ignore them. TUN mode creates a virtual network interface and takes control of traffic that matches its routing conditions at a lower level, so its coverage is generally broader.

These are not simply two levels of proxy strength. The system proxy is easier to understand and troubleshoot and is usually sufficient for everyday browsing. TUN is useful for apps that do not read system proxy settings, UDP traffic, or more complete transparent interception. Enabling TUN may require administrator privileges and can be affected by firewalls, other virtual network adapters, enterprise security software, and system routes.

How to read traffic charts

Upload and download rates only show that data is passing through the core; they do not directly prove that the target website is working. A small, steady amount of traffic may come from system updates, push notifications, or background sync. If the active connection count keeps growing without dropping, open the Connections page to inspect the specific process and target domain. If the client shows zero traffic while the browser still works, the app may be bypassing Clash or using a direct route.

Proxy page: understand proxy groups, not just the node list

The Proxy page is one of the most misunderstood sections. It shows not only server nodes but also proxy groups. A proxy group can contain multiple nodes and can nest other proxy groups. Once a rule matches a proxy group, the core uses that group's current selection method to determine the exit.

Common proxy group types

  • select: Manual selection. The interface usually lets you choose a node or nested proxy group directly. The selection remains in effect until the profile is reloaded or replaced by the client's persistence mechanism.
  • url-test: Automatic latency testing. The core periodically requests the specified test URL and chooses a better-performing node based on latency. This measures the test target's response time, not the actual speed of every website.
  • fallback: Failover. Nodes are used in list order, moving to the next candidate when the current exit is unavailable.
  • load-balance: Load balancing. Connections are distributed across multiple nodes according to the configured strategy, which is better suited to situations where session consistency requirements are clearly understood.

When the interface shows names such as Auto, Node Selection, International Media, or Messaging, those names are usually defined by the profile provider rather than being built-in client features. Clicking a proxy group only changes that group's exit. Whether the current website is affected still depends on whether the rules assign it to that group.

What latency numbers actually mean

The latency shown beside a node usually comes from an HTTP test, not a traditional ICMP ping. Results are affected by the test URL, DNS, network congestion, node load, and the check interval. Lower latency is useful for interactive access, but download speed also depends on bandwidth, link quality, and the destination site. A timeout does not necessarily mean the node has completely failed: the test URL may be restricted, the timeout window may be too short, or the network may be temporarily unreachable.

When choosing a node, start with availability and then consider how it performs in actual use. Repeatedly testing an entire group creates multiple probe connections at once. On mobile networks or with many nodes, this uses extra data and can make short-term results fluctuate.

Profiles: the boundaries of subscription updates, profile switching, and overrides

The Profiles page is also commonly labeled Profiles or Subscriptions. It stores remote subscriptions, local YAML files, and client-generated profiles. After you select a profile, the client usually passes it to the core for loading. Proxy groups, rules, DNS settings, and the node list primarily come from this page.

Updating a subscription is not the same as switching profiles

Update means fetching content again from the original subscription URL; switch means asking the core to load another saved profile. After a successful update, nodes and proxy groups may change, and manual selections may be reset. When an update fails, distinguish among a download failure, invalid response format, and core loading failure.

  1. Download failures commonly appear as timeouts, DNS resolution failures, refused connections, or unexpected HTTP status codes.
  2. Format errors can occur when a webpage URL, single-node link, or sign-in page is imported as a Clash profile.
  3. Loading failures usually appear in the logs as YAML parsing errors, field type errors, rule syntax errors, or port conflicts.

The automatic update interval specifies how often the client checks the remote profile; it does not mean the subscription server will necessarily have new content. If the provider requires a particular request method, support for the relevant parameters can also affect the result.

What a YAML profile contains

A typical profile may include listening ports, operating mode, DNS, nodes, proxy groups, and rules. When proxy providers or rule providers are used, some of this content is split into remote files. Here is a simplified example for understanding the structure:

mixed-port: 7890
mode: rule

proxy-groups:
  - name: Node Selection
    type: select
    proxies:
      - Auto Select
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,Node Selection
  - GEOIP,CN,DIRECT
  - MATCH,Node Selection

Rules are evaluated in order, and the first match takes effect. The final MATCH rule usually serves as the fallback. If a domain already matched DIRECT earlier, changing the fallback group will not change its route. Strategy names shown in the interface must match the names referenced by rules, or the profile may fail to load.

Overrides and profile merging

Some clients provide Merge, Script, Override, or override features for adding local settings after a subscription update, such as changing DNS, inserting rules, or modifying proxy groups. The advantage is that you avoid editing the subscription cache directly, since the cache will be overwritten at the next update. The drawback is a longer processing chain: troubleshooting requires checking both the original profile and the overridden result.

When getting started, keep only necessary changes and record the purpose of each override. If the client suddenly stops starting after an update, temporarily disable the overrides and test whether the original profile loads. This quickly shows whether the problem comes from the subscription content or the local processing step.

Connections: see which app is accessing which address

The Connections page shows current or recent network connections handled by the core. Common fields include the destination domain, destination IP, source address, network type, upload and download amounts, matched rule, proxy chain, and connection start time. It is the most direct page for confirming routing results.

Focus on the rule and proxy chain

When a website does not use the expected node, search for its domain on the Connections page first, then inspect the matched rule and proxy chain. For example, DOMAIN-SUFFIX → DIRECT means the rule explicitly requires a direct connection; MATCH → Node Selection → a specific node means the request fell through to the final rule and passed through the specified group and node.

Some connections show only an IP address and no domain. The app may be connecting directly to an IP, DNS mapping information may not have been associated, or sniffing may not have identified the hostname in the protocol. Use the destination IP, process information, and logs together; an empty domain alone does not prove that rule matching failed.

Why a connection remains after closing a webpage

Modern browsers reuse HTTP/2, HTTP/3, or persistent connections, while messaging apps maintain long-lived sessions. As a result, a connection may remain briefly after a page is closed. After switching nodes or rules, an existing connection usually does not migrate automatically to the new exit. The close button on the Connections page can terminate a specific connection, after which the app will reconnect under the current rules.

Close all interrupts active downloads, calls, and background sync. It is useful for verification after changing the proxy mode or strategy, but it should not be treated as a daily speed boost. If connections are immediately recreated, check which process keeps making requests.

Logs: use levels and timestamps to locate startup, DNS, and connection errors

The Logs page records core runtime events. Common levels include debug, info, warning, and error. Info is usually sufficient for everyday use; debug outputs more matching and connection details and is useful for short troubleshooting sessions, but it produces substantially more data. Restore the normal level after troubleshooting.

First identify the stage where the error occurred

  • Startup: Look for profile parsing failures, occupied listening ports, insufficient permissions, TUN device creation failures, and database file loading errors.
  • DNS: Look for resolution timeouts, unreachable upstream servers, unexpected returned addresses, and fake-ip compatibility issues with the app.
  • Connection: Look for connection timeouts, refused connections, failed TLS handshakes, unreachable networks, and node authentication errors.
  • Rules: Look for failed rule provider downloads, missing proxy groups, and rule fields unsupported by the current core.

A log entry usually includes the time, level, network type, destination, matched rule, and final exit. Do not focus only on the final timeout; trace back through DNS and routing records for the same destination. A timeout may occur between the local device and the node, between the node and the destination, or during DNS lookup, and each case requires a different response.

INFO  TCP connection matched DOMAIN-SUFFIX
source: 127.0.0.1
target: example.com:443
policy: Node Selection
outbound: Auto Select

These records show that the connection entered the core and was handed to the Node Selection strategy according to the domain rule. If the request appears in neither Connections nor Logs, the problem likely occurred before traffic entered Clash. Return to the Overview page and check the system proxy, TUN, app proxy settings, and bypass rules.

Rules and providers: confirm that the profile content has loaded

Some clients provide separate Rules, Proxy Providers, and Rule Providers pages. The Rules page usually lists DOMAIN, DOMAIN-SUFFIX, IP-CIDR, GEOIP, GEOSITE, and other entries in the current loading order, along with their target strategies. It is useful for confirming that a rule exists, but actual matches should be verified on the Connections page.

Proxy providers load a set of nodes from an external file, while rule providers load a set of rules. The update time, health-check status, and error messages in the interface help determine whether a remote resource is available. A successful provider update does not mean the main subscription has been updated; they may use separate URLs and update schedules.

mihomo supports a broad range of rule types and runtime capabilities, but whether a profile works still depends on the core version bundled with the client. When you see unsupported rule type or unknown field errors, confirm which core is actually running instead of checking only the version number of the client shell.

Settings: choosing ports, modes, DNS, and startup options

The Settings page often contains the most options, but most do not need frequent adjustment. The most useful to understand are proxy mode, listening ports, LAN access, DNS, TUN, external control, and launch at startup.

Proxy mode

  • Rule: Uses the rules in the profile to decide whether traffic is direct, rejected, or proxied. This is the most common mode for everyday use.
  • Global: Sends traffic to the global proxy group and is commonly used to temporarily test whether a problem is caused by rule-based routing.
  • Direct: Connects traffic directly and is useful for temporarily bypassing the proxy path for comparison.

Global mode does not automatically send all system traffic into the client; it only changes how traffic that has already entered the core chooses an exit. If neither the system proxy nor TUN is enabled, switching to Global may have no visible effect.

LAN access and external control

Allow LAN connections gives other devices on the same network an opportunity to access the proxy listening port on this machine. Enable it only when proxy sharing is explicitly needed, and use firewall rules, the listening address, and authentication settings to limit access. External control lets the graphical interface or management tools read status, switch strategies, and close connections. It should likewise never be exposed to an untrusted network.

DNS and fake-ip

Clash's DNS module can select upstream servers according to the profile and work with rule matching, domain restoration, and TUN interception. fake-ip mode returns reserved addresses to the app, then lets the core map connections back to the original domain, which helps with domain-based routing. Some LAN services, specialized games, or apps that depend on real DNS results may need to be added to an exclusion list.

Do not troubleshoot DNS by changing several options at once. A safer order is to confirm that the system is sending queries to Clash, check that the upstream DNS is reachable, and then inspect the result for the target domain and its matched rule. A browser's secure DNS feature may also bypass the system resolver and needs to be considered.

Launch at startup and silent startup

Launch at startup only starts the client. Whether it also starts the core, restores the system proxy, or enables TUN depends on separate client settings. When troubleshooting no internet access after a reboot, check whether the client restored the previous toggle states and whether an abnormal exit left the system proxy pointing to a local port.

A repeatable Clash interface troubleshooting workflow

Once you know the pages, common problems can be reduced to a fixed workflow instead of random experimentation with nodes, DNS, and modes.

  1. Check Profiles: Confirm the selected profile, update time, and loading status, and look for syntax or provider errors.
  2. Check Overview: Confirm that the core is running and determine whether traffic is being handled through the system proxy or TUN.
  3. Check proxy mode: Keep Rule for everyday use; briefly use Global or Direct for comparison when testing the effect of routing rules.
  4. Check Proxy: Confirm that the target proxy group has selected a usable node, rather than changing a group unrelated to the target traffic.
  5. Re-establish the connection: Close the target app's old connections so that existing sessions do not continue using the previous exit.
  6. Check Connections: Find the target domain or IP and inspect the matched rule, proxy chain, and actual exit.
  7. Check Logs: Use the failure time to locate DNS, connection, TLS, rule, or permission errors.

If Direct works but Rule does not, focus on the rules and proxy groups. If Global also fails, continue checking the node, DNS, and reachability of the destination. If none of the three modes produces a corresponding connection record, inspect the system proxy, TUN routes, or the app's own proxy settings. This layered approach quickly narrows the problem to the profile, traffic interception, routing, or exit layer.

The Clash client interface is essentially a set of tools for observing and controlling the core. The Proxy page answers “Which exit is being used?”, Profiles answers “Where do the rules and nodes come from?”, Connections answers “Where did this traffic actually go?”, and Logs answers “What happened during execution?” Once you understand these four questions, you can find the corresponding features and complete basic configuration and troubleshooting even when switching platforms or interface layouts.

Continue configuring the Clash client

Choose a client for your current system, then follow the guide to import a profile, select a proxy mode, and check the connection.

Go to Downloads Read the Guide