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

01 / STRUCTURE

JSON構造と設定の適用範囲

実際に読み込まれているファイルを確認する

設定ファイルでは、コアが接続を受け付ける方法や出口の選択、ドメイン名の解決方法を指定します。ただし、クライアントの設定すべてをまとめたものではありません。v2rayNのサブスクリプショングループや画面表示の設定、システムプロキシの項目はクライアントが管理し、コアは通常、クライアントが生成した実行用設定を読み込みます。問題を調べる前に、現在選択されているコア、実行ディレクトリ、ログに記録された設定ファイルのパスを確認してください。ディスク上にconfig.jsonが複数ある場合もあります。読み込まれていないファイルを編集しても、接続動作は変わりません。

JSONの最上位は通常オブジェクトで、各モジュールはキーで区別します。inboundsとoutboundsは配列です。1つのプロセスで複数のローカル接続を受け付けたり、複数の出口を持ったりできるためです。一方、routing、dns、policyはオブジェクトです。画面上の項目の並びだけを見て、JSONの階層を推測しないでください。項目名が正しくても階層が違えば無視されたり、コアの読み込みに失敗したりすることがあります。

最小構成でモジュールの関係をつかむ

以下は、ローカルのSOCKS inboundsから直接接続する基本設定です。リモートプロキシサーバーは含みません。ローカルでの待ち受け、リクエストの受信、直接接続のoutboundが一連の流れとして動くことを確認するための例です。アプリがこのSOCKS接続先を使って初めて、通信がコアに渡されます。2つのtagは設定内で使う名前なので自由に付けられますが、参照箇所も合わせて変更してください。tagはプロトコル名とは異なり、対応する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": {}
    }
  ]
}

設定を読むときは、まずリクエストの流れを追います。アプリがローカルの待ち受け先に接続し、inboundsがSOCKSリクエストを処理し、ルーティングが出口を選び、outboundsが接続先への通信を開始します。ルーティングルールがなければ、通常は先頭のoutboundがデフォルトの出口になります。outboundを追加しただけでは通信は自動的に振り分けられません。ルールなどで明示的に参照する必要があります。多くの項目を暗記するより、この基本の流れを理解すると実際の動作を把握しやすくなります。

構文の正しさと設定の意味を分けて考える

標準JSONではコメント、末尾のカンマ、シングルクォートで囲んだ文字列は使えません。ポート番号は数値で、真偽値はtrueまたはfalseで記述します。引用符付きの文字列で代用することはできません。文字列内のバックスラッシュはエスケープ文字として扱われるため、パスや正規表現を手入力するときは特に注意が必要です。エディターで整形できても、テキストの構造が整っていることしか確認できません。その項目をプロトコルがサポートしているか、リモート側の設定と一致しているかは別途確認してください。

以降のコード例の多くは、最上位モジュールの一部を示したものです。項目同士の関係を説明するための例であり、すべて単独で起動できるわけではありません。例を取り込むときは、既存の同名モジュールを置き換え、同じオブジェクト内に重複したキーを追加しないでください。重複キーの扱いはパーサーによって異なる場合があり、「ファイルは変更したのに動作が変わらない」という誤解につながります。配列内のカンマや括弧も正しく保ち、あるoutboundの設定に別のoutboundを誤って入れないようにしてください。

互換性はクライアント名だけでなく、実際に使っているコアを基準に確認してください。同じクライアントでもコアを切り替えられ、配布パッケージによって対応機能が異なることもあります。項目を調べる際は、モジュール、項目のパス、値の型、対応コアを記録しておきましょう。未知の項目があれば、まず設定の範囲を絞ってください。ネットで見つけたスイッチを次々に追加して試すのは避けましょう。再現可能なリクエストを1つ用意し、inbounds、ルーティング、outboundsの順に確認すると、違いを特定しやすくなります。

02 / INBOUNDS

inbounds：待ち受けアドレスと受け付けるプロトコル

待ち受け範囲によって接続できる相手が決まる

inboundsでは、接続可能なローカル接続先を定義します。listenはバインドするアドレス、portはポート番号、protocolは受信データを解釈するプロトコルを指定します。PC上のアプリだけで使う場合は、127.0.0.1へのバインドが基本です。すべてのインターフェースで待ち受ける設定にすると、LAN内の他の端末からポートに接続できる可能性があります。実際に到達できるかはファイアウォールやネットワーク環境にも左右されるため、アクセス制御を考慮せずにアドレスだけ変更しないでください。

アドレスとポートはセットで確認しましょう。アプリに設定するプロキシアドレスは、同じ端末上で実行中のコアを指している必要があります。スマートフォンのループバックアドレスはそのスマートフォン自身を指し、隣のPCには接続しません。IPv4のループバックで待ち受けても、IPv6のループバックまで待ち受けているとは限りません。アプリでlocalhostを指定すると接続できず、数値のループバックアドレスなら接続できる場合は、名前解決の結果と待ち受けアドレスの種類を確認してください。ローカルの接続先の問題をリモートサーバーの障害と取り違えないようにしましょう。

