Clash Client UI Guide: Proxy, Profiles, and Logs Explained

Understand the client’s four-layer structure

Common Clash GUI clients may use different names and layouts, but their core information usually falls into four layers: profiles define available proxy nodes and rules; the proxy page determines which exit a proxy group uses; the connections page shows sessions currently passing through the core; and the logs page records how the core handles those sessions. System proxy, TUN mode, and port settings sit below these layers, directing device traffic into the Clash or mihomo core.

In a desktop client built around the mihomo core, the left sidebar typically includes Overview, Proxy, Profiles, Connections, Logs, and Settings. Some clients call profiles “Subscriptions,” proxy groups “Policies,” or place core controls on a separate Service page. Names vary, but the data flow is largely the same.

Use the Overview page to check whether traffic is arriving

The Overview page usually shows core status, upload speed, download speed, active connections, and memory usage. After enabling the system proxy, open a new webpage. If the connection count rises from 0 to 6 and download speed briefly reaches 320 KB/s, traffic is reaching the core. This only proves that the app and Clash established a connection; it does not by itself prove that the remote proxy node works.

If the Overview page stays at 0 B/s, check the system proxy toggle and listening port first instead of repeatedly switching nodes. If traffic appears but webpages still fail to load, inspect the Proxy, Connections, and Logs pages for node timeouts, DNS failures, or incorrect rule matches.

Proxy page: groups and nodes are different layers

The Proxy page is easy to misread. The larger cards are usually proxy groups; the nodes or nested groups appear after you expand one. These relationships are defined by proxy-groups in the profile. Rules usually point to a proxy group name rather than hard-coding a single node.

For example, a rule may send traffic to “Node Select”; that group may currently choose “Auto,” which in turn selects “Tokyo 02” after a latency test. The resulting chain is “Node Select → Auto → Tokyo 02.” Seeing multiple layers in connection details is normal.

Common proxy group types

• Manual selection: Corresponds to select; the user chooses a node or nested proxy group. The choice persists until the profile reloads, the option becomes unavailable, or the client resets its state.
• Automatic testing: Corresponds to url-test; nodes are measured against a test URL at set intervals, usually selecting a successful result with lower latency.
• Failover: Corresponds to fallback; it prefers the first node in the list that passes the health check.
• Load balancing: Corresponds to load-balance; connections are distributed across available nodes according to the configured strategy.
• Direct and reject: DIRECT connects to the destination directly, while REJECT blocks matching traffic.

How to interpret latency values

Values such as 38 ms, 126 ms, or Timeout beside a node usually come from an HTTP health check. They are not full webpage load times and are not equivalent to an ICMP ping. The test may include DNS, TCP, TLS, and HTTP response time, depending on the configured test URL and client implementation.

A reliable order for switching nodes

1. On the Proxy page, find the main proxy group actually referenced by the rule, such as “Node Select” or “Proxy.”
2. Run a latency test first and exclude nodes showing Timeout.
3. Choose a consistently responsive node rather than comparing only the lowest value from a single test.
4. Open a new browser tab so an old connection does not continue reusing the previous route.
5. Open the Connections page and check whether the new connection chain includes the node you selected.

Profiles: subscriptions, local files, and the active profile

The Profiles page manages the core’s input. A complete profile usually includes ports, DNS, proxy nodes, proxy groups, and rules. A subscription URL is one source of configuration; a local YAML file is another. Adding a subscription to the client only saves the profile entry. The corresponding proxy groups appear on the Proxy page only after the profile is set as active and loaded successfully.

What the information on a profile card means

• Profile name: Identifies the source; it may be generated by the client or edited manually.
• Updated: The time the profile was last fetched or saved successfully; it does not mean every node was working at that moment.
• Update interval: How often the client plans to fetch the subscription again. Common values are 6, 12, or 24 hours.
• Active indicator: Shows that the core is using this profile. Selecting a card without loading it may not change the status.
• Traffic information: Some subscription response headers provide used traffic, total allowance, and expiration time. Without those headers, the client cannot display this information.

A common path is “Profiles” → “New” → “Import from URL.” Paste the subscription URL and save it, then choose “Set as active” or “Enable” from the profile card menu. Some clients use “Subscriptions” → “Add subscription” instead. To refresh a profile, use its update button rather than repeatedly deleting and importing it again.

Local YAML profiles offer precise control

Local files let you inspect and edit fields directly. YAML uses spaces for indentation; tabs or misaligned levels can prevent loading. The simplified structure below illustrates how ports, proxy groups, and rules map to the Settings page, Proxy page, and connection details:

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: example-node
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: Node Select
    type: select
    proxies:
      - example-node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,Node Select
  - MATCH,DIRECT

mixed-port: 7890 means HTTP and SOCKS inbound connections can share port 7890. mode: rule means connections are handled according to rules. The final MATCH,DIRECT is the fallback rule: unmatched traffic connects directly. Real subscription profiles usually include DNS, rule providers, provider definitions, and more proxy groups.

Why the selected node can change after an update

A subscription update may add, remove, or rename nodes. If the node previously selected by a proxy group no longer exists, the core returns to an available option in that group. The exact result depends on client state persistence and the group type. If the Proxy page changes from “Tokyo 02” to “Auto,” the toggle may still work; the new profile may simply no longer contain a node with the same name.

After updating, check three places: confirm the updated time changed on the Profiles page, verify that the proxy group contents refreshed on the Proxy page, and make sure the Logs page shows no profile reload errors. “Download successful” alone is not enough because downloading and loading the profile into the core are separate steps.

Connections: see where a program is actually routed

