V2Ray設定ファイル完全ガイド｜inbounds・outbounds・ルーティング・DNS

JSON構造の概要

設定オブジェクトと接続経路

V2Rayの設定ファイルは、トップレベルにJSONオブジェクトを置きます。inboundsはアプリからの接続を受け付け、outboundsは接続を送信します。ルーティングは接続先のoutboundを選び、DNSは設定の対象となるドメイン名の解決方法を指定します。ポリシーは接続に関する制限や統計機能の一部を設定します。これらのモジュールはファイル内の順に実行されるスクリプトではなく、カーネルが読み込んで構成する実行環境です。設定を理解するには、リクエストがどのinboundに入り、どのルールに一致し、最終的にどのoutboundへ渡されるかを追いましょう。特定のフィールドが存在するかどうかだけを見るのでは不十分です。

GUIクライアントとカーネルは分けて考える必要があります。v2rayN、v2rayNG、v2flyNGはノードの編集、サブスクリプション管理、プロキシの切り替えを行います。実際に接続を確立するのは、その背後で動作するカーネルです。クライアント画面の1つの設定が複数のJSONフィールドを生成することも、OSの設定だけを変更することもあります。システムプロキシの切り替えは通常後者です。設定にHTTP inboundがあるからといって、ブラウザーが自動的にそれを使うとは限りません。まずはローカルのSOCKS inboundと直結outboundで基本構成を作り、接続経路を確認しましょう。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": []
  }
}

型、配列、タグ参照

JSONではフィールドごとに型が決まっています。この例ではポートは数値、スイッチは真偽値、タグとアドレスは文字列です。複数のinboundやoutboundは配列に入れます。文字列にはダブルクォーテーションが必要です。配列の最後の要素に余分なカンマを付けることはできず、標準JSONではコメントも使えません。エディターでファイルを開けても、カーネルが解析できるとは限りません。構文エラーとフィールドの意味の誤りは別の問題です。まず括弧、引用符、型を確認してから、プロトコルが該当する設定に対応しているかを調べると、単純な構文ミスをネットワーク障害と誤認せずに済みます。

タグはモジュール間の参照に使います。ルーティングで指定するoutboundのタグは、outboundオブジェクトのタグと完全に一致させてください。大文字・小文字の違いでも参照に失敗することがあります。タグには「直結」「ブロック」「リモートプロキシ」のように、短く明確で重複しない名前を使うのがおすすめです。配列内の表示順だけでタグの意味を判断しないでください。ルールに一致しない接続は通常、先頭のoutboundを使うため、並び順を変えるだけでもデフォルトの動作が変わることがあります。設定片をコピーするときは、参照先と参照元をセットで確認しましょう。

フィールド	主な役割	主な関連項目
`inbounds`	アプリからの接続を受け付ける	待ち受けアドレス、ポート、認証方式
`outbounds`	直結、プロキシ、ブロック	プロトコル設定、トランスポート設定
`routing`	接続先を選択する	outboundのタグ、ルールの順序
`dns`	カーネルによるドメイン名解決	解決ポリシー、問い合わせ経路
`policy`	接続ポリシーと統計の設定	ユーザーレベル、統計モジュール

設定片の統合と変更の保存

設定を統合するときは、同じトップレベルフィールドを重複させず、1つにまとめてください。outbound配列がすでにある場合は、同名の配列をもう1つ書くのではなく、既存の配列にオブジェクトを追加するか編集します。重複キーの扱いはパーサーによって異なるため、画面上では保存できているように見えても、実際には後の内容だけが読み込まれることがあります。オブジェクト内のフィールドも正しい階層に置きましょう。たとえばトランスポート設定は該当するoutboundに属し、トップレベルのroutingオブジェクトには置きません。任意のフィールドは、まずカーネルのデフォルト値を保ち、必要な動作を実現するものだけを追加してください。ドキュメントにあるパラメーターをすべて記入する必要はありません。

デスクトップでは、一般的なノード管理にv2rayNを使うのがおすすめです。ただし、実行時に生成される一時設定を直接上書きしないでください。ノードの選択、サブスクリプションの更新、サービスの再起動時に、クライアントが設定ファイルを再生成する場合があります。カスタム設定を編集しているのか、クライアントが永続保存する設定を変更しているのか、まず確認しましょう。テスト前に動作する設定を保存し、変更したフィールドと予想される結果を記録してください。テスト後はログで実際の待ち受けポートと選択されたoutboundを確認します。構成が安定してからルーティングとDNSを追加すれば、問題の切り分けが容易になります。

inboundsの設定

待ち受けアドレス、ポート、アプリの接続

inboundは、カーネルがどこで接続を受け付け、どのプロトコルとして扱うかを定義します。一般的なデスクトップ環境では、SOCKSとHTTPがローカル接続の入口としてよく使われます。アプリがこの入口へリクエストを送るか、システムプロキシや仮想ネットワークインターフェースなどの仕組みで転送される必要があります。待ち受けアドレスをループバックにすると、接続できるのは同じ端末からだけです。すべてのネットワークインターフェースで待ち受けると、LAN内の端末から接続できる場合があります。後者にはファイアウォール、認証、ネットワーク境界の検討も必要です。トラブル対処のためだけに待ち受け範囲を広げないでください。特に公共のネットワークや複数人で使う端末では注意が必要です。

