V2Ray設定ファイルリファレンス

01 / STRUCTURE

JSON構造と設定の範囲

設定ファイルでは、まず各オブジェクト間の関係を定義し、カーネルがそれらを処理の流れとしてつなぎます。アプリからのリクエストをインバウンドが受け取り、ルーティングが宛先や送信元の条件を確認して、アウトバウンドを選択します。DNSはドメイン名の解決に関わり、ポリシーは接続リソースを制御し、ログは実行状況を記録します。これらは順番に実行されるスクリプトではありません。ファイル内の記述順を変えても通常は処理順に影響しませんが、配列内の順序は結果を左右することがあります。

実際に読み込まれている設定を確認する

v2rayNなどのGUIクライアントは通常、ノードやルーティング、DNSの画面設定から実行用の設定を生成します。画面上のサブスクリプショングループ、ウィンドウのレイアウト、速度テストの設定はクライアント側のデータであり、カーネルのトップレベル項目ではありません。ディスク上に config.json というファイルがあっても、それが現在の実行設定とは限りません。クライアントの実行情報や設定の確認画面、起動ログでカーネルの種類と設定の読み込み元を確かめてから、変更場所を判断してください。

生成済みの設定ファイルを直接編集しても、その実行時だけしか反映されないことがあります。ノードの切り替え、サブスクリプションの更新、設定の保存、カーネルの再起動時にクライアントがファイルを再生成し、変更を上書きする場合があるためです。日常的な設定変更には、クライアントが提供するルーティング、DNS、自定义設定の項目を使ってください。設定全体を独自に管理する場合は、そのモードでもクライアント生成ルールが適用されるのかを事前に確認し、二つの設定が自動で統合されると思い込まないようにしましょう。

単独で動作する最小構成から始める

以下の完全な基本設定は、ローカルのループバックアドレスでSOCKSポートを待ち受け、すべての通信を宛先へ直接接続します。カーネルが設定を読み込めるか、ローカルポートに接続できるか、タグが正しく対応しているかを確認するための例です。ポートが使用中の場合は、空いている番号に変更してください。この設定ではリモートプロキシに接続しません。テスト時の通信経路は端末からの直結です。

{
  "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": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "outboundTag": "direct"
      }
    ]
  }
}

この構成を拡張する際は、一度に機能を一つだけ追加してください。まず固有のタグを付けたアウトバウンドを追加し、それを参照するルールを設定して、適用状況を確認します。DNSの変更、スニッフィングの有効化、ポリシーの調整、デフォルトのアウトバウンド変更を同時に行うのは避けてください。最小構成の目的は機能を揃えることではなく、いつでも戻せる状態を用意し、変更と結果の因果関係を明確にすることです。

オブジェクト、配列、項目の型

inbounds と outbounds は配列で、それぞれ複数のオブジェクトを格納できます。routing、dns、policy、log はオブジェクトです。文字列には半角のダブルクォーテーションを使い、真偽値は true または false と記述します。数値と文字列も、項目の仕様に合わせて使い分けてください。ポート範囲の項目で文字列が使える場合があっても、すべてのポート項目で型を混在できるわけではありません。

ツールを問わず読みやすいよう、このページの例はコメント、末尾のカンマ、重複キーのない厳密なJSONで記述しています。一部のローダーが拡張構文に対応していても、エディターで開けることと、使用中のカーネルが読み込めることは別です。説明文を引用符の外に貼り付けたり、文書から全角の引用符をコピーしたりしないよう注意してください。エラー位置は問題を検出した箇所を指すため、実際に不足しているカンマが一つ前の行にあることもあります。

よく使われる六つの項目が、トップレベル項目のすべてではありません。統計、管理インターフェース、その他の拡張モジュールには別途設定が必要な場合があります。構成を完全に見せるためだけに、空のモジュールを機械的に追加しないでください。まず問題が受信、照合、名前解決、接続のどれに関わるかを判断してから、該当するセクションを確認しましょう。見つけた設定値を手当たり次第に試すより、適切な設定範囲を保ちやすくなります。

02 / INBOUNDS

inbounds インバウンド設定

インバウンドは、カーネルがどこから通信を受け取り、受信したデータをどう扱うかを定義します。ローカルアプリがSOCKSまたはHTTPプロキシを使う場合、接続先はプロキシ用のインバウンドであり、リモートノードのアドレスではありません。インバウンドが利用可能でも、それはアプリからカーネルに接続できることを示すだけで、リモートのアウトバウンド接続が成功した証拠にはなりません。トラブルシューティングではローカルの受信とリモートへの接続を分けて確認すると、ポートの問題をノードの問題と取り違えにくくなります。

待ち受けアドレスとポート

listen は待ち受けるネットワークインターフェースを、port はローカルのポート番号を指定します。端末内のアプリだけで使う場合は、127.0.0.1 を明示すると待ち受け範囲を絞れます。すべてのインターフェースからアクセスできるアドレスに変更すると、LAN内の他の端末からも接続できる可能性があります。システムのファイアウォール、アクセス範囲、認証設定もあわせて検討してください。外部からアクセスできるようにするだけでは共有が成功するとは限らず、接続できないときの定番の対処として安易に待ち受け範囲を広げるべきではありません。

