Linux で「CLI + systemd」が選ばれる理由

Windows や macOS ではグラフィカルクライアントが主流ですが、Linux デスクトップではターミナルから直接コアを起動し、プロセスを systemd に任せる構成がよく取られます。理由は単純で、ディストリビューションごとにパッケージングが分かれ、GUI の見た目よりも再現性のある配置とログが重視されるからです。Clash Meta（コミュニティでは実行ファイル名から Mihomo と呼ばれることも多い）コアは単一バイナリで動くため、ホームディレクトリ配下や /opt などに置き、-d で設定ディレクトリを指定するだけで起動できます。

本稿のゴールは「Ubuntu または Debian 系で、Clash Meta Ubuntu 環境として安定したLinux プロキシクライアントを常駐させ、かつsystemd による起動時の自動起動（ブート後も同じ設定で立ち上がる状態）を得ることです。すでに Windows・macOS・Android の記事でクライアント操作に慣れている方は、同じ YAML の思想をそのまま持ち込めますが、Linux ではファイル権限・ユーザーデーモン・ネットワーク名前空間といった OS 固有のレイヤーが前面に出ます。

事前確認：アーキテクチャと権限の整理

まず端末の CPU アーキテクチャを確認し、リリース資産の linux-amd64 か linux-arm64 かを取り違えないようにします。デスクトップの大半は amd64 ですが、ARM 機では arm64 を選ぶ必要があります。次に、後述する TUN モード（Linux ではカーネルの仮想インタフェースを用いてトラフィックを拾うイメージ）を有効にするかどうかを決めます。TUN を使う場合は CAP_NET_ADMIN などの権限が絡み、バイナリにファイル能力を付与するか、一時的に高権限で動かすか、あるいは専用のラッパーを使うかの設計が必要になります。

ここで迷った場合は、まずは HTTP／SOCKS のプロキシポートだけを立ち上げ、ブラウザやシェル環境変数（ALL_PROXY など）で利用する構成から始め、動作が安定してから TUN へ移行すると切り分けが楽です。TUN モードの概念自体は、当ブログのClash TUN モード詳解で OS 非依存の観点から整理しています。Linux 固有の権限まわりは本稿の後半で再度触れます。

バイナリの配置と実行権限

実際のファイル名はビルドや配布元に依存しますが、多くの場合は mihomo という名前の実行ファイルが提供されます。ホームディレクトリ配下に ~/clash-meta のようなディレクトリを作成し、そこにバイナリを置く方法が手軽です。システム全体で共有するなら /opt/clash-meta を掘り、所有者を自分のユーザーに合わせます。

ダウンロードした後は必ず chmod +x で実行ビットを付与し、ターミナルから直接起動してみます。初回は -d オプションで設定ディレクトリを明示し、その中に config.yaml が存在することを確認してください。設定ファイルの基本構造やコアの位置づけについては、Clash Meta 移行ガイドで触れている通り、YAML セマンティクスは他プラットフォームと共通です。違うのは「どのディレクトリを作業ディレクトリとして扱うか」だけ、と捉えると移行が速いです。

パッケージの入手については、検証済みのクライアント一覧と導線を当サイトのダウンロードページにまとめています。ソースコードや Issue を追う用途では各プロジェクトの GitHub が有用ですが、初めてインストールする実行ファイルの第一入手先はサイト側の導線に寄せると、CPU アーキテクチャの取り違えや古いリリースの踏み間違いを減らせます。

設定ディレクトリと config.yaml

-d で渡したディレクトリは、実行時のカレントではなく設定ルートとして扱われます。ここに config.yaml を置き、ルールセットやプロバイダのキャッシュが必要なら同階層またはサブディレクトリに展開します。相対パスで rule-providers や proxy-providers を参照している場合、実際の作業ディレクトリがどこになるかで解決に失敗することがあるため、起動ログに出るパスを一度丁寧に読むのが安全です。

サブスクリプション URL は必ず自分が契約したプロバイダが発行したものを使ってください。第三者が改ざんしたリンクは悪意あるノードへ誘導されるリスクがあります。複数プロファイルを切り替えたい場合は、ディレクトリを分けるか、ファイル名を切り替える運用か、外部コントローラ経由で切り替えるかを決めておくと、トラブル時の切り分けが速くなります。

手動起動と動作確認

systemd に登録する前に、必ずフォアグラウンドまたは一時的なバックグラウンドで動作確認します。代表的なチェックは次のとおりです。(1) ローカル API やログにエラーが出ていないか (2) プロキシポート（例：7890 や 7891）がリッスンしているか (3) ブラウザでプロキシを指定したときに期待どおりにルーティングされるか。ポート番号は設定ファイルの port／socks-port などに依存するため、他アプリと衝突していないかも合わせて確認してください。

