V2Ray 全プラットフォーム対応インストール・設定完全ガイド - Windows・macOS・Android・Linux

このページは体系的に調べられる実用マニュアルです。初回接続を済ませ、プラットフォームごとの差異を確認したい方や、設定の仕組みを理解したい方に適しています。サブスクリプションの導入、ノードの選択、プロキシの有効化だけを早く済ませたい場合は、まずクイックスタートの基本手順をお読みください。インストールパッケージを選ぶ場合はクライアントダウンロードページへ進んでください。短い手順を重ねるのではなく、各プラットフォームで見落としやすい権限、プロキシの適用範囲、TUNの動作、DNSの関係、トラブル解決の順序を詳しく説明します。

最初から最後まで順番に読む必要はありません。初回設定では「共通の準備」「接続モードと設定の範囲」「利用中のプラットフォームの章」を順に確認してください。サブスクリプション、分流、DNS、接続で問題が起きたら、後半の章に移って症状から調べられます。重要な設定を変更する前に現在の動作状態を記録し、一度に一項目だけ変更するのがおすすめです。問題がクライアント、サブスクリプションの内容、システムネットワーク、対象サイトのどこにあるか判断しやすくなります。

01 · BEFORE INSTALLATION

共通の準備：インストールパッケージ、サブスクリプション、システム状態

まずプラットフォームとCPUアーキテクチャに合うクライアントを選ぶ

デスクトップではv2rayNを優先して使います。Windows、macOS、Linuxに対応し、サブスクリプショングループ、システムプロキシ、TUN、ルーティング、ログなどの機能を一通り利用できます。Androidではv2rayNGが使えます。V2Flyカーネル系を利用したい場合はv2flyNGを選べます。3つのクライアントは役割が完全に同じではありません。v2rayNはデスクトップ向けで設定項目が集約され、v2rayNGとv2flyNGはタッチ操作に適し、システムのVPNインターフェースを通じて指定した通信を引き受けます。クライアントごとの設定画面を項目単位で比較しないでください。名称、メニュー階層、初期動作が異なる場合があるため、機能の目的を基準に判断します。

ダウンロード前にCPUアーキテクチャを確認します。Windowsの一般的な端末はx64、macOSはApple SiliconとIntelを区別します。Androidの主流端末は通常arm64を選び、アーキテクチャが不明、またはインストールに失敗した場合にユニバーサル版を試します。Linuxはx64とarm64に加え、ディストリビューションに応じてdebまたはrpmを選びます。debは通常Debian、Ubuntuとその派生システム、rpmはFedora、Rocky Linux、AlmaLinuxなどで使われます。アーキテクチャを間違えると、インストーラーが起動しない、パッケージ非対応と表示される、インストール後すぐ終了するといった症状が出ます。この場合、サブスクリプションを何度も変更する必要はありません。

プラットフォーム	推奨クライアント	インストールパッケージの選び方	プロキシの適用方法
Windows	v2rayN	x64デスクトップ版またはクラシックWPF版	システムプロキシまたはTUN
macOS	v2rayN	Apple SiliconまたはIntel DMG	システムプロキシまたはTUN
Linux	v2rayN	x64/arm64とdeb/rpmを組み合わせる	デスクトッププロキシ、環境変数、またはTUN
Android	v2rayNG	arm64を優先、ユニバーサル版も対応	システムVPNインターフェース

サブスクリプション情報がどの層に属するか確認する

クライアントは設定を読み込み、カーネルを呼び出して接続を確立するだけで、利用可能なサーバーを自動生成することはありません。開始前に、正常にアクセスできるサブスクリプションURL、単一の共有リンク、または完全な設定ファイルを用意してください。サブスクリプションURLには通常、サービス提供者が管理する複数の設定が含まれます。単一の共有リンクは1つの設定だけを表し、JSONファイルには完全なインバウンド、アウトバウンド、DNS、ルーティングルールが含まれる場合があります。3種類の情報では導入先もトラブル解決の方法も異なります。サブスクリプションの更新に失敗したらURLとネットワーク到達性を確認し、単一ノードの接続に失敗したらプロトコルパラメーターを確認します。完全な設定を起動できない場合は、JSON構造とログに出るフィールドエラーを確認してください。

サブスクリプションURLは機密情報として管理してください。公開の議論、スクリーンショット、ブラウザーの同期メモに貼り付けないでください。URLにアカウント識別情報が含まれている場合があります。複数の端末で使うときは、信頼できる端末に直接入力し、クライアントのサブスクリプショングループで取得元を分けます。同じクライアントで複数のサブスクリプションを管理する場合、名前は「用途または提供元の名称」のようにし、「サブスクリプション1」「サブスクリプション2」のような追跡しにくい番号は避けましょう。更新失敗、ノードの重複、ルールの違いが起きたとき、分かりやすいグループ名が切り分け時間を大幅に短縮します。

元に戻せる初期状態を作る

インストール前に、システム時刻とタイムゾーンが正しいことを確認します。TLSハンドシェイクは時刻に依存するため、端末の時刻が大きくずれていると、すべてのノードが同時に失敗することがあります。続いて、現在のシステムプロキシ、VPN、DNS設定、実行中のネットワークツールを記録します。初回テストではプロキシクライアントを1つだけ起動し、複数のアプリがシステムプロキシや仮想NICを同時に変更しないようにします。企業ネットワーク、学校ネットワーク、公共Wi-Fiには認証ページが付くことがあるため、まずブラウザーでネットワーク認証を済ませてからクライアントの接続を判断してください。

まずクライアントの初期設定で1回接続してから、TUN、分流、カスタムDNSを追加するのがおすすめです。一度に変数を増やしすぎると、症状から原因を絞れなくなります。初期検証では、クライアントログに起動エラーがないこと、ブラウザーで目的のサイトにアクセスできること、プロキシを無効にするとネットワークが元の状態に戻ることの3点を確認します。特に3つ目は重要です。システムプロキシの解除漏れ、仮想NICの残留、DNSの固定変更を早期に発見できます。

