v2rayN設定ガイド

第1段階：基本概念

画面、コア、リモートサービスを区別する

接続を3つの要素に分けて考えます。v2rayNはGUIクライアントで、ノードの保存、サブスクリプションの管理、設定の生成、コアの起動を担当します。コアはローカルポートで待ち受け、プロトコルを処理し、ドメインを解決して、接続先を選択します。リモートサービスは接続を受け取り、リクエストを転送します。クライアントをインストールしただけでは利用可能なノードは得られず、サブスクリプションを登録してもリモートサービスが利用可能とは限りません。トラブル対処ではこの3層を個別に確認すると、リモート側の障害を画面設定の問題と取り違えずに済みます。

Project V、V2Fly、Xrayの関係を理解しましょう。Project Vは関連ツールやプロトコルのエコシステムの背景にあり、V2FlyはV2Rayの開発を引き継ぎ、Xrayは関連するコアの派生プロジェクトです。クライアントは複数のコアで接続できますが、あるプロトコルに対応しているからといって、すべてのトランスポート方式とセキュリティ設定の組み合わせに対応するとは限りません。インポートに成功したのは設定を認識できたということであり、使用中のコアが生成された項目を解釈できるか、サーバーとのネゴシエーションに成功するかは別途確認が必要です。

リクエストの流れに沿って設定項目を理解する

アプリがリクエストを送信してからの流れを見てみましょう。システムプロキシを使用するブラウザーは、まずローカルの待受ポートに接続します。コアは対象のドメイン名またはアドレスを受け取り、ルールに基づいて直接接続、プロキシ接続、ブロックのいずれかを選びます。プロキシ経由の場合はノードサーバーに接続し、必要なハンドシェイクを行います。TUNでは仮想ネットワークインターフェースが入口になりますが、その後もルーティングの判定と利用可能なアウトバウンドが必要です。したがって、通信を取り込む方法を変えても、ノードのアドレス、認証情報、トランスポート設定の誤りは解決しません。

ノードの設定項目はグループに分けて確認します。サーバーアドレスとポートは接続先、ユーザーIDやパスワードは認証、トランスポート方式はデータの運び方を指定します。TLSやREALITYなどの設定は、それぞれのセキュリティハンドシェイクを決めます。VMess、VLESS、Trojan、Shadowsocksはそれぞれ異なるプロトコルで、REALITYはそれらと並ぶサブスクリプション形式ではありません。サービス提供元が指定する設定の組み合わせをそのまま使い、名前が似ているからといって項目を入れ替えないでください。

状況を判断する基準を作る

ドメイン解決、トランスポート接続、アプリケーションの応答を区別します。名前解決に失敗した場合、リクエストがノードに届いていない可能性があります。接続拒否なら、待受状態やリモートポートを確認します。ハンドシェイクエラーではセキュリティ設定とシステム時刻を確認します。ページにエラーが表示される場合は、接続先サービス側の問題かもしれません。すべてを「プロキシが動かない」とひとまとめにしないでください。問題が起きたアプリ、接続先、時刻、モードを記録してから、同じ時刻のコアログを確認します。

接続テストの結果が示す範囲を理解しましょう。リストに表示される接続テストは、クライアントが採用するテスト方法で確認できる範囲に限られ、すべてのWebサイト、アプリ、ネットワークで使えることを保証しません。テスト先が制限されていると、実際の用途ではアクセスできてもテストには失敗する場合があります。逆にテストが成功しても、ドメイン解決、長時間接続、ファイル転送が正常とは限りません。実際のWebページとアプリを1つずつ、検証用に決めておきましょう。

この段階の最後に、画面上の項目名を使わずに通信経路を説明してみましょう。どのアプリが、どの入口を通じて、どのコアに何を渡し、どのアウトバウンドから送信するのでしょうか。説明できたら、用語クイックガイドで用語を補足してください。以降の章もこの経路に沿って解説します。すべてのプロトコル項目を一度に覚える必要はなく、接続に成功する前に複雑なルールを追加する必要もありません。

第2段階：クライアントの選び方

OSとプロセッサで候補を絞る

デスクトップではv2rayNを第一候補とし、OSとプロセッサのアーキテクチャに合わせてクライアントのダウンロードページを確認してください。Windowsでは「設定 → システム → バージョン情報」のシステムの種類、macOSでは「このMacについて」のチップまたはプロセッサ、Linuxではディストリビューションのパッケージ形式とマシンアーキテクチャを確認します。パソコンのメーカー名だけでインストーラーを選ばず、画面が似ているからといって異なるプラットフォームのパッケージを流用しないでください。

Windowsのダウンロード欄では、デスクトップ版と従来のWPF版を区別してください。デスクトップ版はクロスプラットフォームのUIを採用し、複数のデスクトップOSで似た操作性を求めるユーザーに適しています。WPF版はWindows向けで、従来の画面と操作感を維持しています。どちらも実際の配布パッケージに記載された動作条件を確認してください。「新しい」「従来版」といった名称だけで特定の機能の有無を判断しないでください。メニューの位置、設定の反映範囲、実行環境は配布版によって異なる場合があります。

