プラットフォーム 読了時間：約12分

Linux版Clashの導入方法｜デスクトップGUIとsystemdでの運用

LinuxデスクトップにはGUIクライアント、サーバーやヘッドレス環境にはmihomoとsystemdが適しています。インストールから設定場所、自動起動、プロキシ環境変数まで、2つの方法を解説します。

まず導入方法を選ぶ：デスクトップはGUI、サーバーは単体カーネル

先に結論です。GNOMEやKDEなどのデスクトップ環境があり、サブスクリプションやプロキシグループを頻繁に切り替えるなら、Linux対応のGUIクライアントが便利です。SSHで管理するヘッドレス環境には、mihomoとsystemdの組み合わせが適しています。どちらもローカルのプロキシポートを提供しますが、起動タイミングや設定場所、権限の範囲は異なります。同じポートを2つのカーネルで同時に使用しないでください。

Clashは、この種のクライアントを指す総称としてよく使われます。mihomoはClash Metaから発展したカーネルです。GUIクライアントが画面、サブスクリプション、サービス管理を担い、実際に利用できる接続方式は搭載カーネルによって異なります。古いクライアント向けの説明を現在のmihomoにそのまま当てはめたり、Clash形式のサブスクリプションならすべて同じプロトコルに対応すると考えたりしないでください。

比較項目GUIクライアントmihomo＋systemd
利用環境ログイン中のデスクトップセッションサーバー、ヘッドレス環境
設定方法サブスクリプション・設定・プロキシグループの画面ローカルのYAMLファイル
起動方法デスクトップへのログイン時に自動起動、またはクライアントサービスシステム起動時にサービスを開始
この記事で確認するポートクライアントの実際の表示を確認例では127.0.0.1:7890に固定

インストール前の確認：アーキテクチャ、パッケージ、使用中のポート

まず、以下の3つのコマンドを実行します。1つ目でCPUアーキテクチャ、2つ目でsystemdの有無、3つ目で使用予定のポートを確認します。7890をすでに別のプロセスが使用している場合は、それが別のプロキシカーネルではないか確認してから、停止するかポートを変更してください。

uname -m
systemctl --version
sudo ss -lntup 'sport = :7890'
  • x86_64は通常amd64またはx64のパッケージに対応し、aarch64は通常arm64に対応します。32ビットARMではarm64のバイナリを実行できません。
  • DebianやUbuntu系ではアーキテクチャに合ったDEB、FedoraなどのRPM系ではRPMを選びます。パッケージ形式とCPUアーキテクチャは、それぞれ確認してください。
  • 古いCPUでは、リリースノートに記載された命令セット要件も確認してください。Illegal instructionが表示された場合は、ファイル名のamd64だけで判断せず、ビルドの種類を確認します。
  • AlpineではOpenRCが一般的で、ユーザーランドにmuslが使われることも多いため、この記事のsystemdユニットをそのまま適用することはできません。

クライアントとカーネルは、各プロジェクトの公式リリースから入手してください。この記事では未検証のバージョンを指定していません。導入時にバージョンとアーキテクチャを記録しておくと、後で問題を調べる際に比較できます。カーネルの実際のバージョンはmihomo -vで確認できます。GUIクライアントでは、画面に表示されるバージョンとカーネルのバージョンを両方記録してください。

方法1：Linuxデスクトップ向けGUIクライアント

設定を読み込んでからシステムプロキシを有効にする