ポートはアプリに設定したプロキシポートと一致し、ほかのプログラムに使われていない必要があります。ポートが使用中の場合は、起動ログにバインド失敗として記録されることが一般的です。この場合、ノードを変更しても解決しません。別のプロキシクライアントを終了するか、GUI設定でローカルポートを変更し、アプリ側も新しいポートに合わせてください。SOCKSポートとHTTPポートは、名称を自由に入れ替えられるものではありません。SOCKSハンドシェイクだけを受け付ける入口にHTTPリクエストを送ると、接続の初期段階で失敗し、ブラウザーにはプロキシサーバーのエラーとして表示されることがあります。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "local-http",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

認証、UDP、ドメイン情報

ローカルで1人だけが使う場合は、認証なしのSOCKS inboundがよく使われます。ただし、どの待ち受けアドレスでも認証を無効にしてよいわけではありません。他の端末にも公開する場合は、ポートにアクセスできる端末、必要な認証方式へのクライアントの対応、送信元を制限するシステムファイアウォールをあわせて検討してください。認証は対策の一部であり、適切な待ち受け範囲の代わりにはなりません。HTTP inboundの設定構造はSOCKSとは異なるため、認証フィールドをそのままコピーしないでください。使用するプロトコルとカーネルが対応する形式に合わせて設定し、アプリがハンドシェイクを完了できるか個別に確認しましょう。

SOCKS inboundのUDPスイッチは、その入口が該当するUDPリクエストを処理できることを示すだけで、接続経路全体でUDPを転送できる保証にはなりません。アプリがSOCKSのUDPアソシエーションを使うか、リモートプロトコルとサービスが対応しているか、outboundが許可しているか、ファイアウォールを通過できるかなどが結果に影響します。ブラウザーのシステムプロキシ接続テストでは、すべてのUDP動作を確認できません。Webページは開けても特定のアプリが使えない場合は、TCP接続とUDP通信のどちらが失敗しているかを切り分けてから、接続方法を変更する必要があるか判断してください。すべての問題をノード品質のせいにするのは避けましょう。

ドメイン名をどこで解決するかは、inboundの接続方法にも関係します。アプリがドメイン名をSOCKSの入口へ渡すこともあれば、アプリ側でIPアドレスを解決してから接続することもあります。HTTPプロキシは通常、接続先情報からドメイン名を取得できます。ルーティングがドメイン名ルールに依存している場合、inboundがIPアドレスだけを受け取ると、想定と異なる結果になることがあります。プロトコルのスニッフィングで、一部の判別可能な通信からドメイン名の手がかりを得られますが、すべての通信に使えるわけではありません。有効化すると接続先の選択に影響することもあるため、必要性を確認して使いましょう。ドメイン名ルールへの一致を保証する万能機能ではありません。

v2rayNのTUNモードとシステムプロキシ

v2rayNのTUNモードと通常のローカルinboundは、異なる層の問題を解決します。システムプロキシは、OSの設定に従うアプリにプロキシの入口を提供します。TUNモードは仮想ネットワークインターフェースを通じて、指定されたルーティング範囲の通信を受け取るため、システムプロキシを参照しないアプリにも適しています。仮想NIC、ルーティング、権限が関わるため、inbounds配列にフィールドを追加するだけで実現できるものではありません。クライアントの接続方式や設定の生成方法はプラットフォームによって異なる場合があります。手動でのカーネル設定とクライアントのTUN設定は、それぞれ個別に確認してください。

TUNを切り替える前に、通常のプロキシ経路が動作することを確認し、必要な権限や他のネットワークソフトとの競合を調べてください。通信を制御する主要な方法は一度に1つに絞りましょう。複数の仮想NICやプロキシプロセスが同時にルーティングを書き換えると、通信がループしたり、名前解決の経路が不明確になったりすることがあります。TUNを無効にしてもアクセスに問題が残る場合は、システムプロキシの設定が残っていないか、仮想インターフェースが復旧しているか、アプリがプロキシ設定をキャッシュしていないかを確認してください。ブラウザーとターミナルで接続方法が異なる場合は、システムプロキシが効かないときの切り分けも参照してください。1つのアプリの結果だけで、inbound全体の不具合と判断しないようにしましょう。

outboundsの設定

デフォルトoutboundと接続先

outboundは、リクエストをカーネルの外へ送る方法を定義します。直結outboundは端末から接続先へ直接接続し、ブロックoutboundは一致したリクエストを終了します。プロキシoutboundはリモートサービスに接続し、そのサービスを経由して接続先へアクセスします。outbounds配列には複数のオブジェクトを含められ、どれを使うかはルーティングで決まります。一般的な設定では、特別なルールに一致しない通信をプロキシにするため、プロキシオブジェクトを先頭に置きます。このページの第1章の基本設定では、ローカル接続を確認するため、あえて直結を先頭にしています。例をコピーする前にデフォルトoutboundを確認してください。接続構造のテスト用設定を、リモートプロキシ設定と取り違えないようにしましょう。

