Linux版Clashクライアントの導入：GUIとコマンドラインの設定手順

デスクトップクライアントとコマンドラインコアを選ぶ

LinuxでのClash導入には、主に2つの方法があります。デスクトップクライアントは、GNOME、KDE Plasma、XfceなどのGUI環境を備えたワークステーションに適しています。画面上でサブスクリプションを追加し、プロキシグループを切り替え、接続履歴を確認できるほか、トレイメニューからシステムプロキシを操作できます。mihomoコマンドラインコアは、サーバー、ソフトウェアルーター、開発コンテナのホスト、またはsystemdでプロセスを一元管理したい環境に向いています。

mihomoはClashの設定体系に対応しながら機能を拡張しているコアです。一般的なClashのルール、プロキシグループ、プロキシノード、DNS、TUN設定はコアが処理し、デスクトップクライアントはその上に設定管理用の画面を提供します。両者を必ず別々のプロキシ層として同時に動かす必要はありません。多くのデスクトップクライアントはコアを内蔵または管理しているため、さらにシステム全体でmihomoを起動すると、ポートの使用競合、コントロールポートの衝突、システムプロキシの切り替え競合が起きやすくなります。

Linuxデスクトップクライアントをインストールする

ダウンロード前にプロセッサーのアーキテクチャを確認します。ターミナルで uname -m を実行すると、一般的には x86_64、aarch64、arm64 などが表示されます。インストーラーのamd64やx64は通常x86_64に、arm64は64ビットARMに対応します。アーキテクチャが合わない場合、クライアント画面が開く前に「バイナリファイルを実行できない」といったエラーが表示されます。

デスクトップディストリビューションでよく使われる形式は、AppImage、DEB、RPMです。クライアントを選ぶ際は、現在も保守されているか、対応コアの種類、設定の保存場所、LinuxのシステムプロキシやTUNを管理できるかを優先して確認しましょう。サブスクリプションのオーバーライド、コアの更新、権限昇格の実装はクライアントごとに異なるため、移行時に画面項目が完全に一致すると決めつけないでください。

AppImageの実行方法

AppImageは従来のパッケージインストール手順を必要としません。現在のアーキテクチャに合うファイルをダウンロードしたら、実行権限を付与してターミナルから起動します。以下のコマンドでは、ファイル名を実際にダウンロードした名前へ置き換えてください。

mkdir -p "$HOME/Applications"
mv "$HOME/Downloads/クライアントファイル.AppImage" "$HOME/Applications/"
chmod +x "$HOME/Applications/クライアントファイル.AppImage"
"$HOME/Applications/クライアントファイル.AppImage"

ダブルクリックしても反応しない場合は、ターミナルから一度起動し、エラー出力を確認します。ディストリビューションによってはFUSE互換コンポーネントが必要です。一部の新しいAppImageは、対応する自己解凍モードで直接実行できる場合もあります。「アイコンが表示されない」だけでインストール失敗と判断しないでください。ウィンドウシステム、トレイ拡張、デスクトップエントリーのキャッシュも表示に影響します。

DEBとRPMのインストール方法

Debian、Ubuntuおよび派生システムでは、APTを使ってローカルのDEBパッケージをインストールできます。APTはパッケージが宣言する依存関係も同時に処理します。

cd "$HOME/Downloads"
sudo apt install ./クライアントファイル.deb

Fedora、Rocky LinuxなどRPMパッケージを使うシステムでは、DNFでローカルファイルをインストールできます。

cd "$HOME/Downloads"
sudo dnf install ./クライアントファイル.rpm

インストール後、アプリケーションメニューからクライアントを起動します。初回起動時は、まずコアが動作しているか確認してから、サブスクリプションまたはローカルのYAML設定を追加してください。クライアントに「システムプロキシとして設定する」項目がある場合、通常は現在のデスクトップセッションのプロキシ設定だけを変更します。すべてのプロセスを透過的にプロキシ経由にする機能とは異なります。ターミナル、コンテナ、システムサービスとして動くソフトウェアがデスクトッププロキシを参照するかは、個別に確認が必要です。

