LinuxでClashを使う
LinuxデスクトップへのGUIクライアントのインストール手順と、ヘッドレスサーバーでmihomoをsystemdサービスとして常時起動する手順を解説します。
1. デスクトップクライアントとCLIサービスのどちらを使うか
LinuxでClashを使う方法は、大きくデスクトップクライアントとコマンドラインサービスの2つです。デスクトップクライアントでは、サブスクリプションの追加、プロキシグループの選択、システムプロキシの設定、ログの確認ができます。mihomoはプロキシコアとしてYAML設定を読み込み、ポートを待ち受け、ルールに基づいて接続を処理します。コアをインストールしただけでは、デスクトップのシステムプロキシは設定されません。
| 利用環境 | おすすめの方法 | 自分で設定・管理する項目 |
|---|---|---|
| Ubuntu、Fedoraなどのデスクトップ環境 | Clash Verge RevやFlClashなどのGUIクライアント | サブスクリプションの追加、設定の有効化、ローカルポートの確認 |
| SSHで管理するサーバー | mihomoとsystemdのシステムサービス | 設定ファイル、実行ユーザー、権限、ログ、更新 |
| ターミナルのツールだけをプロキシ経由にする | どちらの方法でもローカルHTTPプロキシを利用可能 | プロキシの指定または環境変数の設定 |
この記事では、systemdが有効な一般的なLinuxディストリビューションを前提にします。コンテナ、WSL、軽量システムでは、システムレベルのsystemdを利用できない場合があります。まず次のコマンドで環境を確認してから、インストールするパッケージを選んでください。コアのバージョンは実際のコマンド出力で確認し、クライアント画面の表示から推測しないでください。
uname -m
cat /etc/os-release
ps -p 1 -o comm=x86_64は通常、amd64またはx64パッケージに対応します。aarch64は通常、arm64パッケージに対応します。x64用の実行ファイルは使えません。- Debian、Ubuntuでは通常DEB、Fedoraなどでは通常RPMを使用します。パッケージ形式とCPUアーキテクチャの両方を一致させてください。
2. Linuxデスクトップへのインストールとサブスクリプションの追加
GUIクライアントをインストールする
ダウンロードページからLinuxを選び、ディストリビューションとアーキテクチャに合ったクライアントを選択します。以下のコマンドでは、ダウンロードしたDEBパッケージを clash-client.deb、RPMパッケージを clash-client.rpm にリネームし、ファイルのあるディレクトリで該当するコマンドを1つだけ実行してください。
# Debian / Ubuntu：次のコマンドを1つだけ実行
sudo apt install ./clash-client.deb
# Fedora：次のコマンドを1つだけ実行
sudo dnf install ./clash-client.rpmパッケージマネージャーが依存関係を確認します。GUI関連のコンポーネントが不足していると表示された場合は、SSHだけの環境でウィンドウアプリを何度も起動するのではなく、デスクトップ環境がインストールされているか確認してください。インストール後はアプリケーションメニューからクライアントを起動します。通常、GUI全体を sudo で起動する必要はありません。
設定を追加してシステムプロキシを有効にする
- ここではClash Verge Revを例に説明します。「サブスクリプション」画面でサブスクリプションURLを追加し、ダウンロード後に該当する設定を選択します。ボタンの表示名はバージョンによって多少異なる場合があります。
- 「プロキシ」画面でプロキシグループを確認し、利用可能なノードを選択します。「ルール」モードでは、リクエストは設定されたルールに従って振り分けられます。ノードを選んだだけですべての接続がプロキシ経由になるわけではありません。
- 「設定」で「システムプロキシ」とポートを確認し、実際に使われている混合ポートを控えてください。この記事では以降、
7890を例にします。画面上のポートが異なる場合は、コマンド内のポートも置き換えてください。 - まずシステムプロキシを有効にしてブラウザーで確認し、その後ターミナルを個別にテストしてください。別のクライアントのシステムプロキシも同時に有効にすると、設定が上書きされることがあります。
デスクトップ環境には、独自のプロキシ設定画面が用意されていることがあります。たとえばGNOMEでは「設定」→「ネットワーク」→「ネットワークプロキシ」から確認できます。クライアントが想定したアドレスを書き込んでいるか確認できますが、すべてのアプリがデスクトップのプロキシ設定を参照するわけではありません。ブラウザーが接続できるだけでシステム全体がプロキシ経由になったと判断せず、curl、Git、パッケージマネージャーはそれぞれ確認してください。
3. mihomoをインストールしてサービス用アカウントを作成する
ヘッドレスサーバーにGUIクライアントをインストールする必要はありません。アーキテクチャに合ったmihomoコアを入手し、ファイル形式に応じて解凍してから、実行ファイルの名前を mihomo にします。以下では、圧縮ファイルをシステムパスに直接コピーするのではなく、作業ディレクトリにこの実行ファイルがあるものとします。
chmod +x ./mihomo
./mihomo -v
sudo install -m 0755 ./mihomo /usr/local/bin/mihomo
/usr/local/bin/mihomo -vExec format errorが発生した場合は、まずアーキテクチャと解凍状態を確認してください。Permission deniedが発生した場合は、実行権限と、ファイルシステムに noexec マウントオプションが設定されていないか確認します。実行できるようにするために、ファイルへ任意の書き込み権限を付与しないでください。
プログラム、設定、実行データを分ける
専用のシステムアカウントでサービスを実行します。設定は /etc/mihomo、キャッシュやルールデータは /var/lib/mihomo に保存し、実行ファイルは /usr/local/bin に置きます。以下のアカウント作成コマンドは1回だけ実行してください。同じ名前のアカウントがすでにある場合は、用途と権限を先に確認します。
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ここでは一般ユーザーで 7890 を待ち受けるため、低位ポートをバインドする権限は不要です。また、このサービス構成ではTUNを使わないため、ネットワーク管理権限も付与しません。後からTUNを追加する場合は、デバイスへのアクセス、ケイパビリティ、ルーティングの動作を改めて確認してください。サービス全体をrootで常時実行する方法は避けてください。
4. 設定を準備して起動前に確認する
まず最小構成でプログラム、権限、待ち受けポートを確認し、その後に実際のサブスクリプションを使います。以下はローカルで直接接続するための完全なテスト設定です。プロキシノードは作成されず、すべてのリクエストが最終的に直接接続されます。HTTPとSOCKSの混合ポートが正常に動作するか確認するためだけに使用します。
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は設定のテスト、-dは作業ディレクトリ、-fは設定ファイルを指定します。テストに成功しても、コアが設定を読み込めたことを示すだけで、ノードへの接続や対象サイトへの到達を保証するものではありません。GeoIP、GeoSite、リモートルールセットを使う設定では、対応するデータファイルの準備やダウンロード経路の確認も必要になる場合があります。
実際のサブスクリプション設定に置き換える
mihomoに対応したYAMLファイルをローカルに保存します。たとえば、現在のディレクトリにある profile.yaml を使用できます。ファイルの内容が正しい設定であり、サブスクリプションのエラーページやログインページ、ノード一覧だけのエンコード済みテキストではないことを確認してから、固定パスにコピーします。
sudo install -o root -g mihomo -m 0640 \
./profile.yaml /etc/mihomo/config.yaml
sudo -u mihomo /usr/local/bin/mihomo \
-t -d /var/lib/mihomo -f /etc/mihomo/config.yaml- サービスに必要な
mixed-port: 7890とローカルホストへのバインド設定を維持してください。同じキーがすでにある場合は値を変更し、重複したキーを追加しないでください。 proxy-groupsで参照するノード名と、ルールで参照するプロキシグループ名が一致しているか確認してください。proxy-providersやrule-providersを使用する場合は、ローカルキャッシュを作業ディレクトリ内（例：./providers）に置くことをおすすめします。サービスから書き込めない設定ディレクトリは指定しないでください。tun、LAN向けの待ち受け、外部公開のコントロールインターフェースが意図せず有効になっていないか確認してください。サブスクリプションに含まれる実行時設定も確認が必要です。
5. systemdでサービスを常時起動する
システムサービスユニットを作成します。専用アカウントで実行し、起動前に設定をテストします。プロセスが異常終了した場合は5秒後に再起動します。強化設定によりシステムディレクトリは読み取り専用となり、実行データ用ディレクトリだけが書き込み可能です。そのため、設定内のキャッシュファイルも実行データ用ディレクトリに保存してください。
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
ExecStartPre=/usr/local/bin/mihomo -t -d /var/lib/mihomo -f /etc/mihomo/config.yaml
ExecStart=/usr/local/bin/mihomo -d /var/lib/mihomo -f /etc/mihomo/config.yaml
Restart=on-failure
RestartSec=5
UMask=0077
NoNewPrivileges=true
PrivateTmp=true
ProtectHome=true
ProtectSystem=strict
ReadWritePaths=/var/lib/mihomo
[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-pagerenable --nowを実行すると、サービスの自動起動設定と即時起動を同時に行えます。network-online.targetは起動順序を指定するだけです。実際の動作はディストリビューションのネットワーク待機サービスにも左右されるため、サブスクリプションサーバーやプロキシノードに必ず接続できるとは限りません。
変更を反映する方法
YAMLだけを変更した場合は、先に前述の -t テストを実行します。成功したら sudo systemctl restart mihomo.service を実行してください。サービスユニットを変更した場合は、まず sudo systemctl daemon-reload を実行してから再起動します。この記事では ExecReload を設定していないため、設定の再読み込みに systemctl reload は使えません。
6. 待ち受け、リクエスト、ルールを個別に確認する
手順1：ポートが実際に待ち受けているか確認する
sudo ss -lntp 'sport = :7890'
curl --proxy http://127.0.0.1:7890 \
--connect-timeout 10 --max-time 30 \
-I https://example.com/
curl --proxy socks5h://127.0.0.1:7890 \
--connect-timeout 10 --max-time 30 \
-I https://example.com/待ち受けアドレスはループバックアドレスである必要があります。外部に公開される 0.0.0.0:7890 になっていないことを確認してください。2つのcurlコマンドで、混合ポートのHTTPとSOCKSの接続をそれぞれ確認します。socks5hは対象ドメインの処理をプロキシに任せるため、curlがローカルで先に名前解決する影響を除外できます。ただし、mihomoが最終的にどのDNS上流を使うかを決めるものではありません。
最小構成でリクエストに成功しても、確認できるのは直接接続が正常に動作することだけです。実際の設定に切り替えた後は、ログでルールの適用とプロキシグループの選択を確認し、テスト用ドメインが想定したノードを経由しているか確認してください。HTTP接続の確立、対象サイトからのステータスコードの受信、想定どおりの出口IPは、それぞれ別の確認項目です。
手順2：ターミナルのプログラムにプロキシを明示する
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1
curl -I --connect-timeout 10 --max-time 30 https://example.com/
# 現在のターミナルで上記の設定を解除する
unset http_proxy https_proxy no_proxyhttps_proxyには引き続きhttp://を指定できます。これはHTTPプロキシのCONNECTトンネルでHTTPSサイトに接続するという意味であり、接続先がHTTPに切り替わるわけではありません。環境変数が適用されるのは現在のプロセスとその子プロセスだけです。他のターミナル、デスクトップアプリ、起動済みのsystemdサービスには自動で引き継がれません。
特定のプログラムだけが失敗する場合は、そのプログラム固有のプロキシ設定を確認してください。sudoは環境変数を引き継がない場合もあります。curlでプロキシを使えたとしても、APT、コンテナのビルド、バックグラウンドサービスも同じプロキシを使用しているとは限りません。
7. リモート利用とTUNの権限に関する注意点
サーバー上の127.0.0.1はサーバー自身を指し、手元のPCを指すものではありません。サーバー経由のプロキシを一時的にテストする場合は、混合ポートをインターネットに直接公開せず、ローカルからSSHポートフォワーディングを利用できます。192.0.2.10はドキュメント用の例示アドレスです。実行前に実際のサーバーアドレスに置き換え、opsも実際のSSHアカウント名に変更してください。
# 手元のPCで実行し、このセッションを開いたままにする
ssh -N -o ExitOnForwardFailure=yes \
-L 127.0.0.1:17890:127.0.0.1:7890 [email protected]
# 手元のPCで別のターミナルを開いてテストする
curl --proxy http://127.0.0.1:17890 \
--connect-timeout 10 --max-time 30 \
-I https://example.com/ローカルポートに17890を使うのは、よく使われるローカルクライアントのポートとの競合を避けるためです。LANにプロキシを公開する場合は、allow-lan、待ち受けアドレス、認証、ファイアウォールを合わせて設計し、接続元のネットワーク範囲を制限してください。コントロールインターフェースとプロキシの待ち受けポートは別物です。コントロールインターフェースをプロキシアドレスとして使わないでください。
TUNは導入に必須ではない
TUNは仮想ネットワークインターフェースとルーティングを使い、条件に合うIPトラフィックを取り込みます。システムプロキシを参照しないアプリに適しています。Linuxでは通常、/dev/net/tun、ネットワーク管理権限、DNSルーティングの設定が必要です。この記事のサービス設定は一般ユーザーで実行し、権限も制限しているため、TUNの利用を想定していません。YAMLに tun.enable: true を追加すると、権限不足で失敗する可能性があります。
8. トラブルシューティングと日常的な更新
| 症状 | まず確認する項目 | 対処方法 |
|---|---|---|
| サービスが終了し、ポートも待ち受けていない | journalctlのログと設定テストの出力 | YAML、ファイル権限、ルール関連データの問題を修正してから起動する |
| ログにaddress already in useと表示される | ssで7890を使用しているプロセス | 重複して起動したコアを停止するか、待ち受けポートとアプリのプロキシ設定をそろえる |
| ブラウザーは接続できるが、ターミナルは直接接続する | ターミナルのプロキシ指定と環境変数 | まずcurlの--proxyを使って明示的に確認する |
| プロキシに接続できるが、リクエストが直接接続される | ルールの順序、プロキシグループの選択、ログの出力先 | DIRECTに一致していないか、直接接続するグループを選択していないか確認する |
| ルールセットのダウンロードに失敗する | 作業ディレクトリの権限、ダウンロード先、ネットワーク状態 | キャッシュパスを書き込み可能にし、更新経路が未使用のプロキシに依存していないか確認する |
更新前に、元に戻せるプログラムと設定を保管する
コアを更新する前に、mihomo -vの出力を記録し、旧プログラムを保管します。新しいプログラムを一時パスに置き、バージョン表示と設定テストを実行して、使用中のプロトコルと設定項目に対応していることを確認してください。その後サービスを停止し、プログラムを入れ替えて起動します。実行中のファイルを直接上書きしたり、プログラム更新と大規模なルール変更を同じトラブル対応で行ったりしないでください。
サブスクリプション設定を更新する前に、/etc/mihomo/config.yamlをバックアップし、ポート、待ち受けアドレス、コントロールインターフェース、TUN、providerのパスを比較します。設定テストに成功してから再起動し、ポートの確認とプロキシを明示したリクエストを再度実行してください。この順序なら、問題がプログラム、設定、ネットワークのどこにあるか切り分けやすくなります。複数の条件を一度に変更して原因を見失うことも防げます。
デスクトップでは、現在の設定、プロキシグループ、システムプロキシが一致しているかが重要です。サーバーでは、アカウント権限、固定された設定パス、systemdのログを確認します。まずローカルプロキシを安定させてから、自動更新、リモート管理、TUNを必要に応じて追加すると、運用負荷を抑えやすくなります。