同じアドレスとポートで、同種の通信を複数のインバウンドが重複して待ち受けることはできません。ポートの競合は、別のクライアントが起動中の場合や、前回正常終了しなかったカーネルのプロセスが原因のことがあります。バインドに失敗したら、まず重複して起動しているプロセスを終了し、ポートが使用可能になったか確認してください。ポートを変更した場合は、ブラウザー、システムプロキシ、その他のアプリのプロキシ設定も変更しないと、アプリは古いポートに接続し続けます。

SOCKSとHTTPは互換ではない

以下はトップレベルの inbounds に追加できる項目の抜粋です。二つの入口には別々のポートを割り当て、タグで区別しています。SOCKSのUDPオプションは、その入口が該当するリクエストを受け付けることを示すだけです。すべてのアプリ、アウトバウンド、通信経路でUDPが使えるという意味ではありません。HTTPインバウンドはHTTPプロキシを利用するアプリ向けです。ポートに接続できるからといって、SOCKSとして使用することはできません。

{
  "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": {}
    }
  ]
}

アプリ側のプロキシ種別は、インバウンドのプロトコルと一致させてください。HTTPリクエストをSOCKSポートへ送ると、接続切断やプロトコルエラー、応答なしになることがあります。その場合、ノードを変更しても解決しません。また、アプリが宛先ドメインをプロキシに渡すのか、それとも先に自分で名前解決してIPアドレスを渡すのかも確認してください。どちらの方法かによってカーネルが認識できる宛先情報が変わり、その後のドメインルールにも影響します。

タグと送信元の識別

tag は設定内で使う名前であり、ネットワークアドレスでも待ち受け動作を決める値でもありません。ローカルSOCKS、ローカルHTTPのように、短く意味のわかるタグを付けておくと管理しやすくなります。ルーティングの inboundTag にはタグを大文字・小文字も含めて完全一致で指定してください。タグを変更した後にルールの参照を直し忘れると、そのルールが機能せず、通信が後続ルールやデフォルトのアウトバウンドに流れることがあります。

アプリごとの入口を区別したい場合は、別々のタグを使えます。通常の入口を残したまま、テスト専用の入口を追加し、インバウンドタグでテスト通信を指定したアウトバウンドへ送る方法です。アプリ全体のルールを何度も変更せずに、新しい出口を検証できます。ただし、入口が増えるほどポートとルールの関係が複雑になります。使わなくなった入口は削除するか無効化し、古いテスト経路を長期設定に残さないようにしましょう。

スニッフィングで取得できる情報

リクエストによっては、カーネルに届く時点でIPアドレスしか含まれていないことがあります。スニッフィングでは、対応プロトコルの初期データからHTTPのホスト名や一部のTLSハンドシェイクに含まれるサーバー名などを取得できる場合があります。通信を復号する機能ではなく、暗号化された通信をすべて識別できるわけでもありません。アプリのプロトコル、ハンドシェイク方式、プライバシー機能によって見える情報は異なるため、スニッフィングを有効にすればすべてのドメインルールが適用されるとは限りません。

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls"]
  }
}

上記は単一のインバウンドオブジェクトに追加する項目の抜粋で、トップレベルのオブジェクトではありません。destOverride はスニッフィング結果に基づいて宛先を補正する動作に関わります。対応項目と選択肢は、使用するカーネルで確認してください。接続先を書き換えず、スニッフィング結果をルーティング判定にだけ使いたい場合は、その用途専用の設定が現在のカーネルにあるかを確認しましょう。別のカーネルの拡張項目をそのまま使い、同じ動作になると思い込まないでください。

インバウンドを検証するときは、まずクライアントのログに待ち受けエラーがないことを確認し、プロキシ設定に対応したアプリを指定した入口に接続します。カーネルがリクエストをまったく受信していない場合は、アプリの設定と通信の取り込み範囲を確認してください。受信ログがある場合は、ルーティングとアウトバウンドの確認に進みます。Androidの通信取り込みはシステムの許可やアプリごとの設定にも左右され、画面上の設定場所はデスクトップのシステムプロキシとは異なります。

03 / OUTBOUNDS

outbounds アウトバウンド設定

アウトバウンドは、カーネルが宛先へ接続する方法を定義します。直接接続する、リモートプロキシに転送する、ルールに従ってリクエストを拒否するといった動作を指定できます。インバウンドが通信を受け取り、アウトバウンドが送信し、その間をルーティングがつなぎます。リモートノードが利用できなくても、ローカルのインバウンドは正常に待ち受けていることがあります。また、クライアント画面にノード名が表示されていても、現在のカーネルがアウトバウンド設定を受け付けたとは限りません。設定の生成と接続の確立は別々に検証してください。

デフォルトの出口は配列の順序で決まる

従来形式の設定では、ルーティングルールに一致しない通信は通常、outbounds 配列の先頭にあるアウトバウンドへ送られます。このデフォルト動作は重要です。オブジェクトの順序を入れ替えるだけで、どのルールにも一致しない通信の経路が変わることがあります。タグが direct や proxy だからといって、デフォルトの出口を判断することはできません。タグは参照名にすぎず、実際の動作はプロトコルや設定、配列内の位置によって決まります。

