v2rayN 初心者向け10の質問：サブスクリプションの追加、システムプロキシ、接続できないときの解決策

1. v2rayNとは？ダウンロード後に必要なものは？

v2rayNはクライアントであり、ノードを提供するサービスではありません。サーバー設定の管理、プロキシコアの起動、システムプロキシやルーティングの設定を行います。クライアントをダウンロードしただけでは、利用可能なサーバーは手に入りません。有効なサブスクリプション、またはサーバーアドレス、ポート、認証情報、通信パラメーターを含むノード共有リンクが必要です。

デスクトップではv2rayNを使用します。Android向けには、Xrayコアを採用したv2rayNGと、V2Flyコアを採用したv2flyNGがあります。各プロトコルを利用できるかどうかは、対応するコアとバージョンによって異なります。サブスクリプションをインポートできるからといって、すべてのノードが互換性を持つわけではありません。特にVLESS + REALITYでは、クライアントのコアが明確に対応していることを確認してください。

• Windows：「設定」→「システム」→「システム情報」でシステムの種類を確認し、プロセッサーのアーキテクチャに合ったインストーラーを選びます。
• Linux：uname -mを実行します。x86_64は通常x64、aarch64は通常ARM64に対応します。ディストリビューションに合ったパッケージ形式を選んでください。
• macOS：「このMacについて」でチップ情報を確認し、AppleシリコンかIntelプロセッサーかを判別します。
• 初回起動：圧縮ファイルはすべて展開してからメインプログラムを実行してください。インストールが必要なパッケージは、システムの案内に従ってインストールします。実行ファイルだけを圧縮ファイルから取り出して起動しないでください。

2. サブスクリプションや共有リンクをインポートするには？

サブスクリプションアドレスは通常、複数のノードを取得するために使います。vmess://やvless://で始まる文字列は、通常、単一ノードの共有リンクです。インポート方法はそれぞれ異なります。サブスクリプションアドレスはサブスクリプショングループに登録し、単一ノードのリンクはクリップボードからインポートします。リンクが長いかどうかだけで種類を判断しないでください。

1. サブスクリプションをコピー

   サービス提供元からサブスクリプションアドレス全体をコピーし、前後に引用符、空白、改行がないことを確認します。アドレス内のトークンはアクセス認証情報です。公開チャットに貼り付けないでください。

2. グループを追加

   「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、追加ボタンをクリックしてメモとアドレスを入力し、保存します。識別しやすいよう、「普段使い」などのメモを付けられます。

3. ノードを更新

   「サブスクリプショングループ」メニューから「すべてのサブスクリプションを更新（プロキシを経由しない）」を選びます。初回設定で利用可能なプロキシがない場合は、まず直接取得を試してください。

4. 一覧を確認

   対象のグループに切り替え、サーバーの項目が表示されることを確認します。グループ名だけが表示されてノードがない場合、設定は保存されていますが、サブスクリプションの取得または解析に失敗しています。

単一ノードの共有リンクを入手した場合は、内容全体をコピーし、メイン画面の「サーバー」→「クリップボードから一括URLをインポート」を選びます。画面に表示されるCtrl + Vも使えます。インポート後はノードを選択してアクティブサーバーに設定し、アプリのプロキシ接続先も設定してください。

3. サブスクリプションの更新に失敗したら、何度も再試行すべき？

エラーを確認してから、プロキシ経由で取得するか判断してください。「プロキシを経由しない」は、クライアントがサブスクリプションアドレスへ直接アクセスする設定です。「プロキシを経由する」には、すでに利用可能なノードが必要です。初回インポート時に利用可能なノードがなければ、プロキシ経由を何度も選んでも依存関係の循環が起きるだけです。

サブスクリプションリンクはアクセスキーに相当します。エラーコード、発生時刻、クライアントログを記録して調査できますが、スクリーンショットでは完全なURL、ユーザー識別情報、認証フィールドを隠してください。テストのために、出所不明のオンライン変換ページへサブスクリプションを渡さないでください。

4. ノードを多数インポートした後、現在のノードを選択・確認するには？

サーバー一覧からノードを選択し、右クリックして「アクティブサーバーに設定」を選びます。現在のアクティブ表示と起動ログで切り替えを確認してください。行をハイライトしただけでは、切り替わっていない場合があります。切り替え後、ログで設定が再読み込みされたか、認証、証明書、通信接続のエラーが表示されていないかを確認します。