SOCKSとHTTPのinboundsが受け付けるもの

SOCKS inboundsは、通常SOCKSプロキシに対応したアプリで使います。HTTP inboundsはHTTPプロキシのリクエストを受け付け、アプリがCONNECTで確立するトンネルも処理します。どちらもブラウザーの通信を特定のWebプロトコルに強制変換するものではなく、システムプロキシを自動で有効にする機能でもありません。アプリ側でinboundsと同じ種類のプロキシを選択してください。SOCKSのポートをHTTPプロキシ専用の項目に指定しても、コアが自動判別するとは限りません。以下では2種類のinboundsを分けて、確認しやすくしています。

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

ここでSOCKSのUDPを有効にしても、すべてのUDPアプリが自動的にその経路を通るわけではありません。アプリがSOCKS UDPに対応している必要があり、outboundとリモートサービスも該当する転送に対応している必要があります。システムプロキシですべてのアプリや任意のUDP通信を扱えるわけではありません。「Webサイトは見られるのに、リアルタイムアプリだけ使えない」という場合も、すぐにノードの障害と判断しないでください。まずアプリがどの方法で接続しているかを確認し、必要な通信方式が後続の経路でサポートされているか調べましょう。

スニッフィングで接続先情報を補う

ルーティングにはドメイン名が必要でも、アプリからコアへ渡される情報が接続先IPアドレスだけの場合があります。inboundsのスニッフィング機能は、接続開始時のHTTPホスト名やTLSハンドシェイク内のサーバー名を検出し、ルーティングの判断材料を補えることがあります。汎用的なコンテンツ復号機能ではなく、すべての接続からドメイン名を取得できるわけでもありません。対応するプロトコルやオプションはコアごとに異なるため、項目を追加する前に使用中のコアのドキュメントを確認してください。他のコア向けの例をそのままコピーしないでください。

設定項目	意味	確認ポイント
`listen`	ローカルのバインドアドレス	ローカル利用ならループバックアドレスを推奨
`port`	待ち受けポート	アプリの設定と一致し、他のプロセスが使用していないこと
`protocol`	inboundsのプロトコル	アプリが送信するプロキシプロトコルと一致していること
`tag`	inboundsのtag	ルーティングで参照するtagと一致していること

スニッフィングでは、「ルーティングの判定にだけ使う」場合と「接続先を書き換える」場合を区別する必要があります。元の接続先を変更したくない場合に、ルーティングだけに影響するオプションを提供するコアもありますが、すべてのコアで使えるわけではありません。トラブル対処では、まず追加のスニッフィングを無効にし、ドメイン名またはIPアドレスが明確なリクエストを1つ成功させてから、機能を1つずつ有効にしましょう。そうしないと、inboundsが受け取った元の接続先とスニッフィングで得た名前が混在し、ログのルーティング結果を読み取りにくくなります。

inboundsの起動に失敗するローカル側の原因として、ポート競合、存在しない待ち受けアドレス、権限不足がよくあります。同じ端末上の2つのクライアントが同じアドレスとポートを使うと、通常は同時に待ち受けできません。競合を避けるために待ち受け範囲をむやみに広げないでください。使っていないクライアントを終了するか、ポートを計画的に変更し、アプリのプロキシ設定も合わせて更新しましょう。詳しい対処手順はログでのトラブル対処をご覧ください。システムプロキシの設定手順は使い方ガイドで確認できます。

03 / OUTBOUNDS

outbounds：プロキシプロトコルと通信設定

outboundsのtagとデフォルトの順序

outboundsは、リクエストをコアから接続先やリモートプロキシサーバーへ送ります。protocolで出口のプロトコルを選択し、settingsにそのプロトコルの設定を記述します。streamSettingsでは下位の通信方式と通信の保護を設定します。tagは設定内で参照するための名前にすぎません。proxyという名前を付けても、プロキシ機能が自動的に備わるわけではありません。outboundが実際に存在し、設定が有効で、ルーティングルールから選択されるかデフォルトの位置にある場合に、リクエストを処理します。

基本設定には、プロキシ、直接接続、ブロックの各outboundを含めることがよくあります。freedomによる直接接続では、コアを実行している端末から接続先へ通信します。blackholeはルールに一致したリクエストを終了します。「直接接続」は端末のネットワークスタックを経由しないという意味ではなく、OSレベルの仮想ネットワークアダプターを必ず回避するという意味でもありません。TUNなどで全体の通信を処理している場合、コア自身の接続に正しい迂回経路があるかを確認してください。ないと、リクエストが再びコアに取り込まれるループが起きる可能性があります。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

ノードの接続情報と通信の保護を分けて確認する

リモートプロキシのoutboundには通常、サーバーアドレス、ポート、プロトコルに応じた認証情報が含まれます。VMess、VLESS、Trojan、Shadowsocksでは認証情報の構造が異なるため、protocolだけを変更しても別プロトコルの設定にはなりません。サブスクリプションをインポートする利点の1つは、ノードの種類に応じた項目をクライアントが生成することです。手動で変更する場合は、サービス提供元の情報を項目ごとに確認してください。共有リンクの見た目だけから、暗号化方式、通信経路、セキュリティ設定を推測しないでください。

