V2Ray総合ガイド：基本概念から高度な設定まで

// FOUNDATION

基本概念：クライアント、コア、ノード、サブスクリプション

まず画面層と実行層を分けて考える

一般に「V2Rayクライアント」と呼ばれるものは、単一のプログラムではなく、グラフィカルインターフェース、プロキシコア、設定ファイル、システムのネットワーク設定を組み合わせたものです。v2rayN、v2rayNG、v2flyNGはサーバー一覧の表示、サブスクリプションの保存、プロキシモードの切り替え、ログの確認を担当します。実際に接続を確立し、プロトコルを解釈して通信を処理するのはコアです。v2rayNはデスクトップ環境の各種コアを管理でき、v2rayNGは主にXrayコアを実行層として使用し、v2flyNGはV2Flyコア向けです。この関係を理解しておけば、「画面のボタンが変わらない」「コアの起動に失敗する」「リモートサーバーに到達できない」を同じ問題として扱わずに済みます。

グラフィカルクライアントは、画面上の選択内容から実行用設定を生成し、ローカルのプロキシポートを起動します。ブラウザーやOSはリクエストをこのローカルポートへ渡し、コアはプロトコル、トランスポート、セキュリティ設定、ルーティング規則に基づいて送信方法を決めます。そのため、1つのノードを利用するには少なくとも4つの条件が関係します。サーバーアドレスを解決できること、ポートへの接続を確立できること、認証パラメーターが一致すること、トランスポートとセキュリティ設定が互いに適合していることです。どれか1つでも一致しなければ、接続タイムアウト、ハンドシェイク失敗、起動後に対象サイトへアクセスできないといった症状が現れます。

ノード、サブスクリプション、プロキシ切り替えは別のもの

ノードは具体的な接続パラメーターのまとまりで、通常はアドレス、ポート、ユーザー識別子、プロトコル、トランスポート、セキュリティ設定を含みます。サブスクリプションは更新可能なデータの入口で、一度に複数のノードやグループ情報を取得できます。クライアントにサブスクリプションを追加しても、設定の取得先を登録しただけです。更新を実行し、使用するサーバーを選び、適切なプロキシモードを有効にして初めて、通信がコアに入ります。インポート後にサーバー一覧が空の場合は、未更新、現在のクライアントが形式を認識できない、更新リクエストが完了していない、といった原因が考えられます。

共有リンクとサブスクリプションリンクも分けて考えましょう。共有リンクは通常1つのノードだけを記述し、一時的なインポートや設定の移行に向いています。サブスクリプションリンクはサーバー群を継続的に管理するためのもので、更新によってノードが追加、削除、変更されることがあります。詳しい形式はサブスクリプションリンクの形式を詳しく解説をご覧ください。長期利用ではサブスクリプショングループを保持し、すべてのノードを関連のないローカル項目へコピーしないでください。以後の更新で古い設定を正しく置き換えられなくなります。

プロトコル、トランスポート、セキュリティは3層の設定

VMess、VLESSなどは主に接続プロトコルと認証フィールドを表します。TCP、WebSocket、gRPCなどはトランスポート層の選択で、TLS、REALITYなどは安全なハンドシェイクや認証を処理します。クライアント画面では同じ編集画面に並んでいても、自由に置き換えられるものではありません。サーバー側のプロトコルがVLESSなら、クライアントの選択欄だけをVMessに変更しても接続できません。トランスポートがWebSocketなら、パスやホストなどのパラメーターも一致させる必要があります。プロトコルの基本的な違いはVMessとVLESSの違いで詳しく確認できます。

// CLIENT AND INSTALL

クライアントを選び、保守しやすくインストールする

名称ではなくプラットフォームで選ぶ

デスクトップではv2rayNを第一候補にします。Windows、macOS、Linuxに対応し、複数のサブスクリプション管理、ルーティング規則の編集、詳細ログの確認、TUNの利用に適しています。Androidではv2rayNGを優先します。サブスクリプションや既存設定がV2Flyコアを前提としている場合は、v2flyNGも選択肢になります。3つのクライアントは役割が完全に同じではないため、複数の端末で画面をそろえる目的だけで、プラットフォームに合わない構成を無理に使うことはおすすめしません。インストールパッケージはダウンロードページにまとめてあり、プロセッサーアーキテクチャーとインストール形式ごとに掲載しています。