準備ができたら、v2rayN初回接続チュートリアルで速度測定と有効性の確認方法を確認できます。複数の取得元を管理する場合は、サブスクリプショングループ設定の実践も参考にしてください。これらの記事は個別の作業を扱い、この章では各プラットフォームに共通する判断基準を説明します。

02 · TRAFFIC CONTROL

接続モードと設定の範囲：システムプロキシ、TUN、アプリ内プロキシ

システムプロキシはブラウザーやシステム設定に従うアプリに適している

システムプロキシとは、クライアントが待ち受けるローカルHTTPまたはSOCKSポートをOSのプロキシ設定に書き込む仕組みです。ブラウザー、一部のオフィスソフト、多くのシステムネットワークフレームワーク対応アプリは、リクエストをローカルポートへ送り、V2Rayカーネルがルーティングルールに従って直接接続またはプロキシ経由を選びます。動作が分かりやすく、切り替えが速く、必要な権限も比較的少ないため、初回設定では優先すべき方法です。一方、システムプロキシを読み取らないアプリ、一部のコマンドラインツール、ゲーム、独自のネットワークスタックを使うソフトは完全に迂回することがあります。

システムプロキシを有効にすると、クライアントには通常「クリア」「自動設定」「グローバル」「変更しない」などの項目が表示されます。バージョンによって文言は多少異なりますが、判断基準は同じです。自動設定はローカルの待ち受けアドレスをシステムに書き込み、クリアはシステム状態を復元し、変更しないはカーネルだけを動かしてシステムを変更しません。トラブル時はメニューにチェックがあるかだけでなく、OSのネットワーク設定でプロキシアドレスが本機を指しているか、ポートがクライアントの現在のインバウンドポートと一致するかを確認します。ポートが別のアプリに使用されている場合、ログに待ち受け失敗やアドレス使用中の表示が出ることが多いです。

TUNはより広い範囲の通信を扱いたい場合に適している

TUNモードは仮想NICでIP通信を受け取り、カーネルに処理させるため、システムプロキシに従わないアプリも広く対象にできます。通常は管理者権限が必要で、ルーティングテーブル、DNSハイジャック、自動ルーティングにも関係します。TUNは「高機能だから常に良い」というスイッチではありません。ブラウザーだけをプロキシするならシステムプロキシのほうが管理しやすく、コマンドラインやデスクトップアプリ、複数のネットワークスタックを同じルールに通したい場合にTUNを検討します。有効化前に設定を保存し、他の仮想ネットワークツールを停止し、システムファイアウォールがクライアントのインターフェース作成を妨げていないことを確認してください。

TUNを起動した後にインターネットへ接続できなくなっても、必ずしもノードの問題とは限りません。仮想NICの権限不足、デフォルトルート未設定、LANセグメントの誤った取り込み、DNS応答の欠如、スリープ復帰後のインターフェース無効化などがよくある原因です。まずTUNを停止し、同じノードをシステムプロキシで試します。システムプロキシは使えるのにTUNだけ使えない場合、原因は仮想NIC、ルート、DNSに絞られるため、サブスクリプションを繰り返し更新する必要はありません。どちらのモードも失敗する場合は、ノード、カーネルログ、現在のネットワークを確認します。

アプリ内プロキシは正確だが、設定漏れが起きやすい第三の方法

コマンドラインツールや開発ソフトでは、個別にプロキシを指定できることがあります。たとえば一部のプログラムはHTTP_PROXY、HTTPS_PROXY、ALL_PROXY環境変数を読み込み、別のプログラムは自身の設定画面で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

curl -I https://example.com

上記のポートはローカルプロキシ変数の形式を示すための例です。実際の値はクライアントの設定画面に従ってください。テスト後は現在のターミナルでunset HTTP_PROXY HTTPS_PROXY ALL_PROXYを実行できます。ターミナルからは接続できるのにGUIアプリからは接続できない場合、カーネルとノードはおそらく正常で、GUIアプリがシステムプロキシを読み取るかを確認すべきです。逆にブラウザーは使えるのにターミナルが使えない場合は、ターミナルのプログラムがシステム設定を読み取っていない可能性が高いです。

ルーティングモードが接続後の分流方法を決める

システムプロキシまたはTUNは通信をカーネルへ送り、ルーティングルールはどのアウトバウンドから通信を出すかを決めます。この2つは混同されがちです。「グローバルプロキシ」は通常、カーネルに入ったリクエストを優先的にプロキシ経由へ送ることを意味します。ルールモードはドメイン、IP、ポート、プロセスなどの条件で照合し、直接接続モードは一時的な復旧に使います。ルールが上から順に評価される場合、上の広いルールが下の詳細なルールを隠すことがあります。変更後はルールの存在だけでなく順序も確認してください。

LANアドレス、プリンター、ネットワークストレージ、ルーター管理画面は通常、直接接続にします。特にTUNモードではプライベートアドレス帯に注意しないと、ローカルサービスへアクセスできなくなることがあります。代表的なプライベートネットワークは10.0.0.0/8、172.16.0.0/12、192.168.0.0/16です。有効化後にインターネットは使えるのにLANだけ切断された場合は、まずこれらの範囲が直接接続に設定されているかを確認し、その後、社内ネットワークやコンテナネットワークの経路が重複していないかを調べます。

プロキシが有効かどうかは、クライアントのアイコンだけで判断できません。ログ、対象サイトへのアクセス結果、出口ネットワークの変化を同時に確認します。速度測定でも、TCP遅延と実接続テストを区別してください。前者は基本的なハンドシェイク応答を示すだけで、後者のほうが実際の利用状況に近い結果になります。具体的な判断手順はノードの遅延、地域、プロトコルの選び方を参照してください。

03 · WINDOWS

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

デスクトップ版とクラシックWPF版の選び方