リモートアドレス、リモートポート、ユーザーID、トランスポート方式は、ひとまとまりの設定として確認してください。アドレスが正しくてもポートが違えば、サービスに接続できないことがあります。ネットワーク接続が確立しても、ユーザー設定が一致しなければプロトコル段階で拒否される場合があります。ユーザー設定が正しくても、トランスポート層の設定が違えば、想定した接続を確立できません。クライアントに表示されたノード名は別名にすぎず、各フィールドが一致している証拠にはなりません。ノード編集画面でサービス提供元の設定全体を照合し、特にインポート時にトランスポートパス、サービス名、セキュリティ設定が欠落していないか確認してください。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "example.com",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-0000-0000-000000000000",
                "encryption": "none",
                "level": 0
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "example.com"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

VLESSプロトコル、トランスポート、セキュリティ層

VLESSでは、ユーザー設定に例のような暗号化フィールドが使われることがありますが、接続全体にセキュリティ層がないという意味ではありません。プロトコル、トランスポート、トランスポートのセキュリティは、それぞれ別の要素です。プロトコルはプロキシリクエストの表現方法、トランスポートはそのデータを運ぶ接続方式、セキュリティ層は接続の保護方法を決めます。上の例ではフィールドの関係を示すためにTCPとTLSを使っていますが、実際のサービスではありません。サービスが別のトランスポートやセキュリティ方式を使う場合は、その設定に合わせて変更してください。複数方式のフィールドを1つのオブジェクトに詰め込まないでください。

V2Rayのプロトコルは、クライアントのメニューから自由に選べるものではありません。サーバー側の設定と使用中のカーネルが対応している必要があります。VMess、VLESS、Trojan、Shadowsocksでは、認証情報や設定構造が異なります。プロトコルのフィールド名だけを変更しても、別のプロトコルに切り替わるわけではありません。VMessでは端末の時刻などにも注意が必要です。また、プロトコルごとのセキュリティ設計を1つの設定項目だけで説明することはできません。基本的な違いはVMessとVLESSの違いを参照し、実際のノード設定に基づいてクライアントの選択肢を決めてください。

TLSのサービス名は、証明書およびサーバー設定と一致している必要があります。接続先アドレスにはドメイン名もIPアドレスも使えますが、接続先と証明書検証に使う名前は必ずしも同じではありません。ブラウザーで特定のアドレスを開けても、そのアドレスが該当するプロキシプロトコルを提供しているとは限りません。証明書エラーが発生したら、システム時刻、名前、証明書チェーンを確認し、設定の入手元も確認してください。エラー表示を消すために、まず証明書検証を無効にするのは避けましょう。実際の設定ミスを見えなくし、接続の検証機能も弱めてしまいます。

カーネルの互換性と設定の保持

XrayとV2Flyでは設定の考え方を一部共有していますが、すべてのフィールド、トランスポート、拡張機能が共通とは限りません。v2rayNではカーネルを選択できます。v2rayNGとv2flyNGは異なるカーネル体系を対象としています。切り替える前に、ノードが必要とする機能に対応しているか確認してください。未知のフィールド、未対応のプロトコル、起動失敗が発生した場合は、リモートアドレスを何度も変更するのではなく、使用中のカーネルの対応範囲を確認しましょう。各プロジェクトの関係はProject V、V2Fly、Xrayの関係を参照してください。

既存ノードをインポートしたら、まずクライアントが認識した元の設定を維持し、項目ごとに確認してからカスタマイズしてください。トランスポートの種類に応じて、関係のない入力項目を画面上で非表示にするクライアントもあります。非表示だからといって、以前入力した値が最終設定に反映されないとは限りません。生成された設定のoutboundオブジェクトを確認し、値が正しい階層にあるか調べてください。テストごとに変更する設定は1つに絞り、失敗ログと時刻を記録しましょう。プロトコル、トランスポート、カーネルを同時に変更すると、接続が復旧しても、どの変更が有効だったのか分かりにくくなります。

routingの設定

ルールの順序とマッチ条件

ルーティングでは、接続の特徴とoutboundのタグを対応付けます。条件には、接続先ドメイン名、接続先IPアドレス、接続先ポート、ネットワーク種別、inboundタグなどがあります。ルールは通常、順番に評価され、最初に一致したルールで接続先が決まります。そのため、例外を指定する詳細なルールは、範囲の広いルールより前に置いてください。どのルールにも一致しない場合は、通常、先頭のoutboundに接続が渡されます。フィールドを増やすよりも、デフォルトoutboundとルールの順序を理解することが重要です。前方に広範囲のルールがあると、後方の詳細なルールが該当するリクエストを処理できなくなることがあります。

1つのルール内では、通常、異なる種類の条件をすべて満たす必要があります。同じ種類の条件を配列に複数指定した場合は、いずれか1つに一致すれば対象になります。たとえばinboundタグと接続先ドメイン名を両方指定すると、そのinboundが受け取った該当ドメインへのリクエストだけが対象です。どちらか一方に一致すれば動作するわけではありません。複数の目的を1つのオブジェクトに詰め込まず、別々の条件を表す場合はルールを分けてください。ルールの目的を記録しやすくなり、ログからoutboundを変更したルールを特定しやすくなります。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:blocked.example.com"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.com"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

ドメインルールとIPアドレスルールの使い分け

例の完全一致ルールは指定したドメイン名だけに一致し、ドメインルールは対象のドメインとサブドメインに一致します。最初のルールで特定のサブドメインをブロックし、次のルールで同じ親ドメインに一致するほかのリクエストを直結させることで、詳細なルールを優先する例を示しています。各プレフィックスの意味を、一般的な文字列の感覚で判断しないでください。特に正規表現は、範囲が広すぎると無関係なドメインにも一致し、管理も難しくなります。まず完全なドメイン名やドメインのサフィックスを使い、複雑なパターンが本当に必要な場合に限り正規表現を使いましょう。一致するケースと一致しないケースの両方をテストしてください。

