Arch Linux で Clash Verge Rev を導入：AUR・購読・systemd まで（2026）

ローリング環境で GUI プロキシを「置ける」状態にそろえる

Arch Linux は常に新しい上流が流れ込むローリングリリースです。Manjaro のように派生ディストリビューションを使っていても、多くの場合 AUR（Arch User Repository） を併用してアプリケーションを追加します。GUI の Clash Verge Rev は公式の core／extra には載っていないため、ユーザがメンテしている AUR パッケージ経由で入れるのが現実的です。検索すると clash-verge-rev-bin（上流のリリースバイナリをそのままパッケージング）や、ソースから組み立てる clash-verge-rev など、名前が似たエントリが並びます。ここを取り違えると「ビルドは通ったが別フォークだった」「既存の clash-verge-bin とファイルがぶつかった」といった事後修正が面倒になるので、最初に目的のクライアントが Rev であることを確認しておくのが安全です。

本記事のゴールは次の三つです。第一に、AUR から適切なパッケージを導入する。第二に、プロバイダーが発行する HTTPS の購読 URL を取り込み、ノード一覧とルールが期待どおり読み込める状態にする。第三に、再起動後も手動起動を忘れないよう systemd --user でログインセッションに合わせて常駐させる。ルール文法や DNS の細部は チュートリアル・ドキュメントに譲り、OS とパッケージングの観点に絞って書きます。自動起動のユニット例や環境変数の話は、汎用 Linux 向けに詳しくまとめた Ubuntu 版 Clash Verge・systemd ガイドとも内容が重なります。併読すると「Wayland 下の DISPLAY」のような論点の補足が得られます。

オープンソースについて：上流の開発状況やリリースノートは clash-verge-rev リポジトリを参照してください。Linux 向けの入手経路が複数あるため、改ざんリスクや表記ゆれを避けたい場合は 当サイトのダウンロードページから最新ビルドの所在を確認するのが無難です。

パッケージの選び方：clash-verge-rev-bin が候補の中心

実務では clash-verge-rev-bin を選ぶケースが多いです。理由は単純で、上流が GitHub で配布している AppImage や tarball に近い成果物を PKGBUILD が取りに行き、ローカルでの rustc／Tauri フルビルド時間を短縮できるからです。一方 clash-verge-rev（-bin なし）はソースビルドになり、マシンスペックやネットワーク状況によっては時間とディスクを使います。どちらを選んでも中身は同じ系列であれば UI の流れは同じですが、パッケージの conflicts（競合） に注意してください。AUR のページでは、Rev 系ビルドが従来の clash-verge／clash-verge-bin などと同時導入できない旨が宣言されていることが多く、既に旧パッケージを入れている場合は先に削除してから入れ替えます。

Manjaro 利用者は、アクセスポイントをオフィシャルミラーに揃え、pacman -Syu で同期してから AUR に進むとビルド依存の取り違えが減ります。ハイブリッド显卡や Wayland 前提のデスクトップでは、WebKit 系列のランタイム不足でウィンドウが出ないことがあるため、初回はターミナルから実行して標準エラーに赤い行が出ていないかを見る癖を付けるとよいです。

AUR を使う前の下準備

公式ドキュメントでも繰り返し言われる通り、AUR のパッケージは「本人がビルドして自身の責任で使う」前提です。ヘルパー（yay や paru）は依存解決や git clone を楽にするだけで、中身のレビューはユーザー側に残ります。最低限、sudo pacman -S --needed base-devel git でビルド環境を整えます。ヘルパー未導入の場合は、Arch Wiki の手順に沿って yay か paru を入れてください。使い慣れた方を選べばよく、機能要件はどちらも大きくは変わりません。

注意：AUR にある PKGBUILD を読まずに信頼できるソースからの取得か確認しないまま実行するのは避けてください。人気パッケージほどコメント欄に最新のひっかかり（署名検証、glibc バージョンなど）が溜まるので、ビルド失敗時はまずそこと PKGBUILD の source= を確認します。

インストール手順（yay／paru 想定）

環境が整ったら、次の流れで進めます。ExecStart に書くパスを後で使うので、インストール直後に which clash-verge やパッケージが提供するコマンド名を必ず確認してください（ディストリビューションやビルドにより表記がわずかに異なる場合があります）。

  1. ターミナルで yay -S clash-verge-rev-bin または paru -S clash-verge-rev-bin を実行し、差分レビューのプロンプトが出たら内容をざっと確認してから続行します。
  2. ビルドとパッケージインストールが終わったら、アプリケーション一覧から Clash Verge Rev を起動するか、判明したコマンド名で起動します。真っ黒な画面で終わるときは端末から同じコマンドを叩き、不足ライブラリや権限エラーを読み取ります。
  3. 内部の Mihomo（Clash Meta 系）カーネルが初期化されるまで数秒待ち、設定画面でバージョンやデータディレクトリの場所を把握しておくと、後からのバックアップが楽です。
  4. 競合エラーで止まった場合は、既存の Verge 系パッケージを pacman -Qs clash-verge で列挙し、意図しないものをアンインストールしてから再試行します。

初回起動：システムプロキシから入ると切り分けが楽