以下の項目抜粋では、直結を先頭に置き、拒否用のアウトバウンドを追加しています。ローカルの基本構成とルールからの参照を説明する例であり、リモートノードを含む設定ではありません。ルールに一致しない通信をリモートプロキシへ送る場合は、先頭のアウトバウンドまたは末尾のフォールバックルールを改めて設計してください。ドメインの名前解決、サブスクリプションの更新、ローカルネットワークへのアクセスまで同じ出口に送られないかも確認が必要です。

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

直結、拒否、リモートプロトコル

freedom は宛先へ直接接続するアウトバウンドプロトコルです。直結でも端末のネットワーク、ファイアウォール、接続先サービスの状態に左右されるため、リモートノードを経由しないから必ず到達できるとは限りません。blackhole は一致した通信を拒否または破棄するためのもので、明示的なブロックルールに使います。アプリ側では、プロトコルや応答設定によって接続失敗、応答なし、待機などの形で現れる場合があります。トラブルシューティングでは、まず拒否用のアウトバウンドに送られていないか確認してください。

リモートプロキシのアウトバウンドには、サーバーアドレス、ポート、認証情報のほか、トランスポートやセキュリティの設定も含まれます。VMess、VLESS、Trojan、Shadowsocksでは設定オブジェクトが異なるため、protocol だけを変更して別の種類のノードに置き換えることはできません。信頼できるノード情報やクライアントのインポート機能から該当する項目を生成し、生成された設定を確認してください。不完全な設定例を見ながら値を一つずつ推測するのは避けましょう。

ノードのアドレスは接続先サーバーを指定します。TLSのサーバー名はハンドシェイク時の検証などに使われ、両者は異なる場合がありますが、サーバー側の構成と一致している必要があります。トランスポート層のパスやホスト名、セキュリティ層のサーバー名も用途が異なります。ハンドシェイクに失敗した場合は層ごとに確認し、三つの項目すべてをサーバーのIPアドレスに変更するのは避けてください。証明書の検証を無効にすると問題が見えにくくなるため、通常のトラブルシューティング手段として使うべきではありません。

項目を追加する前にカーネルの対応状況を確認する

XrayとV2Flyは従来の設定概念の一部を共有しますが、拡張プロトコルやトランスポートのオプションが互換とは限りません。ノードでREALITYや特定のフロー制御項目が必要な場合は、実際に起動しているカーネルが対応しているかを先に確認してください。v2rayNGとv2flyNGではカーネルの方針が異なります。デスクトップでv2rayNを使う場合も、クライアント名から機能を推測せず、現在のノードと実行情報を確認しましょう。

プロトコル、トランスポート、セキュリティ層は関連していますが、それぞれ別の要素です。VLESSはプロキシプロトコルで、TLSやREALITYはセキュリティ関連の設定、実際のネットワーク転送には別のパラメーターがあります。設定を誤った階層に置くと、設定エラーになったり、読み込み後にネゴシエーションに失敗したりすることがあります。各層の概要はREALITYとXTLS Visionの仕組みも参照してください。実際の項目は使用するカーネルの仕様に従ってください。

タグと接続経路を再確認する

ルールから参照するアウトバウンドには、それぞれ重複しないタグを付けてください。タグが重複すると設定の意味が不明確になり、ツールによる重複値の扱いにも依存できません。アウトバウンドの名前を変更したら、ルーティングや出口チェーンなど、他の参照箇所も確認しましょう。画面上でノードの表示名を変えても、生成設定内のアウトバウンドタグが変わるとは限りません。リスト上の名前だけでなく、実際に動作している設定を確認するほうが確実です。

アウトバウンドを診断するには、まずローカルの直結構成で接続先サービスを確認し、同じ入口とテスト先を使ってリモート出口に切り替える方法があります。リモート経路だけが失敗する場合は、サーバーアドレスの名前解決、ポートへの接続、安全なハンドシェイク、認証情報を順に確認してください。宛先によって異なるルールが適用されることがあるため、あるウェブサイトに一度アクセスできても、すべての出口が正常とは限りません。一つの宛先でタイムアウトしただけで、ノード全体が使えないとも判断できません。

設定を保守する際は、デフォルトの出口、明示的な直結、明示的な拒否、リモート出口の役割を明確にしておきましょう。新しい出口は単独で検証してから、少数のルールで参照し、最後にデフォルト経路を変更します。この順序なら、新しいノードの設定ミスがすべての通信に影響するのを防げます。問題が起きても設定全体を作り直さず、関係するルールだけを元に戻しやすくなります。

04 / ROUTING

routing ルールと照合順序

ルーティングは、リクエストの条件をアウトバウンドのタグに対応付けます。大切なのはルールの数ではなく、照合順序、条件の組み合わせ、カーネルが認識できる宛先情報です。従来形式の項目ルールは通常、上から順に評価され、最初に一致したルールの出口が選ばれます。後続のより細かいルールを自動的に探すことはありません。そのため、例外的なルールは広い条件のルールより前に、フォールバックは末尾に置くのが基本です。ファイルの後方にあるルールに、前のルールを上書きする特別な優先権があるわけではありません。

一つのルール内で条件をどう組み合わせるか

同じルールに複数の条件を指定した場合、通常はすべてに一致する必要があります。たとえば inboundTag と domain を併記すると、入口とドメインの両方が一致するという意味で、どちらか一方が一致すればよいわけではありません。同じ条件に複数の候補を並べた場合は、通常そのうち一つに一致すればよい形式です。独立した二つの条件の組み合わせを表したい場合は、二つのルールに分け、「または」のつもりで「かつ」を指定しないようにしましょう。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "domain": [
          "full:example.com",
          "domain:example.org"
        ],
        "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",
          "fe80::/10"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

