Linux ヘッドレス環境での Clash Meta：インストール、systemd 常駐、サブスクリプション自動更新

ヘッドレス Linux で Clash Meta を選ぶ理由

ヘッドレス環境にはトレイもプロファイルウィザードもありません。挙動はすべて設定ファイルに書き、init 系で強制します。Meta 系コアは多くのプロバイダが前提とする機能やルールエコシステムに追従しやすく、ノート PC クライアントとデータセンター中継で同じパターンを流用しやすいのが利点です。Clash はローカルポート（多くは HTTP/SOCKS 兼用の mixed-port）で待ち受け、ルールに従ってアウトバウンドへ流します。外部コントローラは REST API を公開するため、状態確認やプロファイル切替、リロード要求を自動化でき、UI が SSH だけのときに特に効きます。

デスクトップ向けチュートリアルと比べると、サーバー運用では三つの責務が繰り返し現れます。第一に、アーキテクチャに合った実行ファイルを配布し、プロトコル変化に合わせて更新すること。第二に、ディレクトリ権限は最小権限へ：専用アカウントで動かし、秘密情報を world-readable に置かず、書き込みが必要な provider キャッシュを静的設定から分離する。第三に、systemd と統合してクラッシュを一過性にし、ネットワーク準備への依存を明示し、journalctl で観測可能にする。ここまで固めると、透過転送や TUN 的な取り込みは段階的な拡張になり、一度きりの脆い構成になりにくくなります。

前提：ユーザー、ポート、コールドスタート

サイドルータ読者はカーネル転送や nftables、DHCP と組み合わせることもありますが、本稿は「そのマシン上で信頼できる SOCKS/HTTP 出口を得る」ところまでを対象にします。systemd でパスとログが安定していると、ゲートウェイ連携の後工程がずっと楽になります。

mihomo（Clash Meta）バイナリのインストール

GitHub Releases などから現行版を取得し、アーキテクチャに合うアーカイブまたは単体バイナリを /usr/local/bin/mihomo のような標準パスへ配置します。公開されているチェックサムがあれば検証してください。ディストリビューションのパッケージや AUR も可ですが、古いビルドは新しい YAML キーを拒否して即終了し、ログでは原因不明のサービス失敗に見えがちです。

1. uname -m の出力とリリース資産名を突き合わせる。
2. 公開されているダイジェストがあれば整合性を確認する。
3. sudo install -m 0755 mihomo /usr/local/bin/mihomo などで配置する。
4. サービスユーザーで mihomo -v を実行し、動作と依存を確認する。

設定ディレクトリと最小スケルトン

実運用では /etc/mihomo や /var/lib/mihomo に config.yaml を置き、所有者を揃えます。リスナー、モード、ログ、コントローラバインド、読み込む proxy-providers／rule-providers を宣言します。サーバーでは secret を必ず設定し、露出モデルを理解していない限り 127.0.0.1 にバインドするのが無難です。

次のスケルトンは関係を示す最小例です。本番前に実際のポリシーグループ、パーサ、ルールで拡張し、URL はプロバイダのものに差し替えてください。

port: 7890
socks-port: 7891
mixed-port: 7893
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
secret: "change-me"

proxy-providers:
  airport:
    type: http
    url: "https://example.com/subscription"
    path: ./providers/airport.yaml
    interval: 3600
    health-check:
      enable: true
      interval: 600
      url: https://www.gstatic.com/generate_204

proxies: []

proxy-groups:
  - name: PROXY
    type: select
    use:
      - airport

rules:
  - MATCH,PROXY

interval はコアがサブスクリプションを再取得してメモリへマージする周期です。ヘルスチェックでノードを積極的に試し、手動ローテーションを減らせます。プロバイダが provider 断片ではなく完全プロファイルを返す場合は、利用バージョンのドキュメントに合わせて構造を調整してください。フィールド名は進化し、厳格なパーサは失敗時に即終了します。

systemd ユニットの記述

