Linux で Clash を使う2つの道:デスクトップクライアント導入とコマンドラインコア運用

Linux での Clash 導入、2つの道どちらを選ぶべきか

厳密に言えば、今日の「Clash」はもはや単一のソフトウェアではなくエコシステムを指すことが多くなっています——実際に動いているエンジンは mihomo(前身は Clash Meta。オリジナルの Clash コアは開発が停止しています)で、その上にグラフィカルなデスクトップクライアントを乗せることもできれば、コアのバイナリファイルをそのままシステムにサービスとして配置することもできます。この2つの道の違いは「画面があるかないか」だけではなく、使う場面そのものが異なります。

• デスクトップクライアント方式:Ubuntu、Fedora、Debian などのディストリビューションでデスクトップ環境(GNOME、KDE など)を使う場面に適しています。グラフィカルな画面上でノード切り替え、ルールログの確認、TUN モードのオン/オフをマウス操作でできるため、導入コストが最も低く、代表的なソフトは Clash Verge Rev と FlClash です。
• コマンドラインコア方式:グラフィカル画面のないサーバー、NAS、サブルーター、クラウドホスト、あるいは Clash を起動時に自動起動するバックグラウンドサービスにしてしまいたい場合に適しています。ウィンドウ操作を行う必要も便利さもなく、config.yaml と systemd のユニットファイルで長期間稼働させます。

この2つの道は同じ mihomo コアを使っているため、ルール構文やサブスクリプション形式は完全に共通です。違うのは「誰がコアを起動させるか、誰がコントロールパネルを公開するか」だけです。お使いの Linux マシンが日常のネット利用と長期稼働(たとえば常時起動しているミニPCなど)を両方兼ねているなら、両方の方式を導入して必要に応じて切り替えても構いません。

デスクトップクライアント方式:Clash Verge Rev と FlClash の導入要点

デスクトップクライアント方式では、Clash Verge Rev と FlClash が現在の Linux デスクトップ上でメンテナンスが活発でオープンソースで確認できる2つの選択肢です。いずれも内部では mihomo コアを使っており、画面デザインや依存サイズにわずかな違いがあります。

Clash Verge Rev:主要ディストリビューションを幅広くカバー

Clash Verge Rev の公式配布は .deb、.rpm、.AppImage の3形式で、Debian/Ubuntu 系、Fedora/openSUSE 系、そしてどのディストリビューションでも動く AppImage 汎用形式をほぼカバーしています。導入のポイント:

1. Debian/Ubuntu 系では dpkg -i で .deb パッケージを導入し、依存関係不足のエラーが出た場合は apt --fix-broken install を実行すれば解決します。
2. Fedora/openSUSE 系では rpm -i または対応するパッケージマネージャーで .rpm パッケージを導入します。
3. システムパッケージを入れず一時的に試したい場合は、AppImage ファイルに実行権限を付与してダブルクリックまたはコマンドラインで実行します:chmod +x Clash-Verge-Rev.AppImage && ./Clash-Verge-Rev.AppImage。
4. 初回起動時に TUN モードで追加の権限付与が必要と表示された場合は、画面の案内に従って sudo 付きの補助プロセス導入を一度実行すれば、以後 TUN のオン/オフで毎回パスワードを入れる必要はなくなります。

FlClash:軽量なクロスプラットフォームの選択肢

FlClash は Flutter で構築されており、同様に Linux 向けの .deb と .AppImage パッケージを提供しています。画面はよりシンプルで、リソース消費も比較的少なく、性能が高くないデスクトップ機や仮想マシン環境に適しています。導入方法は Clash Verge Rev と似ており、展開または導入後そのまま実行し、初回起動時にサブスクリプションリンクまたはローカル設定ファイルを手動でインポートする必要があります。

両者の導入後の使い方はほぼ同じです:サブスクリプションリンクをインポート → プロキシモードを選択(ルール/グローバル/ダイレクト)→ 必要なら TUN モードを有効にして全トラフィックを引き受ける → ノードリストでグループを選んで切り替える。具体的な画面操作の手順や各プラットフォーム共通のトラブル対処リストは、当サイトの初回インストール設定に関する別記事を参照してください。

コマンドライン方式:mihomo コアを直接動かす完全な手順