以下はTrojanのoutboundでよく使われる階層の例です。proxy.example.comとサンプルのパスワードは構造の説明用であり、実際のサービスには接続できません。サービス提供元から指定されたアドレス、ポート、パスワード、証明書名に置き換えてください。前に示した直接接続の例とは用途が異なる設定片です。最上位のオブジェクト全体をそのまま重ねて追加しないでください。実際に使う前に、現在のコアがこのプロトコルと通信項目に対応していることも確認してください。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "trojan",
      "settings": {
        "servers": [
          {
            "address": "proxy.example.com",
            "port": 443,
            "password": "your-password"
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "proxy.example.com",
          "allowInsecure": false
        }
      }
    }
  ]
}

通信方式はデータの運び方、TLSは通信の保護方法、プロキシプロトコルはプロキシリクエストのやり取りを定義します。この3つをそれぞれリモート側と一致させる必要があります。サーバーが受け付ける通信方式、パスの大文字・小文字の区別、特定のホスト名が必要かどうかは、サーバー側の設定に従ってください。クライアント側だけ変更しても、サーバー側が自動で対応するわけではありません。設定が一致しないと、即時切断やハンドシェイクの失敗、タイムアウトまでの待機などが発生します。

証明書名とサーバーアドレスは別の項目

サーバーアドレスは接続先を特定するためのもので、TLSのserverNameはハンドシェイク時のSNIと証明書の検証に使われます。環境によって両者が異なることもあります。ドメイン名を数値のIPアドレスに変更しても、証明書に対応するサーバー名を維持する必要がある場合があります。証明書の検証を無効にして、名前の不一致を長期的に回避しないでください。まずシステム時刻、証明書の対象範囲、入力した名前が一致するかを確認し、そのうえで証明書チェーンやネットワークの問題かどうかを判断しましょう。

接続の再利用、下位ソケット、高度な通信パラメーターは追加の調整項目です。初期設定の必須条件ではありません。まず標準設定でノードが動作することを確認し、特定のアプリで接続の繰り返しや長時間接続の切断が起きるかを見てから、コアの対応状況に応じて調整しましょう。「最適化設定」を一括で適用すると複数の条件が変わり、失敗の再現が難しくなります。速度測定の結果だけを理由に、プロトコルの認証情報を変更しないでください。性能調整用のスイッチではありません。

outboundが正常に起動しても接続できない場合は、ドメイン名の解決、リモートポートへの接続、TLSネゴシエーション、プロトコル認証のどこで失敗しているかを切り分けてください。前の段階が成功していない状態で、後の段階を調べても意味がありません。証明書に関する問題はTLSハンドシェイクとSNIのトラブル対処メモもご覧ください。GUIクライアントの変更やインストールが目的なら、クライアントページから選べます。コアのダウンロード先を別途探す必要はありません。

04 / ROUTING

routing：ルールの順序と通信の振り分け

ルールは記述順に評価され、条件の細かさで自動整列されない

routingでは、接続情報とルールを順に照合し、一致したリクエストを指定のoutboundに渡します。よく使われるtype: "field"形式では、ドメイン名、接続先IP、ポート、ネットワーク種別、inboundsのtagなどを条件にします。ルールは上から評価され、通常は最初に一致したルールで処理先が決まります。そのため、具体的な例外は広範囲のルールより前に置いてください。すべての接続に一致するルールを先頭に置くと、後続の細かなルールが正しく書かれていても実質的に使われなくなります。

1つのルールで異なる条件項目を指定した場合、通常はすべての条件を満たす必要があります。同じ配列に複数の候補を入れる場合は、一般にいずれか1つに一致すれば対象です。たとえばドメイン名の配列には複数のサイトを指定できますが、ポート条件も加えた場合は接続ポートも条件を満たさなければなりません。用途の異なる条件を1つのルールに詰め込み、互いに置き換わると考えないでください。ルールを読む際は、「どのinboundsから、どの接続先へ、どのネットワークで接続し、どのoutboundに渡すか」を言葉で整理し、コードと一致しているか確認しましょう。

ドメイン名の部分一致・完全一致とIP範囲

domain:は、ドメイン名とそのサブドメイン範囲の指定に使います。full:はドメイン名の完全一致、regexp:は正規表現による照合に使います。プロキシ接続のレイヤーでは通常、Webページの完全なURLは見えないため、ルールにページパスを書く必要はありません。プロトコルやパスを含むURLをドメイン条件として指定しても、一致しないことがあります。固定のホスト名にはシンプルな条件を優先し、正規表現はパターン指定が本当に必要なときだけ使うと、保守やエスケープの確認が容易です。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:telemetry.example.com"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "127.0.0.0/8",
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "::1/128",
          "fc00::/7"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

