How to Navigate the Clash Client Interface: Proxy, Profiles, and Logs Explained

Start with a map of the client interface

A Clash graphical client is usually not the proxy service itself. It is the management interface for the core, configuration files, and system network settings. Sidebar names and layouts vary between clients, but the main sections are broadly the same: Overview handles switches and status, Proxy handles policy selection, Profiles handle subscriptions, Connections show active traffic, Rules explain matching results, Logs record core activity, and Settings manage local options such as ports, TUN, and launch at startup.

When opening the client for the first time, there is no need to change every setting. A safer sequence is to import a profile first, confirm that policy groups appear on the Proxy page, and then enable the system proxy. When something goes wrong, check Connections, Rules, and Logs in that order. This separates three questions: whether the profile is valid, whether traffic reached the core, and how the request was handled.

Overview: switches, ports, and runtime status

What the system proxy switch controls

The most frequently used control on the Overview page is the “system proxy” switch. When enabled, the client points the operating system’s HTTP and HTTPS proxy settings to a local listening port such as 127.0.0.1:7890. Browsers and desktop apps that follow system proxy settings then send requests to the Clash core, which uses its rules to decide whether to connect directly, reject the request, or forward it through a policy group.

The system proxy switch is separate from the core switch. Some clients start the core and listen on a port in the background while leaving the system proxy disabled. In that state, apps with a manually configured proxy can use the core, while ordinary browser traffic may bypass it. Turn off the system proxy before quitting the client so the system settings return to normal; well-designed clients usually restore them during a normal exit.

Mixed, HTTP, and SOCKS ports

A common configuration uses mixed-port: 7890, allowing the same port to accept both HTTP and SOCKS5 requests. Other setups use separate ports such as port: 7890 and socks-port: 7891. Port numbers are not universal standards, so follow the current client settings and active configuration. If another program is already using 7890, the core may fail to start; the Logs page will typically report that the address is in use or that listening failed.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

The example above means that the core provides a mixed proxy port on local port 7890, runs in rule mode, and exposes its control interface at 127.0.0.1:9090. The control interface lets the graphical client read connection, rule, and traffic status; it is not the proxy port to enter in a browser.

Mode selection is not node selection

• Rule mode: Matches rules from top to bottom. Requests may use direct, proxy, or reject policies, making this the best choice for everyday use.
• Global mode: Sends traffic through the global policy group, which is useful for temporarily testing whether a node can reach a target.
• Direct mode: Connects to the target without using a proxy node, making it useful for comparing network behavior.

The mode determines how rules handle traffic; it does not automatically choose the best-performing node. Even in rule mode, open the Proxy page and check which option each relevant policy group currently uses.

Proxy page: switching policy groups and nodes

Identify the policy group before choosing a node

The Proxy page usually displays several policy groups as cards or lists. A policy group is an exit selector defined by the configuration author. Names may include “Node Selection,” “Auto,” “Streaming,” or “Final.” Entries can be actual nodes or other policy groups, so the selection path shown in the interface may have two or three levels.

For example, a rule may send a domain to the Proxy group, while Proxy currently selects Auto, and Auto then chooses a node through latency testing. Changing an unrelated group will not affect that domain. Start with the policy name matched by the rule and follow the group references until you reach the final exit.

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Auto
      - DIRECT
      - Node-A

  - name: Auto
    type: url-test
    proxies:
      - Node-A
      - Node-B
    url: https://www.gstatic.com/generate_204
    interval: 300

A select group requires manual selection; a url-test group chooses automatically based on test results; fallback prioritizes availability and switches when the current node fails; and load-balance distributes connections across multiple nodes according to its configured strategy. The graphical client only presents these structures; actual behavior comes from the core and the configuration.

How to interpret latency values

The test value on the Proxy page is usually the time required to reach a specified test address from this device through a node, measured in milliseconds. A reading of 80 ms means the probe took about 0.08 seconds; it does not represent a fixed download speed. A node can have low latency but limited bandwidth, or pass the probe while connections to the target website still fail.

• Repeated tests are more useful than a single result. Watch three tests a few seconds apart to filter out brief fluctuations.
• If the result shows “Timeout,” update the profile first, then check the node’s validity period and the local network instead of repeatedly clicking Test.
• Switching nodes affects only new connections. Existing long-lived connections may continue using the previous exit.
• To verify a new node immediately, close the old connection on the Connections page and reload the target page.

Profiles: importing, updating, and switching subscriptions

The Profiles page stores the active configuration

The Profiles page is also commonly labeled “Subscriptions.” A profile typically includes listening ports, DNS, nodes, policy groups, and rules. The client selects one profile as active and passes the processed configuration to a compatible core such as Clash Meta (mihomo). If the Proxy page is empty, policy groups are missing, or the mode cannot be changed, first confirm that a profile has been activated successfully.

A common import path is “Profiles” → “New” → “URL”: paste the subscription URL and save it. Some clients use “Subscriptions” → “Add Subscription” instead. To import a local file, select a YAML file. After importing, click the profile or choose “Set as Current Profile” to activate it. Downloading a file into the list does not always replace the profile currently in use.

What the Update button does

1. The client requests the subscription URL and downloads the latest content.
2. It identifies or converts the response format, depending on the client’s capabilities.
3. It saves a new local copy and reloads the core according to the client settings.
4. The Proxy page rebuilds its policy groups and node list.

A normal small profile usually updates within a few seconds. If the Proxy page does not change afterward, switch to another profile and back, or check the Logs page for YAML parsing errors, network timeouts, or unexpected HTTP status codes. Subscription URLs are sensitive configuration data; do not paste them into public screenshots, shared logs, or support discussions.