以下は前述の基本設定と組み合わせられるルーティング項目の抜粋です。最初のルールは指定したSOCKSインバウンドだけを対象とします。同じドメインにアクセスしても、HTTPインバウンドからの通信は一致しません。次のルールにはループバック、プライベート、一部のローカルアドレス範囲を指定していますが、特殊用途アドレスを網羅した完全な一覧ではありません。実運用でより広い分類が必要な場合は、内容を確認したデータセットを使い、更新方法と適用範囲も把握してください。

ドメイン式は指定範囲を意識して使う

full: は完全一致に使い、特定のホスト名だけを指定する場合に適しています。domain: は指定したドメインとそのサブドメインに一致します。接頭辞のない式はキーワードとして照合される場合があり、見た目より広い範囲に適用されることがあります。正規表現ではJSONのエスケープ規則にも注意が必要です。範囲の広すぎる式は、意図の把握やメンテナンスも難しくなります。完全一致やドメインのサフィックスで表せる場合は、より明確な書き方を優先してください。

ドメインルールが照合するのは、リクエストに含まれるかカーネルが認識した宛先情報であり、ウェブページが最終的に読み込むすべてのリソースではありません。一つのページから複数のドメインへリクエストが送られることがあります。メインページが指定した出口を使っても、画像、API、動画まで同じ出口を使うとは限りません。ルールを診断する際は個別の宛先リクエストを選び、ページ全体の結果を特定のドメインルールの証拠とみなさないようにしましょう。

名前解決のポリシーが変えるのは照合の過程

AsIs はルーティングのIP照合のためにドメインを積極的に名前解決しません。リクエスト自体がIPアドレスなら、IPルールは引き続き照合できます。IPIfNonMatch は、ドメイン宛てのリクエストが既存ルールに一致しない場合に名前解決してから照合します。IPOnDemand は、ルーティング処理でIP情報が必要になった時点で名前解決します。これらはシステムDNSのオン・オフや、アウトバウンド側のドメイン解決ポリシーではありません。

名前解決を行うポリシーに切り替えると、遅延やルールの一致結果が変わることがあります。DNSが異なる地域のアドレスを返せば、IP分類ルールが別の出口を選ぶ場合もあります。反対に、アプリがカーネルの外でドメインをIPアドレスに変換済みの場合、カーネルの名前解決ポリシーを変えても元のドメイン情報は復元できません。DNSアドレスを次々に入れ替えるのではなく、インバウンドのプロトコル、スニッフィング、アプリ側の名前解決方法をあわせて確認してください。

例外、分類、フォールバックでルールを構成する

まず明示的に拒否する宛先や指定の出口に送る宛先を具体的に指定し、次にローカルネットワークや用途別の分類を置き、最後に残りの通信を処理します。適切な順序はポリシーによって異なりますが、各ルールをなぜその位置に置くのか説明できる状態にしてください。末尾にすべての宛先に一致するルールを置くと、それより後のルールは使われません。末尾のルールを置かない場合は、最初のアウトバウンドがデフォルトの出口になることを理解しておきましょう。

geosite: や geoip: の分類を使うには、対応するデータファイルと有効な分類名が必要です。カーネルが構文をサポートしていても、実行環境に必要なデータが用意されているとは限りません。更新後に分類の読み込みに失敗した場合は、データファイルのパスと分類名を先に確認し、すべてのルーティングルールを削除するのは避けてください。生成設定、クライアント内蔵ルール、カスタムルールでは並び順が異なる場合もあるため、実行中の設定を確認しましょう。

ルールを変更したら、ログで宛先、送信元、アウトバウンドが想定どおりか確認してください。「一部のサイトだけ動かない」場合は、まず実際に選ばれた出口を比較し、次にDNSと接続の過程を確認します。クライアントの全体スイッチやノードの色だけでは、個々のリクエストの経路は判断できません。長期的な運用では、同じルールを追加し続けるより、ルールのグループに短い説明を残すほうが、変更を戻しやすくなります。

05 / DNS

dns 名前解決と接続経路

DNSの問題では、まず「どこで名前解決しているか」を確認します。アプリが独自に問い合わせることも、OSが代わりに名前解決することも、カーネル内蔵のリゾルバーを使うこともあります。リモートプロキシが接続先ドメインを向こう側で解決する場合もあります。トップレベルの dns は主にカーネル内蔵の名前解決動作を設定するもので、端末上のすべてのアプリのDNS設定を自動で変更するわけではありません。サーバーを設定に追加しても、実際の問い合わせがそのリゾルバーを通るか確認が必要です。

名前解決する場所と問い合わせの出口を区別する

SOCKSでは、アプリがドメイン名をそのままプロキシに渡す場合と、ローカルでIPアドレスを取得してから接続する場合があります。HTTPプロキシのリクエストには通常ドメイン名を含められますが、アプリが事前に名前解決することもあります。仮想ネットワークによる通信の取り込みでは、DNSリクエストの処理方法も関わります。カーネルに渡される情報がドメイン名かIPアドレスかを把握して初めて、ドメインルーティング、内蔵DNS、アウトバウンド側の名前解決がそれぞれ関与するか判断できます。

