0本稿で「完了」とみなす状態
ゴールはシンプルに言うと次のとおりです。入手経路が問われる安定ビルドが起動し、購読または同等のリモート構成から生成したプロファイルがアクティブで、Proxies にノードが見え、Clash Verge Rev のトグルから システムプロキシが期待どおり同期され、ブラウザで出口が切り替わる。ここまで揃えば UDP 配下や全体トンネルを載せたい動機に合わせて TUN モードの別稿や カーネル／スタックの整理記事へ進んでも、原因の切り分けが一気に楽になります。逆にいま Linux 版 Mihomo を systemd だけで常駐させている構成なら、GUI 前提の本ページとはポートと責務がぶつかりやすいので、まずどちらを正にするか決めてください。ヘッドレス寄りの型は Linux Mihomo・systemd・分流の記事が押さえています。
Arch Linux はrolling更新の代表格で、ライブラリ版とカーネル版の進みが速いことが長所でもあり、Electron 系 GUI が要求する共有オブジェクトの下限が日々わずかに動くこともあります。検索ワードとして「Arch Linux プロキシ クライアント」を足してくる読者は、固定版ディストリビューションの手順をそのまま流用すると依存の解釈でずれるため、pacman／AUR の語感で読み替える必要があります。EndeavourOS や Manjaro のように Arch 派生であっても大枠は同じですが、ミラーの既定、セキュアブートの初期状態、デスクトップ既定（KDE と GNOME の差）など細部は違います。特に Manjaro は独自ホールドのニュアンスがあるので、AUR パッケージの説明欄とフォーラムの実報告をセットで見る癖をつけると安全です。
1始める前の確認：派生版・権限・競合
まず cat /etc/os-release から系譜を確認し、純粋な Arch か派生かを言語化します。次に uname -r と uname -m でカーネルとアーキテクチャを押さえ、リリース一覧の x86_64／aarch64 表記と突き合わせます。AUR でビルドする前提なら base-devel グループ相当が揃っているかを pacman -Qg base-devel などで軽く点検し、ヘルパーとして yay か paru のどちらかが実行できることも確認します。初回インストール直後の最小構成では git すら入っていないこともあるので、必要なら sudo pacman -S --needed git を先に済ませます。セキュリティ観点では AUR の PKGBUILD を丸ごと信用せず、ソース URL とチェックサムを眺める最短レビューを挟むのが望ましいですが、本稿では手順の幹に集中します。
- ブラウザ拡張プロキシを常時オンにしていると、システム欄が正しくても見かけ上の出口が二重化します。検証ウィンドウだけでもオフへ寄せると切り分けが速いです。
- 商用 VPN の全トンネル常駐と併用していると、誰がルートを握っているかログを読まないと結論が出ません。テストでは片方を一時停止するのが安全です。
- 企業ポリシーで PAC 固定の端末では GNOME の手入力が灰色のままということがあります。権限とポリシー確認が先です。
関連：購読更新の 403／タイムアウトは初回導入の外側に出やすい不具合なので、別稿とログ照会をセットにしてください。
2導線の選び方：AUR、公式バイナリ、AppImage
pacman の追跡下に置きたいなら AUR が第一候補です。実際のパッケージ名はコミュニティのメンテ状況で前後するため、ここでは固定表記を避け、検索キーワードとして「clash verge rev」「verge rev」を yay やブラウザの AUR ページに打ち込む型を推します。-bin 系はビルド時間を短縮しやすい一方、上流配布物への追従がメンテ依存です。ソースから組み立てる系は時間はかかりますが、ローカル toolchain と相性の確認に向きます。AppImage はホーム配下へ置いて試すのに向き、アンインストールもファイル削除で済みやすい反面、デスクトップ統合や自動更新まわりは手作業が増えがちです。rolling 環境で「今日だけ触りたい」なら AppImage、「毎日のデスクトップ実務」なら AUR、という粗い分岐で十分です。
固定リリースの Debian 12 向け記事や Ubuntu 24.04 向け記事は apt と .deb の語彙に最適化されています。Arch で同款を探す読者は語彙ごとページを跨いでも構いませんが、依存解決のコマンドとトラブルの典型が変わる点だけは取り違えないでください。誤って両系統の手順を混ぜると、「存在しない apt サブコマンド」を叩いたり、逆に AUR を pacman 単体で入れようとして止まったりします。
3AUR（yay／paru）で入れる典型例
以下は例示であり、実際のパッケージ名は検索結果を優先してください。ヘルパーが対話的にビルド依存を増やすので、画面に出た不足品はそのまま承認して構いません。初回はキーチェーンや GPG の質問が挟まることもあるため、端末を閉じずに最後まで見ます。ビルドキャッシュが肥大化したら paccache などの運用は別途整理で十分です。
# Example with yay (package name from search results)
yay -S package-name-listed-in-aur
# Example with paru (same idea; replace with resolved name)
paru -S package-name-listed-in-aur
完了後はアプリケーションメニューから起動できるか、もしくは command -v clash-verge のような実行体名の有無を確認します。名前はパッケージの .desktop ファイルに依存するので、pacman -Ql で実際にインストールされたパスを見ると早いです。更新は通常 yay -Syu／paru -Syu に乗りますが、AUR 側だけピンポイントで再ビルドしたいときはヘルパーの対話オプションを読み、衝突するローカル変更が無いかも確認してください。メジャーアップデート直後にウェブキットまわりの再リンクが必要になることは珍しくありません。その場合は一度ログアウト／再起動を挟むと挙動が揃うことがあります。
注意：AUR はユーザー投稿です。公式 GitHub とチェックサムを自分の目で一度突き合わせるクセを付けると、サプライチェーン事故の表面化が早くなります。
4AppImage を試す最短手順
ポータブルに試すなら公式リリースの AppImage を取得し、書き込み可能な場所へ置いて実行権を付与します。USB メモリの読み取り専用マウント上だと失敗しやすいので避けます。初回に統合ダイアログが出ても必須ではありません。標準エラーにライブラリ名が並ぶ場合は、その記号を手掛かりに pacman -F で所属パッケージを当て、足りない分だけ追加します。乱暴にメタグループを一式入れてしまうとrolling環境の清浄さが落ちるので、メッセージ駆動で段階的に足す方が安全です。
chmod +x ~/Applications/Clash.Verge_*_x86_64.AppImage
~/Applications/Clash.Verge_*_x86_64.AppImage
実行ファイル名とアーキテクチャ接尾辞はリリース資産ごとに異なります。uname -m が aarch64 なのに x86_64 資産を落とすような取り違えがもっとも多いので、フォルダに保存した直後にファイル名を再確認してください。Wayland か X11 かでもトレイ挙動が微妙に変わりますが、本文の本筋には影響しにくいです。
5TUN を触る前に押さえるカーネルと権限
まずは システムプロキシだけで疎通を通すのが失敗率低めです。TUN をオンにする段では /dev/net/tun の有無、他プロセスとのルート競合、capabilities や polkit ダイアログで拒否していないかを順に見ます。rolling ではカーネル更新直後に外付けモジュールの再ビルドが必要な環境もありますが、一般的なデスクトップ用途ではデフォルトの virtio／generic パスで足りることが多いです。スタックを gvisor 系へ寄せるか system 側へ寄せるかの議論は 専用の比較記事に委ね、ここでは「システムプロキシでノードが生きていることを先に確証する」ことだけ繰り返します。
セキュアブート有効マシンではカスタムモジュール方針が絡む例もあります。派生ディストリビューションでは初期値が異なるので、ハードウェアごとのフォーラムスレッドを一度見ておくと安心です。CLI からの検証では ip route の既定と、Clash ログに出る policy 名の対応を追うと早いです。
6初回起動と画面の見どころ
左側ナビの Profiles・Proxies・Logs・設定の位置付けは Linux でも安定しています。初回のみ ファイアウォール の許可や キーリング のパスフレーズ、Wayland 下でのシステム統合ダイアログが挟まることがあります。断ってしまうと特定機能だけが静かに失敗するタイプなので、同じ操作をもう一度辿って再提示します。トレイアイコンが見えないときは拡張やステータス領域の折り畳みに紛れているだけということがあるので、プロセス一覧で名称検索し、落ちたのか隠れたのかを分けます。
7購読の取り込みとプロファイル優先
購読 URL を Profiles に追加して更新し、アクティブなプロファイルとして読み込ませます。時計ずれだけで TLS が破綻する事例はどのディストリビューションでも起きるので timedatectl を一瞥します。自動更新間隔を詰めすぎると運営側のレートリミットで一時的に 403 を踏むことがあり、ログの見え方が「設定ミス」に見えがちです。Proxies ではまず単一ノードを手動選択し、遅延表示が妥当かを見てから自動グルーピングへ進むと変数が減ります。RULE・DIRECT・REJECT の見え方は後続の ルール並びの記事に直結するので、ログの policy 名をメモする癖を付けてください。購読 URL を公開チャットに貼るのは鍵流出に直結するので避けます。
合格ライン：購読更新がエラーなく終わり、Proxies にノード列が見え、致命的な TLS 連打がログに出ていないこと。
8システムプロキシをオンにして DE と突き合わせる
Clash Verge Rev 側の システムプロキシ相当トグルをオンにします。GNOME なら 設定 → ネットワーク → プロキシ にローカル待受が入るのが期待どおりです。KDE Plasma でも同趣旨の場所に反映されますが、アプリ名とメニュー階層が派生版で多少異なります。Wayland 下でイベントが短時間詰まると欄が空のまま見えることがあるので、数秒待ってから開き直す程度で十分です。ブラウザ側で「システム設定を使用する」がオフのままだと、OS は合っているのに表示だけ変わらない事故が起きます。Firefox と Chromium 系の両方で一度確認します。
# Example (GNOME): read proxy schema keys
gsettings list-recursively org.gnome.system.proxy
CLI から外向き HTTP を試すならその場で http_proxy を export するやり方も有効ですが、混合ポートと HTTP／SOCKS の取り違えに注意し、アプリ画面の表示と突き合わせます。
9初回疎通の見え方と落とし穴
ブラウザで出口確認サイトを開き、普段の回線と違う経路になっているかを見ます。DNS の厳密な漏れ対策まで踏み込むのは次の段階でよく、本稿のラインはここまでです。速度が伸びないときはノード輻輳か、ルールが意図せず遠回りしている可能性を疑い、ログでマッチした policy を追います。ポート記憶違いは頻発するので ss -lntp で LISTEN を眺める手段も有効です。sudo が必要ならその場だけ付与し、常時ルートは避けます。検証タブが二つあるとき片方だけ拡張プロキシがオンだと出口が分岐するので、ウィンドウ単位で状態を揃えます。
典型的なつまずき：優先して確認する順序
・yay／paru が無い：公式手順に従いヘルパーを入れてから再実行。会社端末ではビルド自体が禁止されていることもあります。
・AUR ビルドが途中で止まる：GPG かネットワークかをログで切り分け、社内プロキシが git clone を壊していないか確認します。
・AppImage が即終了：読み取り専用メディア上でないか、足りない共有ライブラリを stderr で特定してから pacman -S で一段ずつ足します。
・システムプロキシ ON なのにブラウザだけ直結：ブラウ側の固定設定と拡張を先に疑い、DE の欄が空ならトグルを再度発火します。
・購読は通ったがノードゼロ：リモート側設定の空配列やメンテによる一時偽空を疑い、HTTP ステータスを手掛かりにします。
・TUN だけ即失敗：まずシステムプロキシで生存確認し、権限と競合サービスを整理してからスタック記事へ進みます。
FAQ
rolling 環境で検索語が分散しやすいテーマなので、導入経路と運用モデル別に並べました。ログの読み方は関連チュートリアルへ広げてください。
AUR と AppImage はどちらを優先しますか？
日常運用を pacman で追いたいなら AUR、素早く試すなら AppImage、の二択が扱いやすいです。同時常駐は避け、切り替え時は Quit まで含めて一方を止めます。
Manjaro／EndeavourOS 固有の注意は？
ミラーとホールド、既定 DE、初期セキュアブート方針が本家 Arch と完全一致しないことがあります。AUR ページのコメント欄とフォーラム実報を必ず一度読みます。
TUN を最初からオンにしてもよい？
システムプロキシでノードとルールが生きていることを確認してからの方が切り分けが楽です。内核スタックの細部は専用記事へ委譲します。
yay と paru の違いは？
どちらも目的は同じで、レビュー習慣と出力の好みで選べます。初回ビルド時間にだけ余裕を持ってください。
ヘッドレスサーバーは対象？
GUI 前提の手順はデスクトップ向けです。SSH 先のみなら Mihomo と systemd の記事へ切り替えます。
購読 403／timeout のときは？
期限切れ URL、UA 制限、レートリミットを疑い、購読エラー向け記事とログを突き合わせます。
まとめと次のステップ
Arch 系での本筋は 入手経路の決定（AUR か AppImage）→ ビルドまたはポータブル起動 → 購読更新 → Proxies で出口確認 → システムプロキシ同期 → ブラウザ検証、の順です。rolling ならではの速い更新は得意分野ですが、Electron 系 GUI と共有ライブラリの追従コストもセットで受け止める必要があります。次段では TUN／ルール優先／購読障害の深掘りへ広げられるよう、ログを開く癖だけでも早めに付けておくと後工程が軽くなります。
多くの代替クライアントは設定ファイルの手編集や端末前提が強く、トレー切替や視覚的なログビューまで含めると導線が分裂しがちです。可視化されたまま Mihomo と向き合えるツールは初日のつまずきを減らしやすく、rolling の試行錯誤とも相性が良いです。まだ手元にまとまった入手先が無ければ、公式資産をアーキテクチャ一致で選び、必要に応じて Clash の入手ページから関連ビルドへ跳んでください。試験は許可された構成の範囲に留め、ログとポリシーを読みながら徐々に本運用へ寄せるのが安全です。