• まず1つ選ぶ：サービス提供元が利用可能と案内しており、現在のコアが対応するプロトコルのノードを優先します。コア、ルーティング、DNSを同時に変更しないでください。
• 次に遅延を測定：右クリックメニューの遅延テストは候補の絞り込みに役立ちます。ただし、TCP接続が成功しても、ポートに接続できたことを示すだけで、認証やWebリクエストまで成功するとは限りません。
• 最後にアクセスをテスト：実際のリクエストを実行し、ブラウザーで対象ページを開きます。遅延の数値はダウンロード速度ではなく、最小値だけで使い心地を判断することもできません。

たとえば、TCP遅延が80ミリ秒でもアクセス時に認証エラーが出るノードは使えません。一方、遅延が150ミリ秒でもリクエストが正常に完了するノードなら、ローカル設定の切り分けを続ける価値があります。これらの数値は判断例であり、本サイトでの実測値ではありません。

5. システムプロキシはどれを選ぶ？「変更しない」と「クリア」の違いは？

ブラウザーを初めてテストする場合は、「システムプロキシを自動設定」を選んでください。トレイアイコンの右クリックメニューから「システムプロキシ」を開き、該当する項目を選びます。システムプロキシをクライアントのローカル待ち受けポートに向けますが、この接続先を使うかどうかは、アプリがシステムプロキシ設定を参照するかによって異なります。

Linuxデスクトップ環境やアプリによって、システムプロキシへの対応状況は異なります。ターミナルツールでは、独自のパラメーターや環境変数が必要な場合もあります。「システムプロキシが有効」だからといって、すべてのプログラムがプロキシを使うとは限りません。ブラウザーにプロキシ拡張機能がある場合は、システム設定を上書きしていないかも確認してください。

6. ローカルアドレスとポートは何を指定する？サーバーのポートを使わないのはなぜ？

アプリが接続するのはローカルのプロキシ接続先であり、コアがリクエストをリモートサーバーへ転送します。リモートノードの443などのポートは、クライアントからサーバーへの接続に使うものです。ブラウザーのローカルプロキシ設定には入力できません。まず「設定」→「パラメーター設定」でローカル待ち受けポートを確認してください。具体的な項目はバージョンやインバウンドの種類によって異なります。

ログにaddress already in useと表示された場合、待ち受けアドレスまたはポートがすでに使用されています。クライアントが重複起動していないか確認して終了し、ほかのプログラムも調べてください。ローカルポートを変更した場合、プロキシを手動設定しているアプリの設定も変更が必要です。ローカルブラウザーを接続するために、待ち受けアドレスをすべてのネットワークインターフェースへむやみに公開しないでください。

7. 接続済みなのにWebページが開けない場合、何を確認する？

画面上の実行状態は、通常、ローカルコアが起動したことを示すもので、すべてのWebサイトへの接続を保証するものではありません。アプリがプロキシを使っていない、ノードの認証に失敗した、ドメイン名を解決できない、またはルーティングによって誤った出口へ送られている可能性があります。設定を一度に何か所も変えるより、接続経路を手前から順に確認してください。

1. ローカル接続先を確認

   ログでローカルポートの待ち受けが成功しているかを確認します。ポートの競合、設定の解析失敗、コアの終了がある場合は、まずそのエラーを解決してください。

2. アプリの接続を確認

   システムプロキシの自動設定を有効にして、ブラウザーのプロキシ拡張機能を一時的に無効にします。または、アプリでローカルのHTTP、SOCKS5接続先を明示的に設定します。

3. リクエストが届いているか確認

   Webページを再読み込みして接続ログを確認します。現在のログレベルでアクセスが記録される設定なら、対応するリクエストが見つかるはずです。記録がない場合は、アプリがプロキシを迂回していないか確認してください。

4. リモート側の応答を確認

   認証失敗の場合はサブスクリプションとノード情報を優先して確認します。タイムアウトの場合は回線とサーバーの状態を確認します。証明書エラーの場合は、システム時刻とサーバー証明書の設定を確認してください。

5. 名前解決を個別に確認

   ログにドメイン名の名前解決エラーが明示されている場合は、DNS設定を確認します。すべての接続タイムアウトをDNSの問題と決めつけたり、接続問題を解決するために証明書の検証を無効にしたりしないでください。

システムにcurlがあれば、システムプロキシの設定を通さずに、指定したローカル接続先を直接テストできます。以下のコマンドはローカルのHTTPまたは混合ポートが10808で、接続先が本サイトであることを想定しています。このリクエスト経路だけを検証するもので、すべての通信が正常であることを示すものではありません。

curl --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://v2raywrt.com/

コマンドは成功するのにブラウザーで失敗する場合は、ブラウザー独自のプロキシ設定、拡張機能、キャッシュされた接続を優先して確認してください。ローカルポートに接続できない場合は、待ち受けアドレスとコアの状態を確認します。ローカル接続先への接続後にリモート側でタイムアウトする場合は、利用可能と確認できている別のノードで比較してください。