以下は dns 項目の抜粋で、静的ホストマッピング、サーバーリスト、アドレスファミリーの選択を示しています。例には到達可能なパブリックDNSアドレスを使用していますが、ネットワークによっては接続が制限されることがあり、組織内の名前解決が必要な場合もあります。アドレスをそのままコピーすればDNSの問題がすべて解決するわけではありません。実際のネットワークに合わせて選択してください。

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

192.0.2.10 はドキュメント用の例示アドレスです。このマッピングは形式を示すもので、実際に利用できるウェブサービスではありません。静的マッピングを使う際は注意が必要です。対象ドメインが指定したアドレスに固定され、負荷分散、サービス移行、証明書との対応に影響することがあります。テスト後は例のマッピングを削除し、実際に必要なドメインと確認済みのアドレスを使って本番用のルールを設定してください。

DNSポリシーとルーティングポリシーは別の設定

queryStrategy は内蔵DNSが問い合わせる、または返すアドレスファミリーの傾向を制御します。ルーティングの domainStrategy は照合時にドメインのIPアドレスを取得するかどうかを制御します。直結アウトバウンドにも独自の名前解決ポリシーがある場合があります。どれも名前解決に関わりますが、適用される場所は異なります。トップレベルのDNSを変更しても、直結アウトバウンドが同じ方法で結果を使うとは限らず、リモートプロキシのアウトバウンドがすべてローカルで宛先を名前解決するわけでもありません。

従来形式の直結アウトバウンドで内蔵DNSの結果を使う場合は、カーネルの対応状況に応じて該当するポリシーを設定できます。以下の抜粋では直結アウトバウンドに UseIP を追加し、ドメイン名への接続時にIPアドレスを取得するよう指定しています。ルーティング段階の照合順序を決めたり、他のアウトバウンドを変更したりする設定ではありません。利用できるポリシー名やアドレスファミリーごとの値は、実行中のカーネルの項目定義を確認してください。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIP"
      }
    }
  ]
}

DNSの問い合わせにも通信経路が必要

内蔵DNSが発生させるネットワーク通信には、到達可能な経路が必要です。通常のアドレス、暗号化DNSのアドレス、ローカルシステムによる名前解決など、サーバーの種類によって接続方法が異なり、すべてが同じルーティングに従うとは限りません。DNSリクエストにタグを付けて個別にルーティングする方法は、より詳細な設定です。現在のカーネルがどう対応しているかを確認してください。DNSアドレスを設定すれば、選択中のリモートノードを自動で経由するとは限りません。

起動時の依存関係が循環しないよう注意してください。リモートノードのアドレスがドメイン名で、DNSサーバーにはそのリモートノード経由でしか接続できない場合、リモート接続に必要な名前解決ができない可能性があります。暗号化DNSサービス自体がドメイン名の場合も、初回の名前解決が必要です。トラブルシューティングでは、まずノードのアドレスとDNSサーバーを最初に名前解決する経路を確保してから、各サービスのドメインを最終的にどこで解決するか検討してください。

アドレスファミリー、キャッシュ、ドメイン別の名前解決

端末にIPv6アドレスがあるからといって、宛先までのIPv6経路が正常とは限りません。IPv4のみを問い合わせる設定は一部の問題を切り分けるのに役立ちますが、すべての環境で長期的に使える解決策ではありません。特定のアドレスファミリーだけ失敗する場合は、ルーティング、インターフェース、上流への接続を確認してください。デュアルスタック環境では、DNSの応答と実際に選ばれる接続先が異なる場合があります。応答一覧の先頭だけで判断せず、ログに記録された宛先アドレスも確認しましょう。

サーバーを切り替えた後も、アプリ、OS、カーネル、上流側にキャッシュが残っていることがあります。検証時は既存の接続を閉じ、クライアントが提供する方法で関連コンポーネントを再起動してください。必要に応じてシステムのキャッシュも処理し、新しいリクエストを送ります。既存の接続が古いアドレスを使い続けていても、新しい設定が保存されていないとは限りません。キャッシュの消去、ノードの変更、ルールの変更を同時に行うと、復旧しても原因を特定できなくなるため避けてください。

ドメインごとにDNSサーバーを使い分ける場合は、ルール一覧、想定するアドレス範囲、フォールバック設定が相互に影響します。異なるDNSビューが本当に必要な場合に限って構成を複雑にし、ドメインごとの用途を記録しましょう。内部ドメインは、名前を認識できる組織内のDNSサーバーに問い合わせる必要があります。接続は確立するのにページを開けない場合は、接続後にインターネットを利用できない場合のチェックリストを参考に、システムプロキシ、ルーティング、接続先サービスを確認してください。

06 / POLICY

policy 接続と統計のポリシー

policy は、ユーザーレベルに応じた接続動作と、システムレベルの一部の統計設定を定義します。トラフィックを振り分けたり、ノードを選択したりするルールではなく、タイムアウト値を小さくしても接続が速くなるわけではありません。多くの構成はポリシーを手動で変更しなくても動作します。リソース管理、接続の維持、統計など明確な要件がある場合に限り、項目を一つずつ変更して実際の通信を確認してください。

レベルオブジェクトとユーザー項目の関連付け