インストールパッケージを選ぶ前に、OSの種類とプロセッサーアーキテクチャーを確認してください。Windowsの一般的なデスクトップではx64を選びます。macOSではApple SiliconとIntelを区別します。近年のAndroid端末は通常arm64で、確認できない場合は汎用パッケージを選べます。Linuxではx64とarm64に加え、ディストリビューションに応じてdebまたはrpmを選びます。アーキテクチャーが合わないと起動できない場合があり、インストール形式が合わない場合は通常、システムのパッケージ管理ツールに拒否されます。

インストール先が将来の保守コストを左右する

Windowsのデスクトップ版と従来型WPF版では、使用しているUI技術が異なります。デスクトップ版は複数のデスクトップOSで似た操作方法を使いたい場合に向いています。従来型WPF版は、従来のv2rayNの操作に慣れたWindowsユーザーに適しています。圧縮形式でダウンロードした場合は、書き込み権限のある固定場所へ展開してください。圧縮ファイルのプレビュー画面から直接起動するのは避けます。設定、ログ、一時ファイルを正常に保存する必要があり、パスが頻繁に変わるとショートカットや自動起動も機能しなくなります。

macOSで初めて起動するときは、システムが許可するアプリ起動手順で確認を完了し、プロセッサーに合ったパッケージかどうかも確認してください。Linuxではdebまたはrpmをインストールした後、デスクトップメニューから起動し、トレイまたはメイン画面が表示されることを確認します。Androidでは、インストール後に初めて接続を有効にすると、システムのネットワーク接続確認が表示されます。これはローカル仮想ネットワークの構築に必要な権限です。権限を拒否すると、ノードが正しくても端末の通信を取得できません。

初回起動では3項目だけ確認する

1つ目は、メイン画面が開き、コアの起動エラーが繰り返し表示されていないことです。2つ目は、ログ、サブスクリプション、プロキシモードの入口を確認することです。3つ目は、システム時刻とタイムゾーンが正しいことです。一部プロトコルの認証や安全なハンドシェイクは時刻に依存するため、端末の時刻が大きくずれると、パラメーターが一致しているように見えても接続できないことがあります。初回起動時にDNS、ルーティング、TUN、ポート、コア設定を同時に変更しないでください。失敗したときに原因を特定しにくくなります。

インストール後は、まずローカルのリッスン設定を初期値のままにしておくとよいでしょう。一般的なグラフィカルクライアントはHTTP、SOCKS、混合プロキシのポートを管理しますが、具体的な番号は現在の設定画面で確認してください。別の端末のポート番号をそのまま使う必要はありません。ポートが他のプログラムと競合すると、ログにリッスン失敗やアドレス使用中のメッセージが表示されます。その場合は競合するプログラムを終了するか、クライアントでローカルポートを変更し、そのポートを利用するブラウザー、ターミナル、開発ツールの設定も合わせて変更します。

Windows：「タスク マネージャー」を開き、クライアントのプロセスが実行中であることを確認
macOS：「アクティビティモニタ」を開き、v2rayNを検索
Linux：デスクトップのシステムモニターを使うか、次を実行：
ss -lntp

// SUBSCRIPTION

サブスクリプションのインポート、グループ、更新方針

完全なインポート手順は4つの操作で構成される

サブスクリプション管理の安定した手順は、サブスクリプションURLの追加、更新の実行、サーバー一覧の確認、使用するサーバーの選択です。リンクを編集欄に貼り付けて保存しただけでは、ノードが一覧に書き込まれたとは限りません。v2rayNでは、まず分かりやすいサブスクリプショングループ名を作成し、対象グループを更新します。v2rayNGとv2flyNGでも、サブスクリプション設定にURLを保存した後、手動で更新してください。更新後は通知内容を確認し、リクエスト完了だけでなく、認識可能な設定を取得できたことを確認します。

リンクをコピーするときは、内容全体を保持してください。チャットツールやWebページのレイアウトによってリンクに空白や改行が入り、表示された部分だけをコピーすると一部のパラメーターが失われることがあります。インポート後に空になった場合は、まず元のURLをコピーし直し、先頭、クエリパラメーター、末尾の文字が完全か確認します。余分に見えるエンコード文字を手動で削除してサブスクリプションを「修復」しないでください。必要なデータである可能性があります。

グループで更新範囲を管理する

