なぜヘッドレス Linux で Clash Meta か

リモートの Linux サーバーでは、ブラウザやトレイ常駐型の GUI クライアントを前提にできません。ローカルでも、軽量 WM だけの環境では「設定画面付きアプリ」より、単一バイナリ＋YAML の方が導入と自動化が単純になります。Clash 系の現行実装として広く使われている Clash Meta（mihomo） は、同じ設定思想のままヘッドレス運用に載せやすく、systemd と相性がよいのが利点です。

コアの役割やプロトコル周りの前提は、デスクトップ向けの解説と共通です。Windows や macOS で Meta コアへ切り替える話は Clash Meta（mihomo）コアアップグレードガイド でまとめています。本記事は「Linux にバイナリを置いてサービス化する」ことに焦点を当てます。

ディレクトリ構成と実行ユーザー

運用では、バイナリ・設定・ルールセット・キャッシュを一つのホームディレクトリにまとめると権限管理が楽です。例として /opt/clash-meta をルートとし、その下に config.yaml、実行ファイル、取得したルールファイルを置く構成を想定します。セキュリティのため、root で常時動かすより、専用のシステムユーザー（例：clash-meta）を作り、そのホームまたは作業ディレクトリだけに書き込み権限を絞る方法が推奨されます。

リッスンするポート（例：HTTP プロキシや mixed ポート）は、他サービスと重ならないか事前に ss -lntp などで確認してください。特権ポート（1024 未満）を使う場合は、バイナリに capability を付けるか、フロントのリバースプロキシで受けるなど、方針を決めてからユニットを書きます。

バイナリの配置と設定ファイルの要点

配布形態はビルドやパッケージによって名称が mihomo や clash-meta など異なることがありますが、起動時に渡すのは「実行ファイルのパス」と「-d で指定する設定ディレクトリ」が基本です。設定ファイル名は多くの場合 config.yaml で、同ディレクトリにルールセットやキャッシュが生成されます。

ヘッドレスでは画面からログレベルを変えられないため、トラブルシュートのために ログ出力の粒度 を YAML で把握しておく価値があります。開発版ではキー名が変わることがあるため、利用中のバージョンのドキュメントに合わせ、必要なら一時的に詳細ログへ上げて事象を切り分けます。分流やポリシー設計そのものは Clash YAML ルール分流ガイド の考え方がそのまま使えます。

設定のバックアップ サービス化する前に、動作確認できた config.yaml を別名で退避しておくと、試行錯誤で壊したときに即座に戻せます。systemd の ExecStartPre で文法チェックを挟む運用もありますが、コマンドの有無は環境次第です。

systemd ユニットの例

以下はイメージです。実際のパス・ユーザー名・ExecStart の引数は環境に合わせて置き換えてください。Restart=on-failure や Restart=always でプロセス落ちに強くできます。LimitNOFILE は大量接続時に効くことがあります。

# /etc/systemd/system/clash-meta.service
[Unit]
Description=Clash Meta (mihomo)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=clash-meta
Group=clash-meta
WorkingDirectory=/opt/clash-meta
ExecStart=/opt/clash-meta/mihomo -d /opt/clash-meta
Restart=on-failure
RestartSec=3
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

ファイルを保存したら systemctl daemon-reload を実行し、systemctl start clash-meta で起動、systemctl status clash-meta で状態を確認します。ここで active (running) にならない場合は、次節のログを必ず併読してください。

起動時の自動起動（enable）

手動起動が成功したら、systemctl enable clash-meta でブート時にユニットを有効化します。無効化するときは disable です。ネットワークの準備より先にプロセスだけ立ち上がってしまうと、最初の名前解決や購読取得に失敗することがあるため、After=network-online.target を付けたうえで、それでも不安なら起動後のヘルスチェックを別スクリプトに分ける方法もあります。

コンテナ内で動かす場合も思想は同じですが、PID 1 とシグナルの扱い、ボリュームのマウント先、タイムゾーンなど、ホスト運用とは別の落とし穴があります。ここではネイティブの systemd を想定しています。

ログの見方：journalctl と設定側のログ

標準出力・標準エラーを journal に流す構成であれば、journalctl -u clash-meta -e で末尾から追え、-f でフォローできます。起動直後だけなら -b（今回のブート）と組み合わせるとノイズが減ります。ユニット名はファイル名に合わせてください。

コアがファイルログを別パスに書く設定の場合は、journal だけ見て「何も出ない」と判断しないことが重要です。設定の log-level やファイル出力の有無を確認し、ルールヒットや DNS、プロキシ選択の記録がどのレベルで出るかを把握しておくと、分流まわりの不具合を追いやすくなります。症状が「接続できない」一択のときは、まず プロセスが生きているか、次に 期待するポートで待ち受けているか、その上で ルールと DNS の順が定石です。

詳細ログとディスク 長期間デバッグレベルを上げっぱなしにすると、ログボリュームが膨らむことがあります。切り分けが終わったら、運用に適したレベルへ戻すか、ログローテーションの方針を決めてください。

よくあるつまずき

症状・状況 確認の手順
start 直後に失敗し status が inactive journalctl -u ユニット名 -e で理由を確認。設定パスの誤り、YAML 文法エラー、バイナリの実行権限不足が多いです。
プロキシポートに接続できない ファイアウォール（nftables／iptables／クラウドのセキュリティグループ）と、リッスンアドレスが 127.0.0.1 限定になっていないかを確認。
名前解決やルールの挙動がおかしい YAML の dns ブロックと rules の順序、fake-ip の有無を見直す。分流の基本は ルール分流ガイド を参照。
アップデート後に動かなくなった 破壊的変更がないかリリースノートを確認。バイナリ差し替え後は daemon-reload と再起動を忘れずに。

どの段階で詰まっているかをメモしながら進めると、次回以降の自分やチームの時間を大きく節約できます。

まとめ

ヘッドレス Linux での Clash Meta 運用は、配置の一貫性、systemd による常駐と自動起動、journal とファイルログの両面からの観測 の三本柱で安定します。GUI がなくても、YAML とログさえ読めればトラブルはかなりの範囲で切り分け可能です。デスクトップ向けのクライアントをお探しの場合は、用途に合わせて ダウンロードページ で各プラットフォームの選択肢を比較できます。

→ Clash を無料ダウンロード — Meta コア対応のクライアントを一覧から選び、自分の環境に合わせて試せます。

ほかのチュートリアルは 技術コラム からどうぞ。