What to look at first: the overall layout of the main window
The shell design differs slightly between Clash clients (whether built on the original core or on Clash Meta/mihomo), but the functional layout of the main interface is broadly the same. It's usually split across a sidebar or tab bar into sections: Overview (or Home), Proxies, Profiles, Rules, Connections, Logs, plus a Settings page. For beginners, only three of these need to be opened daily: the Proxies page for picking nodes, the Profiles page for managing subscriptions, and the Logs page for checking issues. Getting familiar with these three covers roughly ninety percent of everyday use.
Before diving in, one thing worth understanding up front: the client itself is just a graphical shell. The actual traffic forwarding and rule matching happens in the underlying core program (the engine). Every toggle and every log line you see in the interface is really a display of the core's state or an edit to the core's configuration. Once that clicks, when you run into "the interface looks fine but nothing connects," you'll know to dig into the core's logs instead of just restarting the interface over and over.
Proxies page: node groups, latency tests, and manual switching
The Proxies page is the most frequently used panel, and its core unit is the "proxy group." A subscription profile usually comes pre-divided into several groups — for example, groups by region such as "Hong Kong Nodes" or "Japan Nodes," or groups by purpose such as "Global Proxy," "Streaming Unlock," or "Ad Block." Each group contains specific nodes plus a strategy type that determines how selection works.
- select groups: manual selection — whichever node you click is the one used. Good for cases where you already know which route you want.
- url-test groups: automatic speed testing — the client periodically runs latency tests against the nodes in the group and automatically switches to the best-performing one.
- fallback groups: primary/backup — the node higher in the list is preferred, and the client falls back down the list only when the current one becomes unavailable.
- load-balance groups: load balancing — different connections are spread across multiple nodes according to a set rule.
On the Proxies page, each node usually shows a latency figure in milliseconds. This number comes from the client's own round-trip test request to the node — lower generally means faster response, but low latency doesn't equal fast download speed; these are two separate metrics. Treat latency as a first-pass filter when picking a node, and rely on actual use over time to judge speed and stability. Clicking the "Test" button triggers a manual round of batch testing; some clients also let you configure the automatic testing interval from the Settings page.
Manually switching nodes is straightforward: open the relevant group and click the node you want to use. The switch usually takes effect immediately, with no need to restart the client or reconnect the system proxy. If pages still won't load after switching, the issue is most likely not the node itself but the system proxy toggle or a routing rule — in that case, head to the Logs page to check the actual connection record.
Profiles page: subscription management, update cycles, and switching between profiles
The Profiles page (sometimes labeled "Subscriptions" in some clients) manages full YAML configuration files, each of which bundles node information, group settings, and routing rules. For most people, a profile comes from a subscription link provided by a proxy service or a self-hosted node provider; the client periodically requests this link to fetch the latest node list.
This page mainly handles three things:
- Adding a subscription: after pasting the subscription link, the client downloads and parses it once to generate a usable profile entry.
- Manual/automatic updates: subscription content isn't static — providers swap nodes or adjust bandwidth allocation from time to time. The Profiles page usually offers an "Update Now" button, and you can also set an automatic update cycle, commonly refreshing once a day or every few hours.
- Switching between profiles: if you've saved multiple subscriptions or custom profiles, the Profiles page lists them all; clicking one switches to it, and the one currently active is usually marked clearly.
One thing to note: after switching profiles or updating a subscription, whatever node you'd manually selected on the Proxies page is usually reset back to the group's default option. This is because the groups and node list in the new profile may have changed, and the client won't force-keep the old selection. If "the node reverted to default after updating the subscription," that's normal behavior — just go back to the Proxies page and reselect.
Profiles also often include DNS settings and TUN mode fields. TUN mode works by creating a virtual network adapter at the system network layer to take over all traffic; compared with the regular system-proxy mode, it has broader coverage and can handle traffic from apps that don't respect system proxy settings. The corresponding toggle and status are usually found on the Settings or Overview page rather than on the Profiles page itself — the Profiles page's job is simply to have these fields take effect along with the subscription.
Logs page: connection records, rule matches, and troubleshooting clues
The Logs page is where you should go first when troubleshooting — not the Settings page. It records the real-time process of every network connection the client handles. A typical log line looks roughly like this:
[Info] [TCP] example.com:443 match Rule(DOMAIN-SUFFIX,example.com) using HK-Node01Breaking this down, the line tells you four things: the destination address and port of the connection, which routing rule it matched, exactly how that rule matched (here, by domain suffix), and which node ultimately handled the connection. Once you can map these four pieces, you can usually tell "why a particular site went through this node" or "whether a rule is actually taking effect."
The Logs page typically also supports filtering by log level, commonly ranging from low to high: Debug, Info, Warning, Error. When troubleshooting a connectivity issue, switching to Debug reveals a fuller picture of the connection attempt — including failed connection setups, DNS resolution errors, and other details — which speeds up diagnosis noticeably, though the log will also refresh much faster. It's worth switching back to the default level once you're done, so it doesn't keep consuming resources.
Another common need is checking the "Connections" panel (some clients split the connection list and logs into separate sub-pages). The Connections panel shows a list of active and past network connections, including each connection's source process, destination address, node used, and cumulative traffic — useful for confirming whether traffic from a specific app (say, a browser or some other client software) is actually going through the proxy rather than bypassing it with a direct connection.
Suggested troubleshooting order: check the Logs page first to confirm whether the connection matched the expected rule, then go back to the Proxies page to confirm the selected node in the group is actually usable, and only then check the system proxy or TUN toggle status. Doing it in reverse order tends to waste time on unrelated steps.
A few tips for using the three panels together
Once you're familiar with what each of the three panels does, here are a few practical combos for everyday use.
The latency test on the Proxies page keeps showing timeouts — does that mean the node is dead?
Not necessarily. A timeout could mean the node really is unavailable, or it could mean the test target address itself is restricted in your current network environment, or that a temporary local network glitch caused a single test to fail. Try re-testing manually once or twice; if it keeps timing out and the Logs page also shows failed connection records for that node, then it's reasonable to treat it as a node issue and switch to another node in the group.
After updating a subscription, the custom rules I'd saved earlier are gone from the Profiles page — what happened?
If the custom rules were written directly into the subscription's profile file, updating the subscription pulls the latest content from the remote source and overwrites any local manual edits. To keep custom rules intact, you generally need to use the client's "override" or "extra rules" feature to store custom content separately, so it doesn't get mixed in with the subscription's main profile during updates.
The Logs page has too much information to sort through — is there a way to view records for just one node or one rule?
Some clients' Logs pages support keyword filtering or a search box, letting you type in a node name or domain keyword to narrow things down. If the client doesn't have a built-in filter, you can also sort the Connections panel by destination address for a similar effect.