Ubuntu で Clash Verge：サブスクリプション取り込みと systemd による起動自動化

Linux デスクトップで「再起動すると止まる」を防ぐ

Ubuntu をはじめとする Linux デスクトップでは、プロキシクライアントを一度手動で立ち上げればそのセッション中は問題なく動くものの、再起動やログアウトのあとに起動し直すのを忘れて「突然つながらなくなった」と感じることがあります。グラフィカルな Clash Verge（多くの場合 Clash Verge Rev 系のビルド）を使う場合も同様で、デスクトップの「スタートアップアプリケーション」に頼る方法は環境やディスプレイセッションによって挙動がぶれやすいです。

そこで現実的なのが、ユーザーのログイン後に確実にプロセスを立ち上げる systemd ユーザーユニットです。本記事では、パッケージまたは AppImage などからクライアントを配置するところから、サブスクリプション（購読）URL の取り込み、自動起動の設定、代表的なつまずきまでを一連の流れでまとめます。対象は主に Ubuntu 22.04 / 24.04 系の一般的なデスクトップ環境（GNOME）を想定していますが、他の systemd ベースのディストリビューションでも考え方はほぼ同じです。

オープンソースについて：上流のソースやリリース履歴は clash-verge-rev リポジトリで確認できます。インストール用パッケージの入手は、バージョン取り違えを防ぐため 当サイトのダウンロードページの導線を優先するのがおすすめです。

事前準備：アーキテクチャと依存関係

まず、CPU アーキテクチャに合ったビルドを選びます。一般的な PC は amd64（x86_64）、ARM ボードや一部のノート PC は aarch64（arm64） 向けが必要です。取り違えると実行時に「実行ファイルの形式が違う」といったエラーで止まります。カーネルが古すぎる環境では、上流が想定する glibc のバージョンと合わず起動に失敗することもあるため、可能であれば LTS リリースへ追従しておくと安心です。

Clash Verge 系の Linux 版は、WebKitGTK などの GUI ランタイムに依存することが多く、公式ドキュメントやリリースノートに記載のパッケージを apt で入れておくと初回起動がスムーズです。不足している共有ライブラリがあると、ターミナルから起動したときにだけエラーメッセージが表示され、デスクトップのランチャーからだと黙って終了してしまうことがあります。トラブル時は一度 clash-verge または AppImage を端末から実行し、赤字の行を確認してください。

インストール：.deb と AppImage の考え方

配布形式は大きく分けて .deb パッケージと AppImage の二系統が一般的です。.deb を使うとメニューにエントリが登録されやすく、バイナリのパスも /usr/bin/ 付近に揃いやすいため、後述の systemd ユニットを書くときに ExecStart が素直になります。一方、AppImage は単一ファイルで持ち運びやすい反面、保存場所を自分で決める必要があり、更新のたびにファイル名にバージョンが付く場合はユニットファイルのパスも直し忘れに注意が必要です。

.deb を使う場合

ダウンロードした .deb に対して sudo apt install ./clash-verge_*.deb のようにローカルパスを指定してインストールします。依存関係エラーが出た場合は、表示されたパッケージ名を追加で入れてから再試行します。インストール後、which clash-verge などで実際の実行ファイルパスを控えておくと、次の systemd 設定が楽です。名称が clash-verge ではなくディストリビューションやビルドによって微妙に異なる場合があるため、必ず自分の環境で確認してください。

AppImage を使う場合

AppImage には実行権限を付与し、恒久的な場所（例：~/Applications/）に置くと管理しやすいです。FUSE まわりの制限がある環境では追加パッケージが必要になることがあります。systemd から起動するときは、シンボリックリンクで短いパスを用意するか、バージョン番号を含まないファイル名にリネームして ExecStart を固定化する方法が実務的です。更新で中身だけ差し替える運用にすると、ユニットファイルを毎回編集しなくて済みます。

初回起動と権限（TUN・プロキシ）

初回起動後、内部の Mihomo（旧称 Clash Meta）カーネルがプロファイルを読み込みます。Linux で TUN モードを使う場合は、カーネルモジュールや CAP_NET_ADMIN などの権限が絡み、パスワード入力を求められることがあります。まずはシステムプロキシのみでブラウザの疎通を確認し、必要になった段階で TUN を有効にすると、切り分けがしやすくなります。ルールや DNS の詳しい考え方は チュートリアル・ドキュメントや TUN 解説記事と併読すると理解が早いです。

注意：他社製 VPN クライアントや社内ポリシーによるフィルタと同時に TUN を有効にすると、ルーティングが競合して「一部のサイトだけ開かない」症状が出ることがあります。不具合時は一旦 TUN をオフにして挙動を比較してください。

サブスクリプション（購読）の取り込みと更新

プロバイダーから渡される HTTPS の購読 URL を GUI の「プロファイル」または「サブスクリプション」画面に追加します。名前は後から見て分かるように付け、更新間隔はポリシーに合わせて調整します。手動で「更新」を押したあと、ノード一覧にサーバーが現れるか、遅延テストが通るかを確認します。

取り込み後に確認したいポイント

  • ノード数が 0：URL の打ち間違い、期限切れトークン、プロバイダー側の認証エラーが典型です。ブラウザや curl で URL を開き、YAML もしくはエンコード済みの本文が返るかを見ます。
  • 更新だけ失敗する：システム時刻のずれ、中間証明書、企業プロキシによる TLS インターセプトが疑われます。別ネットワークで試すと切り分けやすいです。
  • ルールセット取得エラー：プロファイル内の外部ルール URL がブロックされていないか、DNS が意図せずフィルタしていないかを確認します。