What to check when a profile update fails

If the client offers overrides, scripts, or profile merging, leave them disabled while getting started. An override can change DNS, rules, and policy groups, so troubleshooting then requires understanding both the original subscription and local modifications, which adds considerable complexity.

Connections and Rules: trace where a request went

The Connections page answers three practical questions

The Connections page lists active or recently established network connections. Common columns include the target domain, target IP, protocol, rule, policy chain, upload and download totals, and connection time. Use it to confirm whether a request reached Clash, which rule matched it, and which node was ultimately used.

• No new records appear: The application may not be reading the system proxy settings, or it may require TUN to take control.
• The record shows DIRECT: The rule classified the request as a direct connection, so switching an ordinary proxy group will not change the result.
• The policy chain shows several names: The request passed through nested policy groups; the final node is usually the actual exit.
• Download traffic keeps increasing but the page never finishes: The connection is established, so check DNS, the target’s response, or the application’s own state.

Many clients let you end an individual connection or close all connections from the Connections page. After switching nodes, close old connections and reopen the page to prevent HTTP/2, WebSocket, or download tasks from reusing the previous connection. Closing all connections interrupts active downloads, sync jobs, and calls, so make sure no important task is running first.

The Rules page shows matching order

Clash evaluates rules in the order listed in the configuration and usually stops at the first match. Common rule types include DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, IP-CIDR, GEOIP, and the final catch-all rule MATCH. The Rules page helps explain why a domain used a direct connection or a particular group.

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.net,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

In the configuration above, example.com connects directly, example.net and its subdomains go to Proxy, private network addresses connect directly, and other requests that matched nothing earlier ultimately enter Proxy. If a broad rule appears before a more specific one, the later rule may never run.

Logs: find problems by level and keyword

Choose an appropriate log level first

Common log levels include silent, error, warning, info, and debug. info is usually enough for everyday use; switch temporarily to debug when investigating a complex connection problem. Debug logs arrive faster and include more domains, target addresses, and connection details. Restore info after troubleshooting.

In common desktop clients, adjust this under “Settings” → “Clash Settings” → “Log Level”; some interfaces place it under “Settings” → “Core Settings.” After changing the level, reproduce the problem once instead of searching through a large history. Note the exact time—for example, open the target app at 14:32:10—then inspect logs after that timestamp.

How to read common log messages

An error log describes what happened at a particular moment; it is not necessarily the root cause. For example, a connection timeout may result from an unreachable node, or DNS may have returned an unusable address first. During troubleshooting, consider the surrounding log lines, the policy chain on the Connections page, and the active profile together.

Settings: TUN, LAN access, and startup options

When should TUN mode be enabled?

The system proxy depends on an application reading the operating system’s proxy settings. Some games, command-line tools, store apps, and software using a custom network stack may ignore them. TUN mode takes over a broader range of traffic at the IP layer through a virtual network interface, but it also involves administrator permissions, routing tables, DNS interception, and compatibility with other VPN software.

A common path is “Settings” → “Clash Settings” → “TUN Mode”; some clients first require service mode to be installed. The first activation may trigger a system permission prompt. If the system proxy already covers the target app, there is no need to switch to TUN for “more speed.” TUN expands traffic coverage; it does not directly increase node bandwidth.

• The network goes completely offline after enabling it: turn off TUN first, then check the virtual adapter, DNS settings, and conflicts with other VPNs.
• LAN devices cannot connect: check the route exclusions and keep common private network ranges on direct connections.
• The network behaves abnormally after the client exits: reopen the client, disable TUN normally, then check the system routes and DNS.
• Only one program bypasses the proxy: watch the Connections page first; consider TUN only if no record appears.

What allowing LAN connections means

allow-lan: true allows other devices on the same local network to access the proxy port listened on by the client. You must also check the bind address, firewall, and device IP. For example, if the computer is 192.168.1.20 and the mixed port is 7890, manual proxy settings on a phone typically use server 192.168.1.20 and port 7890, not 127.0.0.1.

LAN sharing is suitable only for trusted networks. If the client supports local proxy authentication, set a username and password as well. When leaving a home or office network, disable LAN access or use the system firewall to restrict which network ranges can connect.

Complete first-use workflow

1. Open Profiles and import a valid profile from a URL or local YAML file.
2. Confirm that the profile is marked as current and check its latest update time.
3. Open Proxy, confirm that policy groups and nodes are visible, and run a latency test.
4. Choose a node or an automatic selection group in the main selection group.
5. Return to Overview, keep Rule mode selected, and enable the system proxy.
6. Open a browser and visit the target page while watching for a new record on Connections.
7. If the connection fails, check the matched rule, policy chain, and corresponding time range in Logs.
8. Evaluate TUN mode only if the target application does not read the system proxy settings.

This sequence separates profiles, policies, traffic capture, and troubleshooting into independent steps. If the Proxy page shows nodes but the browser creates no connection records, the issue is likely with the system proxy or application capture. If a record exists but the policy is DIRECT, check the rules. If the policy is correct but the request times out, continue with the node, local network, and DNS.

The core idea behind interface troubleshooting

The pages in a Clash client are interconnected. Profiles provide rules and policy groups; Proxy determines the selection within each group; Overview controls whether the system sends traffic to the core; Connections shows the live result; and Logs record error details. Follow this chain one layer at a time instead of repeatedly reinstalling the client or changing several settings at once.

Daily use usually requires only Profiles, Proxy, and Overview; Connections, Rules, and Logs mainly explain problems. Once you know what question each page answers, you can quickly find the equivalent feature even after switching to a Clash Meta (mihomo) client with a different menu layout.