ALL-PLATFORM SETUP MANUAL

V2Ray全プラットフォーム対応インストール・設定ガイド

Windows、macOS、Linux、Androidに対応。クライアント選び、サブスクリプションの取り込みからシステムプロキシ、TUN、DNS、原因の切り分けまで解説します。まず接続を一度確立するならクイックスタートガイドから。パラメーターやプラットフォームごとの差異、トラブル対処の分岐を確認する場合は、この完全ガイドに戻ってください。

対応クライアント：v2rayN · v2rayNG · v2flyNG 最終更新：2026-08-19

TABLE OF CONTENTS

章立て

01 / PREPARE

共通の準備：クライアント、コア、サブスクリプションを区別する

クライアントはノードでもサブスクリプションサービスでもない

インストール前に、3つの用語を分けて理解しましょう。v2rayN、v2rayNG、v2flyNGはGUIクライアントで、設定の保存、コアの呼び出し、システムプロキシの設定、実行ログの表示を担当します。V2FlyとXrayはコアのファミリーで、インバウンド、アウトバウンド、ルーティング、DNS、トランスポートプロトコルを実際に処理します。サブスクリプションURLは、サーバー側で管理されるノード一覧です。クライアントがURLを読み込むと、一覧を選択可能なサーバー設定に変換します。クライアントをインストールしただけでは接続可能なノードは自動的に追加されません。サブスクリプションURLだけあっても、対応するクライアントがなければ、その設定でシステム通信を直接通すことはできません。

デスクトップではv2rayNを優先します。Windowsではデスクトップ版と従来のWPF版、macOSとLinuxでは対応するインストールパッケージが用意されています。メニューの位置はUIのバージョンによって多少異なりますが、基本概念は同じです。サブスクリプショングループにURLを保存し、サーバー一覧でノードを管理します。システムプロキシはブラウザーなどシステム設定に従うアプリを対象にし、TUNは仮想ネットワークインターフェースを通じてより広い通信を取り込みます。AndroidではXrayコアを搭載したv2rayNGを優先し、V2Flyコアのファミリーが必要な場合にv2flyNGを検討します。具体的なインストールパッケージは、当サイトのクライアントページでプラットフォームに合うものを選んでください。

インストール前に4つの基本情報を確認する

設定を準備する際は、サブスクリプションURLが完全か、端末の時刻が自動同期されているか、現在のネットワークから一般的なサイトに正常にアクセスできるか、システムアーキテクチャは何かを確認してください。サブスクリプションURLは通常HTTPまたはHTTPSで始まるアドレスです。コピー時に空白、改行、チャットアプリが付けた末尾の句読点を混ぜないでください。システム時刻のずれはTLSハンドシェイクや証明書判定に影響し、ノードは存在するのに接続直後に失敗することがあります。まずシステムの時刻とタイムゾーンを自動設定にしてからクライアントの問題に進むほうが、ノードを何度も切り替えるより効果的です。

システムアーキテクチャによってインストールパッケージが決まります。Windowsの一般的な端末はx64、macOSはApple SiliconとIntelのパッケージから選びます。Androidの主流端末は通常arm64で、構成が分からない場合はユニバーサルパッケージを使えます。Linuxはアーキテクチャに加えてディストリビューションのパッケージ体系も確認が必要です。Debian、Ubuntuと派生システムは通常deb、Fedora、RHEL系と関連ディストリビューションは通常rpmを使います。形式を間違えても通常システムが壊れることはありませんが、インストーラーに拒否されたり、アーキテクチャ不一致と表示されたりします。

プラットフォーム 優先クライアント インストール前の確認 初回接続方法
Windows v2rayN x64、デスクトップ版またはWPF版 システムプロキシ
macOS v2rayN Apple SiliconまたはIntel システムプロキシ
Linux v2rayN debまたはrpm、x64またはarm64 アプリプロキシまたはシステムプロキシ
Android v2rayNG arm64またはユニバーサルパッケージ システム接続の許可

切り戻し可能な最小構成を作る

初回起動時に、ルーティング、DNS、トランスポート層のパラメーター、TUNを同時に変更しないでください。最小構成は4ステップです。サブスクリプションを取り込み、更新し、ノードを1つ選び、システムプロキシまたはモバイル端末の接続を有効にします。その後、もともと安定しているサイトをブラウザーで開き、クライアントログを確認します。接続できたら分流とDNSを追加し、変更は毎回1種類に限定してください。異常が出ても、どの手順で発生したか分かります。「突然すべて使えなくなった」場合、ノードが一斉に無効になったのではなく、複数の高度な設定を同時に変更して追跡できなくなっていることが少なくありません。

初期サブスクリプションには、識別しやすい名前を付け、デフォルトのルーティング設定を残すことをおすすめします。更新前にサブスクリプションから生成されたノード項目を手動で変更しないでください。次回の更新で上書きされることが多いためです。特定のノードのトランスポートパラメーターを変更する必要がある場合は、独立した設定として複製するか、サービス提供元がサーバー側での変更に対応しているか確認してください。サブスクリプションURL自体は機密性の高い設定です。公開スクリーンショット、ログ、質問文に貼り付けないでください。トラブル対処では、エラーの種類、発生時刻、クライアントの状態だけを残し、ドメイン、ユーザー識別子、ノードアドレスは必要に応じて隠してください。

最後に、切り戻し手順を用意します。システムプロキシの切り替え場所を覚え、クライアント終了後にシステムネットワークをどう復元するか確認してください。デスクトップでシステムプロキシを使う場合は、クライアント終了前にシステムプロキシを解除します。TUNを使う場合は、先にTUNを無効にしてからプログラムを終了します。Androidでは接続を切断するだけでシステム接続を解放できます。ここまで準備すれば、各プラットフォームのインストール手順はUIと権限モデルが異なるだけで、サブスクリプション、ノード、ルーティング、DNSの基本的な考え方は共通です。

02 / WINDOWS

Windows：v2rayNのインストール、サブスクリプション、システムプロキシ

デスクトップ版と従来のWPF版、どちらを選ぶか

Windowsではv2rayNを第一候補にします。ダウンロードページにはデスクトップ版と従来のWPF版の2つの入口があります。デスクトップ版は新世代のクロスプラットフォームUIを採用しており、新規インストールや複数のデスクトップシステムを使う人に適しています。従来のWPF版はWindowsネイティブUIの系統で、メニューの情報密度が高く、旧版の操作に慣れた人向けです。どちらもサブスクリプション管理、ノード選択、システムプロキシ、ルーティング、TUN設定に対応しており、同時にインストールする必要はありません。迷ったらまずデスクトップ版を使い、UIの互換性、旧設定の移行、操作習慣など明確な理由がある場合だけWPF版を選んでください。