プライベートIPアドレスのルールは、ルーティングの判定に実際に渡された接続先IPアドレスにだけ一致します。リクエストがドメイン名で届き、ルーティングで名前解決を行わない場合、プライベートIPのCIDRルールだけでは、そのドメインが最終的に指す社内サービスを判別できないことがあります。対象となる内部ドメインにドメインルールを追加するか、IP判定に使われる名前解決ポリシーを選んでください。また、ドメイン名が複数のアドレスを返す場合や、IPv4とIPv6で結果が異なる場合があります。一度ルールに一致したからといって、すべてのアドレスファミリーや名前解決結果で同じ経路になるとは限りません。

ルーティングのドメイン名ポリシーと、直結outboundのドメイン名ポリシーは、適用される箇所が異なります。ルーティング側のポリシーは、ルール判定時にドメイン名を解決するかを主に制御します。直結outbound側のポリシーは、実際に直結する際のアドレス選択に影響します。両者を混同すると、「解決ポリシーを設定したのにルーティングに一致しない」と誤認することがあります。必要に応じて名前解決する設定では、実行条件と使用中のカーネルの実装も確認し、意図しないDNS問い合わせを避けてください。ドメイン名で正確にルールを表現できる場合は、IPアドレスに一致させるためだけにすべてのリクエストを強制的に名前解決する必要はありません。

ルール用リソースと変更の検証

ルーティング設定によっては、地域別のIPアドレスやドメイン分類のリソースを参照します。これらの参照先となるリソースファイル、リソース名、更新方法がクライアントに用意されている必要があり、JSONに記述するだけで自動的に利用できるわけではありません。リソースがないと起動エラーになったり、分類内容の違いで一致範囲が変わったりすることがあります。このページでは単独で理解しやすいよう、ドメイン名とCIDRを明示しています。外部ルールを追加する場合は、必要なリソースと使用中のカーネルとの互換性を確認し、生成された設定に実際どの参照が含まれるか調べてください。ルールの名称だけで互換性を判断しないようにしましょう。

ルーティングを変更したら、直結される接続先、プロキシ経由になる接続先、ブロックされる接続先をそれぞれ選び、動作を確認しましょう。接続ログに記録されたoutboundタグも確認してください。ブラウザーのキャッシュ、既存の長時間接続、アプリ独自の名前解決によって、変更が反映されていないように見えることがあります。必要に応じて既存の接続を閉じるか、アプリを再起動してください。すべての接続が切れた場合は、最後に追加した広範囲のルールを外し、タグの表記とデフォルトoutboundを確認します。ルールの数は品質を示す指標ではありません。目的を説明でき、テストできる少数のルールのほうが長期的に管理しやすく、別のクライアントにも移行しやすくなります。

dnsの設定

まず名前解決の場所を確認

DNSの問題は、まず名前解決が行われる場所ごとに切り分けましょう。アプリはシステムのリゾルバーを使うことも、独自の方法で名前を解決することもあります。ローカルプロキシがドメイン名を受け取り、カーネル内で解決する場合もあれば、リモートサービスがドメイン名をもとに接続先へ接続する場合もあります。これらの経路は同時に使われることがあります。トップレベルのdnsオブジェクトが制御するのは、カーネルのDNS機能を使う該当リクエストだけです。端末上のすべてのプログラムの名前解決を自動的に制御するわけではありません。「DNSを変更したのにブラウザーの結果が変わらない」としても、直ちに設定が無効とは限りません。まずブラウザーのリクエストが、そのDNS経路を通っているか確認しましょう。

接続先の名前解決と、プロキシサーバーのアドレスの名前解決も分けて考えてください。outboundは最初にリモートサービスのアドレスを取得する必要があります。リモートアドレスがドメイン名なら、起動時や接続時に名前解決が必要になる場合があります。その後、アクセスするWebサイトのドメイン名が別の場所で解決されることもあります。まだ確立していないプロキシ接続を使ってすべてのDNS問い合わせを行おうとすると、起動に必要な依存関係が循環することがあります。名前解決経路を設計するときは、リモートサービスのアドレスをどう解決するか、DNSサーバーへどう接続するか、プロキシが使えないときにも必要な名前解決経路が残るかを明確にしてください。よく知っているサーバー名を選ぶだけでは不十分です。

