プラットフォーム導入 2026-04-28 読了目安 9分

Clash の Linux における2つの導入方法:デスクトップクライアントのインストールと mihomo コマンドライン運用

Linux 環境の差は Windows や macOS よりもはるかに大きく、デスクトップ環境を持つワークステーションならグラフィカルなクライアントをそのまま導入できますが、サーバー、コンテナ、最小構成のシステムではコアのバイナリとシステムサービスによる常駐運用しか選択肢がありません。本稿ではこの2つの方法をそれぞれ実行可能な手順として解説します。

Linux の導入をなぜ2つの方法に分けて考えるのか

Windows と macOS における Clash クライアントは基本的に「インストーラーをダウンロード→ダブルクリックで実行→GUI で設定」という決まった流れで、差異はシステム権限のダイアログ程度です。Linux はそうではなく、これはエコシステム自体が分裂していることに起因します。デスクトップ向けディストリビューション(Ubuntu、Debian、Fedora Desktop など)にはウィンドウシステムやシステムトレイがあり GUI クライアントを動かせますが、クラウドサーバー、NAS、ルーター、Docker コンテナのような GUI なし環境には表示サーバーそのものが存在せず、GTK や Webview に依存するクライアントは起動できません。

これによって2つの導入方法が想定するシーンも大きく異なってきます。GUI クライアントの Clash Verge Rev は、日常業務や開発デバッグのようにノードの切り替え、通信量の確認、ルールの調整を頻繁に行うデスクトップシーンを想定し、直感的な操作を重視しています。一方 mihomo コア と systemd の組み合わせは、長期間稼働させるサーバーシーンを想定し、自動起動、クラッシュ時の自動再起動、無人運用を重視しており、GUI での操作は必要も適合もしません。どちらの方法を選ぶかを決める最初のステップは、自分のシステムに GUI 環境があるかどうかを確認することです。

方法1:deb パッケージで Clash Verge Rev をインストール(デスクトップ環境)

Clash Verge Rev は現在の Linux デスクトップにおいて開発が活発でインターフェースの完成度も高い GUI クライアントの選択肢の一つで、Tauri フレームワークをベースに構築されており、従来の Electron 実装よりもリソース消費が軽い点が特徴です。Ubuntu / Debian 系ディストリビューションを例に、公式が配布する .deb インストールパッケージを使う手順を紹介します。

ステップ1:システム依存関係の確認

Tauri アプリは画面描画に WebKitGTK コンポーネントを利用します。ほとんどのデスクトップ向けディストリビューションには標準で入っていますが、最小構成のインストールやミニマルイメージでは不足している場合があります。事前に手動で補っておくのがおすすめです。

sudo apt update
sudo apt install -y libwebkit2gtk-4.1-0 libgtk-3-0 libayatana-appindicator3-1

ヒント

一部の古いディストリビューションのリポジトリには libwebkit2gtk-4.0 しかなく 4.1 が存在しない場合があります。インストールでエラーが出たら、まず apt-cache search webkit2gtk でローカルリポジトリが実際に提供しているバージョン番号を確認し、インストールコマンド内のパッケージ名を置き換えてください。

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

対応するアーキテクチャ(amd64 または arm64)のインストールパッケージをダウンロードしたら、dpkg -i ではなく apt install でインストールします。前者は依存関係を自動処理し、後者は失敗した際に依存関係を手動で補う必要が出てきます。

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

インストールが完了するとアプリケーションメニューに Clash Verge Rev のアイコンが表示されます。初回起動時にネットワーク設定への書き込み権限を求めるプロンプトが出るので、指示に従って許可してください。

ステップ3:サブスクリプションの読み込みとプロキシの動作確認

起動後、クライアントのサブスクリプション管理画面にリンクを貼り付けて取得を完了させ、プロキシページでノードを選択します。システムプロキシまたは TUN モードを有効にした後、以下のコマンドでトラフィックがプロキシ経由になっているかを確認できます。

curl -s https://ipapi.co/json/

返ってきた結果の位置情報フィールドがノードの所在地域に変わっていれば、プロキシ経路が正しく機能していることになります。コマンドラインツールがプロキシを経由しない場合(コマンドラインのプロキシとブラウザのプロキシは異なるシステム設定項目を参照します)、http_proxy と https_proxy の環境変数を追加で設定する必要があります。あるいはクライアント側で TUN モードを有効にしてネットワーク層のトラフィックをまとめて処理させれば、ツールごとに個別設定する手間を避けられます。

デスクトップ方式でよくある依存関係の問題

エラーの症状	よくある原因	対処方法
起動しても反応がなく、ウィンドウが表示されない	WebKitGTK のバージョンが一致していない	リポジトリで実際に利用可能なバージョン番号を確認し、依存関係を再インストールする
システムトレイのアイコンが表示されない	appindicator 関連のライブラリが不足している	libayatana-appindicator3-1 もしくは各ディストリビューションの相当パッケージを追加インストールする
TUN モードの有効化に失敗する	必要なネットワーク権限が不足している	クライアントの案内に従って setcap を実行するか、権限付与のうえで再起動する

方法2:mihomo コア + systemd による常駐運用(GUI なし環境)