完全なインストールパッケージをダウンロードし、インストーラーの指示に従ってインストールします。ユーザーアカウント制御の画面が表示されたら、プログラム名と実行しようとしている操作が一致するか確認してから続行を許可してください。インストール先は現在のユーザーが書き込める場所を選び、プログラムデータを自動削除の対象になるディレクトリに置かないようにします。初回起動時、v2rayNは通常設定ディレクトリを作成し、コアコンポーネントを準備します。ファイアウォールの確認が表示された場合は、実際に必要なネットワーク範囲だけを許可してください。通常の単体利用で、接続失敗を防ぐために関係のない受信アクセスまで開放する必要はありません。

サブスクリプションを取り込み、使用するノードを選ぶ

サブスクリプショングループの管理画面を開き、グループ名を追加して、完全なサブスクリプションURLをURL入力欄に貼り付けて保存します。続いてサブスクリプションを更新します。更新が成功すると、メイン一覧にサーバー項目が表示されます。URLを保存しただけで更新していない場合、一覧が空のままなのは正常です。ノードを1つ選び、使用サーバーに設定します。ステータスバーまたは一覧のマークで現在の選択を確認できます。ノード名はサブスクリプション内の説明にすぎず、接続品質を示すものではありません。初回テストで大量のノードを連続測定する必要はなく、まず設定がそろった項目を1つ選んで基本接続を確認してください。

更新に失敗したら、まずURLの前後に空白がないか、ブラウザーでサブスクリプションURLを開けるか、グループが有効かを確認します。サブスクリプションの内容はBase64テキスト、共有リンクの集合、構造化設定などの場合があり、クライアントが内容から形式を判定します。サブスクリプション全体を単一ノードの編集画面に貼り付けたり、単一のVMessまたはVLESS共有リンクをサブスクリプションURL欄に入力したりしないでください。単一の共有リンクはクリップボードからサーバーに取り込み、サブスクリプションURLはサブスクリプショングループに登録します。入口の用途が異なります。

まずシステムプロキシを有効にし、TUNが必要か判断する

ノードを選んでサービスを起動し、システムプロキシモードを「システムプロキシを自動設定」など、明確に有効と分かるモードにします。これでWindowsのシステムプロキシに従うブラウザーやデスクトップアプリの通信がv2rayNに渡ります。ローカルの待ち受けポートはクライアントが管理するため、通常は手入力不要です。アプリに独自のプロキシ設定がある場合は「システムプロキシを使用」を選びます。システム設定を読み取らない場合だけ、v2rayNに表示される現在のローカルHTTPまたはSOCKSポートを確認して個別に入力してください。

システムプロキシは、経路が短く権限も少なく、簡単に解除できるため、まず設定を検証するのに適しています。ゲーム、一部のコマンドラインプログラム、ストアアプリ、独自のネットワークスタックを実装したソフトはシステムプロキシを迂回することがあります。その場合にTUNを検討します。TUNの有効化には管理者権限が必要なことが多く、仮想ネットワークアダプターが作成されます。初回有効化後はDNS、LANアクセス、スリープ復帰を再テストし、ブラウザーでページが開くかだけで判断しないでください。有効化後に全体がオフラインになったら、まずTUNを無効にしてシステムプロキシが動くことを確認し、次にドライバー、ルーティング、DNSを確認します。スイッチをさらに増やすのは避けてください。

Windowsでよくある残留プロキシと権限の問題

終了後にネットワークが切れる原因として最も多いのは、閉じたローカルポートをシステムプロキシが指し続けていることです。v2rayNを再び開き、システムプロキシを解除してから通常どおり終了してください。Windowsのネットワークとインターネット設定で、手動プロキシや設定スクリプトの残留を確認する方法もあります。いきなりネットワークスタック全体をリセットしないでください。他のネットワークソフトや保存済み設定まで影響します。まずプロキシアドレスがループバックアドレスを指しているか、対応ポートが待ち受け中かを確認すれば、原因を特定できることが多いです。

クライアントが設定を書き込めない、更新後に設定が消える、ログにアクセス拒否が出る場合は、インストール先とセキュリティソフトのフォルダーアクセス制御を重点的に確認します。日常利用で常に管理者モードを強制するのはおすすめしません。管理者権限が必要な機能は、操作時に表示される指示に従って許可してください。TUNだけが失敗しシステムプロキシは正常なら、サブスクリプション、ノード、コアは基本的に動いています。仮想アダプター、ルーティングの競合、権限に範囲を絞ってください。システムプロキシも失敗する場合は、ノード、時刻、サブスクリプション項目、コアのログに戻ります。

コマンドラインプログラムでは、古いプロキシ環境変数を引き継いでいないか先に確認できます。次のPowerShellコマンドは現在の環境を読み取るだけで、設定は変更しません。すでに無効なアドレスが出力された場合は、該当するターミナル設定またはシステム環境変数から削除してください。クライアントのノードを何度も変更する必要はありません。

Get-ChildItem Env:HTTP_PROXY
Get-ChildItem Env:HTTPS_PROXY
Get-ChildItem Env:ALL_PROXY

Windowsでスリープしたりネットワークを切り替えたりすると、仮想アダプターや古いルートがすぐに更新されないことがあります。まずクライアント接続を切り、ネットワークアイコンが戻るまで待ってからサービスを再起動します。頻発する場合は、日常のブラウジングにはシステムプロキシを優先し、より多くのプログラムを取り込む必要があるときだけTUNを有効にしてください。最初の操作順ははじめにで詳しく確認できます。この章ではバージョン選びとWindows特有の問題の切り分けを扱います。

03 / MACOS

macOS：チップの選択、権限、プロキシ設定

Apple SiliconかIntelかを先に確認する

macOSでv2rayNを使う場合、最初に確認するのはシステム名ではなくプロセッサーのアーキテクチャです。システム情報または「このMacについて」を開き、AppleシリーズのチップならApple Silicon対応のarm64パッケージ、Intelプロセッサーならx64パッケージを選びます。アーキテクチャを間違えると、システムに起動を拒否されたり、追加の変換レイヤーが必要になったりします。変数が増えてトラブル対処も難しくなるため、ダウンロードページでチップ別の入口を確認してからインストールしてください。

