v2rayN デスクトップ版と WPF 版の違い：Avalonia クロスプラットフォーム版の選び方

Avalonia デスクトップ版と WPF 版の主な違い

2 つのバージョンの違いは、まず UI 技術にあり、プロキシプロトコルの違いではありません。Avalonia はクロスプラットフォーム UI フレームワークで、同じ v2rayN デスクトップ UI を Windows、macOS、Linux 向けに構築できます。一方、WPF は Windows 向けのデスクトップ UI 技術なので、WPF 版は Windows 専用です。どちらもサブスクリプション管理、ノード選択、ルーティング設定、システムプロキシ制御、コアプロセス管理に対応します。実際の接続性能を左右するのは、同梱またはユーザーが設定した Xray コアであり、画面をどのフレームワークで描画するかではありません。

同じ有効な設定であれば、VMess、VLESS、Trojan、Shadowsocks、REALITY や一般的なトランスポート方式は、Avalonia と WPF のどちらに切り替えても自動的には変わりません。サーバーアドレス、ポート、ユーザー識別子、トランスポート層、安全設定、ルーティングルールが同じなら、コアに渡される設定内容も同じになるはずです。そのため、「あるノードが WPF 版では使えるのに Avalonia 版では使えない」ことを、すぐに UI フレームワークの違いに結び付けてはいけません。コアのバージョン、設定の移行、権限、DNS、システムプロキシの状態も確認してください。

「デスクトップ版」という名称は、「ランタイムが必要なパッケージ」と混同されがちです。ダウンロード時は、プラットフォーム、アーキテクチャ、UI の種類、ランタイム同梱の有無を確認してください。ファイル名に desktop とあるかだけで判断するのは禁物です。たとえば Windows x64 では、フレームワーク依存パッケージは比較的小容量ですが、説明に記載された .NET ランタイムがシステムに必要です。自己完結型パッケージは必要な実行コンポーネントを含むため容量が大きく、ランタイムを別途用意したくない環境に向いています。

対応 OS、UI、トレイ動作を比較するポイント

OS は最も分かりやすい選択基準です。macOS と Linux では WPF が動作しないため、Avalonia デスクトップ版を選びます。Windows では両方から選べます。他のプラットフォームと近い UI を使いたいなら Avalonia、Windows の通知領域、ウィンドウの最小化、スタートアップ、ネイティブなファイルダイアログを重視するなら WPF 版が適しています。

Avalonia の利点はクロスプラットフォームで構成を統一できることですが、「統一」とは 3 つの OS のデスクトップ動作が完全に同じという意味ではありません。macOS のメニューバー、Linux の各デスクトップ環境におけるトレイプロトコル、Windows の通知領域にはそれぞれ実装上の違いがあります。メインウィンドウを閉じたときに終了するかトレイに常駐するかも、v2rayN の設定項目やデスクトップ環境の対応状況に左右されます。初回起動後は、ウィンドウを閉じる、トレイアイコンをダブルクリックする、トレイメニューを右クリックする、プログラムを終了する、という 4 つの操作を確認してください。

高 DPI スケーリングも個別に確認しましょう。125%、150%、または複数のディスプレイで異なる倍率を使っている場合は、ノード一覧の列幅、QR コードウィンドウ、ログウィンドウ、メニューの表示位置を確認します。文字が途中で切れる場合は、まずシステムの拡大率と v2rayN のバージョンを確認し、その後クライアントを再起動してください。UI だけの問題をノード設定の変更で解決しようとしてはいけません。

Linux ユーザーは、使用しているデスクトップ環境がトレイに対応しているかも確認してください。トレイアイコンが表示されないからといって、コアが動作していないとは限りません。メインウィンドウで接続状態やログを確認したり、ローカルの待ち受けポートを調べたりできます。macOS ユーザーは、初回起動時に表示されるネットワークアクセス許可に対応し、システムプロキシを切り替えた後、ブラウザーで実際にアクセスして確認してください。

システムプロキシ、ルーティングルール、コアの動作に違いはあるか

v2rayN の「システムプロキシ」と「コアの実行」は別の層です。コアを起動すると、ローカルアドレスで SOCKS、HTTP、または混合プロキシのポートを待ち受けます。システムプロキシ機能は、Windows、macOS、Linux のデスクトップ環境にあるプロキシ設定をそのポートへ向けるものです。コアが正常でもシステムプロキシが設定されていなければ、手動でプロキシを指定したアプリは接続できても、通常のブラウザーは直接接続のままになることがあります。

WPF 版は Windows のシステムプロキシ API を呼び出します。一般的な操作入口は、メイン画面またはトレイメニューにある「システムプロキシ」です。Avalonia 版にも同じ機能がありますが、メニューの位置や状態アイコンはバージョンやプラットフォームによって異なる場合があります。切り替え後はメニューのチェック状態だけでなく、システムプロキシのアドレスが 127.0.0.1 を指しているか、ポートが「設定」→「パラメーター設定」のローカルポートと一致しているかも確認してください。