コアの機能を既存の設定に合わせる

AndroidではXrayコアをベースにしたv2rayNGを優先し、V2Flyコアを使用するv2flyNGは代替候補とします。複数のクライアントをインストールして頻繁に切り替えるのではなく、既存ノードのプロトコルと機能を基準に選んでください。2つのアプリの設定が完全に同じとは限らず、インポート方法が似ていても設定データベースをそのままコピーできるとは限りません。初めて使う場合はAndroidのクイックスタート手順を確認し、通信を取り込む入口は動作するものを1つだけにしてください。

クライアントの機能とサブスクリプションの内容を区別しましょう。クライアントを変えても通常のノードが別のセキュリティ設定に変わるわけではなく、サーバーが提供していない項目が補われるわけでもありません。インポート後に項目が不足している場合は、サブスクリプションの対象クライアント、リンクに必要な情報がすべて含まれているか、ノードが必要とするコアを確認してください。インポートを通すために項目を安易に削除しないでください。保存できた簡易設定でも、実際のハンドシェイクで非互換が判明する場合があります。

移行前に元に戻せる環境を確保する

デスクトップ版の画面を切り替える前に、旧環境のサブスクリプショングループ、使用中のノード、待受ポート、ルーティングモード、DNS設定を記録し、クライアントのバックアップ機能で保存します。新しい環境は別のインストールとして扱い、まず1つのノードで基本的なアクセスを確認してください。同じ待受ポートを取り合う2つのクライアントを同時に起動したり、システムプロキシを交互に書き換えたりしないでください。画面に表示されたモードと、システムで実際に使われているアドレスが食い違うことがあります。

動作条件を確認するときは、画面の起動と通信の取り込みを分けて考えます。メインウィンドウが開いても、コアが起動したとは限りません。コアが起動しても、現在のアカウントで仮想ネットワークインターフェースを作成できるとは限りません。通常のシステムプロキシでは、プログラム全体を常時管理者権限で実行する必要はありません。一方、TUNでは権限の昇格や対応するサービス機構が必要な場合があります。目的の機能に必要な権限だけを付与し、あらゆるエラーに対して権限を上げる方法を取らないでください。

選択したら、OS、プロセッサ、使用するクライアント、予定している入口モードを明確に書き留めてください。ダウンロードページで該当プラットフォームの要件を確認し、インストール途中で方針を変えずに済むようにします。デスクトップ版の2つのUIを比較したい場合は、v2rayNデスクトップ版とWPF版の違いを参照し、外観だけでなくOSの対応状況と機能差を確認してください。

この段階の合格基準は「パッケージを正しく選ぶこと」であり、「すべての機能を有効にすること」ではありません。現在のデバイスと既存ノードの要件を満たし、シンプルで再現可能な接続方法を1つ確保しましょう。より多くのアプリを取り込んだり、ルールを調整したりする必要が出てから機能を追加すれば、問題発生時の確認範囲を絞れます。

第3段階：インストールと初回起動

保存先と動作条件を決める

Windowsクライアントのダウンロードページから、確認済みのバージョンを選び、実際のパッケージ形式に合わせて操作します。インストーラーの場合はウィザードに従ってインストールします。圧縮ファイルの場合は固定のフォルダーに展開してから実行し、圧縮ファイル内から直接起動しないでください。継続して使うデータを、一時ファイルの削除対象になる場所に置くのは避けましょう。設定、ログ、コアのファイルを保存するため、パスの短さよりもフォルダーに書き込みできることが重要です。

初回起動時に実行コンポーネントの不足が表示されたら、現在の配布パッケージの説明に従って必要なものを追加してください。古いガイドを参考に、アーキテクチャが合わないコンポーネントを安易にインストールしないでください。表示された名前を正確に記録し、実行環境の不足、ファイルのブロック、コアの起動失敗を区別します。システムのセキュリティ警告が表示されたら、配布元とファイルのプロパティを確認してから対応を判断してください。画面を開くためにシステムの保護を全面的に無効にしたり、すべての不明なプログラムを許可したりしてはいけません。

画面とコアがそれぞれ起動していることを確認する

メインウィンドウが開いたら、まずログまたは情報欄を探します。まだノードがない場合、接続できないのは正常です。設定の読み込み失敗、書き込み権限のないパス、待受失敗がないかを確認してください。画面が応答するのはGUIが正常という意味であり、コアが待ち受けていることを示すものではありません。ノードを追加したら起動情報をもう一度確認し、即時終了や再起動の繰り返しがないことを確かめてから、システムプロキシを設定します。動作していないポートにブラウザーを向けないようにしてください。

「設定」にあるローカル待受関連の項目を確認し、アドレス、ポート、対応する入口プロトコルを記録します。バージョンによっては混合入口が用意されていたり、HTTPとSOCKSの入口が別々だったりします。古い記事から現在のデフォルトポートを推測しないでください。通常はローカルアプリからループバックアドレスに接続できれば十分です。LANからの接続を許可するとアクセス範囲が広がります。他のデバイスとの共有が明確に必要な場合だけ有効にし、ファイアウォールとアクセス制限も合わせて検討してください。