{
  "dns": {
    "hosts": {
      "service.example.com": "192.0.2.10"
    },
    "servers": [
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

静的マッピング、サーバー、アドレスファミリー

この設定片では、システムのローカルリゾルバーを使う基本構成と、静的ドメインマッピングの形式を示します。例のアドレスはドキュメント用であり、実際のサービス接続先には使えません。実在のWebサイトをテストする場合は、この説明用マッピングを削除してください。静的マッピングは、接続先アドレスが明らかで、名前解決結果を固定する必要がある場合に適しています。頻繁に変わるサービスの名前解決を長期的に置き換える用途には向きません。ドメイン名に対応するアドレスは、地域、負荷、サービスの移転によって変わる場合があります。古いアドレスを固定すると接続に失敗したり、本来のアドレス選択の仕組みを迂回したりすることがあります。

DNSサーバーには、システムの名前解決を使う形式のほか、カーネルが対応する形式も指定できます。方式ごとにプロトコル、ポート、通信経路が異なることがあるため、サーバーアドレスだけでプロキシ経由かどうかを判断しないでください。HTTPSベースの名前解決サービスを設定する場合は、サービスのドメイン名自体をどう名前解決し、接続するかも検討する必要があります。カーネルによっては、ローカルから直接送る問い合わせと、ルーティングの対象にできる問い合わせを区別します。実際の動作は使用中のカーネルのドキュメントで確認してください。まず到達可能だと分かっているシンプルな方式で検証し、その後にドメインごとの振り分けルールを追加すれば、複数の依存関係が同時に失敗するリスクを抑えられます。

アドレスファミリーのポリシーは、問い合わせる、または受け付けるIPアドレスの種類を決めます。ただし、IPv6接続に対応していないネットワークを、設定だけで対応させることはできません。特定のアドレスファミリーだけを使う設定にすると、接続先に該当するレコードがない場合、利用可能なアドレスが得られないこともあります。一部のサイトだけ接続が遅い、名前解決できてもタイムアウトする場合は、得られたアドレスファミリーが端末、リモートサービス、最終的なoutboundの接続性に合っているか確認してください。変更前に名前解決結果を記録し、変更後も同じドメインで再度確認しましょう。一度の接続成功だけで、すべての場面で特定のアドレスファミリーが適切だと決めつけないでください。

ドメイン振り分け、キャッシュ、ルーティングの連携

より複雑なDNS設定では、一部のドメインに使うDNSサーバーを指定し、フォールバックの動作も制御できます。指定サーバーから応答がない場合、空の結果が返された場合、応答がフィルタリングされた場合に、別のサーバーへ問い合わせるかどうかで最終結果やアクセス速度が変わります。カーネルが対応するサーバーオブジェクトのフィールドと、フォールバックの仕組みをあわせて確認してください。「優先して使う」が「それ以外は使わない」という意味とは限りません。アドレス範囲も指定した場合は、正常な結果がその範囲外になる可能性がないか確認してください。範囲外の有効な応答を条件に合わない結果として扱うことがあります。

DNSとルーティングの設定は、目的に合った内容に揃える必要があります。内部ドメインを直結したい場合は、名前解決経路から内部アドレスを取得でき、ルーティングでも該当する名前またはアドレスを認識できるようにしてください。特定の接続をリモートサービス経由にしたい場合も、名前解決を行う場所がそのサービスの動作を妨げないか確認します。DNSサーバーの選択、ルーティングで使うoutbound、ブラウザーのセキュアDNS設定を、同じスイッチと考えないでください。それぞれ異なる層に作用します。トラブル対処では、2つを固定して1つだけ変更し、ログとアプリの動作から結果を確認しましょう。

キャッシュによって、設定変更の結果がすぐに見えないことがあります。キャッシュはブラウザー、OS、カーネル、リモートのリゾルバーなどに存在し、プロセスを1つ再起動してもすべてが消えるとは限りません。検証時は、設定が再読み込みされたことを確認してから既存の接続を閉じ、必要に応じて対象アプリを再起動してください。また、名前解決の失敗、接続タイムアウト、証明書エラーを区別して記録しましょう。1つのアプリだけで問題が起きる場合は、独自の名前解決方式を有効にしていないか確認してください。仮想ネットワークインターフェースを使う環境では、DNSがクライアント側で別に制御されていないかも確認し、実際のリクエストに関与しないトップレベル設定を繰り返し変更しないようにします。

policyの設定と統計

ユーザーレベルと接続時間の制限

policyモジュールは一部の接続動作と統計機能を設定します。リクエストがどのノードを使うかを決める機能ではありません。一般的にはユーザーレベルごとにポリシーを設定し、システム全体の統計オプションを定義します。ユーザーレベルは設定内の参照値であり、アカウント権限、料金プラン、ノード品質の評価ではありません。該当するユーザーオブジェクトがそのレベルに対応し、実際に参照している場合にだけ、関連するポリシーが適用されます。設定にレベルを書いても、それを参照するユーザーがいなければ、すべての接続にそのパラメーターが適用されるわけではありません。

接続の確立、アイドル状態の維持、半閉鎖後の待機は、それぞれ異なる段階です。ハンドシェイクのタイムアウトは接続確立中の待機を制限し、アイドル時間の制限は通信がない接続に適用されます。片方向の接続を閉じた後の待機時間は、反対方向に未完了のデータが残っている場合に使われます。値を短くするとリソースを早く解放できる一方、低速なネットワーク、ロングポーリング、長時間通信のないアプリで切断が頻発することがあります。具体的な症状に基づいて調整してください。すべてのタイムアウトをまとめて短くし、切断が増えた原因をリモートサービスの不安定さと誤認しないようにしましょう。

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5,
        "statsUserUplink": true,
        "statsUserDownlink": true
      }
    },
    "system": {
      "statsInboundUplink": true,
      "statsInboundDownlink": true,
      "statsOutboundUplink": true,
      "statsOutboundDownlink": true
    }
  },
  "stats": {}
}

統計スイッチ、ID、読み取り方法

