導入方法を選ぶ：デスクトップクライアントか単体カーネルか

LinuxでClashの設定を使う方法は、大きく分けて2つあります。デスクトップ環境ではGUIクライアントを導入し、mihomoをクライアントから管理します。サーバーや軽量環境ではmihomoを直接起動し、systemdでプロセスを管理します。mihomoはプロキシカーネルであり、デスクトップの設定画面ではありません。バイナリをシステムに置いただけでは、システムプロキシは有効にならず、すべてのターミナルコマンドがプロキシ経由になるわけでもありません。

利用シーンおすすめの方法管理する項目
普段使いのデスクトップ、設定を頻繁に切り替えるGUIクライアント設定のインポート、プロキシグループ、システムプロキシ、ログイン時の自動起動
SSHサーバー、コマンドラインツールmihomoとsystemd設定ファイル、サービス用アカウント、ポート、ターミナルの環境変数
プロキシに対応していないアプリも経由させたいTUNを追加設定仮想ネットワークインターフェース、権限、ルーティング、DNS

以下のコマンドは、systemdを使用するDebian 12やUbuntu 24.04などを例にしています。ローカルのループバックアドレス 127.0.0.1 と混合ポート 7890 を使用します。まず ps -p 1 -o comm= を実行し、PID 1が systemd であることを確認してください。コンテナ、一部のWSL環境、OpenRCを使うシステムでは、サービス管理の手順をそのまま適用できません。

Linuxデスクトップ：クライアントを導入してプロキシ接続を確認

ディストリビューションとCPUアーキテクチャに合ったパッケージを選ぶ

クライアントダウンロードページでLinuxを選び、Clash Verge RevやFlClashsなどの対応パッケージとシステム要件を確認してください。DebianやUbuntuでは通常DEB、FedoraなどではRPMを選びます。ARM64用パッケージをx86_64端末に入れないよう、まず次の2つのコマンドで環境を確認しましょう。

uname -m
cat /etc/os-release
  • x86_64 は通常x64またはamd64、aarch64 は通常arm64に対応します。
  • DEBまたはRPMパッケージは、デスクトップのソフトウェアインストーラーで開けます。依存関係のエラーが出た場合は、ディストリビューションのパッケージマネージャーで解決してください。別のOS向け共有ライブラリを安易にダウンロードしないでください。
  • インストール後にウィンドウが開かない場合は、ターミナルからクライアントを起動し、エラーメッセージを確認してください。GUIランタイムの不足とプロキシ設定の誤りは別の問題です。

まず設定をインポートし、その後システムプロキシを設定

クライアントの設定またはサブスクリプション画面から、提供元の互換性のある設定をインポートして適用し、接続ログとプロキシグループを確認します。メニュー名はクライアントによって異なるため、実際の画面に従ってください。カーネルが起動し、7890で待ち受けていることを確認してから、クライアントのシステムプロキシを有効にします。

手動で設定する場合、GNOMEデスクトップでは通常「設定」→「ネットワーク」→「ネットワークプロキシ」→「手動」から設定します。HTTPとHTTPSのプロキシには、ホスト 127.0.0.1、ポート 7890 を指定できます。ここでいうHTTPSは、HTTPSリクエストが使用するプロキシの設定です。ローカルの待ち受けポートでTLSを有効にする必要があるという意味ではありません。

デスクトップのシステムプロキシは、その設定に従うアプリに接続情報を渡す仕組みです。ブラウザーは利用する場合がありますが、SSHや一部のゲーム、ターミナルツールは利用しないことがあります。クライアントを終了する前にシステムプロキシを無効にしてください。有効なままだと、停止済みのポートを参照し続け、Webページを開けなくなることがあります。

コマンドラインで導入：バイナリ、設定、データの保存先を固定

実行ファイルと専用アカウントを用意する

mihomoプロジェクトの配布元から、端末のアーキテクチャと命令セットに合ったLinuxカーネルを入手します。展開後、実行ファイルを mihomo という名前にして、現在のディレクトリに置いてください。展開前のアーカイブを実行ファイルとしてインストールしてはいけません。まずアーキテクチャとバージョンを確認し、カーネルを固定パスに配置します。

file ./mihomo
chmod u+x ./mihomo
./mihomo -v
sudo install -m 0755 ./mihomo /usr/local/bin/mihomo

getent group mihomo >/dev/null || sudo groupadd --system mihomo
id mihomo >/dev/null 2>&1 || sudo useradd \
  --system --gid mihomo --home-dir /var/lib/mihomo \
  --no-create-home --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

この例では、設定を /etc/mihomo/config.yaml、実行データを /var/lib/mihomo に置きます。設定は管理者が管理し、サービス用アカウントには読み取り専用でアクセスさせます。キャッシュやルール関連のデータはデータディレクトリに書き込みます。起動時のカレントディレクトリに依存したり、SSHユーザーの ~/.config がシステムサービスの設定ディレクトリとして自動的に使われると想定したりしないでください。