1. サーバー一覧から、動作確認済みのノードを 1 つ選び、アクティブサーバーに設定します。
2. 「設定」→「パラメーター設定」を開き、ローカル SOCKS、HTTP、または混合プロキシのポートを記録します。
3. コアを起動し、ログに待ち受け開始の成功メッセージが表示されるか確認します。ポートの競合や設定の解析エラーがないことも確認してください。
4. メイン画面またはトレイメニューからシステムプロキシを開き、必要に応じて自動設定またはグローバルプロキシモードを選択します。
5. ブラウザーを開いて実際にアクセスし、その後もう一度ダイレクト接続モードへ切り替え、設定に応じて通信経路が変わることを確認します。

ルーティングルールも、生成されたコア設定によって実行されます。ドメインルール、IP ルール、geosite、geoip、ダイレクト出口、プロキシ出口、ブロック出口のロジックは、UI が Avalonia か WPF かによって変わりません。ただし、両方の UI ではルートエディターの表レイアウト、ボタン位置、デフォルトの列幅が異なる場合があります。移行後はルールの順序を確認してください。前にあるルールが先に一致し、最終的な出口を変えることがあります。

特定のアプリだけでプロキシを使いたい場合は、システムプロキシを無効のままにして、アプリ内に 127.0.0.1 とローカルポートを入力できます。このときプロキシの種類を区別してください。アプリで SOCKS5 を指定する場合は SOCKS 待ち受けポート、HTTP を指定する場合は HTTP または互換性のある混合ポートを使います。10808 と 10809 を逆に設定することは、移行後に「コアは起動しているのにアプリが接続できない」よくある原因の 1 つです。

Windows で 10808 ポートを確認:
netstat -ano | findstr :10808

macOS または Linux で 10808 ポートを確認:
lsof -nP -iTCP:10808 -sTCP:LISTEN

OS と使い方に合わせてバージョンを選ぶ

Windows のみを使うユーザーにとって、WPF 版は通常、より分かりやすい出発点です。特に、通知領域への常駐、トレイへの最小化、システム起動時の自動起動、Windows ネイティブのウィンドウ動作に慣れている方に向いています。現在の WPF 版の設定が安定しており、クロスプラットフォームへの移行も必要ないなら、Avalonia がクロスプラットフォームフレームワークだからという理由だけで急いで変更する必要はありません。

Windows ユーザーが Avalonia を選ぶ合理的なケースは、macOS や Linux の端末と似た UI を使いたい場合、またはクロスプラットフォーム版のメニュー構成に慣れておきたい場合です。切り替える前に、サブスクリプション URL、ルーティングルール、必要なカスタム設定をバックアップしてください。旧プログラムのディレクトリ全体を新しいディレクトリに上書きすることはおすすめしません。リリースによって UI の種類、ランタイム構成、設定ファイルの構成が変わる可能性があるためです。

macOS と Linux のユーザーは、2 つを何度も比較する必要はありません。使用するプラットフォームとプロセッサアーキテクチャに合った Avalonia ビルドを選んでください。ダウンロード前にデバイスのアーキテクチャを確認し、合わない環境で x64 ビルドを使わないようにします。Linux ではパッケージ形式に必要な実行権限とデスクトップ依存関係も確認してください。macOS では初回起動に必要なシステムのセキュリティ許可とネットワーク権限を確認します。

職場環境と個人環境で結論が異なる場合もあります。業務用デバイスでシステムプロキシの設定、システム起動時の自動起動、バックグラウンドプログラムが一律に制限されている場合は、まず端末管理ルールに従い、アプリ単位のプロキシでテストしてください。個人のデバイスでは使用頻度に応じて自動起動を決められますが、どの環境でも 2 つの v2rayN インスタンスを同時に実行して同じ待ち受けポートを奪い合うことは避けてください。

• Windows のみ：クロスプラットフォームで統一された UI が明確に必要でない限り、まず WPF 版を選びます。
• Windows と他のデスクトップ OS を併用：Avalonia に統一すると、メニュー構成を切り替える負担を減らせます。
• トレイの安定性を重視：Windows ではまず WPF をテストし、Linux ではデスクトップ環境がトレイプロトコルに対応しているかを先に確認します。
• 既存の設定が安定：現在動作しているバージョンを残し、設定をエクスポートして移行テストを行います。元のディレクトリを直接上書きしないでください。
• ランタイムのインストールに制約がある：ダウンロードページの説明を確認し、現在の OS と実行環境に合ったビルド形式を選びます。

別のバージョンへ移行する手順