例の時間フィールドは一般的なカーネルの仕様に合わせて秒単位にしています。数値は構造を説明するためのもので、すべてのネットワークに適した推奨値ではありません。レベルオブジェクトのキーは文字列ですが、ユーザーオブジェクト内のレベルは通常数値であり、設定内の型が異なります。まずはクライアントのデフォルトポリシーを維持し、再現可能なタイムアウトの問題がある場合にだけ変更してください。バッファーや接続管理に関するフィールドは、対応範囲、単位、デフォルト値がカーネルによって異なる場合があります。ネット上の設定一式を汎用的な最適化としてそのまま使わないでください。

統計モジュールを有効にすることと、統計結果を読み取れることは別です。空の統計オブジェクトでモジュールを有効にし、ポリシーのスイッチでどの方向や対象のデータを収集するかを指定できますが、画面に自動でグラフが表示されるわけではありません。結果を読むには、クライアント側の対応機能か、カーネルがサポートする統計インターフェースが必要です。クライアントに表示される速度や通信量は、別の方法で収集されていることもあります。そのため画面にユーザー統計が表示されなくても、統計モジュール全体が無効とは限りません。どの種類のデータを読み取る予定なのか、インターフェースが実際に存在するかを確認しましょう。

ユーザー単位の統計には、ユーザーオブジェクト内で識別可能なIDフィールドとプロトコルの対応も必要です。レベルのスイッチだけでは、期待する統計項目が作られないことがあります。ローカルの通常のSOCKS入口にレベル0を設定しても、自動的にリモート側のユーザーIDが割り当てられるわけではありません。inbound、outbound、ユーザーの統計は観測地点が異なるため、区別せずに合算して実際の通信量と見なさないでください。カプセル化のオーバーヘッド、トランスポート層の違い、複数の接続も比較結果に影響します。統計は傾向の把握や通信元の特定に使い、サーバー側の請求額と直接対応するものとは考えないでください。

統計インターフェースとアクセス範囲

管理インターフェースを手動で設定する場合は、使用中のカーネルのインターフェース仕様とサービス一覧を確認し、待ち受け範囲を必要な範囲に制限してください。入口、対応するルーティング、サービス名は連携して設定する必要があります。ポリシーを追加するだけでは、アクセス可能な管理経路は作られません。統計ツールを接続するためだけに、インターフェースをすべてのネットワークインターフェースで公開しないでください。こうした管理経路を通常のプロキシ入口と混同してはいけません。GUIクライアントが該当インターフェースを管理している場合は、既存の表示機能を優先し、新しい入口が既存のポートと競合しないようにしてください。

ポリシーを変更したら、再現可能な操作で動作を確認しましょう。アイドル時の切断を調べる場合は、アプリが接続してから通信がない時間と切断までの時間を記録します。ハンドシェイク失敗の場合は、リモートポートへの接続後、セキュリティ層またはプロトコルのどの段階まで進んだかを記録してください。該当する段階に問題の証拠がある場合にだけ、関連するポリシーを変更します。実際の原因がDNSの失敗、ブロックへのルーティング、ノード設定の誤りなら、タイムアウトを延ばしてもユーザーを長く待たせるだけで接続は直りません。リソースの異常な消費がある場合も、接続数の発生元と通信のループを先に確認してください。

テスト後は、不要になった診断スイッチを元に戻してください。詳細なログや大量の統計項目を有効にすると、継続的な確認の負担が増え、保存されたデータから利用状況が分かることもあります。設定ガイドに載っているモジュールをすべて常時有効にする必要はありません。安定して使うときは、用途を説明できるオプションだけを残しましょう。モバイル端末では、ポリシーによる接続の解放とOSのバックグラウンド制限を区別してください。アプリがバックグラウンドで停止されている場合、カーネルのアイドル時間を延ばすだけでは解決しません。アプリの権限とバッテリー管理の設定を確認してください。

サブスクリプションとクライアントの設定生成

サブスクリプションの内容は完全な設定ではない

サブスクリプションは主に、クライアントへノード情報を提供します。実際に動作する設定は通常、クライアントが選択中のノード、ローカル入口、ルーティング、DNS、その他の設定を組み合わせて生成します。サブスクリプション形式によって扱える情報の範囲は異なり、ノード情報だけを記述する形式もあれば、より多くの設定構造を含む形式もあります。それらをクライアントが受け入れて保持するかどうかは、インポート方法にも左右されます。サブスクリプションURL、共有リンク、完全なJSONファイルを同じ種類のデータとして扱わないでください。入手した内容の種類を確認してから、サブスクリプション更新、クリップボードからのインポート、カスタム設定のいずれかを選んでください。

v2rayNGでは通常、サブスクリプショングループを作成し、名前とURLを入力して保存した後、更新を実行します。その後、グループ内にノードが表示されたか確認してください。v2rayNのサブスクリプショングループも、同様の考え方で管理します。名前は登録元の識別に使い、URLは実際の内容を取得するために使います。両者は代わりにはなりません。更新が成功しても、ノードを選んで接続を開始する必要があります。サブスクリプションを取得できたからといって、リモートサービスに接続できるとは限りません。また、システムプロキシやモバイル端末のVPN接続が有効になったわけでもありません。それぞれ別に確認してください。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth"
      }
    }
  ],
  "outbounds": [
    {
      "tag": "selected-node",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": [
          "local-socks"
        ],
        "outboundTag": "selected-node"
      }
    ]
  }
}

