Linuxでmihomoコアを動かす:コマンドライン導入、設定ディレクトリ、systemd自動起動

Linuxでmihomoを導入する手順を解説。CPUアーキテクチャに合ったバイナリの選び方から、config.yamlの配置、systemdサービスの設定、デスクトップ環境のプロキシ設定まで紹介します。

1. 導入範囲:まずローカルプロキシを動かし、TUNは後から検討

この記事では、DebianやUbuntuなどsystemdを使用するLinux環境を対象にします。sudo権限が必要です。また、gzip、curl、iproute2、CA証明書をインストールしてください。まず次のコマンドでPID 1がsystemdか確認します。コンテナや一部のWSL環境、ほかのinitシステムでは、サービス管理の手順をそのまま適用できません。

ps -p 1 -o comm=
uname -m
sudo apt update
sudo apt install gzip curl iproute2 ca-certificates

mihomoはClash Metaから発展したプロキシコアであり、ウィンドウを備えたデスクトップクライアントではありません。YAMLの読み込み、プロキシ接続の確立、ルールの適用を担いますが、デスクトップメニューやサブスクリプション管理画面、システムプロキシの切り替え機能は、このバイナリだけでは利用できません。

  • ローカルアプリの接続先:この記事では 127.0.0.1:7890 を使用します。同じmixedポートでHTTPプロキシとSOCKS5のリクエストを受け付けます。
  • サービスの権限:ログイン不可の専用ユーザーを使い、通常のプロキシポートにroot権限を与えません。
  • 通信の対象範囲:まず明示的プロキシを検証します。この記事では透過プロキシ、ファイアウォール転送、TUN仮想インターフェースは設定しません。

2. バイナリの選択:アーキテクチャを確認して展開・インストール

まず uname -m の出力を確認し、ダウンロードページで対応するLinux用コアファイルを選びます。クライアント用のDEBやRPMパッケージを、単体コアの圧縮ファイルとして使わないでください。また、デバイスのブランドだけでCPUアーキテクチャを判断しないようにしましょう。

コマンドの出力対応するファイルの種類インストール前の確認
x86_64Linux amd64CPU命令セット別のビルドがある場合は、リリースノートを確認して互換性のあるものを選びます。
aarch64Linux arm6464ビットのユーザー空間で動作していることを確認します。
armv7l対応するLinux ARM版ビルドARMのバージョンと浮動小数点ABIを確認してください。arm64用ファイルはそのまま使えません。

以下の手順では、ダウンロードした.gz形式のコアファイルを、現在のユーザーのDownloadsディレクトリに保存し、ローカルでmihomo.gzに名前を変更したものとします。これは作業用のファイル名であり、配布ファイルの元の名前ではありません。圧縮されていないバイナリをダウンロードした場合は、gzipでの展開手順を省略してください。

gzip -dc "$HOME/Downloads/mihomo.gz" > "$HOME/Downloads/mihomo"
chmod 0755 "$HOME/Downloads/mihomo"
"$HOME/Downloads/mihomo" -v
sudo install -m 0755 "$HOME/Downloads/mihomo" /usr/local/bin/mihomo
/usr/local/bin/mihomo -v

バージョン確認コマンドでは、ファイル自体のバージョン情報が表示されます。Exec format errorが出た場合は、まずCPUアーキテクチャと圧縮状態を確認してください。Illegal instructionが出た場合は、より新しい命令セットを要求するビルドを誤って選んでいないか確認します。どちらのエラーも、sudoを繰り返し追加して解決しようとしないでください。

3. ディレクトリの役割:設定は/etc、実行データは/var/lib

ディレクトリを固定すると、端末からの手動起動とsystemdからの起動で異なるファイルを読み込む事態を防げます。この記事では、設定ファイルを-f、データディレクトリを-dで明示し、ログインユーザーのデフォルト設定パスには依存しません。

パス用途権限の方針
/usr/local/bin/mihomoコアの実行ファイルrootでインストールし、サービスユーザーには実行権限だけを付与します。
/etc/mihomo/config.yamlメイン設定ファイルrootで編集し、mihomoグループに読み取り権限を付与します。
/var/lib/mihomoキャッシュ、ルール関連リソース、プロバイダーファイルサービスユーザーに書き込み権限を付与します。
/etc/systemd/system/mihomo.servicesystemdユニットファイルrootが管理します。

