はじめに 読了目安 14分

Clash Linux版のインストール方法：デスクトップクライアントとCLIコアの2つの導入ルート

LinuxでClashを使う方法は、GUI付きデスクトップクライアントと、コアをsystemdサービスとして動かすCLI構成の2通り。ディストリビューション別に、インストール手順、設定ファイルの場所、自動起動を解説し、それぞれに適した用途も紹介します。

まず選ぶ：デスクトップクライアントかMihomo CLIコアか

Linuxには、あらゆる用途に適した唯一のインストール方法があるわけではありません。Ubuntu、Fedora、Linux Mint、Archのデスクトップを日常的に使うなら、サブスクリプション管理、プロキシグループの切り替え、ログ確認、システムプロキシのオン・オフが重要です。一方、サーバー、ソフトルーターの中継環境、ディスプレイのないホストでは、リソース使用量、リモート管理、自動起動が重視されます。この2つのニーズに対応するのが、デスクトップクライアントとCLIコアの2つのルートです。

比較項目 デスクトップクライアント Mihomo CLIコア
適した環境 Ubuntu、Fedora、Mint、Archのデスクトップ サーバー、開発マシン、NAS、GUIのないホスト
サブスクリプションの追加 GUIにURLを貼り付けて更新 config.yamlを用意して手動または定期的に更新
プロキシグループの切り替え プロキシグループやノードをクリックして切り替え 外部コントローラーAPIまたはWebパネルで操作
バックグラウンド実行 デスクトップへのログイン後に自動起動 systemdがシステム起動時に起動
一般的なメモリ使用量 GUIとコアの合計で、おおむね140～320 MB 通常のルール設定で、おおむね35～110 MB
TUNの権限 通常はサービスモードまたは権限付与コンポーネントが処理 CAP_NET_ADMINなどの権限が必要

インストール前にCPUアーキテクチャを確認

アーキテクチャの異なるパッケージをダウンロードすると、「バイナリファイルを実行できません」やExec format errorが表示されます。まずターミナルで次のコマンドを実行します。

uname -m
cat /etc/os-release

ディストリビューション情報によってパッケージ形式を選びます。Ubuntu、Debian、Linux Mintでは.deb、FedoraやRHEL系では.rpmを優先します。その他のデスクトップ環境ではAppImageも利用できます。サーバーにコアを導入する場合は、アーキテクチャに合った実行ファイルを直接使用します。

ルート1：Linuxデスクトップクライアントをインストール

デスクトップ環境では、Mihomoコアを内蔵し、現在も保守されていてLinuxビルドを提供しているクライアントがおすすめです。パッケージ名にはamd64、x86_64、arm64、aarch64などの表記が付くことがあります。先ほどのuname -mの結果に合わせて選んでください。macOS用のClashXパッケージをLinuxへコピーしてはいけません。両者は実行形式もシステムインターフェースも互換性がありません。

Ubuntu、Debian、Linux MintにDEBをインストール

パッケージが「ダウンロード」ディレクトリに保存されているとします。まずそのディレクトリへ移動し、APTでローカルパッケージをインストールします。dpkg -iだけを実行するのではなくAPTを使うと、パッケージが宣言する依存関係も同時に処理できます。

cd ~/下载
sudo apt install ./Clash-Linux-amd64.deb

英語環境のディレクトリ名は通常cd ~/Downloadsです。ファイル名は、実際にダウンロードした完全な名前に置き換えてください。先頭数文字を入力してTabを押すと自動補完できます。インストール後はアプリケーションメニューから起動できます。また、dpkg -l | grep -i clashでパッケージが登録されているか確認できます。

Fedora、RHEL系ディストリビューションにRPMをインストール

cd ~/Downloads
sudo dnf install ./Clash-Linux-x86_64.rpm

dnf installはRPMの依存関係情報を読み取ります。デスクトップのセキュリティポリシーが厳しく設定されている場合、初めてTUNやサービスモードを有効にすると管理者権限の確認画面が表示されることがあります。これは仮想ネットワークインターフェースの作成やルーティング変更に必要な手順なので、繰り返しキャンセルしないでください。

AppImageの実行と配置

AppImageはディストリビューションのパッケージデータベースに登録する必要がありませんが、実行権限が必要です。ここではダウンロードディレクトリ内のファイルを例にします。

cd ~/Downloads
chmod +x Clash-Linux-x86_64.AppImage
./Clash-Linux-x86_64.AppImage