Clash Verge RevやFlClashなどはLinux向けのGUIを提供していますが、配布パッケージやシステムとの連携方法はそれぞれ異なります。サイトのダウンロードページで対応プラットフォームや利用条件を比較し、各プロジェクトの手順に従ってインストールしてください。DEBをインストールする場合は、sudo apt install ./ファイル名.debを使えます。ファイル名はダウンロード先にある実際の名前に置き換えてください。説明用の名前をそのままコピーしてはいけません。

  1. クライアントのサブスクリプションまたは設定画面から、サービス提供元のClash/mihomo設定を読み込みます。サブスクリプションURLには認証情報が含まれることが多いため、公開するスクリーンショットやログに載せないでください。
  2. 設定を更新し、ノードとプロキシグループが表示されることを確認します。ノード一覧があるだけでは、DNS、ルール、プロキシグループがすべて正しく設定されているとは限りません。
  3. ルールモードを選び、対象のプロキシグループでノードを選択します。画面に表示されるHTTP、SOCKS、または混合ポートを記録してください。
  4. システムプロキシを有効にし、プロキシルールに確実に一致する宛先へブラウザーからアクセスします。同時に接続履歴で、適用されたルール、プロキシグループ、出口を確認してください。

クライアントによってメニュー構成は異なるため、すべてのソフトに共通する固定のメニュー手順はありません。「設定が有効か」「カーネルが起動しているか」「ポート番号はいくつか」「システムプロキシが設定されたか」の4点を確認してください。トレイアイコンが表示されているだけでは、通信がカーネルを通っているとは限りません。

設定ディレクトリとデスクトップの自動起動

GUIクライアントのデータは、アプリごとのディレクトリとして~/.configや~/.local/shareなどのXDGユーザーディレクトリに保存されることがあります。具体的な場所はアプリによって異なるため、まずクライアントの設定画面で保存先を確認してください。パスを推測して一括削除するのは避けましょう。サブスクリプションのキャッシュ、上書き用ファイル、カーネルが実際に読み込む設定は、別々のファイルである可能性があります。

まず手動で正常に起動することを確認してから、クライアントのログイン時自動起動を有効にします。ログアウトして再ログインし、動作を確認してください。デスクトップの自動起動は通常「ユーザーのログイン後に起動する」という意味であり、誰もログインしていない状態での稼働を保証するものではありません。クライアントに独立したサービスモードがある場合は、専用のインストール手順に従い、同じポートを使うsystemdサービスを重ねて設定しないでください。

方法2：mihomoバイナリと設定ディレクトリを準備する

以下では、TUNに必要なネットワーク管理権限を付与せず、専用の低権限ユーザーで通常のプロキシサービスを実行します。まずアーキテクチャに合った公式アーカイブを入手します。gzip形式の単一ファイルをダウンロードした場合は、ローカルでmihomo.gzに名前を変更し、そのディレクトリで次の操作を行います。

gzip -dk mihomo.gz
file ./mihomo
chmod u+x ./mihomo
./mihomo -v
sudo install -o root -g root -m 0755 ./mihomo /usr/local/bin/mihomo

Exec format errorは、アーキテクチャの不一致や、圧縮ファイルを実行しようとした場合によく発生します。ダウンロードと展開の手順に戻って確認し、実行権限を何度も追加して対処しないでください。次にサービス用アカウントを作成します。同名のアカウントがすでにある場合は、用途を確認してから作業してください。重複して作成したり、権限を安易に変更したりしないでください。

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

準備した完全な設定を作業ディレクトリのconfig.yamlとして保存し、サービス用の設定ディレクトリに配置します。この記事では公開ノードを提供せず、DNSとポートだけの断片を完全なサブスクリプションとして扱うこともありません。設定には、利用するサービスに合ったノードまたはプロバイダー、プロキシグループ、ルールが必要です。

sudo install -o root -g mihomo -m 0640 \
  ./config.yaml /etc/mihomo/config.yaml

完全な設定にある既存の同名フィールドを編集し、YAMLの末尾に同じキーを重複して追加しないでください。ローカルで通常のプロキシを使うための主な項目を以下に示します。単独では動作しない部分的な設定例です。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
tun:
  enable: false

mixed-portを設定すると、同じポートでHTTPとSOCKSのプロキシ接続を受け付けます。この例はローカル利用のみを想定しています。完全な設定でほかの受信ポート、DNSリスナー、コントローラーAPIを有効にしている場合は、それぞれの待ち受けアドレスも確認してください。特にexternal-controllerは、管理上の必要がなければ無効のままにします。有効にする場合はループバックアドレスにバインドし、専用のアクセスキーを設定してください。

