Linux 導入 読了目安 14 分

LinuxでClashをインストール：デスクトップクライアント、mihomo CLI、systemdの設定手順

デスクトップ環境からGUIなしのサーバーまで、設定ディレクトリ、サービス起動、ログ確認、プロキシ環境変数を解説します。

導入方法とCPUアーキテクチャを確認する

Linuxで「Clashをインストールする」ときは、通常2つの方法があります。デスクトップ向けはGUIクライアントでカーネル、サブスクリプション、システムプロキシ、プロキシグループを管理する方式で、Ubuntu、Debian、Fedora、Arch Linuxなどのデスクトップ環境に適しています。CLI方式ではmihomoカーネルを直接実行し、systemdでプロセスを管理します。サーバー、ソフトウェアルーター、開発マシン、GUIのない端末に向いています。

2つの方式で行う処理の中心は同じです。YAML設定を読み込み、ローカルのプロキシポートで待ち受け、ルールに従ってポリシーを選択し、設定されたノードへ接続を転送します。主な違いは管理方法です。GUIクライアントにはサブスクリプション更新、ポリシー切り替え、ログ画面があります。一方、CLI方式では設定ディレクトリ、サービス権限、ログ、更新手順を自分で管理する必要があります。

現在のLinux CLI環境では、継続的にメンテナンスされているmihomoを選ぶのが一般的です。Clash Metaの派生プロジェクトで、Clashで使われるルール、プロキシグループ、プロキシプロバイダー、DNS、TUN設定に対応しています。古い設定を移行する際は拡張子だけで判断せず、使用中のルール種別、スクリプト項目、DNSオプション、実験的機能が現在のカーネルでサポートされているか確認してください。

ダウンロード前にCPUアーキテクチャを確認します。パッケージ名のアーキテクチャはシステムと一致している必要があり、ディストリビューション名だけで判断してはいけません。次のコマンドでカーネルが報告するアーキテクチャを確認します。

uname -m
getconf LONG_BIT
コマンド出力 よく使われるパッケージ識別子 代表的なデバイス
x86_64 amd64 または x86_64 主なIntel、AMD製デスクトップPCとサーバー
aarch64 arm64 または aarch64 64ビットARMサーバー、開発ボード
armv7l armv7 一部の32ビットARMデバイス

デスクトップディストリビューションにGUIクライアントをインストールする

デスクトップユーザーは、現在もメンテナンスされ、Linux版が明確に提供されているクライアントを優先してください。一般的な配布形式にはAppImage、Debianパッケージ、RPMパッケージがあります。形式を選ぶ際は、アーキテクチャ、デスクトップ環境、アプリのリリースノートを同時に確認します。GUIクライアントは通常、ユーザー設定をシステム共通の/etcではなく、ホームディレクトリ内のアプリデータディレクトリに保存します。

AppImageをインストールする

AppImageは単一ファイルで実行できる形式で、システムのソフトウェアソースを変更したくないデスクトップ環境に適しています。アーキテクチャに合ったファイルをダウンロードしたら、まず実行権限を付与し、ターミナルから起動します。以下では、インストールファイルが現在のユーザーのDownloadsディレクトリに保存されているものとします。実際のファイル名はダウンロード結果に合わせてください。

cd "$HOME/Downloads"
chmod +x Clash*.AppImage
./Clash*.AppImage

ターミナルから起動できるのにファイルマネージャーでダブルクリックしても反応しない場合は、ターミナルで起動エラーを確認してください。一部のディストリビューションではFUSEランタイムが必要です。また、AppImageによっては展開して実行することもできます。ファイルの出所や権限への影響が不明なままsudoでGUIクライアントを起動しないでください。設定がrootユーザーのディレクトリに保存され、後から通常ユーザーに「設定が消えた」「ファイルを変更できない」と見える原因になります。

DEB・RPMパッケージ

Debian、Ubuntuおよび派生ディストリビューションでは、対応するDEBパッケージをインストールできます。APTでローカルファイルをインストールすると、パッケージが宣言する依存関係も同時に処理できます。