FUSE関連のエラーが表示された場合は、使用中のディストリビューションのリポジトリから互換性のあるFUSE実行コンポーネントをインストールしてください。また、--appimage-extract-and-runで起動できるか先に確認することもできます。長期利用では、AppImageを~/Applicationsへ移すと、ダウンロードディレクトリの整理時に誤って削除するのを防げます。

サブスクリプションを追加して初回接続を完了

  1. クライアントの「サブスクリプション」ページを開き、「新規作成」または「URLからインポート」を選びます。クライアントによっては「サブスクリプション」→「新規作成」→「URL」という手順です。
  2. サービス提供元から案内されたサブスクリプションURLを貼り付け、確認後に一度更新します。
  3. 「プロキシ」または「プロキシグループ」ページを開き、メインのグループからノードを選択します。URLテスト用のグループを選ぶこともできます。
  4. 「システムプロキシ」を有効にしてから、テストページへアクセスするか、コマンドで外部IPアドレスを確認します。
  5. システムプロキシを読み取らないアプリケーションの通信も取り込みたい場合は、その段階でTUNモードを設定します。初回起動時にネットワーク設定をすべて変更する必要はありません。
curl -I --proxy http://127.0.0.1:7890 https://example.com
curl -I --proxy socks5h://127.0.0.1:7890 https://example.com

1つ目のコマンドはHTTPプロキシ、2つ目はSOCKS5を使い、ドメイン解決をプロキシ側に任せます。ポートはクライアントの実際の設定に合わせてください。一般的な混合ポートは7890ですが、HTTPとSOCKSを7890と7891に分ける設定もあります。確認場所は通常「設定」→「パラメータ設定」→「ポート設定」です。

ルート2：Mihomo CLIコアをインストール

MihomoはClashの設定体系を受け継ぐオープンソースのコアで、ルールベースの振り分け、プロキシグループ、ルールセット、DNS、TUNに対応しています。CLI構成にはサブスクリプション一覧やトレイメニューはありません。実行ファイルを用意し、config.yamlを配置して、systemdに管理させるのが基本です。

バイナリと専用アカウントを用意

以下では、ダウンロードして解凍済みのmihomo-linux-amd64-v1.19.12を例にします。バージョン番号はファイル名の形式を示すためのものです。実際の導入では、ダウンロードページにある現行バージョンと正しいアーキテクチャを選んでください。

sudo install -Dm755 mihomo-linux-amd64-v1.19.12 /usr/local/bin/mihomo
sudo useradd --system --home-dir /var/lib/mihomo --create-home --shell /usr/sbin/nologin mihomo
sudo install -d -o mihomo -g mihomo -m 750 /var/lib/mihomo
/usr/local/bin/mihomo -v

ディストリビューションに/usr/sbin/nologinがない場合は、command -v nologinで実際のパスを確認してください。専用のシステムアカウントを使うと、実行ディレクトリを一般ユーザーのホームディレクトリから分離でき、systemdでネットワーク権限を正確に付与できます。

最小限の起動可能な設定を用意

変換またはエクスポートした完全なClash/Mihomo設定を/var/lib/mihomo/config.yamlとして保存します。以下の断片はポート、コントローラー、DNS、ルールの基本構成を示すものですが、プロキシノードは含まれていません。コアの起動と直接接続の確認にのみ使用できます。

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

external-controller: 127.0.0.1:9090
secret: "change-this-controller-secret"

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

proxies: []

rules:
  - MATCH,DIRECT

mixed-port: 7890はHTTPとSOCKSの両方の接続を受け付けます。external-controllerは制御用インターフェースであり、プロキシポートではありません。制御インターフェースは127.0.0.1だけで待ち受けさせ、LANへ直接公開しないようにします。実際の設定では独自の強力なsecretを設定し、リモート管理にはSSHポートフォワーディングを優先してください。

設定をコピーしたら所有者を修正し、構文テストを実行します。YAMLはインデントに敏感です。リスト項目は通常、親要素より半角スペース2つ分深くします。Tab文字はインデントに適していません。

sudo chown mihomo:mihomo /var/lib/mihomo/config.yaml
sudo chmod 640 /var/lib/mihomo/config.yaml
sudo -u mihomo /usr/local/bin/mihomo -t -d /var/lib/mihomo