8. ルーティングはグローバルとルール分岐のどちらを選ぶ？中国国内のサイトが遅い場合は？

普段の利用では、まずクライアントに用意されているルール分岐のプリセットを使ってください。システムプロキシはアプリからクライアントへリクエストを渡す方法を決め、ルーティングルールは受け取ったリクエストをプロキシ、直接接続、ブロックのどれにするかを決めます。この2つは別の仕組みです。システムプロキシが有効でも、すべての宛先がリモートノードを経由するとは限りません。

• 中国国内のサイトが遅い：現在のルーティングプリセットで、対象ドメインがプロキシ経由になっていないか確認します。まずローカルネットワークに適したルール分岐のプリセットに戻してテストしてください。
• 特定のサイトだけ失敗する：ドメインルール、ルールの順序、実際に選ばれた出口を確認します。すぐにすべての設定をリセットしないでください。
• 一時的なグローバルテスト：テスト対象の通信をプロキシ経由にするルーティングモードを一時的に選べます。テスト後は元のプリセットに戻し、診断用の設定をそのまま常用しないでください。
• ルールデータベースのエラー：ログにGeoIPまたはGeoSiteデータが見つからないと表示された場合は、ルールファイルと更新状態を確認してください。ノードのプロトコルだけを変更しても解決しません。

ルール分岐の結果は、DNSやドメインの識別方法にも影響されます。テストでは同じノード、同じ宛先を使い、ルーティングの項目を一度に1つだけ変更してから接続し直してください。ブラウザーで確立済みの長時間接続が以前の出口を一時的に使い続け、「設定が反映されない」と感じることがあります。

9. TUNが必要なのはどんなとき？有効にすると通信できなくなるのはなぜ？

TUNは仮想ネットワークインターフェースを使って通信を取り込みます。システムプロキシを参照せず、アプリごとにプロキシを設定しにくい場合に適しています。速度を上げるスイッチではなく、利用できないノードを直す機能でもありません。初心者はまず通常のシステムプロキシでノードが使えることを確認し、それからTUNを導入すると、問題の切り分けがしやすくなります。

• 有効にする前：現在のシステムプロキシとルーティング設定を記録します。デフォルトルートを変更するほかのネットワークツールを終了し、システムが仮想ネットワークインターフェースの作成を許可していることを確認してください。
• 権限の要件：クライアントとシステムの案内に従って権限を許可します。手間を省くために、関係のないプログラムへ継続的に高い権限を与えないでください。
• 有効にした後：Webページ、通常はシステムプロキシに従わないアプリ、ローカルネットワーク上のサービスを個別にテストします。Webページが開いても、UDPやローカルネットワークへのアクセスが必ず正常とは限りません。
• 通信できなくなった場合：まずTUNを無効にし、基本的なネットワークが復旧することを確認してから、仮想インターフェース、DNSの取り込み、ルートの競合を調べます。サブスクリプション、コア、DNSの全項目を同時に変更しないでください。

10. v2rayNを終了すると通信できない場合、復旧して調査情報を残すには？

よくある原因は、クライアント終了後もシステムがローカルプロキシを参照していることです。v2rayNを再度開き、「システムプロキシ」から「システムプロキシをクリア」を選んでから、通常の方法で終了してください。ここでは「変更しない」ではなく「クリア」を選びます。TUNを有効にしていた場合も、まず無効にしてネットワークの復旧を待ちます。

1. システムプロキシを確認：Windowsでは「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシや設定スクリプトが残っていないか確認します。組織のポリシーで管理されているデバイスでは、独断で変更しないでください。
2. アプリの設定を確認：ブラウザー拡張機能、ターミナルの環境変数、アプリに手動入力した127.0.0.1のプロキシ設定は、システムプロキシと一緒に必ず解除されるわけではありません。それぞれ元に戻してください。
3. 接続を再確立：影響を受けているアプリを再起動し、直接アクセスをテストします。それでも失敗する場合は、ネットワーク接続、システムDNS、仮想インターフェースの状態を確認してください。
4. 必要な情報を記録：OS、クライアントのバージョン、コアの種類、エラーの発生時刻、関連ログの一部を記録します。サブスクリプショントークン、ユーザー識別情報、サーバー認証情報は隠してください。

次に問題が起きたときは、「ローカルネットワーク → コアの待ち受け → アプリのプロキシ → ノード接続 → ルーティングとDNS」の順に確認してください。一度に変更する条件は1つだけにし、変更前後の結果を記録します。そうすれば、クライアント設定、サーバー、特定アプリの接続方法のどこに問題があるかを切り分けられます。