DNS まわりで fake-ip を使っている場合、Linux の systemd-resolved や NetworkManager の挙動と相互作用します。名前解決が不安定に感じたら、まずログを確認し、必要なら DNS セクションをフラットに読み直すのが有効です。分流の考え方は分流ルールの記事と併せて読むと、ルールの意図がつまみやすくなります。

systemd ユニットの作成

ユーザー権限で常駐させる場合は、~/.config/systemd/user/ にユニットファイルを置き、systemctl --user enable --now で有効化します。ブート時にユーザーサービスを立ち上げたい場合は、linger を有効にする必要がある点に注意してください（loginctl enable-linger ユーザー名）。管理者としてシステム全体に提供するなら /etc/systemd/system/ に置き、専用の非特権ユーザーを作ってバイナリと設定を所有させる方法もあります。

ユニットの骨格は、After=network-online.target でネットワークの準備を待ち、Type=simple で ExecStart にバイナリと -d をそのまま渡す形がシンプルです。失敗時の再起動は Restart=on-failure とし、短時間に何度も繰り返さないよう RestartSec を数秒空けると安定します。環境変数（EnvironmentFile）でサブスクリプション URL などの秘密を渡す構成は避け、可能なら設定ファイル側の管理に寄せるか、パーミッションを厳しくしたファイルに限定してください。

有効化・自動起動・ログの見方

ユニットを有効化したら、systemctl --user status（またはシステムユニットなら systemctl status）で状態を確認します。ログは journalctl --user -u ユニット名 -f で追うのが便利です。設定を書き換えたあとは、コアが再起動を要求するかどうかをドキュメントに従い、systemctl --user restart で反映します。古いプロセスが残っているとポートが掴めず失敗するため、停止してから起動する癖を付けるとよいです。

これで「ログイン後に自動で立ち上がる」「再起動後も同じ設定で戻る」という意味でのsystemd による自動起動運用が実現できます。ノート PC ではスリープ復帰直後にネットワークが一瞬不安定なことがあるため、そのタイミングだけ再接続が必要になるケースもあります。ログのタイムスタンプと突き合わせて原因を切り分けてください。

Linux での TUN と権限の補足

TUN を有効にする場合、ディストリビューションによってはカーネルモジュールや名前空間の制約が絡みます。コアに付与する Linux ファイル能力（setcap）や、iptables／nft との連携といった話題は、バージョンと環境の組み合わせで差が大きいため、ここでは「公式ドキュメントとコミュニティの手順をそのまま適用する」前提に留めます。まずはプロキシポート運用で安定させ、TUN は二段階目として取り組むのが現実的です。

アップデートとロールバック

バイナリは単一ファイルなので、更新時は新しいファイルを別名で置き、動作確認後に旧ファイルと入れ替えるだけでロールバックも容易です。systemd の ExecStart が指すパスを固定し、実体はシンボリックリンクにする運用もよくあります。設定ファイルは Git 管理しない場合でも、日付付きのバックアップを取っておくと、サブスクリプション側の変更で突然動かなくなったときに助かります。

よくあるつまずき

ポートが既に開いている

別のプロキシや開発サーバが同じポートを使用していると、起動に失敗します。ss -lntp などで衝突を確認し、設定側のポートを変更するか、競合するプロセスを止めます。

権限エラーで設定が読めない

設定ディレクトリやファイルの所有者が想定と異なると、非特権ユーザーで起動したデーモンが読めません。ls -la で所有者とモードを確認し、必要なら chown と chmod を調整します。

名前解決だけが不安定

Clash 側の DNS 設定と、OS のリゾルバ設定が食い違っていると、ブラウザでは開けるのに CLI だけ失敗する、といった症状が出ます。ログの DNS 関連メッセージと、resolvectl status などの出力を突き合わせてください。

オープンソースとしての参照先

コアや周辺ツールのソースコード、Issue、ライセンス表記は、各プロジェクトの GitHub リポジトリで公開されているのが一般的です。不具合の詳細やリリースノートを読む用途には便利ですが、初めてインストールする実行ファイルの入手は、当サイトのダウンロードページに整理した導線を優先すると、環境ごとの取り違えを減らせます。

まとめ

Linux では「GUI」よりもファイル配置・権限・デーモン管理が主役になります。Clash Meta コアを単一バイナリとして配置し、-d で設定ディレクトリを固定し、動作確認のうえで systemd に登録する、という流れは、他のサーバ用途の常駐プロセスと同じ発想で取り組めます。Windows や Android の記事で触れたルールやポリシーグループの知識はそのまま活きますが、プラットフォーム固有の差分はここで一度だけ丁寧に潰しておく価値があります。

実際に手を動かして比べると、メモリ使用量の小ささや、起動スクリプトにそのまま組み込める手軽さなど、Linux ならではのメリットも実感しやすいはずです。環境に合ったパッケージはプラットフォームごとに異なるため、まずは当サイトの一覧から選ぶのが確実です。準備が整ったら、→ Clash を無料ダウンロードして、Linux を含む各環境向けのクライアントを確認するところから進めてみてください。