2026-09-28 · プラットフォーム · 約9分

v2rayN Desktop(Avalonia)とWPF版の違い:Windows・macOS・Linuxではどのパッケージを選ぶ?

Avalonia採用のクロスプラットフォーム版とWindows専用のWPF版を、画面・トレイ・対応OSで比較。OS別に適したインストールパッケージを紹介します。

この記事の要点

Windowsでは、クロスプラットフォーム版Desktopと従来のWPF版から選べます。macOS・Linuxでは各OS向けのDesktopパッケージを選びます。まずOSとCPUアーキテクチャを確認し、必要なランタイム、トレイの動作、コアの起動をチェックしましょう。この記事では、パッケージ選びからインストール、移行、トラブルシューティングまでを解説します。画面フレームワークの違いを、プロトコルやノードの違いと混同しないことが大切です。

Desktop版とWPF版の違いは画面であり、サブスクリプション形式ではない

AvaloniaはクロスプラットフォームのデスクトップUIフレームワーク、WPFはWindows向けのデスクトップUIフレームワークです。v2rayN DesktopはAvaloniaで構築され、Windows・macOS・Linux向けの各ビルドが提供されます。WPF版はWindows向けです。クロスプラットフォーム対応とは、各OS向けのビルドを提供できるという意味であり、1つのインストールパッケージを3つのOSでそのまま実行できるわけではありません。

v2rayNは、サブスクリプションのグループ分け、ノードの選択、ルーティング設定、コアプロセスの管理を担います。プロキシ接続を実際に確立するのは選択したコアです。VMessやVLESSなどのプロトコルが使えるかどうかは、コアのバージョン、ノードの通信パラメーター、サーバー設定によって決まり、画面がAvalonia製かWPF製かには左右されません。画面を切り替えても、期限切れのサブスクリプションは直らず、非対応のコアにプロトコル機能が追加されることもありません。

比較項目Desktop(Avalonia)WPF
対応OSWindows・macOS・Linux、それぞれに合ったパッケージを選択Windows
画面とスケーリングクロスプラットフォームのUI。システムフォントや拡大率の設定による影響ありWindowsのデスクトップUIとウィンドウ操作
トレイとウィンドウを閉じたときの動作OS、デスクトップ環境、クライアント設定によって異なるWindowsの通知領域と連携
プロトコルの接続機能実際に使用するコアと設定によって異なる同様にコアと設定によって異なる
システムプロキシとTUN各OSでの連携方法と必要な権限を確認Windowsの権限とネットワーク設定を確認

選び方の結論:まずOSとアーキテクチャを確認し、その後に画面を選ぶ

まず、このPCで動作しないパッケージを候補から外します。Windowsでは、画面の好みや実際の機能を試したうえでDesktop版かWPF版を選びましょう。特定のノードに接続できないという理由だけで、画面フレームワークを変える必要はありません。

Windows・macOS・Linux向けインストールパッケージの選び方

ダウンロード時は、OS・CPUアーキテクチャ・パッケージ形式の3点を確認します。ファイル名のx64は通常IntelまたはAMDの64ビットCPU向け、arm64はARMの64ビットCPU向けです。どちらも64ビットですが、アーキテクチャが異なるため互換性はありません。ランタイムがパッケージに含まれるかどうかは別の情報なので、ダウンロードページの説明を確認してください。

3つのOS
Desktop版が対応するデスクトップOS
1つのOS
WPF版はWindows向け
64ビット
x64とarm64は同じ64ビットでもアーキテクチャが異なる

以下の「おすすめ」は、複数のデスクトップOSで似た操作感を求める場合に限った案内です。すべてのWindows端末でDesktop版がWPF版より適しているという意味ではありません。対応アーキテクチャとパッケージ形式は、ダウンロードセンターに現在掲載されている内容を確認してください。

Desktop版:複数のOSで使う

おすすめ

Windows・macOS・Linuxそれぞれに合ったビルドをダウンロードします。画面構成は似ていますが、システムプロキシ、トレイ、権限の操作は使用するOSに合わせて行う必要があります。

おすすめのユーザー:複数のデスクトップOSを使い分け、似た操作感を保ちたい方。

WPF版:Windowsで継続して使う

Windowsだけで使い、従来の画面に慣れていて、現在の設定で安定して動作している場合はWPF版を使い続けても問題ありません。「従来の画面」だからといってコアが古いとは限らないため、コアの状態は別途確認してください。

おすすめのユーザー:主にWindowsを使い、従来のウィンドウやトレイの操作に慣れている方。