通常はdmgを開き、アプリをApplicationsに移動します。初回起動時にシステムのセキュリティ確認が表示されたら、システム設定のプライバシーとセキュリティでブロック理由を確認し、入手元と今回のダウンロード操作が一致すると確認してから開くことを許可します。1つのアプリのために端末全体のセキュリティ設定を長期間下げないでください。v2rayNがシステムプロキシの変更やネットワーク拡張の作成を必要とすると、システムが個別に権限を求めます。通常のファイルアクセスとは異なるため、機能を実際に有効にする際に指示に従って許可してください。

サブスクリプションの取り込みとノード選択

サブスクリプション設定を開き、グループを新規作成してURLを貼り付け、保存してから更新します。macOS版はWindows版と画面構成が異なる場合がありますが、サブスクリプショングループ、サーバー一覧、現在のノード、プロキシモードの4要素が中心である点は同じです。更新後にノード一覧が表示されたら、まず1つ選び、サービスを起動します。「サブスクリプションの更新完了」は「通信の取り込み完了」を意味しません。更新は設定の同期にすぎず、システムがクライアント経由で接続するかどうかはプロキシの有効化にも左右されます。

チャットツールからURLをコピーした場合は、特に改行や文字置換に注意してください。いったんプレーンテキストエディターに貼り付け、1行だけのURLであることを確認してからクライアントに入力します。クエリパラメーターを含むサブスクリプションURLは、末尾部分も切り取らないでください。更新時に証明書またはハンドシェイクエラーが出たら、まずシステム時刻、現在のネットワーク、サブスクリプションURL自体を確認します。特定のノードだけ失敗し他が正常なら、そのノードの項目を調べ、サブスクリプショングループ全体を削除しないでください。

システムプロキシとアプリプロキシの違い

システムプロキシを有効にすると、Safari、システムのネットワーク設定に従うブラウザー、多くのデスクトップソフトがv2rayNのローカルプロキシを使います。ターミナルのコマンドや一部の開発ツールが自動的にシステムプロキシを読むとは限らず、対応はツール次第です。ターミナルのリクエストが変わらないからといって、クライアント全体が壊れているとは判断しないでください。システムプロキシに従うブラウザーでも同時に確認します。コマンドラインツールがHTTPまたはSOCKSプロキシに対応している場合は、ツール側の設定にクライアント表示のローカルアドレスとポートを入力できます。

クライアントを終了する前に、システムプロキシを解除してください。アプリを終了したのにすべてのページが開けない場合は、システム設定のネットワーク詳細でHTTPプロキシ、HTTPSプロキシ、自動プロキシ設定が有効なままになっていないか確認します。残ったアドレスは127.0.0.1のポートを指していることが多く、その時点ではローカルで待ち受けるプロセスがありません。該当項目を無効にすればネットワークは復旧します。Wi-Fiを削除したり、ネットワークを忘れさせたり、DNSを消去したりする必要はありません。まず直接的なプロキシの残留を処理してください。

TUN、ネットワーク拡張、LANアクセス

macOSのTUNはネットワーク拡張または仮想インターフェースの権限に関係します。システムの初回確認で許可した後、機能をいったん無効にして再度有効にすると反映されることがあります。有効化前に、システムプロキシモードで接続が安定していることを確認してください。TUNが失敗したとき、「同じノードがシステムプロキシでは使えるか」が最も有効な比較対象になります。システムプロキシは正常でTUNを有効にすると切断される場合は、DNSの取り込み、デフォルトルート、他のネットワーク拡張との競合を優先して確認します。全通信を取り込むソフトが複数動くと、ルーティングの優先順位やDNS設定が上書きし合うことがあります。

プリンター、ファイル共有、ルーターの管理画面にアクセスする場合は、LANアドレスを直接接続のままにします。代表的なプライベートアドレス帯は10.0.0.0/8、172.16.0.0/12、192.168.0.0/16です。ループバックアドレスやリンクローカルアドレスもリモートノードに渡すべきではありません。デフォルトの分流設定には通常これらのルールが含まれますが、カスタムルーティング後は再確認してください。LAN機器だけ到達できない場合は、ノードのプロトコルを変更せず、プライベートアドレスが誤ってプロキシのアウトバウンドに送られていないかルールを確認します。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

Wi-Fi、テザリング、有線ネットワークを切り替えた後も、古いシステムプロキシが残ることがあります。一方、ローカルポートはクライアントの再起動で復元されます。正しい順序は、接続を切断し、ネットワークを切り替え、基本ネットワークが使えることを確認してから再接続することです。切り替え後にサブスクリプションは更新できるのにウェブページが開けない場合は、現在のノード、プロキシモード、DNSを確認します。サブスクリプションも更新できない場合は、新しいネットワークの認証ページと接続性を先に確認してください。

macOSで重要なのは特殊な設定を増やすことではなく、システム権限とネットワーク拡張の範囲を尊重することです。システムプロキシで足りるならシンプルな構成を保ち、より多くのアプリを取り込む必要がある場合だけTUNを有効にします。LANサービスが必要なら、プライベートアドレスを明確に直接接続へ残してください。ネットワーク拡張を変更するたびに、ブラウザー、ターミナル、LANの3方向を再確認すると、1つのページだけを試すより境界の問題を早く見つけられます。

04 / LINUX

Linux：パッケージ、デスクトッププロキシ、TUN権限

deb、rpm、アーキテクチャの選択

Linuxデスクトップではv2rayNを使います。ダウンロード前にディストリビューションのパッケージ体系とCPUアーキテクチャを確認してください。Debian、Ubuntu、Linux Mintなどは通常deb、Fedora、RHEL系やrpmパッケージ管理を使うディストリビューションはrpmを選びます。x86_64端末はx64、arm64端末は対応するarm64パッケージを使います。ターミナルでuname -mを実行するとアーキテクチャを確認できます。一般的にx86_64はx64、aarch64はarm64に対応します。

uname -m
cat /etc/os-release

ローカルのdebパッケージをインストールする場合は、aptに依存関係の処理を任せるのが基本です。rpmパッケージでは、ディストリビューションが現在使用しているパッケージ管理コマンドを使います。以下のコマンドに登場するファイル名は、現在のディレクトリに実際にダウンロードした名前へ置き換えてください。存在しない名前をそのまま使わないでください。GUIのソフトウェアセンターでもインストールできますが、依存関係エラーが出た場合はターミナルの出力のほうが原因を追いやすくなります。

sudo apt install ./v2rayN-linux-x64.deb

sudo dnf install ./v2rayN-linux-x64.rpm