最小構成で待ち受けを確認する

以下の設定は、サービスとローカルポートの動作確認専用です。すべての通信は直接接続され、プロキシノードは含まれません。実際のサブスクリプションの代わりにはなりません。既存の設定がある場合は、コマンドを実行して上書きする前にバックアップしてください。最小構成を使うと、サブスクリプションの形式、リモートルールの取得、ノードの可用性をいったん切り分けて確認できます。

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
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 は設定のテスト、-d は作業データディレクトリの指定、-f は設定ファイルの指定に使います。実際の設定に切り替える際も、必ずテストを実行してください。構文チェックに通っても、ノードへの接続やリモートルールの取得が成功するとは限りません。起動ログもあわせて確認してください。

サブスクリプションURLの応答がBase64形式のノード一覧、Webページ、ログイン案内の場合、そのままmihomoのメイン設定として保存することはできません。互換性のある完全なYAMLを入手するか、メイン設定内で形式に合わせて proxy-providers を設定してください。サブスクリプションURLにはアクセス用の認証情報が含まれることが多いため、公開ログやスクリーンショットに載せないでください。

systemdサービス：自動起動、ログ、設定変更後の再起動

システム全体で使うunitファイルを作成します。この例では専用の一般ユーザーで実行し、ローカル向けのHTTP/SOCKS混合プロキシだけを提供します。TUNは有効にしないため、カーネルを常時rootで実行する必要はありません。

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
LimitNOFILE=65536
UMask=0077

[Install]
WantedBy=multi-user.target
UNIT

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo.service
systemctl status mihomo.service --no-pager
sudo journalctl -u mihomo.service -n 80 --no-pager
sudo ss -lntup | grep ':7890'
  • enable --now は、自動起動の設定とサービスの即時起動を同時に行います。enable だけでは、サービスはすぐには起動しません。
  • Restart=on-failure は異常終了時に再起動します。手動でサービスを停止した場合に、強制的に再起動する設定ではありません。
  • network-online.target で実際にどれだけ待機するかは、システムのネットワーク管理コンポーネントによって異なります。リモートのサブスクリプションサーバーへの接続が確立済みであることまでは保証しません。
  • サービスが active (running) と表示された後も、待ち受けアドレスが 127.0.0.1:7890 であることを確認してください。すべてのネットワークインターフェースに誤って公開されていないかも確認します。

設定ファイルとunitファイルでは、変更後の手順が異なる

YAMLを変更したら、同じサービスアカウントで設定をテストしてからサービスを再起動します。この記事のunitには ExecReload を定義していないため、systemctl reload を一般的な再読み込み方法として使わないでください。再起動すると、既存のプロキシ接続が一時的に切断されます。

sudo -u mihomo /usr/local/bin/mihomo -t \
  -d /var/lib/mihomo -f /etc/mihomo/config.yaml
sudo systemctl restart mihomo.service
sudo journalctl -u mihomo.service -n 40 --no-pager

/etc/systemd/system/mihomo.service または関連するdrop-inを変更した場合に限り、先に sudo systemctl daemon-reload を実行します。カーネルを更新する前に、元のバイナリと設定をバックアップしてください。サービスを停止してファイルを置き換え、mihomo -v と設定テストの結果を確認してから再起動します。

ターミナルのプロキシ設定：環境変数を使うのは対応アプリだけ

mihomoが7890で待ち受けたら、現在のターミナルで次の環境変数を設定します。これらの変数に対応する多くのHTTPツールで利用できますが、Linux全体の通信を透過的にプロキシするものではありません。

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

curl -I --connect-timeout 10 https://example.com
curl -I --proxy http://127.0.0.1:7890 https://example.com
curl -I --proxy socks5h://127.0.0.1:7890 https://example.com

socks5h は接続先のドメイン名解決をプロキシ側で行う指定です。socks5 では通常、ローカル側で先に名前解決します。上記の https_proxy も http:// を使います。これはローカルのHTTPプロキシ接続先を表す設定であり、HTTPSサイトには通常CONNECTトンネルで接続します。

最小の直接接続設定でプロキシを明示したリクエストが成功しても、ローカルカーネル経由で接続できたことが分かるだけです。リモートのプロキシノードを確認するには、有効な設定に切り替え、プロキシグループでノードを選択し、接続ログで適用ルールと出力先を確認してください。

設定の永続化と解除

Bashを開くたびに有効にするには、前述のexport行を ~/.bashrc に追加します。Zshでは通常 ~/.zshrc を使います。GUIアプリ、定期実行タスク、systemdサービスは対話型シェルの設定を自動的に読み込みません。そのため、シェルに設定しただけでこれらのプロキシも有効になったとは判断できません。

unset http_proxy https_proxy all_proxy no_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