サブスクリプショングループは、画面上の分類にとどまりません。サーバー項目と取得元の関連付けを作り、更新時にどの古い項目を置き換えるかをクライアントへ伝えます。サブスクリプションの取得元ごとに別のグループを作り、用途や端末範囲が分かる名前を付けることをおすすめします。すべてを「デフォルト」と名付けるのは避けてください。複数の取得元を同じグループに混在させると、更新後にノードの出所を判断しにくくなり、不要な項目を整理する際に使用中の設定まで誤って削除しやすくなります。

手動で追加したサーバーは、ローカル設定グループに入れるか、明確な印を付けてサブスクリプション更新による上書きを避けます。サブスクリプションのノードを一時的に変更する場合は、まず独立した項目として複製してから編集してください。サブスクリプション管理下のノードを直接変更すると、次回更新時にリモート側の内容へ戻ることがあります。クライアントの「更新時に古いサーバーを削除」「ローカルの変更を保持」などの項目は意味が異なるため、有効にする前に、グループ内に保持すべき手動項目があるか確認してください。

更新頻度は変化の必要性に合わせる

サブスクリプションは、頻繁に更新すればよいとは限りません。通常は、ノードに変化があったとき、現在のサーバーが利用できなくなったとき、取得元から設定変更の通知があったときに更新します。自動更新の間隔が短すぎると不要なリクエストが増え、クライアント起動時の準備も長引くことがあります。適度な自動更新間隔を設定し、必要なときだけ手動更新するほうが安定します。モバイル回線では、接続が頻繁に切り替わる間に何度も連続更新しないでください。ネットワーク中断をサブスクリプション無効と誤認するおそれがあります。

更新失敗は、リクエスト失敗と解析失敗を区別します。リクエスト失敗は、タイムアウト、名前解決エラー、接続拒否などとして現れます。現在のネットワーク、システム時刻、サブスクリプションURLへのアクセス可否を確認してください。解析失敗は、内容を取得できたもののクライアントが形式を認識できない状態です。ログインページ、案内文、不互換なデータ構造が返っている可能性があります。この場合、更新ボタンを押し続けても結果は変わりません。ログでレスポンスの種類を確認し、現在のクライアントがその形式に対応しているか確認してください。

速度テストは同じ条件で比較する

クライアントの遅延テスト、接続テスト、ダウンロードテストは同じ指標ではありません。遅延テストは通常、特定の探測方法による往復時間だけを示し、Webページの読み込みや大容量ファイルの転送性能を直接表すものではありません。接続テストは対象へ到達できるかを確認します。実際の使用感は帯域幅、パケットロス、対象サイト、現在のネットワークにも左右されます。したがって、ノードの順位付けは同じネットワーク、同じテスト方法、近い時間帯で行い、異なる端末の数値を直接比較しないでください。

使用するサーバーを選んだら、安定した対象を1〜2件使って確認し、大量のノードを連続して切り替えないでください。頻繁な切り替えはDNSキャッシュ、既存接続、アプリの再試行を重ね、ログも読みにくくします。特定のアプリだけ失敗する場合は、まずプロキシモード、対象ドメイン、失敗時刻を記録し、ログから該当する接続を探します。画面の詳しい位置はv2rayNの画面と機能を確認してください。

サブスクリプションのトラブル記録：
1. グループ名と更新時刻
2. 更新通知またはエラーテキスト
3. 更新後にサーバー項目数が変化したか
4. 現在使用中のサーバー名
5. 使用したプロキシモードとテスト対象

// PROXY MODE

システムプロキシ、アプリプロキシ、通信の取得範囲

ローカルポートは通信がコアへ入る入口

クライアントの起動後、通常は端末上で1つ以上のプロキシポートをリッスンします。HTTPプロキシは標準のシステムプロキシに対応するブラウザーやデスクトップアプリに適しています。SOCKSプロキシは、このプロトコルに対応するソフトウェアへ個別に設定できます。混合ポートは1つのポートで複数の入口に対応します。ポート自体が最終的なノードを決めるわけではなく、リクエストをコアへ渡すだけです。ノードの選択、DNS処理、ルーティング規則は実行設定によって決まります。

プロキシが有効か確認するときは、「コアがリッスンしていること」と「アプリが実際にその入口を向いていること」を同時に確認します。クライアントが実行中でもシステムプロキシが有効でなければ、システム設定に従うアプリは自動的にコアへ入りません。ブラウザーに個別プロキシが設定されている場合は、システムプロキシが無効でも、そのブラウザーがローカルポートを使い続けることがあります。切り分ける前に使用中の取得方式を明確にし、システム設定、ブラウザー拡張機能、アプリ内プロキシを同時に有効にしないでください。

