v2rayN 設定・保守ガイド

基本概念：クライアント、コア、設定の違い

リクエストの経路を把握する

接続の流れをいくつかの段階に分けて考えます。アプリがリクエストを送信し、通信がローカルのプロキシ入口に入り、コアがルールに基づいて送信先を選び、リモートサーバーが目的のサイトなどにアクセスします。クライアントはGUIの提供、サブスクリプションの保存、実行設定の生成を担当し、コアは実際の通信を処理します。ウィンドウが開いても、GUIが起動したことしか確認できません。コアが正常に動作しているか、リモートサーバーが利用できるかは別途確認が必要です。問題が起きたら、複数の設定を一度に変えるのではなく、この経路に沿って順に確認すると原因を特定しやすくなります。

設定は大きく2種類に分けられます。1つはサーバーアドレス、ポート、認証情報、通信方式、セキュリティ設定など、リモート接続に関するもの。もう1つは待ち受けアドレス、システムプロキシ、ルーティング、名前解決など、端末側の動作に関するものです。サブスクリプションが提供するのは通常、主に前者で、端末側の設定はクライアントが管理します。サブスクリプションを更新してノードが変わっても、システムプロキシやルーティングが連動して変わるとは限りません。反対に、端末側のプロキシ入口が正常でも、無効なリモート認証情報は解決できません。

コアの系統とプロトコル項目を理解する

Project Vは、関連するプロキシ技術のエコシステムの背景にあたります。V2FlyとXrayは、それぞれ異なるコアの開発系統です。v2rayNはデスクトップ向けのGUIクライアントで、利用できる機能は選択したコアとクライアントの対応状況によって異なります。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。クライアント、コア、プロトコルを同じものとして扱わないようにしましょう。プロトコル項目が機能するかどうかは、クライアントが設定を表現できるか、コアが解釈できるか、リモート側と設定が一致しているかによって決まります。

VMess、VLESS、Trojanはよく使われる接続プロトコル名です。通信方式は接続の運び方を定め、TLSやREALITYなどの設定は接続時のセキュリティ交渉に関わります。REALITYは独立したサブスクリプション形式ではなく、スイッチを有効にするだけで任意のノードに対応機能が加わるわけでもありません。設定をインポートしたら、サービス提供元が指定した組み合わせを維持してください。サーバー名、フィンガープリント、公開鍵、通信パスなどを名前だけで推測して変更しないでください。どれか1つでも一致しないと、単なる接続先への到達不能ではなく、ハンドシェイクエラーになることがあります。

観測できる症状から障害箇所を切り分ける

名前解決、接続確立、アプリの応答を分けて考えます。ドメイン名の解決に失敗している場合、リクエストはまだリモート側に届いていない可能性があります。接続がタイムアウトする場合は、端末のネットワーク、接続先アドレス、中継経路を確認します。ハンドシェイクエラーなら、プロトコルのパラメーターやセキュリティ設定を調べます。クライアントの接続テストで確認できるのは、そのテストが対象とする範囲だけで、実際のアプリでの動作確認の代わりにはなりません。特定のページが開いても、その時点のリクエストが成功したことを示すだけです。他のアプリ、プロトコル、ルーティングまで正しいとは限りません。

最小限の動作基準を作り、確実に使える設定を1つ残します。まずシステムプロキシで対応アプリの動作を確認し、その後、ルーティングや仮想ネットワークインターフェースを段階的に追加します。一度に変更する項目は1つにし、変更前後の症状を記録してください。ノードの変更、名前解決ルールの書き換え、仮想ネットワークインターフェースの有効化を同時に行うと、接続が回復しても何が効いたのか分かりません。保守で大切なのは、設定を何度も切り替えて偶然つながることではなく、同じ結果を再現できることです。

クライアント選び：OS、アーキテクチャ、コアの要件で選ぶ

デスクトップではv2rayNを優先

まずクライアントのダウンロードページを開き、使用中のOSに対応する項目を選んでから、CPUアーキテクチャとパッケージの種類を確認してください。デスクトップ向けには、Windows、macOS、Linuxで使えるv2rayNをおすすめします。ファイル名に似た文字列があるだけでインストールしたり、あるプラットフォームでの経験を別のプラットフォームにそのまま当てはめたりしないでください。画面の仕組み、権限管理、配布パッケージの形式はOSごとに異なります。適切な配布版を選ぶことで、起動できない、アーキテクチャに対応しない、インストール方法が合わないといった問題を減らせます。