インストーラーがアーキテクチャ不一致を報告したら、チェックを強制的に無視せず、適切なパッケージを選び直してください。デスクトップ用ランタイムが不足している場合は、ディストリビューションのバージョンがまだサポート期間内か確認し、システムの公式リポジトリから依存関係をインストールします。無関係な入手元からライブラリを混在させないでください。アプリが起動したら、ウィンドウ、トレイアイコン、設定ディレクトリが現在のユーザーに属しているか確認します。GUIクライアントを長期間rootで起動すると設定ファイルの所有者が混乱し、一般ユーザーで設定を保存できなくなることがあります。

サブスクリプションを取り込み、デスクトップ環境の違いを理解する

v2rayNのサブスクリプション手順は他のデスクトッププラットフォームと同じです。グループを作成し、URLを貼り付け、保存、更新、使用ノードの選択という流れです。主な違いはLinuxのデスクトップ環境にあります。GNOME、KDEなどのデスクトップでは、システムプロキシの設定場所やアプリが設定を引き継ぐ仕組みが完全には統一されていません。ブラウザーは通常デスクトッププロキシを読み取りますが、ターミナル、コンテナ、バックグラウンドサービスは読み取らないことが多いです。初回確認ではまずデスクトップブラウザーを使い、コアとノードが正常だと確認してからコマンドラインツールを個別に設定します。

一部の軽量デスクトップ環境には統一されたシステムプロキシのインターフェースがありません。その場合、v2rayNの「システムプロキシを設定」だけではすべてのアプリを対象にできないことがあります。クライアントが現在待ち受けているHTTPおよびSOCKSポートを確認し、対象アプリのプロキシ設定にアドレスを入力してください。現在のターミナルだけで一時的に試す場合は、環境変数を設定する方法もあります。テスト後にターミナルを閉じれば元に戻るため、無効なポートをシェル設定に長期間残さずに済みます。

export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809
export ALL_PROXY=socks5://127.0.0.1:10808

例示するポートは形式を説明するためのものです。実際の値は必ずクライアント画面の表示に従ってください。v2rayNでローカルポートを変更した場合は、環境変数も合わせて変更します。大文字・小文字の変数を別々に読むツールもあるため、トラブル対処ではenv | grep -i proxyを実行して現在のセッションを確認できます。コマンドラインは使えるのにブラウザーが使えない場合、デスクトッププロキシが未設定であることが多いです。ブラウザーは使えるのにコマンドラインが使えない場合は、ツールがシステムプロキシを引き継いでいない可能性があります。両者を混同しないでください。

TUNに必要な権限とルーティングの確認

LinuxでTUNを有効にするには、/dev/net/tunへのアクセス、仮想インターフェースの作成、ルーティングの変更が必要です。v2rayNは権限昇格の仕組みを通じてこれらを実行する場合があります。画面にTUNの起動失敗が表示されたら、まずカーネルモジュールとデバイスノードが存在するか確認し、次にログの権限エラーを確認してください。アプリ全体を永続的にrootで実行するのは避けます。ネットワーク管理権限が必要なコンポーネントだけに限定的な権限を与え、ユーザー設定は一般アカウントの所有に保つのが正しい方向です。

ls -l /dev/net/tun
ip address
ip route

TUNの有効化前後で、デフォルトルートとDNSの状態をそれぞれ記録します。有効化後に完全にオフラインになった場合は、TUNを無効にしてデフォルトルートが戻るか確認します。ドメインだけ開けず既知のアドレスには応答がある場合はDNSに絞ります。LAN機器に接続できない場合は、プライベートアドレスがTUNへ誤送信されていないか確認します。NetworkManager、systemd-resolved、デスクトップ環境がDNSを同時に管理することがあるため、最終的にどの層が有効か確認し、3か所に異なるサーバーを繰り返し設定しないでください。

スリープ、トレイ、バックグラウンドプロセス

デスクトップ環境によってはウィンドウを閉じるだけでトレイに隠れ、別の環境ではトレイ拡張がなく、ウィンドウを閉じるとプログラムが終了します。初回利用時にv2rayNの終了動作を確認し、クライアントが終了したと思ったのにシステムプロキシが残る事態を避けてください。プロセス一覧とポートの待ち受け状態から、コアが動作中か判断できます。システムプロキシがローカルポートを指しているのにプロセスが終了していると、ブラウザーではすべてのページが接続失敗になります。

スリープから復帰すると、ネットワークインターフェース名、デフォルトルート、DNSが再生成されることがあります。システムプロキシモードなら通常は再接続だけで済みますが、TUNモードではいったん無効にしてから再度有効にする必要がある場合があります。復帰後もログに古いインターフェースが表示されるなら、システムネットワークが安定するまで待ってからクライアントを再起動します。コンテナと仮想マシンは独立したネットワーク名前空間を持つため、ホストのシステムプロキシが内部の通信を自動的に対象にすることはありません。コンテナでプロキシを使う場合は、プロキシアドレスを明示的に設定し、ホストの待ち受けポートへ到達できることを確認してください。

Linuxのトラブル対処で重要なのは、「クライアントのコアが動作しているか」「デスクトップアプリがプロキシを読み取っているか」「システムルートがTUNに取り込まれているか」の3層を分けることです。1つのコマンドの結果だけで全体を判断しないでください。ブラウザー、プロキシ環境変数を付けたターミナルのリクエスト、ip routeはそれぞれ別の層に対応します。層ごとに確認すれば、デスクトップ環境の違いをノード障害と誤認せずに済みます。

05 / ANDROID

Android：v2rayNG、v2flyNG、接続の許可

クライアントとインストールパッケージの選択

Androidではv2rayNGを第一候補にします。Xrayコアを使用し、多くのサブスクリプションや一般的なプロトコル設定に適しています。v2flyNGはV2Flyコアを使用し、別のコアファミリーを試す選択肢になります。両クライアントにはarm64とユニバーサルのインストールパッケージがあります。2015年以降の主流スマートフォンなら、まずarm64を選べます。アーキテクチャが不明、インストール時に互換性エラーが出る、より広い端末を対象にしたい場合はユニバーサルパッケージを選んでください。2つのクライアントを同時に接続状態にしないでください。システムは同時にこの種の接続を1つしかネットワークへ渡せません。

インストールパッケージを開くと、現在のブラウザーまたはファイル管理アプリにアプリのインストールを許可するよう求められることがあります。この権限は実際にインストールを実行するアプリにだけ与え、完了後はシステム設定で無効にできます。インストールできない場合は、ダウンロードが完全か、アーキテクチャが合っているか、署名元の異なる同名アプリが端末に存在しないかを確認します。上書きに失敗した場合は、まずクライアント内の重要な設定をバックアップしてから、古いアプリをアンインストールするか判断してください。サブスクリプションや手動ノードまで失わないようにします。

