Linux で Clash を動かすには全く異なる2つの経路があります。デスクトップ環境では視覚的な操作を重視し、GUI付きクライアントを直接インストールします。サーバー環境にはグラフィカルインターフェースがないため、コアプログラムと systemd を組み合わせて常駐サービスを構築する必要があります。本稿ではこの2つの経路のインストール手順、ディレクトリ構成、権限のポイントを整理します。
手を動かす前に明確にしておくべきことがあります。Linux で「Clash を導入する」というのは単一の操作ではなく、まず自分の環境タイプを判断する必要があります。デスクトップ版 Linux(Ubuntu Desktop、Fedora Workstation、各種 Linux Mint 系列など)にはウィンドウマネージャーとシステムトレイがあり、GUI付きクライアントの導入に適しています。日常的なノード切り替えやトラフィック確認はクリック操作で行えます。サーバー版 Linux(クラウドホスト、NAS、家庭用ゲートウェイ)は通常 SSH 接続のみでデスクトップ環境がなく、コマンドラインのみのコアプログラムとプロセス管理ツールを組み合わせてプロキシをバックグラウンドで常駐させるしかありません。
この2つの経路で使うソフトウェアの形態は全く異なります。デスクトップ経路では Clash Verge Rev のような Tauri フレームワークをベースにパッケージ化された GUI クライアントを使い、内部に mihomo コアを統合してサブスクリプション管理、ルール編集、トラフィックグラフの視覚的インターフェースを提供します。コマンドライン経路では mihomo コアの実行ファイルを直接実行し、インターフェースはなく、すべて設定ファイルとターミナルコマンドで操作し、さらに systemd でプロセスのライフサイクルを管理して、マシン再起動後も自動的に起動するようにします。
ヒント:自分の環境がどちらのタイプか分からない場合は echo $XDG_CURRENT_DESKTOP を実行してください。出力があればデスクトップ環境が存在します。クラウドサーバーのコンソールから SSH 接続しているマシンは、基本的にコマンドラインのみの環境です。
Clash Verge Rev の公式配布パッケージには Debian/Ubuntu 系ディストリビューション向けの .deb インストールパッケージが用意されており、現時点でデスクトップ Linux 上で最も導入しやすい方法です。手動で依存関係を設定する必要がなく、ダブルクリックまたは dpkg でインストールできます。以下が完全な手順です。
Linux デスクトップの主流は x86_64(amd64)アーキテクチャで、一部の ARM デバイス(国産ノートPCの一部や Raspberry Pi デスクトップキットなど)では aarch64 アーキテクチャのパッケージを選ぶ必要があります。アーキテクチャの判断は以下を実行します。
uname -m
# 出力が x86_64 → amd64 パッケージを選択
# 出力が aarch64 → arm64 パッケージを選択ダウンロードした deb パッケージをローカルディレクトリに置いたら、インストールコマンドを実行します。deb パッケージ自体は自動で依存関係を取得しないため、依存関係が不足している旨の表示が出たら続けて apt で補完します。
sudo dpkg -i clash-verge-rev_*.deb
# 依存関係エラーが出た場合、以下のコマンドで自動修復
sudo apt --fix-broken installインストール完了後、アプリケーションメニューにアプリが表示され、同時にシステム内にユーザーレベルのバックグラウンド補助プロセスが登録され、システムプロキシ設定と仮想ネットワークカードの権限申請を処理します。初回起動時、システムは通常グラフィカルなパスワード認証ウィンドウを表示します。これは TUN モードを有効化する際に仮想ネットワークインターフェースを構築する必要があり、その作成には root 権限が必須であるためで、これは正常な流れであり、インストールエラーではありません。
Clash Verge Rev の設定パネルには「自動起動」のスイッチがあり、有効にするとプログラムはデスクトップ環境の自動起動機構(~/.config/autostart/ 下の .desktop ファイル仕様に準拠)を通じてユーザーログイン時に自動起動します。スイッチが機能しない場合は、このディレクトリに対応する desktop ファイルが生成されているか手動で確認できます。
ls ~/.config/autostart/ | grep -i clash生成されていない場合は、アプリのインストールディレクトリから desktop ファイルをこのパスにコピーするか、設定パネルで自動起動スイッチを一度オフにしてから再度オンにすると、多くの場合登録プロセスが再度トリガーされます。
Debian 系以外のディストリビューションには各自の対応方法があります。
.rpm 形式も用意されており、sudo rpm -i または sudo dnf install でローカルファイルを指定すればインストールできます。yay や paru といった AUR ヘルパーツールで検索・インストールすれば、依存関係は自動的に解決されます。サーバーにはデスクトップ環境がなく、GUI クライアントを導入する必要もできません。mihomo コア(Clash Meta プロジェクトの後継)を直接導入する方が合理的です。コア自体は単一の実行ファイルで、消費するリソースは極めて少なく、systemd で管理すればマシン再起動後もプロキシサービスが自動的に復旧し、手動での対応が不要になります。
導入前にディレクトリ構造を計画しておくことで、設定ファイルとプログラム本体が混在するのを避け、後でコアのバージョンをアップグレードする際に設定を誤って削除するリスクを減らせます。
/etc/mihomo/ # 設定ファイルディレクトリ
├── config.yaml # メイン設定ファイル
├── geoip.dat # GeoIP データベース
└── geosite.dat # GeoSite データベース
/usr/local/bin/mihomo # コア実行ファイルコアの実行ファイルを /usr/local/bin のようなシステムレベルの実行ディレクトリに置き、設定ファイルは独立して /etc/mihomo に置くのは、Linux でのソフトウェア導入における一般的な慣習で、systemd による統合管理がしやすく、後で手動で設定を調査する際も迅速に特定できます。
mkdir -p /etc/mihomo
cd /usr/local/bin
# 対応アーキテクチャのコア圧縮パッケージをダウンロード・展開済みで mihomo ファイルが得られたと仮定
chmod +x mihomo
mihomo -v # 正常に実行できバージョン番号が出力されるか確認サーバーのアーキテクチャ判断も同様に uname -m を使います。クラウドホストの大多数は x86_64 ですが、一部の海外の安価なサービスプロバイダーや ARM クラウドインスタンス(軽量アプリケーションサーバーなど)は aarch64 です。ダウンロード前に必ず確認してください。アーキテクチャが一致しない実行ファイルは実行時に即座にエラーで終了します。
サブスクリプションから変換した YAML 設定ファイルを /etc/mihomo/config.yaml に配置し、内部の重要なフィールドに問題がないか確認します。特に external-controller の項目は要注意です。サーバー環境でこのアドレスを開放し 0.0.0.0 にバインドすると、コアの制御インターフェースを公開インターネットに晒すことになるため、必ずアクセスキーを設定するかローカルアドレスのみにバインドしてください。
external-controller: 127.0.0.1:9090
secret: "十分に複雑なキーを設定してください"新しいサービスファイル /etc/systemd/system/mihomo.service を作成し、以下の内容を記述します。
[Unit]
Description=mihomo Daemon
After=network.target
[Service]
Type=simple
User=root
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
LimitNOFILE=65535
[Install]
WantedBy=multi-user.targetいくつかのフィールドについて重点的に説明します。-d /etc/mihomo はコアがこのディレクトリ内の設定ファイルを読み込むよう指定するもの、Restart=on-failure はプロセスが異常終了した際に自動再起動することを示し、一度のネットワークの揺れでプロキシサービスが完全に中断するのを防ぎます。LimitNOFILE はファイルディスクリプタの上限を上げるもので、プロキシサービスは大量の同時接続を維持する必要があるため、システムのデフォルト制限では高負荷時に接続エラーが起きやすいからです。
sudo systemctl daemon-reload
sudo systemctl enable mihomo
sudo systemctl start mihomo
sudo systemctl status mihomoenable コマンドは自動起動のシンボリックリンクを構築する役割を持ち、これによりサーバー再起動後に手動でコマンドを実行する必要なく、mihomo がシステムと共に自動起動します。status コマンドは現在の稼働状態を確認するもので、active (running) の行が正常かどうかを重点的に確認してください。
Linux 環境でプロキシを導入する際に最もつまずきやすいのは権限の問題です。ここで整理しておきます。
設定ファイルで tun.enable: true を有効にしている場合、コアは仮想ネットワークインターフェースを作成しルーティングテーブルを変更する必要があり、この操作は Linux では CAP_NET_ADMIN 権限が必須です。root 権限で systemd サービスを実行するのが最も簡単な解決方法です(前述のサービスユニット内の User=root の通り)。しかし、セキュリティ上の理由からプロキシプロセスを root 権限で常駐させたくない場合は、setcap コマンドで実行ファイルに個別に権限を付与し、一般ユーザー権限で実行することもできます。
sudo setcap cap_net_admin,cap_net_bind_service=+ep /usr/local/bin/mihomo権限付与後、サービスユニット内の User=root をプロキシサービス専用に作成した一般ユーザーに変更し、権限範囲をさらに絞ることが、サーバーのセキュリティ実践においてより推奨される方法です。
一般ユーザーでサービスを実行する場合、設定ディレクトリに対応するユーザーの読み取り権限を付与することを忘れないでください。そうしないとコアは設定ファイルを読み込めず起動時に即座に終了します。
sudo chown -R clash-user:clash-user /etc/mihomoサービス起動後、まずポートが正常にリスニングしているか確認します。
sudo ss -tlnp | grep mihomo次にコマンドラインからプロキシ経由のリクエストを送信し、出口 IP が変化しているか確認します。
curl -x http://127.0.0.1:7890 https://api.ip.sb/ip返ってきた IP がノードの出口アドレスでサーバー本体のアドレスでなければ、プロキシ経路が正常に機能していることを示します。デスクトップ環境で Clash Verge Rev を使っている場合は、クライアント内の接続状態とレイテンシテストの結果を確認するだけでよく、手動での curl 確認は不要です。
注意:サーバーシナリオで mihomo を使うのは通常、社内・LAN内のデバイスに統一されたプロキシ出口を提供するためであり、サーバー自身が「壁を越える」ためではありません。bind-address を設定する際は、どのローカルネットワーク IP セグメントにアクセスを許可するか明確にし、ポートを公開インターネットに無制限に開放することによるセキュリティリスクを避けてください。
両方の経路の導入が完了した後、日常的な運用の重点はそれぞれ異なります。以下に整理します。
デスクトップクライアント側:Clash Verge Rev にはサブスクリプション自動更新機能が組み込まれており、設定で更新周期を設定できるため、毎回手動でサブスクリプションリンクを再インポートする必要はありません。複数のサブスクリプション源を切り替えている場合は、各設定ファイルを一目で識別できる名前にリネームすることをお勧めします。誤って無効なサブスクリプションに切り替えるのを防げます。
コマンドラインサービス側:設定ファイルを更新した後、サービス全体を再起動する必要はなく、mihomo は RESTful API によるホットリロードをサポートしています。もしくは直接 systemctl restart mihomo でサービスを再起動して反映させることもできます。設定ディレクトリの定期バックアップをお勧めします。特にカスタムルールが多いシナリオでは、一度の誤操作で設定が上書きされるとルールがすべて失われる可能性があります。
また、どちらの経路であっても、GeoIP と GeoSite データベースは定期的に更新することをお勧めします。データベースが古すぎると振り分けルールの誤判定を招き、「プロキシを通すべきドメインが通らず、直結すべきアドレスが逆にプロキシを経由する」といった状況が発生します。具体的な更新方法とトラブルシューティングの手順は、データベース更新に関する技術ノートを参照してください。
| 項目 | デスクトップ経路(Clash Verge Rev) | コマンドライン経路(mihomo + systemd) |
|---|---|---|
| 適用シーン | 日常業務・開発用のデスクトップ Linux | クラウドサーバー、NAS、デスクトップ非搭載のゲートウェイ機器 |
| 操作方法 | GUI でのクリック操作 | ターミナルコマンド + 設定ファイル |
| インストール形式 | deb/rpm/AppImage | 単一のコア実行ファイル |
| 常駐方式 | デスクトップの自動起動機構 | systemd サービスユニット |
| 権限のポイント | 初回起動時の GUI 認証 | CAP_NET_ADMIN または root 実行 |