Get-NetTCPConnection -State Listen |
  Sort-Object LocalPort |
  Select-Object LocalAddress, LocalPort, OwningProcess

このコマンドは、現在のTCP待受ポートとプロセスIDを表示するもので、ネットワーク設定は変更しません。結果に表示されたポートを画面に記録した値と照合し、タスクマネージャーの「詳細」タブで対応するプロセスを確認します。ポートが他のプログラムに使用されている場合は、まず重複して起動しているクライアントを終了してください。複数のクライアントを同時に使う必要がある場合は、いずれかの待受ポートを変更し、そのポートに依存するアプリの設定も更新します。見覚えのないプロセスを見つけても、すぐに終了しないでください。

起動時の基準状態と終了手順を記録する

まずはスタートアップ起動、自動サブスクリプション更新、TUNなどの追加機能を無効にして、手動で起動と終了を一度試します。終了前にシステムプロキシを解除し、終了後にブラウザーが通常のネットワーク経路でアクセスできることを確認してください。これで復旧手順を検証できます。後でノードに問題が起きても、システムをローカルプロキシの入口から切り離す方法が分かります。メインウィンドウを閉じただけではトレイに格納された可能性があるため、トレイメニューから完全に終了したことを確認してください。

他のデスクトップOSでも同じ順序で確認します。プログラムが起動する、データを保存できる、コアを読み込める、待受ポートが競合しない、終了後に元の状態へ戻せることを確かめてください。macOSではチップに合ったインストール方法を選び、Linuxではディストリビューションに合うパッケージ形式を使います。権限に問題がある場合は、インストール先とシステムの警告を確認し、すべてのファイルのアクセス権を広げないでください。待受ポートの競合を詳しく調べるには、ローカルポートが使用中の場合の対処方法を参照してください。

この段階を終えたら、インストール場所、データのバックアップ方法、待受設定を簡潔に記録しておきます。クライアントを一度再起動し、設定が維持されていることを確認してください。この基準状態が安定していれば、サブスクリプションの追加やルールの調整で起きた変化を比較できます。インストール層の不安定さをネットワークの変化と取り違えずに済みます。

第4段階：サブスクリプションとノードの管理

グループを追加してから更新する

「サブスクリプショングループの設定」を開き、見分けやすいグループ名を付けて、サービス提供元のサブスクリプションURLを該当欄に貼り付けます。先頭や末尾の空白、改行、コピー時に混入した句読点がないか確認してください。サブスクリプションURLにはアクセス用の認証情報が含まれる場合があるため、機密情報として扱い、公開スクリーンショット、メモ、問い合わせ文面に載せないでください。グループを保存してメイン画面に戻り、該当グループを選択して「現在のサブスクリプションを更新（プロキシを使用しない）」を実行します。

更新方法の違いを理解しましょう。「プロキシを使用しない」は、まだローカルプロキシを利用できない場合や、サブスクリプションURLに直接アクセスできる場合に使います。プロキシ経由の更新は、すでに利用可能な接続経路に依存します。直接更新に失敗したら、まず現在のネットワークからURLにアクセスできるかを確認し、利用可能なプロキシに切り替える必要があるか判断してください。使えるノードがまったくない状態で、プロキシ経由の更新によって初回取得の問題が解決すると期待しないでください。相互に依存してしまいます。

取得エラーと解析エラーを区別する

更新結果を確認するときは、まず内容を取得できたかを判断します。ドメインを解決できない、接続がタイムアウトする、サービスから拒否されるといった問題は取得段階のものです。内容が返ってきてもノードが表示されない場合は、形式が対応していない、ログインページが返された、ノードの設定項目を認識できない、といった可能性があります。Webページが開けても、返された内容がサブスクリプション本文とは限りません。サービス提供元に問い合わせる際は、エラーの種類と機密情報を除いた応答の説明だけを伝え、サブスクリプションURL全体や認証情報は送らないでください。

更新に成功したら、ノード一覧で名前、プロトコル、アドレス、所属グループを確認します。同じ名前でも同一の設定とは限らず、名前から実際の通信品質も判断できません。ノードを1つ選んでアクティブサーバーに設定し、コアが正常に読み込まれるかを確認します。多数のノードを一度に並列テストしないでください。テスト自体が帯域を消費したり、サービスの制限に触れたりするほか、短時間の結果が実使用時の安定性を見えにくくすることがあります。

手動ノードとサブスクリプションによる上書きを理解する

単独の共有リンクを使う場合は、クライアントのクリップボードからのインポート機能で追加し、取り込まれた項目を確認します。手動ノードは一時的な検証や少数の設定に適しており、サブスクリプショングループはサービス提供元による一括更新に適しています。サブスクリプションのノードを直接編集しても、その変更が永続するとは限りません。次回の更新でレコードが作り直される場合があります。長期的にカスタマイズする場合は、まず独立した手動グループにコピーし、元のサブスクリプションと同期されないことが分かるように記録してください。