テストに成功すると設定の解析が完了します。yaml、mapping、unmarshalのエラーが出た場合は、表示された行の周辺でインデント、コロン、フィールドの型を確認してください。サブスクリプションがHTMLページ、ログイン画面、Base64形式のノード一覧を返す場合、それを完全なconfig.yamlとして直接使用することもできません。

systemdでバックグラウンド実行と自動起動を設定

SSHセッションでMihomoを直接実行すると、ターミナルを閉じたときにプロセスが終了することがあります。systemdを使えば、起動順序、異常終了時の再起動、ログ確認、自動起動を一元管理できます。/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=/var/lib/mihomo
ExecStartPre=/usr/local/bin/mihomo -t -d /var/lib/mihomo
ExecStart=/usr/local/bin/mihomo -d /var/lib/mihomo
Restart=on-failure
RestartSec=5
LimitNOFILE=1048576
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/mihomo

[Install]
WantedBy=multi-user.target

ExecStartPreは起動のたびに設定をテストするため、誤った設定で現在稼働中のプロセスが置き換わることはありません。Restart=on-failureは異常終了時だけ再起動し、間隔は5秒です。CAP_NET_ADMINとCAP_NET_RAWはTUNなどのネットワーク操作に使用します。ローカルのHTTP/SOCKSポートだけを公開しTUNを使わない場合は、2行のcapability設定を削除して権限範囲をさらに絞れます。

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
systemctl status mihomo --no-pager
journalctl -u mihomo -n 80 --no-pager

active (running)と表示されればサービスは稼働中です。YAMLを変更したら、先にテストコマンドを実行してからsudo systemctl restart mihomoを実行します。ログを継続して確認するにはjournalctl -u mihomo -fを使います。Ctrl+Cを押してもログ表示が終了するだけで、サービスは停止しません。

ポートが実際に待ち受けているか確認

ss -lntp | grep -E '7890|9090'
curl -I --proxy http://127.0.0.1:7890 https://example.com

systemdが稼働中と表示されているのに7890が待ち受けていない場合は、設定で別のポートに変更されていないか、ルールセットの読み込み失敗でプロセスが終了していないかを確認します。ポートが開いているのにリクエストがタイムアウトする場合は、プロキシグループの選択、ノードの接続性、DNSログ、サーバーのファイアウォールを確認してください。バイナリを何度も再インストールする必要はありません。

TUN、システムプロキシ、ターミナルの環境変数を使い分ける

デスクトップでの日常利用：まずシステムプロキシ

システムプロキシは変更範囲が小さく、ブラウザー、デスクトップチャットツール、GNOMEやKDEのプロキシ設定に従うアプリに適しています。クライアントの一般的な操作手順は「設定」→「システムプロキシ」→「有効化」です。普段のWeb閲覧や開発ドキュメントの確認だけなら、まずシステムプロキシを使うほうが問題を切り分けやすくなります。

ターミナルツール：プロセス単位でプロキシ変数を設定

多くのCLIプログラムはHTTP_PROXY、HTTPS_PROXY、ALL_PROXYを読み取ります。一時的な設定は現在のターミナルセッションだけに適用され、ターミナルを閉じると無効になります。

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

curl -I https://example.com

直接接続に戻すには次を実行します。

unset HTTP_PROXY HTTPS_PROXY ALL_PROXY
unset http_proxy https_proxy all_proxy

Gitも個別に設定できるため、すべてのターミナルプログラムへ恒久的な影響を与える必要はありません。

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

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

コンテナ、ゲーム、プロキシ設定を読み取らないプログラム：次にTUNを検討

TUNモードは仮想ネットワークインターフェースを作成し、ルーティングによってより多くの通信をMihomoへ送ります。HTTP/SOCKSプロキシに対応していないプログラムもカバーできますが、DNS、ルートの優先順位、LANアクセス、権限に関する問題が増えます。サーバーでリモート設定する前に2つ目のSSHセッションを確保し、誤ったルーティングで現在の管理接続が切れないようにしてください。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-redirect: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

auto-detect-interfaceはデフォルトの出口インターフェースを識別します。auto-routeは通信を取り込むルートを追加し、dns-hijackは指定したDNS通信をコアに処理させます。対応項目はコアのバージョンやOSのネットワークスタックによって異なるため、有効化する前にmihomo -tを実行してください。Docker、Podman、仮想マシンのブリッジ、ポリシールーティング環境では、コンテナ用ネットワークが誤ってプロキシへ送られないよう、除外するネットワークも確認します。

