The Complete Guide to the Clash Dashboard: Connections, Logs, and Latency Testing

What the Dashboard Is, and Why You'd Use It

The Clash core itself is just a background process with no interface. The clients you actually see day to day — Clash Verge, Clash for Windows, and so on — are really just the core paired with a dashboard. The dashboard reads live data through the RESTful API the core exposes and presents it in a graphical UI, so you can manage your proxy without touching a command line.

Common dashboard implementations include Yacd, Metacubexd, and others — the layout varies a bit, but the core feature areas are basically the same: Proxies, Connections, Rules, Logs, and Config.

The Proxies Page: Switching Nodes and Testing Latency

This is the page you'll use most often. It groups all your nodes by "policy group," where each policy group represents a category of routing destination (like "Proxy," "Ad Block," or "Domestic Direct").

• Policy group typesselect (manual selection) lets you pick a specific node yourself; url-test (auto speed test) automatically picks the best node based on latency; fallback (auto failover) automatically switches to a backup when the current node goes down.
• Latency testingClick the "test" button on the dashboard (usually a lightning bolt or stopwatch icon), and the dashboard fires an HTTP request against every node in that policy group and returns a latency number — the lower the number, the faster it responds.
• Manual switchingIf you're not happy with the node auto speed-test picked (e.g. low latency but slow actual downloads), you can manually pick a different node in any select-type policy group.

The Connections Page: See Exactly Where Every Bit of Traffic Went

The connections page lists every currently active network connection in real time. Each row shows the domain/IP being accessed, the node used, the rule matched, data used, connection duration, and more. When troubleshooting whether a specific site/app is going through the proxy, this is the most direct source of evidence.

• If a domain that should be going through the proxy shows DIRECT in the "node" column, that means there's a rules issue — that domain was routed to direct connection by mistake.
• If a connection sits in "connecting" for a long time with no data transferred, the node may be dead or the network unstable — try manually switching to a different node.
• There's usually a search box in the top right where you can filter by a domain keyword to quickly find the connections for a specific app.

The Logs and Rules Pages: Key to Troubleshooting

The logs page prints the core's runtime log in real time, with levels from low to high typically being debug, info, warning, and error. When troubleshooting, it's a good idea to switch to the debug level — you'll see the full process behind every DNS query, rule match, and connection setup. It's a lot of information, but it lets you pinpoint exactly which step went wrong.

The rules page lists, in order, every routing rule currently active in your config (e.g. DOMAIN-SUFFIX,google.com,Proxy). Clash matches rules from top to bottom and stops at the first hit — it never keeps checking further down. If a site is being routed incorrectly, search for the relevant domain on this page to see which rule it actually matched and which policy group it landed in — that's usually much faster than guessing at the config file.

FAQ