Windowsのダウンロードページにはv2rayNデスクトップ版とクラシックWPF版があります。デスクトップ版は新世代のクロスプラットフォームUIを採用し、異なるデスクトップOSでも操作感をそろえたいユーザーに適しています。クラシックWPF版はWindowsデスクトップとの統合がより深く、画面やタスクトレイの操作も従来型です。どちらもサブスクリプション、ノード選択、システムプロキシ、ルーティング、ログ確認に対応しており、同時にインストールする必要はありません。初めて使うならデスクトップ版を優先し、WPFの操作に慣れている場合や既存の設定手順を維持したい場合はクラシック版を選びます。

インストール時は、一般ユーザーが安定して読み書きできる場所を選びます。インストーラーがシステム権限を求めた場合は、取得元を確認してシステムの指示に従ってください。初回起動後は自動起動とTUNをまだ有効にせず、メインウィンドウが正常に表示されるか、ログ欄でカーネルが読み込まれているかを確認します。セキュリティソフトがネットワークアクセスを尋ねたら、現在のネットワーク種別でクライアントがローカル待ち受けと外向き接続を行えるよう許可します。拒否すると、画面は正常でもすべてのテストに失敗することがあります。

サブスクリプショングループと初回更新

サブスクリプショングループの設定を開き、新しいグループを作成してURLを入力します。グループ名は取得元を区別するためのもので、遠隔の内容には影響しません。保存後、「現在のサブスクリプションを更新」または同等の操作を実行し、サーバー一覧が更新されるまで待ちます。一覧が空の場合は、まず更新ログを確認します。URLへのアクセス失敗ならURLと現在のネットワークを確認し、解析失敗ならコピー時に改行、空白、文字の欠落がないか確認します。更新成功後も一覧が非表示なら、サーバーフィルターと現在のグループタグを確認してください。

複数のサブスクリプションを1つのグループに詰め込まないでください。グループを分けると個別に更新、無効化、フィルタリングでき、同名ノードも追跡しやすくなります。更新間隔を短くしすぎても、起動時に何度も取得してノード品質が上がるわけではありません。サービス提供者が推奨する周期で更新し、大規模な障害や設定変更があったときだけ手動更新するほうが安定します。更新前後でサーバー名が変わるのはサブスクリプション内容の変化であり、ローカル設定の破損を意味しません。

設定の選択、実接続テスト、システムプロキシ

サブスクリプション更新後、設定を1つ選んでアクティブサーバーにします。名前だけで判断せず、まず実接続テストまたは実際のアクセスを行ってください。TCP遅延がタイムアウトする設定は通常使えませんが、遅延が低くてもアプリケーション層で成功するとは限りません。TLS、認証、トランスポートパラメーター、遠隔側の状態によって接続に失敗することがあります。初回テストでは一般的な回線を選び、複雑なカスタムルーティングやDNSを同時に有効にせず、動作する基準状態を作ります。

アクティブ設定を確認したら、システムプロキシを有効にします。Windowsのシステム設定にあるプロキシサーバーは、127.0.0.1とクライアントに対応するポートを指定します。ブラウザーに古い状態が残る場合は完全終了して再起動するか、独立したプロキシ拡張機能を使っていないか確認してください。v2rayNを終了する前にシステムプロキシをクリアするのがおすすめです。異常終了した場合は、Windowsの「ネットワークとインターネット」のプロキシ設定を開き、残った手動プロキシを無効にしてからクライアントを再起動します。

TUN、権限、スリープ復帰

システムプロキシに従わないソフトもルール処理へ通したい場合は、通常のプロキシが使えることを確認してからTUNを有効にします。初回の仮想NIC作成には通常、管理者権限が必要です。起動に失敗したら、まずクライアントを通常の方法で終了し、1度だけシステム権限で起動してコンポーネントを初期化します。常用時に毎回管理者権限が必要かどうかは、インストール方法とシステムポリシーによって異なります。別の仮想ネットワークソフトのTUNモードを同時に動かさないでください。デフォルトルートやDNSを奪い合う可能性があります。

Windowsでスリープから復帰した後、Wi-Fiを切り替えた後、有線から無線へ移行した後は、仮想インターフェースに古いルートが残ることがあります。クライアントは動作中と表示されているのに、新しい接続を確立できないのが典型的な症状です。システムプロキシまたはTUNを停止し、数秒待ってから再び有効にします。それでも直らなければカーネルを再起動し、最後にクライアントを再起動します。システムのネットワークアダプターを直接削除するのは第一選択ではありません。多くの場合、ルートが更新されていないだけです。

v2rayNのメイン画面にあるサーバー一覧、サブスクリプショングループ、ログ、設定エリアの機能は、v2rayNメイン画面の機能詳解と合わせて確認できます。インストールパッケージと現在利用できる入口はWindowsダウンロードにまとめています。メイン画面のスクリーンショットに見えるバージョンの外観だけでパッケージ形式を推測しないでください。

04 · MACOS

macOS：チップの選択、権限の許可、プロキシの復元

チップの種類を確認してインストールする

macOS版v2rayNにはApple Silicon用とIntel用の2種類のDMGがあります。システムの「このMacについて」でチップ情報を確認し、Appleチップの名称が表示される場合はarm64対応パッケージ、Intelプロセッサと表示される場合はx64パッケージを選びます。パッケージを間違えるとアプリが開かない、または互換変換レイヤー経由で動作して別の問題が生じることがあります。アプリを「アプリケーション」フォルダーへ移してから起動してください。マウント中のディスクイメージから長期間実行すると、パスの変化が権限、自動起動、更新に影響するためおすすめしません。

初回起動時、ダウンロードしたアプリ、ネットワークアクセス、補助ネットワーク設定の追加についてシステムが確認を求めることがあります。明確な表示が出た場合は、システム設定の「プライバシーとセキュリティ」で対応し、アプリのアイコンを何度もクリックしないでください。システムがアプリを検証中なら、検証が終わるまで起動失敗と判断しないでください。インストール後にウィンドウが見つからない場合は、メニューバーとDockを確認します。デスクトップクライアントはメインウィンドウを閉じてもバックグラウンドで動作することがあり、完全終了にはメニューの終了コマンドを使います。

