The Complete Guide to the Clash Dashboard: Connections, Logs & Latency Tests

The dashboard is your window into what Clash is doing internally. A lot of "why won't this load" problems get answered the moment you glance at it. This article walks through each tab — Proxies, Connections, and Logs — and what each one is good for.

Where to find the dashboard

Desktop clients usually have a built-in dashboard entry point. If you're running a standalone core, just make sure this line is in your config, then open the corresponding web dashboard (yacd, metacubexd, etc.) in your browser to connect:

external-controller: 127.0.0.1:9090
secret: "your-api-secret"       # set one if exposed to LAN

The Proxies tab: how to read the latency numbers

Clicking the lightning bolt icon on a group runs a speed test across every node in it. Here's what the latency colors mean:

• Green (<200ms): healthy — browsing and video are both fine.
• Yellow (200-500ms): usable but sluggish — gaming and video calls will feel noticeably laggy.
• Red / timeout: the node is currently unavailable, don't pick it.

Keep in mind the latency measures the whole path — "you → node → test URL" — not a raw ping value. It's normal for the same node to score very differently at different times, and results tend to run higher during peak hours.

The Connections tab: see exactly who's using bandwidth

The Connections tab lists every active connection, and each row shows the destination domain, the rule it matched, which group and node handled it, and how much traffic it's used. Three things people use it for most:

1. Verifying routing: visit a site, then search for its domain here to confirm it matched the rule and exit node you expected.
2. Spotting bandwidth hogs: sort by traffic to instantly catch apps quietly updating in the background, and kill a specific connection with the × button if needed.
3. Debugging misrouted traffic: if a site you expected to go direct is going through the proxy instead, check which rule it actually matched and fix the ordering or rule in your config.

The Logs tab: your last resort for troubleshooting

When the Connections tab doesn't reveal the problem, head to the Logs tab. Temporarily bump the log level to debug, and most common errors become instantly recognizable:

Once you've finished troubleshooting, remember to set the log level back to info — logging at debug level is fairly resource-intensive.

Three advanced tips

• Rule lookup: some dashboards let you type in a domain and see which rule it would match, letting you "test drive" a rule change before actually making it.
• Traffic charts: the real-time upload/download graph on the overview page is a good sanity check for speed tests — a maxed-out connection should look smooth, while a jagged, spiky line usually means the node is unstable.
• LAN management: with allow-lan enabled, the Connections tab will also show traffic from phones, TVs, and other devices on your network, so you can manage everything from one dashboard.

Which dashboard should you use: built-in vs. third-party web dashboards

Desktop clients usually bundle Proxies, Connections, and Logs into one built-in dashboard — just open it, no extra setup needed. If you're running a standalone core on a server or router, the popular third-party web dashboards each have their own strengths:

• yacd: clean, fast-loading, and reliably stable — good if you just want the essentials without any fuss.
• metacubexd: more feature-rich, richer charts, and more detailed connection info — good if you like digging into the data.

Both talk to Clash through the same external-controller API, so functionally there's no real difference — which one you pick is purely a matter of taste, and switching between them costs nothing. The dashboard is just a "read and control" interface; your configuration and connection state always live on the Clash side.

Using the dashboard on mobile

The same logic applies on mobile — as long as your client supports a dashboard, the workflow is identical to desktop: run speed tests and switch groups on Proxies, check traffic on Connections, and troubleshoot on Logs. If your mobile client doesn't have a built-in dashboard entry, you can open the address configured under external-controller directly in a mobile browser (as long as your phone and the device running the core are on the same network) — same result, just one extra step of opening a browser manually.

Make the dashboard part of your troubleshooting habit

Most people only open the dashboard once something's already gone wrong. A better habit is to keep it open as a passive observation window: glance at latency before switching nodes, and check the Connections tab first — not guesswork — the moment something feels slow. Once that habit sticks, you'll find most "network problems" don't require asking around in a forum or Discord server at all — the dashboard already has the answer sitting right in front of you.

How the dashboard connects to the rest of this series

The dashboard is really the thread that runs through this whole troubleshooting approach: suspect a DNS issue? Head to Logs, set the level to debug, and cross-reference the steps in our DNS configuration guide. Suspect a proxy group isn't switching the way you expect? Check node status on Proxies and the matched group on Connections, and cross-reference our load balancing and failover guide. Suspect a rule is routing something incorrectly? Search the domain on Connections to see which rule actually matched, and cross-reference the reminder in our rule-provider guide that rule order determines the outcome. In short, the earlier articles cover "how to configure it," while this one covers "how to verify and debug it once it's configured" — together they form a complete workflow.

If you're new to Clash, it's worth reading this article alongside our load balancing and failover guide — set up your scheduling strategy first, then learn to use the dashboard to confirm it's actually behaving the way you intended. That order will save you a lot of guesswork down the line.