この設定例では、blockとdirectというtagのoutboundsがすでに必要です。1つ目のルールは2つ目の範囲内にある例外なので、先に配置します。プライベートネットワークの例は記載したアドレスだけを対象としており、特殊用途のネットワークをすべて網羅するものではありません。リンクローカルアドレスなどが必要な環境では、ネットワークの用途に合わせて追加してください。どのルールにも一致しないリクエストはデフォルトのoutboundに進みます。最後にdirectを指定しても、残りの接続すべてが直接接続になるわけではありません。

domainStrategyでルーティング時の名前解決タイミングを指定

AsIsは、IP条件を補うための名前解決を積極的に行わず、受け取った接続先情報をもとに判定します。IPIfNonMatchは、ドメイン名の段階で一致しなかった場合に名前解決し、IPルールを再評価することがあります。IPOnDemandは、IP情報が必要なルールに遭遇した時点で名前解決する場合があります。これらはルーティングの判定方法を変える設定であり、DNSサーバーの一覧ではありません。outboundが接続先へ接続する際に必要な名前解決の代わりにもなりません。ポリシーを変更すると、DNSリクエストの回数やルールの判定結果も変わる可能性があります。

アプリからコアにIPアドレスだけが渡される場合、ドメインルールを追加しても元の名前が復元されるわけではありません。アプリのプロキシ設定、名前解決が行われる場所、利用可能なスニッフィング機能を確認しましょう。逆に、接続先がドメイン名でも、プライベートIPのルールが必ず先に適用されるとは限りません。名前解決の有無やタイミングは現在のポリシーによって異なります。トラブル対処では、ブラウザーのアドレスバーだけを見るよりも、「inboundsがドメイン名とIPアドレスのどちらを受け取ったか」を記録するほうが役立ちます。

geositeとgeoipは分類データの参照であり、リアルタイムのネットワーク検索ではありません。コアが対応するデータファイルを見つけられ、指定したカテゴリ名が存在する必要があります。データがないと起動に失敗することがあり、分類内容が更新されると、同じ設定でも動作が変わる場合があります。まず具体的なドメイン名やIP範囲を1つ使ってルールを検証し、その後で分類データを参照すると、ルール構文とデータの問題を切り分けられます。

ルールを管理するときは、用途と変更理由を設定ファイルの外に記録しておくと便利です。標準JSONにコメントを追加するのは避けてください。古いルールを削除する前に、後続ルールが順序に依存していないか、特にinboundsのtagによる振り分けや全体のフォールバックルールを確認しましょう。照合方法や優先順位の例はカスタムルーティングルールの解説をご覧ください。システムプロキシとグローバルモードの違いは、よくある質問でクライアントの動作とあわせて確認できます。

05 / DNS

dns：名前解決の入口と問い合わせ経路

まず、どのレイヤーが名前解決しているか確認する

1回のアクセスには、アプリ独自の名前解決、OSの名前解決、コア内蔵DNS、リモートプロキシ側での名前解決が関わる場合があります。設定のdnsが指定するのは、コアに関係する名前解決の動作です。端末上のすべてのアプリのDNS設定を自動で置き換えるものではありません。ブラウザーが独自の暗号化DNSを使う場合もあり、アプリが先にIPアドレスを取得してからプロキシリクエストを送ることもあります。DNS設定が適用されているか判断するには、まず問い合わせを発生させているコンポーネントを特定してください。システム設定画面に表示されるサーバーアドレスだけでは判断できません。

コアのDNS動作は、ルーティングポリシー、outboundの設定、クライアントの設定生成方法にも左右されます。ドメイン名をリモート側に渡すリクエストもあれば、IPルールに一致させるためローカルで解決するリクエストもあり、両方が同時に起きることがあります。「Webサイトは開けるが、対応する問い合わせがログにない」場合も、設定が無効とは限りません。inboundsがドメイン名とIPアドレスのどちらを受け取ったか、最終的にどのoutboundが処理したかを確認してから、想定される名前解決の場所を判断しましょう。

servers、hosts、アドレス種別の問い合わせ

serversでは名前解決に使うサーバーを指定します。シンプルなアドレス形式のほか、コアが対応していればドメイン名の条件を付けたオブジェクト形式も使えます。hostsは明示的な名前解決結果を設定するもので、管理下のテストや固定された内部名に適しています。以下の例では数値のDNSサーバーアドレスを指定し、例示用に予約されたドメイン名をドキュメント用アドレスに割り当てています。この割り当て先は説明用で、アクセス可能なサイトではありません。数値アドレスを使うと、起動時にDNSサーバーのドメイン名を解決する必要がなくなります。

