📖 チュートリアル ⏱ 約18分で読めます

Arch Linux で Clash Verge を導入する：AUR からのインストールと systemd ユーザーサービスで購読・自動起動を完了させる

「Arch Linux のデスクトップで Clash Verge を入れ、AUR で配布されているビルドを使い、購読（サブスクリプション）URL を取り込み、ログインのたびに手動起動したくないので systemd --user で自動起動まで済ませたい」という検索意図向けの実践ガイドです。Ubuntu 24.04 や Fedora Workstation の解説記事と手順が混ざると詰まりやすいため、pacman／AUR 前提の流れに絞って書いています。コミュニティ PKGBUILD の名称は時代で入れ替わるため、実際のパッケージ名は常に AUR ページの表示を優先してください。

この記事のゴールと前提

ゴールは次の四点を一つの記事で通すことです。（1）Arch の公式リポジトリに無い Clash Verge 系クライアントを AUR から導入する。（2）初回に Mihomo／Clash Meta コア を通し、GUI から 購読 を取り込む。（3）必要なら systemd のユーザーサービス でセッション開始後に自動起動する。（4）うまくいかないときに journalctl --user や設定画面のどこを見るかを押さえる。対象は KDE Plasma・GNOME など一般的な Linux デスクトップ を想定し、ヘッドレスサーバーは対象外です。

クライアント同士の位置づけや用語の整理は 2026 年時点の Clash エコシステム解説 が役立ちます。Debian 系の .deb 手順は Ubuntu 24.04 の Clash Verge 記事、RPM 系で SELinux と firewalld が絡む場合は Fedora Workstation の Clash Verge 記事 と役割分担してください。本稿はあくまで Arch ローリング 特有の「どこから入れるか」「ユニットの ExecStart をどう書くか」に焦点を当てます。

Ubuntu／Fedora の記事と何が違うか

Ubuntu 向け記事では .deb や AppImage、dpkg -L でのパス確認が中心です。Fedora 向けでは SELinux と firewalld が前面に出ます。一方 Arch Linux では、公式パッケージは pacman、コミュニティがメンテする追加物は AUR（Arch User Repository） に置かれる、という二段構えが基本です。Clash Verge のようなデスクトップ GUI は多くの場合 extra や community ではなく AUR の PKGBUILD に載るため、「apt install」「dnf install」の感覚だけで検索すると見当違いのブログに辿り着きやすくなります。

またローリングであるため、同じ PKGBUILD 名でも依存ライブラリのメジャー更新（例：GTK／WebKit 系）でビルドが一時的に壊れることがあります。それはディストリの品質というより「常に先端を追う」モデルの副作用です。詰まったら pacman -Syu で全体を揃えたうえで AUR ヘルパーから再ビルドする、という順番が定番です。

AUR ヘルパーとパッケージ名の選び方

AUR 本体は「ビルドレシピの集合」であり、公式の pacman フロントでは直接は扱いません。多くのユーザーは yay や paru のような AUR ヘルパーを使い、検索・依存解決・ビルドをまとめて行います。ヘルパー自体の導入は Arch Wiki の該当ページに従うのが確実なので、本稿ではコマンド例を示すに留めます。

実際の PKGBUILD 名はフォークやメンテ状況で変わります。検索すると clash-verge 系、clash-verge-rev 系、-bin サフィックス付き（バイナリ同梱でビルド時間短縮）などが並ぶことがあります。-bin はビルド負荷が低い反面、配布元のバイナリに依存するため、メンテナとダウンロード先の信頼性を AUR コメントとソース URL で確認してください。どれを選んでも「購読を取り込み、コアを起動し、システムプロキシまたは TUN でトラフィックを載せる」という利用の骨格は同じです。

インストール後、実行ファイルの場所を把握しておくと後述の systemd 設定が楽です。例として次のように確認します（パッケージ名は環境に合わせて読み替えてください）。

pacman -Ql パッケージ名 | grep /usr/bin/
# or
command -v clash-verge
command -v clash-verge-rev

出力された絶対パスを、そのまま ExecStart= に使えることが多いです。メニューから起動できるがパスが分からない場合も、上記で特定できます。

初回起動：コア取得、権限、システムプロキシ

初回に Mihomo コアのダウンロードや配置を促す UI が出るビルドがあります。企業ネットワークやセキュリティ製品が GitHub 等への HTTPS を制限していると、ここで失敗し「画面は開くが接続できない」状態になりがちです。用語と全体像は チュートリアルページ も参照してください。

TUN モードを有効にする場合は、カーネル・nftables／iptables・capabilities など OS 側の要件が増えます。仕組みの深掘りは TUN モードの記事 に譲りますが、Arch では初手で TUN に飛ばず、まず システムプロキシ だけでブラウザが期待どおり動くかを切り分けると安全です。Wayland セッションではトレイ挙動や権限ダイアログの出方が X11 と異なることもあるため、不具合報告を検索するときは「DE 名＋ Wayland」をキーワードに含めると当たりやすくなります。