システムプロキシは一般的なデスクトップアプリ向け

システムプロキシを有効にすると、クライアントがOSのプロキシ設定を変更し、システムプロキシに対応するアプリがHTTPまたはHTTPSリクエストをローカルポートへ渡します。設定が簡単で、ブラウザー、一部の通信アプリ、一般的なデスクトップツールに適しています。一方、システムプロキシを読み取らないプログラム、独自ネットワークスタックを使うアプリ、一部のコマンドラインツール、特定のUDP通信はこの入口を通らない場合があります。

クライアントを終了する前に、通常の終了操作を行うか、システムプロキシを先に解除してください。プログラムが異常終了すると、システムにローカルポートを指す設定だけが残り、ポートをリッスンするプロセスがないためブラウザーが突然アクセスできなくなることがあります。その場合はまずシステムプロキシがループバックアドレスを指しているか確認し、設定を解除するかクライアントを再起動します。ノードを何度も切り替えても、存在しないローカルポートの問題は解決しません。

アプリ内プロキシで細かく制御する

開発ツール、ターミナル、ブラウザーの一部では、プロキシを個別に指定できます。アプリ内設定は対象範囲が明確で、他のソフトウェアへ影響しない点がメリットです。一方、各プログラムでアドレスとポートを管理する必要があります。プロキシアドレスには通常 127.0.0.1 を入力し、ポートはクライアントの現在の設定画面に表示される値と一致させます。アプリがコンテナ、仮想マシン、別の端末で動作している場合、ループバックアドレスはそのアプリ自身のネットワーク環境を指すため、ホスト側を直接意味するわけではありません。

コマンドラインで検証するときは、ローカルプロキシを明示的に指定して、「プロキシ経路に問題がある」のか「システムプロキシをプログラムが読み取っていない」のかを切り分けられます。次のコマンドは例示用サイトを使い、指定した入口からHTTPリクエストを送信できるかだけを確認します。ポート番号はクライアントに実際に表示されているローカルポートへ置き換え、他の端末の設定をそのまま写さないでください。

curl --proxy http://127.0.0.1:ローカルポート https://example.com/

コマンドに説明用の文字列を含めたくない場合は、先にクライアントの設定画面でポートを確認し、実際の数字を使って実行してください。正常なWebレスポンスが返れば、ローカルHTTPプロキシと使用中のノードは基本的に利用可能です。ローカルアドレスへ接続できないと表示される場合は、コアがそのポートをリッスンしていないか、ポートの入力が間違っています。接続後に長時間応答がない場合は、ノード、ルーティング、DNSのログを確認します。

// ROUTING

ルーティング：条件、順序、デフォルト出口

ルーティングは出口を決めるもので、ノードを修復するものではない

ルーティングの役割は、ドメイン、IP、ポート、ネットワーク種別などの条件に基づき、接続をプロキシ、ダイレクト、ブロックの各出口へ渡すことです。これは基本接続が利用可能であることを前提とします。使用中のノード自体に接続できない場合、規則を増やしても経路は復旧しません。DNSが異常な結果を返す場合も、ドメイン規則が想定どおり適用されないことがあります。ルーティングを設定する前に、まずシンプルなモードでノードを確認し、その後少しずつ規則を追加してください。

一般的なルールセットには domain、ip、port、network、protocol などのフィールドがあります。ドメイン規則はサイト分類に、IP規則は明確なアドレス範囲の指定に、ポート規則はサービス種別の限定に適しています。ネットワーク規則ではTCPとUDPを区別できます。規則の outboundTag は既存の出口タグを参照するため、タグの表記が一致しないと、条件が正しくても期待した結果になりません。

ルールの順序は具体的なものから一般的なものへ

ルーティングは通常、リストの順番に判定され、最初に一致した規則が実行されます。そのため、具体的な例外規則は、広範囲の規則より前に置きます。たとえば、あるサブドメインをプロキシ経由にし、所属ドメイン全体をダイレクトにする場合は、サブドメインの規則を先に置きます。「すべてのドメイン」や「すべてのIP」のような包括条件を先頭に置くと、後続の規則が適用されません。編集後は上から下まで読み直し、各規則の範囲が次の規則を先に取り込んでいないか確認してください。

