Linux導入 読了目安 14分

LinuxでClashを導入する方法：デスクトップクライアント、mihomoコマンドライン、サービスの自動起動

デスクトップ環境からヘッドレスサーバーまで、設定ディレクトリ、起動コマンド、systemdサービス、ターミナルのプロキシ変数を解説します。

まず導入方法を決める：デスクトップ、コマンドライン、それとも常駐サービス

LinuxでのClash導入には、通常いくつかの選択肢があります。GNOME、KDE、Xfceなどのデスクトップ環境を使う個人用PCには、GUIクライアントが適しています。リモートサーバー、開発コンテナのホスト、SSHだけで管理する機器では、mihomoコアを直接実行する方法が向いています。電源投入後に自動起動し、ローカルのプロキシポートを長時間提供する場合は、コマンドライン実行に加えてsystemdサービスを設定します。

mihomoは、継続的にメンテナンスされているClash Metaのコア名称です。YAML設定の読み込み、プロキシ接続の確立、ルールマッチングの実行、HTTP・SOCKS・mixedポートの待ち受けを担当します。GUIクライアントは通常、その上位層でサブスクリプション管理、ノード切り替え、ログ確認、システムプロキシの切り替えを提供します。つまり、デスクトップクライアントは操作性を担い、コアは実際の通信処理を担います。接続に問題がある場合は、画面上の状態、設定内容、コアの稼働状態のどこに原因があるかを切り分けてください。

利用環境 推奨方式 主な管理方法
Linuxデスクトップでの日常利用 GUIクライアント トレイメニュー、クライアント設定、ログ画面
ヘッドレスサーバー mihomoコマンドライン SSH、設定ファイル、実行ログ
長時間稼働するワークステーションまたはサーバー mihomo＋systemd systemctlとjournalctl
より多くのアプリの通信を制御したい場合 TUNモード 設定ファイル、ルーティング、権限設定

導入前にプロセッサのアーキテクチャも確認します。一般的な個人用PCやクラウドサーバーは通常 amd64 で、一部の開発ボード、ルーター、ARMクラウドホストでは arm64 が使われます。uname -m を実行するとシステムの報告を確認できます。x86_64 は amd64、aarch64 は arm64 に対応します。アーキテクチャの異なるバイナリをダウンロードすると、Shellから実行できない、または形式が正しくないというエラーが表示されることがあります。

Linuxデスクトップクライアント：インストール形式、設定ディレクトリ、プロキシ切り替え

デスクトップ環境では、現在もメンテナンスされ、mihomoへの対応が明記されたGUIクライアントを優先するとよいでしょう。代表的な配布形式にはAppImage、Debian系で使われる .deb、FedoraやopenSUSEなどで使われる .rpm があります。形式はディストリビューションのパッケージ管理方式に合わせて選び、クライアントのためにシステムのソフトウェアソースを変更する必要はありません。

AppImageの実行方法

AppImageは通常、単一ファイルで配布されます。ダウンロード後に実行権限を付与してください。以下のコマンドは、ファイルが現在のディレクトリにあることを前提にしています。実際には、ダウンロードしたファイルの完全な名前を指定します。

chmod +x Clash-Linux.AppImage
./Clash-Linux.AppImage

ダブルクリックしてもウィンドウが表示されない場合は、いったんターミナルから起動して出力を確認します。新しいディストリビューションでは、AppImageが必要とするFUSE互換コンポーネントが不足している場合があります。また、デスクトップのサンドボックス、ディスプレイサーバー、権限設定が起動を妨げることもあります。ターミナルの出力は、デスクトップに表示される短い通知より原因の特定に役立つことが多いです。

debとrpmのインストール

Debian、Ubuntuおよびその派生システムでは、パッケージマネージャーを使ってローカルのdebファイルをインストールできます。依存関係はシステムに処理させましょう。

sudo apt install ./clash-client-linux-amd64.deb

Fedoraでは次のコマンドを使用できます。

sudo dnf install ./clash-client-linux-x86_64.rpm

インストール後、アプリケーションメニューからクライアントを起動します。初回起動では通常、次の3段階を行います。サブスクリプションまたはYAML設定を読み込み、プロキシグループから利用可能なノードを選び、システムプロキシを有効にします。システムプロキシの設定が反映されるのは、デスクトップのプロキシ設定に従うアプリだけです。一部のターミナルプログラム、コンテナ、ゲーム、独自のネットワークスタックを使うソフトウェアは、この設定を自動的に読み取りません。

GUIクライアントの設定ディレクトリはプロジェクトごとに異なります。一般的には ~/.config/ 配下のアプリ専用ディレクトリや、~/.local/share/ 配下のデータディレクトリが使われます。クライアントの実行中に、データベースや管理対象の設定を直接上書きしないでください。移行する場合は、まずクライアントを終了してからアプリのディレクトリをバックアップします。クライアントにエクスポート機能がある場合は、そちらを優先してください。