初回導入時にサービスアカウントとディレクトリを作成します。同名のアカウントがすでに存在する場合は、まず id mihomo の結果を確認し、再利用するか判断してください。作成コマンドを再実行して、エラーを無視しないでください。

sudo useradd --system --user-group --home-dir /var/lib/mihomo --shell /usr/sbin/nologin mihomo
sudo install -d -o root -g mihomo -m 0750 /etc/mihomo
sudo install -d -o mihomo -g mihomo -m 0750 /var/lib/mihomo

サブスクリプションファイルには、サーバーアドレス、パスワード、アクセストークンが含まれる場合があります。公開Webディレクトリに保存したり、内容をそのままサポートチケットに貼り付けたりしないでください。ルールプロバイダーやプロキシプロバイダーの相対パスは、通常データディレクトリを基準に解決されます。./rules/や./providers/など、データディレクトリ内のパスを使い、サービスアカウントの書き込み権限も確認してください。

4. config.yaml:まず待ち受けを確認し、その後に実際の設定を読み込む

最小構成の設定は起動経路の検証に使用

以下のYAMLにはプロキシノードがなく、すべてのリクエストは最終的にDIRECTで接続します。コアの起動、ファイル権限、ローカルポートの動作を確認するためのもので、リモートプロキシが使えることを示すものではありません。まず基準となる状態を作り、その後に完全な設定を読み込めば、導入時の問題とサブスクリプションの問題を切り分けられます。

sudo tee /etc/mihomo/config.yaml > /dev/null <<'YAML'
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false

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

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

sudo -u mihomo /usr/local/bin/mihomo \
  -t -d /var/lib/mihomo -f /etc/mihomo/config.yaml

-tは設定ファイルの検証に使います。検証に成功したら、次にフォアグラウンドで一度起動してください。別の端末で後述のcurlテストを実行します。テストが終わったらCtrl+Cで終了し、フォアグラウンドのプロセスとsystemdサービスがポートを取り合わないようにします。

sudo -u mihomo /usr/local/bin/mihomo \
  -d /var/lib/mihomo -f /etc/mihomo/config.yaml

完全なサブスクリプション設定にはノードとポリシー定義が必要

サービス提供元が用意したmihomoまたはClash Meta用の設定取得手段から、完全なYAMLを取得し、ローカルにDownloads/config.yamlとして保存します。ノードURIの一覧、Base64テキスト、Webページの内容だけでは、メイン設定としてそのまま実行できません。proxiesだけを含むノード一覧も、ルールやポリシーグループを含む完全なメイン設定とは異なります。

sudo cp -a /etc/mihomo/config.yaml /etc/mihomo/config.yaml.bak
sudo install -o root -g mihomo -m 0640 \
  "$HOME/Downloads/config.yaml" /etc/mihomo/config.yaml

sudoedit /etc/mihomo/config.yaml

sudo -u mihomo /usr/local/bin/mihomo \
  -t -d /var/lib/mihomo -f /etc/mihomo/config.yaml
  • エディターで、トップレベルにmixed-port: 7890、allow-lan: false、bind-address: 127.0.0.1が設定されていることを確認します。同じキーがすでにあれば値を変更し、重複して追加しないでください。
  • 初回導入時は、設定ファイルのtun.enableを無効にしてください。53番ポートで待ち受けるDNSサービスを有効にしている場合も、いったん停止するか、別途権限を設計してください。この記事のサービスユニットでは、これらに必要な権限を付与しません。
  • rulesで参照しているポリシー名が、proxy-groupsまたはノード一覧に実際に存在するか確認します。YAMLのインデントにはスペースを使い、Tabは使わないでください。
  • 初回起動時は、必須でないコントローラー設定をいったん削除してもかまいません。外部コントローラーが必要な場合は、ループバックアドレスにバインドしてアクセスキーを設定し、インターネットに直接公開しないでください。