サブスクリプションを導入してローカル待ち受けを確認する

サブスクリプションの手順はWindowsとほぼ同じです。グループを作成し、URLを入力して保存・更新した後、アクティブ設定を選びます。URLをコピーするときは、クリップボードに前後の空白が混入していないか注意してください。更新でサーバー一覧が生成されない場合は、まずログでHTTPステータスと解析情報を確認します。ブラウザーで一般的なページを開けても、サブスクリプションURLへアクセスできるとは限りません。URLには独自のアクセス制限がある場合があります。逆に、サブスクリプション更新の成功は設定をダウンロードできたことを示すだけで、含まれるすべてのノードが接続できることを意味しません。

設定を選んだら、まずカーネルを起動し、ローカルHTTPとSOCKSの待ち受けが作成されたか確認します。システムプロキシにはクライアントに表示される現在のアドレスとポートを入力します。通常、アドレスはループバックアドレスです。LANアドレスを不用意にシステムプロキシへ設定したり、「LAN接続を許可」を初期設定として有効にしたりしないでください。この項目はローカル待ち受けの範囲を広げます。同じネットワーク上の他の端末に現在のプロキシを使わせる明確な必要があり、ネットワーク境界を理解している場合にだけ設定します。

システムプロキシとサービス別設定

macOSのプロキシ設定はネットワークサービスごとに保存され、Wi-Fiと有線ネットワークで異なる設定を持てます。v2rayNがシステムプロキシを変更した後にネットワークサービスを切り替えると、新しいサービスには設定が反映されないことがあります。逆に、システム設定で手動変更したプロキシがクライアントのメニュー状態と一致しないこともあります。ブラウザーがプロキシを通らない場合は、まず現在使っているネットワークサービスを確認し、WebプロキシとセキュアWebプロキシのサーバーおよびポートが本機を指しているか調べます。

クライアント終了後にネットワークへまったくアクセスできない場合、システムプロキシが残っているのにローカル待ち受けが停止していることが多いです。現在のネットワークサービスのプロキシ詳細を開き、該当するプロキシ項目を無効にして保存し、直接接続を再テストします。クライアントがまだ動作しているなら、「システムプロキシをクリア」機能を先に使えます。ルーターを何度も再起動しても、本機に残ったプロキシアドレスは変わりません。

TUN、ネットワーク拡張、DNS

macOSのTUNモードでは、仮想ネットワークインターフェースを作成するためにシステムの許可が必要になることがあります。初回有効化時はシステムダイアログと「プライバシーとセキュリティ」ページを確認し、許可後にモードを再起動します。ボタンを有効にしてもすぐ戻る場合は、ログに権限、インターフェース作成、ルート書き込みのエラーがないか確認します。TUNは起動するのにドメインへアクセスできず、既知のIPには応答がある場合は、まずDNSを確認します。ドメインもIPも到達できない場合は、デフォルトルートと現在のノードを確認してください。

自宅Wi-Fiから会社のネットワーク、テザリング、有線インターフェースへ切り替えると、システムがDNSとデフォルトルートを変更することがあります。TUNモードはネットワーク切り替え後に再構築し、古いインターフェースを使い続けないようにします。LANサービスへアクセスできない場合は、プライベートアドレスが直接接続になっているかを確認し、「簡易ホスト名をバイパス」などのシステム項目が誤って上書きされていないか調べます。開発環境のローカルドメインでは、hosts、LAN DNS、コンテナネットワークへの依存がリモートDNSルールに置き換えられていないかも確認してください。

scutil --proxy
networksetup -listallnetworkservices
route -n get default

上記のコマンドは、現在のシステムプロキシ、ネットワークサービス一覧、デフォルトルートを確認するためのもので、設定は変更しません。結果でプロキシが有効になっている場合は、サーバーアドレスとポートを確認します。デフォルトルートは、現在実際に使っているネットワークインターフェースを指すか、TUNが正しく引き受けている必要があります。調査後は、コマンドラインとクライアントの状態が分離しないよう、切り替えはGUIに戻って行うのがおすすめです。

現在のチップに対応するインストール入口はmacOSダウンロードにあります。同じノードがシステムプロキシでは使えるのにTUNでは使えない場合、サブスクリプションとノードは変えず、権限、DNS、ルートを重点的に確認してください。再インストールより診断に役立ちます。

05 · LINUX

Linux：パッケージインストール、デスクトッププロキシ、サービスの範囲

debとrpmを正しく選ぶ

Linux版v2rayNは、ディストリビューションのパッケージ形式とCPUアーキテクチャを一致させる必要があります。Debian、Ubuntu、Linux Mintなどは通常deb、Fedora、Rocky Linux、AlmaLinuxなどは通常rpmを使います。x64は一般的なIntelおよびAMDのデスクトッププロセッサ向け、arm64は対応するARM端末向けです。uname -mでアーキテクチャを確認できます。一般的なx86_64はx64、aarch64はarm64に対応します。パッケージ形式またはアーキテクチャのどちらかが合わないだけでも、インストール時にパッケージマネージャーから拒否されることがあります。

uname -m

sudo apt install ./v2rayN*.deb
sudo dnf install ./v2rayN*.rpm

ダウンロードファイルのあるディレクトリで、ディストリビューションに合うインストールコマンドを1つ実行します。パッケージマネージャーでインストールすると、直接解凍するよりデスクトップエントリーや依存関係を扱いやすくなります。依存関係を満たせないと表示されたら、まず現在のディストリビューションのパッケージインデックスを更新し、システムバージョンがまだサポートされているか確認します。別のディストリビューションの基礎ライブラリを不用意に混在させないでください。インストールは成功したのにメニューから起動できない場合は、ターミナルから一度起動して標準出力を確認します。GUI依存関係、表示サービス、権限に関する具体的な情報が表示されることがあります。