The Connections page is the most direct place to verify routing results. Each record usually includes the source address, destination domain or IP, network type, upload and download totals, matched rule, proxy chain, and start time. Opening one webpage can create dozens of connections, so filter by domain instead of looking only at the top of the list.

Four fields worth checking

1. Host or destination: Confirm that the record belongs to the website being tested. If only an IP appears, the DNS method or application protocol may not have supplied a domain name.
2. Rule: Shows the matched rule, such as DomainSuffix, GeoIP, RuleSet, or the final fallback rule.
3. Chains: Shows the selection path from proxy group to final node, such as “Node Select → Hong Kong 01.”
4. Process: Displays the process name when supported by the system and permissions. Under TUN mode, process identification depends on the platform and client implementation.

Suppose you open example.com and the connection details show DomainSuffix as the rule and “Node Select → Singapore 03” as the chain. This confirms that the new connection matched the domain rule, entered the intended proxy group, and ultimately used Singapore 03. If the chain shows DIRECT, check the rule order, operating mode, and whether the profile has actually switched.

Existing connections may keep using the old node

Switching a proxy group does not forcibly move already established TCP connections. Browsers may also reuse HTTP/2 or HTTP/3 sessions, so the Connections page can briefly show the old route even after you switch nodes and refresh. Close the relevant connection, open a new private window, or wait for the old session to end before testing again. “Close all connections” interrupts active downloads and other network tasks, so use it carefully.

Logs: locate errors by level and keyword

The Logs page records the core’s activity. During normal browsing, you may see connections, rule matches, and outbound details; configuration or network problems may produce parsing failures, refused connections, timeouts, or failed TLS handshakes. When logs are busy, filter by level first, then search for a domain, port, or proxy group name instead of scrolling line by line.

Three common error patterns

• connection refused: The destination port explicitly rejected the connection. The node service may not be listening, the address may be wrong, or a local control port may not be running.
• i/o timeout: A read or write did not finish within the time limit. Determine whether the delay occurred during DNS, TCP connection setup, the TLS handshake, or the remote response.
• address already in use: Another process is already using the listening port. If the mixed port is set to 7890, check whether another proxy client has claimed 7890.

When troubleshooting, clear the current logs, enable the Info level, and reproduce the issue once. For example, clear the log, visit one destination domain, wait 5 seconds, pause scrolling, and search for that domain. This keeps old entries and background connections from clouding the diagnosis. If Info is insufficient, switch to Debug temporarily; leaving Debug enabled greatly increases log volume.

Settings: system proxy, TUN, and ports each serve a different layer

The Settings page determines how traffic enters the core. The system proxy changes the operating system’s HTTP, HTTPS, or SOCKS proxy settings and works for browsers and desktop apps that honor them. TUN mode creates a virtual network interface with broader coverage and can handle apps that ignore system proxy settings, but it requires the appropriate system permissions and correct routing and DNS configuration.

Do not mix up port fields

• Mixed Port: A combined proxy port, commonly 7890, that accepts both HTTP and SOCKS connections.
• HTTP Port: Used only for HTTP proxying. Some profiles use 7890.
• SOCKS Port: Used only for SOCKS5 proxying; traditional profiles commonly use 7891.
• External Controller: Used by the GUI or Dashboard to control the core. A common address is 127.0.0.1:9090. It is not a browser proxy port.

If the client uses mixed port 7890, a terminal program’s HTTP proxy should usually be http://127.0.0.1:7890, not control port 9090. Use the current profile and Settings page as the source of truth. After changing a port, update the system proxy address, browser manual proxy, and terminal environment variables as well.

Choosing between the system proxy and TUN

For first-time setup, enable the system proxy to verify the basic route. If the browser generates traffic, the selected proxy node works, and the Connections page shows matched rules, the profile and exit are basically functional. If an app ignores the system proxy, consider enabling TUN. This separates an unavailable node from a TUN routing problem.

Some desktop clients must install Service Mode before TUN can be enabled with reliable permissions. A common path is “Settings” → “Service Mode” → “Install,” followed by “Settings” → “TUN Mode.” The exact path depends on the client version. After enabling it, check for a new virtual adapter, verify DNS resolution, and confirm that local network and development services remain reachable as expected.

Complete a UI check in ten minutes

After importing a profile for the first time, follow a fixed sequence. Start with the profile source, then check node selection and the traffic entry point, and finish by validating the result in Connections and Logs. This reduces needless switching between pages.

1. Minute 1: Open Profiles, confirm that the subscription or local file exists, and mark it as active.
2. Minute 2: Run an update, confirm that the updated time changes, and check for profile parsing warnings.
3. Minutes 3–4: Open Proxy, run a latency test for the main proxy group, and choose a node with stable responses on two consecutive tests.
4. Minute 5: Open Settings, confirm that the core is running, and verify that the mixed port matches the system proxy address.
5. Minute 6: Enable the system proxy and visit a test page in a new browser window.
6. Minutes 7–8: Open Connections, filter by the destination domain, and check the matched rule and final node.
7. Minute 9: Return to Overview and confirm that the connection count and upload/download traffic change.
8. Minute 10: Open Logs, filter for Warning and Error, and check for recurring port, DNS, or timeout errors.

Return to the relevant page based on the symptom

Once the interface is clear, troubleshooting can be reduced to one chain: Profiles confirms “what loaded,” Proxy confirms “what was selected,” Settings confirms “how traffic enters,” Connections confirms “what was actually used,” and Logs explains “why it succeeded or failed.” These five questions map to five pages and cover most first-connection problems.