グループを削除する前に、操作対象がグループの記録、サブスクリプションのノード、すべてのサーバーのどれなのか確認してください。テスト用と普段使いのグループを混同しないようにします。更新後にノード数が減っても、インポートの破損とは限りません。サービス提供元が利用可能な項目を変更した可能性もあります。まず更新結果とグループの絞り込み条件を確認し、別のグループを誤って選択していないか見直してください。古いバックアップから復元できるのはローカルの記録であり、利用できなくなったリモートサービスが再び使えるようになるわけではありません。

セキュリティ関連の設定を確認するときは、サーバーアドレス、ポート、ユーザーID、トランスポート方式、サーバー名、対応する鍵の項目を一組として整合させます。ハンドシェイクエラーを解消するために証明書の検証を安易に無効にしたり、別ノードのセキュリティ項目をコピーしたりしないでください。システム時刻が大きくずれている場合もハンドシェイクに影響するため、まずデバイスの時刻を修正してから再テストします。サービス側の要件を把握したうえで、手動で項目を調整してください。

更新頻度はサービス提供元の設定変更のペースに合わせます。頻繁に更新しても通信速度が自動的に上がるわけではなく、トラブル対処中の状態が上書きされることがあります。重要な変更の前にローカルバックアップを保存し、現在のアクティブノードを記録してください。更新後は同じ接続先で検証します。「内容の変更」と「一時的な接続失敗」を区別し、状況を保ったまま調査を続けられます。

この段階の完了基準は、サブスクリプションの取得元、ノードの所属グループ、現在有効なノード、次回更新で上書きされる内容を説明できることです。基本的なインポートに失敗した場合は、クイックスタートのサブスクリプション手順に戻って順にやり直してください。項目名が分からない場合は用語集を確認し、クライアントのデータフォルダー全体を何度も削除しないでください。

第5段階：システムプロキシとプロキシモード

通信の入口とアウトバウンドのルールを分ける

まず2つの問題を区別します。アプリがどのようにリクエストをクライアントへ渡すか、クライアントが受け取ったリクエストをどのように送信するかです。「システムプロキシを自動設定」は前者を担当し、ルーティングのグローバルルールやバイパスルールは後者を担当します。システムプロキシを有効にしても、すべてのプログラムがそれを使うとは限りません。グローバルプロキシを選んでも、コアに届いた通信にだけ影響します。この2つの層を理解すれば、ブラウザーは使えるのに一部のデスクトップアプリでは変化がない理由を説明できます。

v2rayNで「システムプロキシを自動設定」を選び、Windowsの「設定 → ネットワークとインターネット → プロキシ」で実際のアドレスとポートを確認します。クライアントが現在システムプロキシに使用している待受入口と一致している必要があります。トレイアイコンだけを見て判断しないでください。通常はローカルのループバックアドレスを指定し、ノードサーバーのアドレスは使いません。リモートノードのポートはコアがサーバーに接続するためのもので、ブラウザーに入力するローカルプロキシのポートではありません。

アプリの動作に合わせて通信の取り込み方法を選ぶ

まずシステムプロキシを参照することが分かっているブラウザーで、実際の接続先にアクセスします。ブラウザー独自のプロキシ設定、拡張機能、専用プロファイルを使用していると、システム設定に従わないことがあります。トラブル対処では、元の設定を記録してから一時的にプロキシの設定元を1つだけにしてください。コマンドラインツール、ゲーム、バックグラウンドサービスも独自のネットワークスタックを使う場合があります。それぞれの設定を確認し、ブラウザーで成功したからといって、すべてのアプリにも当てはまると考えないでください。

アプリのプロキシを手動設定する場合は、対応するHTTPまたはSOCKSの入口を選び、クライアントが実際に待ち受けているアドレスとポートを入力します。2種類の入口の項目を機械的に入れ替えないでください。クライアントに混合入口がある場合も、選んだプロトコルに対応していることを確認します。アプリに独自のドメイン解決設定がある場合は、解決処理もプロキシ側に委ねられているか確認してください。プロキシを通っていても、ドメインだけが別の経路で解決されることがあります。

解除、維持、自動設定の違いを理解する

「システムプロキシを解除」は、現在システムに設定されている手動プロキシを削除しますが、各アプリ内の設定まで自動的に解除するものではありません。「システムプロキシを変更しない」は、クライアントがシステム設定を書き換えないという意味であり、現在プロキシが設定されていないとは限りません。クライアント終了後にWebページへアクセスできなくなったら、まずシステムがローカルポートを参照したままかを確認し、次にブラウザーに独自設定が残っていないか調べます。クライアントが終了して待ち受けていない入口を使い続けないでください。

