2026年5月27日プラットフォーム導入推定読了時間 7 分

Linux で Clash を導入する全手順:デスクトップ版クライアントとコマンドライン mihomo 運用

デスクトップ環境では Clash Verge Rev の deb パッケージで3ステップ導入、サーバーやヘッドレス環境では mihomo コアを systemd で常駐させる方法を解説。インストールからサブスクリプション導入、自動起動設定まで一通り網羅。

Linux で Clash を運用する2つの方式、どちらを選ぶべきか

Linux には公式が統一したデスクトップ版 Clash クライアントがなく、実用できる方法は完全に異なる2つの方式に分かれます。選び方を間違えると余計な手間がかかります。1つ目はGUIクライアント方式です。画面付きのクライアントを導入し、Windows/macOS の Clash クライアントと同じようにマウス操作でノード切り替えやサブスクリプション導入ができ、GNOME や KDE などのデスクトップ環境を日常使いしている場合に向いています。2つ目はコマンドライン・コア方式です。Clash Meta コアの後継である mihomo という単一の実行ファイルのみを導入し、設定ファイルと systemd サービスでバックグラウンドに常駐させます。クラウドサーバー、NAS、Raspberry Pi のように GUI がなく 24時間稼働させたい環境に向いています。

2つの方式はコア部分が共通しています(デスクトップ版クライアントも内部では mihomo/Clash Meta コアを呼び出しています)。違いは「操作できるウィンドウが必要かどうか」だけです。判断基準は次の通りです。

デスクトップ環境付きの Linux ディストリビューション(Ubuntu、Fedora、Debian など)を自分のノートPCやデスクトップPCに入れていて、普段からノード切り替えや状態確認をしたい場合 → デスクトップ版クライアント方式を選びましょう。
クラウドサーバーや自宅の NAS を管理していて、プロキシサービスを画面操作なしで静かにバックグラウンドで動かしたい場合 → mihomo + systemd 方式を選びましょう。

以下では2つの方式を順に、それぞれ独立した形で解説しています。必要な部分だけ読んでも問題ありません。

デスクトップ環境:Clash Verge Rev を3ステップで導入

Clash Verge Rev は現在 Linux デスクトップ向けとして活発にメンテナンスされている、UIが充実したオープンソースクライアントです。コアには mihomo を採用し、TUN モードによる全トラフィック制御にも対応しています。配布される deb パッケージは Debian/Ubuntu 系ディストリビューションにそのまま対応しています。以下が完全な手順です。

ステップ1:対応アーキテクチャの deb パッケージをダウンロード

ダウンロード前に自分のシステムのアーキテクチャを確認しましょう。デスクトップPC・ノートPCの大半は amd64 ですが、一部の ARM 機器(ARM搭載ノートPCなど)は arm64 パッケージを選ぶ必要があります。コマンドラインでアーキテクチャを確認する方法:

uname -m
# x86_64 は amd64 パッケージに対応
# aarch64 は arm64 パッケージに対応

アーキテクチャを確認したら、当サイトのダウンロードページから対応する deb インストールパッケージのリンクを取得してください。

ステップ2:deb パッケージをインストール

ダウンロード後は apt または dpkg でインストールします。依存関係を自動処理してくれる apt の使用を推奨します。

cd ~/Downloads
sudo apt install ./clash-verge-rev_amd64.deb

依存関係が不足しているという表示が出た場合(純粋な Debian 環境でよく発生します)、まず以下を実行してください。

sudo apt --fix-broken install

その後もう一度インストールし直せば完了です。インストール成功後、アプリケーションメニューにアプリが表示されます。ターミナルからクライアント名を直接入力して起動することもできます。

ステップ3:サブスクリプションを導入してシステムプロキシを有効化

クライアントを起動したら、以下の順で操作してください。

「サブスクリプション」ページに入り、機場(プロバイダ)から提供されたサブスクリプションリンクを貼り付けてダウンロードをクリックし、ノードリストの取得完了を待ちます。
「プロキシ」ページに切り替え、レイテンシの低いノードグループを選ぶか、自動速度テスト対応のポリシーグループをそのまま利用します。
「設定」でシステムプロキシのスイッチをオンにするか、必要に応じて TUN モードを有効化します(パスワード入力による権限付与が必要で、TUN は全トラフィックを制御します。プロキシ設定に対応していないアプリも含まれます)。

サーバー・ヘッドレス環境:mihomo コア + systemd で常駐運用

GUI がない機器(クラウドサーバー、NAS、ルーター相当の機器)では完全なクライアントは不要で、mihomo の単一ファイルコアのみを導入し、YAML 設定を用意して systemd にライフサイクル管理を任せます。この方式のメリットはリソース消費が少なく、切断時に自動再起動し、起動後すぐに使える点です。

ステップ1:mihomo バイナリをダウンロードして配置

