How to Read the Clash Client Interface: A Practical Guide to the Proxy, Config, and Logs Pages

Understand the Interface, Core, and Config File

A Clash client typically has three layers: the graphical interface displays buttons and status, the Clash Meta core (now commonly known as mihomo) handles connections, DNS, and rule matching, and the YAML configuration file defines ports, nodes, proxy groups, and rules. Clicking “Node A” in the interface essentially sends a proxy-group selection to the core’s control API; clicking “Update Subscription” downloads the remote config and tells the core to reload it.

Different clients may label sections “Proxy,” “Strategy,” or “Proxies,” while “Config” may appear as “Subscriptions” or “Profiles.” Button locations also vary between desktop and mobile apps, but the underlying relationships are largely the same. When reading the interface, do not rely only on icon positions. First identify whether the current area controls the core, manages configuration, or displays runtime logs.

What the top status area usually shows

• Runtime status: Whether the core has started. An open interface does not necessarily mean the core is running.
• System proxy: Whether Windows, macOS, or the desktop environment routes its HTTP proxy through a local listening port.
• TUN mode: Whether a virtual network interface is used to handle traffic from more apps that do not read system proxy settings.
• Traffic statistics: Current upload and download speeds, plus total traffic. These figures are measured by the client and are not the same as an internet speed test.
• Active connections: The number of TCP and UDP connections currently maintained by the core. Reused connections may remain for a while after a webpage is closed.

For a typical desktop setup, the mixed proxy port might be 7890, while the external controller port might be 9090. Older configs often place HTTP and SOCKS on 7890 and 7891. These are common values, not fixed standards. Check “Settings” → “Network” → “Port Settings,” or read mixed-port, port, and socks-port in the active YAML.

Proxy Page: Proxy Groups, Nodes, and Latency

The Proxy page is more than a simple server list. It first shows the proxy groups defined in the config, then lists selectable nodes or nested proxy groups inside each one. Rules ultimately point to proxy-group names, and the group decides which node handles the connection. Once this relationship is clear, it becomes easier to understand why changing one node affects only some traffic.

How to read a proxy-group card

A proxy group usually has a name, type, current selection, and list of candidates. For example, rules may send streaming domains to “Streaming,” while the “Streaming” group currently selects “Hong Kong Node.” Changing the “Node Selection” group may have no effect on streaming if the two rules point to different groups.

• select: Manual selection. New connections will usually use whichever candidate you click.
• url-test: Tests candidates at the configured interval and automatically selects the node with the lower test result.
• fallback: Checks candidates in order and prefers the first node that passes the availability test.
• load-balance: Distributes different connections across multiple candidates according to the configured strategy. It does not directly combine their bandwidth for a single download.

DIRECT sends the connection directly through the local network, while REJECT blocks it. Both are built-in strategies, not remote servers. If an ad domain matches REJECT, the logs may show a blocked connection, while the Proxy page will not display node latency.

Latency results are not bandwidth

Numbers such as 68 ms and 214 ms beside a node usually represent the time taken to make an HTTP request to a test URL. They show connection responsiveness at that moment, not download speed. The test URL, DNS resolution, TLS handshake, node load, and local Wi-Fi can all affect the result. An 80 ms node may deliver higher throughput than a 50 ms node.

1. Test one proxy group at a time and wait for all candidates to return results.
2. Retest nodes that time out to rule out temporary packet loss.
3. After selecting a candidate, reopen the target website so the new connection uses the new strategy.
4. If the old page still uses the previous node, terminate the relevant connection on the Connections page or wait for it to close naturally.

Config Page: Subscriptions, Active Configs, and Overrides

The Config page manages configuration sources. Common entries include remote subscriptions, local YAML files, temporary client-generated configs, and runtime configs after overrides are applied. A client can store multiple configs, but the core usually loads only one active config at a time.

What the actions on a subscription card do

• Enable or set as active: Loads this config into the core. If loading fails, the client may keep the previous working config.
• Update: Requests the subscription URL again to retrieve the latest remote content. Updating does not necessarily switch to that config.
• Edit details: Changes the name, update interval, or subscription URL. It usually does not edit the node content returned by the remote service.
• View file: Opens the downloaded YAML for checking fields and syntax. Whether edits can be saved depends on the client.
• Delete: Removes the local config entry. If it is active, switch to another config that loads successfully first.

After updating a subscription, check whether the “Last Updated” time changed, then verify the node count and proxy groups. If the timestamp changes but the content does not, the remote service may have returned the same config. For HTTP 401, 403, or 429 errors, check subscription permissions, link expiry, and request frequency. If the download succeeds but loading fails, inspect the YAML syntax and field compatibility.

Overrides vs. direct editing

A remote subscription is downloaded again the next time it updates, so direct edits to its cached file are often overwritten. Overrides are applied after the subscription downloads and before the core loads the config, making them better for preserving local port, DNS, or TUN settings. Depending on the client, the entry point may be under “Config” → “Overrides” or in the card’s more-actions menu.

mixed-port: 7890
mode: rule
log-level: info
allow-lan: false

external-controller: 127.0.0.1:9090

This general config keeps the mixed proxy listener on local port 7890, uses rule mode, sets the log level to info, prevents devices on the local network from directly accessing the proxy port, and binds the controller only to the loopback address. If the port shown in the interface differs from the file, check whether the client generated a separate runtime config through an override.

Logs Page: Reconstructing a Connection from One Record