mihomoコマンドラインコアを導入する

コマンドラインで導入する際の基本要素は、実行ファイル、作業ディレクトリ、設定ファイルの3つです。実行ファイルは /usr/local/bin/mihomo に、システム全体の設定は /etc/mihomo/ に置くことをおすすめします。これにより、プログラムの更新と設定の保守を分離でき、systemdから固定パスで起動しやすくなります。

信頼できる配布元から、アーキテクチャに合ったアーカイブを入手します。解凍後、バイナリファイルの名前を mihomo に変更してください。ファイルが現在のディレクトリに解凍済みだとすると、次のコマンドを実行できます。

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

mihomo -v では、コアのバージョンとビルド情報が表示されます。Exec format error が出る場合は、通常、アーキテクチャの異なるファイルをダウンロードしています。実行権限がないと表示された場合は、ファイルのモードと、配置先のファイルシステムに noexec マウントオプションが付いていないか確認してください。

初回導入では、複雑なDNS、スクリプト、TUNルールをいきなり追加しないでください。まず、解析可能な基本設定でポートとノードが利用できることを確認し、その後に高度な設定を1項目ずつ追加します。mihomoでは -d で作業ディレクトリを指定でき、そのディレクトリ内の config.yaml がデフォルト設定として読み込まれます。

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

フォアグラウンドでの起動は、初回確認に適しています。ターミナルには設定の解析、リッスンポート、プロキシ接続、ルールのマッチ状況が継続的に表示されます。設定で起動できることを確認してから、後述の手順でsystemdサービスを作成してください。サービスの再起動を繰り返すことで、最初のエラーが隠れるのを防げます。

設定ディレクトリ、サブスクリプションファイル、基本ポート

最小構成のディレクトリには /etc/mihomo/config.yaml だけを置きます。GeoIP、ルールセット、その他の外部リソースを有効にすると、作業ディレクトリにデータベース、キャッシュ、ダウンロードファイルが追加されることがあります。サービス実行ユーザーには設定を読み取る権限と、キャッシュを更新する場所への書き込み権限が必要です。サブスクリプションの認証情報やコントロールインターフェースのキーを設定に含める場合は、ディレクトリとファイルの権限を制限してください。

sudo install -m 0640 config.yaml /etc/mihomo/config.yaml
sudo chmod 0750 /etc/mihomo
sudo ls -la /etc/mihomo

ローカルテスト用の基本設定には、混合プロキシポート、LANアクセスの許可、動作モード、コントロールインターフェースを含められます。以下は構成例のみを示したもので、プロキシノードとルールには実際に利用できるClashまたはMihomo設定を使用してください。

mixed-port: 7890
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: true

external-controller: 127.0.0.1:9090
secret: "ランダムで十分に長いコントロールキーを設定してください"

proxies: []
proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,PROXY

mixed-port はHTTPとSOCKS5接続の両方を受け付けるため、ブラウザー、ターミナルツール、開発ソフトで1つのポートを共有できます。allow-lan: false は、まずローカルホストだけの利用に制限する設定です。bind-address にワイルドカードアドレスを指定していても、LANアクセスを許可していなければ、共有設定が完了しているとは考えないでください。

external-controller はコントロールインターフェースであり、通常のプロキシポートではありません。ローカルだけで管理する場合は 127.0.0.1 にバインドし、コントロールキーを設定します。リモート管理が本当に必要な場合も、ファイアウォール、信頼できるネットワーク範囲、アクセス認証を同時に計画してください。コントロールポートを信頼できないネットワークへ直接公開してはいけません。

サブスクリプションの取り込み時はバックアップを残す

GUIクライアントは通常、サブスクリプションURL、更新間隔、ローカル設定のコピーを自動的に管理します。コマンドラインで運用する場合は、更新担当を明確にする必要があります。管理対象のスクリプトで設定を取得し、まず一時ファイルへ保存してから、コアで設定を検証し、使用中のファイルを置き換える方法が安全です。ダウンロードに失敗したとき、既存の config.yaml を直接上書きしないでください。空の応答や認証切れだけで、次回の再起動に失敗するおそれがあります。