複数プロファイルを運用する場合は、用途ごとに分けておくと、トラブル時に「どの設定が効いているか」を追いやすくなります。Windows / macOS 向けの画面操作に慣れている方は、Linux 版でもメニュー構成は概ね近いため、すぐに作業を再開できるはずです。

なぜデスクトップの自動起動だけでは足りないのか

GNOME の「ログイン時に起動するアプリケーション」に登録する方法もありますが、Wayland と X11 の切り替え、ディスプレイマネージャーの種類、遅延起動の有無によって、タイミングがずれてプロキシより先にブラウザが立ち上がってしまうことがあります。また、セッションが完全に立ち上がる前にコマンドが走ると、トレイアイコンが表示されないままバックグラウンドだけ動いている、という状態の切り分けも面倒です。

systemd --user は、ユーザーログイン後のライフサイクルに沿ってユニットを管理できるため、「いつ起動し、失敗したらどうするか」を宣言的に書けます。GUI アプリをサービス化するときは Type=simple や Type=exec の選択、環境変数 DISPLAY や WAYLAND_DISPLAY の受け渡しが論点になりますが、まずはシンプルな構成から始め、必要に応じて調整するのが安全です。

手順：systemd ユーザーユニットで自動起動

以下は、ユーザーごとの systemd ユニットを作成する一般的な流れです。パスや実行ファイル名は環境に合わせて読み替えてください。

1. ユニットファイルの置き場所

ホームディレクトリに ~/.config/systemd/user/ を作成し、その中に clash-verge.service のような名前でファイルを置きます。システム全体（/etc/systemd/system/）ではなくユーザーユニットにすることで、sudo を多用せずに管理でき、複数ユーザーが同じマシンを共有するときも干渉しにくくなります。

2. サービス定義の例

ExecStart には、先ほど控えた実行ファイルの絶対パスを書きます。AppImage の場合はそのフルパスを指定します。

[Unit]
Description=Clash Verge (user session)
After=graphical-session-pre.target

[Service]
Type=simple
# Replace with: output of `which clash-verge` or full path to AppImage
ExecStart=/usr/bin/clash-verge
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

Wayland 主体の環境でトレイやウィンドウが出ない場合は、セッションから継承すべき環境変数が足りていない可能性があります。そのときは Environment=DISPLAY=:0 のような行を追加する例もありますが、値は echo $DISPLAY の実測に合わせる必要があり、セキュリティと可搬性のトレードオフがあるため、まずは最小構成で動作確認してから足すのがよいでしょう。

3. 有効化と状態確認

ターミナルで次を実行します。

systemctl --user daemon-reload
systemctl --user enable --now clash-verge.service
systemctl --user status clash-verge.service

active (running) と表示され、GUI が期待どおり起動すれば成功です。ログを見るときは journalctl --user -u clash-verge.service -e が便利です。設定を変えたあとは必ず daemon-reload を忘れずに。

ヒント：Linux では「ユーザーユニットの lingering」が無効だと、ログアウトですべてのユーザーサービスが止まります。常にバックグラウンドで動かしたい要件がある場合は loginctl enable-linger ユーザー名 の要否を検討します。通常のデスクトップ利用で「ログイン中は常駐」で足りるなら、デフォルトのままで問題ないことが多いです。

動作確認と再起動テスト

設定が終わったら、実際にシステムを再起動してログインし、Clash Verge が自動で立ち上がっているか、プロキシが有効かを確認します。ここで初めて「デスクトップの自動起動ではダメだった」問題が解消されるはずです。もし起動しない場合は、まず systemctl --user status で失敗理由を読み、ExecStart のパス誤りや権限不足を疑ってください。

よくあるつまずき

トレイに出ない・ウィンドウが見えない

プロセスは動いているのに UI が見えないときは、別のワークスペースに隠れている、またはセッションの種類と表示サーバーの組み合わせによる不具合が考えられます。一度手動起動と自動起動を切り替えて挙動を比較します。

TUN をオンにすると全体の通信が不安定

ルールの順序、DNS（fake-ip など）、デフォルトルートの競合を確認します。TUN 解説やルール分岐の記事を参照し、まずはシステムプロキシのみの構成に戻してから段階的に有効化します。

権限エラーでカーネルが起動しない

ログに permission denied や operation not permitted が出ていないかを見ます。必要に応じて公式 Issue やディストリビューション固有のドキュメントで、capabilities やグループ設定を確認してください。

まとめ

Ubuntu などの Linux デスクトップで Clash Verge を使うときは、インストール形式の違い（.deb / AppImage）と、GUI が期待どおりに立ち上がるための依存関係を押さえることが第一歩です。続いて購読 URL を正しく取り込み、プロファイル更新とノード疎通を確認します。最後に systemd ユーザーユニットでログイン後の自動起動を宣言的に書いておけば、「再起動したら手動で忘れていた」という運用負担を大きく減らせます。

同種のツールのなかでも、Clash 系はルール表現の柔軟さと情報の豊富さのバランスが取りやすく、GUI が揃った Verge 系は Linux に慣れていない方にも取り組みやすい入口になります。環境に合ったビルドの選び方から各 OS の注意点までを一覧できる ダウンロードページも併せてご利用ください。数分でプロファイルの更新と接続確認まで進められます。→ Clash を無料でダウンロードし、快適な接続を試す