The Logs page displays core events. It includes runtime messages such as config loading, listening ports, and DNS initialization, as well as connection targets, matched rules, and proxy paths. When the client says it is connected but a website will not open, the logs are usually more informative than latency figures on the Proxy page.

Choosing a log level

• error: Shows only clear errors, such as a failed port bind, config parsing failure, or failed network request.
• warning: Shows issues that may affect operation without necessarily stopping it immediately.
• info: The best default for everyday troubleshooting. It usually shows connection targets, matched rules, and outbound strategies.
• debug: Records more detailed internal activity. Use it briefly for complex issues; leaving it enabled can generate a large volume of logs.
• silent: Minimizes log output and is not suitable for troubleshooting.

A common path is “Settings” → “Preferences” → “Log Level” → “Info.” When you need DNS or TUN details, switch temporarily to Debug, reproduce the issue once, then return to Info. Menu labels vary by client, but the underlying field is usually log-level.

What clues are contained in one connection log

TCP 127.0.0.1:53142 --> example.com:443
match DomainSuffix(example.com)
using ProxyGroup[Hong Kong 01]

The first line indicates that a local process accessed example.com:443 over TCP; the second shows a domain-suffix rule match; the third identifies the proxy group selected by the rule and the final choice. Actual mihomo log formats vary by version and client wrapper, but look for four details: protocol, destination, matched rule, and outbound path.

1. Clear the current logs to avoid confusion from older records.
2. Close the target app’s existing connections and reopen the target page.
3. Filter by domain, destination IP, or port—for example, search for :443.
4. Confirm whether the record shows DIRECT, a proxy group, or REJECT.
5. If there are no records at all, check whether the app reads system proxy settings or whether TUN needs to be enabled.

How the Connections Page Works with the Three Main Pages

Many clients also provide a Connections page. It shows the source address, destination host, download and upload volume, rule, and proxy chain for active connections. Logs focus on the event stream, while the Connections page focuses on current state. Together, they explain why an old download may continue using the previous path after switching nodes.

Suppose a browser has already established an HTTP/2 long-lived connection through “Node A.” If you switch to “Node B” on the Proxy page, the existing connection usually will not migrate. The Connections page will still show the old path, while newly opened connections use Node B. Terminating a connection interrupts the current request and may also stop a file transfer or live call, so do not treat “Close All” as a routine refresh button.

System Proxy vs. TUN in the Interface

System proxy mode usually works well for browsers and apps that follow the operating system’s proxy settings. In Windows 11, check the status under “Settings” → “Network & Internet” → “Proxy”; in macOS, verify it under “System Settings” → “Network” → “Current Network” → “Details” → “Proxies.” After enabling the system proxy in the client, the address typically points to 127.0.0.1 and the current HTTP or mixed port.

TUN mode uses a virtual network adapter to handle more traffic, including apps that ignore system proxy settings, some command-line programs, and UDP-dependent workloads. Desktop systems may request administrator privileges the first time it is enabled. If the network stops working completely after enabling TUN, check that the virtual interface was created, the default route was added, DNS is handled by the core, and no other VPN or network-filtering software is modifying routes at the same time.

Interface Checks After a Fresh Install

When opening the client for the first time, there is no need to change complex rules immediately. Establish one short, verifiable path: load a config, start the core, choose a strategy, enable traffic capture, and inspect the logs. This sequence applies to Windows 11 24H2, macOS, and common Android clients; the system controls the exact permission prompts.

1. Open the Config page: Import a subscription or local YAML, confirm that it parses successfully, and verify that the proxy-group and node counts look right.
2. Set it as the active config: Watch the top status area and confirm that the core is running, rather than merely confirming that the file downloaded.
3. Open the Proxy page: Run a latency test on the candidate nodes, then select a responsive node in a manual-selection group.
4. Enable the system proxy: On desktop, use it first to verify browser traffic. The listening address should be local, and the port should match the Settings page.
5. Open the Logs page: Keep the level at Info, visit a new domain, and confirm that the target, rule, and strategy appear in the records.
6. Enable TUN when needed: Use it only when an app ignores system proxy settings, requires UDP handling, or needs centrally managed traffic.

Common Interface Symptoms and What to Check

• Node latency looks normal, but webpages will not open: Check the strategy actually matched in the logs, and confirm that DNS resolution and the destination port did not fail.
• Subscription updated successfully, but the Proxy page is empty: Check that the active config switched successfully and that the YAML contains proxy-groups.
• The entire network goes offline after enabling the system proxy: Confirm that the core is running, the proxy port is not occupied, and the system proxy address matches the listening port.
• Switching nodes makes no difference: Close existing connections and try again, then confirm that the target traffic uses the proxy group you just changed.
• No target records appear in the logs: Check whether the app bypasses the system proxy. For games or standalone updaters, test TUN after confirming the config.
• Startup reports address already in use: Check whether 7890, 7891, or a custom port is occupied by another client or a leftover core process.

From Interface Actions to Reading the Config

Once you understand the three pages, map each click back to YAML. The Proxy page comes from proxy-groups and proxies; the Config page manages the file and its update source; and the Logs page presents rules matching results. System proxy and TUN determine whether traffic enters the core in the first place. This approach avoids depending on the fixed layout of any particular client version.

Keep a validation loop when editing configuration: after saving, confirm that the config reloads; open the Proxy page and verify that the proxy groups still exist; then use the logs to confirm that the target domain matched the expected rule. If something breaks, roll back to the last working config instead of stacking more changes onto a file that will not start.