Три способа установить Clash в Linux

Три пути соответствуют трём типам машин. Настольной, в которой вы каждый день что-то нажимаете, нужно графическое приложение. VPS в дата-центре рабочий стол ни к чему, ему достаточно голого ядра. А если оно должно подниматься при загрузке и само возвращаться после падения, вокруг того же голого ядра появляется systemd-юнит — последние два пути на деле две половины одного: сначала запустите руками, потом отдайте системе.

Путь первый: графическое приложение

1. Выберите формат пакета на странице релизов проекта: deb для Debian и Ubuntu, rpm для Fedora и openSUSE, AppImage для всего остального. Под одной версией все архитектуры лежат рядом, так что не берите сборку arm64 на машину x86.
2. deb ставится командой sudo apt install ./имя-файла, rpm — командой sudo dnf install ./имя-файла. Ведущий ./ обязателен: без него менеджер пакетов пойдёт искать программу с таким именем в репозиториях. dpkg и rpm тоже сработают напрямую, но зависимости за вас не разрешат.
3. AppImage сначала сделайте исполняемым — chmod +x — и только потом запускайте двойным щелчком или из терминала. В системные каталоги он ничего не пишет, так что удаление файла и есть удаление программы.
4. В первый раз запускайте из терминала, а не из меню приложений. При неудачном старте окно мелькает и исчезает, и текст ошибки остаётся только в терминале.

Чаще всего не хватает библиотеки времени выполнения. AppImage упаковывает только собственный код приложения, а GTK, WebKit и прочее берёт из системы, поэтому при отсутствии одной из них терминал называет конкретный файл .so. Поищите это имя в менеджере пакетов — обычно попадёте в нужный пакет; названия у дистрибутивов не совпадают: в Debian это что-то со словом webkit2gtk, в Fedora и Arch пишется иначе. Значок в трее — отдельный жанр проблем. GNOME по умолчанию вообще не рисует область трея, пока не установлено расширение AppIndicator, а в сессиях Wayland значки пропадают чаще, чем в X11: если расширение стоит, а значка всё равно нет, войдите один раз в сессию X11 и убедитесь, что дело именно в этом.

Путь второй: только ядро mihomo

uname -m
chmod +x ./mihomo
sudo install -m 755 ./mihomo /usr/local/bin/mihomo
mkdir -p ~/.config/mihomo
mihomo -d ~/.config/mihomo

Если uname -m отвечает x86_64, берите сборку amd64; если aarch64 — берите arm64. Ошибка на этом шаге даёт сообщение о том, что бинарник не запускается, и к вашей конфигурации она отношения не имеет. На страницах релизов обычно лежит сжатый одиночный файл, чьё распакованное имя несёт архитектуру и версию: переименуйте его в mihomo, чтобы остальные команды были короче. Ключ -d указывает на каталог конфигурации, внутри которого должен лежать хотя бы config.yaml. Не отправляйте процесс в фон на первом запуске — пусть пишет в терминал, чтобы вы видели, прочиталась ли подписка и поднялся ли порт. Если хочется чем-то им управлять, включите external-controller и подключите веб-панель, но это отдельная тема.

Путь третий: держать его под systemd

[Unit]
Description=mihomo daemon
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=root
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target

Оба пути в ExecStart нужно привести к тому, куда вы действительно всё положили: сначала бинарник, потом каталог конфигурации, — переписанные буквально они, скорее всего, не стартуют. User здесь root, чтобы работали TUN и низкие порты; если TUN вам не нужен, обычный пользователь безопаснее. Restart=on-failure поднимает сервис только после ненормального завершения, так что меняйте на always, если он должен жить при любом исходе. Где именно должен лежать файл юнита, у дистрибутивов слегка расходится, а команда sudo systemctl edit --force --full mihomo.service заставляет systemd создать файл самостоятельно, и путь запоминать не придётся. Дальше sudo systemctl daemon-reload и sudo systemctl enable --now mihomo. После этого systemctl status mihomo покажет, выжил ли он, а journalctl -u mihomo -f будет следить за логом, где собственные строки ядра скажут, конфигурация не разобралась или порт был занят.

TUN в Linux требует лишнего шага

Тот же переключатель TUN, который в Windows стоит одного клика и установки службы, здесь ведёт себя иначе. Создание виртуального адаптера и правка таблицы маршрутов относятся к правам управления сетью, а у процесса, запущенного от обычного пользователя, их нет. Симптом всегда один: переключатель сам возвращается в выключенное положение, либо строки про TUN в логе прямо говорят, что прав не хватило или устройство не открылось. Выходов два — клиент, установленный из deb или rpm, обычно имеет режим службы: включите его и позвольте привилегированной половине создать адаптер. Либо обойдитесь без службы и выдайте нужную возможность самому бинарнику:

sudo setcap cap_net_admin,cap_net_bind_service=+ep $(which mihomo)
getcap $(which mihomo)

Ещё несколько мелочей, о которые спотыкаются

• setcap поверх AppImage — почти всегда потраченное впустую время. Среда AppImage монтирует содержимое во временный каталог и запускает программу оттуда, поэтому возможность, привязанная к внешнему файлу, до реального процесса не доходит. Нужен TUN — ставьте сборку deb или rpm и включайте режим службы.
• Замена бинарника снимает возможность. setcap помечает сам файл, так что повторяйте команду после каждого обновления ядра или подмены файла, а getcap покажет, на месте ли метка.
• Программы в терминале полностью игнорируют системные настройки прокси. curl, git и менеджеры пакетов читают переменные окружения вроде https_proxy; строка export https_proxy=http://127.0.0.1:7890 закрывает вопрос в пределах одной оболочки, а как сделать это надолго — отдельная тема.
• Перед запуском сверьте хеш. На страницах релизов рядом со сборками обычно лежат файлы контрольных сумм, а способ сравнения разобран в отдельной статье.