デスクトップ環境によってシステムプロキシの自動設定可否が決まる

Linuxには統一されたデスクトッププロキシインターフェースがありません。GNOME、KDE Plasmaなどのデスクトップ環境ではプロキシの保存方法が異なり、v2rayNの自動設定機能もデスクトップセッションによって変わることがあります。クライアントに「システムプロキシが有効」と表示されても、デスクトップのネットワーク設定でHTTP、HTTPS、SOCKS項目を確認してください。デスクトッププロキシに従うアプリ、環境変数だけを読むアプリ、独自設定だけを使うアプリがあります。Linuxでは「カーネルが正常に動作していること」と「アプリが通信をカーネルへ渡していること」を特に分けて考える必要があります。

ブラウザーではアクセスできるのにターミナルのコマンドが使えない場合、ノードが突然停止したのではなく、ターミナルがデスクトッププロキシを読み取っていない可能性が高いです。現在のターミナルでプロキシ変数を一時的にエクスポートしてテストできます。ポートはクライアントの実際の値を使ってください。テストが成功したら、shell設定へ書き込むか判断します。環境変数を長期的に設定すると、パッケージマネージャー、コンテナツール、LANアクセスに影響するため、影響範囲を理解しないまま全体設定するのはおすすめしません。クライアント終了後は、停止したローカルポートへ接続し続けないよう変数も解除します。

サブスクリプションの保存先、権限、設定の永続化

サブスクリプションの導入は引き続きv2rayNのGUIで行います。一度管理者権限で起動した後、通常ユーザーで設定を保存できなくなった場合は、設定ディレクトリの所有者が変わった可能性があります。GUIクライアントは通常、現在のデスクトップユーザーで実行し、TUN作成や特定のシステム操作のときだけ権限を昇格します。常に管理者アカウントで実行すると、ダウンロードファイル、ログ、設定の所有者が混乱し、アプリのアクセス範囲も広がります。保存に失敗したら、サブスクリプションを何度も削除するのではなく、ユーザー設定ディレクトリの権限を確認してください。

デスクトップセッションの終了、システム更新、アプリの異常終了後に、システムプロキシが残ることがあります。復元方法はデスクトップ環境によって異なります。まずネットワーク設定で「プロキシなし」または「自動」に戻し、ターミナルの環境変数も解除されていることを確認します。アプリが独自プロキシを使う場合は、アプリの設定からローカルアドレスも削除します。調査時はv2rayNを終了して通常のネットワークリクエストを実行します。それでも127.0.0.1へ接続しようとするなら、どこかにプロキシ設定が残っています。

TUN、ルーティングテーブル、コンテナネットワークの競合

LinuxのTUNは、カーネルデバイス、ネットワーク管理方式、権限に依存します。有効化に失敗したら、まず/dev/net/tunが存在することを確認し、ログに権限不足がないか確認します。TUNは起動するのに一部のアドレスへ到達できない場合は、ip routeとip ruleを調べます。Docker、Podman、仮想マシン、企業VPNは追加のネットワーク帯を作ることがあります。ローカルLANやプロキシルールと重複すると、通信が誤ったインターフェースへ流れます。ルートが複数あるからといってすべて削除せず、各ルートがどのソフトに属するかを確認してください。

ip route
ip rule
cat /etc/resolv.conf
ss -lntp

ip routeとip ruleはルーティング判断の確認に使い、/etc/resolv.confは現在の名前解決入口を表示します。ss -lntpではローカルの待ち受けポートを確認できます。クライアントがカーネル起動済みと表示しているのに対応するポートが存在しない場合は、まず起動ログを確認します。ポートが存在するのにアプリから接続を拒否される場合は、アドレス種別、プロトコル種別、ファイアウォールを調べます。HTTPリクエストをSOCKSポートへ送ったり、HTTP専用アプリにSOCKS設定を入力したりしても、ローカル接続失敗として現れます。

インストールパッケージの入口とarm64対応項目はLinuxダウンロードにあります。長期的に安定運用したいデスクトップ環境では、まず通常ユーザーのセッションでGUIクライアントを正常に動かし、その後に自動起動、TUN、カスタムルートを段階的に追加してください。

06 · ANDROID

Android：v2rayNG・v2flyNGの導入とシステムVPNによる通信制御

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

Androidではv2rayNGを優先します。Xrayカーネル系を採用しています。V2Flyカーネルを使いたい場合はv2flyNGを選べます。どちらもサブスクリプション、設定一覧、ルーティング、システムVPNによる通信制御に対応しますが、メニュー名や一部のプロトコル対応は異なる場合があります。2つのクライアントで同時に接続を開始しないでください。システム上、この種のVPNセッションを同時に1つしかアクティブにできないためです。切り替える前に現在のクライアントを切断し、その後もう一方で起動します。

新しい主流端末の多くはarm64パッケージを選べば問題ありません。アーキテクチャが不明、arm64パッケージをインストールできない、端末の互換性に特殊な事情がある場合にユニバーサル版を試します。インストール前に、現在使っているファイルマネージャーまたはブラウザーから今回のインストールを実行できるようシステムで許可し、終了後はその提供元のインストール許可を無効にできます。「アプリをインストールできません」と表示されたら、署名の異なる同名アプリがすでに存在しないか、空き容量が十分か、パッケージのアーキテクチャが合っているかを確認します。ネットワーク設定をすべて削除する必要はありません。

スキャン、クリップボード、サブスクリプション導入

単一の設定は、QRコードのスキャン、クリップボードからの共有リンク導入、手入力のいずれかで追加できます。QRコードの導入にはカメラ権限が必要です。クリップボードから導入する前に、完全なリンクをコピーしたことを確認してください。手入力は少数のパラメーターを照合したい場合に適しています。サブスクリプションはサブスクリプショングループまたはサブスクリプション設定を開き、URLを追加して更新します。サブスクリプションURLを単一ノードのリンクとして導入すると、通常は期待した一覧になりません。単一の共有リンクをサブスクリプションURL欄に入力しても、エラーになることがあります。

