v2rayNはどれを選ぶ？Avaloniaクロスプラットフォーム版とWindows WPF版を比較

この記事の要点

macOSやLinuxでは各OSに対応したAvaloniaビルドを選びましょう。Windowsでは、これまでの使い方やシステム連携、動作環境を基準に選べます。画面の違いだけで通信速度や対応プロトコルが変わるわけではありません。インストーラーの見分け方、トレイとシステムプロキシ、動作要件、設定の移行を順に解説します。初めてインストールする方にも、バージョンの切り替えを検討している方にも役立つ内容です。

AvaloniaとWPF：画面とプロキシコアは別もの

AvaloniaとWPFは、どちらもデスクトップアプリのUIを構築する技術です。WPFはWindows向け、Avaloniaはクロスプラットフォーム対応のため、v2rayNは異なるビルドを通じてWindows、macOS、Linuxで利用できます。ダウンロード時に選ぶUIの違いは、主にウィンドウの表示や操作、トレイ、システム機能との連携に関わるもので、プロキシのプロトコルが変わるわけではありません。

v2rayNはサーバー、サブスクリプション、ルーティングルール、ローカルプロキシの入口を管理します。実際の接続処理を担うのは、選択したプロキシコアです。VLESS、VMess、REALITYなどの設定が使えるかどうかは、コアのバージョンやノードのパラメーター、クライアントが各項目に対応しているかを確認してください。インストーラーにAvaloniaやWPFと書かれているだけでは判断できません。

Avaloniaクロスプラットフォーム版

Windows WPF版

Windows向けのUIです。サーバー一覧やトレイメニュー、ショートカット操作に慣れていて、現在安定して使えているなら、そのまま使い続けて問題ありません。UIを変えることだけを目的に移行する必要はありません。

おすすめのユーザー：Windowsをメインに使い慣れた操作や現在の作業環境を維持したい方。

ここでAvaloniaをおすすめしているのは、クロスプラットフォームで使う場合です。すべてのWindows PCでメモリー使用量が少ない、または動作が速いという意味ではありません。同じノードでも、コアのバージョンやルーティング、DNS、接続モードの違いによって、UIの差より大きな変化が生じることがあります。

インストーラーの選び方：OS、アーキテクチャ、依存関係を順に確認

まずOS、次にプロセッサーアーキテクチャ、最後に実行環境の有無を確認します。ファイルサイズだけで選んだり、「クロスプラットフォーム」なら同じ圧縮ファイルをどのOSでも実行できると思い込んだりしないでください。次の項目はダウンロード前に確認できます。

確認項目	確認場所	選ぶ際のポイント
Windowsのシステム情報	「設定」→「システム」→「バージョン情報」で「システムの種類」を確認	x64とARM64は別々に選びます。64ビットOSでも、プロセッサーがx64とは限りません。
macOSのプロセッサー	Appleメニュー→「このMacについて」で「チップ」または「プロセッサ」を確認	Appleシリコン搭載MacはARM64、Intelプロセッサ搭載Macはx64が基本です。配布パッケージの表記を確認してください。
Linuxのアーキテクチャ	ターミナルで `uname -m` を実行	`x86_64` は通常x64、`aarch64` は通常ARM64に対応します。
実行環境	パッケージの説明と起動時に表示される依存関係の案内	自己完結型ビルドか、システムのランタイムに依存するビルドかを確認します。パッケージ名だけで判断しないでください。

WPFだからといって、古い.NET Frameworkが必須とは限りません。最新のWPFアプリは新しい.NETをベースにすることもあります。必要なランタイムのバージョンは、起動時の案内とリリースノートで確認してください。Windows Desktop Runtimeが不足している場合、通常の.NET Runtimeをインストールするだけでは解決しないことがあります。

Avaloniaでも、システム依存がまったくないわけではありません。自己完結型ビルドには通常、必要な.NETランタイムが含まれますが、Linuxではグラフィック、フォント、その他のネイティブライブラリーが別途必要な場合があります。古いシステムで基盤コンポーネントが不足している場合は、まず対応範囲を確認してから依存関係に対処しましょう。起動できていないアプリの問題を調べるために、ノードを何度も変更する必要はありません。