levels はレベル番号をオブジェクトのキーとして指定します。たとえば "0" のように記述します。プロトコルのユーザーオブジェクトにある level は、適用するポリシーレベルを選択しますが、ユーザーの構造はプロトコルごとに異なります。ローカルインバウンドの設定によっては、デフォルトのユーザーレベルも指定できます。level を任意のトップレベルに追加したり、ノード一覧の並びからユーザーレベルを推測したりしないでください。

以下はポリシー項目の抜粋で、レベルとシステム統計設定の階層を示しています。記載した数値は説明用で、あらゆるネットワークに推奨される値ではありません。特に接続の再利用、トランスポート、プロトコルの実装によって、実際のカーネルではデフォルト値や動作の細部が異なる場合があります。要件が明確でない場合は、いわゆる最適化パラメーターをまとめてコピーするより、デフォルトのポリシーを保つほうが管理しやすくなります。

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

タイムアウト項目で対処できる問題

handshake は、関連する接続のハンドシェイク段階における時間制限を設定します。ウェブページを開いてから読み込みが終わるまでの合計時間ではありません。ネットワーク遅延、上流からの応答、プロトコルのネゴシエーションに時間がかかっている場合、制限が短すぎると本来成立する接続まで途中で終了することがあります。ハンドシェイクがタイムアウトする場合は、時間制限を変更する前に、サーバーアドレス、ポート、安全性に関する設定を確認してください。

connIdle はアイドル状態の接続を維持する時間を制限します。チャット、プッシュ通知、ロングポーリングでは通信量が少ない状態が長く続くことがあり、アイドル時間を短くしすぎると再接続が増えることがあります。一方で、使われていない接続を長時間維持すればリソースを消費する可能性もあります。評価時は、アクティブな接続数が減っただけで最適化できたと判断せず、アイドル状態から切断されたことで業務に影響が出るかを確認してください。

uplinkOnly と downlinkOnly は、一方の接続が終了した後も反対方向への転送を続ける段階に関わります。一般的な意味でのアップロード・ダウンロード速度制限ではなく、帯域の上限設定には使えません。半クローズの処理はプロトコルやトランスポートによって異なるため、一方向の通信が途切れた場合も、この二つの値を増やすだけで解決しようとせず、プロトコルの動作とログを確認してください。

統計の設定だけでは統計システムにならない

ポリシーの統計項目を有効にしても、対応するカウンターが記録されるだけで、可視化パネルが自動で表示されるわけではありません。統計を利用するには通常、統計モジュール、対応する管理インターフェース、データを取得するツールも必要です。ユーザー単位で集計する場合は、ユーザーを識別できる情報も必要になります。クライアントがこうした設定をすでに生成している場合は、クライアント側の実装全体を確認してください。同じポートに管理用の入口を追加して競合させないようにしましょう。

クライアントに表示される通信量は、カーネル内の特定のカウンターと一致するとは限りません。通信の取り込み範囲、再接続、プロトコルのオーバーヘッド、計測位置によって数値が変わります。通信量を比較する際は、どの層でいつから計測したのか、すべての入口が対象かを明確にしてください。画面上の数値を上流サービスの請求根拠とみなしたり、統計の範囲を把握せずに計測エラーと判断したりするのは避けましょう。

一律の値を求めず、実際の用途で検証する

ポリシーを変更する際は、実際の利用シーンを想定して検証してください。短いウェブリクエストでは初回接続と連続リクエストを確認し、長時間接続を使うアプリではアイドル後にデータ転送が再開するかを観察します。大容量ファイルの転送では、一方向の終了や接続の維持によって途中で切断されないか確認してください。一度に変更する項目は一つに絞り、変更前の値、テスト方法、結果を記録すれば、ネットワークの変動とポリシーの影響を区別できます。

端末のリソースが不足している場合は、カーネルの重複起動、過剰な速度テスト、不必要なバックグラウンドリクエストも確認してください。ポリシーはあらゆるリソース問題を解決する万能スイッチではありません。接続管理がボトルネックである証拠がなければ、すべてのタイムアウトを短くするより、不要なタスクや使用していない入口を整理するほうが直接的です。元に戻す場合はクライアントのデフォルトポリシーに戻し、同じテストで再確認して、出どころのわからない値を使い続けないようにしましょう。

07 / LOG

log ログとエラーの特定

ログは特定のリクエストで何が起きたかを示すもので、英語のエラーが一行あるだけで原因箇所を特定できるわけではありません。発生時刻、インバウンドの送信元、宛先アドレス、アウトバウンドタグ、その後の状態をあわせて確認してください。バックグラウンドアプリが通信を続けていると、複数のサイトを同時にテストした際に、別のリクエストのエラーを現在の操作と結び付けてしまうことがあります。診断を始める前に通信の範囲を絞り、対象を一つに決めて再現しましょう。

ログレベルと出力先

loglevel はエラーログの詳細度を指定します。一般的なレベルには debug、info、warning、error、none があります。通常は控えめなレベルにし、ルーティングや接続の調査時だけ詳細度を上げるとよいでしょう。詳細なログは量が多く、宛先情報を含む場合もあります。原因を特定したら元の設定に戻し、不要なデータを長期間蓄積しないようにしてください。

{
  "log": {
    "access": "access.log",
    "error": "error.log",
    "loglevel": "info"
  }
}

