Clash Dashboard Guide: Visually Manage Nodes and Rules

Why the Core Needs a Dashboard

If you're using a client with a built-in GUI, it's actually running the same "core + built-in panel" combo internally — the panel is just packaged inside the client's window, so you never notice the process. But if you run the core standalone on macOS, Linux, or a router (see the general workflow on the tutorial page first), you'll need to hook up an external Dashboard yourself to see the node list, live traffic, logs, and rule matches.

Enabling the Core's Control Port

The core opens an HTTP control port in the config file by default, and the Dashboard reads and writes data through that port. Make sure your config.yaml contains fields like these:

external-controller determines the address and port the panel connects to; secret is the access password — it can be left blank for local use, but if you enable LAN access (allow-lan: true), setting a password is strongly recommended.

Connecting to a Dashboard

The control port is fundamentally a standardized HTTP API, and many open-source panels on the market can connect to it — usage is roughly the same across them:

1. Open the panel page in your browser (some panels are pure front-end pages — just open the HTML file directly, no deployment needed).
2. Enter the core address in the panel's connection settings, e.g. http://127.0.0.1:9090.
3. If you set a secret, enter the same value in the password field.
4. Once connected, you'll see the node list, proxy groups, rules, connection logs, and a live traffic graph.

The Three Most-Used Panel Features

1. Node Latency Testing and Switching

The panel's "Proxies" page lists all proxy groups and nodes. Clicking the speed-test icon batch-tests latency for the whole group — lower latency usually means better connection quality. Clicking a specific node switches it to your active server without restarting the core.

2. Rule Match Logs

The "Logs" or "Connections" page shows in real time which rule each request matched and whether it went direct or through the proxy — much more intuitive for troubleshooting "why isn't this site being proxied" issues than staring at the config file and guessing.

3. Online Config Editing

Some panels let you edit proxy-groups and rules directly in the browser and save them — changes take effect immediately, no need to manually open the file, save it, and restart the process.

Letting Other LAN Devices Access the Panel Too

If you run the core on a computer or NAS that's always on, it's natural to want to check its status from a phone or tablet using the same panel. To do that, change external-controller from 127.0.0.1:9090 to 0.0.0.0:9090 so the core listens on all network interfaces, and set allow-lan to true to let LAN devices connect through the proxy.

The connection address should also be adjusted to the LAN IP of the device running the core, e.g. http://192.168.1.5:9090, rather than 127.0.0.1 — the latter always points to the device itself, so connecting from a different device will never work.

Backing Up and Migrating Your Panel Settings

After switching computers, reinstalling the OS, or reflashing a router, many people find that node groups and rule changes all need to be reconfigured from scratch — but this is entirely avoidable. The control port itself doesn't store historical config files; what actually needs backing up is config.yaml and the rule set cache files (if you use rule-providers). Copy these files along with the core executable to the new device, and after starting up, the nodes, groups, and rules in the panel will be fully restored — no need to manually rebuild anything in the panel UI.

If you've modified rules or proxy groups through the panel's "online editing" feature, remember to sync those changes back to your local config.yaml file — for some panels, online editing only affects the core's in-memory runtime state, and unsaved changes may be lost after a restart. Getting into the habit of "export a copy right after editing" saves a lot of repeated work.

Summary

A Dashboard isn't strictly necessary — a GUI client alone can handle everyday proxy needs. But if you run the core in a headless environment like a server or router, or want to closely observe traffic and rule matches, hooking up a web panel takes the whole experience up a notch.