サブスクリプション、クリップボードのリンク、QRコードの取り込み

v2rayNGを開き、サブスクリプション設定からURLを追加します。保存してメイン画面に戻り、サブスクリプションを更新してください。更新が成功するとノード一覧が作成され、その中から1つ選んで現在の設定にします。単一の共有リンクは「クリップボードから取り込む」などの入口を使います。QRコードは単一ノードや、クライアントが認識できる設定内容の取り込みに適しています。サブスクリプション用と単一ノード用のQRコードは見た目が同じため、最終的にはスキャン結果がサブスクリプション管理に入るかノード一覧に入るかで判断します。

QRコードを読み取れない場合は、カメラの権限、QRコード全体が表示されているか、画面の反射を確認します。機密性のあるQRコードをオンライン認識サービスへアップロードする必要はありません。リンクをコピーするときも、途中で切れないよう注意してください。更新後にノードが空なら、グループが有効か、サブスクリプション形式が現在のコアに対応しているか、URLがログインページやエラーページを返していないかを確認します。サブスクリプション入口の詳しい違いはサブスクリプションURLの取り込み手順で確認できます。

初回接続とアプリ別プロキシ

ノードを選択して接続ボタンをタップすると、システムのネットワーク接続許可が表示されます。許可するとステータスバーに接続マークが表示され、クライアントログに接続処理が記録されます。初回テストではデフォルトルートを保ち、複雑なアプリ別ルールは有効にしないでください。まずブラウザーで接続を確認し、その後ほかのアプリを確認します。Androidではデスクトップのように「システムプロキシ」を別途切り替える必要はありません。接続を許可すると、ルールに合うアプリの通信がクライアントへ渡ります。

アプリ別プロキシは、どのアプリをクライアント経由にするかを決めます。一般的には、選択したアプリだけをプロキシする方法と、選択したアプリを迂回させる方法があります。設定前にモード名をよく読み、条件を逆にしないよう注意してください。システムコンポーネント、ブラウザーエンジン、アプリ本体が別パッケージの場合もあります。期待どおりにならない場合は、外部ブラウザーやシステムダウンローダーを呼び出していないか確認します。初回設定ではアプリ別プロキシを有効にせず、全体接続が成功してからアプリを1つずつ追加または除外するほうが原因を追いやすくなります。

バックグラウンド制限、バッテリー最適化、ネットワーク切り替え

しばらく接続した後に自動切断される場合、システムによるバックグラウンドアプリのバッテリー制限が原因であることが多いです。アプリ情報でv2rayNGまたはv2flyNGのバックグラウンド実行を許可し、端末が提供する設定に従って対象クライアントの厳格なバッテリー最適化を無効にします。対象は現在のクライアントだけでよく、すべてのアプリを無制限にする必要はありません。タスククリーナーがバックグラウンドプロセスを強制終了する場合は、該当する削除ルールからクライアントを除外してください。

Wi-Fiとモバイルネットワークを切り替えると、既存の接続が一時的に使えなくなることがあります。まずシステムがアドレスを取得するまで待ち、クライアントが自動復旧するか確認します。戻らない場合は手動で切断して再接続します。Wi-Fiにウェブ認証が必要なら、先にクライアントを切断して認証を完了し、その後再接続してください。特定のWi-Fiだけ失敗してモバイルネットワークが正常なら、クライアント設定はおそらく問題ありません。そのWi-FiのDNS、認証ページ、IPv6経路を確認し、アプリを再インストールするのは後にします。

DNS、IPv6、LANアクセス

Androidで「アプリは接続済みなのにドメインが開けない」場合は、まずDNSを確認します。クライアント内蔵DNS、システムのプライベートDNS、ノード側のリモート名前解決が結果に影響することがあります。初回のトラブル対処ではクライアントのデフォルトDNSを維持し、システムのプライベートDNSが現在のネットワークから到達できないサーバーを指定していないか確認します。特定のドメインだけ解決に失敗する場合は、すべての問い合わせ経路を変更せず、分流DNSを設定します。

IPv6が使えるかどうかは、現在のモバイルネットワーク、Wi-Fi、ノード設定に左右されます。ログでIPv6アドレスが選択されているのに接続がタイムアウトする場合は、クライアントのDNSポリシーで現在の経路に合うアドレス族を優先するか、ノードが対応する出口を提供しているか確認します。すべてのタイムアウトをIPv6のせいにしないでください。まずログの対象アドレスとエラーが起きた段階を見ます。LAN機器に届かない場合は、プライベートアドレスの迂回を許可しているか確認し、アプリ別ルールがファイル管理やキャスト関連のコンポーネントを不適切なアウトバウンドへ送っていないか確認します。

v2rayNGとv2flyNGでは、UIの更新によってメニュー名が変わることがありますが、基本の流れは安定しています。設定を取り込み、ノードを選び、システム接続を許可し、ログを確認するという流れです。まずデフォルト設定でこの流れを完了してから、アプリ別設定、DNS、バックグラウンド制限に進めば、Androidの大半の問題を単一の変数に分解できます。2つのクライアントを比較するときも、同じノードを使って対照し、差がコアの互換性によるものかノード自体によるものか判断してください。

06 / SUBSCRIPTION

サブスクリプションとノード管理：更新、上書き、互換性

サブスクリプション更新で実際に行われること

サブスクリプションの更新は速度測定でも、コアの再インストールでもありません。クライアントがサブスクリプションURLへリクエストを送り、返された内容を読み取り、ノード項目を解析して、該当グループのサーバー一覧を更新します。ノード名、アドレス、ポート、ユーザー識別子、トランスポート方式、TLSパラメーターは通常サブスクリプションから取得されます。更新後も現在のノードが維持される場合がありますが、元の項目が削除されると再選択が必要になることもあります。「更新は成功したのに接続が変わらない」場合は、現在のノードが古い項目のままではないか確認してください。

サブスクリプショングループを使うと、異なる入手元の設定を分離できます。複数のサブスクリプションを判別しにくい1つの名前へ詰め込まず、用途ごとにグループを作ることをおすすめします。グループを更新する前に、現在のサーバーを覚えておくと安心です。新しい一覧に問題があっても、検証済みの別グループへ切り替えて対処を続けられます。クライアント内のサブスクリプションURLは機密情報として扱ってください。URL自体にアクセス識別子が含まれることがあります。スクリーンショットにアドレス欄、QRコード、完全なノード項目を写さないでください。

自動更新と手動更新の使い分け