domain: プレフィックスは指定したドメインとそのサブドメインに一致し、full: は完全一致のみ、keyword: はキーワードで、regexp: は正規表現で照合します。一般的な設定では、明確なドメイン指定や適切に管理されたgeosite分類を優先し、通常の規則で表現できない場合だけ正規表現を検討します。範囲の広すぎる正規表現は意図しない一致を生み、保守コストも増やします。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:service.example.com",
          "domain:example.net"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "udp",
        "port": "53",
        "outboundTag": "dns-out"
      }
    ]
  }
}

上の断片はフィールド構造を示すもので、サーバーの認証情報は含みません。1つ目は2つの例示ドメインをプロキシ出口へ渡します。2つ目はプライベートアドレスをダイレクトにし、LAN機器へのアクセスが迂回しないようにします。3つ目はUDPのDNSリクエストを専用出口へ渡します。実際に使う際は、実行設定に proxy、direct、dns-out のタグが存在することを確認してください。クライアントが画面からタグを生成する場合は、生成結果を優先します。

ドメイン戦略はIPルールの適用タイミングに影響する

domainStrategy は、ドメインリクエストを受けたときにルーティングがIPを解決するかどうかを制御します。AsIs では主に元のドメインで照合し、IP規則のためだけに解決することはありません。IPIfNonMatch ではドメイン規則に一致しなかった場合にアドレスを解決し、IP規則の照合を続けます。IPOnDemand では、IP照合が必要になる可能性があるときに、より早く解決します。戦略を選ぶ際はDNS設定と組み合わせて考え、戦略名を接続速度のモードと解釈しないでください。

ドメインを中心に規則を作る場合は、まずドメイン情報をルーティング層まで保持できることを確認します。geoip分類を多用する場合は、DNS結果が安定し、解決経路が想定どおりであることを確認してください。アプリによってはIPへ直接接続し、照合できるドメインを送らないことがあります。その場合、geositeや通常のドメイン規則は機能せず、IP規則など別の識別方法が必要です。一方、コンテンツ配信ネットワークのアドレスは変化するため、単一のパブリックIPを長期的に手書きする方法には向きません。

推測ではなくログで一致を確認する

ルーティングのトラブルシューティングでは、対象ドメイン、アクセス時刻、最終出口、適用された規則を記録します。クライアントのログレベルが低すぎると、接続の成功または失敗だけが表示され、ルーティングの判断が分からない場合があります。デバッグ中だけログの詳細度を一時的に上げ、完了後は通常レベルへ戻してください。対象が想定した規則に一致しない場合は、規則の順序、ドメインの書式、出口タグ、DNS戦略を順番に確認します。

カスタムルールは段階的に追加します。まず範囲を明確にしたドメイン規則を1つ作って検証し、その後に分類規則とフォールバック規則を追加します。変更するたびに設定を再読み込みし、ログに解析エラーがないことを確認してください。構文と優先順位の例はV2Rayカスタムルーティング規則の書き方で確認できます。設定が長くなったら、各規則の目的をメモし、不要になった例外を定期的に削除します。

// TUN MODE

TUNモード：完全な通信取得、DNS、除外項目

TUNが解決するのは通信の取得範囲

TUNは仮想ネットワークインターフェースを作成し、システムプロキシ設定を読み取らないアプリの通信もクライアントへ入れられるようにします。UDP、コマンドラインプログラム、独自ネットワークスタックのアプリを扱う場合や、ルーティング規則を一元的に適用したい場合に適しています。TUNは高速なプロキシモードではなく、ノードの品質を自動的に改善するものでもありません。変わるのは通信がコアへ入る経路です。基本的なノード、サブスクリプション、ルーティング設定の考え方は従来どおりです。

TUNを有効にする前に、まずシステムプロキシで使用中のノードが利用できることを確認してください。システムプロキシでも接続できない状態でTUNを有効にすると、仮想インターフェース、DNS、ルーティングテーブルという3つの変数が増えるだけです。正しい順序は、クライアントとコアの正常動作、ノード接続、基本ルールを確認し、最後にTUNを有効にすることです。問題が起きても、権限、仮想インターフェース、取得規則のどこに原因があるか絞り込めます。

権限とシステムネットワーク機能を準備する

仮想インターフェースの作成、ルートの変更、DNSの処理には、通常追加のシステム権限が必要です。Windowsではクライアントの案内に従って権限確認を完了し、macOSでは対応するネットワークコンポーネントを許可してください。Linuxでは、現在の起動方法でネットワークインターフェースを管理できることを確認します。Androidクライアントは、システムが提供するネットワーク接続インターフェースでローカルチャネルを作成し、初回有効化時にユーザーの確認を求めます。権限の手順が完了していない場合、画面には一時的に起動中と表示されても、ログではインターフェース作成失敗が報告されることがあります。