サーバー、NAS、コンテナなどの GUI なし環境には GUI クライアントを導入できません。このようなシーンでは通常、mihomo(Clash Meta プロジェクトを継承したコア実装)のバイナリを直接実行し、systemd でライフサイクルを管理することで、自動起動と異常終了時の自動再起動を実現します。

ステップ1:コアバイナリのダウンロードと配置

システムのアーキテクチャに対応する mihomo バイナリをダウンロードし、展開したうえで実行パスに配置し、実行権限を付与します。

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

ステップ2:設定ディレクトリと設定ファイルの準備

設定ファイルは /etc/mihomo/ にまとめて置くことをおすすめします。systemd サービスから読み込むパスを統一しやすく、後々複数の設定を管理する際にも扱いやすくなります。

sudo mkdir -p /etc/mihomo
sudo cp config.yaml /etc/mihomo/config.yaml

設定ファイル内では mixed-port(混合プロキシポート)と external-controller(外部コントロール API のアドレス)の2項目が GUI なし環境での使い方に合っているかを確認する必要があります。画面がなく通信量の確認やノード切り替えができないため、通常は external-controller を有効にし、ブラウザからアクセスできるサードパーティ製パネル(metacubexd など)と組み合わせてリモートでノードを管理します。

mixed-port: 7890
external-controller: 0.0.0.0:9090
secret: "アクセス用のパスワードを設定"

セキュリティに関する注意

サーバーにグローバル IP がある場合、external-controller を 0.0.0.0 でリスニングすると管理インターフェースがインターネット上に公開されてしまいます。必ず secret のパスワードを設定するか、ファイアウォールで接続元 IP を制限してください。そうしないと管理インターフェースがスキャンされ、プロキシルールを改ざんされる恐れがあります。

ステップ3:systemd サービスユニットの作成

新しいサービスファイル /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
LimitNPROC=500
LimitNOFILE=1000000
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW

[Install]
WantedBy=multi-user.target

-d /etc/mihomo はこのディレクトリを作業ディレクトリとして設定を読み込むことを示し、Restart=on-failure はコアのプロセスが異常終了した際に systemd が自動的に再起動することを保証します。CAP_NET_ADMIN と CAP_NET_RAW の2つの権限は、TUN モードでネットワーク層のトラフィックを処理するために必要なものであり、プロセスを完全に root 権限で実行する必要がなくなるため、比較的安全です。

ステップ4:サービスの有効化と状態確認

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

enable コマンドで自動起動を設定し、status コマンドでプロセスが active (running) 状態になっているかを確認します。状態が失敗を示している場合は、まず詳細なログを確認して原因を特定します。

journalctl -u mihomo -n 50 --no-pager

起動失敗の原因としてよくあるのは、設定ファイルのフィールド形式の誤り、ポートが他のプロセスに使用されている、あるいは TUN モードに必要なネットワーク権限が不足していることです。ログには通常、具体的なエラー行番号やフィールド名が示されるので、案内に従って一つずつ修正すれば解決できます。

GUI なし環境でのノードとルールの管理方法

ウィンドウがないからといって手探りで運用するしかないわけではありません。よく使われる管理方法として以下のようなものがあり、自分の得意な方法を組み合わせて使うことができます。

サードパーティ製 Web パネル:external-controller を有効にすれば、同一ネットワーク内のブラウザからそのアドレスにアクセスし、オープンソースの Web パネルと組み合わせてノード切り替え、遅延テスト、ルール確認といった操作を行えます。使用感は GUI クライアントに近いです。
curl で管理 API を呼び出す:mihomo の外部コントロールインターフェースは本質的に REST API であり、curl で直接リクエストを送って現在のプロキシグループの状態を確認したり、ノードを切り替えたりできます。自動化スクリプトに組み込むのに向いています。
設定ファイルを直接編集してサービスを再起動する:ルールやプロキシグループの調整は YAML ファイルを直接書き換え、systemctl restart mihomo で反映させます。変更頻度が低い固定的な環境に向いています。

サブスクリプションの更新については、設定ファイルにサブスクリプションリンクを記載している場合、cron の定期タスクと組み合わせて定期的に取得・更新し、サービスを自動再起動することでノード情報が古くならないようにできます。自動更新スクリプトはあらかじめフォーマットチェックを行っておくのが望ましく、破損した設定ファイルを取得してそのまま上書きしてしまい、サービスの再起動が失敗する事態を避けられます。

2つの方法の選び方

日常的な利用シーンが個人用ノート PC やデスクトップワークステーションで、ウィンドウやトレイアイコンが見える環境であれば、GUI クライアントの方法を選んだ方が操作のハードルが低く、systemd のコマンドを覚える必要もなく、多くの人の使い方に合っています。

クラウドサーバー、自宅の NAS、ルーターへの導入環境、Docker コンテナといったシーンでは、そもそも GUI を動かす条件が備わっていないため、mihomo コアと systemd を組み合わせる方法しか選べません。設定の保守やクラッシュ時の復旧をシステムサービスに任せ、リモートの Web パネルと組み合わせて日常的なノード管理を行うのが、現時点で GUI なし環境において比較的安定した方法です。

この2つの方法は互いに排他的なものではなく、同じユーザーが異なるデバイスで並行して使うことも可能です。業務用ノート PC には GUI クライアントを、自宅の常時稼働サーバーには mihomo と systemd を導入し、同じサブスクリプションを共有しつつ、実行形態だけを分けるという運用もできます。