Windowsでは、ダウンロードページからデスクトップ版または従来のWPF版を選べます。デスクトップ版は新世代のクロスプラットフォームUIを採用し、WPF版はWindows向けのデスクトップUIフレームワークを採用しています。選ぶ際は、操作の好みや現在のシステム環境を考慮し、「新しいUIならすべての機能が同じ」とは考えないようにしましょう。メニューの場所、設定の構成、一部の操作方法は異なる場合があります。ガイドを読む際は、同じ設定を画面上の同じ位置で探すのではなく、設定の意味を確認してください。詳しくはデスクトップ版とWPF版の違いをご覧ください。

モバイル端末はアーキテクチャと必要な機能を確認

Androidでは、Xrayコアを使うv2rayNGをまず検討してください。V2Flyコアが必要で、設定との互換性も確認できている場合は、v2flyNGを選択肢に加えます。どちらもサブスクリプションと接続を管理できますが、コアの設定項目を自由に入れ替えられるわけではありません。設定をインポートできない場合は、クライアントとコアがサブスクリプションに対応しているか確認してから、別のアプリが必要か判断しましょう。クライアントを変更しても、期限切れのサブスクリプション、誤ったパスワード、利用できない接続先が直るとは限りません。

CPUアーキテクチャによって、インストールパッケージが動作するかどうかが決まります。比較的新しいAndroid端末ではarm64を選べることが多いものの、実際の対応状況は端末とOSで確認してください。判断できない場合は、ファイルサイズが大きくなる点を踏まえて汎用版を検討できます。macOSでは「このMacについて」でチップの種類を確認し、Apple SiliconまたはIntel用の項目を選びます。Linuxではアーキテクチャに加えて、ディストリビューションのパッケージ形式も確認します。対応するdebまたはrpmパッケージを選び、パッケージ形式の違いをプロキシ機能の違いと混同しないでください。

利用環境も選択基準に含める

クライアントを選んだら、プロキシを必要とするアプリを具体的に洗い出します。ブラウザーだけを接続する場合は、まずシステムプロキシを使えます。システムプロキシを参照しないアプリも対象にするなら、仮想ネットワークインターフェースの使用を検討してください。会社の端末、管理対象端末、ほかのネットワークツールを併用する環境では、ドライバー、ルーティング、権限の変更が制限されている場合があります。端末の管理要件を先に確認し、より広い範囲を接続対象にすることを当然の目標にしないでください。機能を増やすほど、関係するシステムの層が増え、トラブル時に必要な確認事項も増えます。

最後に、移行する設定の範囲を確認します。ノードのリンクやQRコードで渡せるのは通常、リモート接続のパラメーターです。端末側のルーティング、名前解決の方式、ショートカット、画面設定まで含まれるとは限りません。別のOSへ移行するときは、まずリモート設定をインポートし、新しい端末に合わせてローカルの動作を設定し直してください。OS、アーキテクチャ、クライアントの種類、使用するコア、必要な権限を記録しておきましょう。再インストールや端末変更の際に、古いインストールパッケージが再び動くかどうかに頼らず、この記録を基に選び直せます。

インストール準備：起動と終了を確認できる環境を整える

インストール前に既存のネットワーク設定を確認

ダウンロード前にOSのバージョンとアーキテクチャを確認し、十分な空き容量を確保します。すでに別のプロキシ設定がある場合は、システムプロキシのアドレスとポート、仮想ネットワークインターフェースの状態を記録し、関連アプリを終了して複数のツールが同時にネットワークを制御しないようにしてください。使用中の設定フォルダーをそのまま削除しないでください。インストール段階で目指すのは、クライアントとコアを起動できること、ログを開けること、終了後にシステムネットワークが復旧することです。この時点で複雑なルーティングや自動起動を追加する必要はありません。

Windowsでは、ダウンロードページにある対応するインストーラーを使い、セットアップウィザードに従ってインストールします。展開して実行する配布形式を選んだ場合は、圧縮ファイルのプレビューから直接起動せず、まず固定のフォルダーにすべて展開してください。保存場所を固定すると、更新、ログの確認、設定の保存がしやすくなります。一時ファイルとして頻繁に削除される場所に作業フォルダーを置かず、実行中にファイルを手動で移動しないでください。実行環境が不足していると表示されたら、その配布形式の説明に従って依存関係を補います。不明な配布元から不足コンポーネントを個別に探して入手しないでください。

デスクトップとモバイルの権限をそれぞれ設定

macOSでは、チップに対応するインストーラーパッケージを開き、アプリを安定した保存先に移動してから起動します。システムのセキュリティ警告が表示されたら、入手元と現在のOSで認められた手順を確認し、システム設定から許可してください。アプリ1つを動かすために、システム保護全体を無効にしないでください。クライアントは起動するのに主要機能が動かない場合は、アプリの起動権限、ネットワーク権限、仮想ネットワークインターフェースの権限を分けて確認します。ウィンドウが表示されたからといって、すべての権限が許可されたとは限りません。

