Clash Client Interface Guide: Proxies, Profiles, and Logs Explained

First, understand the difference between the client interface and the proxy core

A Clash client typically has two parts: a graphical interface and a proxy core. The interface imports subscriptions, displays proxy groups, and lets you change settings. The core listens on local ports, matches rules, and establishes connections. An open window doesn’t mean the core is running, and a visible node list doesn’t mean app traffic is reaching the core.

Clients built on Clash Meta (now mihomo) may offer options such as TUN, process-based rules, and different enhanced DNS modes. Available features depend on the core and the client implementation. This guide explains features by function; it doesn’t treat any one client’s layout as universal. Desktop apps often use a sidebar, while mobile apps may use bottom tabs or a drawer menu. If you can’t find a button by name, use the table below to locate the equivalent feature.

Overview: Check core status first, then traffic capture

A running core doesn’t mean the system proxy is enabled

The Overview page usually shows real-time upload and download speeds, total traffic, and runtime status. A speed of zero only means there’s no traffic within the current measurement scope; it doesn’t, by itself, mean a node is down. For a first-time setup, check that the core is running, then confirm how your apps send traffic to the client.

• System proxy: Registers a local proxy address with the operating system. Only apps that follow the system proxy settings will use it; some games, command-line tools, and apps with their own proxy settings won’t.
• TUN mode: Uses a virtual network interface to capture traffic that matches the routing rules. It may require administrator privileges or service support, and is still affected by route exclusions, DNS, and client settings.
• Allow LAN: Lets other devices access the proxy listening on this computer. It isn’t required for this computer’s browser to connect to the internet. Before enabling it, check the listening address, firewall, and access controls.

Look under “Overview” → “System Proxy” for the system proxy toggle; some clients put it in the tray icon’s right-click menu. TUN is often under “Settings” → “TUN Mode.” These paths are meant to help you find the features; menus vary by client. Don’t confuse “System Proxy” with “TUN”—they’re separate settings.

What ports and proxy modes do

The local port is where apps connect. For example, if Settings shows the mixed port as 7890, enter 127.0.0.1 and port 7890 when manually configuring an app that supports HTTP proxies. These are example values, not defaults for every client; use the port shown in your app. A mixed port usually supports both HTTP and SOCKS. Separate HTTP and SOCKS ports must match the proxy type selected in the app.

Rule, Global, and Direct are separate concepts. Rule mode routes traffic according to rules. Global mode typically sends traffic through the selected global policy; it doesn’t mean every app is captured. Direct mode sends connections that have reached the core straight out. Rule mode is a good starting point for everyday use; switch to Global temporarily only when you need to rule out rule-matching issues.

Profiles: Make sure the subscription is updated and active

The Profiles page manages the source of the full configuration, not individual nodes. A profile may come from a subscription URL or a local YAML file. It can include proxy groups, rules, DNS settings, and rule-set references as well as nodes. A successful import only means the client received the profile; also confirm that it parsed successfully, is selected and active, and finished updating.

1. Open “Profiles” and use the import option to add a subscription or local file.
2. Check the profile’s last-updated time, status, or error message. A subscription update timeout and a YAML parse failure are different issues.
3. Select the profile or choose “Enable,” then confirm that the active indicator has moved to that profile.
4. Open Proxies to check that the groups and nodes appear. Then open Rules and confirm the rules look as expected.

Some clients apply a profile automatically after a successful update; others require a manual reload. If the node list doesn’t change after an update, first check which profile is active instead of importing another copy. Multiple profiles with similar names make it easier to select the wrong one and can create the impression that file changes aren’t taking effect.

The original subscription, overrides, and running config may differ

A graphical client may override subscription settings such as ports, DNS, or TUN, or provide features for merging and processing configs. The original subscription therefore may not match the config ultimately passed to the core. When troubleshooting, look for options such as “Running Config” or “View Effective Config” to check the final values. These options aren’t available in every client.

Don’t edit a temporary generated config file to save settings long-term; it may be regenerated on reload. The subscription file itself may also be replaced during an update. Put persistent changes in a client-supported override, or maintain a separate local config after making a backup.

Proxies: You may be selecting a proxy group, not an individual node

The Proxies page usually lists proxy groups first, followed by their available options. A group can contain nodes, other proxy groups, and built-in policies such as DIRECT. Whether selecting a node affects a particular website depends on whether the matching rule points to that group. Changing a group that the current connection doesn’t use won’t change its route.

Latency isn’t a download speed ranking