sudo apt install ./クライアントファイル名.deb

Fedora、Rocky LinuxなどRPM系のディストリビューションでは、DNFでローカルパッケージをインストールできます。

sudo dnf install ./クライアントファイル名.rpm

インストール後はアプリメニューから起動し、サブスクリプションまたはローカルのYAMLファイルを読み込みます。サブスクリプションURLはサービス提供元から入手してください。クライアントの「サブスクリプションを更新」は通常、設定を再ダウンロードする操作であり、クライアントやプロキシカーネルの更新とは別です。3種類の更新をそれぞれ確認してください。

デスクトップ版の初回確認

  1. 設定画面で、サブスクリプションからノードとプロキシグループが正しく読み込まれていることを確認します。
  2. ログを開き、待ち受けポートが正常に作成されているか確認します。
  3. 使用するポリシーノードを選択し、プロキシグループが利用できない項目のままにならないようにします。
  4. 通信を引き受ける範囲に応じてシステムプロキシまたはTUNを選択します。許可なくTUNを有効にしないでください。
  5. クライアント終了後、システムプロキシが元に戻っているか確認します。デスクトップ環境に無効なローカルポートが残るのを防げます。

GNOME、KDE、Xfceでは、トレイアイコンやシステムプロキシの扱いが完全には統一されていません。トレイアイコンが消えても、カーネルが停止したとは限りません。プロセス、待ち受けポート、ログを組み合わせて判断してください。Waylandセッションでは、一部クライアントのウィンドウやトレイ実装がデスクトップ拡張機能やパッケージ形式の影響を受けることもあります。

mihomo CLIカーネルをインストールする

GUIのないサーバーにデスクトップクライアントは必要ありません。基本ディレクトリは3つに分けられます。実行ファイルは/usr/local/bin、設定は/etc/mihomo、実行ログはsystemd journalに保存します。こうするとカーネルの更新で設定が上書きされず、権限も一元管理しやすくなります。

まず設定ディレクトリを作成します。続いて、ダウンロードして展開済みの、現在のアーキテクチャに合ったバイナリを目的の場所へ移動します。

sudo install -d -m 0750 /etc/mihomo
sudo install -m 0755 mihomo /usr/local/bin/mihomo
/usr/local/bin/mihomo -v

バージョンコマンドが正常に出力されれば、少なくとも現在のシステムでバイナリを実行できます。Exec format errorが表示された場合は、まずCPUアーキテクチャを確認してください。ファイルが存在するのに見つからないと表示される場合は、アーカイブが完全に展開されているか、動的リンクの要件を満たしているか、実行禁止のマウントポイントに置かれていないかも確認します。

サービスを正式に作成する前に、フォアグラウンドで一度起動テストを行うことをおすすめします。設定を/etc/mihomo/config.yamlとして保存したら、次を実行します。

sudo /usr/local/bin/mihomo -d /etc/mihomo

-dは作業ディレクトリを指定します。カーネルはこのディレクトリからメイン設定を読み込み、キャッシュ、ルールデータ、その他の実行ファイルを保存することがあります。フォアグラウンドで起動すると、YAMLの解析、ポート競合、ルールのダウンロード、DNS初期化のエラーを直接確認できます。正常動作を確認したらCtrl+Cで停止し、systemdへ切り替えます。

設定ディレクトリ、サブスクリプション、最小起動設定

サブスクリプションは通常、完全なYAMLを返しますが、サービス側で変換された設定を返す場合もあります。保存前に、レスポンスがログインページ、エラーメッセージ、アクセス確認ページではなく、本当に設定テキストであることを確認してください。HTMLの内容をそのままconfig.yamlに保存すると、起動時に解析エラーが報告されます。

以下の設定は、ローカルポートとコントロールインターフェースの基本的な関係を示すもので、完全なサブスクリプションではありません。実際のプロキシノード、プロキシグループ、ルールは有効な設定から取得してください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false