Linuxでは、ディストリビューションのソフトウェアインストーラーまたはパッケージ管理機能を使って、対応するパッケージをインストールします。まず依存関係に関する表示を確認し、デスクトップ環境でGUIを起動できることを確かめてください。通常モードでは動くのに仮想ネットワークインターフェースが動かない場合は、同じパッケージを何度も再インストールせず、権限やサービス要件を確認します。ログの場所はクライアントの画面、ユーザーフォルダー、システムサービスの管理機構など、インストール形態によって異なります。実際の場所を記録しておくと、更新やトラブル時に原因を調べやすくなります。

Androidでは、システムの案内に従って、現在のダウンロード元からのアプリインストールを許可します。インストール後、ダウンロード元の許可を取り消す必要があるか確認してください。初めて接続するときは、システムからVPN接続の作成を求められるので、説明を確認して必要に応じて許可します。この許可により、アプリはシステムのネットワークインターフェースを使って通信を制御できますが、リモート設定が有効だと確認されたわけではありません。組織で管理されている端末では、インストール元やVPNの権限がポリシーで制限されることがあります。端末の管理要件に従い、インストールを繰り返して制限を回避しないでください。

起動と終了を一度確認する

初回起動時に、ログ、設定、終了の入口を確認します。デスクトップではウィンドウを閉じても、通知領域にプログラムが残る場合があります。停止するときは、明示的な終了コマンドを使ってください。終了前後でシステムプロキシが元に戻ったか、バックグラウンドに接続プロセスが残っていないかを確認します。「ウィンドウを閉じる」ことと「プロキシサービスを終了する」ことは同じではありません。Androidでは、画面を閉じる操作とVPNサービスの停止を区別し、アプリとシステムのネットワーク表示の両方で接続状態を確認します。

続いて、ローカルの待ち受け設定を確認します。初回は既定のポートとローカル端末からのみアクセスできる範囲を維持し、LANからの接続は許可しないでください。ポートが使用中なら、古いインスタンスやほかのアプリが利用していないかを調べてから、競合するプログラムを終了するかポートを変更します。変更した場合、そのポートを明示的に指定しているアプリも合わせて変更してください。クライアントだけを変更し、ブラウザーなど他のアプリのプロキシアドレスを変更しないと、「コアは起動しているのにリクエストが届かない」という典型的な問題が起きます。

サブスクリプションの追加：アドレスの保存から設定の確認まで

サブスクリプションのURLはアクセス情報として扱う

サブスクリプションのURLには、アカウントやアクセス権を識別できる情報が含まれることがあります。機密情報として扱い、URL全体を公開スクリーンショット、オンライン変換サイト、公開の質問投稿に載せないでください。入手元、対応クライアント、有効期限を確認してから端末にコピーします。クライアントはURLから設定を読み込むもので、リモートサービスを提供するものではありません。アプリをインストールしただけで有効な設定がなければ、ノード一覧が空なのは正常です。システムプロキシを変更してノードを「生成」する必要はありません。

v2rayNでは、「サブスクリプショングループ」から「サブスクリプショングループ設定」を開き、見分けやすいグループ名を追加してURLを貼り付け、保存します。グループ名は端末内での管理用で、リモート接続には影響しません。保存後にメイン画面へ戻り、「すべてのサブスクリプションを更新（プロキシを経由しない）」または現在の画面にある同等の更新操作を実行します。保存と取得は別の操作です。保存はURLを記録するだけで、更新によって初めて内容を取得・解析します。完了後、該当グループに設定が追加されたことを確認してください。

利用できるネットワークに合わせて更新方法を選ぶ

初回設定で利用できるプロキシがない場合は、まずプロキシを経由せずに更新します。サブスクリプションサービスへのアクセスに既存のプロキシが必要と明示されている場合は、先に動作確認済みの別の接続を用意してから、プロキシ経由で更新してください。同じ使えない設定のまま更新方法だけを何度も切り替えても、サブスクリプションが復旧するとは限りません。更新に失敗したら、端末のネットワーク、URLが完全か、アカウントが有効か、サービスから返された内容が設定なのかログイン画面・エラーページ・アクセス制限の表示なのかを順に確認します。

v2rayNGでは、メニューから「サブスクリプショングループ設定」を開き、名前とURLを追加して保存します。設定一覧に戻ったら「サブスクリプションを更新」を実行してください。画面によっては全件更新と選択中のグループの更新が分かれているため、選択中のグループを確認します。v2flyNGはメニュー構成が異なる場合がありますが、URLの追加、グループの保存、更新の実行、設定の確認という順序は同じです。インポート後に何も表示されなくても、同じグループをすぐに何度も追加せず、更新結果とログに形式の解析エラーがないか先に確認してください。