Linux では、いきなり TUN モード を有効にするとルーティングや DNS の相互作用が複雑になります。ブラウザでまず疎通を確認するなら、クライアント側でシステムプロキシまたは手元アプリ向けのポートを有効にし、期待どおり出口に載っているかを見ます。Allow LAN をオンにして同一セグメントの端末から利用する場合は、無関係なインターフェースへのリッスンになっていないか、ファイアウォールのポリシーと矛盾していないかも確認が必要です。Arch 系はデフォルトで単純なブロックは少ないものの、自分で nftables や別のセキュリティスイートを入れている場合はそこもセットで見ます。

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

プロバイダーから受け取った URL は、GUI のプロファイル／サブスクリプション画面に追加します。名前は後から見て分かるようにし、更新間隔はポリシーと帯域に合わせて調整します。手動で「更新」を実行したあと、ノード数が増えているか、ヘルスチェックや遅延テストが通るかを見ます。典型的な失敗要因は、URL の末尾スペース、期限の切れたトークン、企業ネットワークでの TLS インターセプトです。curl -I で応答コードを見る、別回線で試す、といった汎用手順で切り分けられます。ルールプロバイダの取得だけ失敗する場合は DNS が原因のことが多いので、一旦「フルプロキシ側の DNS に寄せる／寄せない」の比較も有効です。

systemd ユーザーユニットでログイン後に自動起動

Arch でもデスクトップの「ログイン時に起動するアプリ」に登録する方法はありますが、Wayland とセッションタイミングの組み合わせで不安定になり得ます。systemd --user にサービスを書いて enable しておくと、「ログイン後に必ずこのコマンドを起動する」という宣言が残り、トラブル時も journalctl --user でログを追いやすくなります。具体的な [Unit]／[Service] の雛形や DISPLAY まわりの補足は、前述の Ubuntu 向け systemd 記事の例をそのまま流用して構いません。ポイントは ExecStart に実環境の絶対パスを書き、編集後に systemctl --user daemon-reload を挟むことです。

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

再起動テストで落ちる場合は、ユニットがグラフィカルセッションより先に走っていないか、AppImage を直指定しているのにパスが古いバージョンを指したままになっていないかを疑ってください。

よくあるつまずき

AUR ビルドが途中で失敗する

ミラーの同期遅れ、GPG 鍵、一時的な 404 などが典型です。~/.cache 以下の該当ディレクトリを掃除して再ビルドする、公式ニュースで必須の手動対応がないか読む、の順で切り分けます。ローリングの更新直後は、glibc や OpenSSL の世代が変わってソフトの再ビルドが必要になる時期と重なることがあります。

TUN を有効にすると一部アプリだけ不通

split ルールの順序、fake-ip と実 IP の取り違え、別デーモンによるデフォルトルートの奪い合いが疑われます。いったん TUN をオフにして症状が消えるか比較し、ルールを段階的に狭めます。

トレイにアイコンが出ない

GNOME Shell の拡張やステータス周りの互換に依存します。プロセスは生きているのに操作できないときは、一旦フロントを前面に出すショートカットや、コマンドラインからの再起動を試します。

よくある質問

clash-verge-bin ではなく Rev が必要な理由は？

コミュニティで現在も開発が続いているのは Rev 系であることが多く、Issue やドキュメント・周辺ツールの話題もそちらに寄っています。旧パッケージ名が残っているだけの場合、目的の機能（新しいコアオプションや UI）が追従していないことがあります。迷ったら上流リポジトリの README と自分が欲しい機能の対応表を見比べます。

Manjaro で AUR を有効にしていない場合は？

GUI のパッケージマネージャから AUR サポートをオンにするか、Wiki に従って yay／paru を入れてください。Enterprise 向けロックダウン端末ではポリシーで AUR が禁止されていることもあるので、その場合はポータブル形式の配布物と自分用の配置ルールに切り替える必要があります。

まとめ

Arch／Manjaro で Clash Verge Rev を使い始める最短ルートは、レビューしたうえで clash-verge-rev-bin を AUR から入れ、購読 URL の鮮度とルール取得を確かめ、必要なら systemd ユーザーサービスでログイン後のライフサイクルに縫い込むことです。ローリング環境では一見同じ手順でも libc やランタイムの世代差で挙動が変わるため、「パッケージを入れ替えた直後に一度フル再起動する」くらいの保守的な習慣があると安心です。

一方で、コマンドラインのみのコア実装や、ドキュメントの断片を自分で繋ぎ合わせる方式は、GUI に慣れた利用者にとって試行錯誤の回数が増えがちです。設定ファイルの所在や更新タイミングが分かりにくく、初日は動いてもカーネル更新の翌週に急に起動しなくなる、といったストレスも起こりえます。ClashSource は複数 OS の導線と説明を一か所に寄せているので、ビルド済みクライアントの選定からチュートリアル参照までの往復を減らせます。Arch で本稿の手順まで進んだあとも、他端末との揃え方や入手元の確認に迷ったら、 ClashSource のダウンロードページ から続きを進めるとスムーズです。数分でプロファイル更新と接続確認まで押し込めるはずです。