/etc/systemd/system/mihomo.service を作成します。Type=simple、WorkingDirectory を設定ルートに、起動は mihomo -d /path。Restart=on-failure と適切な RestartSec、負荷時のための LimitNOFILE を設定します。PPPoE や VPN でリンクが不安定なら After=network-online.target に揃え、ディストリが実際にルーティング可能になるまで待つ仕組みがあるか確認してください。さもなくば初回取得がレースし、provider が空のままになることがあります。

[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=5
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

1. sudo systemctl daemon-reload
2. sudo systemctl enable --now mihomo.service
3. systemctl status mihomo で active (running) を確認
4. YAML エラー、DNS 失敗、ポート競合は journalctl -u mihomo -e で追う

環境変数による CLI・自動化

mixed-port がローカルで待ち受けると、多くのツールが http_proxy、https_proxy、all_proxy を解釈します。curl、wget、各種パッケージマネージャ、標準変数に対応した CI にとって摩擦が最も小さい経路です。例（ポートは設定に合わせて変更）：

export http_proxy="http://127.0.0.1:7893/"
export https_proxy="http://127.0.0.1:7893/"
export all_proxy="socks5://127.0.0.1:7893/"

大文字のみ／小文字のみを読むツールもあります。メンテナンストラフィックを直送したいなら、グローバルプロファイルに書かずシェル単位や env http_proxy=... curl ... のようにコマンド単位で渡してください。プロキシを無視するアプリには proxychains や redsocks、TUN 層が必要になりますが運用面が広がるので、環境変数で足りないときの拡張と考えます。

サブスク更新と設定リロード

interval による provider 取得は、多くの場合プロセス全体を再起動せずノード一覧を更新します。config.yaml 本体を編集し（provider 追加、ルールファイル変更、リスナ変更など）、完全な再読込が要る場合は外部コントローラ API にシークレット付きでアクセスするのが一般的です（パスはリリースごとに異なり、/configs への PUT パターンが多い）。単純には systemctl restart mihomo も使えますが短時間の切断は発生します。

任意で systemd timer を用意し、時間ごとに curl スクリプトで強制更新する方法もあります。プロバイダ側のエンドポイントが不定期に変わり、すべての interval を短くしたくないときに有効です。トークンはモード 600 の EnvironmentFile に置きユニットから参照し、世界読み取り可能なヘルパースクリプトに埋め込まないでください。

サーバーでは可観測性が重要です。構造化ログに加え、コントローラのヘルスルートがあれば HTTP GET、または mixed-port 経由の定期 curl で、自動化スタックより先に provider 沈黙を検知しましょう。

よくある質問

起動直後に終了し「address already in use」

ss -lntp や lsof -i :7893 で待受を確認してください。手動起動の残骸や別プロキシが mixed／controller ポートを掴んでいる可能性があります。スーパーバイザは systemd に一本化し、二重のフォアグラウンド実行を止めます。

サブスクリプション取得が常に失敗する

同一ホストから curl -v で DNS・TLS・パスを切り分けます。既存プロキシがないと届かない URL なら、信頼できるマシンで初期 providers を用意するか、一時的に届くネットワークで取得し、ノードが通った後は定期更新に任せます。ホスト名の別ラインを試す方が、interval を盲信して詰めるよりコールドスタート改善につながることが多いです。

provider キャッシュ書き込みで権限エラー

実行ユーザーとディレクトリ所有者を一致させ、WorkingDirectory 配下に ./providers を用意してください。ドキュメントのサンプルを root 所有のままコピーし、非 root ユーザーで動かすのは典型ミスです。

まとめチェックリスト

デスクトップ版も欲しい場合

サーバーは YAML と systemd のまま、ワークステーションはインポート補助付き GUI が向きます。本ヘッドレス構成を上流やゲートウェイにしつつ、Windows／macOS では使いやすい統合ビルドが必要なら ダウンロードページ もあわせてご利用ください。

Clash を無料ダウンロードして、スムーズなセットアップを始める