URL、取得内容、共有リンクの違いを理解する

サブスクリプションURLは設定を取得する入口です。URLから返される内容は、複数のリンクをエンコードしたものや、クライアントが対応する別形式の場合があります。単体の共有リンクは、1つのリモート設定を表します。この違いを理解しておけば、サブスクリプションURLを単一ノードとしてインポートしたり、定期更新が必要なURL欄に単体リンクを入力したりせずに済みます。Base64は内容のエンコード形式であり、接続プロトコルを示すものでも、認証情報が暗号化されていることを示すものでもありません。共有用QRコードにも、接続に必要な認証情報が含まれる場合があります。

更新に成功したら設定を1つ選んで有効にし、プロトコル、アドレス、セキュリティ関連の項目が揃っているか確認します。一覧を整理するために、サブスクリプションが管理する接続パラメーターをむやみに変更しないでください。次回の更新で変更が上書きされる可能性があります。手動の調整を残す必要がある場合は、別のローカルグループに複製し、変更理由を記録します。サブスクリプションの設定が削除・置換された場合、サーバー側の一覧が変わった可能性もあります。クライアントがデータを消失させたと決めつけないでください。

最後に、一覧に表示されるかだけでなく、実際のリクエストで動作を確認します。有効な設定を選び、コアを起動し、後述するシステムプロキシを有効にして、プロキシ設定の影響を受けると分かっているアプリでアクセス可能なページを開きます。失敗した場合は、サブスクリプションの取得、設定の解析、実際の接続のどの段階で起きたかを記録します。複数の端末で同じサブスクリプションを使うときは、許可される接続数と利用範囲も確認してください。インポートできても、同時接続が認められるとは限りません。

プロキシモード：入口を確認してから適用範囲を広げる

システムプロキシで最初の動作確認を行う

プロキシモードによって、アプリの通信がどのようにコアに入るかが決まります。デスクトップのシステムプロキシは、ローカルのプロキシアドレスをシステムに登録しますが、その設定を参照するアプリだけが使用します。独自のネットワーク設定を使うアプリもあれば、システムプロキシを無視するアプリもあります。そのため、システムプロキシを有効にしてブラウザーは使えるのに、特定のアプリは使えない場合でも、ノードに問題があるとは限りません。まずアプリがどの入口を使うか確認し、アドレスを個別に設定するか、仮想ネットワークインターフェースで通信を取り込むかを判断します。

v2rayNでは、まず有効な設定とコアの動作状態を確認し、「システムプロキシ」から「システムプロキシを自動設定」を選びます。次に、システムプロキシを参照するアプリでリクエストを確認してください。「自動設定」は、ノードの自動選択、すべてのアプリへの自動設定、ルーティングの自動最適化を意味するものではありません。主にシステムへのプロキシ登録を行います。設定に失敗した場合は、システムに登録されたアドレスとクライアントの実際の待ち受けアドレスが一致しているか確認し、特に以前手動でポートを変更していないか調べてください。

設定を解除する操作と現状維持を区別する

「システムプロキシをクリア」は、該当する操作で管理されたシステムプロキシ設定を解除します。「システムプロキシを変更しない」は、クライアントが現在のシステム設定を変更しないという意味です。後者はプロキシを無効にする操作ではありません。システムに登録されている設定は、そのまま残る場合があります。終了後にネットワークの問題が起きたら、システムプロキシが停止済みのローカルポートを指したままになっていないか確認します。通常の直接接続に戻すには、クライアントのウィンドウを閉じるだけでなく、設定を明示的に解除または復元してください。

特定のアプリにプロキシを設定する場合は、クライアントが提供する入口の種類と待ち受けポートを確認し、アプリ側で対応するHTTPまたはSOCKSを選択します。他のガイドに記載されたポート番号をそのまま入力したり、リモートサーバーのアドレスをローカルのプロキシ入口として使ったりしないでください。ドメイン名の解決については、ローカルで先に解決するアプリもあれば、プロキシ側に名前を渡せるアプリもあります。後のルーティングや名前解決に影響するため、アプリ自体の設定を確認してください。

AndroidのVPNサービスとアプリごとの対象範囲を確認

v2rayNGはAndroidのVPNインターフェースを使って、端末内に通信を取り込む入口を作ります。初回接続にはシステムの許可が必要で、接続後の通信先はクライアントのルーティングや関連設定で決まります。システムにVPNの表示が出ても、確認できるのはインターフェースが確立したことだけです。すべての通信がリモート側へ送られるとは限りません。アプリごとの対象設定を有効にしている場合、対象外のアプリはこの経路に入りません。確認時は、対象アプリ、ルーティングルール、有効な設定を併せて確認します。