サブスクリプションURLには通常、アクセス認証情報が含まれるため、他のユーザーから読めるシェル履歴、サービスログ、公開スクリプトへ直接書き込むのは避けてください。認証情報を権限で保護した環境ファイルに保存し、更新タスクだけがそのファイルを読み取る方法が安全です。更新結果へのアクセス権も制限します。配布元がClash YAMLではなく汎用ノード一覧を出力する場合は、互換形式へ変換してから使用する必要があります。任意のテキストをそのままmihomo設定として起動することはできません。

systemdサービスと自動起動を設定する

基本設定の検証が終わったら、/etc/systemd/system/mihomo.service を作成します。以下のサービスユニットはシステムレベルのプロセスとして動作し、TUN機能を使う場合に備えてネットワーク管理権限を残しています。HTTPまたはSOCKSポートだけを使う場合は、必要な設定を確認したうえで権限範囲を狭めてください。

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

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
LimitNOFILE=1048576
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

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

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

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

sudo journalctl -u mihomo -b --no-pager
sudo journalctl -u mihomo -f

Restart=on-failure は異常終了時だけ再起動するため、設定解析や実行時のエラーを見つけるのに適しています。サービスが再起動を繰り返す場合は、まず systemctl stop mihomo を実行し、同じ設定ディレクトリを指定してフォアグラウンドで起動し、最初のエラーを特定します。よくある原因は、YAMLのインデントミス、リッスンポートの使用中、ルールが参照するプロキシグループの不足、設定ディレクトリの権限不足、TUNデバイスやネットワーク権限の不足です。

デスクトップのシステムプロキシ、ターミナル、TUNモードを接続する

コアが動作しているだけで、すべての通信が自動的にプロキシを通るわけではありません。mixed-port: 7890 だけを設定した場合、アプリケーション側がそのポートへ接続する必要があります。デスクトップ環境では、HTTP、HTTPS、SOCKSプロキシを 127.0.0.1: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"

socks5h は、ドメイン名の解決もSOCKSプロキシ側に任せる指定です。ただし、対応状況はアプリケーションによって異なります。環境変数は現在のシェルと、その子プロセスにだけ適用されます。sudo、systemdサービス、コンテナ、GUIランチャーを使う場合は変数が引き継がれないことがあるため、それぞれの実行環境で個別に設定してください。

TUNモードの役割と前提条件

TUNモードは仮想ネットワークインターフェースを通じて、手動でプロキシを設定できない通信も取り込む機能です。デスクトップアプリ、コマンドラインツール、一部のゲーム接続をまとめて処理したい場合に適しています。Linuxの /dev/net/tun デバイス、ルーティングルール、適切なネットワーク管理権限が必要です。コンテナ、最小構成のカーネル、制限された仮想マシンではTUNデバイスが利用できないことがあり、設定構文が正しくてもインターフェースを作成できません。

一般的な設定では、既存のDNS構成が利用できることを確認してから有効化します。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-redirect: true
  auto-detect-interface: true

auto-route はルートを自動設定し、auto-detect-interface はデフォルトの出口インターフェースを検出します。auto-redirect の対応状況や動作結果は、Linuxのネットワーク環境、カーネル機能、mihomoのバージョンによって異なります。Docker、Podman、VPN、NetworkManagerのカスタムルート、複数のNICを同時に使用している場合は、ルートの優先順位とファイアウォールルールを確認してください。コンテナネットワーク、内部アドレス、プロキシサーバー自身への接続が誤って再びTUNへ送られるのを防ぎます。

TUNを有効にしてドメインを解決できなくなった場合、ノードを何度も切り替えるだけでは解決しません。DNSのリッスン状態、上流DNSへの到達性、ルール内のDNSポリシー、仮想インターフェースのルート、システムが別のローカル名前解決サービスへ問い合わせ続けていないかを分けて確認します。DNSとTUNを同時に大きく変更すると切り分けが難しくなるため、まずプロキシポート、次にDNS、最後にTUNの順で検証してください。

