この記事で分かること

Linux のデスクトップ環境では、Clash Meta 系の実体として広く使われている mihomo を、グラフィカルなクライアント経由で操作する構成と、コア単体をバックグラウンドで動かしておく構成が共存します。後者を systemd に載せておくと、再起動直後やログイン前でもローカルプロキシポートが立ち上がった状態を保ちやすく、ブラウザやターミナルから一貫して同じ upstream に向けられます。

本記事は Debian や Ubuntu を代表とする systemd 採用ディストリビューションを前提に、パッケージや AppImage など入手形態の差を踏まえつつ、「デスクトップで快適に触る」と「常駐して切れない」を両立するための考え方をまとめます。設定ファイルの書き方そのものはYAML・ルール分流の解説やClash Meta への移行ガイドとあわせて参照すると理解が早くなります。

なぜ Linux では systemd 常駐が効くのか

多くの GUI クライアントは、起動中のみコアプロセスを子プロセスとして抱え、ウィンドウを閉じると一緒に止まる設計になっていることがあります。セッション終了や再起動のたびに手動でアイコンを押し直す運用は、すぐに負担になります。systemd にユニットを定義しておけば、ネットワークスタックの準備後に自動で mihomo を起動し、異常終了時は一定間隔で再起動する、といった運用が標準化されます。

ユーザーユニット（ログインユーザー向け）にするか、システムユニット（全ユーザー共通）にするかで権限モデルと設定ディレクトリが変わる点には注意が必要です。後述の例はあくまで一般的な雛形であり、実際のバイナリパスや設定ディレクトリは自分の環境に合わせて置き換えてください。

導入経路：GUI と単体バイナリ

mihomo コア単体を配布物から取り出し、/usr/local/bin などに配置する方法もあれば、mihomo を同梱したデスクトップクライアントを一括で入れる方法もあります。実行ファイルの入手は、信頼できる配布元から行い、当サイトのクライアントダウンロードページで自分のアーキテクチャに合ったビルドを選ぶと、GUI とコアの対応関係を把握しやすくなります。オープンソースのリポジトリは仕様確認やライセンス理解に有用ですが、日々のインストール導線は公式配布ページに寄せておくと更新時の迷いが減ります。

ディストリビューションのパッケージマネージャに同名パッケージがある場合でも、バージョンが古いことがあるため、必要なプロトコルやルールセット形式に合わせてビルドを選びます。導入後は mihomo -v などで実際に動いているバージョンを確認し、GUI が別バイナリを呼んでいないか（重複起動になっていないか）も併せて見ます。

設定ディレクトリと権限

典型的にはホーム配下の ~/.config/mihomo や ~/.config/clash に config.yaml を置きます。TUN モードや特定のポートバインドを使う場合、cap_net_bind_service やネットワーク名前空間まわりの権限が絡むことがあり、そのときは公式ドキュメントに沿って capability を付与するか、ルートレスで動くポート番号に寄せるかを検討します。

システムワイドに /etc/mihomo のような場所へ置く運用にすると、複数ユーザーで共有したいサーバー向けには向きますが、デスクトップ個人利用ではホーム配下の方がバックアップや権限管理が単純です。以降の systemd 例では、ホーム配下のディレクトリを想定したコマンドラインを示します。

systemd ユーザーユニットの例

ログイン後にだけコアを立ち上げたい場合はユーザーサービスが扱いやすいです。ユニットファイルは ~/.config/systemd/user/mihomo.service に置き、systemctl --user daemon-reload のあと systemctl --user enable --now mihomo.service で有効化します。再起動後もユーザーサービスを自動で動かすには、管理者権限で loginctl enable-linger <ユーザー名> を実行し、ログインセッションが無い時間帯でもユーザーユニットが起動できるようにしておく方法があります。

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

[Service]
Type=simple
ExecStart=%h/.local/bin/mihomo -d %h/.config/mihomo
Restart=on-failure
RestartSec=3

[Install]
WantedBy=default.target

ExecStart のパスは環境に合わせて変更してください。%h はホームディレクトリに展開されます。ネットワーク待ちが厳密に不要な環境では After を緩めても構いませんが、Wi-Fi 認証後に起動したい場合は NetworkManager 連携のユニットに依存させるなど、自分の接続手順に合わせて調整します。

システムユニットにする場合の注意

全ユーザーで同じコアを共有したい、またはログイン前から確実にポートを開けておきたい場合は /etc/systemd/system/mihomo.service のようなシステムユニットを使います。このとき実行ユーザーとグループを User= / Group= で明示し、設定ディレクトリの所有者と一致させます。ルートで動かすと設定ミス時の影響範囲が広がるため、非特権ユーザーで listen できるポート設計に寄せるのが無難です。

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

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

[Install]
WantedBy=multi-user.target

デスクトップ GUI との役割分担

Clash Verge 系の Linux 版のように、mihomo を内蔵した GUI を使う場合でも、裏側のコアを systemd 側に任せ、GUI はプロファイル編集やログ閲覧、ノード選択に専念させる構成が取れます。その場合、GUI の「外部コアを指定する」オプションがあればローカルのソケットや管理 API に接続する設定を確認し、無ければ GUI 起動時の自動起動だけをオフにして競合を避けます。

逆に、GUI にすべて任せる運用で十分なら systemd は必須ではありません。ただしセッションの都合でプロセスが落ちやすい環境では、やはりデーモン化した方が「再起動したらプロキシが死んでいた」という事象を減らせます。用途に応じてシンプルな方を選んで構いません。

TUN・DNS・ファイアウォール

Linux で TUN を有効にすると、他の VPN クライアントや nftables のルールと競合することがあります。ルーティングテーブルが意図せず書き換わると「ブラウザだけ直結する」などの部分不整合が出るため、有効化直後は ip route とコアのログを併せて確認します。DNS まわりは Fake-IP 設定と併せて挙動が変わるため、詳細は前述の YAML 解説を参照してください。

トラブルシューティング早見表

再起動後にだけ症状が出る場合は、まず systemd の状態とジャーナルを確認します。

まとめ

Linux デスクトップで Clash Meta（mihomo）を本気で運用するとき、GUI の有無にかかわらず「コアを systemd に載せる」ことで、再起動後の手戻りを大きく減らせます。ユーザーユニットかシステムユニットか、設定ディレクトリをどこに置くか、GUI と二重起動しないか、その三点を押さえれば運用はかなり安定します。

ビルドの選び方や初回セットアップを短く済ませたい場合は、クライアントのダウンロードページから自分の環境向けパッケージを入手し、YAML の細部は別記事で詰めていく流れがおすすめです。オープンソースの情報は開発者向けの参考として活かしつつ、日々のインストールと更新は配布元の整合性が取れた導線に寄せておくと安全です。→ 無料で Clash をダウンロードし、快適な接続体験を試す