設定ファイル、サブスクリプション更新、ログの管理

デスクトップクライアントの設定場所

デスクトップクライアントは通常、/etcではなくユーザーデータディレクトリに設定を保存します。Linuxでよくある場所は~/.config/アプリケーションディレクトリ、~/.local/share/アプリケーションディレクトリです。Flatpakアプリは~/.var/app/アプリケーションIDに保存されることが多くあります。クライアントの実行中にディレクトリ全体を直接上書きせず、画面上のインポート、更新、バックアップ機能を優先してください。

最近変更されたYAMLファイルを探すには、次を実行します。

find ~/.config ~/.local/share -type f \
  \( -name '*.yaml' -o -name '*.yml' \) \
  -mtime -7 2>/dev/null

CLI構成でのサブスクリプション更新

CLIコアはサブスクリプションの形式を自動判定してくれません。安全な手順は、新しい設定を一時ファイルへダウンロードし、構文テストに成功してから正式な設定を置き換えて再起動することです。使用中のファイルを直接上書きすると、不完全なダウンロード1回でサービスが再起動できなくなるおそれがあります。

  1. 新しい内容を一時YAMLファイルとして保存します。
  2. レスポンスがHTMLのエラーページではなく、Clash/Mihomo設定であることを確認します。
  3. 独立した一時ディレクトリでmihomo -tを実行します。
  4. テストに成功したら/var/lib/mihomo/config.yamlへ移動します。
  5. ファイルの所有者を修正し、systemdサービスを再起動します。

設定でproxy-providersを使用している場合、Mihomoは設定内のintervalに従ってproviderを定期的に更新できます。一般的なinterval: 86400は86400秒、つまり24時間ごとの更新を意味します。一方、ヘルスチェックのinterval: 300は5分ごとの確認を意味し、用途が異なります。「更新を速くする」ために両方へ小さな値を設定するのは避けてください。

ログレベルとディスク使用量

通常の運用ではlog-level: infoを推奨します。DNS、ルールマッチング、接続失敗を調査するときだけ一時的にdebugへ切り替え、確認後に戻してください。systemdのログはjournaldが管理します。サービスの使用量は次のコマンドで確認できます。

journalctl --disk-usage
journalctl -u mihomo --since "30 minutes ago"
journalctl -u mihomo -p warning --since today

ログのconnection refusedは通常、接続先アドレスには到達できるものの、そのポートでサービスが待ち受けていないことを示します。i/o timeoutはネットワーク経路またはノードの応答タイムアウトに近い状態です。no such hostやDNS resolve failedが出た場合は、まずDNSの上流、DNSハイジャック設定、IPv6の利用可否を確認します。エラーがローカルの待ち受け、DNS、ノード接続、接続先サイトのどこで発生しているかを切り分けるほうが、ノードを何度も切り替えるより効果的です。

よくあるインストール問題と確認の順番

起動時にExec format errorが表示される

ほぼ確実にアーキテクチャの不一致です。もう一度uname -mを実行し、file /usr/local/bin/mihomoでバイナリの対象アーキテクチャを確認します。x86_64ホストにはamd64ビルド、aarch64ホストにはarm64ビルドを使用してください。

デスクトップクライアントは開くが、システムプロキシが機能しない

systemdが繰り返し再起動する

systemctl status mihomo --no-pager
journalctl -u mihomo -b -n 120 --no-pager
sudo -u mihomo /usr/local/bin/mihomo -t -d /var/lib/mihomo

よくある原因は、YAMLのインデントミス、ポートの競合、実行アカウントに設定ファイルの読み取り権限がないこと、Geoデータのダウンロード失敗、TUN権限の不足です。ポート競合はsudo ss -lntpで確認できます。権限の問題は、namei -l /var/lib/mihomo/config.yamlの出力から各階層のディレクトリ権限を確認してください。

LAN内のデバイスからLinuxホストのプロキシへ接続できない

デフォルトのallow-lan: falseではローカルホストからの利用だけが許可されます。信頼できるLAN内デバイスへプロキシを提供する場合はallow-lan: trueに変更し、明示的なbind-addressを設定したうえで、ホストのファイアウォールではLANのネットワーク範囲からプロキシポートへのアクセスだけを許可してください。外部コントローラーの9090は、プロキシポートを開放するからといって同時に公開してはいけません。

Clash をダウンロード