切り替える前に現在の状態を記録し、切り替え後にシステム設定を照合して、新しい接続をテストします。既存の長時間接続は以前の経路を使い続ける場合があり、ブラウザーの接続プールにも変化が反映されるまで時間がかかることがあります。テストページを閉じて開き直し、必要であればテスト対象のアプリを完全に終了してから再試行してください。テストのたびにノード、DNS、ルーティングを同時に変更しないでください。状況が変わっても、どの変更が影響したか分からなくなります。

この段階を終えたら、順方向と逆方向の両方を検証します。自動設定を有効にしてブラウザーがローカル入口経由で使えることを確認し、システムプロキシを解除して通常のネットワーク動作に戻ることを確かめてください。この操作をトラブル時の復旧手順として残します。システムプロキシを参照しないアプリを取り込む必要があると明確に分かった場合にのみ、後のTUN段階に進んでください。設定項目を増やすためにすべてを有効にする必要はありません。

第6段階：ルーティングとDNS

組み込みモードでルールの基準を作る

まずルーティング関連のメニューで、現在の用途に合う組み込みルールを選びます。たとえば「中国本土をバイパス」に相当するモードを選び、実際のアクセスを確認します。ルールセットごとに、プライベートアドレス、ドメイン分類、デフォルトのアウトバウンドの組み合わせが異なる場合があります。モード名だけから詳細を推測せず、使用前にルールの内容と順序を確認してください。ローカルネットワークのリソースを直接接続するか、どのルールにも一致しない宛先がどこへ向かうか、参照先のデータファイルが読み込めるかも確認します。

ルールの照合順を理解しましょう。一般的なルーティングでは、先頭から順にルールを確認します。前方に広い条件のルールがあると、後方の詳細なルールが適用されない場合があります。特定のサービスに例外を追加する際は、既存ルールとの関係を確認してから適切な位置に追加してください。先頭に「すべての通信をプロキシへ」というルールを置き、その後にあるプライベートアドレスへの直接接続が有効になると期待してはいけません。変更後はページが開くかだけでなく、ログでどのルールに一致したかを確認します。

ドメインルールとアドレスルールを区別する

ドメインルールはリクエストで利用可能なドメイン情報に基づいて照合し、アドレスルールは接続先アドレスに基づいて照合します。1つのサービスが複数のドメインや分散アドレスを使う場合、トップページのドメインを追加するだけでは、ログイン、静的ファイル、ダウンロードのリクエストをすべて網羅できないことがあります。一方、特定の解決結果のアドレスでルールを追加すると、同じアドレスを共有する別のサービスにも影響する可能性があります。一度の名前解決結果を長期的に有効なルールの代わりにせず、対象となる業務ドメインの範囲を明確に指定してください。

{
  "type": "field",
  "domain": ["geosite:cn"],
  "outboundTag": "direct"
}

これはルールオブジェクトの例であり、完全な設定ではありません。該当するコア設定のルール配列に追加する必要があり、環境には利用可能なドメイン分類データが必要です。また、実際のアウトバウンドタグ名がdirectであることも確認してください。クライアントが生成するタグは異なる場合があるため、生成された設定を見て対応づけます。この断片で設定ファイル全体を上書きしたり、共有リンク専用のインポート欄に貼り付けたりしないでください。クライアントが対応するルール編集機能を優先して使います。

名前解決と通信の経路を一致させる

DNSはドメイン名をアドレスに変換しますが、クライアントのコア、OS、アプリがそれぞれ名前解決を行う場合があります。リモートDNSと直接接続用DNSは異なる役割の設定であり、同じアドレスを2か所に入力すれば分流が完成するわけではありません。リモートの名前解決サービスへの接続にプロキシが必要なら、その接続に使うアウトバウンドも明確にしてください。名前解決がプロキシに依存し、プロキシ接続も未完了の名前解決に依存する起動時のループを避けます。

確認時は、まず誰がドメインを解決しているかを特定し、次に名前解決リクエストの経路を確認します。ブラウザーで暗号化DNSを有効にしていると、想定したシステムの名前解決経路を迂回する場合があります。アプリがアドレスを直接リクエストすると、コアが元のドメイン名を取得できないこともあります。スニッフィングは特定の条件下でプロトコル情報を取り出せますが、あらゆる接続を認識できるわけではなく、DNS設計の代わりにもなりません。ルーティングに問題がある場合は、まず経路を簡素化してから機能を段階的に戻してください。

誤ったルールに一致する場合は、対象の完全なドメイン名、実際の解決アドレス、ルールの順序、現在のアウトバウンドを記録します。ルールデータが更新されると、同じドメインの分類が変わる場合があります。データの更新も設定変更の一つとして扱ってください。一時的な例外ルールで解決した場合は、恒久的に残す前に原因を確認します。互いに上書きし合う修正を積み重ねないでください。関連する確認方法はDNSリークテストと漏えい対策の設定を参照し、想定した名前解決経路を重点的に確認します。

この段階を終えたら、次の3つの結果を説明できるはずです。明示的な直接接続、明示的なプロキシ接続、一致するルールがない場合のデフォルト動作です。再起動後もルールが維持されるか、コアが不明な項目や不足しているデータを報告しないかも確認します。システムプロキシでルーティングと名前解決が安定してからTUNを有効にしてください。そうしないと、接続範囲を広げた結果、局所的な問題がより多くのアプリに波及します。