起動確認とよくあるトラブルの切り分け

導入後は、Webページが開くかどうかを最初の判断材料にせず、プロセスから外側へ順に確認します。まずサービスの稼働、次にポートのリッスン状態、続いて明示的なプロキシ経由のリクエスト、さらにルールのマッチ状況とノード接続ログを確認し、最後にシステムプロキシやTUNを有効にします。

systemctl is-active mihomo
ss -lntup | grep -E '7890|9090'
curl --proxy http://127.0.0.1:7890 https://example.com/
journalctl -u mihomo -n 100 --no-pager

7890がリッスンしていない場合は、まず設定解析とポート競合を確認します。ss -lntup でポートを使用しているプロセスを探せます。ポートが存在するのにリクエストが失敗する場合は、ログでDNS失敗、接続タイムアウト、認証エラー、利用可能なプロキシがない状態のどれかを確認します。プロキシグループにノードが表示されていても、実際に接続できるとは限りません。最終的には接続ログと実際のリクエスト結果を基準に判断してください。

デスクトップクライアントは起動するが通信をプロキシできない

• クライアントのウィンドウが開いているだけでなく、内部のコアが動作しているか確認します。
• 現在の設定が有効になっており、プロキシグループが無効または利用できないノードを指していないことを確認します。
• デスクトップのシステムプロキシが正常に設定されているか、対象アプリケーションがシステムプロキシに従うかを確認します。
• TUNを使用している場合は、権限昇格が完了していること、仮想インターフェースが存在すること、他のVPNによってルートが上書きされていないことを確認します。
• 複数のプログラムが同時にプロキシやルートを変更しないよう、他のプロキシクライアントを終了します。

サービス起動直後に終了する

journalctl -u mihomo -b で今回の起動ログを読み込み、最初に現れたエラーを重点的に確認します。YAMLはスペースでインデントします。Tab文字、階層のずれ、特殊文字の引用ミスはいずれも解析失敗の原因になります。ルールが存在しないプロキシグループを参照している場合も、コアが設定の読み込みを拒否することがあります。修正後はまずターミナルでフォアグラウンド実行し、エラーがないことを確認してからsystemdサービスを再起動してください。

LAN上のデバイスから接続できない

プロキシを共有するには、4つの条件をすべて満たす必要があります。設定でLANアクセスを許可すること、サービスがLANから到達できるアドレスでリッスンすること、ホストのファイアウォールで該当するTCPまたはUDPポートを許可すること、クライアントにLinuxホストのLANアドレスを入力し 127.0.0.1 を指定しないことです。無線ネットワークでクライアント分離が有効になっていないかも確認してください。ポートを開放する前に信頼できるネットワーク範囲へ限定し、プロキシポートをインターネット側のインターフェースへ公開しないようにします。

Linux導入後のメンテナンス項目

1. 現在のコアの入手元、バージョン、アーキテクチャ、実行ファイルのパスを記録します。
2. 設定ディレクトリの権限を制限し、サブスクリプションの認証情報とコントロールキーを安全に保管します。
3. 予定しているプロキシ、DNS、コントロールポートを使用するインスタンスが1つだけであることを確認します。
4. 設定更新用の一時ファイルとバックアップを残し、検証に成功してから置き換えます。
5. 更新前に設定互換性の変更点を確認し、更新後は起動ログとルールのマッチ状況を確認します。
6. TUNを使用する場合は、追加されたルート、ファイアウォールルール、VPNやコンテナネットワークとの関係を記録します。
7. デスクトップクライアントを使わなくなったら、システムプロキシ設定も復元し、使われていないポートを残さないようにします。

デスクトップクライアントでは、現在のディストリビューションに対応し、保守が続いているGUIを選び、システムプロキシとTUNの違いを理解することが重要です。コマンドラインでの導入では、固定ディレクトリを使い、設定を先に検証してからsystemdに管理させます。「バイナリ—設定解析—ポートのリッスン—明示的なプロキシ—システム全体への適用」の順で確認すれば、Linuxの導入トラブルの多くを原因の明確な段階まで絞り込めます。