この記事では、読み取り専用のメイン設定を/etc/mihomoに、キャッシュ、データベース、実行データを/var/lib/mihomoに配置します。proxy-providersまたはrule-providersを使う場合、更新対象のファイルは、たとえば./providers/main.yamlのように作業ディレクトリ内に保存します。後から読み取り専用にする設定ディレクトリへの書き込みは避けてください。

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

テストに成功しても確認できるのは設定の読み込みだけで、ノードへの接続が保証されるわけではありません。ファイル権限やデータベース不足のエラーが出た場合は、エラー内容に応じてパス、権限、必要なリソースを修正してからサービスを作成してください。

systemdでサービスを管理：起動、自動起動、ログ確認

sudoedit /etc/systemd/system/mihomo.serviceを使って、以下のユニットファイルを作成します。実行ファイル、設定ファイル、作業ディレクトリを明示し、サービスがシステム内のほかの場所へ書き込めないように制限しています。ネットワーク管理権限は付与していないため、設定のTUNを同時に有効化しないでください。

[Unit]
Description=mihomo local proxy service
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=mihomo
Group=mihomo
StateDirectory=mihomo
StateDirectoryMode=0750
WorkingDirectory=/var/lib/mihomo
ExecStart=/usr/local/bin/mihomo -d /var/lib/mihomo -f /etc/mihomo/config.yaml
Restart=on-failure
RestartSec=5s
UMask=0027
NoNewPrivileges=true
PrivateTmp=true
ProtectHome=true
ProtectSystem=strict
ReadWritePaths=/var/lib/mihomo

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable --now mihomo.service
systemctl is-enabled mihomo.service
systemctl is-active mihomo.service
sudo journalctl -u mihomo.service -b -n 80 --no-pager
sudo ss -lntp 'sport = :7890'

enable --nowは、自動起動の設定とサービスの即時起動を同時に行います。enabledは「次回以降に起動する設定か」、activeは「現在動作中か」を示します。待ち受け状態が設定例と一致し、意図しない公開アドレスではなく127.0.0.1:7890になっていることを確認してください。

  • YAMLを変更した場合は、まず設定をテストしてからsudo systemctl restart mihomoを実行します。再起動中はプロキシ接続が一時的に切れます。
  • サービスユニットを変更した場合は、まずsudo systemctl daemon-reloadを実行してからサービスを再起動します。
  • サービスが繰り返し失敗する場合は、ログで最初に発生した具体的なエラーを確認してください。修正後に起動回数の制限に達している場合は、sudo systemctl reset-failed mihomoを実行してから起動します。

network-online.targetは、インターネットやDNS、サブスクリプションサーバーへの接続を保証するものではありません。リモートルールやプロバイダーの更新に失敗した場合は、ネットワーク未接続、URLの無効化、ファイルへの書き込み権限不足を切り分けてください。ログを公開する前に、サブスクリプションURL、キーなどの機密情報を削除してください。

ターミナルのプロキシ環境変数：参照するプロセスだけに適用

サービスを起動しただけでは、すべてのコマンドラインツールが自動的にプロキシを使うわけではありません。まず現在のターミナルでHTTPプロキシを一時的に設定します。HTTPSの宛先にも通常は次のhttp://形式のプロキシアドレスを使い、クライアントがCONNECTでトンネルを確立します。宛先がHTTPSだからといって、プロキシアドレスのプロトコルを変更する必要はありません。

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 20 https://example.com

環境変数を変更せず、1回のリクエストだけにプロキシを指定する方法もあります。以下のコマンドは、HTTPプロキシとSOCKS5プロキシをそれぞれテストします。socks5hのhは、宛先の名前解決をプロキシに任せることを示します。ただし、実際の名前解決経路はカーネルの設定とノードのプロトコルによって異なります。

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

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