sudo はプロキシ環境変数を引き継がないことがあり、APTにも個別のプロキシ設定があります。一時的なダウンロードのために、ユーザー環境全体を管理者権限のプロセスへ無条件に渡さないでください。curlで一度だけテストする場合は、--proxy オプションを明示する方法がおすすめです。プロキシ環境変数に対応していないアプリでは、アプリ固有の設定を確認してください。

よくあるトラブル：設定、権限、ポート、ルーティングの順に確認

サービスが起動直後に終了する：まずサービスアカウントの設定読み取り権限を確認

sudo journalctl -u mihomo.service -b -n 100 --no-pager
namei -l /etc/mihomo/config.yaml
sudo -u mihomo test -r /etc/mihomo/config.yaml && echo readable
sudo -u mihomo test -w /var/lib/mihomo && echo writable

permission denied の原因は、設定ファイル自体とは限りません。上位ディレクトリにアクセス権がない場合や、リモートルールの保存先がサービスアカウントの書き込み不可になっている場合もあります。対象ディレクトリの所有者と必要最小限の権限を修正し、chmod -R 777 で問題を覆い隠さないでください。SELinuxが有効なシステムでは、拒否ログも確認します。セキュリティ機能を無効にする方法はおすすめしません。

7890が使用中：カーネルが二重に起動していないか確認

sudo ss -lntp 'sport = :7890'
pgrep -a mihomo

デスクトップクライアント、手動起動したカーネル、systemdサービスが同時に動いていることがあります。プロセスの起動元を確認してから、不要なものだけを停止してください。同じ名前のプロセスをまとめて終了させないでください。ポートを 7891 に変更する場合は、mixed-port、デスクトップのプロキシ設定、ターミナルの環境変数も合わせて変更し、再起動後に待ち受けを確認します。

サービスは正常なのに通信できない：接続先と出力先を切り分ける

  • Connection refused：ポートが待ち受けていない、プロセスが終了した、または接続先アドレスが間違っている可能性があります。まず ss で確認し、ルールの変更は後回しにしてください。
  • プロキシ接続後にタイムアウト：カーネルのログで、ノード接続、ドメイン名解決、ルール取得に関するエラーを確認します。ルールに一致しても、出力先の回線が利用できるとは限りません。
  • 証明書エラー：システム時刻、CA証明書、接続先ドメインを確認してください。TLS検証を無効にする方法を恒久対策にしないでください。
  • 起動失敗を繰り返し、再試行されなくなった：原因を解消してから sudo systemctl reset-failed mihomo.service を実行し、サービスを起動してください。

TUNを使う場合は、権限、DNS、リモート接続への影響を個別に検討

この例の一般ユーザーで動作するサービスは、完全なTUN環境としてそのまま使えません。LinuxのTUNには通常 /dev/net/tun へのアクセスが必要です。仮想インターフェースやルーティングの設定にも、適切なネットワーク管理権限が求められます。必要なケイパビリティ、サービスの制限、DNSの制御方法をまとめて設計してください。YAMLに enable: true を1行追加するだけでは不十分です。

特にSSHサーバーでは、自動ルーティングを有効にする前に、2つ目の管理セッションまたはコンソールを確保してください。SSHの戻り通信、LANのサブネット、内部DNSの経路も明確にします。まずはローカルの7890を指定するプロキシ接続を確認し、その後でTUNを導入してください。ポート、DNS、デフォルトルートを同時に変更すると、どの変更で接続が切れたのか特定しにくくなります。

設定の管理：復旧手段を確保し、更新対象を切り分ける

導入後は、バイナリ、設定ファイル、データディレクトリ、待ち受けポート、サービス名を最低限記録してください。サブスクリプション、カーネル、クライアントの更新はそれぞれ別の作業です。カーネルを置き換えてもノードは自動更新されず、systemdの自動起動を設定してもメイン設定が自動更新されるわけではありません。

  • GUIクライアントを使う場合は、設定画面で自動更新の有効・無効と間隔を確認し、更新後に適用された設定も確認してください。
  • 単体カーネルを使う場合、proxy-providers の更新間隔が適用されるのは該当するproviderだけです。メインのYAML全体を定期的に置き換える設定ではありません。
  • メイン設定を自動取得するには、安全なダウンロード、テスト、置き換え、失敗時の復旧手順を自分で設計する必要があります。テストしていない応答で稼働中の設定を直接上書きしないでください。
  • システムサービスを使わなくなったら、sudo systemctl disable --now mihomo.service を実行し、ターミナルの環境変数とデスクトップのプロキシ設定も解除してください。

普段使いのデスクトップにはGUIクライアント、無人運用の環境には保存先を固定したsystemdサービスが適しています。どちらの場合も、設定の読み込み先、待ち受けポート、アプリの接続方法を先に確認し、ルール分岐やTUNは一つずつ追加してください。設定の概念はプロトコルリファレンス、操作手順は設定ガイドをご覧ください。