コマンドライン方式ではグラフィカル画面を一切経由せず、mihomo バイナリ本体を直接管理します。全体の流れは3ステップです:対応アーキテクチャのバイナリをダウンロードする、設定ファイルを準備する、手動で一度動かして問題ないか確認する。

ステップ1:対応する CPU アーキテクチャのバイナリをダウンロード

mihomo の公式リリースページでは amd64、arm64、armv7 などのアーキテクチャが区別されているので、まず以下のコマンドでお使いの機器のアーキテクチャを確認してから対応バージョンをダウンロードします:

uname -m
# x86_64 は amd64 に対応;aarch64 は arm64 に対応

ダウンロードしたファイルは通常 .gz 圧縮ファイルなので、展開して実行権限を付与し、後で systemd から参照しやすい固定ディレクトリに配置します:

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

ステップ2:設定ファイルを準備

サブスクリプションから変換した config.yaml を /etc/mihomo/ ディレクトリに配置し、最低限以下のフィールドが自分の必要な値になっているか確認します:

• port / socks-port:HTTP と SOCKS5 のローカルプロキシポート。
• allow-lan:このマシンが LAN 内の他機器にプロキシを提供する場合は true に設定。
• mode:rule(ルールに基づく振り分け)、global(すべてプロキシ経由)、direct(すべて直接接続)。
• external-controller:コントロールパネルのリスニングアドレス。例:127.0.0.1:9090。secret フィールドと組み合わせてアクセスキーを設定します。

ステップ3:手動で一度動かして確認

まだ systemd と結びつけず、ターミナルで直接一度動かして、設定が正常に読み込まれ構文エラーがないか確認します:

mihomo -d /etc/mihomo

ログにルールの読み込み成功、リスニングポートが開いたという表示が出て、エラーが画面に流れ続けなければ、設定ファイルが使える状態であることを意味し、次のステップの常駐サービス化に進めます。

systemd で mihomo サービスを常駐させ、接続を確認する

手動で動作確認ができたら、次は mihomo を起動時に自動起動させ、クラッシュ時に自動再起動させることです。この作業は systemd に任せるのが最も手間がかかりません。新しくユニットファイルを作成します:

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

以下の内容を書き込みます(実際のパスに応じて調整してください):

[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

保存後、以下のコマンドを順番に実行してサービスを有効化・起動します:

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

systemctl status で active (running) と表示されれば、サービスが常駐していることを意味します。日常のトラブル対処やログ確認には次のコマンドがおすすめです:

journalctl -u mihomo -f

接続確認は curl でローカルプロキシポートを直接テストできます:

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

正常な HTTP ステータス行が返れば、プロキシの経路が通っていることを意味します。現在有効なノード、通信量、ルールのマッチ状況を確認したい場合は、ブラウザで external-controller に設定したアドレス(例:http://127.0.0.1:9090/ui)を開き、オープンソースの Web コントロールパネルプロジェクトと組み合わせて確認できます。デスクトップクライアントを別途導入する必要はありません。

2つの道でのサブスクリプション更新と日常メンテナンスの違い

どちらの道を選んでも、長期的なメンテナンス方法は異なるため、事前に理解しておくと落とし穴を減らせます。

デスクトップクライアント方式のサブスクリプション更新は通常画面に「サブスクリプション更新」ボタンがあり、自動更新間隔の設定もできます。ルールセットやノードリストが更新されると即座に反映され、クライアント自体を再起動する必要はありません。ノード切り替えや振り分けモードの一時変更もクリック操作でできるため、頻繁な調整が必要な日常利用に向いています。

コマンドラインコア方式にはボタンがなく、サブスクリプション更新は通常、定期タスク(crontab)で最新の config.yaml を再ダウンロードして古いファイルを上書きし、その後 systemctl restart mihomo を一度実行して新しい設定を反映させます。更新のたびにプロセスを再起動して既存の接続を中断させたくない場合は、mihomo が提供する設定のホットリロード機能(external-controller パネルからリロードリクエストを送る方式)を検討すると、サービス中断を避けられます。

どちらの道を選んでも、設定ファイルのルール構文は共通です——同じ config.yaml は理論上デスクトップクライアントとコマンドラインコアの間で直接再利用できます。ただ、デスクトップクライアントはインポート時にグラフィカルなグループ設定やパネル設定を自動で補うことが多いです。デスクトップ機とサーバーを両方運用している場合は、同じルールソースを保持しておくと、両者間の設定不一致によるトラブル対処コストを減らせます。