Ubuntu に Clash Meta を deb で導入し、systemd で常駐・ブート時自動起動・異常時再起動まで

1. なぜ systemd で管理するか

Clash Meta は常駐デーモンとして動かす前提のソフトウェアです。手元のシェルでフォアグラウンド起動したままでは、ターミナルを閉じた瞬間に落ちたり、再起動後に忘れて通信が止まったりします。Ubuntu では systemd が標準のサービスマネージャなので、ブート時の自動起動、異常終了からの自動復帰、ログの一元閲覧（journal）までを同じ枠組みで扱えます。Docker や screen/tmux に載せる手もありますが、サーバー用途では systemd が最も追いやすく、障害時の切り分けもしやすいです。

なお本稿は一般ユーザーが自機で利用するための構成例です。職場や学校の機器ではポリシー上プロキシやトンネルが禁止されている場合があります。導入前に規約と法令を確認してください。

2. 前提：バージョン・権限・ディレクトリの考え方

対象は Ubuntu 22.04 / 24.04 系の amd64を想定します（ARM 端末はパッケージ名が異なることがあります）。管理者権限が必要な操作は sudo で行います。設定とランタイムファイルを置く場所は人によって /etc/clash、/etc/mihomo、ホーム直下などに分かれますが、systemd から読み書きするユーザーとパーミッションを揃えることが重要です。以降の例では専用ユーザー clash とディレクトリ /etc/clash-meta を使う構成にします（お好みでパスは読み替えてください）。

購読 URL や config.yaml の書き方の基礎は、当サイトの サブスクリプション導入ガイドと併読するとスムーズです。ルールの評価順や MATCH の落ちどころは ルールルーティング解説の考え方と共通です。

3. deb の入手とインストール

クライアントの入手先は当サイトのダウンロードページを第一候補にし、そこから Linux 向けビルドやリンクを辿る運用が分かりやすいです（インストールパッケージの取得は ダウンロードページから）。一方で、コア単体の .deb は配布形態がリリースごとに変わるため、実際のファイル名は取得時点のリリースノートを確認してください。ダウンロード後は例えば次のようにインストールします（ファイル名は読み替え）。

# Example: install downloaded .deb
sudo dpkg -i ./mihomo-linux-amd64-*.deb
sudo apt-get install -f -y

依存関係で失敗した場合は apt-get install -f がよく効きます。バイナリの実体が /usr/local/bin に入るか、/usr/bin に入るかはパッケージ次第です。which clash-meta や dpkg -L パッケージ名で実パスを確認してから systemd の ExecStart= に書いてください。

オープンソースのビルドや Issue を参照したい場合は、ソース・ライセンス確認用に GitHub を開くのは問題ありません。ただし日々のインストール導線はダウンロードページを主にし、リリース直リンクだけに頼るとファイル名変更で手順がすぐ古くなる点には注意してください。

4. 設定ファイルと作業ディレクトリ

典型的には config.yaml を配置し、そのディレクトリに -d で作業ディレクトリを指定します。mihomo 系では実行ユーザーの書き込み権限が必要なファイル（キャッシュや GeoIP、実行時生成物）があるため、ディレクトリ所有者をサービスユーザーに合わせるのが安全です。例としてルート配下にまとめる場合は次のような準備になります。

sudo mkdir -p /etc/clash-meta
sudo cp /path/to/your/config.yaml /etc/clash-meta/config.yaml
sudo useradd --system --home /etc/clash-meta --shell /usr/sbin/nologin clash 2>/dev/null || true
sudo chown -R clash:clash /etc/clash-meta

TUN モードや特定のキャパビリティを使う構成では、公式ドキュメントに沿った追加の権限付与が必要になることがあります。最小権限で始め、必要になった段階で拡張するのがおすすめです。DNS や fake-ip を有効にする場合は TUN モードの解説も参照してください。

5. 手動起動で動作確認

systemd に載せる前に、同じユーザー・同じ引数で手動起動が成功するかを確認します。例ではバイナリ名を clash-meta と仮定しています。

sudo -u clash -H /usr/local/bin/clash-meta -d /etc/clash-meta

ログにエラーが出ず、ローカルの HTTP/SOCKS ポートに接続できることを確認してから次へ進みます。ここで失敗しているのにユニットだけ整えても、同じ失敗が繰り返されるだけです。設定の文法エラー、ポート競合、購読取得失敗はこの段階で潰すのが早道です。