external-controller: 127.0.0.1:9090
secret: "このホストだけで管理に使うパスワードを設定"

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false

proxies: []
proxy-groups: []
rules:
  - MATCH,DIRECT

mixed-portはHTTPとSOCKS5のプロキシ接続を同時に受け付けるため、CLIツールで統一して設定できます。allow-lan: falseは、LAN上のデバイスにプロキシを公開しないことを示します。LANにサービスを提供する必要がある場合は、待ち受けアドレス、ファイアウォールルール、アクセス範囲も設定してください。このスイッチを有効にするだけでは不十分です。

external-controllerはコントロールインターフェースであり、通常のプロキシポートではありません。パネルと組み合わせる場合は、待ち受け範囲を制限し、secretを設定してください。コントロールインターフェースをすべてのネットワークインターフェースに公開すると管理面が広がります。サーバーでは、まずループバックアドレスで待ち受け、管理用の制御された経路からアクセスするのが安全です。

サブスクリプションから設定を取得したら、既存ファイルをバックアップしてからアトミックに置き換えます。カーネルを再読み込みする前に、ファイル権限を確認してください。

sudo cp /etc/mihomo/config.yaml /etc/mihomo/config.yaml.bak
sudo chown root:mihomo /etc/mihomo/config.yaml
sudo chmod 0640 /etc/mihomo/config.yaml

サービスアカウントが設定ディレクトリにキャッシュやルールセットを書き込む必要がある場合は、ディレクトリのグループにも必要な操作を許可します。権限が厳しすぎるとプロキシプロバイダーを更新できず、権限が不統一だと手動起動は成功するのにsystemdでは失敗することがあります。

systemdでmihomoを管理する

systemdを使うと、起動時にカーネルを開始し、再起動、状態、ログを一元管理できます。まず権限を制限したシステムユーザーを作成します。このアカウントにログインシェルやホームディレクトリは必要ありません。

sudo useradd --system --no-create-home --shell /usr/sbin/nologin mihomo
sudo chown -R mihomo:mihomo /etc/mihomo

/etc/systemd/system/mihomo.serviceに次のサービスユニットを記述します。この基本構成はHTTP、SOCKS、ルール分岐に対応します。設定でTUNを有効にしている場合は、ネットワーク機能とデバイス権限を追加で設定する必要があります。

[Unit]
Description=mihomo proxy service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=mihomo
Group=mihomo
WorkingDirectory=/etc/mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

保存後、systemdの設定を再読み込みし、サービスを起動して自動起動を有効にします。

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
systemctl status mihomo --no-pager

ログの確認にはjournalctlを使います。初回起動時は直近のログ全体を確認し、継続的なトラブルシューティングでは出力を追跡します。

journalctl -u mihomo -n 100 --no-pager
journalctl -u mihomo -f

YAMLを変更したらsudo systemctl restart mihomoを実行できます。再起動前にフォアグラウンドでコピーをテストし、設定構文の誤りによるサービス停止を避けてください。サブスクリプション内のポリシー選択だけを変更した場合も、選択結果がYAMLではなくキャッシュに保存されていないか、クライアントやコントロールパネルで確認します。

TUNモードのsystemd権限

TUNは仮想ネットワークインターフェースを作成してルーティングを変更するため、通常のローカルプロキシより高いネットワーク権限が必要です。サービスユニットの[Service]セクションに必要なケーパビリティを追加すると、サービス全体をrootで常時実行するより権限範囲を管理しやすくなります。

AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW

/dev/net/tunが存在し、カーネルモジュールが利用可能で、サービスアカウントがデバイスへアクセスできることも確認してください。コンテナや制限された仮想マシンでは、ホスト側でTUNデバイスとネットワーク管理機能が許可されている必要があります。設定でTUNを有効にしても、実行環境がこれらの条件を満たすとは限りません。

