Clash Dashboard Guide: Connections, Traffic Graphs & Latency Testing

"Is this rule actually working?" "Which node is this connection using?" "Why did it suddenly get slow?" — these questions are hard to answer by guessing, but the Dashboard usually makes the answer obvious at a glance. This guide covers how the dashboard relates to the Clash core, how to open it, how to use its main features, and the security precautions you need to know.

🗓️ July 17, 2026 ⏱️ About 8 min read 🔗 Related: Configuration Reference · External Controller & Dashboard

How the Dashboard Relates to the Core

The dashboard itself doesn't handle any network traffic — it's just a web UI for reading and controlling the core's state. The actual work is always done by the Clash core.

This relationship is established through the external-controller field in your config file. Once the core starts, it opens a local API at that address; the dashboard connects to this API through your browser to display the node list, connection status, logs, and more, and can also send commands through it (like switching which node a proxy group is currently using). Once you understand this, it becomes clear that the dashboard is just one of many possible "frontends" — the same core can be connected to by several different dashboards at once.

config.yamlyaml

external-controller: 127.0.0.1:9090
secret: "set a sufficiently strong secret here"

How to Open the Dashboard

Different clients expose the dashboard slightly differently, but the underlying principle is the same:

Most GUI clients (Clash Verge Rev, FlClash, etc.): already have a dashboard entry built in, usually accessible directly from the app's "Overview" or "Dashboard" menu — no extra configuration needed.
Core-only / command-line deployments: you'll need to pair it with an open-source dashboard project (community favorites include yacd and metacubexd) — either host its static files alongside the core, or deploy it anywhere that can reach your external-controller address, then open it in a browser.

💡

You can mix and match dashboards freely — for the same core, you can use the client's built-in dashboard and also open a community dashboard in your browser pointed at the same external-controller address. Both show the exact same live data without conflicting.

Tour of the Main Features

Feature	What You Can See	Typical Use
Connections	Every active connection's destination domain/IP, the proxy node it's using, the rule it matched, and traffic transferred	Figuring out "which node/rule is this site actually going through"
Proxies	All nodes and proxy groups, each node's current latency, and a manual way to switch nodes in a `select` group	Manually comparing latency, manually switching lines
Traffic	A real-time upload/download speed graph	Visually confirming traffic is actually flowing and spotting unusual spikes
Logs	The core's real-time log output, including rule matches and connection success/failure info	Debugging errors, confirming whether a specific rule actually fired

The Connections tab is the one you'll use most for everyday debugging: click into a specific connection and you'll see exactly which node it's using and which rule it matched — the most direct way to check whether a rule is actually working, and much faster than repeatedly editing the config and re-testing.

Debugging Real Issues With the Connections List

When "this site isn't working right," rather than immediately assuming your config is wrong, it's more efficient to locate the connection in the Connections list first:

Find the target domain in the Connections list (usually sorted by most recent, which makes it easy to spot). If it doesn't show up at all, the request may be getting blocked at the system level — the issue isn't Clash.
Check which rule it matched, and compare that against your config file to confirm the rule's action is what you expected.
Check which proxy node it's using. If the rule points to a proxy group but the actual node isn't the one you expected, go back to the Proxies tab and check that group's current scheduling state (e.g. whether a url-test group correctly picked the fastest node).

This debugging approach essentially cross-references the rule engine's matching logic against what's actually happening at runtime — much more targeted than just "tweak the config and try again."

Security: secret and allow-lan

⚠️

The interface exposed by external-controller doesn't just let you "view" things — it lets you "control" them too, including reading your node list, switching proxies, and even modifying some runtime settings. If allow-lan is enabled, that interface also becomes reachable from other devices on your local network.

So there are two security rules you should always follow:

Whenever allow-lan is on, always set a sufficiently strong secret to prevent other devices on your local network from accessing your dashboard API without authorization.
If you're only using it on a single machine, there's no need to bind external-controller to 0.0.0.0 or a LAN IP — the default 127.0.0.1 (accessible only from localhost) is already secure enough, and simpler too.