上のオブジェクトでは、選択中のoutboundの構造を示すために、直結プロトコルを使っています。設定生成の説明用であり、サブスクリプションのデータ形式ではありません。実際のクライアントは、選択したノードを対応するプロキシoutboundに変換し、ローカル設定と組み合わせます。ノード名が変わっても、クライアント内部のoutboundタグは固定の場合があります。設定方式によって異なるタグが生成されることもあります。手書きのルールで一覧上の表示名だけに依存せず、生成後のタグを確認してください。クライアントに共通のプロキシoutbound参照方法がある場合は、そのルールに合わせて設定しましょう。

更新時の注意点とカスタム設定

サブスクリプションを更新すると、クライアントによってノード設定が置き換えられたり、ノードの追加・削除や名前の変更が行われたりします。サブスクリプションのノードを手動で編集した場合、次回の更新で変更が上書きされることがあります。長期的に残したい特殊なノードは、クライアントが対応する方法で別のグループや設定に分け、登録元と変更理由を記録しましょう。更新でローカルのルーティングやDNSも変わるかどうかは、インポート方式によります。ノードだけを更新する場合と、設定全体をインポートする場合を混同しないでください。更新前後の実際の実行設定を確認するのが確実です。

構造を明確に管理したい場合は、完全なカスタム設定が適していますが、クライアントによる自動生成機能の一部を迂回する可能性があります。画面上のノード選択、ルーティングのプリセット、ローカルポートの変更が、カスタム設定に反映されないことがあります。カスタムモードに切り替える前に、inboundを管理するのは誰か、管理インターフェースを誰が担当するか、クライアントが起動時にフィールドを自動追加するか、読み込まれる設定ファイルの場所はどこかを確認してください。完全なカスタム設定を使いながら、通常の画面設定もすべて同期されると期待しないでください。まず設定の管理者を明確にし、その後でカスタマイズを加えましょう。

クライアント	対応プラットフォーム	確認するポイント
v2rayN	Windows、macOS、Linux	カーネルの選択、設定生成、システムプロキシ、TUNの設定
v2rayNG	Android	Xrayの設定対応、サブスクリプション更新、VPN権限
v2flyNG	Android	V2Flyの設定対応、既存ノードとの互換性

移行、プライバシー、クライアントの選び方

別のクライアントへ移行する場合は、まずノードを移し、その後でローカル接続とルーティングを設定し直してください。各クライアントのプリセットに同じ名称の設定があるとは限りません。デスクトップにはv2rayN、Androidではカーネルの要件に応じてv2rayNGまたはv2flyNGがおすすめです。同じノード情報でも、カーネルの対応機能によって利用できる範囲が異なる場合があります。クライアントのダウンロードページで、OSに合ったダウンロード先を選んでください。v2rayNGをダウンロードする場合は、端末のアーキテクチャも確認しましょう。アーキテクチャはアプリをインストールして実行できるかに影響しますが、ノードのプロトコルやルーティング動作を決めるものではありません。

サブスクリプションURLにはアクセス用の認証情報が含まれていることが多く、完全なURLを公開画像、チャット、トラブル報告に載せるのは避けてください。問題を報告するときはエラーの種類、応答ステータス、更新時刻を残し、クエリパラメーターやユーザーIDは隠しましょう。更新失敗は、URLにアクセスできない、取得内容が空、形式に非対応、ノードの解析に失敗した、といった段階に分けて確認します。これらの段階と、プロキシノードへの接続可否は必ずしも一致しません。サブスクリプションの一部のノードだけが表示されない場合は、すぐクライアント全体を再インストールするのではなく、表示されないノードのプロトコルやトランスポートに対応しているか確認してください。

自動更新の間隔も適切に設定しましょう。頻繁に更新すると不要なリクエストが増え、トラブル対処中にテスト対象が次々と変わることがあります。間隔が長すぎると、すでに無効になった設定が残る場合があります。サービスの実際の更新頻度と使い方に合わせてください。短い間隔に設定しても接続品質が上がるわけではありません。トラブル対処を始めるときは、ノードと設定を一時的に固定し、検証後に通常の更新へ戻すとよいでしょう。初回の操作は入門ガイドのサブスクリプション手順に従ってください。この章では主に、更新後にどのモジュールが変わったかを説明します。

設定の検証とトラブル対処

設定の読み込みからアプリの接続まで

接続経路に沿って順に検証します。まず設定の構文が読み込めるか、次にカーネルが起動してローカルポートを待ち受けているか、続いてアプリが実際にその入口を使っているかを確認します。その後、ルーティングの選択、DNSの結果、リモート接続、プロトコルのハンドシェイクを調べ、最後に実際のアプリで動作を確認しましょう。この順序なら問題の段階を絞り込めます。Webページが開けないというだけでは原因を特定できず、クライアントを再インストールしても切り分けにはなりません。最後に成功した段階と最初に失敗した段階が分かれば、次にポート、権限、設定値、ネットワーク経路のどれを調べるべきか判断できます。