他の仮想ネットワークソフト、企業ネットワークコンポーネント、セキュリティツールを同時に動かすと、複数のプログラムがルーティングテーブルを変更することがあります。LANへ接続できない、DNSリクエストの経路が異常になる、ネットワーク切り替え後に接続が切れるといった症状が現れます。切り分けるときは、まず通信を取得するツールを1つだけ残し、TUN単独で正常に動作することを確認してから、他のコンポーネントを1つずつ戻してください。複数のプログラムでデフォルトルートの取得を同時に有効にしないでください。

DNSはルーティング戦略と一緒に設計する

TUNモードでは、DNS解決は対象IPを決めるだけでなく、ドメイン規則が十分な情報を得られるかどうかにも影響します。クライアントには、DNSハイジャック、仮想アドレスマッピング、リモートDNS、ローカルDNSなどの設定が用意されている場合があります。目的は選択肢を増やすことではなく、問い合わせが想定した経路に入り、結果がリクエスト元のアプリへ戻り、ルーティング層に正しいドメインの関連情報が残ることです。IPではアクセスできるのにドメインで失敗する場合は、すぐにプロトコルを変えず、まずDNSを確認します。

LAN名、プリンター、ルーターの管理ドメインは、通常ローカルDNSに依存します。すべての問い合わせをリモートDNSへ送ると、これらの名前を解決できないことがあります。プライベートアドレス、LANドメイン、システムに必要な名前解決にはダイレクト経路を残し、それ以外の問い合わせを規則に従って処理できます。仮想アドレス機能を使う場合は、対象アドレス範囲を現在のクライアントだけが管理し、会社のネットワーク、コンテナネットワーク、既存の仮想ネットワークと重複しないようにしてください。

除外項目でローカルリソースを保護する

一般的な除外対象には、ループバックアドレス、プライベートネットワークアドレス、LAN機器、プロキシ経路へ入れるべきでないシステムサービスがあります。除外規則はできるだけ正確にしてください。アプリ全体を除外する方法は簡単ですが、そのアプリのすべての接続がルーティングを迂回します。アドレス範囲を広く除外すると、本来一致すべき対象までダイレクト接続になることがあります。変更前に保護する対象を明確にし、アプリ、アドレス、ドメインのどの単位で除外するかを選びます。

モバイル端末ではアプリ単位のプロキシにも注意が必要です。指定したアプリだけを選ぶ方式では、選択していないソフトウェアはチャネルへ入りません。除外方式では、一覧にあるアプリがダイレクト接続になります。意味が逆なので、設定を移行した後は必ず確認してください。デスクトップで仮想マシンやコンテナからホストのプロキシへ接続する場合は、ネットワーク境界と転送設定も関係します。リッスンアドレスをすべてのインターフェースへ無条件に公開しないでください。

WindowsのDNSキャッシュを更新：
ipconfig /flushdns

Linuxでルーティングを確認：
ip route

macOSでデフォルトルートを確認：
route -n get default

// MAINTENANCE

日常メンテナンス、ログの読み方、障害の切り分け

保守対象はプログラム、設定、実行状態に分ける

クライアントの保守では、インストールパッケージの更新だけに注目しないでください。プログラムファイルは画面と機能を決め、設定データにはサブスクリプション、サーバー、ルーティング、各種設定が保存されます。実行状態には使用中のノード、システムプロキシ、TUN、ログ、ネットワークインターフェースが含まれます。プログラムをアップグレードしても壊れたサブスクリプションは自動修復されず、サブスクリプションを再インポートしてもポート競合は解決しません。問題に対処する前にどの層に属するか判断すると、不要な操作を減らせます。

設定のバックアップには、少なくともサブスクリプションURL、カスタムルーティング、DNS設定、手動ノードを含めます。バックアップファイルはインストールパッケージとは別に保存し、対象クライアントも記録してください。v2rayN、v2rayNG、v2flyNGでは設定の構成方法が異なるため、データディレクトリ全体を直接上書きしてはいけません。復元時は対象プラットフォームに合ったクライアントをインストールし、クライアントが提供するインポート方法で認識可能な内容を戻します。最後にローカルパス、ポート、権限を確認してください。

ログは時刻と段階を意識して読む