デスクトッププロキシを有効にしたら、まずクライアントのログにポートの待ち受け成功が記録されているか確認し、その後ブラウザーでアクセスをテストします。ブラウザーは正常なのにターミナルのコマンドが失敗する場合、通常はターミナルのプログラムがシステムプロキシを読み取っていないのであって、コアやノード自体が停止しているとは限りません。

mihomoコマンドライン導入：ディレクトリ、設定、起動確認

GUIのない環境では、実行ファイル、設定ファイル、実行データを分けて管理することをおすすめします。システム全体で使う場合は、バイナリを /usr/local/bin/mihomo、設定ディレクトリを /etc/mihomo に置きます。現在のユーザーだけが使う場合は、設定を ~/.config/mihomo に置いてもかまいません。コアがキャッシュ、ルールデータ、実行状態を保存する場合があるため、設定ディレクトリには実行アカウントの読み書き権限が必要です。

バイナリをインストールしたら、まず実行できることを確認します。

mihomo -v
mihomo -h

ターミナルにコマンドが見つからないと表示された場合は、ファイルが PATH に含まれるディレクトリにあるか、実行権限があるかを確認します。バイナリが現在のディレクトリにある場合は ./mihomo を使います。Shellは標準では現在のディレクトリからコマンドを検索しません。

mihomoはYAML設定を使用します。以下は待ち受けポートとルールエンジンを確認するための最小構成例です。すべての通信を直接接続し、リモートノードは含みません。

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

proxies: []
proxy-groups: []

rules:
  - MATCH,DIRECT

ファイルを config.yaml として保存したら、まず設定を検証します。対応するコマンドオプションはバージョンによって多少異なるため、mihomo -h の出力を基準にしてください。一般的な確認方法は次のとおりです。

mihomo -t -d /etc/mihomo

検証に合格したら、フォアグラウンドで起動します。

mihomo -d /etc/mihomo

-d は作業ディレクトリを指定します。コアはそのディレクトリからメイン設定と関連データを読み込みます。初回導入時はすぐにバックグラウンドへ移行せず、まず起動ログを確認してください。YAMLを解析できること、ポートが使用中でないこと、ルールファイルを読み込めることを確認します。mixedポートの待ち受け成功を確認したら、別のSSHセッションを開いてプロキシをテストします。

curl --proxy http://127.0.0.1:7890 https://example.com/

実際に使うサブスクリプション設定には通常、プロキシノード、プロキシグループ、ルール、DNS、ルールプロバイダーが含まれます。設定を更新する際は、YAMLの構文だけでなく、プロキシグループが参照するノードやプロバイダー名が存在するか、ルール末尾に妥当なフォールバックがあるか、使用するフィールドが現在のmihomoバージョンでサポートされているかも確認してください。

systemdサービスの自動起動：実行アカウント、再起動ポリシー、ログ

長時間稼働させる場合は、mihomoをsystemdのシステムサービスとして登録できます。システムサービスは、起動直後からプロキシポートを提供したいマシンに適しており、終了状態や実行ログも一元的に確認できます。サービスを作成する前に、専用アカウントと設定ディレクトリを用意します。

sudo useradd --system --home-dir /var/lib/mihomo --create-home --shell /usr/sbin/nologin mihomo
sudo mkdir -p /etc/mihomo
sudo chown -R mihomo:mihomo /etc/mihomo /var/lib/mihomo
sudo chmod 750 /etc/mihomo

次に /etc/systemd/system/mihomo.service を作成します。