変更後は、新しい設定が読み込まれていることを確認してください。クライアントで古いプロセスが動き続けていたり、起動時に別の設定ファイルが再生成されたりする場合があります。エディターに表示された内容と実際の実行状態が一致するとは限りません。設定を保存したら、クライアントの手順に沿ってサービスを再起動し、起動ログで待ち受けアドレス、ポート、使用中のカーネルを確認しましょう。未知のフィールドがログに表示されたら互換性を調べます。アドレスのバインドに失敗した場合はポートを確認してください。起動ログ自体がない場合は、プログラムが正常に起動しているかを確認し、クライアントの起動時クラッシュと権限のトラブル対処を参照してください。

{
  "log": {
    "loglevel": "info"
  }
}

ログ情報と問題の切り分け

ログレベルを一時的にinfoにすると、接続の受け付けからoutboundへの送信まで確認しやすくなります。ただし、ログの内容や詳細度はカーネルとクライアントによって異なります。すべてのルールが共通の形式で一致記録を出すとは限りません。文脈から切り離して、ログの単語だけで判断しないようにしましょう。読み取るときは時系列を保ち、アプリからの接続後にinboundの記録があるか、outboundが選択されたか、名前解決・接続確立・ハンドシェイクのどの段階で失敗したかを確認してください。診断後は普段使いに適したログレベルへ戻し、ログを共有する前に接続先アドレス、サブスクリプションのパラメーター、ユーザーIDなどを伏せてください。

症状	優先して確認	後回しにする項目
起動直後に失敗する	JSON構文、カーネルの対応状況、ポートの使用状況	ノードの速度測定、アプリのキャッシュ
アプリからのinbound記録がない	アプリのプロキシ設定、入口のプロトコルとポート	リモート側のユーザー設定
名前解決に失敗する	実際のDNS経路、サーバーへの接続性	プロトコル名
リモート接続がタイムアウトする	アドレス、ポート、ネットワーク経路、ファイアウォール	統計画面の設定
ハンドシェイクが拒否される	ユーザー設定、トランスポート、セキュリティ層の設定	ローカルポートの表示名
一部の接続先だけ問題がある	ルーティングルール、名前解決結果、アドレスファミリー	すべてのモジュールを一度にリセットする

同じエラーでも原因が複数考えられます。この表は確認の順序を決めるためのもので、症状に原因を1つだけ割り当てるものではありません。リモート接続のタイムアウトは、ネットワークに到達できない場合もあれば、ポートの誤りが原因の場合もあります。ハンドシェイクのエラーは、サービス名の不一致、認証情報の不一致、トランスポート設定の不足などで発生します。見慣れない設定を次々に追加するより、正常に動作する設定と比較するほうが効果的です。比較時は同じ端末、同じネットワーク、同じ接続先を使い、ネットワーク環境の変化を設定変更の効果と取り違えないようにしましょう。

V2Rayノードの速度測定と実際の接続性

V2Rayノードの速度測定には複数の方法があります。ポートの接続テストで分かるのは対象ポートに接続できるかどうかであり、プロキシプロトコルまで確認できるとは限りません。プロキシ経由でテスト用サイトへアクセスすれば、アプリの利用状況に近い結果になりますが、テストサイト、DNS、ルーティングの影響を受けます。ダウンロードテストでは連続転送の状態を確認できますが、通信量も消費します。画面に表示された1つの時間だけで、すべてのアクセス体験を判断することはできません。ノードを比較するときは測定方法と接続先を揃え、実際に使うアプリでも検証してください。1回の順位だけで長期的な設定を決めないようにしましょう。

テストは成功するのにブラウザーで失敗する場合は、両方が同じ入口とルーティングを使っているかを確認してください。ブラウザー拡張機能、プロキシを使わない接続先のリスト、独自の名前解決、既存の接続によって、リクエストの経路が変わることがあります。ターミナルのツールも、独自のプロキシ設定や環境変数を使う場合があります。逆に、ブラウザーで接続できても、すべてのアプリがシステムプロキシに従うとは限りません。動作が異なるアプリごとに接続方法を確認し、カーネルのログにリクエストが記録されているか調べてください。通信を取り込む範囲を広げる必要がある場合は、このページのTUNの章で権限とルーティングへの影響を確認しましょう。

ロールバック、記録、安定運用

テストごとに、関連する設定だけを一組変更し、予想する動作を書き留めてください。たとえば、特定ドメインへの直結ルールを追加した場合に期待するのはoutboundタグの変更であり、すべてのアクセス速度が上がることではありません。名前解決ポリシーを調整した場合に変わるのは、アドレスファミリーや解決経路であり、認証エラーが消えることではありません。予想どおりの結果にならなければ、まず直前の動作する設定に戻し、ルールの前提条件を確認します。変更したフィールド、テスト対象、観察結果を簡潔に記録しておくと、試行を重ねた後でも設定の目的を見失わずに済みます。

安定した設定では、デフォルトoutboundを明確にし、ルールは必要最小限で説明可能なものにとどめ、実際の接続方法に合ったDNSと必要なローカル待ち受け範囲を設定します。説明用の一時マッピング、診断用インターフェース、テスト用パラメーターを削除し、サブスクリプションの更新を再開してください。問題を報告する場合は、クライアント名、OS、カーネルの種類、失敗した段階、機密情報を伏せたログを伝えます。設定全体を公開する必要はありません。詳細を確認するときはこのページの目次から該当するモジュールへ進み、日常的な接続は入門ガイドに沿って行いましょう。構成を保守しやすくし、トラブルのたびに設定全体を作り直す事態を避けられます。