{
  "dns": {
    "hosts": {
      "lab.example.com": "192.0.2.10"
    },
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

UseIPは、IPv4とIPv6の両方の結果を問い合わせる設定です。ほかの問い合わせポリシーで指定できる値は、使用するコアに合わせてください。IPv4のみを返す設定は、デュアルスタック環境の問題を切り分けるのに役立つ場合がありますが、恒常的な最適化として使うものではありません。IPv6が必要なネットワークで制限すると、利用できる経路を失う可能性があります。端末にIPv6アドレスが設定されていても、ネットワークで安定したエンドツーエンド通信ができるとは限りません。アドレス設定と実際の到達性を分けて確認してください。

DNSサーバーの一覧と接続用outboundの一覧は別もの

複数のサーバーを指定しても、常に記述順に1つずつ厳密に切り替わるとは限りません。ドメイン条件、キャッシュ、フォールバックの仕組み、コアの実装によって実際の問い合わせ方法は変わります。ドメインごとにDNSサーバーを使い分ける場合は、どの名前をどのサーバーへ渡し、一致しない名前をどう処理するか明確にしてください。オブジェクト形式のドメイン条件はルーティングのルールと似ていますが、適用箇所は異なります。前者はDNSサーバー、後者は接続先outboundを選ぶため、書き方が似ていても同じルールとして扱わないでください。

暗号化DNSは名前解決サーバーまでの通信を保護しますが、その通信が想定したoutboundを通ることまでは保証しません。現在のコアでの送信経路や、クライアントがDNSルーティングを別途設定していないかも確認してください。DNSサーバーのアドレスにドメイン名を使い、そのサーバーを見つけるために自身のDNS解決が必要だと、起動時に依存関係のループが起きることがあります。まず到達先が明確な数値アドレスを使って基本的な名前解決を確認し、その後で目的の方式に切り替えましょう。

現象	まず確認する点	早合点しないこと
ドメイン名では失敗するがIPアドレスなら接続できる	名前解決と取得したアドレスの種類	リモートのプロトコル障害とは限らない
一部のサイトでまれにタイムアウトする	キャッシュ、デュアルスタックの経路、名前解決にかかる時間	すべてのノードの障害とは限らない
ルールがドメイン名に一致しない	inboundsがIPアドレスしか受け取っていないか	ドメイン名の入力ミスとは限らない
変更後も古い結果が使われる	アプリとシステム各レイヤーのキャッシュ	設定が読み込まれていないとは限らない

キャッシュはDNSのトラブル対処で重要な要素です。クライアントを再読み込みしても消えるのはコアのキャッシュだけで、ブラウザーやOSに古い記録が残ることがあります。既存の接続も、名前解決の結果が変わっただけでは再接続されません。設定を検証するときは新しい接続を使い、必要なら関連アプリを終了してから起動し直し、テスト時刻と問い合わせた名前を記録しましょう。ページを何度もすばやく再読み込みして複数レイヤーのキャッシュ結果を混在させ、その結果だけで特定のサーバーがまったく適用されていないと判断しないでください。

DNSのタイムアウトは、ルーティングのループが原因の場合もあります。たとえば、DNSリクエストが「接続に必要なドメイン名を先に解決しなければならない」プロキシoutboundに送られている場合や、仮想ネットワークアダプターがコア自身の通信を再び取り込んでいる場合です。このとき、パブリックDNSサーバーを次々に追加しても解決しないことがあります。接続の依存関係に戻り、DNSサーバー、プロキシサーバー、コア自身の通信経路をそれぞれ確認しましょう。複雑なドメイン別の名前解決を安定させるには、各段階の前提条件を個別に満たす必要があります。

v2rayNやv2rayNGでDNSを変更するときは、まずクライアントに用意された設定画面を使い、最終的に生成された内容を確認してください。画面の設定とカスタム設定が互いに上書きするのを防げます。初回接続では、変更する項目を少なく保つほうが確認しやすくなります。特定の振り分けを検証する場合は、テスト用ドメインを1つ決め、名前解決とアクセスを別々に確認しましょう。システムプロキシの適用範囲やアプリ独自のDNSに関する質問は、よくある質問をご覧ください。

06 / POLICY

policy：タイムアウト、ユーザーレベル、統計

policyはノードの優先順位を指定するものではない

policyでは、接続リソースや統計に関するポリシーを設定します。主な項目には、ハンドシェイクの待機時間、アイドル状態のタイムアウト、片方向が閉じた後の接続維持時間、通信量の統計設定があります。ノード名をもとにoutboundを選ぶ機能ではなく、ルーティングルールの代わりにもなりません。接続が不安定な場合は、まずoutboundが接続を確立できているかを確認し、その後でタイムアウト設定が原因かを判断してください。すべての時間を長くすると、本来すぐに現れるべきエラーの発見が遅れるだけです。

levelsでは、数字のキーでユーザーレベルを指定します。JSONオブジェクトのキーは引用符で囲む必要があります。ユーザーレベルはOSの権限ではなく、「数値が大きいほど速度が上がる」という順序でもありません。プロトコルのユーザー設定にあるlevelは対応するレベルに関連付けられます。明示的に指定しない場合は、通常デフォルトのレベルが使われます。認証なしのローカルinboundsを主に使い、ユーザーに複数のレベルを設定していない環境では、大きな番号のポリシーを多数追加しても期待した変化は得られません。

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

接続の各段階に分けてタイムアウトを理解する

例にある時間の単位は通常秒ですが、現在使用しているコアの項目説明に従ってください。handshakeはハンドシェイク中に待機する時間、connIdleはデータのやり取りがない接続を維持する時間に関係します。uplinkOnlyとdownlinkOnlyは、片方の方向が閉じた後に、もう一方を維持する時間を指定します。それぞれ対象とする段階が異なるため、あらゆる「接続が切れる」現象を1つの項目だけで説明することはできません。

ハンドシェイク時間が短すぎると、高遅延や一時的な混雑時に接続が確立する前に打ち切られることがあります。長すぎる場合は、失敗がわかるまでの時間が延びます。アイドルタイムアウトが短すぎると、データのやり取りは少なくても通知を待つアプリに影響する可能性があります。長すぎる場合は、より多くの接続リソースを保持します。再現手順が安定しているアプリを使い、切断前に本当にデータが流れていなかったかを記録してから、関係する項目だけを少しずつ変更してください。通信中の障害を、安易にアイドルタイムアウトの問題と決めつけないでください。

ネットワーク接続では、片方向だけが閉じることも珍しくありません。一方が送信を停止しても、もう一方の応答が完了したとは限りません。そのため、片方向の維持時間が一部のリクエストの終了処理に影響することがあります。ログとアプリの動作から半閉鎖状態が原因と確認できた場合に限り、該当する項目を調整しましょう。認証が成立していない場合やサーバー側がセッションを終了している場合、これらの時間を変更してもプロトコルの不一致は解決せず、リモート側に接続維持を強制することもできません。

統計の有効化には一連の収集経路が必要

ユーザーごとのアップロード・ダウンロード統計を有効にしても、クライアントにすぐ数値が表示されるとは限りません。統計モジュール、ユーザーID、APIサービス、クライアントの読み取り処理がそろって初めて機能します。画面に表示された通信量が仮想ネットワークアダプターなど別の情報源に由来する場合もあります。数値が表示されたからといって、policyの項目が有効だとは限りません。この記事では項目の階層だけを示すため、統計は無効にしています。追加のAPIや収集設定は含めていません。

システム全体の統計とユーザーごとの統計では、集計の細かさが異なります。inbounds単位の統計は複数種類のリクエストをまとめる場合があります。ユーザー単位の統計には、プロトコル上で識別できるユーザー情報が必要です。アプリごとに通信量を分けたい場合、ユーザー統計を有効にするだけでは不十分なことがあります。inboundsの分け方、アプリの接続方法、クライアントの表示機能も確認してください。画面上の数値を得るためだけに、管理APIをLANに公開しないでください。APIの待ち受け範囲は実際の用途に合わせて制限しましょう。

統計などの高度なモジュールを有効にして起動できなくなった場合は、必要な関連モジュールがあるか、現在のコアが項目に対応しているか、クライアントが同じ設定をすでに生成していないかを確認してください。別々のAPI設定を2組残したまま、ポートを変えてすべてのエラーを解決しようとしないでください。接続ポリシーだけの最小構成に戻してから統計機能を1つずつ追加すれば、接続処理の問題と監視機能の問題を分けられます。データ収集の設定が通常の利用に影響するのを防げます。

ポリシー変更の評価に、1回の遅延測定だけを使わないでください。短いリクエスト、長時間接続、継続的な通信では影響する段階が異なり、1種類のテストですべての動作は確認できません。初回接続が完了するか、アイドル状態から復帰できるか、実行中のタスクが途中で切れないかをそれぞれ確認し、テスト後は通常のログレベルに戻しましょう。特定の値がどの問題を解決するのか説明できない場合は、設定に残す必要はありません。設定がシンプルなほど、コアの移行時に互換性を確認しやすくなります。

07 / CLIENT INTEGRATION

クライアントによる設定生成と適用範囲

画面の設定が実行用の設定になるまで

v2rayN、v2rayNG、v2flyNGでは、GUIとコアの接続処理が分かれています。クライアントはノード、サブスクリプション、ユーザー設定を保存し、選択内容をコアの実行に必要な設定へ変換します。手作業で項目を記述する負担を減らせる一方、生成ファイルが長期的な設定の保存先とは限りません。ノードの切り替え、コアの再起動、ルーティングモードの変更、サブスクリプションの更新などで設定が再生成される場合があります。実行ファイルを直接編集しても、次の操作で上書きされることがあります。

デスクトップでは、実際に使うコアとシステム環境に合わせてv2rayNを使うのがおすすめです。Androidでは、Xrayコアを採用したv2rayNG、またはV2Flyコアを採用したv2flyNGを選べます。カスタム設定の取り込み方はクライアントによって異なり、画面上の項目名も変更される場合があります。実際にインストールされているバージョンの画面を確認してください。ある項目が見つからない場合、別のクライアントの手順全体を共通の手順として使うのではなく、現在のアプリとコアを先に確認しましょう。

サブスクリプション、ノード、完全な設定の違い

サブスクリプションURLは通常、更新可能なノード一覧を示します。ノード共有リンクは1つのサービスのプロトコルや接続情報を表し、完全なJSONにはinbounds、outbounds、DNS、ルーティングなどが含まれることがあります。この3つは異なる形式なので、同じ種類のテキストとしてインポートできません。ノードリンクのみを受け付ける画面に完全な設定を貼り付けたり、outboundのサーバーアドレスにサブスクリプションURLを入力したりしても、正しく設定されません。インポート前に内容の用途を見分けるほうが、失敗後にボタンを次々と試すより効果的です。

設定の種類	主な用途	管理上の注意
サブスクリプショングループ	ノードをまとめて取得・更新する	更新によりノードの手動変更が上書きされることがある
クライアントの設定	inbounds、ルーティング、動作環境の設定を管理する	変更の反映にコアの再起動が必要か確認する
実行用設定	現在のコアプロセスが読み込む	次回の生成時に上書きされることがある
カスタムの完全設定	クライアントの対応方法に沿ってモジュールを引き継ぐ	画面上のどの設定が引き続き有効か確認する

完全な設定をインポートできるクライアントもあれば、一部の項目やルーティングルールだけをカスタマイズできるクライアントもあります。設定を使う前に、全体の置き換え、特定オブジェクトのマージ、配列項目の追加のどれに当たるかを確認してください。同じ設定片でも、マージ方法によって結果が異なります。outboundsの配列を置き換えると既存の出口が失われ、ルーティングルールを追加しても前のルールに優先されて適用されないことがあります。ファイルを保存できたかだけでなく、最終的に生成された内容に想定したtagと順序が含まれているか確認しましょう。

システムプロキシとTUNは異なる接続方法

システムプロキシは、OSがその設定に従うアプリへプロキシ情報を提供する仕組みで、すべてのアプリを自動で対象にするものではありません。TUNは仮想ネットワークインターフェースと関連するルートを使って、通信をクライアントへ渡します。どちらも同じコアを利用する場合がありますが、同じJSON設定項目ではありません。TUNに必要な権限、仮想インターフェース、システムルートはクライアントが管理することが多く、従来のinbounds配列に見慣れないプロトコル名を追加するだけで、システム全体の通信を処理できるわけではありません。

複数のネットワークプロキシツールを同時に使う場合は、システムプロキシの接続先をどのツールが変更するか、デフォルトルートをどれが管理するか、DNS設定をどれが維持するか確認してください。クライアントを終了しても、別のクライアントがポートを使い続けたり、システム設定を残したりする場合があります。「ソフトを終了したらアプリがネットにつながらなくなった」というときは、まずシステムプロキシが停止済みのローカル接続先を指していないか確認し、次に仮想ネットワークアダプターとシステムルートを調べましょう。すぐにすべてのソフトを再インストールする必要はありません。

小さな変更で設定元を確かめる

カスタム設定が使われているかを調べるには、サービス情報を公開せずに確認できる変更を1つ選びます。たとえば、ローカルの待ち受けポートを変更してテスト用アプリ側も合わせる方法や、既存のoutboundにわかりやすいtagを付ける方法があります。関連する接続を再起動して、待ち受け状態とログを確認してください。最終的に生成された設定が変わっていない場合は、クライアント側の設定元やマージ方法に問題があります。リモートネットワークを調べ続ける必要はありません。生成結果が正しければ、次に接続レイヤーを調べましょう。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["http-in"],
        "outboundTag": "direct"
      }
    ]
  }
}