アーキテクチャを確認後、プロジェクトのリリースページから対応する圧縮パッケージを取得し、展開して得られる実行ファイルをリネームしてシステムパスに配置します。

tar -zxvf mihomo-linux-amd64.tar.gz
sudo mv mihomo-linux-amd64 /usr/local/bin/mihomo
sudo chmod +x /usr/local/bin/mihomo

実行可能か確認:

mihomo -v

バージョン番号が出力されればバイナリの配置は成功です。

ステップ2:設定ディレクトリとサブスクリプションファイルを用意

mihomo はデフォルトで /etc/mihomo/config.yaml を読み込みます。まずディレクトリを作成してください。

sudo mkdir -p /etc/mihomo
sudo curl -o /etc/mihomo/config.yaml "あなたのサブスクリプションリンク"

サブスクリプションリンク自体が標準的な Clash YAML 形式でない場合(一部の機場では Base64 エンコードの汎用形式を提供しています)、変換に対応したクライアントで先に Clash 形式のリンクを生成し、それを上記のコマンドでダウンロードしてください。そうしないと mihomo の解析に失敗します。

ステップ3:手動での動作テスト

まだ systemd と連携させず、フォアグラウンドで一度実行して設定ファイルに問題がないか確認します。

mihomo -d /etc/mihomo

ターミナル出力を確認し、リスンポート(デフォルトのミックスポート 7890)とプロキシグループの読み込み成功のログが表示されたら Ctrl+C で停止し、次のステップに進みます。エラーが出た場合は、設定ファイルの形式かサブスクリプションの内容に問題がある可能性が高いので、YAML のインデントとサブスクリプションの期限切れをチェックしてください。

ステップ4:systemd サービスユニットを作成

サービスファイルを作成します。

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

内容は以下の通りです。

[Unit]
Description=mihomo Daemon
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

保存して終了したら、systemd をリロードしてサービスを起動します。

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

status に active (running) と表示されれば正常に起動しています。

よく使う systemd コマンド	用途
`systemctl start mihomo`	サービスを起動
`systemctl stop mihomo`	サービスを停止
`systemctl restart mihomo`	サービスを再起動(設定変更後に使用)
`journalctl -u mihomo -f`	リアルタイムでログを確認

サブスクリプション導入とルール更新の2つの方法

どちらの方式でもサブスクリプションの内容は期限切れになったり、機場のルールに合わせて定期的に更新する必要があります。ここではそれぞれの環境での更新方法を説明します。

デスクトップ版クライアントでのサブスクリプション管理

Clash Verge Rev では各サブスクリプションに自動更新の間隔を設定できます。サブスクリプション一覧で編集をクリックし、更新周期(単位:時間)を入力すれば、クライアントが周期に従って自動的にサブスクリプションを再取得します。手動で更新したい場合は、サブスクリプション項目の更新ボタンをいつでもクリックできます。

コマンドライン環境でのサブスクリプション更新

mihomo には GUI がないため、サブスクリプションの更新は本質的には設定ファイルを再ダウンロードして古いファイルを上書きし、サービスを再起動して反映させる作業です。簡単な更新スクリプトを書いておくと便利です。

#!/bin/bash
curl -o /etc/mihomo/config.yaml "あなたのサブスクリプションリンク"
systemctl restart mihomo

このスクリプトを update-sub.sh として保存し、crontab -e で定期実行タスクを1つ追加すれば、無人での定期更新が実現できます。例えば毎日午前4時に実行する場合は次のようになります。

0 4 * * * /bin/bash /root/update-sub.sh

自動起動設定とよくある不具合の切り分け

2つの方式では自動起動の設定方法が異なるため、それぞれ説明します。

デスクトップ版クライアントの自動起動

Clash Verge Rev の設定ページには通常「起動時に自動実行」というスイッチがあり、オンにするとデスクトップ環境へのログイン時にクライアントが自動的に起動します。使用しているディストリビューションのデスクトップ環境がこのスイッチに正しく対応していない場合(一部のマイナーなウィンドウマネージャーでは自動起動項目が反映されないことがあります)、システムの起動アプリケーション管理画面に手動でクライアントの実行ファイルパスを追加してください。

mihomo サービスの自動起動

systemd で管理しているサービスは、有効化コマンドを一度実行するだけでシステム起動時に自動的に立ち上がるようになり、追加設定は不要です。

sudo systemctl enable mihomo

その後サーバーを再起動して確認します。再起動後に systemctl status mihomo を実行し、ステータスが active であれば自動起動の設定は成功です。

デスクトップ版とコマンドライン版の両方式を把握しておけば、自分のPCで一時的にノードを切り替える場合でも、常時稼働のサーバーにプロキシの出口を設定する場合でも、同じ考え方で対応できます。まずアーキテクチャと依存関係を確認し、次にサブスクリプションを導入し、最後に自動起動の設定を済ませる。うまくいかなければ一つ前のステップに戻ってやり直せば大丈夫です。