Linux で Clash を構築:デスクトップクライアント導入と mihomo コマンドライン設定
Linux デスクトップに Clash クライアントを導入する方法と、mihomo コアをコマンドラインで動かして自動起動まで設定する手順を解説します。
まずルート選び:GUI かコマンドラインか
Linux で Clash を動かすには2つのルートがあります。1つはデスクトップクライアントで、Clash Verge Rev や FlClash のような GUI アプリを使う方法です。サブスクリプション導入、ノード切り替え、レイテンシテスト、ルール確認をすべてウィンドウ内で行えるため、日常的にデスクトップを使う環境に向いています。もう1つは mihomo コアとコマンドラインを使う方法です。mihomo は Clash Meta コアの後継で、オープンソース・無料、プロキシコアのみを持ちGUI はなく、すべての設定を1つの YAML ファイルにまとめます。サーバー、NAS、ルーターなどに向いていて、デスクトップでもプロキシをシステムサービスのように常駐させたいユーザーに適しています。
この2つのルートは併用できます。同じマシンで自宅では GUI クライアントを操作し、外出先では systemd が mihomo を起動してサービスを継続する、という運用も可能です。以下の表を参考に、どちらを選ぶか先に決めてから作業に入りましょう。
| 比較項目 | デスクトップクライアント | mihomo コマンドライン |
|---|---|---|
| 適した環境 | GNOME / KDE などのデスクトップ | サーバー、端末、常駐サービス |
| 設定方法 | GUI 操作 + サブスクリプションリンク | config.yaml を手動編集 |
| 自動起動 | クライアント内蔵のスイッチ | systemd ユニットで管理 |
| リソース消費 | コア + GUI プロセス | コアプロセスのみ |
| 管理パネル | 専用 GUI パネル付属 | metacubexd などの Web パネルを外部接続 |
デスクトップクライアントの導入
本サイトのダウンロードセンターにある Linux 版から、ディストリビューションのパッケージ形式を選んでください。Debian、Ubuntu、Deepin 系は .deb パッケージ、Fedora、openSUSE 系は .rpm パッケージを使用します。システムに導入したくない場合は AppImage の単一ファイル版が便利です。Clash Verge Rev は deb と rpm の両方を、FlClash は deb を提供しており、いずれも mihomo コアを内蔵しているためインストール後すぐに使えます。
# Debian / Ubuntu 系
sudo dpkg -i clash-verge_*_amd64.deb
sudo apt -f install # 依存関係が不足している場合に補完インストール
# Fedora / openSUSE 系
sudo dnf install ./clash-verge-*-1.x86_64.rpm
AppImage は FUSE ランタイムに依存しており、Ubuntu 22.04 以降は標準搭載されていないため、事前に libfuse2(24.04 では libfuse2t64)を追加インストールする必要があります。Fedora では fuse-libs が対応パッケージです。あとはファイルに実行権限を付与すればそのまま起動できます。
sudo apt install libfuse2
chmod +x FlClash-*-amd64.AppImage
./FlClash-*-amd64.AppImage
注意点は2つあります。1つはアーキテクチャの選択で、通常の PC は amd64(x86_64)、Raspberry Pi や ARM ノートは arm64 を選びます。誤ると起動しません。もう1つは、初回起動後にサブスクリプションページで契約している業者から提供された Clash サブスクリプションリンクを貼り付けて更新し、ノード一覧を取得してから、プロキシページでノードを選び、設定でシステムプロキシのスイッチを有効にする点です。全体を丸ごとプロキシ経由にしたい場合は TUN モードを有効にします。クライアントがコアの権限昇格を求めるダイアログを表示するので、一度承認すればすべてのアプリの通信が個別設定なしでプロキシを経由するようになります。
mihomo コマンドラインでの構築
コマンドラインでの構築は3段階です。コアのインストール、設定の準備、手動での動作確認を経てから systemd に管理を任せます。
ステップ1:コアのインストール
本サイトのダウンロードセンター、または mihomo の GitHub Releases から Linux 版のアーカイブを取得します。ファイル名は mihomo-linux-amd64-v1.18.9.gz のような形式で、実際のバージョンに合わせてください。古い CPU で x86-64-v3 命令セットに対応していない場合は、ファイル名に compatible が付くバージョンを使用します。解凍後、システムの PATH に配置します。
gunzip mihomo-linux-amd64-v1.18.9.gz
chmod +x mihomo-linux-amd64-v1.18.9
sudo mv mihomo-linux-amd64-v1.18.9 /usr/local/bin/mihomo
mihomo -v # バージョン番号が表示されればインストール成功
ステップ2:設定ディレクトリの準備
sudo mkdir -p /etc/mihomo
sudo curl -L -o /etc/mihomo/config.yaml "契約中のClashサブスクリプションリンク"
多くの業者は Clash 用のサブスクリプションアドレスを直接提供しており、取得すればそのまま使える config.yaml になります。汎用サブスクリプションしか提供されていない場合は、一度デスクトップクライアントに導入してからエクスポートするか、サブスクリプション変換サービスで Clash 形式に変換してください。GeoIP や GeoSite のデータファイル(geoip.metadb、geosite.dat など)は初回起動時に設定ディレクトリへ自動ダウンロードされます。ネットワーク事情で取得できない場合は、クライアント側の端末から同名ファイルをコピーしてくることもできます。
config.yaml のうち、日常運用に最も関わる3つの項目を確認しましょう。
mixed-port: 7890 # HTTP と SOCKS の混合入口
allow-lan: false # LAN 内の他デバイスからの接続を許可するか
external-controller: 127.0.0.1:9090 # コントローラーのアドレス、ローカルのみでリスン
mixed-port:HTTP と SOCKS の混合入口ポート。システムプロキシはここを指定します。allow-lan:LAN 内の他デバイスからの接続を許可するかどうか。単体使用では false のままにします。external-controller:外部コントローラーのアドレス。パネル系ツールはこれを通じてコアを管理します。
注意
external-controller を 0.0.0.0 にバインドしてそのままインターネットに公開してはいけません。どうしても遠隔管理が必要な場合は、必ず secret を設定し、さらに認証付きのリバースプロキシを前段に置いてください。
ステップ3:手動起動での動作確認
mihomo -d /etc/mihomo
ターミナルに mixed inbound のリスンログが表示されたら、別のターミナルウィンドウを開いて出口を確認します。
curl -x http://127.0.0.1:7890 https://api.ip.sb
返ってきた出口 IP が選択したノードの地域と一致していれば、プロキシ経路は正常に開通しています。Ctrl+C でプロセスを終了し、サービス化の設定に進みます。
systemd で自動起動を登録する
手動での動作確認が済んだら、mihomo を systemd に管理させ、自動起動とクラッシュ時の自動復旧を実現します。root 権限で /etc/systemd/system/mihomo.service を新規作成します。
[Unit]
Description=mihomo proxy daemon
After=network-online.target
Wants=network-online.target
[Service]
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
LimitNOFILE=1048576
[Install]
WantedBy=multi-user.target
ユニットを読み込んで有効化します。
sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
systemctl status mihomo # active (running) と表示されれば成功
journalctl -u mihomo -f # コアのログをリアルタイムで追跡
status が active (running) と表示されればサービスは正常に動作しています。問題が起きた場合はまず journalctl のログを確認してください。エラー内容から該当箇所が特定できます。
TUN モードで全体を丸ごとプロキシにしたい場合は、まず config.yaml の tun セクションを有効化します。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
続けて service ファイルの [Service] セクションに以下2行のケーパビリティ設定を追加し、コアに仮想ネットワークインターフェースを作成する権限を与えます。
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
変更後は systemctl daemon-reload を実行し、restart mihomo で反映させます。
サブスクリプションの更新も自動化できます。cron で毎週 config.yaml を再取得し systemctl restart mihomo を実行する方法のほか、コントローラーの API を呼んでホットリロードし、再起動を省く方法もあります。
curl -X PUT "http://127.0.0.1:9090/configs?force=true" \
-d '{"path": "/etc/mihomo/config.yaml"}'
デスクトップ環境からプロキシへの向け先設定
コアを起動しただけではまだ最初の一歩に過ぎません。システムの通信をそこへ振り向ける必要があります。GNOME では、設定 → ネットワーク → ネットワークプロキシ → 手動 で、HTTP と HTTPS のホストに 127.0.0.1、ポートに 7890 を入力し、SOCKS ホストも同じく 127.0.0.1:7890 に設定します。KDE では システム設定 のネットワークプロキシページで同様の設定を行います。コマンドラインでの等価な設定は以下の通りです。
gsettings set org.gnome.system.proxy mode 'manual'
gsettings set org.gnome.system.proxy.http host '127.0.0.1'
gsettings set org.gnome.system.proxy.http port 7890
ターミナルで一時的にプロキシ経由にしたい場合は、環境変数を使う方法が手軽です。
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890
この3行を ~/.bashrc に書き込めば恒久的に有効になります。すでに TUN モードを有効にしているマシンでは、これらの手順はすべて不要です。ルーティング層で通信が処理されるため、アプリ側での設定は一切必要ありません。
よくある質問
AppImage をダブルクリックしても反応がなく、ターミナルで実行すると FUSE 関連のエラーが出る
システムに FUSE ランタイムが不足しています。Ubuntu では libfuse2(24.04 では libfuse2t64)、Fedora では fuse-libs をインストールしてください。AppImage に --appimage-extract オプションを付けて展開してから実行する方法もあります。
TUN モードを有効化すると権限不足のエラーが出る
クライアント側ではポップアップでコアの権限昇格を承認する必要があります。コマンドライン側では service ファイルに CAP_NET_ADMIN のケーパビリティ設定が追加されているか確認し、root またはその権限を持つユーザーで実行してください。
curl でテストしてもローカルの IP がそのまま返ってくる
まず 7890 番ポートがリスンしているか確認します(ss -tlnp | grep 7890)。次にルールモードを確認してください。ルールモードでは対象サイトが DIRECT(直結)に振り分けられている可能性があるため、グローバルモードに切り替えて再確認し、ルールが原因かどうかを絞り込みます。
systemctl で mihomo の起動に失敗する
多くの場合、config.yaml の文法エラーかデータファイルの欠落が原因です。journalctl -u mihomo -n 50 を実行して具体的なエラーを確認してください。YAML のインデントはスペースのみを使用し、タブは使えない点にも注意してください。
LAN 内の他デバイスからこのマシンのプロキシを共有したい
config.yaml の allow-lan を true に変更し、ファイアウォールで 7890 番ポートを許可してから、他デバイスのプロキシ設定をこのマシンの LAN 内 IP に向けてください。external-controller はローカルのみのリスンを維持し、一緒に公開しないよう注意してください。
まとめ:デスクトップクライアントは「使いやすさ」を、mihomo と systemd の組み合わせは「常時稼働」を実現します。本記事の順序で作業を進めれば、Linux マシンは起動した瞬間から安定したプロキシ経路を持つようになります。クライアントと各プラットフォーム向けコアはダウンロードセンターに OS ごとに整理されているので、必要に応じて取得してください。