有効なログ分析は、再現した時刻の確認から始まります。古いログを消去または目印を付け、サブスクリプション更新、コア起動、対象へのアクセスなど、明確な操作を1回実行して、直後に追加された記録を確認します。数千行の履歴から「error」を無作為に検索しないでください。以前のエラーはすでに解決している可能性があります。操作が行われた正確な時刻を記録すれば、画面上の動作とコアの出力を対応させられます。

起動段階では設定解析、ポートのリッスン、コアプロセスを確認します。接続段階ではDNS、ルーティング出口、ハンドシェイク、タイムアウトを確認します。実行段階ではネットワーク切り替え、インターフェースの終了、再試行の繰り返しを確認します。接続拒否は、対象ポートが明確に拒否したか、ローカルポートが存在しないことを示す場合があります。タイムアウトは、制限時間内に応答がなかったことを示します。名前解決失敗はDNSを、設定解析失敗はコアがまだ接続段階に入っていないことを示します。これらのエラーを同じ方法で処理してはいけません。

有効な障害記録には次の内容を含める：
- OSとクライアント名
- 現在の取得方式：システムプロキシ、アプリプロキシ、TUN
- 問題が発生した時刻
- 使用中のサーバーとサブスクリプショングループ
- 問題を再現できる対象
- 該当時間帯のログテキスト
- 直近に変更した設定

最小構成で変数を切り分ける

複雑な設定で異常が起きたら、まず最小限の経路を作ります。既知の利用可能なサーバーを1つ残し、TUNを無効にしてシステムプロキシを使い、カスタムルーティングと追加のDNS規則を停止します。最小経路で復旧したら、DNS、ルーティング、TUN、アプリの除外項目の順に1つずつ戻し、毎回1種類の設定だけを変更します。これにより、どの層で障害が発生したか明確になります。

最小経路でも失敗する場合は、ローカルポート、システム時刻、現在のネットワーク、サーバーパラメーターを引き続き確認します。別のネットワークへ切り替えるのは、問題が現在の接続環境に関係するか判断するための切り分け手段です。ログ分析の代わりにはなりません。同じ設定が異なるネットワークでも失敗するなら、ノードパラメーターとコア出力に戻ります。特定のネットワークだけで失敗するなら、DNS、ルーティング、ネットワークの認証ページ、そのネットワークが長時間接続をどう扱うかを確認します。

更新とロールバックは検証可能にする

クライアントを更新する前に、使用中のモード、アクティブなグループ、重要なカスタム設定など、現在利用できている状態を記録します。更新後は、プログラムが起動すること、サブスクリプションを読み込めること、ノードへ接続できることを確認してから高度な機能を戻します。アップグレード後に問題が起きた場合は、設定移行の失敗と動作の変化を区別してください。古いフォルダーを直接上書きすると不要になったファイルが残る可能性があり、完全に消去するとサブスクリプションや規則を失うおそれがあります。元のフォルダーをコピーとして保管し、別の場所で検証する方法がより安全です。

ロールバック時にサブスクリプション内容とクライアントプログラムを同時に戻さないでください。どちらが機能を復旧させたのか分からなくなります。まずプログラムだけを戻し、同じ設定でテストします。それでも問題があれば設定の変更を確認します。日常的に古いサーバー、重複グループ、不要になったルーティング例外も整理してください。設定が簡潔であるほど、更新後の動作を検証しやすくなります。

// ADVANCED PATH

上級テクニック：使える設定から説明できる設定へ

上級者向け設定の基準は項目数ではない

安定した設定の要点は、すべての項目に明確な目的があり、どの層へ影響するか説明できることです。サブスクリプションをインポートしてプロキシを有効にするのは出発点にすぎません。ある通信がなぜプロキシ経由になるのか、なぜダイレクトになるのか、DNSはどこで解決されるのか、TUNはどのアプリを取得するのかを説明できて初めて、保守可能なシステムになります。上級設定を一度にすべて有効にするのではなく、実際の目的に沿って機能を1つずつ追加し、検証方法を残してください。

学習の道筋は4つの層に分けるとよいでしょう。第1層はクライアント操作で、サブスクリプション、使用中のサーバー、ログ、システムプロキシを扱います。第2層は接続構造で、プロトコル、トランスポート、セキュリティパラメーター、コアの関係を理解します。第3層は通信制御で、ドメイン戦略、出口タグ、DNS、TUNを扱います。第4層は保守で、設定のバックアップ、障害の切り分け、変更の評価、安全なロールバックを行います。前の層が安定していないうちは、次へ急がないでください。