6. systemd ユニットの例

/etc/systemd/system/clash-meta.service を作成します。バイナリパスと -d は環境に合わせて必ず置き換えてください。

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

[Service]
Type=simple
User=clash
Group=clash
ExecStart=/usr/local/bin/clash-meta -d /etc/clash-meta
Restart=on-failure
RestartSec=3
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

network-online.target は「NIC が実際に使える」保証ではありませんが、ブート直後の極端なレースを少し減らす目的でよく書かれます。クラウド VM ではクラウド側のメタデータ取得タイミングも絡むため、失敗ログが出る場合は RestartSec を少し長くする・起動後に手動で systemctl restart する、といった運用も検討ください。

7. 有効化・自動起動・ログ確認

ユニットを読み込み、起動と自動起動を有効にします。

sudo systemctl daemon-reload
sudo systemctl enable --now clash-meta.service
sudo systemctl status clash-meta.service

ログは journalctl で追うのが簡単です。起動直後だけなら -b、フォローなら -f を付けます。

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

設定を変えたあとはユニットの再読み込みが必要か、コアが SIGHUP で再読み込みできるかを確認してください。mihomo のバージョンによっては API 経由のリロードが推奨されることもあります。運用が固まったら systemctl cat clash-meta.service で実際に効いている内容を控えておくと、再現性が上がります。

8. 異常終了時の再起動ポリシー

Restart=on-failure は終了コードが失敗のときだけ再起動する挙動です。設定ミスで毎秒クラッシュするループに入った場合、すぐに journal が埋まるので、RestartSec を空けつつ、原因修正まで systemctl stop で止めるのが礼儀です。常に立ち上げ直したい場合は Restart=always も選べますが、意図しない無限再起動に注意が必要です。

OOM やディスク枯渇で落ちるケースでは、そもそもマシン側のリソースを先に直す必要があります。プロキシが再起動しても通信が戻らないときは、Clash 以外のレイヤ（DNS、ルーティング、ファイアウォール）を疑うと切り分けが進みます。

9. デスクトップのプロキシ設定（任意）

コアだけ起動していても、ブラウザや各アプリがプロキシを知らなければトラフィックは流れません。GNOME なら設定アプリのネットワーク／プロキシ、ターミナルなら環境変数 http_proxy / https_proxy、ターミナル以外のアプリは各自の設定画面、という具合にレイヤが分かれます。TUN モードで全トラフィックを掴む構成にするとアプリ個別設定は減りますが、権限やカーネルモジュールの要件が上がるので、まずはルールとポート転送で十分かどうかを判断するとよいです。

PC クライアント全般の選び方や移行の話は CFW 代替・移行ガイドとも補完関係にあります。Linux では GUI 版とコア単体運用を併用する人も多いので、自分の作業スタイルに合わせて選んでください。

10. よくあるつまずき

ポートが既に使われている：別プロセスや以前の手動起動が残っていないか ss -lntp で確認します。権限エラー：clash ユーザーが設定ディレクトリに書けない、バイナリに実行権がない、などを namei -l で追います。DNS だけおかしい：設定の DNS セクションと、OS の systemd-resolved や /etc/resolv.conf の関係を整理します。

アップデート後に起動しない：パッケージ更新でバイナリパスやデフォルトの作業ディレクトリが変わった可能性があります。リリースノートと dpkg -L で差分を確認し、ユニットの ExecStart= を合わせます。

11. まとめ

Ubuntu では deb で Clash Meta を導入し、専用ユーザーとディレクトリを決めたうえで systemd に載せるのが、常駐と再起動の両面で扱いやすい型です。手動起動で成功を確認してからユニット化し、journalctl でログを追い、失敗時は Restart と設定修正のバランスを取る、という順序を守ると迷子になりにくいです。

同じエコシステムでもクライアントの形態は多様ですが、ルールと購読の考え方は共通です。GUI 派はデスクトップ向けビルド、サーバー派はコア＋systemd、という住み分けで構いません。

まずは公式の入手経路から自分の環境に合うパッケージを選び、購読を取り込んだうえでポートとログを確認するのが確実です。Windows や他 OS のビルドも含め、 → 無料で Clash をダウンロードし、快適な接続体験を試す から環境にあったクライアントを選べます。