手動更新は、初回取り込み、設定変更直後の同期、トラブル対処に適しています。自動更新は長期メンテナンス向けですが、間隔を短くしすぎないでください。サブスクリプションの内容が変わらない限り、繰り返しリクエストしても接続は改善しません。自動更新に失敗しても、保存済みの古いノードには影響しないことが多く、クライアントはローカル一覧を使い続けられます。その場合は「サブスクリプションURLにアクセスできない」のか「既存ノードに接続できない」のかを分けて判断してください。

サブスクリプションが空の内容、ウェブページのテキスト、認証ページを返すと、クライアントが形式エラーを表示することがあります。URLを公開せず、自分の端末のブラウザーで期待した内容が返っているか確認できます。ブラウザーでは開けるのにクライアントが失敗する場合は、システムプロキシが更新リクエストを迂回させていないか、証明書がローカルネットワークで置き換えられていないか、クライアントが返却形式に対応しているかを確認します。更新時にプロキシを使うか直接接続するかは、サブスクリプションURLへの到達性で決めてください。固定の方式がすべてのネットワークに適用できるとは限りません。

手動変更が上書きされる理由

サブスクリプションのノードはリモートの一覧から生成され、次回更新時に項目が再書き込みされます。ノード名、ポート、トランスポートパラメーターを手動で変更しても、更新で上書きされることがあります。これはサブスクリプション管理として正常な動作です。カスタマイズを残す必要がある場合は、ノードを独立したサーバーとして複製し、自動更新グループから外します。またはサブスクリプション提供元の管理画面で変更してから再同期してください。生成結果を直接編集する方法は一時的なテスト向けで、長期運用には適しません。

ルーティングとDNSは通常クライアント全体の設定で、ノード更新によって上書きされるとは限りません。「サーバー項目」と「ローカルポリシー」を分けて管理してください。サーバー項目はリモートへの接続方法、ルーティングは通信をどのアウトバウンドへ送るか、DNSはドメインをどう解決するかを決めます。ノード更新後にすべてのサイトの挙動が突然変わった場合は、まず現在のノードとサーバー項目を確認します。一部のドメインだけ経路が想定と異なる場合に、ルーティングとDNSを確認してください。

プロトコル項目とコアの互換性

一般的なサブスクリプションにはVMess、VLESS、Trojanなどのノードが含まれます。プロトコル名は最初の情報にすぎず、接続できるかどうかはトランスポート方式、TLS、セキュリティパラメーター、サーバー名、パスなどの項目にも左右されます。クライアントがノード名を認識したからといって、すべての項目がそろっているとは限りません。ログに「不明な項目」「未対応のトランスポート方式」、設定解析失敗などが出る場合は、サブスクリプションの生成形式と現在のコアの対応範囲が合っていない可能性があります。

Androidではv2rayNGとv2flyNGを使ってコアファミリーを比較できます。ただし比較時は同じノード、同じネットワーク、できるだけ同じルーティング設定を使ってください。ある設定が一方のコアでだけ動いても、もう一方のクライアント全体が故障しているとは限りません。特定項目の実装や対応範囲が異なる可能性があります。デスクトップのv2rayNでも、選択中のコアがノードの要件に合うか確認します。ノード名からプロトコルを推測せず、設定詳細で実際の項目を見るほうが確実です。

サブスクリプション異常の段階的な確認

第1段階はURLです。完全か、期限切れでないか、空白が混ざっていないかを確認します。第2段階はリクエストです。現在のネットワークからアクセスできるか、返ってきたものがサブスクリプション本文かを確認します。第3段階は解析です。クライアントが形式を認識するか、ログに項目エラーがないかを確認します。第4段階は接続です。ノードがドメイン解決、TCP接続、TLSハンドシェイクを完了できるか確認します。段階ごとに処理するほうが、サブスクリプションを何度も削除して追加し直すより速く、使用可能な設定も残せます。

サブスクリプション内の数十個のノードが同時に失敗する場合は、端末の時刻、DNS、ネットワーク、サブスクリプション項目全体の変更、コア設定など、共通条件をまず疑います。1つだけ失敗するなら、そのノードのアドレス、ポート、トランスポートパラメーターを確認します。ノードには接続できるのに特定サイトだけ失敗する場合は、ルーティングとDNSの層へ進みます。この判断ツリーにより、すべての問題を「サブスクリプションが無効」と決めつけずに済みます。

サブスクリプション管理の目的は、一覧を長くすることではありません。設定の入手元、更新時刻、現在のノードを追跡できる状態にすることです。グループを整理し、検証済みノードを1つ比較用に残し、高度なパラメーターを変更する前に元の値を記録してください。サブスクリプションの内容が変わっても、問題がリモート一覧、クライアントの解析、ローカルネットワークのどこにあるかをすぐ判断できます。

07 / PROXY AND TUN

システムプロキシ、TUN、ルーティング、DNSの関係

システムプロキシは対応するアプリだけを対象にする

システムプロキシは本質的に、ローカルHTTPまたはSOCKSの入口をOSとアプリへ通知する仕組みです。ブラウザーや一部のデスクトップソフトがこの設定を読み取り、リクエストをv2rayNへ渡します。すべてのパケットを強制的に捕捉するわけではないため、ゲーム、コマンドラインツール、バックグラウンドサービス、独自のネットワークスタックを持つプログラムは迂回することがあります。システムプロキシは必要な権限が少なく、経路が分かりやすく、解除も簡単です。初回接続と日常のブラウジングの標準方式に適しています。

クライアントは通常、127.0.0.1などのループバックアドレスでローカルHTTPおよびSOCKSポートを待ち受けます。ループバックアドレスは本機からだけアクセスでき、単体利用に適しています。LANからの接続を許可する場合は、待ち受け範囲とファイアウォールルールを明確にし、本機のアプリを接続するためだけにすべてのネットワークインターフェースへポートを公開しないでください。アプリでプロキシを手動設定する場合、プロトコル種別とポートを対応させる必要があります。SOCKSポートをHTTPプロキシ欄に入力すると、接続拒否やプロトコルハンドシェイク失敗のような結果になります。

TUNがより多くのアプリを取り込める理由

TUNは仮想ネットワークインターフェースを作成し、システムルートをそのインターフェースへ向け、クライアントが各接続をプロキシ経由にするか直接接続にするか判断します。アプリがプロキシプロトコルを理解する必要がないため、システムプロキシより広い範囲を対象にできます。その代わり、より高い権限が必要で、システムルート、DNS、他の仮想ネットワークソフトと相互作用します。TUNは「高速モード」ではなく、誤ったノードを修復するものでもありません。システムプロキシを読み取らないアプリを取り込むための仕組みです。

