Linux ヘッドレスで Clash Meta：systemd 常駐と自動起動

こんなとき読む記事：ヘッドレス Linux の前提

Clash Meta（コミュニティでは Mihomo コアとも呼ばれる実装）は、もともと単体バイナリとして動かせるプロキシ／ルールエンジンです。Windows や macOS では Clash Verge Rev のような GUI が前面に出ますが、VPS や自宅サーバ、CI ランナーのように 画面の無い Linux では「インストーラーをクリックする」という体験自体がありません。そこで必要になるのが、実行ファイルの配置、設定ファイルのパスを固定すること、そして systemd による常駐と 起動時の自動起動、クラッシュ後の再起動 です。

本記事は Linux ヘッドレス における Clash Meta Linux 運用を、デスクトップ向け手順とは切り離して整理します。対象読者は「SSH だけで済ませたい」「journalctl でログを追いたい」「購読 URL や config.yaml を自分で管理する」という方です。関連トピックの索引はブログ一覧からも辿れます。

ℹ️

用語：本記事の「ヘッドレス」とは、X11 や Wayland のデスクトップセッションを前提にしないサーバ型 OS の構成を指します。コンテナ内で動かす場合も近いですが、cgroup やネットワーク名前空間の制約が追加されるため、ユニットの CapabilityBoundingSet や AmbientCapabilities は別途設計が必要になることがあります。

なぜ screen ではなく systemd なのか

screen や tmux の中で手動起動し続ける方法もありますが、サーバー再起動 のたびにセッションが消え、プロセス異常終了 の検知も自前になります。systemd を使うと、systemctl enable --now によって ブート時に同じコマンドが再実行 され、Restart=on-failure などで 予期しない終了コード のあとに自動復帰を掛けられます。さらに標準出力は journal に集約されるため、ファイルログを自前でローテーションしなくても、運用開始当初の切り分けが速くなります。

一方で、systemd は ユニットファイルの記述ミス がそのまま「起動しない」「高速リスタートループ」に直結します。ExecStart の引数、作業ディレクトリ、実行ユーザー、環境変数を明示しておくほど、後から同じサーバを触る人間にとって安全です。

ステップ 1：ディレクトリと実行ユーザーを決める

運用で揉めやすいのは「設定がどこにあるか分からない」ことです。例として次のようなレイアウトが読みやすく、バックアップも取りやすいです（パスは一例です）。

/opt/clash-meta/ … 実行バイナリ（例：mihomo）を置く
/etc/clash-meta/ … config.yaml、ルールのローカルコピー、Geo データなどを置く
/var/lib/clash-meta/ … キャッシュや実行時に書き換わるファイル用（書き込み権限をここに寄せる）

ルートで動かす構成は手早いですが、万が一の リモート制御 API 露出や設定ミス時の影響範囲が広がります。可能なら 専用の非特権ユーザー（例：clash-meta）を作り、そのホームまたは /var/lib 以下に書き込み可能領域を限定するのが無難です。Linux 全体のセキュリティ境界はディストリビューションのガイドに従ってください。

ステップ 2：公式リリースからバイナリを配置する

上流では Mihomo の GitHub Releases などから、自分の CPU アーキテクチャ向けの圧縮パッケージを取得するのが一般的です。ファイル名はリリースごとに変わるため、ここでは手順だけ示します。取得後、実行ビットを付与し、/opt/clash-meta/mihomo のように単一パスへ揃えると、ユニットの ExecStart が短く保てます。

sudo install -o root -g root -m 0755 mihomo /opt/clash-meta/mihomo

バージョン確認は /opt/clash-meta/mihomo -v のように対話シェルで一度叩くと確実です。パッケージマネージャに公式パッケージが無い場合でも、この「単体バイナリ＋設定」モデルが GUI の無い Linux 運用では扱いやすい強みになります。GUI 前提の導入記事と併せて読むなら、コアの位置づけは Clash Meta アップグレードガイドが補助線になります。

✅

ヒント：リリース差し替え時は、まず別名で置き、動作確認後にシンボリックリンクを付け替えるとダウンタイムを短くできます。systemd の ExecStart はシンボリックリンク先を解決して実行されるため、運用ポリシーに合わせて選んでください。

ステップ 3：config.yaml のパスを固定する

ヘッドレスでは「どのディレクトリをカレントにして起動したか」で相対パスの解決結果が変わります。-d や -f のサポート状況はバージョンで差があるため、手元の mihomo -h を必ず確認してください。典型的には 設定ディレクトリ を一つ指定し、その中の config.yaml を読ませます。

購読やプロバイダの URL を config.yaml に直書きする運用では、ファイル権限を厳しめにしておく価値があります。インポートや更新間隔の考え方は購読インポートの解説と思想が共通です。ルールや DNS の詳細は用途次第ですが、サーバ用途では fake-ip と systemd-resolved の組み合わせ など、ホスト全体の名前解決に影響する項目に注意が必要です。

