Ubuntu デスクトップで Verge Rev と AppImage を選ぶ理由
Linux で Clash/Mihomo を使う一般的なルートは、パッケージやバイナリを入れて config.yaml をエディタで弄り、必要なら systemd ユニットを自作する流れです。Ubuntu デスクトップ利用者にとって、初日からその全要件を満たすのは負荷が高く、購読 URL の反映や接続ログの追跡もターミナル前提になりがちです。Clash Verge Rev は購読・ルール・接続状況を GUI に寄せやすく、検索で「インストール」「購読」を併記する利用者の期待に沿いやすいのが利点です。
配布形式としての AppImage は、公式ビルドを一ファイルで受け取り、ディストリのリポジトリ事情に振り回されにくい反面、FUSE や実行権限まわりで躓く人が一定数います。本稿ではその典型を先に潰し、システムプロキシでブラウザ疎通まで持っていく順序を固定します。クライアント一般の比較は クライアントの選び方 に譲り、本稿は Ubuntu 上の Verge Rev・AppImage に絞ります。
すでに無頭サーバーやゲートウェイ用途で TUN を論じた記事(例:Ubuntu で TUN と systemd)とは役割が違います。同じ Ubuntu でも、デスクトップの「まず画面で通す」ニーズと、ルーター直前の透過プロキシ設計は読み替えが必要です。
事前確認:ディストリ版、表示サーバ、他 VPN、管理ポリシー
企業や学校支給の端末では、追加インストールやトンネル利用自体がポリシーで禁止されていることがあります。プロキシや購読 URLの取り扱いも契約上の秘密情報です。いきなり GUI を開く前に、運用側の許諾と利用規約を確認してください。
常駐する別 VPN 製品は、ルートや iptables/nft、あるいは全トラフィックの捕獲を握り、Clash Verge Rev で System Proxy を ON にしてもブラウザが期待どおり流れない原因になります。検証時は片方を止めて差分を見るのが最も早い切り分けです。
Ubuntu のディスプレイ環境は X11 と Wayland が混在します。Electron 系 GUI は版によってトレイ挙動や権限ダイアログの出方が微妙に変わるため、「スクリーンショット記事のラベルが手元と一致しない」場面は想定内です。画面上の英語名(Profiles/Subscriptions/System Proxy など)は、手元ビルドに合わせて読み替えてください。
入手は ダウンロードページ を主軸にし、見知らぬミラーや「改造版」は購読トークンごと漏洩するリスクがあるため避けます。AppImage でも配布元のチェックサムやリリースノートを確認できるなら確認してください。
正規入手と AppImage の保存場所
一般的な流れは、リリース一覧から Linux 向けの AppImage を取得し、ホーム直下の Applications や ~/bin など、バックアップ方針が決まった場所へ保存します。ファイル名にバージョンが含まれる場合は、複数世代を混在させないよう整理しておくと、アップデート後の挙動差の切り分けが楽です。
ブラウザのダウンロードフォルダのまま起動しても動くことはありますが、誤削除しやすいので、運用ディレクトリへ移してから権限を付けるのをおすすめします。Clash Verge Rev 初回起動時にはユーザーディレクトリ配下に設定やキャッシュ、Mihomo バイナリの展開が走るため、数分以内にディスク書き込みが増えるのは正常寄りの挙動です。
実行権限・FUSE・起動コマンド
ターミナルで保存先へ移動し、実行ビットを付けます。例として次のような流れです(ファイル名は実際のものに読み替え)。
Terminalchmod +x ./Clash.Verge.Rev-*-linux-amd64.AppImage
./Clash.Verge.Rev-*-linux-amd64.AppImage
Ubuntu 22.04 以降では、AppImage が内部で期待する libfuse2 が入っていない環境があり、「fuse」「FUSE」「failed to open fuse」系のメッセージで起動に失敗することがあります。その場合は sudo apt install libfuse2 のように依存を追加して再試行するのが典型です。組織標準イメージでは apt がロックされていたりプロキシ越しになることもあるため、社内手順に従ってください。
ARM64 端末を使っている場合
ARM64 の Ubuntu では、ファイル名やリリース表記に aarch64/arm64 が含まれるビルドを選びます。amd64 用バイナリを無理に走らせると qemu や互換層の話に進み、初日の目的から外れます。
初回起動:コア展開とトレイ/メインウィンドウ
初回はバックグラウンドでコアの取得検証が走り、トレイアイコンやメインウィンドウの表示が遅れることがあります。何も起きないように見える場合は、プロセス一覧にアプリと mihomo 名のプロセスがいるか、ログに権限エラーがないかを確認してください。
Wayland 下では「バックグラウンドでの実行」や通知まわりの許可を求められることがあります。不要な権限は与えない方針で、機能を使う段階で足していくのが無難です。セキュリティソフトが実行をブロックしているケースでは、例外ルールの登録が必要になることもあります。
購読 URL の取り込みとプロファイル生成
プロバイダから受け取った 購読 URL(クエリに秘密トークンが付く形式は第三者と共有しない)を、Subscriptions/購読追加に相当する欄へ貼り付けます。表示名と更新間隔(例として 1440 分=一日一回)を設定し、更新 または Apply を実行してノード一覧が流し込まれるかを確認してください。
更新が失敗するときは、URL の打ち間違い、期限切れトークン、プロバイダ側のレート制限、キャッシュ CDN の挙動などを疑います。HTTP ステータス別の切り分けは 購読更新エラー記事 が速いです。リストの健全性は 購読とノード管理 も参考になります。
既存 YAML から始める場合
すでに config.yaml がある場合は、設定ディレクトリを開く系のメニューから配置し、GUI でアクティブ・プロファイルにします。エディタ直編集と GUI の両方で同じキーを触ると上書き競合が出やすいので、どちらを正とするか最初に決めてください。
プロファイル・モード・ノード指定
複数の購読やローカル YAML がある場合、画面上部またはサイドで今動かすプロファイルを選びます。続けて Rule/Global/Direct などのモードを指定し、プロキシグループで実際に使うノード(自動選択や url-test 付きグループなど)を選びます。
国内ドメインを直結し、それ以外をプロキシへ流す一般的なルールベースは、初回の挙動把握に向きます。ルール設計を詰めたい場合は ルール分流のベストプラクティス を参照してください。ここまで終えてもブラウザが素通りに見えるなら、次のシステムプロキシ段階が分かれ目です。
システムプロキシで初回疎通(推奨ルート)
Clash Verge Rev 側で System Proxy 相当のトグルを ON にすると、多くの GNOME 系デスクトップでは システム設定 → ネットワーク → 利用中のインターフェース → ネットワークプロキシ に、127.0.0.1 と期待する HTTP/HTTPS ポートが反映されます。ビルドにより mixed-port と SOCKS の対応関係が変わるため、実数値は画面とログの双方で確認してください。
ブラウザでは、(1) 任意の HTTPS サイトで証明書警告が出ないこと、(2) 許可された診断用ドメインで出口が期待に近いこと、を同じセッションで続けて確認します。社内ポリシーで外部 IP チェックが難しい場合は、運用側が許可する代替ドメインに置き換えてください。
ログにトラフィックが出ずブラウザだけ直結に見えるときは、システムプロキシがオフのまま、ブラウザが独自のプロキシ設定を握っている、別 VPN がルートを奪っている、のいずれかを疑います。Firefox はシステム設定を参照しない既定があり得るため、接続設定を「システムのプロキシ設定を使用する」側に寄せる必要がある場合があります。
Checklist — Ubuntu first hop1. Verge: active profile + node selected
2. Verge: System Proxy = ON (label varies by build)
3. OS: Network proxy shows 127.0.0.1 + expected ports
4. Browser: HTTPS OK; egress check matches policy
TUN と systemd は次の段階(関連記事への橋渡し)
TUN を有効にすると、プロキシ非対応アプリや UDP 周りまでまとめてコアへ寄せられますが、権限・カーネルモジュール・他製品 VPN という OS 近傍の話に踏み込みます。Ubuntu デスクトップで「最初から全部をトンネルへ」と考える前に、本稿のシステムプロキシルートで期待挙動を固めると、失敗時の差分がはっきりします。
サーバーや常時オン端末で systemd と権限を詰める読者は、Ubuntu:TUN と systemd の実測手順 を正としてください。ブリッジや nft の話まで含めるなら Linux:TUN と nftables も関連しますが、いずれも本稿の「初日 GUI 導入」とはレイヤが異なります。
うまくいかないときの切り分け
「一度に一手だけ」戻すのがコツです。システムプロキシ OFF → ON、別 VPN 停止、ノード切替、の順で差分を付けます。mixed-port が既に他プロセスに掴まれている症状は ポート競合の記事 がそのまま参考になります(タイトルに Windows があっても論点は共通です)。
AppImage だけが起動しない場合は、実行権限、FUSE 依存、ファイルの破損ダウンロード、セキュリティブロックの順が早いです。Wine や別ランタイムに頼らず、Linux 向け公式ビルドへ戻すのが安全です。
よくある質問
アイコンが出ずすぐ終了する
初回展開の失敗、ディスク容量不足、他セキュリティ製品のブロックが考えられます。ターミナルから起動して標準エラーを読むと原因が早い場合があります。
購読は取れたのに遅いだけのとき
ノード側混雑、ルールによる遠回り、DNS の遅延、IPv6 と IPv4 の組み合わせ、時間帯変動などが典型です。ヒットルールと遅延表示を同時に見ると原因が絞れます。
端末の curl は通るのにブラウザだけ直結に見える
ブラウザがシステムプロキシを参照していない、拡張が別経路を握っている、プロファイル別設定が食い違っている、のいずれかを疑います。Firefox の接続設定と Chromium 系のフラグを切り分けてください。
OSS と入手経路
Mihomo/Clash Meta 系はソースとリリースノートが追いやすい一方で、一般利用者の主たる入手口はサイト上のダウンロード導線に揃え、GitHub は検証用途に割り切ると混乱が減ります。バージョンアップでメニュー表記が変わるたびにスクショ記事が陳腐化するため、最終的にはリリースノートと手元 UI を正としてください。
まとめ
Ubuntu デスクトップで Clash Verge Rev を実用に載せる最短ルートは、正規の AppImage 入手 → 実行権限と FUSE → 購読インポートとプロファイル選択 → システムプロキシでブラウザ疎通を確認の四段です。要件が広がった段階で TUN や systemd を足すほうが、権限と競合の切り分けが楽になります。
一方、単一ボタンの商用 VPN クライアントはルール細工やログの粒度が限られる製品が多く、失敗時に「プロバイダか端末か OS の権限か」を分けにくいです。Clash V.CORE は購読・ルール・ログを同じ文脈に置けるため、今回のような初回セットアップから運用面の微調整まで一気通貫で扱いやすく、のちに TUN やサーバー運用へ広げるときも考え方を揃えやすいです。
具体的な入手と更新は ダウンロードページ から進め、購読運用と接続確認を同じ画面群で完結させましょう。