更新後に設定一覧が空の場合は、現在のグループ、検索フィルター、更新ログを確認します。一覧はあるのに接続できない場合は、設定を1つアクティブ項目にして実接続テストを行います。モバイル通信とWi-Fiでは経路が異なるため、同じ設定でも結果が変わることがあります。判断時は現在のネットワーク種別を記録してください。Wi-Fiで更新してモバイル通信へ切り替えてテストした結果だけで、ノードが無効だと結論づけないようにします。

接続の許可、アプリ別プロキシ、バックグラウンド制限

初めて接続ボタンを押すと、システムにVPN接続の許可が表示されます。許可後、ステータスバーに対応するシステム表示が出ることが多いです。接続を押しても反応がない場合は、別のVPNセッション、仕事用プロファイルのポリシー、システムのネットワーク機能がインターフェースを使用していないか確認します。クライアントは接続済みなのにすべてのアプリへアクセスできない場合は、いったん切断して既知の利用可能な設定に切り替えます。特定のアプリだけ通信できない場合は、アプリ別プロキシの設定を確認してください。

アプリ別プロキシでは、クライアントの処理を通すアプリや、バイパスするアプリを指定できます。ルールの向きを必ず確認してください。「選択したアプリのみプロキシ」と「選択したアプリはプロキシを通さない」は正反対の結果になります。初回設定ではアプリ別の制限を無効にし、全体の接続が正常になってから1つずつ追加するのがおすすめです。有効化後に新しくインストールしたアプリだけ接続できない場合は、既存の一覧に含まれていない可能性があるため、選択範囲を確認し直します。

システムによってはバックグラウンドアプリ、スリープ中の通信、自動的なプロセス終了が制限され、画面ロック後しばらくして接続が切れることがあります。システムのバッテリー設定でクライアントに必要なバックグラウンド動作を許可し、そのアプリへの過度なスリープ制限を解除します。すべての省電力機能を無効にする必要はなく、現在のクライアントだけ調整してください。接続が頻繁に再構築される場合は、Wi-Fiとモバイル通信の自動切り替えが原因かもしれないため、まず一方のネットワークに固定してテストします。

ルーティング、リモートDNS、LANアクセス

Androidクライアントは通常、システムVPNインターフェースで通信を引き受け、ルーティングモードがドメインとIPの出口方向を決めます。ルールモードではLANアドレスを直接接続にしてください。そうしないと、キャスト、プリンター、ネットワークストレージ、ルーター管理画面へアクセスできないことがあります。インターネットは使えるのにLAN機器が見えなくなった場合は、まずLANバイパス設定とプライベートアドレスルールを確認し、ノードのプロトコルパラメーターは変更しないでください。

DNS設定はルーティング先と一致させる必要があります。遠隔ドメインをプロキシ経由で開く場合、リモートDNSを使うとローカルで得た結果とプロキシ出口の不一致を減らせます。一方、ローカルドメイン、ルーターのドメイン、LANサービスはローカルDNSに依存することがあります。設定を1種類に固定しすぎると、一方のドメインは正常でも別のドメインが失敗する場合があります。初回はクライアントの初期DNSを使い、安定して再現する名前解決の問題があるときだけ変更し、変更するたびに切断と再接続を行います。

2つのAndroidクライアントのarm64版とユニバーサル版の入口はAndroidダウンロードにあります。Xray、V2Fly、GUIクライアントの関係を理解したい場合は、Project V、V2Fly、Xrayのエコシステム整理を参照してください。クライアント名、カーネル名、プロトコル名を同じ階層のものとして混同しないために役立ちます。

07 · CONFIGURATION

サブスクリプション、ルーティング、DNS：全プラットフォーム共通の設定の核

サブスクリプション更新とノードパラメーターは別の経路

サブスクリプションの更新では、URLへリクエストを送り、返却内容を読み込み、設定を解析してローカルグループへ書き込みます。一方、ノード接続では、1つの設定を読み込み、カーネルを起動し、サーバーのドメインを解決し、トランスポートを確立してプロトコルのハンドシェイクを完了します。更新成功は最初の経路が完了したことを示すだけで、すべてのノードが使えることは証明しません。ノード接続の成功も、後でサブスクリプションを更新できることを意味しません。トラブル時はどちらの経路で失敗したかを先に確定してください。そうしないと、サブスクリプションURLの問題を「ノード変更」で処理したり、単一ノードのパラメーター問題を「サブスクリプション再導入」で処理したりします。

サブスクリプションを更新する前に、現在使える設定を記録しておきます。更新後に項目が大きく変わったら、まずグループが正しいか確認します。複数のサブスクリプションで同名ノードができた場合、表示名だけで取得元を判断しないでください。グループで絞ってから速度測定を行うか、キーワードで不要な地域や倍率表示を除外できます。フィルターが広すぎると正常なノードを隠し、狭すぎると管理しにくくなります。複数の取得元を整理する詳しい手順は複数サブスクリプションのグループ化とサーバーフィルターを参照してください。

ルーティングルールは照合範囲と順序で動作する

よく使われるルーティング条件には、ドメイン、IPアドレス、ポート、プロトコル、プロセスがあります。ドメインルールは特定のサイトに、IPルールはLANや固定ネットワーク帯に適しています。プロセスルールはデスクトップアプリの分流に便利ですが、プラットフォームによって対応状況が異なります。ルールは通常、上から下へ照合され、該当するとプロキシ、直接接続、ブロックのいずれかへ送られます。そのため、詳細なルールは広いルールより前に置きます。たとえばLANとローカルドメインを先に直接接続し、次に特定ドメインを処理し、最後に未一致の通信をデフォルトの出口へ送ります。

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