💡 ヒント 他社製の常駐 VPN や社内 ZTNA クライアントと同時に TUN を有効にすると、ルーティングや DNS が競合して片方だけ通信不能になることがあります。切り分けのときは一度どちらかを完全終了してから再接続を試してください。

購読（サブスクリプション）のインポートと更新

プロバイダから渡された 購読 URL を Clash Verge のサブスクリプション画面に登録し、手動またはスケジュールで 更新 を実行します。User-Agent や更新間隔はプロバイダの案内に合わせるのが安全です。URL が切れた・認証に失敗する場合の整理は 購読 URL の解説記事 にまとめてあります。

複数プロファイルを運用するときは、表示名と「いまアクティブなプロファイル」を常に意識できる状態にしておくとミスが減ります。ローカル YAML を直接編集する場合は、購読の自動更新で上書きされないよう、クライアントのマージやオーバーライド機能の有無を先に確認してください。ルールを足したい場合の基本は カスタムルールのガイド が参考になります。

systemd --user でログイン後に自動起動する

毎回ランチャーから起動するのが負担なら、systemd のユーザーサービスに登録する方法があります。単位がユーザーセッション側である点は Ubuntu 記事で触れた内容と同じですが、Arch では ExecStart に書くバイナリパスが AUR パッケージ由来のため、前述の command -v で実測した値を使うのが確実です。

手順 1：ユニットファイルを置く

次の例を ~/.config/systemd/user/clash-verge.service に保存します。ExecStart はご自身の環境の絶対パスに差し替えてください。

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

[Service]
Type=simple
ExecStart=/usr/bin/clash-verge
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

Wayland 下でディスプレイ関連の環境変数が不足し GUI が起動しない場合は、デスクトップ環境のドキュメントに沿って Environment= を追加する必要が出ることがあります。まずは最小構成で試し、journalctl --user -u clash-verge.service -b の一行目から確認すると早いです。

手順 2：有効化と状態確認

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

active (running) が確認できれば、ユーザーセッション上でプロセスが立っています。再ログイン後も自動起動するかを必ず確認してください。

補足：ログイン前から動かしたいケース

ユーザーサービスは原則「そのユーザーがログインしたあと」に起動します。ディスプレイマネージャより前に常駐させたい、という要件は GUI クライアントとは相性が悪いことが多く、loginctl enable-linger など別設計が必要になる場面もあります。一般的なデスクトップ用途では ログイン後の自動起動 で十分なことがほとんどです。

代替：XDG autostart の .desktop

~/.config/autostart/*.desktop を置く方法もあります。設定が短く、表示セッションとの相性トラブルが少ない一方、失敗時の自動再起動は systemd の方が扱いやすいです。好みと運用で選んでください。

トラブルシューティングのチェックリスト

  1. 1

    購読とプロファイル

    期限切れ・メンテ・URL 再発行で止まっていないか。エラー文をそのまま検索すると FAQ に当たりやすいです。

  2. 2

    systemd ユーザーログ

    journalctl --user -u clash-verge.service -b で ExecStart の誤りや権限エラーを確認します。ユニット名はファイル名に合わせてください。

  3. 3

    AUR ビルドと依存

    yay -S や paru -S のログに失敗理由が出ていないか。ローリング直後は公式側の更新待ちが必要なこともあります。

よくある質問

AUR と公式リポジトリ、どちらが安全？

「公式か非公式か」より、PKGBUILD の内容・メンテ頻度・コメントの健全性を見る姿勢が重要です。初めてのパッケージはビルドスクリプトのダウンロード先を必ず確認し、不審なら使わないでください。

手動起動と systemd で二重に立ち上がらないか

両方有効にするとプロセスが二重になることがあります。運用はどちらかに寄せるか、クライアント側の「起動時に開く」設定と systemd を重ねないようにしてください。

Ubuntu の記事の systemctl 行をそのまま使ってよいか

コマンド列そのものは多くがそのまま通用しますが、ExecStart のパスとパッケージ名は必ず Arch 側で取り直してください。.deb 前提のパスを写すと即座に失敗します。

まとめ

Arch Linux で Clash Verge を安定運用するコツは、「Ubuntu／Fedora の手順書から画面操作だけ借りて、パッケージ取得とバイナリパスは AUR／pacman 前提で取り直す」ことに尽きます。購読の取り込み、systemd --user による自動起動、ログの見方は他ディストリと共通する部分が大きいので、本稿で触れた内部リンクを辿ると全体像が掴みやすくなります。

クライアントの入手先と各 OS の説明は 本サイトのダウンロードページ に集約してあります。日々のインストール媒体の確認にはそちらを優先し、ライセンスやソースの参照だけを GitHub などに分けると迷いが減ります。

→ Clash を無料ダウンロードし、Arch 以外の端末でも同じ考え方で試す