Linux Clash Setup: Desktop App vs Command-Line Core Deployment

Which of the two Linux Clash deployment paths should you pick

Strictly speaking, "Clash" today refers more to an ecosystem than a single piece of software — the engine underneath is mihomo (formerly Clash Meta; the original Clash core has stopped receiving updates), and you can either wrap it in a desktop client with a GUI, or drop the core binary straight into the system to run as a service. The difference between the two paths isn't just "has a UI or not" — the use cases themselves are different:

• Desktop client path: suited to everyday use on Ubuntu, Fedora, Debian, and other distros running a desktop environment (GNOME, KDE, etc.). Switching nodes, viewing rule logs, and toggling TUN mode are all mouse clicks, with the lowest learning curve. The leading options are Clash Verge Rev and FlClash.
• Command-line core path: suited to servers, NAS boxes, gateway routers, cloud instances without a GUI, or any case where you just want Clash to run as a background service that starts on boot without needing (or being convenient) to open a window. It runs long-term off a config.yaml plus a systemd unit file.

Both paths run on the same mihomo core, and rule syntax and subscription formats are fully interchangeable — the only difference is who's responsible for keeping the core running and exposing the control panel. If your Linux machine does double duty as a daily driver and a long-running box (say, a mini PC that's always on), you can install both and switch as needed.

Desktop client path: setting up Clash Verge Rev and FlClash

On the desktop client side, Clash Verge Rev and FlClash are currently the two actively maintained, open-source options for Linux desktops. Both wrap the mihomo core underneath, with some differences in UI style and dependency footprint.

Clash Verge Rev: covers the mainstream distros

Clash Verge Rev officially ships .deb, .rpm, and .AppImage packages, covering Debian/Ubuntu-based distros, Fedora/openSUSE-based distros, and the universal AppImage format that runs on almost anything. Installation notes:

1. On Debian/Ubuntu-based systems, install the .deb with dpkg -i; if you hit a missing-dependency error, run apt --fix-broken install right after.
2. On Fedora/openSUSE-based systems, install the .rpm with rpm -i or your package manager of choice.
3. If you don't want to install a system package and just want to run it once, make the AppImage executable and launch it directly: chmod +x Clash-Verge-Rev.AppImage && ./Clash-Verge-Rev.AppImage.
4. If the first launch asks for extra permission to enable TUN mode, follow the on-screen prompt to install a helper process with sudo once — after that, toggling TUN won't ask for a password every time.

FlClash: a lighter cross-platform alternative

FlClash is built on Flutter and also ships .deb and .AppImage packages for Linux, with a simpler UI and a smaller footprint — a good fit for lower-spec desktops or VMs. Installation is similar to Clash Verge Rev: extract or install, then run directly; on first launch you'll need to manually import a subscription link or a local config file.

After installation, the usage flow for both is basically the same: import a subscription link → pick a proxy mode (rule-based / global / direct) → enable TUN mode when you need to route all traffic → switch groups in the node list. For step-by-step GUI instructions and a cross-platform troubleshooting checklist, see our other article on first-time setup.

Command-line path: the full steps for running the mihomo core directly

The command-line path skips the GUI entirely and manages the mihomo binary directly. The whole process has three steps: download the binary for your architecture, prepare the config file, and do a manual test run to confirm everything works.

Step 1: Download the binary for your CPU architecture

The official mihomo release page offers separate builds for amd64, arm64, armv7, and other architectures. Check your machine's architecture first, then grab the matching build:

uname -m
# x86_64 maps to amd64; aarch64 maps to arm64

The downloaded file is usually a .gz archive. Extract it, make it executable, and move it into a fixed location so systemd can reference it later:

gunzip mihomo-linux-amd64.gz
chmod +x mihomo-linux-amd64
sudo mkdir -p /etc/mihomo
sudo mv mihomo-linux-amd64 /usr/local/bin/mihomo

Step 2: Prepare the config file

Put the config.yaml generated from your subscription into the /etc/mihomo/ directory. At minimum, check these fields are set to the values you need:

• port / socks-port: local HTTP and SOCKS5 proxy ports.
• allow-lan: set to true if this machine needs to serve as a proxy for other devices on the LAN.
• mode: rule (route by rules), global (route everything through the proxy), or direct (route everything directly).
• external-controller: the address the control panel listens on, e.g. 127.0.0.1:9090, paired with a secret field to set an access key.

Step 3: Do a manual test run

Before wiring up systemd, run it once directly in the terminal to confirm the config loads correctly with no syntax errors:

mihomo -d /etc/mihomo

If the logs show rules loading successfully and the listening ports opening, with no errors flooding the output, the config is good to go — you're ready to turn it into a persistent service.

Using systemd to keep mihomo running and verifying connectivity

Once the manual run works, the next step is to have mihomo start on boot and restart automatically on crash — systemd is the simplest way to do this. Create a new unit file:

sudo nano /etc/systemd/system/mihomo.service

Add the following content (adjust paths as needed):

[Unit]
Description=mihomo Clash kernel service
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
User=root

[Install]
WantedBy=multi-user.target

Save it, then run the following commands in order to enable and start the service:

sudo systemctl daemon-reload
sudo systemctl enable mihomo
sudo systemctl start mihomo
sudo systemctl status mihomo

If systemctl status shows active (running), the service is up and persistent. For day-to-day troubleshooting and log checks, use:

journalctl -u mihomo -f

To verify connectivity, test through the local proxy port directly with curl:

curl -x socks5h://127.0.0.1:7890 https://www.google.com -I

A normal HTTP status line in the response means the proxy chain is working. If you want to check the active node, traffic, and rule matches, open the address configured under external-controller in a browser (e.g. http://127.0.0.1:9090/ui) paired with an open-source web control panel project — no desktop client needed.

Subscription updates and day-to-day maintenance: how the two paths differ

Once you've picked a path, long-term maintenance works differently too — worth knowing ahead of time to avoid some pitfalls.

On the desktop client path, there's usually an "update subscription" button right in the UI, with an option to set an auto-update interval. Rule sets and node lists take effect immediately after updating, no client restart needed. Switching nodes and temporarily changing the routing mode are both click operations — good for use cases that need frequent adjustments.

The command-line core path has no button. Updating the subscription usually relies on a scheduled task (crontab) that re-downloads the latest config.yaml, overwrites the old file, and then runs systemctl restart mihomo to apply it. If you don't want to restart the process (and interrupt existing connections) on every update, it's worth looking into mihomo's config hot-reload interface (triggered via the external-controller panel) to avoid service interruption.

Whichever path you take, the rule syntax in the config file is universal — the same config.yaml can, in theory, be reused directly between a desktop client and a command-line core, though desktop clients often add a layer of GUI grouping and panel settings on import. If you maintain both a desktop machine and a persistent server, it's worth keeping a single source of rules to cut down on troubleshooting from configs drifting apart.