Suppose, in the same test, Node A shows 65 ms and Node B shows 120 ms. That only means they took different amounts of time to complete that probe. These figures are illustrative, not results measured by this site. The test URL, DNS, handshake, and current network conditions all affect the result; it doesn’t tell you video throughput or how well gaming traffic over UDP will perform.

A timeout doesn’t necessarily mean the node is completely unusable; the test destination may simply be unreachable. First check the test URL in the config, then verify with the service you actually need. After switching manually, start a new request. Existing long-lived connections usually won’t move to the newly selected option automatically.

Rules: Check matching order, not just the rule count

The Rules page shows the routing rules currently loaded. Rules are generally evaluated in order; the first match determines which policy is used. Domain suffix, IP range, and final fallback rules serve different purposes. A large number of rules doesn’t guarantee that traffic is routed as intended. The example below illustrates rule logic; it’s not a complete config to replace your subscription with.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

The first rule sends matching domains direct. The second matches the specified private IPv4 ranges and uses no-resolve to avoid triggering a DNS lookup just for that rule. The final rule sends anything not yet matched to the policy named PROXY. If your actual config doesn’t define that policy, you can’t use the example as-is.

example.com is a documentation example domain. When troubleshooting, use the destination domain shown on the Connections page. A web page may request several domains for sign-in, images, APIs, and more; checking only the main domain in the browser’s address bar can miss the request that actually failed.

For configs that use RULE-SET, also confirm that the referenced rule sets loaded successfully. A reference on the Rules page doesn’t mean a remote rule set has finished downloading. Check the Connections and Logs pages to verify both the rule definition and the rule that a connection actually matched. For more on config structure, see the handbook’s guide to proxy groups.

Connections: Verify the route a request actually took

The Connections page is the most direct way to verify routing. Common fields include destination host and port, source address, network type, matched rule, proxy chain, and upload and download totals. Some clients also show the process name, depending on system permissions and core capabilities. A blank process field doesn’t, by itself, mean the connection is faulty.

1. Pause unrelated downloads to reduce clutter. You can clear the displayed records, but note that “Clear records” and “Close connections” are different actions.
2. Open the website you want to test, then filter by domain or process right away.
3. Check the destination port—for example, HTTPS commonly uses 443—then verify the rule and proxy chain.
4. If you changed a node or rule, close the corresponding existing connection and refresh the page to create a new one.

If the target request doesn’t appear at all, check the traffic capture path first: does the app follow the system proxy, have its own proxy configured, or fall within the TUN routes? If the request appears and its proxy chain ends in DIRECT, investigate the matched rule instead of repeatedly testing node latency.

A browser request may use both TCP and UDP. Requests using HTTP/3 may also appear under UDP connections. If a connection shows traffic but images are still missing, check the failed resources individually; one successful connection to the main page doesn’t mean every resource loaded successfully.

Logs: Find errors by time, not just by searching for red entries

The Logs page records events, not a complete browsing history. Common log levels include error, warning, info, and debug; available options depend on the client and core. Use Info for routine checks. Turn on Debug briefly when you need more detail, reproduce the issue, then switch it off to keep large volumes of logs from burying useful entries.

A timeout can refer to a subscription download, a connection attempt to a node, or a DNS query. Read the entry alongside its timestamp, component, and destination address. Note when you refresh or switch nodes, reproduce the issue once, then review the logs from about 10 seconds before and after. Avoid changing several settings at once, or you may lose track of the cause.

A complete check: from importing a profile to confirming a match

For a first-time setup, follow the steps below in order. Verify one thing at a time. If something fails, troubleshoot it on the relevant page before moving on; there’s no need to change DNS, TUN, rules, and nodes all at once.

1. Profiles: The subscription imported successfully, the active profile is enabled, and the update completed without errors.
2. Overview: The core is running, the local port matches your app settings, and one clear traffic capture method is selected for testing.
3. Proxies: Check the target proxy group and confirm its final selection is an available node or the intended policy.
4. Rules: Confirm that the relevant rules are present and in a sensible order, and that rule sets have loaded.
5. Connections: Start a new request and verify the destination, matched rule, and final route.
6. Logs: If the request fails, check the entries around the same time for DNS, connection, or config errors.

Keep in mind what each page can tell you: Profiles shows “what was loaded,” Proxies shows “what’s selected,” Rules shows “how traffic is routed,” Connections shows “what actually happened,” Logs shows “where errors occurred,” and Overview helps check runtime status and traffic capture. To continue checking browser and system network settings, follow the connection troubleshooting steps.