[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
sudo systemctl status mihomo

今回の起動ログは次のコマンドで確認できます。

sudo journalctl -u mihomo -b
sudo journalctl -u mihomo -f

-b は今回の起動後の記録だけを表示し、-f は新しいログを継続的に追跡します。YAMLを変更した後は、まず単独で設定を検証してからサービスを再起動してください。

sudo -u mihomo /usr/local/bin/mihomo -t -d /etc/mihomo
sudo systemctl restart mihomo

現在のユーザーがログインしている間だけ実行する場合は、systemdのユーザーサービスも利用できます。ユニットファイルを ~/.config/systemd/user/ に置き、systemctl --user で管理します。ユーザーサービスに専用のシステムアカウントは不要ですが、標準ではユーザーセッションの存続期間に左右されます。ログアウト後も実行を続ける場合は、システムのlinger設定を含め、権限と保守方法を検討してください。

サービスを無条件に高速再起動する設定は避けてください。設定構文の誤り、ポートの競合、ファイル権限の問題は、連続再起動で自動的に解決しません。むしろ同じログが大量に生成される可能性があります。Restart=on-failure に数秒の間隔を組み合わせるほうが、断続的なプロセス終了への対応に適しています。

ターミナルのプロキシ変数：HTTP_PROXY、ALL_PROXY、NO_PROXY

Linuxデスクトップの「システムプロキシ」は、すべてのShellコマンドに自動適用されるわけではありません。curl、Git、一部のパッケージマネージャー、開発ツールは環境変数を読み取るため、コマンドライン環境では別途設定が必要です。mihomoのmixedポートが 7890 だとすると、現在のターミナルで次を実行します。

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=localhost,127.0.0.1,::1

大文字と小文字の変数を同時に設定すると、より多くのツールに対応できます。

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

socks5h の h は、ドメイン名の名前解決も SOCKS プロキシ側に委ねることを示します。ローカル DNS の経路差を抑えたいコマンドライン通信に適しています。ただし、プロキシプロトコルや環境変数の優先順位に対する実装はツールごとに異なります。問題が発生した場合は、まず curl でプロキシを明示してテストし、その後で使用中のツールのドキュメントを確認してください。

長期間有効にする場合は、Bashの ~/.bashrc やZshの ~/.zshrc など、Shellの設定ファイルにエクスポートコマンドを書けます。より安全なのは切り替え用の関数を定義する方法です。LAN内のサービスへアクセスするときやネットワークを調査するときに、プロキシを切り忘れるのを防げます。

proxy_on() {
  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=localhost,127.0.0.1,::1
  export http_proxy="$HTTP_PROXY"
  export https_proxy="$HTTPS_PROXY"
  export all_proxy="$ALL_PROXY"
  export no_proxy="$NO_PROXY"
}

proxy_off() {
  unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY
  unset http_proxy https_proxy all_proxy no_proxy
}

sudo を実行すると、通常は環境変数が除外されます。そのため、一般ユーザーのターミナルでプロキシを有効にしていても、sudoで起動したプログラムが同じプロキシを使うとは限りません。手間を省くために環境変数をすべて広範囲で引き継ぐのではなく、パッケージマネージャーや個別のコマンドがサポートするプロキシ設定を使ってください。

コンテナも、ホストの 127.0.0.1 プロキシを自動的に引き継ぐわけではありません。コンテナ内のループバックアドレスはコンテナ自身を指し、ホストを指しません。コンテナからホストのプロキシへアクセスするには、Docker、Podman、ネットワークモードに応じて到達可能なホストアドレスを設定し、mihomoの待ち受けアドレス、LANアクセス設定、ファイアウォールルールを確認します。プロキシポートをLANへ公開する前に、アクセスを許可するネットワーク範囲も制限してください。

TUNモード：権限、ルーティング、DNSの連携

システムプロキシや環境変数が有効なのは、プロキシ設定を自ら読み取るアプリだけです。プロキシ設定に対応していないプログラムでは、mihomoがTUN仮想インターフェースを使って通信を引き受けられます。TUNモードはルーティングを変更し、より多くの接続を処理するため、通常のポートプロキシより導入が複雑です。

Linuxシステムにはまず /dev/net/tun が必要です。次のコマンドで確認できます。

ls -l /dev/net/tun

コンテナや制限された仮想環境では、このデバイスがマッピングされていない場合があります。デバイスが存在していても、mihomoを実行するアカウントにはネットワーク管理権限が必要です。systemdサービスには、必要に応じて権限設定を追加できます。

CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE

この2行はサービスファイルの [Service] セクションに記述します。変更後は systemctl daemon-reload を実行してサービスを再起動してください。通常のプロキシポートが1024より大きい場合、一般に CAP_NET_BIND_SERVICE は必要ありません。残すかどうかは、実際の待ち受けポートに応じて決めます。

TUNを設定する際は、自動ルート、自動出口インターフェース検出、DNSハイジャック、IPv6の動作を確認します。対応フィールドはmihomoのバージョンによって変わるため、現在のバージョンのドキュメントと起動ログを基準にしてください。導入後は、少なくとも次の項目を検証します。

  1. mihomo停止後に、システムのデフォルトルートとDNSが復元されるか。
  2. 現在のSSH接続が安定しているか、リモート管理用アドレスが誤ってプロキシへ送られていないか。
  3. LANのサブネット、ゲートウェイ、NAS、開発サービスが想定どおり直接接続されるか。
  4. IPv4とIPv6が一貫したポリシーで処理され、一方の通信だけがルールを回避していないか。
  5. スリープ復帰、ネットワーク切り替え、VPN接続後に、TUNルートの再構築が必要か。

トラブルシューティング：プロセス、ポート、設定、ルールを順に確認

Linuxの接続問題は、層ごとに切り分けるのが適しています。最初からノードを何度も変更したり、クライアントを再インストールしたりしないでください。まずプロセスの存在を確認し、次にポートの待ち受け、プロキシリクエスト、DNS、ルールのマッチングを確認します。

プロセスが起動直後に終了する

systemdを使っている場合は、まず systemctl status mihomo と journalctl -u mihomo -b を実行します。よくある原因は、YAMLのインデントエラー、現在のコアで未対応の設定フィールド、書き込みできない作業ディレクトリ、参照先のルールファイルが存在しないことです。mihomo -t -d /etc/mihomo を手動で実行すると、設定エラーの位置をより直接的に確認できます。

ポートが使用中になっている

7890ポートを待ち受けているプロセスを確認します。

ss -lntp | grep 7890

古いインスタンス、別のプロキシクライアント、重複起動したサービスなどが同じポートを使用している可能性があります。不要なインスタンスを停止するか、設定でポートを変更し、ターミナルのプロキシ変数も合わせて修正してください。片方だけを変更すると、プログラムが引き続き古いポートへ接続してしまいます。

ローカルでは使えるが、他のデバイスから接続できない

まず allow-lan、待ち受けアドレス、ホストのファイアウォールを確認します。127.0.0.1 のみで待ち受けている場合、サービスはローカルからの接続しか受け付けません。LANアクセスを許可した後も、ファイアウォールで送信元の範囲を制限し、制御インターフェースを信頼できないネットワークへ直接公開しないでください。external-controller を設定する場合は、ループバックアドレスにバインドし、アクセス認証情報を設定することをおすすめします。

ブラウザーは使えるのに、Gitやcurlが接続できない

これは通常、システムプロキシとターミナル環境が分離していることが原因です。env | grep -i proxy を実行して現在の変数を確認し、curlの --proxy オプションで比較テストを行います。Gitなどのツール自体に古いプロキシアドレスが保存されていないかも確認してください。Gitのグローバルプロキシ設定が、現在の環境変数を上書きする場合があります。

プロキシは接続済みだが、対象通信が誤ったポリシーを通る

一時的にログレベルを上げ、リクエストがどのルールとプロキシグループにマッチしたかを確認します。Clashのルールは上から順に評価されるため、前方の広範なルールが通信を先に捕捉することがあります。ドメインルール、IPルール、GEOIP、ルールセットの順序を確認し、リスト末尾に明確なフォールバックルールがあることを確認してください。ルールを変更したら、まず設定を検証してからグレースフルリロードまたはサービス再起動を行います。

コアと設定を更新する順序

コアの更新と設定の更新は分けて行います。まず現在動作しているバイナリと設定のコピーを保存し、どちらか一方だけを置き換えて検証してください。mihomoを更新した後は、バージョンコマンドと設定検証を実行し、既存のフィールドを引き続き解析できることを確認します。サブスクリプションを更新した場合は、プロキシグループの参照、ルールプロバイダー、ノード名を重点的に確認します。重要な条件を一度に1つだけ変更すると、障害発生時に切り戻しと原因特定が容易になります。

長時間稼働するサーバーでは、サービスの終了状態、ログ容量、設定の更新時刻を定期的に確認してください。サブスクリプションの自動更新は、コアの自動リロードを意味しません。ファイル変更後に、使用中のクライアントやスクリプトが設定の読み込みを実行するか確認します。読み込み中の設定ファイルを直接上書きする場合は、まず一時ファイルへ書き込み、構文検証を済ませてから正式ファイルへアトミックに置き換えると、書き込み途中の状態を読み込むリスクを減らせます。

導入完了後のチェックリスト

  • ダウンロードしたビルドが、uname -m で報告されたプロセッサアーキテクチャと一致しているか確認します。
  • 設定ディレクトリが実行アカウントの所有になっており、機密設定を他のローカルユーザーが読み取れないことを確認します。
  • フォアグラウンド起動の段階で、YAML、待ち受けポート、基本的なプロキシリクエストをテストします。
  • systemdサービスに、明確な作業ディレクトリ、実行アカウント、失敗時の再起動ポリシーが設定されているか確認します。
  • ターミナルのプロキシ変数がmihomoの実際のポートと一致し、ローカルアドレスとLANアドレスに適切な直接接続範囲が設定されているか確認します。
  • TUNを有効にする前に、デバイスノード、ネットワーク権限、SSHの管理経路、ルートの復旧方法を確認します。
  • サブスクリプション、ルール、コアのバージョンを変更した後は、項目ごとに検証し、複数の実行条件を同時に変更しないようにします。

デスクトップクライアント、mihomoコマンドライン、systemdは相互排他的な選択肢ではありません。個人用ワークステーションでは、GUIクライアントで日常的なノード管理を行いながら、ログ診断にコマンドラインを使えます。GUIのないサーバーでは、mihomoとsystemdによって安定した、監査しやすい運用を実現できます。導入方法を決めた後、アプリがシステムプロキシを読み取るかどうかに応じて環境変数またはTUNを選ぶと、全体の設定が整理しやすくなります。

Clashをダウンロード