有効化の順序は次のとおりです。まず同じノードがシステムプロキシで使えることを確認し、現在のDNSとLANの状態を記録します。次にデフォルトルートを取得する他のソフトを終了してからTUNを有効にします。確認時は通常のドメイン、LANアドレス、システムプロキシを迂回していたプログラムを少なくとも1つテストしてください。ブラウザーは使えるのにLANが使えない場合は、プライベートアドレスの直接接続を確認します。すべてのドメインが失敗する場合はDNSを確認し、特定のプログラムだけ失敗する場合は特殊なプロトコルや独立したネットワーク環境を使っていないか確認します。

モード 対象範囲 必要な権限 適した段階
システムプロキシ システムプロキシに従うアプリ 低い 初回確認、ブラウザー、一般的なデスクトップアプリ
アプリ内プロキシ 単一のアプリ 低い コマンドラインツールと独自のプロキシ設定
TUN システムルートから仮想インターフェースに入る通信 高い より多くのアプリを取り込む必要がある場合

ルーティングルールは順番に照合される

ルーティングルールは、通信をどのアウトバウンドへ渡すかを決めます。通常は、明確なプライベートアドレスの直接接続を先に記述し、次にプロキシしたいドメインやアドレスを記述し、最後にデフォルト動作を設定します。ルールの順序は重要です。通信が前のルールに一致すると、通常は後続のルールが処理されません。範囲の広すぎるドメインルールを先頭に置くと、後ろの直接接続ルールが永遠に適用されないことがあります。分流を調べるときは、実際の対象ドメイン、解決後のIP、該当したルール、最終アウトバウンドのタグを確認します。

domainStrategyは、ルーティング段階でドメインと解決結果をどう使うかを決めます。AsIsは元のドメインによる照合を優先し、ドメインルールが明確な設定に適しています。他のポリシーでは必要に応じてアドレスを解決し、IPルールに参加させることがあります。動作を理解しないまま、ルーティングポリシーとDNSを同時に変更しないでください。まずデフォルト値のまま検証し、「ドメインルールに一致しない」「対象IPで分流したい」といった具体的な要件に応じて調整します。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      }
    ]
  }
}

DNSリーク、リモート解決、分流DNS

DNSはドメインをアドレスへ変換しますが、DNSリクエストと接続通信は別の経路を通せます。ドメインをローカルで解決し、接続だけをプロキシに通すと、現在のネットワークの影響を受ける可能性があります。逆にすべての問い合わせをリモートへ送ると、ローカルドメインやLANサービスが正しく解決できないことがあります。ドメインの種類に応じて解決経路を決め、ルーティングとDNSの判断を一致させるのが適切です。詳しい手順はDNSリークの確認と設定手順で確認できます。

DNSの問題が起きたら、まず名前解決の失敗と接続の失敗を分けます。ログにドメインが見つからない、DNSクエリがタイムアウトしたと明確に出ている場合だけDNS層を調べます。アドレス解決済みでTCP接続がタイムアウトするなら、ノード、ルーティング、対象ネットワークを確認します。ブラウザーが独自のセキュアDNSを使い、システム設定を迂回することもあります。比較テストでは一時的にブラウザーがシステムDNSに従うようにし、クライアント、システム、ブラウザーの3つの解決経路が同時に変わらないようにします。

いわゆるリーク防止設定は、サーバーアドレスを1つ入力するだけではありません。アプリの問い合わせ、システムの問い合わせ、TUNによる取り込みの間に予期しない迂回経路がないことを確認するものです。システムプロキシとTUNの2つのモードでそれぞれ確認してください。システムプロキシは通常、システムDNS全体を強制的に取り込みませんが、TUNは問い合わせをより一元的に処理できます。変更後は古いキャッシュを消去するか、キャッシュの期限切れを待ってください。そうしないと過去の結果を新設定の効果と誤認します。

段階的な設定のおすすめ順序

第1段階はデフォルトルートとシステムプロキシだけを使い、サブスクリプションとノードを確認します。第2段階でプライベートアドレスの直接接続と必要なドメインルールを追加し、各ルールが適用されることを確認します。第3段階でDNSを設定し、解決経路と分流を一致させます。第4段階で初めてTUNを有効にし、より多くのアプリ、LAN、スリープ復帰をテストします。各段階が終わるたびに切り戻し可能な設定を残してください。一度にすべてを有効にするより遅く見えますが、方向のない試行錯誤を大幅に減らせます。

システムプロキシ、TUN、ルーティング、DNSは互いに関係しますが、役割の異なる4つの層です。システムプロキシはアプリがリクエストをクライアントへ渡すかを決め、TUNはシステムパケットが仮想インターフェースへ入るかを決めます。ルーティングはクライアントに入った後のアウトバウンドを決め、DNSはドメインからアドレスを得る方法を決めます。メニューの位置を覚えるより役割から原因を特定するほうが、プラットフォームやUIが変わっても応用できます。

08 / DIAGNOSIS

よくある設定問題：ログの段階ごとに切り分ける

まず障害がどの層で起きたか判断する

接続経路全体は6層に分けられます。ローカルアプリがクライアントに入ったか、ドメインが解決されたか、クライアントがノードアドレスへ接続したか、トランスポート層が確立したか、TLSなどのセキュリティ層が完了したか、対象リクエストがルーティングどおりにアウトバウンドへ出たかです。ログのエラー位置は「ウェブページが開かない」という情報より具体的です。トラブル対処では時刻を記録し、もう一度リクエストを実行して、その時刻付近のログを確認してください。以前のエラーやバックグラウンドの再試行に埋もれずに済みます。

ログに新しい接続がまったくない場合は、アプリがシステムプロキシを迂回している、アプリ別ルールで除外されている、TUNが該当ルートを取り込んでいない可能性があります。DNSタイムアウトが出る場合は、解決サーバーと問い合わせ経路を確認します。ノードアドレスへの接続がタイムアウトする場合は、現在のネットワーク、アドレスの到達性、ポートを確認します。TLSハンドシェイクに失敗する場合は、システム時刻、サーバー名、セキュリティパラメーターを確認します。接続確立後に対象からエラーが返る場合は、ルーティングと対象サービスを確認し、すぐにクライアントを再インストールしないでください。

サブスクリプションは更新できるのに、すべてのノードへ接続できない