例ではルーティング構造の基本的な関係を示しています。プライベートアドレスは直接接続し、指定したドメインはプロキシへ送ります。実際の完全な設定には、directとproxyのタグに対応するアウトバウンド定義も必要です。GUIクライアントのルーティング画面では通常、JSONを手書きせずに設定できますが、タグの関係を理解することは重要です。存在しないアウトバウンドタグをルールが参照すると、カーネルが起動を拒否することがあります。ドメインルールの書式が現在のカーネル形式に合わない場合は、ルールが一致しません。

DNSがドメインをルーティング判定へ送る方法を決める

ドメインへアクセスするとき、クライアントはドメインルールで先に照合することもあれば、IPへ解決してから続けて判定することもあります。domainStrategyはドメインを解決するタイミングを制御しますが、カーネルやクライアントによって選択肢が多少異なる場合があります。AsIsはドメインを保持してルール照合する傾向があり、IPIfNonMatchはドメインルールに一致しない場合にIPを解決します。より積極的な解決方式ではDNSの関与が増えます。選択時は汎用的な高速化設定と考えるのではなく、ルール上の要件を基準にしてください。

DNSの問題は、ドメインを開けない、初回アクセスに時間がかかる、同じサイトの結果がネットワークごとに異なる、TUNモードですべてのドメインに失敗するといった形で現れます。まずドメインとIPの到達性を比較し、その後クライアントのDNSログを確認します。システムDNS、クライアントDNS、ブラウザーのセキュアDNS、ルーティングポリシーを同時に変更しないでください。一度に1つの層だけ変更すると、どこが有効だったか判断できます。ブラウザーが独自のDNS設定を持つ場合もあるため、他のアプリとブラウザーの結果が異なるときは、システムやクライアントの名前解決を迂回していないか確認します。