複数の通信入口が同時に有効にならないようにします。仮想ネットワークインターフェースをテストする際は、同じリクエストがローカルの入口を重複して通る可能性を減らすため、先にシステムプロキシを解除できます。アプリ内プロキシを使っている場合も、後で戻せるよう明示設定を記録しておいてください。「グローバル」という言葉だけでは状況を特定できません。すべてのアプリを対象にする意味の場合もあれば、すべてのルーティング先をプロキシにする意味の場合もあり、異なる層の設定です。問題を説明する際は、入口の方式とルーティングモードを分けて伝えてください。

この章を終えたら、次の3点を説明できるようにします。どのアプリがリクエストを送っているか、リクエストがどのローカル入口に入るか、コアがそのリクエストを受け取っているか。ログに該当する動作がまったくない場合は、まず入口とアプリの設定を確認します。接続記録がある場合は、リモート側とルーティングの確認に進みます。層ごとに範囲を絞れば、あらゆる接続問題をサブスクリプションやノードのせいにせずに済み、後で仮想ネットワークインターフェースを設定する際の比較基準も明確になります。

ルーティングとDNS：マッチ条件と名前解決の経路を揃える

プリセットからルーティングの基準を作る

ルーティングは、コアに入った通信がどの経路で出ていくかを決めます。システムプロキシとは別の設定です。システムプロキシは通信がコアに入るかを決め、ルーティングは入った通信を直接接続、プロキシ、その他の定義済みの送信先のどれに振り分けるかを決めます。v2rayNでは、まず「ルーティング設定」にある「中国本土を除外」などのプリセットを使い、対象範囲を理解してから運用してください。ルールはドメインやアドレスのデータに依存するため、データの更新状況、名前解決の場所、接続先の変化で結果が変わることがあります。プリセット名がすべてのサイトの動作を保証するわけではありません。

多くのルールシステムは上から順に照合されるため、具体的な例外は広い範囲のルールより前に配置します。すべての通信に一致するルールが先にあると、後続のドメインルールが適用されない場合があります。ルールを追加するたびに、「有効」かどうかだけでなく、条件、送信先、配置順を確認してください。クライアントごとに送信先のタグ名が異なる場合があります。設定の一部をコピーする前に実際のタグを確認してください。存在しない送信先を指定すると、設定の読み込みに失敗したり、リクエストが想定どおりに処理されなかったりすることがあります。

ドメインルール、アドレスルール、名前解決の方針を区別する

ドメインルールは、コアがドメイン名を取得できることを前提とします。一方、アドレスルールは接続に使われる宛先アドレスを照合します。アプリがローカルで先に名前を解決し、アドレスだけを送る場合、ドメインルールの適用条件が変わることがあります。通信のスニッフィングで一部の状況では情報を補えますが、すべてのリクエストの本当のドメイン名を復元できるわけではなく、正しい名前解決設定の代わりになる万能な機能でもありません。ルーティング結果が想定と違う場合は、ログでコアが実際に取得した情報を確認してから、ルールが一致しなかった理由を調べます。

以下は、Xrayのルーティング項目で一致条件を示す例です。ルールの構造を理解するためのもので、単体で実行できる完全な設定ではありません。例では、指定したドメインとそのサブドメインを、既存の直接接続用アウトバウンドに送ります。組み込む前に、完全な設定でdirectという名前のアウトバウンドが定義されていることを確認してください。例示用のドメインは構文を説明するためのもので、実際のサービスには使えません。GUIクライアントでは、自動生成された設定ファイル全体を直接上書きせず、ルーティングエディターで同じルールを設定することをおすすめします。

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

AsIsは、ルーティング段階で現在取得できている情報を使って照合するという意味で、システム全体で以後の名前解決を停止するわけではありません。実際に接続を確立する際は、適切な箇所で引き続き名前解決が行われることがあります。他の名前解決方式も、使用するコアのドキュメントを確認して理解してください。名称だけから追加の問い合わせが発生するかどうかを判断できません。名前解決とルーティングは相互に影響します。どちらかを変更したら、ルール編集画面の表示だけでなく、最終的な宛先アドレスと送信先を改めて確認してください。

DNSを個別に切り分ける

名前解決の仕組みを設計する際は、誰が問い合わせるか、問い合わせをどこに送るか、その問い合わせ自体がどの経路を使うかを整理します。直接接続するドメインには、通常、ローカル経路に適したアドレスを返す名前解決方式を使います。プロキシ経由でアクセスするドメインは、想定どおりの経路で名前解決されるか確認してください。暗号化DNSは問い合わせの通信保護方式を変えるだけで、送信先の選択ミスを自動的に直すものではありません。リモートの名前解決サービスへの接続にプロキシが必要な場合は、同じ経路を使ってプロキシサーバー自身の名前を解決する依存関係が生じないようにします。