3種類のOS

Windows、macOS、Linuxごとに対応パッケージを選択

2種類のアーキテクチャ

x64とARM64を優先して確認

10808

後述の接続テストで使うローカルポートの例

システム連携を比較：トレイ、システムプロキシ、TUNを個別に確認

ウィンドウが開くのは、GUIが動作することを示すだけです。使いやすさは、ウィンドウを閉じた後の動作やトレイへのアクセス、スタートアップ、システムプロキシの設定にも左右されます。メニューの場所はバージョンによって変わる場合があるため、スクリーンショットだけでなく、実際の機能を一つずつ確認しましょう。

ウィンドウとトレイ：閉じるボタンをクリックしたとき、アプリが終了するのか、トレイに最小化されるのかを確認します。続けてトレイからメインウィンドウを再表示し、拡大縮小や日本語フォント、マルチモニター間の移動に問題がないか確認してください。
システムプロキシ：v2rayNのシステムプロキシメニューで「システムプロキシを自動設定」を選択した後、Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」で、プロキシサーバーのアドレスとポートを確認できます。メニューの表記はインストールしたバージョンによって異なります。
スタートアップ：有効にしたら、アプリを完全に終了してからシステムに再ログインし、自動起動するか、コアが起動するか、プロキシ設定が意図どおりに復元されるかを確認します。これらは個別に確認すべき3つの項目です。
Linuxデスクトップのトレイ：トレイアイコンが表示されるかどうかは、デスクトップ環境とトレイのサポート状況にも左右されます。アイコンが消えても、コアが停止したとは限りません。プロセスやログも確認して判断してください。

システムプロキシモードの影響を受けるのは、通常、システムプロキシ設定に従うアプリだけです。TUNモードでは仮想ネットワークインターフェースやルーティング、権限が関係します。利用できるかどうかは、OSやクライアントのビルド、コア、権限設定によって異なり、AvaloniaかWPFかだけでは判断できません。UIのバージョンを比較するときは、まずTUNを無効にして通常のローカルプロキシが使えることを確認し、その後でTUNを個別にテストしてください。

結論：まずローカルポートを確認し、その後にシステム連携を調べる

同じ接続中のサーバーで、ローカルプロキシを手動指定すれば接続できるのにブラウザーでは接続できない場合は、システムプロキシの設定とアプリがプロキシに対応しているかを優先して確認します。すぐにUIの違いやノードのプロトコルが原因だと決めつけないでください。

速度とリソース使用量：適切に比較する方法

「どちらのバージョンが速いか」は、UIの応答性とネットワーク通信に分けて考える必要があります。サーバー一覧のスクロールやウィンドウの表示時間はUIの使い心地に関するものです。一方、ダウンロード速度やハンドシェイクの失敗、ウェブページのタイムアウトは、主にネットワーク経路やコア、ノード、設定に左右されます。異なるOS間のテストではドライバーやネットワークスタックの違いも加わるため、UI技術だけが原因とは言えません。

両方のクライアントのバージョンと実際に動作しているコアのバージョンを記録し、同じノードを使います。ルーティング、DNS、接続モードも統一してください。
一度に起動するバージョンは1つだけにし、サブスクリプションの更新や速度テスト、その他のダウンロードを一時停止します。5分間アイドル状態にした後、クライアントとコアの各プロセスについて、メモリーとCPUの使用量を記録します。
同じ接続先で接続テストを3回連続して行い、成功率と合計所要時間を記録します。サンプルが1つだけの場合は、偶発的な変動を結論にしないでください。
1つ目のバージョンを終了し、コアのプロセスが停止してローカルポートが解放されたことを確認してから、2つ目のバージョンを起動して同じテストを行います。両方を同時に起動した状態で使用量を比較しないでください。

以下はローカルのSOCKS接続をテストするコマンドです。待ち受けアドレスを 127.0.0.1、ポートを 10808 とし、その接続口がSOCKSに対応していることを前提としています。クライアントに別のポートが表示されている場合は、先に数値を置き換えてください。Windowsでは curl.exe、macOSとLinuxでは通常 curl を使用します。

curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output NUL --write-out "HTTP=%{http_code} total=%{time_total}s\n" https://example.com/
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output /dev/null --write-out "HTTP=%{http_code} total=%{time_total}s\n" https://example.com/

socks5h は接続先のホスト名をプロキシ側で解決する指定です。このプロキシ経路の検証には適していますが、すべてのアプリのDNS動作を示すものではありません。接続拒否が返された場合は、待ち受けポートとコアの起動状態を確認してください。証明書やハンドシェイクのエラーが発生した場合は、ログとあわせてシステム時刻、TLSパラメーター、サーバー側の設定を確認します。

WPFからAvaloniaへ移行する：戻せる状態を保って切り替える

同じクライアントの異なるUIでも、すべてのバージョンでデータディレクトリや設定形式が完全に同じとは限りません。特に複数のバージョンをまたぐ場合、データベースや設定が更新されることがあります。元のファイルを直接上書きせず、旧ディレクトリを残して別の場所で動作を確認するのが安全です。

移行手順：旧版を残し、新版を別環境で確認

旧環境

クライアントを終了し、実際に使用しているデータディレクトリと設定をバックアップします。
サブスクリプショングループ、接続中のサーバー、ローカルポート、カスタムルーティングを記録します。
現在のバージョンを記録し、ポートの競合を避けるため自動起動を一時停止します。
サブスクリプションURLにはアクセス用の認証情報が含まれる場合があります。バックアップファイルへのアクセスを制限してください。

新環境

プログラム専用のディレクトリを使い、旧環境のデータディレクトリを共有していないことを確認します。
バージョンでサポートされているインポート方法を優先するか、サブスクリプションを再登録します。
ローカル接続口、ルーティング、DNS、システムプロキシの状態を改めて確認します。
接続、再起動、ウィンドウの復元をテストしてから、旧版の置き換えを検討してください。

異なるOS間の移行では、サブスクリプションと、明示的にエクスポートした設定を中心に移行します。旧プログラムのディレクトリ全体を、別のOS向けのコアファイルごとコピーしないでください。

サブスクリプションを再登録するとサーバー一覧は復元できますが、カスタムルールやショートカット、ウィンドウ設定、ローカルの待ち受けポートは復元されない場合があります。移行後は接続先のサーバーを選び直してください。一覧にノードが表示されただけでは、接続設定が完了したことにはなりません。

インストール後に起動しない・接続できない場合：問題が起きた段階から確認

2つのUIを何度も切り替えるよりも、「プログラムの起動」「コアの起動」「プロキシの適用」「リモート接続」のどの段階で問題が起きているかを特定するほうが効果的です。エラーの全文を保存しつつ、サブスクリプションの認証情報やサーバーのパスワードなど、機密情報は伏せてください。

症状	優先して確認する項目	次の手順
起動時に実行環境がないと表示される	ランタイムの種類、バージョン、アーキテクチャ	エラーの案内に従って必要な実行環境を追加するか、同じOS向けの自己完結型ビルドを選びます。
UIは正常だが、コアの起動に失敗する	コアファイル、実行権限、待ち受けポート、設定ログ	ファイルを完全に展開したか確認します。Linuxでは実行権限を確認し、ポートが使用中でないか調べてください。
手動プロキシでは接続できるが、ブラウザーでは接続できない	システムプロキシの状態、ブラウザーのプロキシ設定	アドレスとポートを確認し、別のプログラムによって設定が書き換えられていないか調べます。
特定のノードだけハンドシェイクに失敗する	対象ノードのパラメーター、コアの対応状況、システム時刻	サーバー名や公開鍵など、対応する設定項目を確認します。先にUIを切り替える必要はありません。
終了後にネットワークに問題が起きる	システムプロキシの設定やTUNルートが残っていないか	プロキシ設定を元に戻し、クライアントとコアが終了していることを確認してから、直接接続をテストします。

選び方はシンプルです。macOSとLinuxでは各OSに対応したAvaloniaビルドを使います。Windowsへの初回インストールでは、ダウンロードページで現在提供されているデスクトップ版から始められます。WPF版を安定して使えているなら、まずはその環境を維持しましょう。UIやシステム連携、動作環境に明確な理由がある場合に、元に戻せる方法で移行してください。