ディストリビューションによっては、systemdのセキュリティポリシー、SELinux、AppArmorのルールがネットワーク操作をさらに制限します。ログのpermission deniedはカーネルの監査記録と合わせて判断し、ネットワーク機能の問題をディレクトリ権限の拡大だけで解決しようとしないでください。

ターミナル、パッケージマネージャー、リモートセッションでプロキシを使う

mihomoがポートで正常に待ち受けても、アプリケーション側からそのポートへリクエストを送る必要があります。システムプロキシ、環境変数、TUNはそれぞれ異なる経路です。CLIサーバーでは環境変数が最も一般的で、デスクトップアプリは通常デスクトップ環境のシステムプロキシを読み取ります。プロキシ設定に従わないアプリにはTUNを検討します。

現在のターミナルだけで一時設定する

mixed-portが7890の場合、現在のshellでは次のように設定できます。

export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
export all_proxy="socks5h://127.0.0.1:7890"
export no_proxy="127.0.0.1,localhost,::1"

export HTTP_PROXY="$http_proxy"
export HTTPS_PROXY="$https_proxy"
export ALL_PROXY="$all_proxy"
export NO_PROXY="$no_proxy"

socks5hのhは、宛先ホスト名の解決をプロキシ側で行うことを示し、この記法に対応するツールに適しています。すべてのプログラムが同じ変数群を読み取るわけではないため、大文字・小文字の両方を設定するとCLIツールとの互換性を高められます。現在のshellを終了すると、これらの一時変数は無効になります。

変数を~/.profileやshellの初期化ファイルに書き込むと、ログインのたびに有効になります。ただしサービス停止中も、それらの変数を読み取るプログラムはローカルポートへ接続しようとします。長期運用するサーバーでは、必要なときだけプロキシを有効化・解除する専用スクリプトの利用が適しています。

unset http_proxy https_proxy all_proxy no_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

APT、DNF、Git

APTとDNFは通常、実行環境のプロキシ環境変数を引き継げますが、sudoで実行するとセキュリティポリシーによって環境変数が削除される場合があります。恒久的に設定する場合は、ソフトウェア自身のプロキシ設定ファイルを使い、必要なソースだけに適用してください。Gitではユーザー単位でHTTPプロキシを設定できます。

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

Gitの設定を解除するには次を実行します。

git config --global --unset http.proxy
git config --global --unset https.proxy

SSHはHTTPプロキシ環境変数を自動的には読み取りません。SSHでリポジトリを取得する場合、接続経路はSSH設定とProxyCommandで決まります。ブラウザーで正常にアクセスできても、SSHも正常だとは限りません。

リモートサーバーのアクセス範囲

SSHでリモートサーバーを管理している場合、127.0.0.1:7890は管理者のPCではなく、リモートサーバー自身を指します。mihomoが手元のPCで動作しているなら、SSHポート転送でプロキシポートをリモート側へ転送します。サーバーにmihomoをインストールしているなら、アプリケーションをサーバー自身の待ち受けポートへ接続させます。ループバックアドレスとLANアドレスを混同しないでください。

起動失敗、ポート競合、DNSのトラブルシューティング

サービスが繰り返し再起動する

まずsystemctl status mihomoで終了コードを確認し、直近100行のログを読みます。YAMLのインデントエラー、項目の型エラー、設定ファイルの読み取り不可、作業ディレクトリへの書き込み不可などが起動失敗の原因になります。systemdの自動再起動でログがすぐ流れてしまうため、まずサービスを停止し、同じアカウントでフォアグラウンド実行します。

sudo systemctl stop mihomo
sudo -u mihomo /usr/local/bin/mihomo -d /etc/mihomo

この手順で、「rootで手動実行すると正常だが、サービスアカウントでは失敗する」という権限差を確認できます。修正後にサービスを起動し、テスト用インスタンスとsystemdのインスタンスを同時に残さないでください。

ポートがすでに使用されている

ssで待ち受けポートと対応するプロセスを確認します。

sudo ss -lntup | grep -E '7890|7891|9090|1053'