ブラウザーのセキュアDNS、OSのキャッシュ、アプリ独自のキャッシュによって、確認結果が変わることがあります。ルールを変更したら、既存の接続を閉じ、必要に応じて関連するキャッシュを更新してから、同じ宛先を再テストします。古い接続が以前の経路を使い続けていても、新しいルールが無効とは限りません。特定のアプリだけで問題が起きる場合は、そのアプリがクライアントの名前解決設定を迂回していないか確認してください。詳しくはDNS設定の解説をご覧ください。トラブルシューティングでは、名前解決の結果とルーティングの一致状況を必ず併せて記録してください。

TUNの有効化：権限、ルーティング、競合を確認

仮想ネットワークインターフェースが必要か確認する

TUNは、仮想ネットワークインターフェースを通じてシステムルーティングから渡された通信を受け取り、システムプロキシを参照しない一部のアプリも対象にできます。変更されるのは入口とシステムネットワークの経路です。無効なリモート設定を修復する機能ではなく、すべての通信がプロキシ経由で送信されることを保証するものでもありません。仮想ネットワークインターフェースに入った後も、ルーティング、プロトコルの対応状況、除外ルールに従って処理されます。システムプロキシで正常動作を確認し、対象範囲を広げる必要が本当にある場合に有効化すれば、トラブル時に調べる項目を大幅に減らせます。

有効にする前に現在の設定を保存し、システムのネットワーク設定、クライアントのログ、無効化する操作を確認しておきます。デスクトップでは、OSや配布形態によって管理者権限、補助サービス、ネットワークコンポーネントが必要な場合があります。クライアントの案内に従って必要な操作を行い、日常的な実行環境全体を常に最高権限で動かさないでください。端末の管理ポリシーで仮想ネットワークインターフェースやルーティングの変更が禁止されている場合は、許可された入口方式を使います。権限を繰り返し要求してポリシー上の制限を解決しようとしないでください。

決まった手順で初回有効化を行う

まず通常のプロキシで動作確認済みの設定を有効にし、ネットワークルーティングを変更する他のツールを終了します。システムプロキシはいったん解除し、通信経路を1つに絞ってから、v2rayNで「Tunを有効化」または現在の画面にある同等のスイッチを探します。案内に従って権限を許可し、インターフェースの作成とルーティングの読み込みが成功したかログで確認してください。権限不足、インターフェース作成の失敗、アドレスの競合が発生したら、まず明らかな起動エラーに対処します。すぐにサブスクリプションを変更したり、複数の接続先を切り替えたりしないでください。

インターフェースが作成されたら、通常のWebページ、システムプロキシを参照しないアプリ、LAN内の端末、よく使う業務サービスを順に確認します。外部サイトを1つ見るだけでは、ローカルプリンター、ファイル共有、LANの管理画面への影響を見落とすことがあります。ローカルリソースに接続できない場合は、プライベートアドレスや必要なネットワーク範囲が正しく除外されているか確認し、接続先が実際にその範囲にあるかを調べます。すべてのプライベートアドレスを機械的に除外しないでください。組織内ネットワークは実際の構成に応じた判断が必要です。

ループ、名前解決、複数ネットワークアダプターを個別に確認

仮想ネットワークインターフェースでは、プロキシプログラム自身のリモート接続が入口に戻されてループしないようにする必要があります。クライアントが必要な除外や送信元の指定を処理する場合が多いものの、複数のネットワークアダプター、ネットワーク共有、他のネットワークツールが共存する環境では、経路選択が不安定になることがあります。有効にした直後にすべての接続が切れる、ログに似た接続が繰り返し記録される、コアの負荷が異常に高いといった症状が現れます。その場合は、まず仮想ネットワークインターフェースを無効にして基準状態に戻し、インターフェースの選択とルーティングを1つずつ確認してください。プロキシの層をさらに追加しないでください。

名前解決もよくある問題の箇所です。仮想ネットワークインターフェースによってシステムの問い合わせ先が変わり、既存のセキュアDNS、組織の名前解決サービス、他のVPNと競合する場合があります。IPアドレスでは接続できるのにドメイン名では失敗する場合は、まず名前解決の経路を確認します。大容量ファイルや一部のプロトコルだけで失敗する場合は、経路、パケットサイズ、プロトコルの対応状況も調べてください。検証せずにMTUを下げたり、他人の設定値をそのまま使ったりしないでください。まず既定値を記録し、変更ごとに元へ戻して同じ宛先を再テストできるようにします。