これは、少なくともクライアントがサブスクリプションURLへアクセスできることを示しますが、ノード経路が正常だとは限りません。まず端末の時刻とタイムゾーンが自動同期されているか確認し、ノードを1つ選んで古いログを消去してから再接続します。すべてのノードが同じDNSエラーを出すなら、システムとクライアントのDNSを確認します。すべてがノードアドレス接続時にタイムアウトするなら、現在のネットワークとルーティングを確認します。すべてが設定解析段階で失敗するなら、サブスクリプション形式またはコアの互換性を優先して調べます。

数十個のノードを次々に切り替え、画面の色だけで判断しないでください。切り替えるたびに一定時間の完全なログを残し、エラーが同じ段階で起きているか比較します。同じ段階なら共通条件、異なる段階ならノード固有の差である可能性があります。システムプロキシとTUNを比較することもできます。システムプロキシは正常でTUNだけ失敗するなら、権限、ルーティング、DNSの取り込みに範囲を絞れます。両方失敗するなら、ノード、サブスクリプション、コアに近い層を確認します。

接続済みと表示されるのに、ウェブページが開かない

「接続済み」は通常、クライアントプロセスまたはシステム接続が確立したことを示すだけで、すべての対象リクエストが成功したことを意味しません。まずブラウザーがシステムプロキシを読み取っているか、モバイル端末の対象アプリがアプリ別ルールに含まれているか確認します。次にログに該当ドメインのリクエストがあるか確認します。リクエストがなければ取り込み層を処理し、DNS問い合わせはあるのに結果がないならDNSを確認します。アドレス取得後に接続が失敗するなら、ルーティングとノードを確認します。

デスクトップでは、システムプロキシのアドレスが現在のv2rayNのローカルポートと一致しているかも確認します。アップグレード、設定移行、手動変更後も、システムが古いポートを指していることがあります。ブラウザー独自のプロキシ拡張がシステム設定を上書きする場合もあるため、トラブル対処時はいったんプロキシ経路を1つだけにします。1つのブラウザーだけ異常なら、システムプロキシに従う別のアプリで試すと、ブラウザー側かクライアント側かを素早く判断できます。

一部のサイトまたはアプリだけ失敗する

一部だけ失敗する場合は、分流、DNS、IPv4とIPv6の選択、アプリ独自のネットワークスタックが関係していることが多いです。まず失敗した対象が想定したルーティングルールに一致しているか確認し、次にDNSが返したアドレスを確認します。ドメインルールの一致形式も確認してください。完全なドメイン、サブドメイン、キーワードでは対象範囲が異なります。ルールが広すぎると無関係な対象に影響し、狭すぎると1つのホスト名にしか一致しません。変更後は関連キャッシュを消去して再テストします。

アプリは失敗するのにブラウザーが正常な場合は、アプリがシステムプロキシに対応しているか、UDPを使っているか、コンテナや仮想マシン内で動作しているかを確認します。システムプロキシは主にHTTP系リクエストを対象とし、TUNはより一般的な通信を取り込めますが、クライアントがUDPをどう処理するかも確認が必要です。Androidのアプリ別プロキシではパッケージ選択を確認し、Linuxコンテナではネットワーク名前空間を確認します。Windowsのバックグラウンドサービスは別のアカウントコンテキストで動くことがあります。これらは取り込み層の違いであり、サブスクリプション層の問題ではありません。

TUNを有効にすると全体がオフラインになる

第1にTUNを無効にし、基本ネットワークとシステムプロキシが戻るか確認します。第2に仮想インターフェースが作成されたか、デフォルトルートが想定した場所を指しているか確認します。第3にDNSが到達不能なアドレスへ変更されていないか確認します。第4に他の仮想ネットワークプログラムによるルーティング競合を除外します。全体がオフラインの状態でノードプロトコルやサブスクリプション項目を変更し続けないでください。仮想インターフェースが確立していない問題とは直接関係しません。

TUNを無効にしてもオフラインのままなら、残留システムプロキシ、デフォルトルート、DNSを確認します。Windowsでは手動プロキシ、macOSではネットワークのプロキシ項目、Linuxでは環境変数、デスクトッププロキシ、ip routeを確認してください。基本ネットワークを復旧してから再度有効にします。ネットワーク切り替えやスリープ復帰後に頻発する場合は、端末全体を再起動する前にクライアント接続を作り直します。ルートが戻らない場合にだけ、より深いシステムネットワーク処理を検討してください。

ログの読み方と、共有してよい情報

有効なログには時刻、モジュール、エラーの種類、状況が含まれます。一般的なキーワードは、解析エラー、接続タイムアウト、接続拒否、ハンドシェイク失敗、設定項目エラー、権限エラーに分けられます。トラブル対処ではエラーの前後数行をコピーし、プラットフォーム、クライアント、システムプロキシかTUNか、問題が安定して再現するかを説明してください。「failed」の1行だけを切り取らないでください。同じ単語でも発生段階によって原因がまったく異なります。

ログを共有する前に、サブスクリプションURL、ノードアドレス、ユーザー識別子、認証項目、ローカルの個人パスを隠してください。ノード名にアカウント情報が含まれている場合も処理が必要です。プロトコル種別、トランスポート方式、エラーモジュール、発生順序を残せば、通常は十分です。よくある質問はFAQページで確認できます。エコシステムとクライアントの関係はProject V、V2Fly、Xrayの関係で解説しています。

再現可能な復旧手順

設定を変更しすぎて追跡できなくなったら、パラメーターを追加し続けないでください。まず現在の設定をエクスポートまたは記録し、TUNを無効にし、システムプロキシを解除して、デフォルトのルーティングとDNSポリシーを戻します。サブスクリプショングループを1つだけ残し、更新後にノードを1つ選び、システムプロキシで最小テストを行います。成功したら「ルーティング、DNS、TUN、アプリ別設定」の順に1項目ずつ戻し、追加するたびにログと対象の挙動を確認します。

最小構成でも失敗する場合は、正常と分かっている別のネットワークで比較し、端末設定と現在のネットワークを切り分けます。次に同じサブスクリプション内の別ノードで比較し、ノード固有の問題か共通設定かを確認します。Androidではv2rayNGとv2flyNGでコアファミリーを比較することもできますが、ネットワークとノードは同じにしてください。対照実験では一度に1つの変数だけを変えると、結果を説明できます。

最終的な目標は、ログのすべてのメッセージを消すことではありません。リクエストが想定どおりクライアントに入り、正しく解決され、接続に成功し、正しいアウトバウンドに一致することを確認することです。一部の再試行や重要でない通知は実際の利用に影響しない場合があります。まずリクエストを中断させた最初のエラーを解決し、その後に派生したエラーを処理します。この順序を理解すれば、UIの名称が変わってもトラブル対処の方法は変わりません。