macOSとLinuxでは、ターミナルからアーキテクチャを確認できます。以下のコマンドはシステム情報を表示するだけで、ネットワーク設定は変更しません。

uname -m

x86_64は通常x64に、arm64またはaarch64はARM 64ビットに対応します。Linuxで必要なグラフィックライブラリ、ランタイム、システムライブラリがそろっているかは、パッケージの説明もあわせて確認してください。アーキテクチャの一致は、最初に確認する項目の一つです。

画面・トレイ・バックグラウンド動作を個別に確認する

Desktop版とWPF版では、フォントの描画、リストの表示密度、拡大率、メニューの位置、ショートカットキーへの反応が異なる場合があります。高解像度ディスプレイで文字が大きすぎる、またはダイアログが画面からはみ出す場合は、まずシステムの拡大率とマルチディスプレイごとの設定を確認してから、クライアント画面の問題かどうか判断してください。サブスクリプションやルーティング設定を先に削除する必要はありません。

ウィンドウを閉じても、必ずしもプログラムが終了するとは限りません。トレイに最小化されるか、コアプロセスが動き続けるかは、クライアントの設定と使用中のOSのトレイ対応状況によります。Linuxではデスクトップ環境によってステータスアイコンの対応が大きく異なります。アイコンが見えないだけでは、コアが停止したとは判断できません。

  1. 初回起動時はメインウィンドウを表示したままにする:ノードを選択し、ログにコアの起動成功が記録されるか確認します。起動に失敗した場合は、まずエラー内容を控えてください。
  2. ウィンドウを閉じた後の動作を確認する:ウィンドウの閉じるボタンを押した後、タスクマネージャーまたはシステムのプロセス管理ツールで、クライアントが引き続き動作しているか確認します。
  3. トレイの場所を確認する:Windowsでは通知領域の隠れているアイコン、macOSではメニューバーを確認します。Linuxでは、デスクトップ環境がステータスアイコンに対応しているか確認してください。
  4. 正常に終了できるか確認する:アプリのメニューまたはトレイのメニューから終了し、その後システムプロキシが想定した状態に戻っているか確認します。通常の終了に、プロセスの強制終了を使わないでください。

WPF版からDesktop版への移行:サブスクリプションとシステム設定を分けて扱う

移行前に、現在のデータをバックアップしてください。バックアップにはサブスクリプションURL、グループ情報、カスタムルーティング、必要な設定値の記録が含まれます。アクセス情報が含まれる場合があるため、安全な場所に保管してください。旧フォルダーの設定ファイルをすべて別のビルドやバージョンのデータフォルダーに上書きするのは避けましょう。内部構造や保存先が互換とは限りません。

移行手順:旧環境を残し、新環境を個別に検証する

旧環境:復元に必要な情報を保存
  • 現在のサブスクリプショングループと更新方法を記録する。
  • カスタムルーティングルールとDNS設定を保存する。
  • ローカル待ち受けポート、システムプロキシ、TUNの状態を記録する。
  • プロキシとコアを停止してから、新環境を起動する。
新環境:まず必要最低限の動作を確認
  • クライアント画面からサブスクリプショングループを追加し直す。
  • 使用可能な既存ノードを1つ選び、コアを起動する。
  • まずローカルプロキシをテストし、その後システムプロキシを確認する。
  • 最後にカスタムルーティング、DNS、TUNの設定を戻す。

設定を一つずつ移行すれば、問題の原因を特定しやすくなります。サブスクリプションは再取得できますが、PCの権限、ファイルパス、デスクトップ環境との連携は改めて確認が必要です。

サブスクリプションを更新して取得できるのは、サービス提供元が配信するノード情報です。旧クライアントのローカル設定がすべて同期されるわけではありません。グループの更新間隔、カスタムルール、ショートカット、ウィンドウの動作を個別に確認してください。OSをまたいで移行する場合、以前の絶対パスをそのまま使うことはできません。

同じ端末に2つのプログラムを残す場合、普段はどちらか一方だけを起動してください。2つのプロセスが同時にシステムプロキシを設定したり、同じポートを待ち受けたり、仮想ネットワークアダプターを作成したりすると、問題の原因を特定しにくくなります。テスト後は残すインスタンスを決め、自動起動の設定も確認して、再起動後に旧インスタンスが再び起動しないようにしましょう。

インストール後はローカル接続を確認し、その後システムプロキシとTUNを検証

