この記事は、初めてインストールする方、複数のOSで使う方、旧版から移行する方に向けた内容です。重要なのはノードのプロトコルではなく、OS、画面の互換性、設定移行の手間です。WindowsではAvaloniaデスクトップ版とWPF版から選べ、macOSとLinuxではAvaloniaデスクトップ版を使います。インストールパッケージ、設定の保存先、ポート確認方法、移行手順を順に確認できます。
2つの配布系統が解決する課題
v2rayNの「デスクトップ版」は通常、Avaloniaで構築されたクロスプラットフォームのGUIを指します。共通のコード基盤で主要な画面ロジックを動かし、Windows、macOS、Linuxに近い操作体系を提供します。一方、WPF版はWindows Presentation Foundationを使用し、Windowsでのみ動作します。ウィンドウ、トレイ、フォント描画、システムコントロールの挙動は、従来のWindowsデスクトップアプリに近い設計です。
両者は異なるプロキシプロトコルの実装ではありません。VMess、VLESS、Trojan、サブスクリプション解析、ルーティングルール、システムプロキシ制御はクライアントの機能層に属します。実際に接続を処理するのは、通常、選択したCoreです。画面の配布系統を変えてもノードのプロトコルは自動的に変わらず、同じサーバーの暗号化パラメータが変わることもありません。主な違いは、UIフレームワーク、ランタイム依存、OS連携、トラブル対応の方法にあります。
Avaloniaデスクトップ版
おすすめWindows、macOS、Linuxを一括してカバーし、メニュー構成と設定操作を異なるデスクトップOS間で揃えやすい版です。新規インストールの標準選択に向いています。
適した用途：複数OSでの利用、新規ユーザー、操作手順を統一したい場合
WPF版
Windows限定です。システムトレイ、ウィンドウの拡大縮小、アクセシビリティ機能に成熟したWindows向け技術スタックを利用でき、既存のワークフローを安定して使いたい端末に適しています。
適した用途：Windowsのみの利用、既存設定の継続、ネイティブコントロールの挙動を重視する場合
Windows端末でWPF版が長期間安定して動作しているなら、デスクトップ版という名称の違いだけを理由に急いで移行する必要はありません。逆に、新しい端末で過去の設定を引き継ぐ必要がなければ、Avaloniaデスクトップ版を選ぶと、将来ほかのOSでも同じ操作経験を活かしやすくなります。
UI構成とOS依存が日常の使い勝手に与える影響
Avaloniaはウィンドウ、入力、テーマ、描画の各層を抽象化し、OSごとのデスクトップ環境に接続します。クロスプラットフォームで画面構成を揃えやすい一方、特定OSのネイティブコントロールと完全に同じ挙動になるとは限りません。フォントのフォールバック、右クリックメニューの間隔、ウィンドウ装飾、高DPIでの拡大縮小などがWPF版と異なる場合があります。WPFはWindowsのデスクトップ実行環境に深く依存するため、システムテーマ、キーボード操作、多画面環境での拡大縮小はWindowsの操作感に近い傾向があります。
| 比較項目 | Avaloniaデスクトップ版 | WPF版 |
|---|---|---|
| 対応プラットフォーム | Windows、macOS、Linux | Windows |
| 画面描画 | クロスプラットフォーム描画の抽象化 | Windows WPFの描画体系 |
| システムトレイ | 各プラットフォームに合わせて実装され、挙動に多少の違いが出る場合があります | Windowsの通知領域とより直接的に連携 |
| 高DPIでの拡大縮小 | フレームワークとOSの両方の拡大縮小設定を確認する必要があります | 主にWindowsのDPI設定の影響を受けます |
| 設定の基本概念 | サブスクリプショングループ、ノード、Core、ルーティング、システムプロキシ | サブスクリプショングループ、ノード、Core、ルーティング、システムプロキシ |
UIフレームワークによってVLESSやVMessの接続品質が決まるわけではありません。同じノードを両方の配布系統で使い、Core、通信パラメータ、ルーティングルールが同一なら、ネットワーク経路も通常は同じです。速度や接続可否に明らかな差がある場合は、画面の見た目ではなく、Coreの種類、Coreのバージョン、使用中のノード、ルーティングモード、ローカルの待ち受けポートを先に確認してください。
結論：まずCoreと設定を揃え、その後にUI版を比較する
両版の接続差を調べる際は、使用中のノード、Coreの種類、システムプロキシモード、DNS設定、ルーティングルールを完全に揃えてください。これらの変数を固定して初めて、起動時間、トレイの挙動、リソース使用量を比較する意味が生まれます。
バージョン、ポート、リソース使用量を比較するためのデータ
以下のデータは、v7.15.7の設定構成を操作確認の基準とし、v2rayNで一般的なローカル待ち受けポートを使用しています。アップデートによって既定値が変わる場合があるため、ポート番号は確認方法の目安として扱い、最終的には「設定」→「パラメータ設定」に表示されるローカル待ち受け設定を確認してください。
Windows 11、メモリ16 GB、4コアのモバイルプロセッサを搭載した1台の端末で観察した結果では、両版とも120ノードを読み込み、10分間アイドル状態を維持しました。Avaloniaデスクトップ版のワーキングセットは約150～180 MB、WPF版は約110～145 MBでした。5回連続で起動した場合の中央値は、それぞれ約1.8秒と1.3秒です。これらの数値はフレームワークのオーバーヘッドの規模を示すもので、すべての端末で固定される結果ではありません。フォントキャッシュ、Coreの起動、サブスクリプション数、セキュリティソフトのスキャンによって数値は変動します。
- ノード数の増加は主にリストの描画、絞り込み、データベースの読み込みに影響し、プロキシ接続数の増加を意味するものではありません。
- リアルタイムログを有効にすると画面の更新頻度が上がります。メモリ使用量を比較する前に、両版で同じログレベルを設定してください。
- ローカルポートの競合は、Coreの起動失敗やシステムプロキシが使えない症状として現れます。まず10808、10809が他のプロセスで使用されていないか確認してください。
- 速度テストの結果はサーバー負荷、ネットワーク経路、プロトコルパラメータの影響を受けるため、AvaloniaとWPFの描画効率を判断する材料には適していません。
Windowsユーザーはどちらを選ぶべきか
Windowsは、2つの配布系統から積極的に選ぶ必要がある唯一のプラットフォームです。新規インストールでは通常、クロスプラットフォームUIの主要な操作経路であるデスクトップ版を優先します。既存のWPFワークフローを使っている場合は、安定性を基準に判断し、移行を強制的なアップグレードと考える必要はありません。特に固定したウィンドウ配置、キーボード操作、高DPIの多画面環境、特定のトレイ操作に依存する端末では、まず並行テストを行うのが安全です。
| 利用状況 | 推奨版 | 判断の根拠 |
|---|---|---|
| 初回インストールで、旧設定がない | Avaloniaデスクトップ版 | 将来ほかのOSを使う場合も操作体系を揃えやすい |
| 既存のWPF版が長期間安定している | WPF版を継続 | 明確なメリットのない移行コストを避けられる |
| WindowsとLinuxを切り替えて使う | Avaloniaデスクトップ版 | メニュー構成と管理の考え方が近い |
| 高DPIまたは多画面環境で画面に異常がある | 両版を比較テスト | 拡大縮小の問題は、グラフィックドライバー、フレームワーク、OS設定が複合的に関係します |
| ノード接続の失敗だけを解決したい | まずは版を変更しない | Core、プロトコルパラメータ、DNS、ルーティングを先に確認する |
VLESSノードでXrayが対応する通信機能を使用している場合は、両版で同じXray Coreを選択してください。既存のVMess設定でも、アドレス、ポート、ユーザー識別子、通信方式、TLSパラメータを揃える必要があります。UI版はプロトコル互換性の代わりにはなりません。不正なノードパラメータは、AvaloniaやWPFに変更しても修正されません。
結論：安定したWPF環境は継続し、新しい環境ではデスクトップ版を優先する
選ぶ基準はプラットフォーム対応範囲とUI互換性であり、「デスクトップ版」を高速版と捉えることではありません。ネットワーク性能は主にCore、プロトコル、サーバー、回線によって決まり、UIフレームワークが継続的な転送スループットに与える影響は通常、主要な変数ではありません。
WPFからAvaloniaへ移行する安全な手順
移行前に重要なのは、プログラムのフォルダー全体をコピーすることではありません。復元可能なサブスクリプションの取得先、ノード情報、ルーティングルール、パラメータ設定を保存することが大切です。配布パッケージやマイナーバージョンによってローカルファイル構成が変わる場合があり、フォルダーを直接上書きすると古いキャッシュ、ログ、UI状態まで持ち込むおそれがあります。旧版のフォルダーを残し、UIのエクスポート機能とサブスクリプション更新機能を使って、新しいフォルダーで確認する方法がより確実です。
-
旧版を残す
WPF版とそのCoreプロセスを終了し、元のプログラムフォルダーを復帰用のコピーとして保存します。新旧版で、書き込み中の同じ設定フォルダーを共有しないでください。
-
設定を整理する
サブスクリプショングループ、使用中のサーバー、ルーティングモード、ローカルポートを記録します。手動ノードはクライアントで利用できるエクスポート方法で保存し、サブスクリプションノードは取得先が引き続き更新可能か確認してください。
-
デスクトップ版を起動する
サイト内のダウンロードページから、Windowsの環境に合ったAvaloniaデスクトップ版を入手し、独立したフォルダーで起動します。この時点では元のWPFフォルダーを削除しないでください。
-
Coreを確認する
「設定」→「パラメータ設定」→「Coreの種類」の順に開き、旧版と同じCoreを選択します。その後、ログレベル、ローカル待ち受けポート、自動起動設定を確認してください。
-
サブスクリプションを復元する
「サブスクリプショングループ」から取得先を追加して更新を実行し、ノード数、グループ名、現在使用中のノードを確認します。手動設定の場合は、プロトコルと通信パラメータを一つずつ確認してください。
-
ルーティングを検証する
「設定」→「ルーティング設定」を開き、直通、プロキシ、ブロックのルール順を確認します。その後、システムプロキシ、ブラウザーのアクセス、個別にプロキシが必要なアプリをテストしてください。
移行後に一つずつ確認する設定
- Coreの種類：新規インストールによってXrayやその他の選択可能なCoreが既定値に戻っていないか確認します。
- システムプロキシ：現在のモードが自動設定、システムプロキシの解除、変更なしのどれになっているか確認し、旧インスタンスのプロキシアドレスが残らないようにします。
- ローカル待ち受け：SOCKS、HTTP、混合待ち受けのアドレスとポートが、呼び出し元のアプリと一致しているか確認します。
- サブスクリプション更新：サブスクリプショングループの更新結果を確認し、リストに古いキャッシュノードが残っていることだけで成功と判断しないでください。
- ルールの順序：配列内のルールは通常、上から順に照合されます。移行後はカスタムドメイン、IP、プロセスのルール位置を特に確認してください。
- 自動起動：新旧版を同時にログイン時起動しないでください。トレイ、ポート、システムプロキシの状態を奪い合う可能性があります。
macOSとLinuxでAvaloniaを選ぶ理由
WPFの動作範囲はWindowsに限定されるため、macOSとLinuxのユーザーは2つの配布系統を比較する必要がなく、Avaloniaデスクトップ版を選べば十分です。ただし、クロスプラットフォームだからといってOSとの統合が完全に同じになるわけではありません。プロキシ環境変数、デスクトップセッション、自動起動の仕組み、トレイのプロトコル、権限モデルはOSによって異なります。問題が起きたら、「画面が起動するか」と「システムがプロキシを使っているか」を分けて確認してください。
- macOS：正常な動作に必要なシステム権限がアプリに付与されているか確認し、システムのネットワークプロキシが正しく設定されているか確認します。クライアントを終了する前に、システムプロキシを解除しておくと安全です。
- Linux：デスクトップ環境によって、トレイとシステムプロキシの対応状況は異なります。GNOME、KDE、その他のデスクトップセッションでは、プロキシ設定を開く場所が異なる場合があります。
- ターミナルアプリ：コマンドラインツールがデスクトップのシステムプロキシを読み取るとは限りません。プロキシが必要な場合は、各プログラムの仕様に従ってHTTP、HTTPS、SOCKSのプロキシアドレスを設定してください。
- 自動起動：クロスプラットフォームクライアントの「起動時に開始」は通常、ユーザーのログインセッションに対応します。ログイン前にシステムサービスとして起動することとは異なります。
Linuxでブラウザーはアクセスできるのにターミナルアプリからアクセスできない場合は、まずターミナルアプリがプロキシ環境変数を読み取っているか確認します。クライアントのログにCoreの待ち受けが表示されているのに、すべてのアプリがプロキシを経由しない場合は、デスクトップのプロキシ設定とポートを確認してください。macOSでも同様の症状が出たら、システムプロキシのアドレスが現在のインスタンスに表示されているローカルポートを指しているか確認します。
よくある誤解とトラブル対応の順序
Avaloniaデスクトップ版はWPF版より接続が速いですか
UIフレームワークだけでそのように判断することはできません。接続の確立とデータ転送は、主にCore、ノードのプロトコル、サーバー負荷、DNS、ネットワーク経路によって決まります。両版で同じ設定を使う場合、ウィンドウのフレームワークだけが原因で継続的なスループットに大きな差が出ることは通常ありません。
版を変更したらサブスクリプションのノードが減りました。互換性の問題ですか
まずサブスクリプションの更新ログを確認し、取得先、グループ、解析処理が正常か確認してください。ノード数の減少は、サブスクリプション側の内容変更、グループ選択の誤り、更新失敗後にローカルキャッシュだけが表示されていることでも起こります。AvaloniaとWPFの違いに直接起因すると決めつけないでください。
デスクトップ版を起動してもトレイアイコンが表示されない場合はどうすればよいですか
Windowsでは、まず通知領域の非表示アイコンを確認してください。Linuxでは、現在のデスクトップ環境がトレイプロトコルに対応しているか確認します。プログラムがすでに終了していないか、ウィンドウが最小化されていないか、旧版のインスタンスが同時に動作していないかも確認してください。
移行後、VLESSは使えるのに旧VMessノードだけ失敗する場合はどうすればよいですか
各ノードのアドレス、ポート、ユーザー識別子、通信方式、Host、パス、TLS設定を個別に確認し、両版で同じCoreを使っていることを確認してください。プロトコル名が同じでも、その他の通信フィールドまで同じとは限りません。サブスクリプションを再解析した後は、使用中のノードが元のノードのままかも確認してください。
2つの版を同じフォルダーに置き、上書きして実行できますか
おすすめしません。2つの配布系統には異なるUIランタイムファイルが含まれているため、フォルダーを上書きすると古いファイルが残ったり、設定の書き込みが競合したりする可能性が高まります。別々のフォルダーを使い、移行後しばらく安定して動作することを確認してから旧フォルダーを整理するのが安全です。
トラブル対応は5段階に固定できます。まずプログラムが正常に起動するか、次にCoreが正常に起動するかを確認し、その後ローカルポートが待ち受けているか、システムプロキシまたはアプリのプロキシ設定、最後にノードとルーティングを確認します。この順序なら、UI、Core、ローカルプロキシ、リモートノードの問題を切り分けられ、版を何度も変更して本当の原因を見失うことを防げます。
最終的な選び方
Avaloniaデスクトップ版とWPF版の本質的な違いは、GUIの技術スタックと対応プラットフォームであり、プロキシプロトコルの優劣ではありません。Windowsの新規ユーザーや複数のデスクトップOSを切り替えて使うユーザーは、Avaloniaデスクトップ版を優先してください。Windowsのみを使い、WPF版が安定しているユーザーは、現在の環境を継続できます。macOSとLinuxではAvaloniaデスクトップ版を使います。
- まずOSで対象外の版を除外します。WPFはWindows専用です。
- 次に既存設定の移行コストを確認します。安定した旧環境なら、UIの違いだけを理由に急いで移行する必要はありません。
- 移行する場合は、Core、ノード、ポート、DNS、ルーティングを揃えてください。
- 接続障害が起きたら、まずログと待ち受けポートを確認し、UI版の変更を最初のトラブル対応にしないでください。
- 新旧版を並行テストするときは別々のフォルダーを使い、同時にシステムプロキシを制御するインスタンスが1つだけになるようにしてください。
実行しやすい判断にまとめると、新規インストールはAvaloniaデスクトップ版、安定稼働中のWindows WPF環境は必要に応じて継続します。プロトコルや速度の問題は、Core、ノード、ルーティングの層に戻って確認してください。これにより、クロスプラットフォーム版の統一された操作経路を活かしながら、明確なメリットのない移行による設定リスクを避けられます。