上の設定片は、inboundsのtagを使った振り分けだけを示しています。http-inというtagのinboundsと、directというtagのoutboundが別途必要です。この設定片がそれらを作成するわけではなく、既存のルーティングを確認せずに上書きする用途にも適しません。カスタム設定を保守するときは、変更の目的、対応コア、依存するtagを個別に記録してください。サブスクリプションURLやパスワードを公開メモに書かないようにしましょう。端末を移行する前に必要な設定をエクスポートし、機密情報の保存方法がクライアントの仕様に沿っているか確認してください。

初回利用では、まず使い方ガイドに沿ってインポート、ノード選択、動作確認を行い、その後で完全設定の取り込みを検討しましょう。v2rayNの設定画面やログの場所を知りたい場合は、メイン画面の機能ガイドをご覧ください。このページでは設定項目と適用範囲を解説しています。クライアントの具体的なボタンは現在の画面で確認し、例と完全に同じ設定にするために、安定しているデフォルト設定を無理に変更する必要はありません。

08 / DIAGNOSTICS

ログの確認と設定を戻す手順

まずプロセスが正常に起動しているか確認する

設定のトラブル対処で最初の分かれ目になるのは、コアが起動後も動作を続けているかです。起動直後に終了する場合は、Webページへの接続を試す前に、最初に出たエラーを確認してください。よくある原因は、JSONの構造エラー、未対応のプロトコルや項目、待ち受けの重複、必要なデータファイルの不足です。その後に「接続拒否」が続いても、コアの終了に伴う二次的な現象かもしれません。アプリ側の警告を修正するだけでは、最初の起動エラーは解決しません。