自分の設定ベースラインを作る

設定ベースラインとは、動作確認済みで、できるだけ少ない項目からなる設定です。1つのサブスクリプショングループ、1つの使用中サーバー、初期ローカルポート、基本的なシステムプロキシ、必要最小限の規則を含めます。新しい設定を追加する前にベースラインを複製し、変更目的と検証結果を記録します。問題が起きたらすぐにベースラインへ戻し、原因が追加設定にあるのか外部ネットワークの変化にあるのかを判断できます。

ベースラインにはプラットフォームごとの差異も記録します。同じサブスクリプションでも、v2rayN、v2rayNG、v2flyNGでは画面上の位置、DNSの実装、ルーティング生成方法が異なる場合があります。3台の端末ですべての項目を完全に一致させる必要はありません。「LANはダイレクト」「指定した用途はプロキシ」「未一致はデフォルト出口」といった目的の動作をそろえることが重要で、画面上の項目順をそろえることではありません。

ルールを確認可能な判断表にする

規則が増えたら、まずテキストで判断表を作り、それをクライアント設定へ変換するとよいでしょう。各行には少なくとも、対象、条件、想定出口、検証方法を含めます。たとえば「プライベートアドレス—geoip:private—direct—ルーター管理画面へアクセス」「指定ドメイン—domain規則—proxy—ルーティングログを確認」のように記述します。この方法なら規則の重複を見つけやすく、クライアントを変更した後も再現しやすくなります。

デフォルト出口を明確にします。具体的な規則に一致しなかった通信を最終的にどこへ送るかは、ルーティング設計で最も重要な境界です。デフォルト出口をプロキシにするなら、先にダイレクトにすべきローカルリソースを明確にします。ダイレクトをデフォルトにするなら、プロキシへ入れる対象を明確にします。自分の記憶だけで規則順序を管理せず、設定構造そのものに優先順位を表現させてください。

設定変更の記録例：

目的：LANリソースをダイレクト接続にする
一致条件：geoip:private
出口：direct
位置：具体的な用途規則の後、パブリック通信のフォールバック規則の前
検証：ローカルゲートウェイとLAN機器へアクセス
ロールバック：この規則を無効にして設定を再読み込み

DNSとネットワーク観測ツールを段階的に学ぶ

上級段階では、基本的な名前解決とポート確認の方法を身につけることをおすすめします。nslookup や dig で、どのリゾルバーがドメインの結果を返したか確認できます。ipconfig、ip route、route などではインターフェースとルーティングを確認でき、ss ではローカルのリッスンポートを確認できます。これらのツールはクライアントログの代わりではなく、OS側からクライアントが構築したとする状態が実際に存在するかを検証するために使います。

観測結果は前後関係と合わせて判断してください。ドメインを解決できてもプロキシ接続の成功を意味せず、ポートがリッスン中でもリモートノードが利用できるとは限りません。TUNインターフェースが存在しても、すべてのアプリが取得されているとは限りません。各ツールが答えるのは1つの問いだけです。問題を分けて検証すれば、1つの正常な結果を見て早々に調査を終えることを避けられます。

長期的な保守サイクルを作る

完全なサイクルは、「現在の状態を記録する—1つの変更を提案する—検証する—保持またはロールバックする」で構成されます。サブスクリプションの更新、コア設定の切り替え、ルーティングの追加、TUNの有効化はすべてこの流れに従ってください。変更に成功したら最終結果を記録し、失敗したらベースラインへ戻してエラーログを残します。記録が蓄積されると、よくある問題は試行錯誤の繰り返しから再利用可能な判断手順へ変わっていきます。

クライアントの選択も定期的に見直せます。デスクトップではv2rayNを主な管理ツールとし、Androidではコアと設定の要件に応じてv2rayNGまたはv2flyNGを選びます。3つの違いはv2rayN・v2rayNG・v2flyNGの比較で確認できます。選ぶ基準はプラットフォーム、設定の互換性、保守のしやすさであり、画面上の項目数ではありません。

このガイドを読み終えたら、クイックスタートガイドに戻って基本手順をもう一度実行し、各ステップの目的を説明できるか確認してください。クライアントを変更または追加する場合はダウンロードページでプラットフォームに合うパッケージを選びます。具体的なエラーがある場合はよくある質問で症状から検索してください。最終的な目標は、決して変わらない設定を保存することではなく、検証、調整、復元ができる運用方法を身につけることです。