第7段階：TUNモードと通信の取り込み範囲

仮想インターフェースが本当に必要か判断する

TUNは仮想ネットワークインターフェースを通じて、ルーティング条件に合うシステム通信を取り込みます。システムプロキシを参照しないものの、共通のルーティングに含める必要があるアプリに適しています。変わるのは通信の入口であり、ノードに新しいプロトコル機能が追加されたり、認証情報の誤りが自動的に直ったりするわけではありません。有効にする前に、同じノードが通常のシステムプロキシで使えることを確認し、正常に動作する状態を残してください。基本的な接続が不安定な場合は、サブスクリプション、待受、ルーティングの章に戻って確認します。

通信の取り込み範囲を検討するときは、ローカル、LAN、リモートを分けて整理します。プリンター、共有フォルダー、開発用サービス、リモートデスクトップ、他の仮想ネットワークには、特定の直接接続経路が必要な場合があります。TUNを有効にすればすべてのアドレスをプロキシに送るべき、というわけではありません。有効化する前にプライベートアドレスや必要なネットワーク範囲の扱いを確認してください。リモート管理の接続が切れてから復旧方法を考えるのではなく、ネットワークを戻す手段をあらかじめ用意しましょう。リモート操作中は特に重要です。

権限、インターフェース、ルーティングの順に起動する

設定を保存し、現在のクライアントが必要とする管理者権限またはサービス機構を使用してから、「TUNモードを有効にする」をオンにします。画面やコアによって起動方法は異なるため、実際の案内を確認してください。スイッチをオンにした直後にアクセスできないからといって、すぐ失敗と判断しないでください。まずコアが終了していないこと、仮想インターフェースが作成されたこと、システムルートが設定されたことを確認します。ログに権限不足、インターフェース作成失敗、ルート設定失敗が記録されている場合は、個別に対処してください。

インターフェースやドライバーに関する問題が表示されたら、まず重複起動したクライアントを終了し、他の仮想ネットワークソフトウェアが同種のリソースを使用していないか確認します。システム上の仮想ネットワークインターフェースをすべて削除したり、ドライバーを一括でアンインストールしたりしないでください。仮想マシン、コンテナー、企業ネットワーク用のインターフェースを削除すると、既存の環境に影響する場合があります。まずTUNを無効にしてクライアントを再起動し、明確なエラーに基づいて該当コンポーネントだけを処理してください。作業内容も手順ごとに記録します。

TCP、UDP、DNSの実際の動作を検証する

まずシステムプロキシで利用できていたWebページをテストし、次にこれまで通信を取り込めていなかった対象アプリを試します。両方が成功して初めて、入口の変更が目的を達成したと判断できます。UDP、音声通話、リアルタイム通信を使うアプリでは、リモート側と設定の組み合わせが必要な通信に対応しているかも確認してください。Webページを表示できてもUDPが正常とは限りません。アプリが起動しても、その後のメディア通信が同じ経路を通るとは限りません。実際の操作を行って確認してください。

DNSはTUNのトラブル対処における独立した層です。有効にすると、システムの名前解決、アプリの暗号化DNS、仮想インターフェースによる通信の取り込みが同時に作用する場合があります。アドレスへの接続はできてもドメイン名でアクセスできない場合は、まず名前解決の経路、リモートDNSサービスへの到達性、ルーティングの循環を確認します。名前解決の問題を隠すために対象アドレスを永久固定したり、DNS設定をすべて消去したりしないでください。現在の値を保存し、コアが対応する設定方法と一つずつ照合します。

LAN内のデバイスにアクセスできない場合は、ドメインの例外を追加するだけで済ませず、接続先アドレス、サブネットマスク、現在のルートを確認します。アドレスを直接使う共有サービスは、ドメインルールには一致しません。他のネットワークトンネルも同時に動作している場合、ルーティングの優先順位やデフォルトゲートウェイが競合する可能性があります。不要な入口を1つずつ無効にして比較してください。テスト後に組み合わせを戻し、どの設定が競合を引き起こすか確認します。すべての問題をノードのせいにしないでください。

スリープからの復帰、Wi-Fiの切り替え、有線ネットワークの抜き差し後は、仮想インターフェースと名前解決の経路を再確認します。復旧しない場合は、まずTUNをオフにしてからオンにし、クライアントに状態を再構築させてください。それでも失敗する場合は新しいログを確認し、権限を何度も上げないでください。正常終了後にネットワークが復旧することを確認し、異常終了後もシステムプロキシとルートの状態を確認します。詳しい仕組みと手順はv2rayN TUNモード設定メモを参照してください。

この段階の合格基準は「スイッチがオンのまま」であることではありません。追加対象のアプリが正しく取り込まれ、直接接続が必要なリソースも引き続き使え、終了後の復旧方法が明確であることです。必要を満たせる場合にTUNを継続して使いましょう。通常のシステムプロキシですべての用途をカバーできるなら、よりシンプルな入口を使うことで、権限、インターフェース、ルーティング間の影響を減らせます。