複数のネットワークアダプターがある端末では、ネットワークの切り替えに注意が必要です。Wi-Fiと有線LANの切り替え、スリープからの復帰、ネットワーク共有によって、既定の出口が変わることがあります。切り替え後だけ失敗する場合は、通信の取り込みを停止してから再確立し、新しいインターフェースに合わせてルーティングが復旧したか確認してください。AndroidではシステムのVPNインターフェースを使います。デスクトップ用のドライバーやサービスの操作をそのまま適用せず、システムの許可、アプリごとの対象範囲、他のVPNとの競合を確認します。

日常の保守：更新、バックアップ、段階的な切り分け

元に戻せる手順で更新する

日常の保守では、クライアント、コア、サブスクリプションの3種類の更新を区別します。クライアントの更新は画面や設定管理の機能を変え、コアの更新は設定項目への対応や接続動作に影響することがあります。サブスクリプションの更新ではリモート設定の一覧が変わります。3つを同時に更新してから問題箇所を探すのは避けてください。安全な手順は、まずバックアップを取り、1つの層だけを更新し、決まった宛先で動作確認してから次に進むことです。重要な業務用接続では復旧の時間も確保し、利用直前に環境全体を変更しないでください。

バックアップを取る前に、対象となるデータを確認します。サブスクリプションURLからリモート設定を再取得できても、手動で追加したノード、ローカルルール、名前解決の設定、画面設定まで復元できるとは限りません。クライアントのエクスポートデータには認証情報が含まれることがあります。保護された場所に保管し、公開ストレージやチャットグループに安易に共有しないでください。別のOSで復元する場合は、バックアップ形式とインポート対応状況を確認し、端末上のパス、待ち受けポート、権限に関する設定も調べます。同じバックアップがすべてのプラットフォームで同じように動作するとは限りません。

サブスクリプションを更新するときは手動設定を保護

サブスクリプションを更新する前に、URLがまだ有効かを確認し、現在の有効な設定を記録します。更新後は、グループの内容、有効な設定、接続パラメーターに変更がないか確認してください。サーバー側で削除された項目が一覧から消えたり、クライアントが有効な設定を選び直したりすることがあります。更新に成功しても、実際のアクセスで動作を確認しましょう。長期保存する手動設定は別のグループに入れて、追加元を記録します。サブスクリプション管理の設定と混在させると、更新時に上書きされるおそれがあります。グループ管理の問題を、同じ設定を何度もインポートして解決しようとしないでください。

複数の端末で同じサブスクリプションを使う場合、「リモート設定一覧の共有」と「端末側設定の共有」を分けて管理します。デスクトップとモバイルでルーティングを完全に揃える必要はありません。LANの除外範囲や対象アプリは、端末ごとに設定し直す必要があります。サブスクリプション、QRコード、バックアップの使い分けについては、複数端末の設定を同期する方法をご覧ください。どの方法を使っても、移行後は受信側の端末で入口、名前解決、ルーティングを改めて確認してください。インポート完了の表示だけで判断しないでください。

層ごとにトラブルの情報を整理する

問題が起きたら、まずすべてのアプリで異常があるか、プロキシを無効にすると基本ネットワークが正常かを記録します。基本ネットワークも使えない場合は、端末の接続と上流ネットワークを確認します。システムプロキシを参照するアプリだけが失敗するなら、待ち受け入口を調べてください。コアがリクエストを受信しているのにリモート接続に失敗する場合は、有効な設定とハンドシェイクのログを確認します。特定のドメインやアプリだけで起きる問題なら、ルーティング、名前解決、アプリ独自の設定を重点的に調べます。影響範囲を分類すれば、最初からすべてのプログラムを再インストールせずに済みます。

ログを確認する際は、エラーの前後の情報と発生時刻を残しつつ、アドレス、アカウントを識別する情報、サブスクリプションのパラメーター、認証情報を削除してください。ログにあるタイムアウトは、さまざまな層の原因で発生します。単語1つだけで原因を断定しないでください。「サブスクリプション更新中」「コア起動時」「特定のアプリを開いた後」のように、エラーと操作を対応づけます。質問する際は、OS、クライアントの種類、入口方式、直近の変更を添えると、設定全体を送るより役立ちます。

最後に復旧状態を確認します。仮想ネットワークインターフェースを停止し、残ったシステムプロキシを解除してクライアントを終了したうえで、通常のネットワークが使えるか確かめます。その後、最小限の基準設定から段階的に起動してください。スリープからの復帰やネットワーク切り替え後だけ問題が起きるなら、その条件を記録し、一時的な状態を恒久的な設定ミスと決めつけないでください。必要に応じてトラブルシューティングで似た症状を確認できます。原因、変更内容、再テストの結果を記録しておくと、次に同じ問題が起きたときの対応時間を短縮できます。