よくある競合原因は、別のClash GUIクライアント、古いmihomoプロセス、その他のローカルプロキシです。重複したインスタンスを停止するかポートを変更し、環境変数、デスクトップのシステムプロキシ、コントロールパネルのアドレスも同時に更新してください。YAMLだけ変更してアプリ側のプロキシアドレスを変更しないと、カーネルは正常に動作しているのにリクエストがすべて失敗する状態になります。

ノードはあるが接続できない

まずログで失敗した段階を確認します。名前解決の失敗、接続タイムアウト、TLSハンドシェイク失敗、認証失敗はそれぞれ異なる問題を示します。サーバー時刻が正確か確認し、サブスクリプションの有効期限を確認してから、プロキシグループで現在選択されている項目をテストします。ルールモードでは、リクエストが最終的にどのルールとポリシーに一致したかも確認し、ルール分岐の問題をノード障害と誤認しないようにします。

一部のドメインだけ異常な場合は、DNS設定、ルールセットの更新状態、IPv6経路を確認します。設定でIPv6を無効にしても、カーネルに関係する名前解決や接続先選択に影響するだけで、OS全体のIPv6動作が停止するとは限りません。デスクトップブラウザーが独自のセキュアDNSを使う場合もあるため、ブラウザー、システム、mihomoそれぞれの名前解決経路を確認してください。

システムプロキシを有効にしても一部のアプリが直接接続する

システムプロキシは、デスクトップ環境が提供するプロキシパラメーターにすぎません。ブラウザーや多くのデスクトップアプリは読み取りますが、ゲーム、コンテナ、一部のCLIプログラム、独自のネットワークスタックを実装したソフトウェアは無視することがあります。まずアプリ自身のプロキシ設定や環境変数を試し、より多くの通信を引き受ける必要がある場合にTUNを導入します。

Dockerコンテナ内の127.0.0.1はコンテナ自身を指します。コンテナからホストのプロキシへ接続するには、到達可能なホストアドレスを使い、mihomoの待ち受け範囲とファイアウォールが送信元を許可していることを確認します。allow-lanを有効にした場合も、待ち受けインターフェースを確認し、プロキシポートを管理されていないインターネット側インターフェースへ直接公開しないでください。

アップデート、バックアップ、日常メンテナンス

CLIカーネルの更新では、バイナリと設定を分けて扱います。現在のバージョンを記録し、サービスを停止してから/usr/local/bin/mihomoを置き換え、バージョン出力を再確認してサービスを起動し、ログを監視します。設定形式が変わった場合は、対象バージョンのリリースノートを読み、テスト環境で検証してから本番インスタンスを置き換えてください。

次の内容をバックアップすることをおすすめします。メイン設定、手動管理しているオーバーライドルール、systemdサービスユニット、環境変数スクリプトです。キャッシュデータベースや自動ダウンロードされたルールセットは通常再生成できますが、ポリシー選択がキャッシュに依存している場合、作業ディレクトリを削除するとプロキシグループが初期値に戻ることがあります。

サーバーを長期運用する場合は、次の状態を定期的に確認します。

  • systemctl is-active mihomoが実行中の状態を返すか。
  • ローカルプロキシ、DNS、コントロールポートが想定したアドレスだけで待ち受けているか。
  • ログにルールのダウンロード失敗、DNSタイムアウト、接続リトライが継続して出ていないか。
  • サブスクリプションの更新時刻とノードの利用可能状態が想定どおりか。
  • サービス再起動後にTUNルートが正しく復元されているか。
  • パッケージ更新後に、サービスアカウント、デバイス権限、セキュリティポリシーが変わっていないか。

インストールと設定を続ける

Linuxのアーキテクチャと利用環境に合ったクライアントを選び、クイックスタートに沿ってサブスクリプションの読み込み、ポリシー選択、プロキシモードの設定を行います。

ダウンロードページへ クイックスタートを見る
Clash をダウンロード