第8段階：日常のメンテナンスとトラブル対処

バックアップと更新は別々に行う

接続が安定しているときに、サブスクリプショングループ、手動ノード、ルーティング、DNS、必要なカスタム設定を含むバックアップを作成します。クライアントのエクスポート機能を使い、バックアップに含まれない項目も記録してください。バックアップにはサブスクリプションの認証情報やノードの識別情報が含まれる場合があります。管理された場所に保管し、共有する前に必ず機密情報を削除してください。メインプログラムのファイルだけでは使用中の状態を復元できず、ノード名のスクリーンショットだけでは設定全体を再現できません。

クライアント本体、コア、サブスクリプション、ルールデータの更新を区別します。それぞれ変更する対象が異なるため、個別に実行してその都度確認してください。クライアントを更新する前に正常終了し、ファイルが使用中のままにならないようにします。更新後はメニュー、待受状態、設定の移行結果を確認してください。現在のパッケージがコアの管理を一元化している場合は、その仕組みに従います。別の配布元のコアファイルを安易に上書きすると、画面が生成する設定項目とコアの機能が合わなくなるおそれがあります。

入口から出口へ順に原因を絞り込む

問題が起きたら、設定をさらに変更する前に、発生直前の変更を記録します。「アプリが入口を使っているか、ローカルで待ち受けているか、コアが起動しているか、ドメインが解決できているか、ノードとハンドシェイクできているか、接続先が応答しているか」の順に確認してください。一つの段階を通過してから次に進みます。この手順なら問題の境界を絞り込めます。ノードを何度も切り替え、サブスクリプションを更新し、システムネットワークをリセットして現象を再現できなくするのは避けてください。

ブラウザーだけが失敗し、他のアプリが正常なら、ブラウザー独自のプロキシ、拡張機能、暗号化DNS、接続キャッシュを確認します。すべてのアプリが失敗する場合は、まず待受とコアログを確認してください。特定の接続先だけで失敗するなら、接続先自体、ドメインルール、分散リソースに違いがないか調べます。ネットワークを変えてから失敗する場合は、DNS、アクセス認証、ルーティング環境を比較します。分類して調べるほうが、接続テストを繰り返すより有効で、不要な設定の作り直しも防げます。

Get-Date
Resolve-DnsName example.com

上記のコマンドで確認できるのは、現在のシステム時刻とシステムの名前解決結果です。クライアント内部のリモートDNSをテストしたことにはなりません。比較の基準として使ってください。システムの名前解決に失敗してもコア内の名前解決が正常なら、両者の経路が異なることを示します。システムで正常に解決できても、プロキシ経由の送信が正常とは限りません。ハンドシェイクエラーが起きたら、システム時刻とタイムゾーン、時刻同期の状態も確認します。コマンドが一度成功しただけでプロキシの全経路が正常と判断せず、実際のアプリで検証してください。

再現に必要な情報と復旧手順を記録する

ログを読むときは、その後に連鎖して起きたタイムアウトだけでなく、関連する最初のエラーを探します。エラーが属するモジュール、接続先の種類、発生時刻を記録し、操作の順序と照合してください。問題を報告する際は、サブスクリプションURL全体、ユーザーID、パスワード、その他の機密項目を削除します。ルールを示す必要がある場合は、関係する部分とアウトバウンドとの対応だけを残してください。ログレベルを上げるとアクセス記録が増える場合があります。調査が終わったら適切なレベルに戻し、不要になった複製ファイルを削除します。

バックアップを復元したからといって、環境全体が元どおりになったと決めつけないでください。まずグループが存在することを確認し、次にアクティブノード、待受ポート、ルーティング、DNSを確認して、最後にシステムプロキシまたはTUNを検証します。旧環境のインターフェース、権限、インストール先は新しいデバイスに適さない場合があるため、新しいシステムに合わせて再設定してください。復元作業中も現在のバックアップを残し、出所の分からない古い設定で、唯一利用できる状態を上書きしないでください。

モバイル端末のメンテナンスでは、バッテリー最適化、自動起動、バックグラウンド制限も確認する必要があります。画面ロック後に接続が切れる問題は、デスクトップの待受ポートの競合とは別です。デスクトップ用のトラブル対処手順をそのまま使わないでください。v2rayNGのバックグラウンド動作とバッテリー設定を参考に、デバイス側の確認項目を作成できます。どのクライアントを使う場合も、復旧可能な設定を残してから更新し、ネットワークの利用可否とソフトウェアの変更を分けて検証してください。

この段階を終えたら、簡潔な復旧チェックリストを準備します。システムプロキシを解除する、TUNを無効にする、通常のネットワークを確認する、クライアントを起動する、基準ノードを読み込む、ルーティングを戻す、といった項目を並べます。実際に問題が起きたとき、断片的な情報をその場で探すより、手順に沿って確認するほうが判断を揃えやすく、局所的な問題をシステム全体に広げずに済みます。