ステップ 4：systemd ユニットファイルの例

以下は 実測の雛形 です。ユーザー名・パス・引数は環境に合わせて置き換えてください。コメントはユニット側ではなく、ここでは文章で補足します。

[Unit]
Description=Clash Meta (Mihomo) proxy
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=clash-meta
Group=clash-meta
WorkingDirectory=/etc/clash-meta
ExecStart=/opt/clash-meta/mihomo -d /etc/clash-meta
Restart=on-failure
RestartSec=3
LimitNOFILE=1048576

NoNewPrivileges=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Restart=on-failure は終了コードが失敗扱いのときに効きます。設定ファイルの文法エラーで即終了するタイプの失敗が続く場合、リスタートループ になるので、初回導入時は Restart=no で挙動を確認してから切り替えると安全です。LimitNOFILE は大量接続を扱うほど効いてくることがありますが、テナントの ulimit ポリシーに依存します。

ステップ 5：有効化・起動と疎通確認

ユニットを /etc/systemd/system/clash-meta.service などに保存し、systemctl daemon-reload のあと、次で有効化します。

sudo systemctl enable --now clash-meta.service
systemctl status clash-meta.service --no-pager

active (running) が確認できたら、設定で開いている mixed-port や HTTP ポート に対して、同じホスト上から curl でプロキシ経由の取得テストを行います。別マシンから叩く場合は、バインドアドレスが 127.0.0.1 だけになっていないか、ファイアウォール で意図しないゾーンに穴が開いていないかを必ず確認してください。

ステップ 6：journalctl でログを追う

systemd 管理下では、標準出力・標準エラーが journal に流れます。直近だけなら次のようにします。

journalctl -u clash-meta.service -e --no-pager
journalctl -u clash-meta.service -f

長期保存が必要なら journald の永続化設定 や、別途ファイルロガーへ転送する仕組みを検討します。トラブルシュートでは、起動直後の「設定読み込みエラー」「DNS モジュールの警告」「ルールプロバイダ取得失敗」あたりが典型です。アプリ横断でトラフィックを取り込みたい場合は、デスクトップ向けとは前提が異なるため、TUN モード解説を読み替えたうえで、サーバ用途ではカーネルモジュールや権限の要件を別途確認してください。

external-controller とセキュリティ境界

external-controller（REST 風 API）を有効にすると、ダッシュボードや自動化からルールセットや接続状況を操作できます。ヘッドレスでは「SSH トンネルでだけ触る」「VPC 内の管理ネットワークにだけバインドする」など、到達可能範囲を最小化 する設計が重要です。0.0.0.0 に晒したまま認証を弱くすると、第三者に設定を読まれるリスクが跳ね上がります。

秘密トークンや購読 URL は設定ファイルとバックアップ媒体の両方で漏洩経路になります。個人用ワークステーション向けの「ダウンロードしてクリック」体験とは責任分界が異なるため、サーバー運用の情報セキュリティ規程 に照らしてから有効化してください。

⚠️

注意：本記事は一般的な技術説明です。所属組織やクラウド事業者の利用規約、輸出管理、ローカル法域の要求に反する構成は取らないでください。プロキシの用途は自己責任の範囲で正当な目的に限定してください。

デスクトップクライアントとの役割分担

ローカル PC では GUI がポート表示や購読更新、システムプロキシの切り替えを肩代わりします。一方 Linux サーバー では、その多くを 設定ファイル編集 と systemctl、必要なら ansible などの IaC に置き換えます。開発用ノート PC で慣れたワークフローをそのまま VPS に持ち込むと、ログの見方や権限まわりで齟齬が出やすいので、「どこまでをコアに任せ、どこからをホスト側のネットワーク設計に書くか」を文章化しておくとチーム運用が楽です。

ワークステーション側で快適に使うためのクライアント入手は、OS ごとのパッケージをまとめたダウンロードページから選ぶのが分かりやすい一方、本記事の対象は「データセンタ内の 常駐プロセス」です。用途が違えば選ぶ成果物も違う、という整理だけははっきりさせておくと迷いが減ります。

まとめ：パス・ユーザー・ユニットを三点セットで固定する

Linux ヘッドレス で Clash Meta を運用するときの要点は次の三点です。第一に、バイナリと設定と書き込み先 のパスを決め、人間が SSH で迷子にならないこと。第二に、systemd で 起動時自動起動 と 失敗時再起動 を明示し、挙動を status と journalctl で追えること。第三に、external-controller やプロキシポートの 露出面 を必要最小限に抑え、サーバとしてのセキュリティ境界を守ることです。

コア単体の強みは、GUI が無い環境でも同じ思想で積み上げられることにあります。日常の PC では引き続き完成度の高いクライアントを使い、サーバ側は本記事のように薄く堅く載せる──役割分担がはっきりすると、トラブル時の切り分けも速くなります。

→ 無料で Clash をダウンロードし、快適な接続体験を試す