DesktopとWPFは、v2rayNのデスクトップUIの選択肢であり、プロキシプロトコルの違いではありません。新規導入や複数OSでの利用には、まずAvaloniaベースのDesktop版を検討しましょう。Windowsで安定して使えている場合は、WPF版を継続しても問題ありません。インストーラー、動作要件、サブスクリプションの移行、プロキシモード、トラブルの確認方法を順に解説し、既存設定を保ちながら選択・移行する手順を紹介します。
DesktopとWPF：UIとコアを区別する
大きな違いはUIフレームワークと対応OSです。DesktopはAvaloniaで構築されたクロスプラットフォームUIで、Windows、macOS、Linuxに対応します。WPFはWindows向けのデスクトップUIフレームワークのため、WPF版はWindows環境で使用します。ファイル名にあるDesktopは「サーバー版」を意味するものではなく、インストールするとすべての通信が自動的にプロキシ経由になるわけでもありません。
| 比較項目 | Avalonia Desktop | WPF |
|---|---|---|
| UIフレームワーク | Avalonia | Windows Presentation Foundation |
| 対応OS | Windows、macOS、Linux | Windows |
| 操作感 | クロスプラットフォームのUI。OSによって差が生じる場合あり | Windows向けのデスクトップ操作。既存の手順を引き継ぎやすい |
| 動作要件 | パッケージが自己完結型か、対象OSは何かによって異なる | パッケージが自己完結型か、.NET Desktop Runtimeが必要かによって異なる |
| プロトコル対応 | 実際に使用するコアと設定によって異なる | 実際に使用するコアと設定によって異なる |
| 移行時の確認点 | OS連携、パス、権限、機能へのアクセス方法 | 既存設定との互換性、依存関係、コアの更新 |
v2rayNはサブスクリプション、サーバー、ルーティング、コアの実行を管理します。実際の接続処理を担うのは選択したコアです。VMessとVLESSはプロトコル名、XrayとV2Flyは別々のコアプロジェクトで、AvaloniaとWPFはUI技術です。UIをDesktopに変えただけで特定のノードが速くなったり、これまで非対応だったプロトコル設定が使えるようになったりするわけではありません。
結論：速度を比べる前に接続条件をそろえる
同じノード、同じコアのバージョン、同じルーティングルール、同じプロキシモードで比較してください。条件が異なる場合、速度測定の結果からAvaloniaとWPFの性能差を判断することはできません。
OS別の選び方：Windowsはどちらも選択可能、ほかのOSはDesktop
新規インストールなら、まずDesktop版を試す方法があります。Windowsで安定して使えているなら、UIの名前が変わっただけで移行する必要はありません。選ぶ際は、利用中のOS、必要な機能、慣れた操作方法を基準にしましょう。クロスプラットフォーム対応でも、すべての機能が同じとは限りません。メニューの位置、トレイの操作、システムプロキシの実装はリリースごとに変わることがあるため、インストール後の画面とリリースノートを確認してください。
Avalonia Desktop
おすすめ新規インストール時に優先して検討できる選択肢です。Windowsではデスクトップ向けインストーラーを選びます。macOSではプロセッサに合わせてARM64またはx64を選択してください。LinuxではCPUアーキテクチャとディストリビューションのパッケージ形式を確認します。サブスクリプションの更新、トレイ、システムプロキシ、必要なTUN機能を試してから、継続利用するか決めましょう。
おすすめの用途：新規導入、複数OSでの利用、macOSまたはLinuxのデスクトップ環境
Windows WPF
使い慣れたWindows環境を維持したい場合に適しています。既存のサブスクリプション、ルーティング、ショートカット、トレイ操作に問題がなければ、そのまま使い続け、リリースノートに沿ってクライアントとコアを更新しましょう。問題が起きた場合は、依存関係、権限、ノード設定を確認してください。UIを変えればすべての不具合が解決するとは限りません。
おすすめの用途：Windowsで安定した設定があり、慣れたUIや操作方法を使い続けたい場合
- Windows：「設定」→「システム」→「バージョン情報」でシステムの種類を確認します。ダウンロードページのx64インストーラーはx64システム用です。PCのメーカー名だけでアーキテクチャを判断しないでください。
- macOS：Appleメニューから「このMacについて」を開きます。Appleシリコン搭載モデルはARM64、Intelプロセッサ搭載モデルはx64を選択してください。初回インストールでは、異なるアーキテクチャ向けの変換実行を前提にしないようにしましょう。
- Linux：
uname -mでアーキテクチャを確認します。x86_64はx64、aarch64はARM64に対応します。Debian・Ubuntu系ではDEB、FedoraなどRPMを使うディストリビューションではRPMを選びます。
動作要件：UIが起動してもプロキシが使えるとは限らない
動作要件は配布パッケージによって異なります。「Desktop版なら.NET不要、WPF版なら必ず別途.NETをインストール」と単純に考えることはできません。どちらのUIも、必要なマネージドランタイムを含む自己完結型パッケージとして配布される場合があります。フレームワーク依存のパッケージでは、対応するランタイムがシステムに必要です。WPF版では通常の.NET Runtimeだけでなく、.NET Desktop Runtimeが必要かどうかも確認してください。
- まずインストーラーを確認：OS、アーキテクチャ、パッケージのリリースノートを確認します。起動時にランタイム不足のメッセージが出た場合は、指定されたランタイムの種類とメジャーバージョンに合わせてください。適当なバージョンをインストールして何度も試すのは避けましょう。
- 次にアプリの起動を確認：メインウィンドウが開くことと、設定フォルダーに書き込めることを確認します。同じフォルダーにDesktop版とWPF版を混在させて展開しないでください。コンポーネントやコアが上書きされるおそれがあります。
- 続いてコアを起動：サーバーを選択してログを確認します。コアファイルの不足、実行権限の不足、ポートの競合があると、「ウィンドウは正常に開くのに通信できない」状態になることがあります。
- 最後にアプリの通信を接続：必要なシステムプロキシを有効にするか、テストするアプリでローカルプロキシを明示的に指定します。接続の入口、ルーティング、リモート接続のすべてが正常であれば、インストール完了です。
macOSでは初回起動時にアプリの許可やネットワーク権限が必要になる場合があります。LinuxのTUNでは仮想ネットワークインターフェースへのアクセスやルート変更の権限が関係することがあります。いずれもOSとの連携に関する問題で、UIを変えても解決するとは限りません。まず通常のプロキシ接続を確認してから、より高い権限が必要な通信の取り込みを設定しましょう。切り分ける範囲を絞れます。
機能の確認：サブスクリプション、システムプロキシ、TUNを個別に検証
日常的な機能は、3つの段階に分けて確認できます。サブスクリプションから正しいサーバー一覧が生成されるか、コアが接続を確立できるか、アプリの通信がクライアントを経由するかをそれぞれ確認します。システムプロキシが影響するのは、システムのプロキシ設定に従うアプリが中心です。TUNは仮想ネットワークインターフェースで通信を取り込みますが、ルーティング、DNS、権限、除外ルールの影響を受けます。2つは別の機能であり、「有効になった」という表示だけで実際の接続を確認したことにはなりません。
上記のポートはテスト方法を説明するための例で、すべてのバージョンのデフォルト値ではありません。SOCKSとHTTPで別々のインバウンドを使う設定もあれば、混合インバウンドを使う設定もあります。「設定」→「パラメーター設定」で実際の待ち受けポートとインバウンドの種類を確認してください。画面上の項目名はバージョンによって変わる場合があります。対応するインバウンドが実際に設定されている場合に限り、以下のコマンドを使用できます。
# SOCKSインバウンド：プロキシ側で接続先ドメインを名前解決
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 https://example.com/
# HTTPインバウンド：HTTPプロキシ経由でHTTPS接続を確立
curl --proxy http://127.0.0.1:10809 --connect-timeout 10 https://example.com/プロキシを明示したテストに成功しても、その経路が使えることしか確認できません。システムプロキシやTUNがほかのアプリにも適用されている証明にはなりません。コマンドで応答があるのにブラウザーが開けない場合は、ブラウザーのプロキシ設定とシステムプロキシの状態を確認します。ローカルポートへの接続に失敗する場合は、コアの起動状態とポート番号を確認してください。ローカルプロキシには接続できるのにタイムアウトする場合は、ノード、DNS、ルーティングを確認します。
- サブスクリプション：「サブスクリプショングループ」にURLを追加して更新し、ノード数、グループ名、プロトコル項目を確認します。更新完了の表示だけでなく、生成されたサーバー情報も確認してください。
- ルーティング：同じルールセットでテストし、直接接続とプロキシ経由の通信を区別します。UIを切り替えた後は、既存ルールファイルのパスや外部データファイルも確認してください。
- TUN：別のクライアントを終了してから、必要な権限、DNS、ルーティングを確認します。複数のTUNが同時にシステムルートを変更すると、原因の特定が難しくなるため避けてください。
WPF版からDesktop版へ移行：バックアップ後に別環境で試す
移行時は元の環境を残したまま、新しい環境を別に用意して、問題があれば戻せるようにします。サブスクリプションURLは通常再登録できますが、サブスクリプションにすべてのローカル設定が含まれるわけではありません。カスタムルーティング、待ち受けポート、ショートカット、DNS、コアの選択、TUNの設定を個別に確認してください。同じv2rayNでも、任意のバージョン間で設定フォルダーをそのまま上書きできるとは限りません。
移行方法：旧環境を残し、新環境を検証
旧WPF環境
- 現在のバージョンに備わっているバックアップまたはエクスポート機能を使います。
- ローカルポート、コア、ルーティング、DNSの設定を記録します。
- 元の設定フォルダーを残し、アプリとコアを終了します。
- サブスクリプションURLは安全に保管し、公開画像に写り込まないようにします。
新しいDesktop環境
- 専用フォルダーを使うか、対象OSの通常の方法でインストールします。
- まずサブスクリプションを追加し、動作確認済みのノードを1つ選びます。
- 通常のプロキシ接続を確認してから、カスタムルールを1つずつ戻します。
- 最後にトレイ、自動起動、TUNをテストします。
一度に起動する環境は1つにしてください。新環境の検証が終わってから旧環境を削除するか判断し、ポートやシステムプロキシが競合しないようにします。
- 現在の状態を記録：旧環境のクライアントとコアのバージョン、使用中のノード、プロキシモードを控えます。正常にアクセスできるテスト先も記録してください。ログ全体を第三者に渡す必要はありません。
- 最小限の設定を読み込む：まずサブスクリプションと使用可能なノードを1つだけ追加します。初回テストでは複雑なルーティング、自動タスク、TUNを戻さず、変数を減らします。
- 設定を1つずつ戻す：設定を1項目戻すたびにテストします。ルーティングを戻した後にだけ失敗する場合は、UIを再インストールするのではなく、ルールとデータファイルを優先して確認してください。
- 終了時の動作を確認：クライアントを閉じるか終了した後、システムプロキシが想定どおり元に戻るか確認します。旧アプリのプロキシ設定が残っていると、新アプリを起動する前から通信に問題が起きる場合があります。
OSをまたいで移行する場合は、パスの形式にも注意してください。Windowsのドライブ文字付きパスはmacOSやLinuxではそのまま使えません。エクスポートした設定が外部ルール、証明書、その他のファイルを参照している場合は、移行先OSでパスを設定し直してください。手間を省くために設定フォルダー全体を新しいOSへ上書きすると、OS固有の設定まで引き継がれてしまいます。
よくある問題：起動失敗、ポート競合、選択時の注意点
トラブルシューティングは「インストーラーと依存関係 → コアの起動 → ローカルインバウンド → ノード接続 → システムプロキシまたはTUN」の順に進めると効率的です。UIの問題とネットワークの問題を切り分けられ、サブスクリプションの更新失敗をAvaloniaの非互換と誤認することも避けられます。以下の問題は、まず影響範囲を絞って確認してから、バージョンを切り替えるか判断してください。
Desktop版が起動しない場合、WPF版を入れ直せば解決しますか？
まず起動エラーを記録します。ダウンロードしたパッケージのOSとアーキテクチャを確認し、表示された案内に従ってランタイムやGUI依存関係を調べてください。macOSやLinuxでは、WPFは代替版になりません。Windowsの場合も、ファイルの混在や必要なランタイムの不足がないか、先に確認しましょう。
2つのバージョンを同時に起動すると、新しい方が接続できないのはなぜですか？
まず旧バージョンを完全に終了し、新バージョンのログにアドレスやポートの競合が記録されていないか確認します。Windowsではnetstat -ano | findstr :10808を使って例のポートの使用状況を確認できます。実際のポートに置き換えてください。ウィンドウを閉じただけでは、アプリがトレイに常駐してコアを実行し続けている場合があります。
同じサブスクリプションを読み込めても、ノードに接続できないのはなぜですか？
そのサーバーで選択されているコア、トランスポート方式、TLSパラメーターを確認し、接続ログを調べてください。サブスクリプションを解析できても、現在のコアがすべてのプロトコル項目に対応しているとは限りません。UIの違いを原因と決めつける前に、旧環境で接続できていた同じノードを試してください。
Windowsだけで使う場合も、Avalonia版に切り替える必要がありますか？
必要ありません。現在のWPF環境で問題なく使えているなら、そのまま継続できます。Desktop版を検討する場合は、別環境を用意してトレイ、システムプロキシ、よく使う機能を確認しましょう。移行するかどうかは、UIの名称ではなく実際の機能とメンテナンスの要件を基準に判断してください。
デスクトップ版の設定をAndroidクライアントにそのままコピーできますか？
デスクトップの設定フォルダーをコピーするのではなく、Android側でサブスクリプションを追加し直すことをおすすめします。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。ノードを選ぶ際はプロトコルの対応状況を確認してください。デスクトップ版の待ち受けポート、システムプロキシ、TUN設定をモバイル版にそのまま適用しないでください。
選び方は2つにまとめられます。macOSとLinuxでは対応するDesktop版のインストーラーを選びます。Windowsでは新規導入ならDesktop版を優先して検討し、WPF版で安定している場合は必要に応じて移行を判断してください。どちらのUIを選んでも、カスタムルーティングやTUNを設定する前に、ノード1つ、インバウンド1つ、プロキシモード1つで接続を確認しましょう。
OSに合ったv2rayNをダウンロード
ダウンロードセンターでWindows Desktop版、Windows WPF版、または使用するアーキテクチャに合ったmacOS・Linux向けパッケージを選んでください。初回設定では、ガイドに沿ってサブスクリプションを追加し、プロキシ接続をテストします。