1. 想定環境と用語
対象は Ubuntu 22.04（Jammy）のクリーンなサーバーまたはデスクトップです。Snap 版やディストリビューション付属の古いパッケージに頼らず、公式に近い形で コア単体を置く前提で書いています。GUI の Clash Verge などは本稿の範囲外ですが、裏側で動かすバイナリと設定の考え方は共通です。
文中の Clash は多くの場合 Mihomo（旧 Clash Meta 系）コアを指します。リリース名が mihomo でも clash-meta でも、役割は「YAML を読み、ルールとプロキシグループを解釈し、指定ポートで待ち受けるプロセス」です。インストールというより、実行可能ファイルと config.yaml を所定の場所に置き、常駐プロセスとして束ねるイメージで捉えると手順がぶれません。
Windows や macOS の記事では画面操作が中心でしたが、Linux では systemd がその役割を担います。単に nohup で裏起動するより、Restart= や After=network-online.target を明示したユニットのほうが、再起動やクラッシュ後の挙動が予測しやすくなります。
2. ディレクトリと権限の決め方
運用で最初に迷うのが「root で動かすか、専用ユーザーで動かすか」です。セキュリティとファイル所有者の一貫性の観点から、非特権ユーザー（例：clash）を作り、設定と実行ファイルをそのユーザーが読める場所に置く構成を推奨します。ルート直下にバイナリを置く例（/usr/local/bin）と、ホーム直下に閉じる例のどちらでも構いませんが、WorkingDirectory と 設定パスを systemd と揃えることが重要です。
本稿では例として次を採ります（読み替え可）。
- 実行ファイル：
/usr/local/bin/mihomo（root:root、実行ビット付与） - 作業ディレクトリ／設定：
/etc/clash（所有者をclash:clashにし、設定のみ書き込み可能に）
/etc/clash は管理者がデプロイし、日々の購読更新が必要なら clash ユーザーに書き込み権限を絞るか、更新用スクリプトを systemd timer で回す、といった分割が現場では一般的です。いきなり world-writable にしないことがポイントです。
ユーザー作成の例
システムユーザーとして clash を追加し、ログインシェルを無効にしておくと誤操作が減ります。コマンド例は環境に合わせて調整してください。
sudo useradd --system --home /etc/clash --shell /usr/sbin/nologin clash
sudo mkdir -p /etc/clash
sudo chown clash:clash /etc/clash3. バイナリの配置
配布物はプロジェクトのリリースページから取得するのが一般的です。本サイトではクライアントの入手は ダウンロードページを第一に案内し、Linux 向けコアの取得元は利用規約とライセンスに従って選択してください。アーキテクチャ（amd64 / arm64 など）は uname -m で確認し、取り違えないようにします。
ダウンロードした圧縮ファイルを展開し、実行ファイルを /usr/local/bin/mihomo に置いたうえで、
sudo chmod 755 /usr/local/bin/mihomoとして実行権限を付与します。SELinux や AppArmor を有効にしている環境では、追加のプロファイルが必要になる場合があります。Ubuntu 22.04 のデフォルトでは AppArmor が有効なので、カスタムパスに置いた場合は拒否ログが出ないか dmesg や journalctl も併せて確認すると安心です。
バージョン確認は mihomo -v のようなサブコマンドが用意されていることが多く、期待するビルドかを起動前に固定しておくと、後からのトラブルシュートが楽になります。
4. 設定ファイルと動作確認
/etc/clash/config.yaml を配置し、所有者を clash:clash にします。最低限、mixed-port や port、DNS、プロキシとルールが矛盾なく書かれているかを確認してください。TUN を Linux で使う場合はカーネルモジュールや CAP_NET_ADMIN が絡み、本稿の「単純な systemd 常駐」の一歩先に進みます。まずはローカルプロキシとして 127.0.0.1 で待ち受けられる状態を作ると切り分けが容易です。
ユニット化する前に、一時的に clash ユーザーで手動起動して挙動を見ることをおすすめします。
sudo -u clash -H /usr/local/bin/mihomo -d /etc/clashここで購読 URL や証明書エラーが出ていれば、systemd に載せる前に YAML 側を直します。手動では動くのにサービスだけ失敗する場合は、環境変数や作業ディレクトリ、読み込むパスの差分を疑ってください。
external-controller を LAN に晒す設定は、トークン無しのままにしないでください。必要なら 127.0.0.1 のみに限定するか、ファイアウォールで遮断します。
5. systemd ユニットの記述
/etc/systemd/system/clash.service を作成します。以下はあくまでテンプレートであり、実際の ExecStart パスやオプションは環境に合わせてください。
[Unit]
Description=Clash Mihomo Daemon
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=clash
Group=clash
WorkingDirectory=/etc/clash
ExecStart=/usr/local/bin/mihomo -d /etc/clash
Restart=on-failure
RestartSec=5
LimitNOFILE=1048576
[Install]
WantedBy=multi-user.targetAfter=network-online.target は、起動直後に DNS や購読取得が失敗しやすい状況を減らすための定番です。ネットワークが後から立ち上がる環境ではこれでも足りないことがあるため、その場合は ExecStartPre で短い待機を入れる、あるいは失敗時に 自動再起動 に頼る、といった運用になります。
Restart=on-failure はプロセスが異常終了したときに クラッシュ再起動 する指定です。always にすると意図しないループも起こり得るため、まずは on-failure から始めるのが無難です。RestartSec はログの洪水を防ぐためのクールダウンとして効きます。
Capability が必要な場合
TUN や透明プロキシの高度なモードでは CapabilityBoundingSet や AmbientCapabilities の付与が必要になることがあります。その場合は最小権限に留め、不要なら TUN をオフにしてユーザーモードのプロキシだけで運用する選択肢も検討してください。
6. 有効化と状態確認
ユニットを登録したらデーモンリロードと有効化を行います。
sudo systemctl daemon-reload
sudo systemctl enable --now clash.service
systemctl status clash.serviceactive (running) が返ればプロセスは起動しています。enabled になっていれば 起動時自動起動 の設定も完了です。再起動試験では sudo reboot 後に再度 status を確認し、ネットワークより後に立ち上がっているかを見ます。
一時停止や設定反映のために systemctl restart clash.service を使うと、手動で PID を探して kill するより安全です。設定ファイルだけ差し替えた場合も、コアがリロードに対応していれば API や SIGHUP で済む場合がありますが、運用を単純化するなら再起動一本に寄せるチームも多いです。
7. ポートとプロセスの検証
インストールが成功していても、ファイアウォールやバインド先のミスで外部から見えないことがあります。まずはローカルで 127.0.0.1 に向けて HTTP プロキシや SOCKS のハンドシェイクができるかを確認し、次に ss または lsof で LISTEN を確認します。
ss -tlnp | grep -E 'mihomo|clash'mixed-port が 127.0.0.1 にしかバインドしていない場合、同じマシン上のブラウザからは使えても、別ホストからは繋がりません。LAN 内の別端末にプロキシを提供したいときは allow-lan 相当の設定と、バインドアドレスの見直しが必要です。サーバー用途では逆に LAN に開かないほうが安全なので、要件に合わせて絞り込みます。
ufw を有効にしている場合は、必要なら該当 TCP ポートを許可します。ただしインターネットに面した VPS で不要なポートを開けないことは基本中の基本です。
| 症状 | よくある原因 | 確認すること |
|---|---|---|
| サービスは active だが接続できない | 127.0.0.1 のみリッスン | YAML の bind／allow-lan、ss の出力 |
| 起動直後だけ購読に失敗 | ネットワーク未準備 | network-online、journalctl の順序 |
| 再起動ループ | 設定エラー・権限不足 | systemctl status、ユニットの Restart 値 |
| 手動では動くがサービスだけ落ちる | User／WorkingDirectory の不一致 | ファイル所有者、パス、環境変数 |
8. ログと失敗時の読み方
systemd 管理下では journalctl が第一の情報源です。
journalctl -u clash.service -b -e-b は今回のブート分に絞り、-e は末尾から表示します。YAML の文法エラー、証明書検証、DNS タイムアウトなどはここに現れやすいです。コア側がファイルにログを吐く設定になっている場合は、そのファイルもあわせて tail します。
失敗のたびに 自動再起動 が走ると、画面が流れて読みにくくなることがあります。その場合は一時的に Restart=no にして再現し、静的なエラーメッセージを確保する方法もあります。運用では RateLimitIntervalSec などで再起動頻度を抑える選択肢も検討してください。
9. セキュリティと運用上の注意
プロキシは通信の集約点になるため、設定ファイルに埋め込んだトークンや購読 URL の扱いには十分注意してください。/etc/clash のパーミッションを緩めすぎないこと、バックアップを取る媒体を暗号化すること、共有サーバーでは他ユーザーから読めない位置に置くこと、が基本です。
オープンソースのライセンスやビルドの出所を確認したうえで利用する場合、ソースや Issue トラッキングは各プロジェクトの公式情報を参照してください。一方で、日常のクライアント入手と更新は 本サイトのダウンロードページを優先すると、説明書とパッケージの対応関係が取りやすくなります。
他 OS との比較では、Windows でポート共有やファイアウォールを扱った Windows 11 向けの記事や、ルートと TUN を切り分けた TUN トラブルシュートと目的が異なることがわかるでしょう。Linux ではその分、systemd とファイル権限の設計が運用品質を決めます。
10. まとめ
Ubuntu 22.04 で Clash Linux 環境を作る流れは、バイナリと config.yaml を決めた場所に置き、専用ユーザーで動かし、systemd に 起動時自動起動 と クラッシュ再起動 を託す、という一本線です。途中で躓きやすいのは権限の取り違えと、LISTEN アドレスとファイアウォールの組み合わせです。ss と journalctl をセットで見れば、大半は「設定が読めていない」「ネットワークより先に購読に行った」「ループバックだけ開いている」のいずれかに収束します。
GUI クライアントが用意されている OS と比べ、Linux は初期コストはかかりますが、サーバー上で安定したプロキシ端末を自前運用したい場合に再現性が高いのが強みです。ビルドやルールの見通しがよい Mihomo 系コアと組み合わせると、ログと YAML を軸にしたメンテナンスがしやすくなります。