こんな方むけ
Windows の TUN 周りや macOS のシステム拡張、Android の VPN モードなど、GUI クライアント前提の記事はそろいつつあります。一方で、自宅サーバーやリモートの Linux マシン、あるいはデスクトップで「コアだけ」静かに常駐させたい場合、ターミナルから手動起動しているとセッションを閉じた瞬間に止まったり、再起動後に忘れて通信が詰まったりしがちです。
本記事では、Mihomo（Clash Meta コア）を systemd のサービスとして登録し、ブート時の自動起動とクラッシュ後の自動復帰までを、設定ファイルの置き場所やログの見方、購読更新とのつなぎ方まで含めて整理します。Windows やスマホ向け GUI と同じ「裏でずっと動く」体験を、Linux でも再現するための実務寄りの手順です。
なぜ systemd なのか
Linux でプロセスを常駐させる手段は複数ありますが、主要ディストリビューションでは systemd が標準です。依存関係の解決（ネットワークが上がってから起動する等）、ログの一元化（journalctl）、失敗時の再起動ポリシー、ユーザー単位とシステム単位の両方のユニットといった機能が揃っており、運用の再現性が高いのが利点です。
手動の nohup や screen／tmux でも「とりあえず動かす」ことはできますが、再起動後の手当てや失敗検知は自分でスクリプトを足す必要が出ます。本稿のゴールは、一度整えればメンテしやすい状態に置くことです。用語の整理や全体像は ドキュメント も併せて参照してください。
準備：バイナリと設定の所在を決める
ユニットを書く前に、次の 3 点をはっきりさせます。（1）Mihomo 実行ファイルのフルパス、（2）設定ディレクトリまたは単一 YAML のパス、（3）そのディレクトリに対する実行ユーザーの読み書き権限です。パッケージで入れた場合と、GitHub Release から取った単体バイナリを /usr/local/bin に置いた場合でパスが変わるため、which mihomo や実際に動いているコマンドラインをメモしておくと安全です。
起動引数は環境によりますが、代表的には設定ディレクトリを -d で渡すか、単一ファイルを -f で渡します。ルールの外部ファイル化や購読キャッシュは ルールプロバイダー上級ガイド の考え方と相性がよく、常駐サービスにしておくとバックグラウンドでの更新と組み合わせやすくなります。
ユニットファイルの例（システムサービス）
管理者権限で全ユーザー向けに動かすなら /etc/systemd/system/mihomo.service のような名前で保存します。以下はあくまで雛形です。パスとユーザー名は環境に合わせて置き換えてください。
[Unit]
Description=Mihomo (Clash Meta) daemon
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=mihomo
Group=mihomo
WorkingDirectory=/etc/mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5s
LimitNOFILE=1048576
[Install]
WantedBy=multi-user.targetAfter=network-online.target は、ブート直後に DNS やルートが未整備のまま起動して購読取得に失敗するのを減らすための定番です。厳密な挙動はディストリビューションやネットワーク管理（NetworkManager、systemd-networkd 等）に依存するため、一度 journalctl で起動直後のログを眺め、必要なら遅延起動用のタイマーユニットを別途足す判断もできます。
Restart=on-failure は、設定ミスなどで異常終了したときに限り再起動します。常に立ち上げ直したい実験環境では Restart=always も選択肢ですが、YAML が壊れていると無限にループしログが埋まるので、本番寄りなら on-failure から始めるのが無難です。RestartSec で間隔を空けると、上流の一時障害とぶつかったときのスパイラルを避けやすくなります。
ユーザー単位で動かす場合
デスクトップで自分のホーム以下に設定を置きたい場合は、~/.config/systemd/user/mihomo.service に同様の内容を置き、User= 行は省略します（そのユーザーのコンテキストで動きます）。有効化は systemctl --user enable --now mihomo.service、ログイン時にユーザーサービスを立ち上げるには loginctl enable-linger <ユーザー名> が必要になるケースがあります。サーバー用途ならシステムユニットの方が単純なことが多いです。
有効化・起動・状態確認
ファイルを保存したら sudo systemctl daemon-reload を実行し、sudo systemctl enable --now mihomo.service で有効化と即時起動をまとめて行えます。状態は systemctl status mihomo.service、直近のログは journalctl -u mihomo.service -e で確認できます。設定を直したあとは sudo systemctl restart mihomo.service が手早いです。
通信がおかしいときは、GUI が無い分ログが頼りの UIになります。ポートの取り違えや dial tcp のタイムアウト切り分けは、既存の ログ診断ガイド とそのまま相性がよく、常駐化したあとも同じ視点で追えます。
ログをファイルに残すか、journal に任せるか
systemd では標準出力・標準エラーが journal に集約されるのが普通です。長期保存や外部のログ集約基盤へ送る必要がある場合は、ユニットに StandardOutput=append:/var/log/mihomo.log のような行を足す方法もありますが、ローテーションやパーミッション設計が別途必要になる点に注意してください。調査中だけ一時的に log-level を上げ、落ち着いたら戻す、という運用はデスクトップ版と同じく有効です。
購読更新と設定リロードをつなぐ
常駐させたあとも、購読 URL からの定期更新は別プロセス（cron、独自スクリプト、上流が配る更新ツール）で行う構成が一般的です。更新後にコアへ反映するには、プロセス再起動か、外部コントローラの API でリロードのどちらかです。API を使う場合は設定で external-controller を有効にし、適切な認証（シークレットやバインドアドレスの制限）を必ず組み合わせてください。ローカルループバック限定にし、不要なら公開しないのが基本です。
更新のたびにフル再起動すると一瞬切断が出ることがあるため、運用要件に応じて API リロードを選ぶ判断になります。いずれにせよ、「更新 → 反映 → ログで成功確認」の一連をスクリプト化しておくと、ヘッドレス環境での手戻りが減ります。
TUN モードと権限の注意（短く）
Linux で TUN／ルーティングをコア側に任せる構成は、ディストリビューションやカーネル設定、Capability の付与状況によって要件が変わります。非特権ユーザーで動かしつつ TUN を触るには追加の capability やポリシーが必要になることがあり、難しければ「プロキシポートだけ提供し、ルーティングは別手段で扱う」設計も現実的です。詳細は自環境のドキュメントと upstream の README を優先し、無理な特権付与は避けてください。
ファイル権限と攻撃面
設定にプロキシの URL やトークンが含まれる場合、ユニットで動かすユーザーを専用に分け、ディレクトリのパーミッションを絞るのがおすすめです。実行バイナリは可能なら配布元のチェックサムで検証し、自動更新スクリプトを入れるなら取得元の固定と失敗時のロールバック方針まで決めておくと安心です。
まとめ
Linux で Mihomo を「常にそこにある基盤」として扱うには、systemd によるサービス化が最もメンテしやすい選択肢のひとつです。ネットワーク待ち合わせ、失敗時の再起動、ログの追跡、購読更新後の反映までを一つの運用ストーリーとして設計すると、デスクトップの手動起動に比べてトラブル時の切り分けが格段に楽になります。
GUI 付きクライアントを使う環境では画面操作で済む部分も多いですが、サーバーや自動化シナリオではコア＋systemd の組み合わせが効きます。バイナリの入手元やライセンス、Issue へのフィードバックは Mihomo の GitHub リポジトリ が参照先になります。一方で、日々のクライアント導入や更新は検証済みのパッケージがまとまった公式導線に寄せた方が、試行錯誤のループを短くしやすいです。関連記事は 技術ブログの一覧 から辿れます。→ Clash を無料ダウンロードして、手元の環境で常駐構成を試す