Choosing a Clash Dashboard: Comparing the Popular Options

Step One: Turn On the External Controller

No matter which dashboard you pick, it depends on the core exposing external-controller — the RESTful API endpoint that a dashboard talks to:

external-controller: 127.0.0.1:9090
secret: "your-strong-secret"

A dashboard is really just a web app that talks to this API. Whether it's a page you host yourself or a set of static assets bundled with the core, everything it shows — connection lists, node latency, log streams — comes through this same endpoint.

What the Popular Dashboards Focus On

The dashboard ecosystem moves fast enough that naming specific projects here would go stale quickly, but they generally fall into three categories by focus:

• Lightweight, read-only — shows connection status, latency, and traffic charts and nothing else. Clean, fast to load, good for a quick glance at what's happening;
• Full-featured management — adds node switching, rule editing, subscription management, and detailed logs on top of the read-only view. Most capable, but also the most complex interface;
• Mobile-optimized — tuned for phone browsers, useful when the dashboard is running on a router and you mostly need to check it from your phone.

If you're just running a GUI client on your own computer, you typically don't need a separate dashboard at all — the client's built-in UI already covers most needs. Dashboards earn their keep on headless setups: routers, NAS boxes, and cloud servers where there's no GUI to look at directly.

What You Actually Get From a Dashboard

Once connected, these are the views you'll end up using the most:

• Live connection list — every active connection, including the destination domain, the rule it matched, and the final routing decision (DIRECT / PROXY / REJECT). The fastest way to answer "why isn't this site going through the proxy?";
• Node latency panel — real-time latency results for every node in a proxy group, so you can see at a glance whether you're actually on the fastest one;
• Traffic stats — upload/download totals broken down by connection or time window, useful for spotting an app that's quietly chewing through bandwidth in the background;
• Log stream — a live-scrolling feed of the core's runtime logs, where rule-loading failures and subscription fetch errors usually show up first.

Compared to raw text logs, a dashboard turns this information into something you can actually scan quickly, which matters a lot more once the core is running unattended on a router or server with no display attached.

Security Settings You Need Before Connecting

A misconfigured external controller effectively hands over full control of your proxy setup, so don't skip this step:

• Always set a genuinely strong secret — never leave it blank or on a default value;
• If you only need the dashboard locally, bind external-controller to 127.0.0.1, not 0.0.0.0;
• If you genuinely need remote access (say, the dashboard is on a router and you need to reach it from another device), go through a local network connection or put a reverse proxy with authentication in front of it — don't expose the control port directly to the public internet.

The Usual Steps to Connect a Dashboard

1. Confirm the core has external-controller enabled with a secret set;
2. Enter the core's address (e.g. 127.0.0.1:9090) and the secret in the dashboard's connection settings;
3. Once connected, you should see the live connection list, node latency, and logs. If the connection fails, check the address/port first, then whether the core is actually running, then whether a firewall is blocking that port.

Troubleshooting a Failed Connection

Dashboard connection failures usually boil down to one of a handful of causes: the core doesn't actually have external-controller enabled, or a config change wasn't reloaded; the address or port is wrong, especially mixing up 127.0.0.1 with the LAN IP you should be using for remote access; the secret doesn't match, often because a stray space or quote got copied along with it; or a firewall / security tool is blocking local access to that port. Working through these in order covers the vast majority of connection failures.

If the dashboard loads but shows no data, that's usually not a connection problem — the core simply hasn't logged any connections yet. Visit a site to generate some traffic, then check back. For the full list of parameters external-controller supports, see the Advanced Configuration Docs.