ログにファイルの場所が表示される場合は、そのログが現在の実行インスタンスのものか確認してください。複数のクライアントや残存プロセスが別々のログを出力していることがあり、古いウィンドウの情報が直近のテストに対応しているとは限りません。再起動した時刻を記録し、現在のインスタンスに関係するログだけを残して、設定ファイルのパスと編集場所が一致しているか確認しましょう。クライアントに起動エラーの詳細が表示される場合は、まずそこでモジュール名を確認し、該当箇所をファイルから探してください。似た項目を先にまとめて置換するのは避けましょう。

一時的にログの詳細度を上げる

接続の流れを調べる場合、コアが対応していることを確認したうえで、ログレベルを一時的にinfoへ変更できます。より詳細なデバッグレベルは、原因を絞り込んだ後に限って使用してください。ログには接続先のドメイン名、アドレス、ユーザー情報が含まれることがあります。共有前に機密情報を削除しましょう。ログを増やせば調査しやすくなるとは限りません。特に複数のアプリが同時に通信していると、正常な接続が問題のリクエストに埋もれます。テスト中はアプリを1つに絞り、接続先も1つ決めておくと確認しやすくなります。

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

この設定は最上位のログモジュールだけを置き換えるもので、単独で使える完全な設定ではありません。変更してもログの詳細度が変わらない場合は、コアの再起動が必要か、クライアントがログ設定を上書きしていないか確認してください。調査が終わったら通常のレベルに戻し、不要なアクセス情報を記録し続けないようにしましょう。ログをファイルに出力する場合は、保存先のディレクトリが存在し、実行中のプロセスに書き込み権限があるかも確認してください。ログファイルを作成できないこと自体が別のエラーを引き起こす場合があり、接続障害と混同しないようにしてください。