以下はファイル出力に関する項目の抜粋です。相対パスは通常、プロセスの作業ディレクトリを基準とするため、設定ファイルの保存場所と一致するとは限りません。GUIクライアントが標準出力を取り込み、実行ログの画面に表示する場合もあります。ログファイルが見つからない場合は、起動方法、作業ディレクトリ、書き込み権限を確認してください。ファイルがないからといって、カーネルが動作していないとは限りません。保存場所を固定する場合は、端末に実在し、書き込みが許可されたパスを使ってください。

アクセスログとエラーログは用途が異なります。アクセス記録からリクエストの受信や経路を確認できますが、アクセス記録があっても宛先のデータが最後まで転送されたとは限りません。表示される項目はカーネルやログレベルによって異なる場合があります。想定したアウトバウンドタグが見つからない場合は、一時的にログの詳細度を上げるか、実際の設定でルールを確認してください。デフォルトの経路を推測する根拠にしないようにしましょう。

処理の流れに沿ってよくあるエラーを読む

connection refused は通常、接続先アドレスの相手側が接続を明示的に拒否したことを示します。宛先がローカルのプロキシポートなら、カーネルが待ち受けているか確認してください。リモートノードのポートなら、サービスの稼働状況、アドレス、ポート番号を確認します。認証は通常、接続が確立した後に行われるため、このエラーがそのまま認証失敗を意味するわけではありません。ログ内のアドレスがどの階層に属するかを先に特定してください。

i/o timeout は読み書きのいずれかの段階で待ち時間を超えたことを示しますが、接続確立、ハンドシェイク、データ転送のどこで起きたかは特定できません。アドレスへの到達不能、応答の欠落、経路上のパケットロス、プロトコルの不一致など、さまざまな原因で同じように見えることがあります。同じリクエストの前のログをたどり、最後に完了した段階を確認してください。すべてのタイムアウト値を大きくしても、待ち時間が延びるだけで接続経路の問題は解決しないことがほとんどです。

TLS関連のエラーでは、システム時刻、サーバー名、証明書チェーン、安全性に関する設定を確認してください。IPアドレスで接続する場合とドメイン名で検証する場合では、要件が異なることがあります。トランスポート層のホスト名も証明書名とは別です。サーバーが特定のセキュリティプロトコルを要求しているのにクライアントが別の設定を使っていると、ポートには接続できてもハンドシェイクに失敗することがあります。すべての検証を無効にするのではなく、項目の組み合わせを正してください。

起動時のエラーと実行中のエラーを分けて対処する

起動前の失敗は、JSON構文、項目の型、認識できないプロトコル、データファイル、ポートのバインドが原因であることがよくあります。まずカーネルを安定して起動できる状態にしてから、ネットワークをテストしてください。実行中の失敗は、リクエスト単位で追跡します。クライアントが起動と終了を繰り返す場合は、起動メッセージが繰り返し表示されるだけで正常動作していると判断しないでください。最初に発生した致命的なエラーを見つけましょう。その後の接続エラーは、カーネルがすでに終了しているために起きている可能性があります。

タグが見つからない場合は、ルールの参照先とアウトバウンド配列を確認してください。分類データの読み込みに失敗した場合は、データファイルと分類名を確認します。権限エラーなら、出力先のディレクトリや通信の取り込みに必要な権限を調べます。エラーを消すためだけにモジュール全体を削除しないでください。各エラーを対応する設定オブジェクトと結び付け、その範囲内で修正してから、同じ起動テストまたはリクエストテストを再実行しましょう。

必要な情報を残し、機密情報を伏せる

ログを共有して相談する前に、ユーザー情報、サブスクリプションURL全体、リモートノードの認証情報、公開したくないアクセス先を削除してください。スクリーンショットではウィンドウのタイトル、クリップボードの内容、サイドバーも確認しましょう。調査に必要な情報として、項目名、エラーの種類、前後の時間関係、匿名化したタグは残せます。重要な前後関係を省いて最後の一行だけを切り取らないでください。

テスト時刻、使用した入口、テスト対象、想定する出口、実際の結果を記録し、一連の証拠として残すことをおすすめします。ルールを変更してもエラーが変わらない場合は、実行設定が本当に更新されたか、古いプロセスが停止したか、テストアプリが既存の接続を再利用していないか確認してください。エラーの詳しい意味はv2rayNの実行ログで原因を特定する方法も参照できます。最終的な判断は、現在の設定と同一リクエストのログに基づいて行ってください。

ログファイルの保存範囲も管理が必要です。長期間稼働する環境では、クライアントの機能に応じて定期的に削除またはローテーションし、ディスク使用量が増え続けないようにしてください。書き込み中のファイルを削除してすぐに容量が解放されるかは、システムの動作によって異なります。メンテナンス時は、関連するログ出力を停止するかカーネルを終了しておくと安全です。ログの目的は再現と診断を支えることであり、すべてのアクセスを無期限に記録することではありません。

08 / VALIDATION

設定の検証と変更の管理

設定の検証は、テキスト、構造、起動、通信経路、実際の用途の五段階に分けて行います。テキストを解析できても項目が有効とは限らず、項目が有効でもポートが待ち受けられるとは限りません。待ち受けが正常でもリクエストが正しい出口を使うとは限らず、接続に成功してもすべてのアプリが通信の取り込み対象になったとは限りません。段階を追って確認すれば、上流の問題が解決していない段階で下流の設定を何度も変更せずに済みます。