5. systemdサービス:ユーザー、パス、起動オプションを固定

フォアグラウンドのプロセスが終了したことを確認してから、サービスファイルを作成します。絶対パスを使うことで、systemdと対話型端末の環境変数の違いによりプログラムが見つからなくなるのを防げます。network-online.targetはシステムのネットワーク準備が完了したことを示すだけで、サブスクリプションURLやリモートノードへの接続を保証するものではありません。

sudo tee /etc/systemd/system/mihomo.service > /dev/null <<'UNIT'
[Unit]
Description=mihomo local proxy service
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=mihomo
Group=mihomo
WorkingDirectory=/var/lib/mihomo
ExecStart=/usr/local/bin/mihomo -d /var/lib/mihomo -f /etc/mihomo/config.yaml
Restart=on-failure
RestartSec=5s
UMask=0077
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target
UNIT

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo.service
systemctl is-enabled mihomo.service
systemctl is-active mihomo.service
sudo systemctl status mihomo.service --no-pager
sudo journalctl -u mihomo.service -b -n 80 --no-pager

enable --nowは、起動時の自動起動を設定すると同時にサービスをすぐ起動します。is-enabledの結果はenabled、is-activeの結果はactiveになるはずです。これらで確認できるのはプロセスの状態だけです。プロキシ経由で目的の接続先にアクセスできるかは、次のセクションで検証してください。

設定ファイルとサービスファイルの変更は別々に対応

  • YAMLだけを変更:まず mihomo -t で設定全体を検証し、問題がなければ sudo systemctl restart mihomo を実行します。
  • serviceファイルを変更:まず sudo systemctl daemon-reload を実行し、その後サービスを再起動します。
  • 一時停止:sudo systemctl stop mihomoを実行します。次回起動時の自動起動設定は解除されません。
  • 自動起動を無効にして停止:sudo systemctl disable --now mihomoを実行します。

このサービスではExecReloadを定義していないため、systemctl reload mihomoが使えるとは限りません。設定を検証してから再起動する方法が確実です。再起動すると既存の接続が切れるため、ダウンロードやリモートセッションの最中は避けてください。

6. 接続の検証:待ち受け、HTTP、SOCKS5を段階的に確認

まずポートを確認し、その後リクエストをテストします。-qを使うとユーザーのcurl設定ファイルの影響を避けられます。また、--noproxy ""を指定して、既存のプロキシ除外リストによって今回のテストが迂回されないようにします。以下のURLはリクエスト手順の例であり、ノードの速度測定用ではありません。

sudo ss -lntp | grep ':7890'

curl -q --noproxy "" --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 30 -I https://example.com/

curl -q --noproxy "" --proxy socks5h://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 30 -I https://example.com/

socks5hでは、接続先のドメイン名をプロキシ側で解決します。curlのローカルで接続先を名前解決するsocks5とは異なります。mihomoを使う場合、実際の名前解決経路はコアのDNS設定にも左右されるため、このオプションだけでDNS通信すべての出口を判断することはできません。

  • 接続が拒否される:コアが動作しているか、ポートが一致しているか、別のアドレスだけで待ち受けていないかを確認します。
  • プロキシには接続できるが接続先がタイムアウトする:ローカルの待ち受けポートを変え続けるのではなく、実際に適用されたルール、選択中のポリシー、ノードを確認します。
  • 最小構成でリクエストに成功する:明示的プロキシの接続口が使えることを示すだけで、通信は引き続き直接接続です。
  • 実際のノードを検証:完全な設定を読み込んだ状態でjournalctl -u mihomo -fを確認し、リクエストに適用されたルールと出力ポリシーを確認します。HTTP CONNECTの確立メッセージを、接続先サイトから応答があった証拠と取り違えないでください。

7. デスクトップと端末:接続先ごとにプロキシを設定

GNOMEのデスクトップ設定

GNOMEで「設定」→「ネットワーク」→「ネットワークプロキシ」を開き、「手動」を選択します。HTTPとHTTPSのプロキシには、ホスト127.0.0.1、ポート7890を指定します。SOCKSにも同じホストとポートを設定できます。HTTPS欄はHTTPSの接続先に使うプロキシを指定するもので、ローカルポートでTLSを提供する必要はありません。