第9段階：応用設定と学習の進め方

生成された設定を読むことから始める

応用設定の第一歩は、設定ファイルを最初から丸ごと書くことではなく、クライアントが実際に生成する内容を読むことです。現在の設定を表示する場所を探し、インバウンド、アウトバウンド、ルーティング、DNS、ログの各モジュールを区別して、画面上の設定がどのように反映されるかを確認します。起動時やノード切り替え時に生成ファイルが作り直されることがあり、直接編集しても変更が維持されるとは限りません。クライアントが提供するカスタム設定の入口とマージ規則を理解してから、どの項目を画面上で管理するか決めてください。

アウトバウンドタグを1つ追跡してみましょう。プロキシ用と直接接続用のアウトバウンドで実際に使われるタグを探し、ルールの参照先と一致しているか確認し、最後にどのルールにも一致しない場合の動作を確認します。タグは設定内の参照関係を示すものであり、固定された日本語名でもノードの備考欄でもありません。他の資料にあるルールをコピーする前に、この対応関係を必ず確認してください。項目の形式は正しくてもタグが存在しない場合、起動時に失敗したり、意図した出口が選ばれなかったりすることがあります。

各実験で期待する結果を決める

実験ごとに目的、変更内容、元に戻す方法を書きます。たとえば、特定のドメインを直接接続する場合は、そのドメインが指定したルールに一致し、他の接続経路は変わらないことを期待します。特定のアプリにTUNを適用するなら、そのアプリの通信が新たにコアへ入り、ローカルのリソースには引き続きアクセスできることを期待します。何を観察するか分かるよう、期待する結果を具体的にしてください。「少し速くなった気がする」だけでは、キャッシュ、ノード、ネットワークの変動を排除できません。

実験専用の設定コピーを用意し、普段使う環境に設定を重ね続けないようにします。複数ルールを組み合わせる前に単独の例外ルールを試し、複雑なドメイン処理を調べる前に基本的な名前解決を理解してください。新たな問題が起きたら、最近の動作する状態に戻して変更を比較し、さらに修正を積み重ねないでください。実験記録は、翌日にデバイスを開いたときも、カスタム項目ごとの用途を理解できる内容にします。

問題の種類に合わせて次の学習ルートを選ぶ

プロトコルの学習ルートは、インポートやハンドシェイクの問題が頻繁に起きるユーザーに適しています。サーバーアドレス、認証、トランスポート、セキュリティ層、サーバー名の順に学び、どの項目をリモート側から取得する必要があるかを理解してください。プロトコル名を性能ランキングとみなしたり、1回のテストだけで特定の組み合わせが常に優れていると判断したりしないでください。プロトコルの選択は、まずサーバーの対応状況と実際のネットワーク環境によって決まります。クライアントが実行できるのは、互換性のある設定に限られます。

ルーティングの学習ルートは、LAN内のリソースへのアクセス、サービスごとの接続先の振り分け、複雑なアプリの扱いが必要なユーザーに適しています。まずルールの順序、ドメインとアドレスの違いを把握し、次に分類データとデフォルトのアウトバウンドを学びましょう。DNSのルートでは、名前解決を誰が開始し、どのアウトバウンドから送信し、その結果がどのようにルール判定に使われるかを追います。2つのルートは互いに検証する必要がありますが、初回の調整では分けて試してください。そうしないと、1回のアクセスの変化に名前解決結果とルール判定の両方が関わり、原因を特定できなくなります。

システムネットワークの学習ルートは、TUNを継続して使うユーザーに適しています。インターフェース、ルーティングテーブル、アドレス範囲、権限の境界を学び、ネットワークの切り替え、仮想マシン、他のトンネルが競合する理由を理解してください。機能を増やすためだけにLANからの待受を許可したり、アクセス範囲を理解しないままローカルポートを共有したりしないでください。他のデバイスにサービスを公開すると、認証、デバイスの信頼性、ファイアウォールも追加で検討する必要があります。もはやローカルプロキシの設定だけの問題ではありません。

保守しやすい設定を作る

最終的な設定を整理するときは、不要になった一時的な例外を削除し、残すルールには短い理由と、必要となるコアの機能やデータファイルを記録します。ルールが多ければ網羅性が高まるとは限りません。相互に重複すると、かえって読みづらくなります。説明できない設定のまとまりを保存しないでください。どうしても残す必要がある場合は、実験用のコピーで問題を解決することを確認してから長期運用の設定に統合し、再起動後も有効であることを確かめます。

読む順序を決めておきましょう。操作を忘れたらクイックスタートに戻り、用語が分からないときは用語クイックガイドを確認し、具体的なエラーが起きたら技術記事を読み、プラットフォームを変更するときはクライアントのダウンロードページを開きます。本ガイドはこれらの情報をつなぐものであり、すべての機能を一度に有効にする必要はありません。説明、検証、復旧ができる運用方法を1つ保ち、実際の問題に合わせて段階的に広げることが、この学習ルートの目標です。