まずOSとCPUアーキテクチャに合ったパッケージを選び、次に実行環境を確認します。WindowsではWPF版とAvalonia版を選べます。macOSとLinuxでは、それぞれのOS向けAvalonia版を選びましょう。本記事では、画面を構成するフレームワークとプロキシコアの違い、パッケージ名の見方、起動できない場合の確認手順、既存の設定を残して別の版を試す方法を解説します。
画面フレームワークとプロキシコアの違い
WPFはWindows向け、Avaloniaはクロスプラットフォーム対応のデスクトップUIフレームワークです。v2rayNでは、ウィンドウやリスト、メニューなどの画面と操作を主に担います。プロキシプロトコルではなく、サーバー側に特別な接続方式への対応を求めるものでもありません。WPF版からAvalonia版に替えても、VMessをVLESSに変更する必要はありません。
実際の接続処理を担うのはプロキシコアです。v2rayNの画面側はサーバー情報を保存し、設定を生成してコアのプロセスを管理します。Xrayなどのコアがプロトコルやルーティング、外部への接続を処理します。そのため、「画面が起動するか」と「プロキシ接続できるか」は別々に確認します。画面が起動しても、コアファイルやノード情報、システムプロキシ、ルーティング設定の確認が必要です。
| 比較項目 | WPF版 | Avalonia版 |
|---|---|---|
| 対応OS | Windows | Windows、macOS、Linux。実際の対応状況は各リリースの配布ファイルで確認 |
| 画面の実装 | WindowsのデスクトップUIと操作体系 | クロスプラットフォーム対応のUIとウィンドウ体系 |
| 主な選択理由 | 使い慣れたWindowsの操作方法を維持できる | 異なるOS間で似た画面構成を使える |
| 接続機能の判断基準 | 画面フレームワーク名だけでなく、使用するコア、ノードのプロトコル、設定を確認 | |
| OSとの連携に関する違い | トレイ、スタートアップ、システムプロキシ、権限の扱いはOSの影響を受ける | |
「クロスプラットフォーム」は、1つのアーカイブがすべてのOSでそのまま動くという意味ではありません。Avaloniaで共通化されるのは画面技術であり、アプリ本体や同梱コアにはOSとアーキテクチャごとの違いがあります。また、WPF版かAvalonia版かだけで通信遅延の優劣は判断できません。通信性能を比較する場合は、ノード、コア、ルーティング、テスト対象をそろえてください。
Windowsとクロスプラットフォーム環境での選び方
現在のWPF版が安定して動作しており、サブスクリプショングループやサーバー一覧、システムプロキシなど普段の操作に問題がなければ、画面の名称だけを理由に移行する必要はありません。WindowsとLinuxを併用する場合や、macOSでも近い操作感を求める場合は、Avalonia版を試す価値があります。リリースによってメニューの位置が変わることがあるため、画面をピクセル単位で照らし合わせないでください。
利用環境に合わせて選ぶ
主にWindowsを使う
- WPF版に慣れていて問題なく動いているなら、対応するビルドをそのまま使えます。
- 複数のOSで操作方法をそろえたい場合は、別のフォルダーにAvalonia版を入れて試せます。
- トレイ表示、画面の拡大縮小、よく使うショートカットが使いやすいか確認しましょう。
macOSまたはLinuxを使う
- Windows版ではなく、対象OS向けのAvalonia版を選びます。
- デバイスのアーキテクチャに合わせてx64とarm64を選びます。
- デスクトップ環境のトレイ対応、実行権限、プロキシ設定をそれぞれ確認します。
まずOSとアーキテクチャに合うものを選び、その後に操作感を比較しましょう。画面の選択だけで接続設定が済むわけではありません。
高解像度ディスプレイでの文字サイズやリストの表示密度、右クリックメニュー、ウィンドウの拡大縮小は、実機で確かめるのがおすすめです。Linuxのトレイ表示はデスクトップ環境や拡張機能にも左右されます。macOSでは、ウィンドウを閉じたときにアプリが終了するかどうかも確認してください。ウィンドウが消えたら、別のプログラムを起動する前にメニューバーやトレイで動作状態を確認しましょう。
パッケージ名と実行環境
パッケージを選ぶときは、「OS → CPUアーキテクチャ → 画面の種類 → 配布形式」の順に、ファイル名とリリースノートを確認します。ファイル名のwindows、linux、macosは対象OS、x64とarm64は対象アーキテクチャを示します。wpfの表記はWPF版を区別する目印です。表記がない場合も、ダウンロードページの説明と照らし合わせて判断してください。単語がないことだけを根拠に決めないようにしましょう。
- Windows：「設定」→「システム」→「システム情報」を開き、「システムの種類」を確認します。Windowsのバージョン番号とCPUアーキテクチャは別の情報です。
- macOS：Appleメニューから「このMacについて」を開き、チップまたはプロセッサの情報を確認します。Appleシリコン搭載機では、対応するarm64ビルドを選びましょう。
- Linux：ターミナルで
uname -mを実行します。一般にx86_64はx64、aarch64はarm64に対応します。リリースノートに記載されたシステムライブラリの要件も確認してください。 - 配布形式：インストーラー、アーカイブ、アプリパッケージでは起動方法が異なります。アーカイブはすべて展開してください。圧縮ファイルのプレビュー画面から実行ファイルだけを起動するのは避けましょう。
どちらの画面も.NET技術を使用していますが、実行環境を別途インストールする必要があるかどうかは、ビルドの配布方式によります。自己完結型ビルドには必要な.NETランタイムコンポーネントが含まれています。一方、フレームワーク依存型ビルドは、システムにインストール済みの互換ランタイムを使用します。自己完結型でもOSのコンポーネントが一切不要になるわけではありません。特にLinuxでは、システムライブラリやグラフィカル環境の要件に注意してください。
画面の実行環境とコアファイルの問題は分けて考えます。ランタイム不足は通常、ウィンドウが表示される前に起きます。画面は正常に開くのに、ログにコアが見つからない、実行権限がない、起動できないと出る場合は、同梱コアとそのパスを確認します。メインプログラムだけをコピーすると、設定リソースやコアのフォルダーが抜けることがあります。
設定を残して別の画面を試す
別のフォルダーにインストールして試し、現在動作しているフォルダーを直接上書きしないでください。同じOSの近いバージョン間なら設定データを再利用できる場合がありますが、異なるバージョンのデータ構造やOSごとのパスが完全互換だとは限りません。まずバックアップを取り、サブスクリプションからノードを復元した後、ローカル設定を一つずつ確認するのが安全です。
-
既存の設定を控える
元のアプリで「設定」→「パラメーター設定」を開き、ローカルの待ち受けポートやLAN接続の許可などを控えます。メイン画面のシステムプロキシの状態、ルーティングの選択、サブスクリプショングループのURLも記録してください。終了前に、元のアプリのデータフォルダーをバックアップします。
-
古いアプリを終了する
トレイメニューから「終了」を選び、アプリ本体とコアのプロセスが停止したことを確認します。ウィンドウを閉じただけではバックグラウンドで動き続ける場合があります。その状態で別のアプリを起動すると、待ち受けポートが競合することがあります。
-
別のフォルダーから起動する
当サイトのダウンロードページから対象OSのビルドを選び、配布形式に応じてインストールするか、新しいフォルダーにすべて展開します。まずメインウィンドウが正常に表示されることを確認し、その後でノードとシステムプロキシを設定してください。
-
サブスクリプションを再設定する
「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、元のURLを追加して保存します。その後、「サブスクリプショングループ」から更新を実行してノードを取得します。グループの編集方法は画面によってボタンやメニューに分かれる場合があります。同じ機能名を目印に探してください。
-
接続を確認する
ノードを選択し、TUNをオフにした状態で、メイン画面のシステムプロキシメニューから「システムプロキシを自動設定」を選びます。通常のブラウザーでアクセスできることを確認してから、カスタムルーティング、DNS、その他の通信制御設定を戻してください。
サブスクリプションで復元できるのは主にサーバー情報であり、クライアントの設定すべてではありません。カスタムルーティング、待ち受けポート、ホットキー、ウィンドウ配置、ローカルファイルのパスは個別に確認してください。OSを変更すると、旧フォルダー内の絶対パスが特に使えなくなりやすいので注意が必要です。サブスクリプションURLには認証情報が含まれる場合があります。移行時のメモやスクリーンショットは安全に保管し、URL全体を公開しないでください。
起動と接続を切り分けて確認
まず問題がどの段階で起きているかを特定します。ダブルクリックしてもウィンドウが表示されない場合は、OS、アーキテクチャ、実行環境を確認します。ウィンドウは開くのにノードを起動できない場合は、コアのログを確認します。ノードが起動してもブラウザーがプロキシを経由しない場合は、システムプロキシとポートを確認してください。この順番なら、実行環境の問題をサブスクリプションの不具合と誤認しにくくなります。
たとえば、「設定」→「パラメーター設定」に表示されるローカル待ち受けポートが10808で、ログにaddress already in useと出る場合は、まず古いコアがそのポートを使用していないか確認します。以下のコマンドは使用状況を確認するだけで、設定は変更しません。実際のポートが10808以外なら、画面に表示された値を使ってください。すべてのビルドでHTTPとSOCKSのポートが同じように用意されているとは限りません。
# Windows：ターミナルでポートの使用状況を確認する例
netstat -ano | findstr :10808
# Linux：サンプルポートを待ち受けているプロセスを確認
ss -lntp 'sport = :10808'
# macOS：サンプルポートを待ち受けているプロセスを確認
lsof -nP -iTCP:10808 -sTCP:LISTEN出力に表示されたプロセスを特定してから、どのアプリを終了するか判断してください。見覚えのないシステムプロセスをむやみに停止しないでください。クライアントの待ち受けポートを変更した場合は、プロキシを手動設定しているアプリのポートも合わせて変更します。ブラウザーがシステムプロキシ経由で接続できても、それはその経路が使えることを示すだけです。すべてのコマンドラインツールやシステムプロキシを参照しないアプリが、同じ接続を自動的に使うわけではありません。
パッケージ選びと移行に関するよくある質問
WindowsでもAvalonia版に切り替える必要がありますか？
切り替える必要はありません。現在のWPF版で問題がなければ、そのまま使えます。画面を比べたい場合は、データをバックアップしてAvalonia版を別のフォルダーで試し、トレイ、ウィンドウの拡大縮小、サブスクリプション管理、システムプロキシなどの日常操作を確認してください。元のフォルダーを直接上書きしないようにしましょう。
画面を切り替えても、以前のサブスクリプションは使えますか？
画面フレームワークを変えても、サブスクリプションURLは変わりません。「サブスクリプショングループ」→「サブスクリプショングループ設定」でURLを追加し、更新して確認してください。解析に失敗する場合は、サブスクリプションの形式やURLの有効性、コアのプロトコル対応を確認しましょう。WPF版とAvalonia版でノードを共有できないと決めつける必要はありません。
ランタイムをインストールしても起動できないのはなぜですか？
エラーメッセージに記載されたフレームワーク名、メジャーバージョン、アーキテクチャを確認し、パッケージをすべて展開できているかも確認してください。WPF版に必要なDesktop Runtimeと通常のRuntimeは別物です。Linuxではターミナルから起動して出力を確認し、システムライブラリ不足や実行権限のエラーがないか調べましょう。
一方の版では接続できるのに、もう一方ではWebページが開かないのはなぜですか？
まずもう一方のアプリを終了し、ポートの競合を避けます。次にノード、コア、ルーティング、DNSを比較してください。メイン画面のシステムプロキシメニューから設定し直し、アプリに手動設定したプロキシポートも確認します。これらの条件をそろえて初めて、接続結果を比較できます。
古いフォルダーをそのままコピーしてもよいですか？
まず元のフォルダーを複製して保管してください。OSをまたいでフォルダー全体を上書きするのは避けましょう。実行ファイルやコア、パスが異なる場合があります。サブスクリプションを再登録してから、以前のルーティングやポートを設定し直してください。設定データを移行する場合は、移行先バージョンの互換性に関する説明を先に確認します。
選び方は、パッケージがOSとデバイスに合っているか、実行環境の要件を満たしているか、普段の操作に合うかの3点で整理できます。Windowsでは使い慣れた操作に合わせて2つの画面を比較し、macOSとLinuxでは対象OS向けのAvalonia版を選びましょう。通信に問題がある場合は、コア、ノード、プロキシの適用方法を確認してください。画面の名称だけで接続機能を判断しないことが大切です。