{
  "dns": {
    "servers": [
      "https+local://1.1.1.1/dns-query",
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

DNSの設定機能はカーネルのバージョンとクライアントの実装によって変わります。上の例はサーバー一覧と問い合わせ方式の階層を示すもので、クライアントが対応する方式を確認せずに完全な設定を直接上書きすることはおすすめしません。GUIクライアントにDNSプリセットがある場合は、現在のカーネルに合うプリセットを優先し、ログを見ながら微調整します。カスタム設定の前に元の値を保存しておけば、名前解決に異常が出てもすぐ戻せます。

速度測定の結果は実接続と合わせて判断する

ノード一覧の遅延は、TCPプローブ、接続テスト、対象URLへのテストなどから得られる場合があり、方法が違う結果を単純に横比較することはできません。TCP遅延が低いことは基本接続が速いことを示しますが、完全なアプリケーションリクエストは含みません。実接続テストは実利用に近い一方、テスト先、DNS、現在のネットワークの影響も受けます。ノードを選ぶときは、接続成功率、実際のアクセス、地域の要件、通信倍率を総合的に見て、一覧で最も小さい数値だけを選ばないでください。

一括速度測定では複数の接続を同時に確立するため、ネットワークが弱い場合やノード数が多い場合、一時的なタイムアウトが起こることがあります。サブスクリプショングループごとに分けて測定し、候補ノードを実際のアクセスで検証します。ノードの状態が時間帯によって変わるのは通常のネットワーク現象です。頻繁に切り替えると、かえって問題を再現しにくくなります。すべてのノードが同時に失敗した場合は、ノードを1つずつ編集する前に、本機のネットワーク、システム時刻、サブスクリプション状態、カーネル起動を確認してください。

08 · TROUBLESHOOTING

よくある設定トラブル：症状から解決経路を組み立てる

クライアントが起動しない、または起動直後に終了する

まずインストール層の問題か設定層の問題かを判断します。インストーラーが動かない、パッケージ非対応と表示される場合は、プラットフォーム、アーキテクチャ、パッケージ形式の選択ミスが主な原因です。ウィンドウが一瞬表示されて終了する場合は、実行時依存関係、権限、設定解析、カーネル読み込みの失敗が考えられます。デスクトップではターミナルから起動して出力を確認し、Windowsではクライアントのログディレクトリも確認します。macOSではシステムの通知、Linuxでは標準出力とデスクトップセッション情報を確認してください。エラーを記録せずに再インストールを繰り返すと、現場を上書きするだけで、アーキテクチャや権限の問題は解決しないことがあります。

設定を削除すると起動できる場合、カスタムルーティング、DNS、完全なJSONが原因かもしれません。すべてを再導入するのではなく、直近の変更から戻します。初期設定でも起動できない場合は、システム時刻、ディスク容量、ユーザーディレクトリへの書き込み権限、セキュリティソフトによるブロックを確認します。読み取り専用の場所へのインストール、管理者所有の設定ディレクトリ、実行を阻止されたカーネルファイルでも、似た症状が出ます。

サブスクリプション更新に失敗する、更新後に一覧が空になる

サブスクリプションの失敗では、まずリクエストが送信されたかを確認します。URL形式の誤り、コピー漏れ、ネットワークからのアクセス不能、サーバー側の異常は、リクエスト段階で失敗します。リクエストは成功したのに解析に失敗する場合は、返却内容がクライアント対応のサブスクリプション形式かを重点的に確認します。解析も成功したのに一覧が空なら、現在のグループ、検索フィルター、非表示条件を誤って有効にしていないか調べます。複数のグループがある場合は、別の取得元ではなく現在のグループを更新しているか確認してください。

サブスクリプションURLをブラウザーで開けても、クライアントにコピーしたものと完全に同じとは限りません。ブラウザーはURLを自動補完したりログイン状態を保持したりしますが、クライアントは入力された元のURLでリクエストします。再コピーするときは、提供元のページにあるコピー機能を使い、チャットアプリによるリンクの切り詰めを避けてください。更新頻度が高すぎるとサーバー側の制限に触れる場合があるため、連続クリックより適切な時間を置いて再試行するほうが有効です。

ノードは利用可能と表示されるのにブラウザーでページを開けない

まずアクティブノードが本当に選択されているか確認し、次にシステムプロキシが設定されているか確認します。クライアントのテストは、指定先へカーネルが接続できることだけを検証します。ブラウザーでは通信をローカルポートへ送る必要があります。システムプロキシ設定でループバックアドレスとポートを確認し、その後ブラウザーを完全に再起動します。独立したプロキシ拡張機能がある場合は一時的に無効にし、システム設定が上書きされないようにします。特定のサイトだけ失敗する場合は、ルーティングルール、DNS、対象サイトの状態を確認し、プロキシ全体が使えないと直接判断しないでください。

すべてのブラウザーで失敗するのに、コマンドラインがアプリ内プロキシで使える場合、問題はシステムプロキシまたはブラウザー設定に集中しています。ブラウザーは使えるのに他のアプリが使えない場合は、他のアプリがシステムプロキシに従っていないため、アプリ内プロキシまたはTUNを検討します。アプリの種類を比較すると、通信がどの層でクライアントへ入っていないかを素早く判断できます。

TUNを有効にした後、完全にネットワークへ接続できない

すぐにTUNを停止し、通常のネットワークが復旧するか確認します。停止後もアクセスできない場合は、システムプロキシが残っていないかを確認し、DNSとデフォルトルートも調べます。通常のネットワークが戻ったら、同じノードでシステムプロキシを使ってテストします。システムプロキシが使えるならノードとカーネルは基本的に正常で、次はTUNの権限、仮想インターフェース、自動ルーティング、DNSだけを調べます。システムプロキシも使えない場合は、まずノードまたはカーネルを処理し、仮想NICの調整を続けないでください。

TUNの問題は、複数のVPN、コンテナネットワーク、仮想マシン、企業ネットワーククライアントを同時に動かしているときに起こりやすくなります。競合の可能性があるネットワークツールを1つずつ停止し、ルートの変化を観察します。LANに到達できないのにインターネットは使える場合は、プライベートネットワーク帯を直接接続にします。ドメインだけ失敗してIPは到達できる場合はDNSを確認します。すべての通信に出口がない場合は、デフォルトルートとインターフェース権限を調べます。「ネットワークをすべてリセット」するより、症状ごとに分けたほうが有効な設定を残しやすくなります。

しばらくすると接続が自動的に切れる

モバイル端末ではまずバックグラウンド制限とネットワークの自動切り替えを確認し、デスクトップではスリープ復帰とネットワークインターフェースの変化を確認します。毎回決まった時間に切断される場合は、クライアントの定期更新、カーネル再起動、システムの省電力ポリシーを調べます。Wi-Fiの電波状態が変わったときだけ起きるなら、ネットワーク切り替えで接続が無効になった可能性があり、切断と再接続で戻ることがあります。ログに遠隔側からの切断や連続したハンドシェイク失敗がある場合は、ノードを比較して変更します。

1回の切断だけでノードの安定性を判断しないでください。発生時刻、ネットワーク種別、現在のモード、ログの重要行を記録し、2〜3回繰り返して傾向を見ます。すべてのノードが同時に切断されるなら本機のネットワークまたはクライアント状態の可能性が高く、特定のノードだけ繰り返し失敗するならノード側の問題に近いと考えられます。候補ノードの実接続テスト方法は初回接続とプロキシ有効性の確認を参照してください。

クライアント終了後もネットワークに異常がある

最も多い原因は、システムプロキシまたは環境変数がローカルポートを指し続けていることです。WindowsとmacOSでは現在のネットワークのプロキシ設定を開き、手動プロキシを無効にします。Linuxではデスクトッププロキシに加え、ターミナルのHTTP_PROXY、HTTPS_PROXY、ALL_PROXYも確認します。AndroidではシステムVPNセッションが切断されていることを確認してください。TUNを使っていた場合は、仮想インターフェースとルートの削除が完了するまで待ってからネットワークへ再接続します。

ブラウザーにまだ異常がある場合は、完全終了して再起動し、必要に応じて独自プロキシとDNS設定を確認します。特定のアプリだけ復旧しない場合は、そのアプリのネットワーク設定からローカルプロキシを削除します。ブラウザーのデータ削除を最初に行う必要はありません。プロキシの残留とWebキャッシュは別の層の問題です。まずシステムを直接接続へ戻し、その後クライアント設定を層ごとに復元すると、単純な問題を広げずに済みます。

サブスクリプション更新、ノード変更、再インストールの判断基準

サブスクリプションリクエストに失敗する、またはサーバー一覧が長期間更新されない場合は、サブスクリプションを確認します。特定の設定だけハンドシェイクに失敗し、他の設定が正常なら、ノードを変更するか遠隔側の復旧を待ちます。すべてのノードが失敗するのにカーネルが正常なら、ネットワーク、時刻、システムプロキシ、DNSを確認します。アプリが起動しない、依存関係が壊れている、インストールパッケージのアーキテクチャが間違っている場合に、初めてインストール層を処理します。多くの接続問題は設定やシステムネットワーク層で起きるため、再インストールはトラブル解決の後半に置きます。

複雑な障害では、最小構成を作ります。サブスクリプショングループを1つ、既知の利用可能な設定を1つ、初期ルーティング、初期DNSだけ残し、システムプロキシでテストします。最小構成が成功したら、カスタム設定を1項目ずつ戻します。どの段階で再び問題が起きたかが、その層の原因であることが多いです。最小構成でも失敗する場合は、クライアントログ、システムのプラットフォーム、ネットワーク種別、再現手順を収集します。「接続を押した後にログへ何が出るか」「システムプロキシが設定されるか」「システムプロキシとTUNの比較結果」を説明すると、単に「使えない」と書くより切り分けに役立ちます。

トラブル解決後は、確認済みのクライアント種別、サブスクリプショングループ名、よく使う接続モード、カスタムルールを記録しておくと便利です。再インストールが必要な場合は、まずクライアントダウンロードページでプラットフォームの入口を確認してください。基本手順をやり直すだけなら、クイックスタートチュートリアルへ戻ります。このマニュアルは境界や異常の確認に、クイックスタートは最短の動作経路を復元するのに適しています。