元の設定と変更の目的を記録する

変更前に、正常に動作していることが確認済みの設定を保存し、対応するクライアント、カーネル、動作モードを記録してください。バックアップは管理された場所に保管し、認証情報を含むファイルを安易に同期したり公開したりしないようにします。ファイル名に用途とローカルでの管理日を付けてもかまいませんが、「最終版」のような曖昧な名前だけに頼らないでください。元に戻す際は、その設定がどの入口、出口、ルールに対応するかも把握しておきましょう。ファイルが開けたことだけでは不十分です。

変更ごとに、期待する結果を明記してください。たとえば「指定したドメインを直結にする」「テスト用の入口を追加する」といった内容です。その効果を直接確認できるリクエストも用意しましょう。一つのドメインだけを修正する場合、DNSや接続ポリシー全体を同時に変える必要はありません。変更範囲を小さくすれば、テストに失敗したときに確認する差分が減り、変更を戻すべきか判断しやすくなります。

第1段階：構文と構造の確認

不明なオンラインツールに設定をアップロードせず、ローカルエディターのJSON診断機能で括弧、引用符、カンマ、項目の型を確認してください。次に、各トップレベル項目が正しい場所にあるかを調べます。スニッフィングの設定は個々のインバウンドに、アウトバウンドの設定は該当するアウトバウンドに、ルールは routing.rules に置きます。構造の位置が間違っていても、一般的なJSON解析には成功することがあり、単純なスペルミスより見つけにくい場合があります。

参照関係もすべて確認してください。ルールが参照するアウトバウンドタグが存在するか、インバウンドタグが完全一致しているか、分類名が現在のデータファイルにあるか、ログの保存先に書き込みできるかを調べます。タグは自動で連動する変数ではなく、片方を変更してももう片方は更新されません。対応表には画面上の表示名と実際のタグを両方記録し、クライアント画面の名称をカーネルの項目値と取り違えないようにしましょう。

第2段階：起動とローカル経路

クライアントの設定チェック機能や実行情報を使って、カーネルが設定を読み込めることを確認してください。カーネルごとにコマンドラインでの確認方法は異なるため、このページでは特定の起動オプションを共通コマンドとして扱いません。起動後はローカルの待ち受けを確認し、プロキシに対応したテストアプリからその入口を明示的に使います。受信ログがない場合は、プロキシのアドレス、ポート、アプリの設定、システムの許可を確認してください。

まず第1章の完全な直結基本設定に戻し、ローカルのリクエストを受信して送信できるか確認してください。基本設定でも失敗するなら、リモートノードのセキュリティ項目を調べる必要はありません。基本設定は成功し、カスタム設定が失敗する場合は、インバウンド、アウトバウンド、ルーティング、DNS、ポリシーの順に設定を段階的に戻してください。各段階で再起動してテストし、最初に差が生じる箇所を見つけましょう。

第3段階：ルーティングと実際の用途を再確認

指定した出口を使うはずの宛先を一つ選び、そのルールの影響を受けないはずの宛先も対照として選びます。両方の実際のアウトバウンドを記録し、ルールの適用範囲が広がりすぎていないことを確認してください。ドメインルールではサブドメイン、ページ内のリソース、リダイレクトも考慮します。ポートルールでは宛先ポートとローカルの待ち受けポートを区別してください。対照テストは、ウェブページが一度開いたことだけを見るよりも、ルールの意図と実際の動作が一致していることを確認しやすくなります。

同じカーネル設定でも、OSによってファイルのパス、待ち受け権限、通信の取り込み方法が異なる場合があります。アプリ独自のネットワーク設定も、デスクトップ環境の設定に従うとは限りません。ある端末で動作した設定のノードだけを変更して、別の端末でもまったく同じ経路になると考えないでください。環境を移行したら、まず入口と権限を検証してから、プロトコルやルーティングの設定を再利用しましょう。

更新、ロールバック、継続的な参照

クライアントを更新したりカーネルを切り替えたりする際は、古い設定と変更履歴を残し、生成された設定に従来のルールが含まれているか確認してください。サブスクリプションの更新で主に変わるのはノード情報であり、実行設定全体のバージョン管理が行われるとは限りません。カスタム項目が上書きされた場合は、クライアントが提供する永続的な設定方法に切り替えましょう。一時ファイルを何度も編集する方法を定常的なメンテナンス手順にしないでください。

問題が起きたら、まず直近で関係する変更を取り消し、同じテストを再実行してください。復旧した後は変更前後の差分を比べ、該当する項目を特定します。分析せずに古いファイル全体へ永久に置き換えるだけでは、原因がわからないままになります。カーネルの違いが関係する場合は、元のプロトコルとトランスポートの組み合わせを維持し、クライアント、カーネル、ノード、ルールを一度に変更してテスト条件をすべて変えないようにしましょう。

日常的な接続操作はクイックスタートガイドの手順に沿って進めてください。別のプラットフォームへ移行する場合やクライアントを選ぶ場合は3つのクライアントの比較を、インストーラーはダウンロードページをご覧ください。このページでは設定項目ごとに確認先をまとめています。受信の問題はインバウンド、出口の問題はアウトバウンド、照合の問題はルーティング、ドメインの問題はDNS、接続維持の問題はポリシーを確認し、最後にログと対照テストで判断を検証してください。