設定を永続化する場合、Bashの対話型ターミナルでは~/.bashrc、Zshでは~/.zshrcに記述し、ターミナルを開き直して確認できます。ログインシェル、デスクトップアプリ、systemdサービスでは環境変数の読み込み経路が異なり、Bashの設定ファイルを必ず読み込むとは限りません。小文字の変数名のみを受け付けるツールもあれば、大文字にも対応するツールもあります。各ツールのドキュメントに従って設定してください。

sudoは通常、プロキシ環境変数を引き継ぎません。APTやコンテナ、ほかのサービスでも個別の設定が必要な場合があります。手間を省くために、すべてのプロセスへ適用されるグローバル環境変数にプロキシを設定するのは避けてください。まず単一のコマンドで動作を確認し、必要な範囲だけ永続化します。現在のターミナルの設定を元に戻すには、次を実行します。

unset http_proxy https_proxy all_proxy no_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

TUN、リモートアクセス、よくあるトラブルの注意点

TUNを検討するタイミング

ブラウザーやプロキシ環境変数に対応したツールが正常に動作することを確認したうえで、システムプロキシや環境変数を参照しないアプリがある場合にTUNを検討します。TUNでは仮想ネットワークインターフェース、ルーティング、DNSの制御が関わるため、enableをtrueに変えるだけで、どの環境でも動作するわけではありません。

まずls -l /dev/net/tunで確認します。コンテナではホストから適切なデバイスとネットワーク権限を割り当てる必要があり、VPSによっては制限があります。この記事の低権限サービスにはTUN向けの権限を設定していないため、そのままTUNに使うことはできません。必要な場合は、現在のmihomoのドキュメントを参照し、サービス権限を改めて検討してください。特にネットワーク管理権限、自動ルーティング、DNSリダイレクトの設定に注意が必要です。一般的な解決策としてサービス全体をrootで実行するのは避けてください。

SSHでリモートホストのルーティングを変更する場合は、2つ目のセッションとプロバイダーの管理コンソールを開いたままにし、ロールバック方法も用意してください。TUNの自動ルーティングや厳格なルーティングにより、管理接続が切れる可能性があります。接続パネルに記録があってもDNSが制御されているとは限りません。アプリ独自の暗号化DNSも別途確認してください。

リモートマシンからローカル待ち受けを安全に使う方法

自分のPCからサーバー上のプロキシを使うだけなら、7890をインターネットに直接公開する必要はありません。SSHのローカルポートフォワードを作成します。ssh -L 17890:127.0.0.1:7890の後ろに、通常サーバーへのログインに使う接続先を指定してください。その後、ローカルのアプリから127.0.0.1:17890へ接続します。サーバー側のノード、ルール、ネットワークが正常であることは別途必要です。

複数の条件を同時に変えず、症状から原因を切り分ける

  • Connection refused：まずサービスの状態と待ち受けポートを確認します。この段階では、リクエストがルール判定まで届いていないことがほとんどです。
  • サービスは動作しているがリクエストがタイムアウトする：プロバイダーの更新状況、選択中のノード、宛先に適用されるルール、サーバーの外向き通信を確認します。すぐにクライアントを再インストールする必要はありません。
  • ターミナルでは使えるがブラウザーでは使えない：ブラウザーとデスクトップのプロキシ設定を確認してください。環境変数を設定しても、起動済みのブラウザーの通信設定は自動的に変わりません。
  • ブラウザーでは使えるがターミナルでは使えない：現在のシェルの環境変数、ツールのプロキシ対応、sudoによる環境変数の除去を確認してください。
  • 再起動後に動かない：デスクトップへのログイン時の自動起動と、システム起動時のサービスを区別します。systemctl is-enabled mihomoを実行し、今回の起動ログも確認してください。

最後に3点を確認します。再起動後にサービスが起動すること、7890が想定したアドレスだけで待ち受けていること、プロキシルールに確実に一致するリクエストが接続履歴で対応するノードに記録されていることです。実際のカーネルバージョンとあわせて記録しておけば、アップグレードや移行後も同じ条件で確認できます。設定の基本は入門ガイド、DNSやルールの仕組みはリファレンスをご覧ください。

Clash最新版をダウンロード