inbounds、名前解決、ルーティング、outboundsの順に確認する

コアが正常に動作していることを確認したら、テスト用リクエストが該当するinboundsに届いているかを見ます。ログに何も記録されない場合は、アプリのプロキシ種別、アドレス、ポート、システムプロキシの状態を確認してください。リクエストは届いているのに接続先情報が違う場合は、アプリの名前解決方法やスニッフィングを確認します。接続先が正しいのにoutboundが違う場合は、ルールの順序、tag、ドメイン戦略を調べましょう。想定したoutboundが選ばれたことを確認してから、サーバー名の解決、接続、TLS、プロトコル認証を調べてください。別のレイヤーを推測で調べるのは避けましょう。

段階	よくある原因	次に行うこと
設定の読み込み	括弧、項目の型、コアとの互換性	最小構成に戻し、モジュールを1つずつ追加する
ローカルの待ち受け	ポートの競合、アドレス、権限	現在の待ち受けプロセスとアプリの接続先を確認する
ルーティングの判定	条件が一致しない、順序が先行ルールに遮られる	接続先を1つに絞り、outboundのtagを確認する
リモート接続	名前解決、接続性、証明書、認証情報	接続の段階ごとに設定を確認する

「タイムアウト」は、ある段階が待機時間内に完了しなかったことを示すだけで、根本原因とは限りません。サーバー名の解決、接続先ポートへの接続、プロトコルのネゴシエーションでは、それぞれ確認方法が異なります。ログに最後のメッセージしか残っていない場合は、詳細度を適度に上げて再現し、より早い段階の情報を探してください。タイムアウトを見てDNS、通信方式、認証情報を同時に変更すると、たまたま直ってもどの変更が効いたのか判断できません。

修正を検証する際は、新しく作成したリクエストとアプリの実際の動作をあわせて確認してください。既存の長時間接続は以前のoutboundを使い続けることがあり、ブラウザーのキャッシュによりページが正常に見えても新しいリクエストが発生していない場合があります。関連する接続を閉じてからテストし、想定したinboundsとoutboundsを通っていることを確認しましょう。アプリが必要とするほかの通信も成功するか確認してください。実接続による速度測定はサービスへの到達性を比較するのに役立ちますが、1回成功したからといって、すべてのドメイン、プロトコル、アプリでルーティングが意図どおりとは限りません。

説明できる状態に戻すことを目標に設定を戻す

複数箇所を変更して原因がわからなくなった場合は、直近に起動できた設定へ戻し、inboundsを1つ、動作確認済みのoutboundを1つ、必要最低限のルールだけ残してください。その後、DNS、振り分け、policy、高度な機能の順に戻し、毎回同じ接続先をテストします。この順序は機能を恒久的に減らすためではなく、複雑な問題を確認可能な手順に分けるためのものです。追加した設定の結果を毎回把握できれば、後から変更を重ねても原因不明の例外が増えにくくなります。

起動エラーの分類を詳しく知りたい場合は、Xrayログから設定エラーを特定する方法をご覧ください。起動できているのにプロキシが有効か判断できない場合は、初回接続の確認メモを参考にしてください。解決しない場合は、よくある質問から症状を探してください。設定リファレンスの目的は、ファイルを長くすることではなく、各項目の役割を説明できるようにすることです。