「画面が開くこと」と「プロキシを使えること」は、別々に確認する必要があります。前者は、少なくともGUIプログラムが起動したことを示します。後者には、コアの実行ファイル、ノードのパラメーター、ローカルの受け口、ルーティング設定がすべて正常である必要があります。ランタイム不足のメッセージが表示された場合は、パッケージの説明に従って依存関係を追加するか、適切なパッケージを選び直してください。コアの起動失敗を、すぐにAvaloniaが原因だと決めつけないでください。

  1. コアの状態を確認:起動ログを見て、コアの不足、実行権限の不足、ポートの競合がないか確認します。Linuxでは、プログラムの保存先で実行ファイルの起動が許可されているかも確認してください。
  2. ローカルの受け口を確認:「設定」→「パラメーター設定」を開き、実際の待ち受けアドレス、ポート、受け口の種類を確認します。バージョンによって項目の配置が異なる場合があるため、画面に表示されている値を基準にしてください。
  3. プロキシを個別にテスト:プロキシアドレスを明示したリクエストを使い、アプリがシステムプロキシ設定を参照するかどうかによる影響を切り分けます。
  4. システムプロキシを確認:ローカルの受け口が正常に動作した後、ブラウザーにシステムプロキシを使わせます。システムプロキシを設定しても、すべてのプログラムが強制的にプロキシを使うわけではありません。
  5. 最後にTUNを確認:プロキシに対応していないプログラムの通信も取り込む必要がある場合に限り有効にし、システムの許可、ルート、DNSを確認します。TUNで通信を取り込んでも、すべての宛先がプロキシ経由になるわけではありません。

以下では、この端末で待ち受けを確認済みのSOCKSエンドポイント127.0.0.1:10808を例にします。これはテスト用の例であり、現在のインストール環境の既定ポートとは限りません。画面に別のポートが表示されている場合は、その値に置き換えてください。Windowsのターミナルではcurl.exeを使うとcurlを明示的に実行できます。macOSとLinuxではcurlを使用します。

curl --proxy socks5h://127.0.0.1:10808 --head --connect-timeout 10 https://example.com/

socks5hはドメイン名の解決をプロキシ側に任せます。--connect-timeout 10は接続段階のタイムアウトを10秒に設定します。このリクエストで確認できるのは、現在の経路から宛先に到達できるかどうかです。一度の応答だけで、すべてのルーティングやDNSが正しいとは判断できません。ローカルポートにすぐ接続できない場合は、まず待ち受け状態を確認します。接続後にタイムアウトする場合は、ノード、出口、宛先への接続性を確認してください。

パッケージ選びと移行に関するよくある質問

WindowsでWPF版を使っています。Desktop版に切り替えるべきですか?

画面フレームワークが異なるだけなら、移行する必要はありません。複数のOSで似た画面を使いたいか、再現性のある表示・操作上の問題があるかなど、実際の要件を整理しましょう。現在の環境が安定している場合は、バックアップを取ってからDesktop版を別途テストしてください。動作確認前に旧環境を上書きしないでください。

macOSでexeファイルをダウンロードしたのに、開けないのはなぜですか?

OSに合わないパッケージを選んでいます。ダウンロードセンターでmacOS向けのDesktop版を選び、CPUに応じてarm64またはx64を指定してください。ファイルの拡張子を変更しても、対象OSは変わらず、必要なランタイムも追加されません。

Linuxでウィンドウは表示されますが、トレイアイコンが見つかりません。どうすればよいですか?

まずメインウィンドウを表示したままにし、使用中のデスクトップ環境がステータスアイコンに対応しているか確認します。次に、クライアントのウィンドウを閉じたときの設定を確認してください。システムのプロセス管理ツールで、プログラムがバックグラウンドで動作しているかも確認します。トレイアイコンはデスクトップ環境との連携機能であり、コアの接続状態を示すものではありません。

Desktop版に替えてサブスクリプションは同じなのに、ルーティング結果が異なるのはなぜですか?

選択中のコア、カスタムルーティング、ルールデータ、DNS、システムプロキシの状態を順番に確認してください。同じサブスクリプションでも、同じノードを利用していることを示すだけで、ローカルのルーティング設定まで同一とは限りません。まずプロキシの接続先を明示したリクエストで確認し、その後、以前のルールを一つずつ戻してください。

ARM端末にx64パッケージをそのままインストールできますか?

互換レイヤーの利用を最初の選択肢にしないでください。まずダウンロードセンターで、OSに合ったarm64パッケージが提供されているか確認します。互換方式を使う場合は、画面プログラムと同梱コアの両方が動作するか個別に確認してください。画面が起動しても、コアが実行できるとは限りません。

v2rayN をダウンロード