移行の目的は必要な設定を残しつつ、旧 UI のキャッシュ、ウィンドウ状態、互換性のない設定を新バージョンへそのまま持ち込まないことです。開始前に v2rayN を終了し、タスクマネージャーやシステムのプロセス一覧に v2rayN と Xray のプロセスが残っていないことを確認してください。実行中に設定をコピーすると、書き込み途中の不完全なファイルになる可能性があります。

サブスクリプションを利用している場合は、まずサブスクリプショングループ名、サブスクリプション URL、更新方法、カスタムメモを記録します。手動で追加したノードは、クライアントのエクスポート機能で共有リンクや設定を保存してください。ルーティングについては、有効なルールセット、ルールの順序、デフォルトの出口、DNS 設定を記録します。これらはウィンドウサイズ、テーマ、一覧の列幅より移行する価値があります。

1. 旧バージョンでサブスクリプションを一度更新し、不要だと確認できた重複ノードを削除します。
2. 必要なサーバー設定をエクスポートし、サブスクリプション URL とグループ設定を別途記録します。
3. 「設定」→「パラメーター設定」を開き、ローカルポート、ログレベル、システムプロキシモード、システム起動時の自動起動状態を記録します。
4. 旧バージョンを完全に終了し、新バージョンを新しい独立したディレクトリに展開またはインストールします。
5. 新バージョンを初めて起動したら、まずシステムプロキシを有効にせず、サブスクリプションとノードをインポートして項目を確認します。
6. ノードを 1 つ選んでコアを起動し、ログが正常であることを確認してから、システムプロキシを有効にしてブラウザーでテストします。
7. ルーティングと DNS を確認し、テストが完了してから旧ディレクトリを残すか決めます。

旧版が 10808 を使用していて、新版の初回起動時に別のポートが生成された場合、旧ポートに依存するブラウザー拡張機能、開発ツール、コマンドライン環境は自動的に追従しません。新版のポートを元の値に戻すか、呼び出し元の設定を 1 つずつ更新してください。ただし、2 つのプログラムが同時に 127.0.0.1:10808 を待ち受けないようにする必要があります。

移行後にノード一覧は正常なのに接続できない場合は、まずコアのログを比較し、すべてのサブスクリプションを先に削除しないでください。サーバーアドレスの名前解決、システム時刻、トランスポートパラメーター、REALITY 関連の項目、TLS サーバー名、ローカルポートの競合を重点的に確認します。すべてのノードが同時に失敗するなら、コア、権限、DNS、システムプロキシの問題である可能性が高く、1 つのノードだけが失敗する場合は、そのノードの設定を優先して確認します。

ダウンロード前と起動後のチェックリスト

ダウンロード前に確認するのは、OS、プロセッサアーキテクチャ、UI の種類、ランタイム形式の 4 点です。Windows x64 ユーザーは Avalonia と WPF から選べます。macOS と Linux では対応する Avalonia ビルドを選択します。フレームワーク依存ビルドと自己完結型ビルドの主な違いは、実行コンポーネントがプログラムに同梱されるかどうかであり、異なるプロトコル対応と誤解しないでください。

起動後は「設定、コア、ポート、システムプロキシ、ルーティング」の順に確認します。この順番なら UI の問題とネットワークの問題を切り分けられます。ウィンドウが開くのは UI プロセスが起動したことを示すだけです。ログにコアの待ち受け成功が表示されて初めてローカルプロキシの入口が確立され、ブラウザーの通信が想定どおり切り替わって、システムプロキシの設定が完全に反映されたと判断できます。

• Windows、macOS、Linux のうち、対象 OS に合ったビルドをダウンロードし、プロセッサアーキテクチャがデバイスと一致していることを確認します。
• Windows ユーザーは、圧縮ファイルの容量ではなく、Avalonia と WPF のどちらを使うかを明確に選びます。
• フレームワーク依存ビルドでは、ページに記載された .NET ランタイム要件を先に満たします。
• 初回起動後、「設定」→「パラメーター設定」で実際のローカル待ち受けポートを記録します。
• 動作するノードを 1 つ起動し、コアのログに設定解析エラーやポート競合エラーがないか確認します。
• システムプロキシを有効にして実際のアクセスをテストし、その後ダイレクト接続へ戻して状態の切り替えが有効か確認します。
• カスタムルーティングをインポートしたら、ノード一覧だけでなく、ルールの順序、デフォルトの出口、DNS も確認します。
• ウィンドウを閉じた後の動作が想定どおりであることを確認し、トレイメニューの終了項目を見つけます。

まだ判断できない場合は、現在の安定版を残したまま、もう一方のバージョンを独立したディレクトリに置いて短時間テストしてください。同じサブスクリプション、同じノード、同じルーティング条件で、起動速度、トレイ動作、システムプロキシの切り替え、スリープからの復帰をそれぞれ確認します。実際に操作して比較すれば、UI のスクリーンショットだけを見るより信頼できる判断ができます。