現在のデスクトップユーザーの端末から、次のコマンドでGNOMEを設定することもできます。sudoを付けないでください。rootユーザーの設定を変更したり、現在のユーザーのセッションバスにアクセスできなくなったりする場合があります。

gsettings set org.gnome.system.proxy.http host '127.0.0.1'
gsettings set org.gnome.system.proxy.http port 7890
gsettings set org.gnome.system.proxy.https host '127.0.0.1'
gsettings set org.gnome.system.proxy.https port 7890
gsettings set org.gnome.system.proxy.socks host '127.0.0.1'
gsettings set org.gnome.system.proxy.socks port 7890
gsettings set org.gnome.system.proxy ignore-hosts "['localhost', '127.0.0.0/8', '::1']"
gsettings set org.gnome.system.proxy mode 'manual'

現在の端末で使う環境変数

デスクトップのプロキシ設定が、端末のプログラムにも自動的に適用されるとは限りません。プロキシ環境変数に対応したコマンドラインツールでは、現在のシェルで次の値を設定できます。変数の設定は、その後に起動するプログラムにのみ適用されます。大文字・小文字の変数、SOCKS、除外リストへの対応はツールによって異なります。

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

ブラウザーで別のプロキシを手動指定している場合は、システムプロキシを使う設定にするか、上記のポートを直接指定してください。コンテナや仮想マシン内の127.0.0.1は、それぞれの環境自身を指し、ホストマシンではありません。この記事のループバック待ち受け構成では、これらの環境から直接接続できません。

8. よくあるエラーと元に戻す手順

症状まず確認する項目対処方法
status=203/EXEC実行ファイルのパス、実行権限、ファイルのアーキテクチャ/usr/local/bin/mihomo -vを手動で実行し、サービスに設定した絶対パスと照合します。
permission deniedメイン設定の読み取り権限、ディレクトリへのアクセス権限、データディレクトリの書き込み権限sudo -u mihomoを使って設定を検証します。rootで実行して権限の問題を隠さないでください。
address already in use7890または設定で指定した別の待ち受けポートsudo ss -lntupでポートの使用プロセスを確認し、重複しているコアを停止するか、ポートを変更します。
リソースのダウンロードに失敗する設定でGeoデータ、ルールプロバイダー、プロキシプロバイダーを参照しているかリソースURL、ディレクトリ権限、起動時に直接接続できるかを確認します。バイナリを何度も再インストールする必要はありません。
デスクトップを終了した後も端末からインターネットに接続できないシェルにプロキシ環境変数が残っている環境変数を解除し、コマンド自体に別のプロキシ設定がないか確認します。

設定更新後に起動できなくなった場合は、まずログで最初に発生した有効なエラーを確認します。今回のYAML変更が原因であれば、保存しておいたバックアップを復元し、設定を検証してから再起動してください。最初に作成したバックアップは直接接続用の最小構成です。復元しても実際のプロキシノードは戻りません。

sudo cp -a /etc/mihomo/config.yaml.bak /etc/mihomo/config.yaml
sudo -u mihomo /usr/local/bin/mihomo \
  -t -d /var/lib/mihomo -f /etc/mihomo/config.yaml
sudo systemctl restart mihomo

サービスを停止する前に、アプリの接続先をローカルプロキシから直接接続に戻してください。GNOMEと現在の端末では、以下の方法でそれぞれ設定を解除できます。シェルの起動ファイルに環境変数を追加している場合は該当行も削除し、端末を開き直してください。

gsettings set org.gnome.system.proxy mode 'none'
unset http_proxy https_proxy all_proxy no_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY
sudo systemctl disable --now mihomo

最終確認の順序は、バイナリの実行、サービスアカウントによる設定の読み取り、設定の検証、7890番ポートの待ち受け、指定したプロキシ経由のリクエスト成功、ログ上の想定ポリシー確認、システム再起動後のサービス復旧です。各段階を個別に確認すれば、導入、設定、アプリの接続口、リモート接続のどこに問題があるかを切り分けられます。

Clash をダウンロード