上級設定への道筋：検証できる実験で設定を広げる

まず説明できる基準設定を作る

上級設定とは、高度なスイッチをすべて有効にすることではありません。各リクエストの入口、名前解決の場所、一致するルール、最終的な送信先を説明できることが大切です。まず動作する基準設定を整理し、OSとクライアント、有効な設定の入手元、入口方式、ルーティングのプリセット、名前解決の方式を記録します。必須機能と任意の実験は分けてください。基準設定がないまま複雑な設定が一時的に動いても、ネットワークや更新の後に復旧しにくく、新しい設定が何を解決したのかも判断できません。

実験の前に、検証可能な問いを立てます。たとえば、特定のアプリがシステムプロキシを無視するか、特定のドメインが想定した送信先に一致するか、ネットワークを切り替えた後も名前解決できるか、といった問いです。次にテスト対象を固定して変更前の状態を記録し、関連するパラメーターを1つだけ調整します。テストが終わったら既存の接続を閉じてリクエストを再送し、接続の再利用で観察結果が変わらないようにします。結果を安定して再現できない場合は、不確かな現象を説明するためにルールを増やすのではなく、まず実験の範囲を狭めてください。

依存関係に沿ってルールと名前解決を拡張

上級設定の1つ目は、詳細なルーティングです。完全一致のドメイン、ドメインのサフィックス、アドレス範囲の違いを理解し、必要な例外を追加して適用順を確認します。ワイルドカード、正規表現、コア固有のルールはそれぞれ意味が異なる場合があり、他の環境の表現をそのまま貼り付けてはいけません。カスタムルールには目的とテスト対象を記録します。長期間使われていない、説明できない、前のルールと重複するルールは、増やし続けず整理してください。

2つ目は、名前解決の経路を分ける設定です。アプリからの問い合わせ、クライアントによる名前解決、リモート側での名前解決、システムキャッシュをそれぞれ図にして、各段階のネットワーク依存関係を確認します。DNSサービスの名前だけから応答の品質を判断せず、実際の宛先に返されるアドレスと、そのアドレスが最終的な送信経路に適しているかを確認してください。暗号化DNSでは、DNSサービス自体のドメイン名をどのように解決するかも考慮します。予備のDNSアドレスをむやみに増やすより、明確な起動経路を作る方が保守しやすくなります。

設定全体と部分的な設定例を区別する

3つ目は、生成される設定の理解です。まずクライアントの表示機能を使って実際の動作内容を確認し、インバウンド、アウトバウンド、ルーティング、名前解決それぞれの役割と照らし合わせます。GUIクライアントは起動時や保存時に設定ファイルを再生成することがあり、生成後のファイルを直接編集しても変更が保持されない場合があります。カスタム設定が必要な場合は、現在のクライアントの読み込み方法と対応範囲を確認し、基準となる設定全体を保存してください。他の部分を含まない部分的な例を、完全な設定ファイルとしてそのまま実行することはできません。

プロトコルのパラメーターは、実際に必要な設定に沿って学びます。新しい項目を含む設定を扱う場合は、まず必要なコアとクライアントが対応しているか確認し、項目間の依存関係を理解します。使用中のサービスが提供していない認証やセキュリティ設定を、プロトコルの試用を目的に変更しないでください。通信方式、サーバー名、関連するセキュリティ項目はリモート側と一致する必要があり、クライアントだけでは決められません。用語ガイドを読むときは、用語の説明を自分の設定と照らし合わせ、名称だけでなく実際に有効になる条件も確認してください。

チェックリストで毎回の学習を締めくくる

一通りの動作確認では、接続、ルーティング、名前解決、LANへのアクセス、終了後の復旧を確認します。プロキシが必要なアプリが動くことだけでなく、直接接続すべきリソースも想定どおりに使えることを確認してください。初回起動に加え、ネットワーク切り替え、スリープからの復帰、再起動後の状態もテストします。テスト対象は特定の結果を出すことではなく、実際の利用環境から選びます。ネットワーク条件によって動作は変わるため、単一の数値より環境情報を記録する方が有用です。

作業が終わったら、一時的な実験設定を簡潔な保守メモに整理します。設定を追加した理由、反映を確認する方法、異常時に無効にする手順、サービスの更新に合わせて変更が必要な項目を記録してください。普段の接続をすばやく再現するには使い方ガイドへ、クライアントを変更する場合はダウンロードページで対応プラットフォームを確認します。具体的なエラーが起きたら、該当する章とトラブルシューティングを参照してください。設定の適用範囲と元に戻す手順を明確にしておけば、用途が増えても理解、検証、保守しやすい状態を保てます。