V2Ray 設定ファイル完全ガイド

01 / CONFIG ROOT

JSON構造の全体像とデータフロー

設定はノード情報を並べただけのものではない

V2Ray設定ファイルのルートは1つのJSONオブジェクトです。主なトップレベルフィールドにはlog、dns、inbounds、outbounds、routing、policy、statsがあります。inboundsは端末上のアプリから送られた接続を受け付け、outboundsは接続が最終的にどこから出ていくかを決め、routingは各接続をいずれかのoutboundへ割り当てます。DNSはドメインの照合と宛先解決に結果を提供し、policyとstatsは接続単位の動作を制御します。フィールドを暗記するより、この流れを理解することが重要です。アプリの接続がinboundポートに入り、コアが宛先ドメインまたはIPを認識し、ルーティングルールを上から順に照合して、該当後にoutboundタグを選択します。必要に応じてDNSが解決を行い、最後に対応するoutboundが接続を確立します。

クライアントが生成する設定は、手書きの例より複雑になることがあります。GUIクライアントがローカル管理インターフェース、統計用の入口、複数のDNSサーバー、互換用フィールドなどを追加するためです。見慣れないフィールドを見つけても、いきなりブロック全体を削除しないでください。まずどのトップレベルモジュールに属するかを確認し、別のモジュールからタグで参照されていないかを調べます。たとえばルーティングルールのoutboundTagは、いずれかのoutboundのtagに対応していなければなりません。policyのレベル番号は、ユーザーやinboundが使用するレベルと一致させる必要があります。DNSのtagが、ルーティングルールで独立したトラフィック入口として扱われることもあります。

JSONの構文と型の制約

JSONは句読点とデータ型に厳密です。オブジェクトには波括弧、配列には角括弧を使い、文字列は必ず二重引用符で囲みます。オブジェクトのメンバー間にはカンマが必要ですが、最後のメンバーの後に末尾カンマは置けません。真偽値はtrueまたはfalseと記述し、文字列にはできません。ポートは通常数値であり、"10808"と書くとJSON構文の検査を通っても、コアのフィールド検証に通らない場合があります。コメントは標準JSONの一部ではないため、//やブロックコメントを含む例をコピーすると、「invalid character」のような解析エラーになることがあります。

フィールド名は大文字と小文字を区別します。outboundTagとoutboundtagは同じフィールドではなく、domainStrategyも自由に書き換えられません。もう1つ多いのが階層の誤りです。プロトコル固有のパラメーターは通常、そのオブジェクトのsettings内に置き、トランスポートのパラメーターはstreamSettings内に置きます。サーバーアドレスをoutboundのルート階層に直接置くことはできません。「unknown field」が出たら、まずフィールドの所属階層を確認し、ネットワークを疑うのはその後にしましょう。

最小構成から段階的に拡張する

設定を手動で管理する場合は、起動できる最小構成から始めます。ローカルinboundを1つ、利用可能なoutboundを1つ、direct outboundを1つ、少数のルーティングルールを用意します。コアがファイルを読み込めることを確認してから、DNS、複雑なルール、policy項目を追加してください。こうすれば「構文エラー」「プロトコルパラメーターのエラー」「ルーティングロジックのエラー」を切り分けられます。数百行の設定を一度に貼り付けると手間は省けますが、括弧のずれ1つで原因特定のコストが急増します。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ]
}

GUIクライアントで設定を保存すると、設定ファイルが再生成されることがあります。そのため、一時ファイルを手動で編集しても永続化されるとは限りません。長期的に使うルールは、クライアントが提供するカスタム設定、ルーティングルール、DNS設定の入口に登録するのが基本です。起動失敗の分析だけが目的なら、現在の設定をエクスポートまたは別の場所へコピーしてから段階的に削減してテストし、次回のサブスクリプション更新で調査中の状態が上書きされないようにしてください。

02 / INBOUNDS

inbounds：リッスン、認証、トラフィック識別

inboundが端末上のアプリの接続方法を決める

inboundsは配列であり、1つの設定に複数のローカル入口を用意できます。デスクトップクライアントではSOCKSとHTTPの2種類が一般的です。ブラウザーやプロキシ設定に対応したアプリはHTTP入口へ、SOCKS5に対応したプログラムはSOCKS入口へ接続します。透過プロキシ、トンネルインターフェース、LAN共有はより複雑な接続方式なので、まず基本的なローカルプロキシが正常に動くことを確認してから有効にしてください。各inboundには、socks-inやhttp-inのように、分かりやすく重複しないtagを設定すると、入口ごとのルーティングが容易になります。

listenは待ち受けアドレスを決めます。127.0.0.1にすると通常は現在の端末からだけ接続でき、個人用のデスクトップ環境に適しています。LANからアクセスできるアドレスへ変更すると接続可能な範囲が広がるため、システムファイアウォール、inbound認証、ネットワーク境界も同時に検討する必要があります。「アプリがローカルポートへ接続できない」という理由だけで待ち受け範囲を広げないでください。まずクライアントが起動しているか、ポートが使用中でないか、アプリのプロキシ種別がinboundプロトコルと一致しているかを確認します。

portはローカルの待ち受けポートで、システムプロキシやアプリ内のプロキシ設定と一致させる必要があります。ポート番号に固定の決まりはありませんが、同じアドレス上で2つのプログラムが同じポートを同時に使用することはできません。ログにaddress already in useと出たら、競合しているプロセスを終了するか、待ち受けポートを変更し、クライアントを二重起動していないか確認します。ポートを変更した後は、ブラウザー、ターミナルの環境変数、その他のアプリのプロキシアドレスも更新してください。コアが正常に起動していても、アプリのトラフィックが入らない場合があります。

SOCKSとHTTPのinboundパラメーター

SOCKS inboundのsettingsには、通常authとudpが含まれます。ループバックアドレスで個人利用する場合はnoauthが一般的ですが、待ち受け範囲を広げるならクライアントの対応状況に応じてアクセス制御を設定してください。udpは、そのinboundがUDPリクエストを受け付けるかどうかを決めますが、リモートプロトコル、outbound経路、宛先サービスがUDPに対応することを自動的に保証するものではありません。HTTP inboundは主にHTTPプロキシリクエストとCONNECTトンネルを処理するため、アプリがHTTPプロキシモードに明示的に対応している必要があります。SOCKSポートをHTTPプロキシ欄に入力すると、接続直後に切断されたり、ハンドシェイク形式のエラーになったりします。

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

sniffingの役割と限界

sniffingは接続初期のデータから宛先ドメインを識別し、本来は宛先IPしか取得できないトラフィックでもドメインルールで振り分けられるようにします。destOverrideでは、識別可能なHTTPホスト情報とTLSハンドシェイク内のサーバー名に対応するhttpとtlsがよく使われます。これはWebページの内容を復号する機能ではなく、すべての接続でドメインを復元できるわけでもありません。暗号化されたクライアントの挨拶の変化、標準外プロトコル、IPへの直接アクセスでは、ルーティングがIPしか認識できないことがあります。

トラフィック識別を有効にした後、特定アプリの宛先が書き換えられたり接続動作が不自然になったりした場合は、まず必要なoverrideの種類だけを残し、ログと照合してください。ルーティングを識別結果だけに依存してはいけません。重要なLAN、予約済みアドレス、既知のIP範囲には、引き続きIPルールを設定します。一方、識別を無効にすると、多くのドメインルールが一致しなくなる可能性があります。特に、システムが先に名前解決を行い、宛先IPだけを渡すアプリでは顕著です。使用するかどうかはinbound方式とアプリの動作を踏まえて判断し、同じ設定を機械的に適用しないでください。

複数inboundの役割分担

複数のinboundは異なるプロキシ種別に対応するだけでなく、異なるルーティングポリシーを割り当てるためにも使えます。たとえば一方のSOCKS inboundは通常の振り分け、もう一方は特定のoutboundへ固定します。ルーティングルールでinboundTagを使って入口を照合し、送信先のoutboundTagを指定してください。入口専用のルールは汎用的なドメインルールより前に置きます。そうしないと、接続が先に広範囲のルールへ捕捉されることがあります。

inboundの調査は3段階で確認できます。まずコアのログにリッスン成功が表示されるか、次にローカルに対応する待ち受けポートが存在するか、最後にアプリのリクエストが実際に入っているかを確認します。コアが接続を受け取っていないなら、問題は通常、アプリのプロキシ設定、システムプロキシの状態、ポート競合にあります。接続を受け取っているのに宛先へ到達できない場合は、routing、outbound、DNSへ進みます。最初の段階を確認する前に、サーバー側のプロトコルパラメーターを何度も変更しないでください。

03 / OUTBOUNDS

outbounds：プロトコル、サーバー、トランスポート層

outbound配列とタグの設計

outboundsは、接続がコアから外へ出る方法を記述します。一般的な設定には、少なくともプロキシoutbound、freedomによる直接接続outbound、blackholeによるブロックoutboundを1つずつ含めます。プロキシoutboundはリモートサーバーへ接続し、direct outboundは端末のネットワークで宛先へアクセスし、block outboundは特定の接続を明示的に拒否します。routingモジュールはタグだけで出口を選ぶため、タグは安定して短く、用途が分かるものにします。たとえばproxy、direct、blockです。ノードを交換するときも、proxy内部のサーバーパラメーターを変更するだけで、すべてのルーティングルールを書き直さずに済みます。

配列の順序は、明示的なルーティング結果がない場合に使用されるデフォルト出口へ影響することがあります。暗黙の動作に依存しないよう、重要なトラフィックはルールで明示的にタグへ送ってください。主要なプロキシoutboundも見つけやすい位置に保ちます。GUIクライアントが現在のノードに応じて先頭項目を動的に変更する場合もあるため、設定を手動で統合するときは配列の位置だけで出口の用途を判断せず、tag、protocol、プロトコル設定も確認します。

プロトコルパラメーターとトランスポートパラメーターの階層

プロキシoutboundは通常、2つの部分に分かれます。settingsにはプロトコル自体が必要とするサーバー、ポート、ユーザー情報を保存し、streamSettingsには基盤ネットワーク、TLS、REALITY、WebSocketなどのトランスポート設定を保存します。両方をサーバー側と一致させる必要があります。プロトコルは正しくてもトランスポート層が一致しない場合、TCP接続後にハンドシェイクが失敗することがよくあります。トランスポート層が正しくてもユーザー識別子が誤っていれば、リモート側から即座に拒否されることがあります。

以下はVLESS outboundの構造上の位置を示す例です。ドメイン、識別子、公鍵は構造説明用のサンプル値なので、使用時は実際の設定に置き換えてください。securityはユーザーオブジェクト内にあり、VLESSユーザー層の設定を示します。一方、streamSettings内にもsecurityがあり、こちらはトランスポートのセキュリティ方式を示します。同名のフィールドでも階層が異なるため、互いに置き換えることはできません。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-4000-8000-000000000000",
                "encryption": "none",
                "flow": "xtls-rprx-vision"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "serverName": "www.example.com",
          "fingerprint": "chrome",
          "publicKey": "replace-with-server-public-key",
          "shortId": "0123456789abcdef"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "response": {
          "type": "none"
        }
      }
    }
  ]
}

address、serverName、宛先ドメインは別のもの

addressはクライアントが実際に接続するサーバーアドレスで、ドメインまたはIPを指定できます。TLSやREALITY関連のserverNameは、ハンドシェイクで使用するサーバー名です。両者が同じ場合もあれば、サーバー側の設定で決まる場合もあります。routingにおける宛先ドメインは、アプリが本来アクセスしようとしたサイトです。トラブル対処ではこの3つを区別してください。サーバーアドレスの名前解決失敗は接続入口の問題、サーバー名の不一致は通常ハンドシェイク失敗、アプリの宛先ドメインが誤った出口へ進む場合はルーティングの問題です。

サーバーアドレスにドメインを使う場合、コアはプロキシ接続を確立する前にそのドメインも解決する必要があります。DNSルールが過剰に積極的だと、サーバードメイン自体の解決がまだ確立していないプロキシ経路へ送られ、循環依存になることがあります。安全策として、サーバードメイン用に利用可能な初期解決経路を用意するか、クライアントが提供するサーバーアドレスの処理方式に合わせて設定してください。DNS変更後にすべてのノードが同時に使えなくなった場合は、ノードを1つずつ再入力する前に、この層を確認します。

複数プロキシoutboundと選択の関係

1つの設定に複数のプロキシoutboundを含めることができます。たとえばproxy-mainとproxy-altです。ただし、V2Rayコア設定で複数のoutboundを定義しても、GUIクライアントの遅延選択や自動フェイルオーバーになるわけではありません。実際の選択は、ルーティングルール、負荷分散ポリシー、クライアントの生成ロジックによって決まります。ノードオブジェクトを配列に追加するだけで自動切り替えを期待しないでください。v2rayN、v2rayNG、v2flyNGのノード選択画面は対応する設定を生成しますが、手動設定では各タグを誰が参照するのか明確にする必要があります。

outboundの失敗は外側から内側へ調べます。サーバーアドレスを解決できるか、宛先ポートへ接続できるか、プロトコルのユーザーフィールドが正しいか、最後にトランスポートのセキュリティとネットワーク種別を確認します。ログのtimeoutは、アドレス、ポート、経路に到達できないことを示す場合が多く、handshake failedはトランスポート層のパラメーターに近いエラーです。invalid userや認証関連のメッセージなら、ユーザー識別子に戻って確認します。TLSエラーの詳しい分類はTLS証明書エラーのトラブル対処チェックリストで確認できます。

04 / ROUTING

routingルール：照合順序と振り分けの書き方

ルールは上から順に適用される

routing.rulesは順序を持つルール配列です。コアは接続の属性を1件ずつ確認し、通常は適用可能なルールに一致すると対応するoutboundを選択します。そのため、ルールの順番が結果を直接左右します。範囲が具体的で優先度の高いルールを前に置き、フォールバックのルールを後ろに置いてください。たとえば不要なプロトコルをブロックし、内部ネットワークアドレスを処理し、特定のドメインをdirectへ送ってから、プロキシまたはデフォルト出口を設定します。先に範囲の広いドメインルールを書くと、後ろの精密なルールは構文が正しくても適用されないことがあります。

ルール内の複数の照合項目は、通常、1つの接続に対する条件を組み合わせるために使います。たとえばinboundTagとdomainを同じルールに含めると、指定したinboundから来て、かつドメイン条件を満たす接続を意味します。1つの項目内に複数の値を並べた場合は、通常、その項目のいずれかに一致すれば命中します。複雑なルールは、まず「socks-special inboundから来たexample.comの接続をproxy-altへ送る」のように自然言語で書き、その後フィールドへ対応させると、「かつ」と「または」を取り違えにくくなります。

domainStrategyとドメイン照合

domainStrategyは、IPルールを使うためにいつドメインを解決するかを決めます。一般的には、できるだけドメインとして照合し、必要な場合だけIPへ解決する方法や、ドメインルールに一致しなかった後でIPルールを試す方法があります。利用可能な値と詳細は使用するコアによって異なるため、現在のクライアントのコア動作を基準にしてください。ただし原則は同じです。解決処理にはDNS依存が生じるため、ポリシーを積極的にするほどDNS経路の安定性を確認する必要があります。

ドメイン項目では、完全一致、サブドメイン範囲、キーワード、ルールデータセットがよく使われます。full:example.comは完全一致のみ、domain:example.comはそのドメインとサブドメイン、keyword:exampleはより広い範囲に一致し誤検出のリスクも高くなります。geosite:は、コアで利用可能なドメインデータの分類を参照します。ルールデータは現在のコアのリソースと一致している必要があり、分類が存在しない、またはリソースが読み込まれていない場合はネットワーク障害として扱えません。

IP、ポート、プロトコルのルール

IPルールには単一アドレス、CIDRネットワーク、geoip:データ分類を指定できます。ループバック、プライベートネットワーク、リンクローカルなどの内部アドレスは、通常directへ明示的に送ります。ポートには単一番号または範囲を指定して特定サービスのトラフィックを絞れますが、ポートだけでアプリの種類を確実に判定することはできません。同じポートが異なる用途に使われる場合もあります。プロトコル識別はコアが認識できる接続特性に依存するため、明確な対象に限って使い、ドメインやIPルールの代わりにはしないでください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "full:intranet.example.com",
          "domain:local.example"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "inboundTag": [
          "socks-special"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

デフォルト出口とルール末尾

すべての宛先を対象にする末尾ルールが、常に必要とは限りません。ルールに一致しなかった場合にどのoutboundを使うかは、コアのデフォルト動作とoutboundの並びに関係します。設定を監査しやすくするには、主要な出口の位置を安定させ、例外処理が必要なトラフィックを明示してください。チームや複数端末でルールを共有するなら、「デフォルトの経路」を文書化し、管理者の記憶に依存しないようにします。新しいノードをインポートした後は、outboundの順序が変わっていないか確認することも重要です。

振り分けが機能しないときは、まずrouting段階で対象がドメインとして現れているか、IPとして現れているかを確認します。ルールがドメイン指定なのにログがIPしか示さない場合は、inboundの識別とDNS処理を確認します。宛先ドメインが見えているのに一致しない場合は、プレフィックス、照合範囲、ルール順を確認します。正しいタグに命中しているのに接続できない場合は、対応するoutboundを調べます。「一致しない」と「一致後にoutboundが失敗する」を分ければ、ルール表へ重複項目を延々と追加せずに済みます。

クライアントのカスタムルールを設定する場所

v2rayNのルーティング設定、v2rayNGとv2flyNGの振り分け設定は、最終的にコアが読み取れるルールへ変換されます。ルールセット、プリセットモード、カスタム項目の結合順はクライアントによって異なる場合があります。変更前に現在の設定をエクスポートするか、実行時設定を確認し、カスタムルールがプリセットルールの前後どちらに入るかを確かめてください。クライアントの「LANをバイパス」「グローバル」「ルール」などのモードは、単なる画面上のスイッチではなく生成ロジックを制御しています。

中国本土への直接接続と海外宛てのプロキシという一般的な構成は、ドメイン分類、IPデータ、ルール順序が組み合わさって動作するため、1行のルールをコピーするだけでは不十分です。完全な記述方法とトラブル対処の流れはV2Rayルーティングルール設定の実践ガイドを参照してください。ルールを移行する際は、移行先クライアントのコア系列とリソースファイルが同じ分類名に対応しているかも確認します。

05 / DNS

DNS設定：サーバー選択、ドメインルール、出口の関係

V2RayのDNSが解決する問題

DNSモジュールは、コアが解決する必要のあるドメインに結果を提供し、ドメインの種類に応じて異なるサーバーを選択することもできます。システムDNSを完全に置き換えるものではありません。アプリがシステム層で先に解決してIPだけをプロキシへ渡す場合もあれば、ドメインをそのままSOCKSまたはHTTP inboundへ渡す場合もあります。サーバーアドレス自体も、初期解決をシステムまたはコアで行う必要があります。DNSの問題を判断する前に、誰がクエリを発行したのか、どの層で宛先ドメインが解決されたのか、解決結果がroutingに使われたのかを確認してください。

最も簡単なservers配列には、localhostまたはDNSサーバーアドレスを指定できます。より詳細なオブジェクト形式では、サーバーアドレス、対象ドメイン、期待するクエリ結果を指定できます。サーバーの順番を「1番目が失敗したら常に2番目を使う」と単純に考えてはいけません。実際の動作は、ドメイン照合、クエリ種別、コアの実装にも左右されます。複数のサーバーを設定する場合は、各サーバーがどのドメインを担当するかを明確にし、アドレスを大量に並べて自動的な最適化を期待しないでください。

ドメインに応じたDNSサーバーの選択

サーバーオブジェクトにdomainsを設定すると、一致するドメインでそのサーバーを優先的に使用できます。ドメインの表現方法はroutingルールと似ており、完全一致、ドメイン範囲、利用可能なデータ分類を使えます。ここでのルールは「誰に問い合わせるか」を決め、routingルールは「DNSクエリや最終接続をどの出口から出すか」を決めます。両者は別の層です。DNSのドメイン条件だけを書いて対応する出口を処理しなければ、クエリが想定した経路を通るとは限りません。

{
  "dns": {
    "hosts": {
      "router.example": "192.168.1.1"
    },
    "servers": [
      {
        "address": "localhost",
        "domains": [
          "full:router.example",
          "domain:local.example"
        ]
      },
      {
        "address": "1.1.1.1",
        "domains": [
          "geosite:geolocation-!cn"
        ],
        "skipFallback": true
      },
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

hostsは特定の名前に静的な対応付けを与えるもので、固定されたローカルサービス名やテスト環境に適しています。大規模で頻繁に変わるアドレス一覧の管理には使わないでください。静的マッピングは通常の問い合わせを迂回するため、アドレスが変わると古い値が接続異常を引き起こし続けることがあります。あるドメインの解決結果がシステムと異なる場合は、クライアント画面で生成されたカスタムホストレコードを含め、hostsを確認してください。

クエリポリシーとアドレスファミリー

queryStrategyは、問い合わせるアドレス種別の傾向を制御します。利用可能な値と詳細は使用するコアによって異なりますが、通常はIPv4とIPv6の両方を使う、一方だけを使う、環境に応じて選ぶといった動作に関係します。ある時点でIPv6経路が利用できなかったからといって、関連機能を永久に削除しないでください。まず端末のネットワーク、リモートoutbound、対象サイトが完全な経路を形成しているか確認するのが適切です。システムにアドレスがあっても利用可能な経路がなければ、解決成功後に接続がタイムアウトします。これはDNSが結果を返さない問題ではなく、ネットワーク経路の問題です。

ドメインルールでIP分類を使う場合、コアは対象を先に解決し、その結果をIPルールと比較することがあります。このときqueryStrategyが間接的にルーティング結果を変えます。同じドメインでも異なるアドレスファミリーが返されれば、別のネットワークルールに一致する可能性があります。設定を設計する際は、偶然の1回の解決結果にroutingの結論を過度に依存しないようにしてください。安定した直接接続が必要な内部名には、明確なドメインルールと内部ネットワークルールを併用すると保守しやすくなります。

DNSクエリがoutboundを選ぶ仕組み

DNSサーバーアドレス自体もネットワーク上の宛先なので、専用タグやルーティングルールで出口を制御できます。通常のIPアドレスをDNSサーバーに使う場合は、宛先IPとポートで識別できます。暗号化DNSをドメイン形式で指定する場合は、まずそのDNSサーバーのドメインを初期解決する必要があります。よくある循環は、プロキシサーバーの解決にDNSが必要で、そのDNSがプロキシoutboundへルーティングされ、さらにプロキシoutboundがサーバーアドレスの解決を必要とする状態です。起動経路にはプロキシに依存しない利用可能な解決入口を残すか、クライアントが対応する明示的なブートストラップ設定を使ってください。

DNSクエリが成功したのにWebページを開けない場合は、解決結果だけで判断せず、最終接続も確認してください。解決後のIPが誤ったoutboundへ送られた、リモート側がそのアドレスファミリーに対応していない、宛先ポートがブロックされている、アプリがコアのDNSを使っていない、といった可能性があります。逆にWebページを開けても、すべてのDNSが設定どおりに実行されたとは限りません。アプリ独自の名前解決でローカルプロキシを迂回することもあります。厳密に確認する場合は、ログの宛先形式、inboundプロトコル、アプリのプロキシ方式を併せて確認します。

キャッシュ、FakeDNS、トラブル対処の範囲

一部のクライアントやコア環境では、透過的な接続でドメインの対応関係を維持するためにキャッシュやFakeDNSを使います。FakeDNSは内部マッピング用のアドレスを返し、コアが接続を受け取った後で本来のドメインへ戻します。そのアドレスが別のアプリやシステムコンポーネント、不一致のinboundで処理されると、一見すると異常な宛先IPになることがあります。有効にする前に現在の接続方式が本当に必要としているか確認し、関連するアドレス範囲がローカルネットワークと重ならないようにしてください。

DNSのトラブル対処では、層ごとに置き換えていく方法が効果的です。まず明確に利用できる通常のサーバーを1つ使って基本解決を確認し、次にドメイングループを戻し、その後でqueryStrategyと専用ルーティングを追加します。毎回変更する変数は1つだけにし、対象ドメイン、返されたアドレス、最終的なoutboundタグを記録してください。設定入口の詳しい説明は、サイト内のV2Rayの利用手順にあるクライアントの章も参照できます。

06 / POLICY

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

policyオブジェクトの2層構造

policyは、接続のライフサイクルと統計動作をまとめて設定するために使います。一般的な構造にはlevelsとsystemが含まれます。levelsはユーザーレベルをキーとし、各レベルにハンドシェイク、アイドル接続、上り下りの片側終了後に待機する時間などを定義します。systemはinboundとoutboundの統計を有効にするかどうかを制御します。個人用クライアントの多くは複雑なレベル設定を必要としませんが、この構造を理解しておくと、アイドル状態が続いた接続が解放される理由や、統計モジュールにデータが生成されない理由を説明しやすくなります。

レベル番号は速度の優先順位ではなく、特定のユーザーに高い帯域幅を自動的に与えるものでもありません。ユーザーやプロトコルオブジェクトが参照するlevelを、1組のpolicyへ対応付けるだけです。設定にレベル0しかない場合、デフォルトレベルを使うすべての接続がこの値を採用します。レベルを追加しても、どのユーザーからも参照されなければ実際の効果はありません。サーバー用の設定をクライアントへ移行するとき、複雑なレベル表を残したまま、それを参照していたユーザーオブジェクトを削除してしまうケースがよくあります。

接続ライフサイクルのパラメーター

handshakeは通常、接続確立段階で許容する待機時間を制御します。connIdleはデータの動きがない接続を維持する時間を決めます。uplinkOnlyとdownlinkOnlyは、片側のデータが終了した後にもう一方を待つ時間に使われます。単位と対応範囲は現在のコアのフィールド定義を基準にしてください。アイドル時間が短すぎると、長時間接続、メッセージプッシュ、ダウンロード制御接続が頻繁に再確立されます。長すぎると、無効になった接続がより長くリソースを占有します。

タイムアウトは長ければ安定するというものではありません。サーバーアドレスに到達できない場合、ハンドシェイクの待機時間を長くすると障害の検知が遅れます。ネットワークを頻繁に切り替える環境では、古い接続を長時間残しても自動復旧にはなりません。policyを調整する前に、ログで切断原因を確認してください。リモート側が切断しているなら、ローカルのアイドル時間を延ばしても意味はありません。アプリ自身が定期的に再接続している場合も、すべての再接続をコアのpolicyのせいにしないでください。

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

統計機能のスイッチは統計結果そのものではない

policy内の統計フィールドは、コアが対象データを収集できるようにするだけです。トップレベルのstatsオブジェクトと、統計を読み取るAPIまたはクライアント機能も必要です。すべてのスイッチをtrueにしても、画面に自動的にデータが表示されるとは限りません。逆に、トラフィック情報を表示するためにクライアントが統計設定を生成し、API inboundや内部ルーティングを追加することもあります。policyだけを残して関連オブジェクトを削除しないでください。

統計機能を有効にすると、一定の状態管理が必要になります。個人環境では、本当に必要な項目だけを有効にしてください。たとえばoutboundの総量だけを確認したいなら、ユーザーごとの上り下り統計まで同時に有効にする必要はありません。設定を監査するときは、何を観測したいのか、どのインターフェースで読み取るのか、どのクライアント画面に表示するのかを確認します。答えられない場合は、項目を網羅するためだけに実用性のないモジュールを追加せず、シンプルな設定を保つのが基本です。

クライアントが生成するpolicyの扱い

v2rayN、v2rayNG、v2flyNGは、トラフィック統計、接続テスト、ローカル管理機能に応じてpolicyフィールドを書き込むことがあります。設定を手動で上書きする場合は、関連するクライアント機能を先に無効にするか、対応するカスタム設定入口を使ってください。そうしないと、次回起動時に再生成される可能性があります。特にデスクトップでシステムプロキシ、接続テスト、統計表示を同時に使っている場合、実行時設定はサブスクリプション内のノードリンク1件と同じではありません。

policyのトラブル対処は、ネットワークのトラブル対処と混同しないようにします。コアの起動失敗がpolicyフィールドを明示しているなら、型、レベルキー、現在のコアがそのフィールドに対応しているかを確認します。接続は確立するのに早く切断される場合は、アイドル時間とアプリの動作を比較します。統計が空の場合は、データ収集の一連の構成を確認します。これら3つを分ければ、設定構造、接続ライフサイクル、クライアント表示のどこに問題があるか判断できます。

デフォルトのままにするべき場合

通常のWeb閲覧、コマンドラインプロキシ、日常的なサブスクリプション利用では、policyを手動で調整する必要はほとんどありません。デフォルト値は一般的な用途を考慮して設定されています。ログと再現手順から、特定の接続がpolicyの時間設定に影響されていると確認できない限り、「速くする」ための変更はおすすめしません。policyパラメーターが制御するのは待機時間と状態であり、リモート回線の品質やサーバーのスループットを向上させるものではありません。

本当に調整が必要なら、現在の値と再現条件を記録し、一度に1つのパラメーターだけを変更して、同じアプリと同じネットワーク経路で結果を観察します。変更しても接続問題が変わらなければデフォルトへ戻し、outboundとシステムネットワークの確認を続けてください。設定完全ガイドの目的はすべてのフィールドを変更することではなく、必要な変更に明確な根拠を持たせることです。

07 / LOG & STATS

ログ、統計、実行時設定：観測可能なトラブル対処環境を作る

logフィールドとログレベル

logは、コアが出力する実行情報を決めます。一般的なログレベルは、詳細なデバッグ情報から警告、エラーへ向かって段階的に絞り込まれます。普段はwarning程度の簡潔なレベルを使い、複雑な問題を再現するときだけ詳細度を一時的に上げ、原因を確認したら戻してください。最も詳細なログを長期間出し続けると重複情報が大量に発生し、重要なエラーが見つけにくくなります。ディスク容量を余分に使うこともあります。

ログは通常、アクセスログとエラーログに分かれます。アクセスログは「どの接続が入り、宛先は何で、どの出口を選んだか」を示し、エラーログは「どの段階で、なぜ失敗したか」を示します。最後の1行だけを見ると誤判断しやすく、最外層のエラーが単なる「接続終了」で、本当の原因が数行前のDNS、routing、ハンドシェイク情報にあることもあります。調査時はコアの起動から障害発生までの時間帯を保持し、実行した操作も記録してください。

{
  "log": {
    "access": "",
    "error": "",
    "loglevel": "warning"
  },
  "stats": {}
}

空のパスをどう扱うかは、コアとクライアントの起動パラメーターによって異なります。GUIクライアントは通常、ログ出力を引き受け、画面に表示します。手動でファイルパスを入力すればクライアントが必ずそのファイルを読む、と考えないでください。Windows、macOS、Android、Linuxではアプリデータの場所と権限モデルが異なるため、まずクライアント内蔵のログ画面やエクスポート機能を使います。クライアントを再インストールする場合は、インストールパッケージのページからプラットフォームに合ったバージョンを選べます。

ログを読む段階の順序

起動ログでは、まず設定の解析を確認します。JSONの文字位置、未知のフィールド、型エラーが出ている場合、コアはまだネットワーク接続段階に入っていません。この時点でノードアドレスを変更しても意味はありません。設定の読み込みに成功したらinboundのリッスンを確認し、ポートとアドレスを確かめます。その後DNSとroutingを観察して、宛先が認識され想定したoutboundに一致しているか確認し、最後にリモート接続、TLS、プロトコルハンドシェイクを調べます。データフローに沿ってログを読めば、大量の情報も明確な段階に分類できます。

一般的なエラーテキストは、文脈から切り離して解釈してはいけません。timeoutはDNS、TCP接続、ハンドシェイクのどの段階でも発生します。connection refusedはローカルポート、リモートポート、中継転送のいずれから返ることもあります。failed to find an available destinationは、outboundの選択、解決結果、policyに関係する場合があります。判断材料はエラー前後のモジュール名、宛先アドレス、タグであり、英文フレーズ1つだけを検索することではありません。

実行時設定と保存済み設定

クライアント画面に保存されるのは、ノード、サブスクリプション、ルーティングモード、アプリ設定です。実際にコアへ渡される実行時設定は、起動時に動的に合成されることがあります。トラブル対処では、サブスクリプションリンク内のノード項目だけでなく、実行時設定を確認してください。クライアントがローカルinbound、API、統計、DNS、direct・block outboundを追加することもあります。システムプロキシ設定はコア設定の外側にあります。実行時設定が正しいのにアプリのトラフィックが入らないなら、JSONを変更し続けるのではなく、システムプロキシまたはアプリのプロキシを確認します。

実行時設定をコピーしてテストするときは、一時ポート、クライアント内部のタグ、パスに注意してください。コアを単独で起動する前に、環境依存の設定を現在の端末で利用できるものへ置き換えます。逆に、手書きの設定をクライアントへ戻すと、クライアント側で再整理されることもあります。長期運用では主な設定元を1つに決めてください。クライアント設定を主体にして対応するカスタムルールで拡張するか、完全な手書き設定を主体にして、2つの設定元が交互に上書きしないようにします。

statsとクライアントのトラフィック表示

トップレベルのstatsオブジェクトは統計モジュールを有効にしますが、実際の指標はpolicyのスイッチにも左右されます。一部のクライアントは内部APIでinbound、outbound、ユーザー単位のデータを読み取り、画面に表示します。APIオブジェクトや内部ルーティングを削除すると統計が停止する可能性がありますが、プロキシ接続は正常なままです。「コアは動くのに画面のデータが空」という状態は、ノードの停止とは分けて対処してください。

統計値はトラフィックの方向や、特定の入口を経由したかを確認するのに適していますが、回線品質の評価値ではありません。スループットは対象サーバー、ネットワーク経路、同時接続数、アプリの動作に左右されます。設定画面に多くの数字を表示するためだけに、すべての統計項目を有効にしないでください。まず「特定のinboundが上りトラフィックを受け取っているか確認する」のように目的を決め、対応する項目だけを有効にし、完了後は簡素な設定へ戻します。

最小限の再現環境を作る

信頼できるトラブル対処記録には、少なくとも使用クライアント名、OSプラットフォーム、コア系列、再現手順、エラー発生段階、関連タグ、削減した設定構造を含めます。ノードの認証情報やサブスクリプション内容をそのまま公開してはいけません。プロトコル種別、フィールド階層、サンプル化したアドレスを残せば、他の人が構造上の問題を判断できます。

コアが設定を読み込んだ直後に終了する場合の詳しいログ特定方法は、ログでconfig.jsonの設定エラーを特定する方法をご覧ください。certificate invalid、serverName、ハンドシェイク段階にエラーが集中している場合は、TLS証明書エラーのトラブル対処チェックリストへ進み、システム時刻、サーバー名、証明書チェーンの順に確認します。

08 / VALIDATION

完全設定の組み立て、検証順序、障害分岐

読みやすい基本設定を組み立てる

完全な設定では、まずタグの関係を明確にし、ルール数を増やすのはその後にします。以下の基本構造には、ローカルSOCKS inbound、プロキシoutbound、direct・block出口、簡単なDNSとroutingを含めています。プロキシサーバー情報はあくまで例で、そのまま接続には使えません。各モジュールがどのように相互参照されるかを示すことが例の目的です。実際にはGUIクライアントがサブスクリプションからプロキシoutboundを自動入力することが多く、手動ルールはクライアントが対応する設定入口から統合する方が適しています。

{
  "log": {
    "loglevel": "warning"
  },
  "dns": {
    "servers": [
      "localhost"
    ]
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-4000-8000-000000000000",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "server.example.com"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      }
    ]
  },
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300
      }
    }
  }
}

第1層：構文と構造の検証

設定を起動できない場合は、まずJSONが完全か確認します。括弧が対応しているか、配列のメンバー間にカンマがあるか、文字列を二重引用符で囲んでいるか、数値と真偽値が正しい型になっているかを重点的に確認してください。エディターが示すエラー行は、解析を続けられなくなった位置にすぎないことがあります。本当に不足しているカンマが前の行にある場合もあります。修正後に設定を再度読み込み、JSON解析エラーが出なくなるまで繰り返します。

構文を通過したら、フィールド構造を検証します。フィールド名、所属階層、コアが対応しているかを確認してください。別のコア系列、古いガイド、異なるクライアントの設定を使っている場合、一部のフィールドが利用できないことがあります。XrayとV2Flyには共通の基盤がありますが、プロトコルや機能には違いもあり、設定を常にそのまま交換できるとは限りません。2つのコア系列とクライアントの組み合わせについては、XrayとV2Flyのコア関係と選び方をご覧ください。

第2層：タグとリッスンの検証

すべてのinboundとoutboundのタグを書き出し、参照を1つずつ確認します。各outboundTagに同名のoutboundが存在し、各inboundTagが実際の入口に対応している必要があります。タグは大文字と小文字を含めて一致させ、同名タグは設定の意味を不明確にするため避けてください。続いて、各inboundのリッスン成功、ポート競合の有無、アプリのプロキシアドレスとプロトコル種別が完全に一致しているかを確認します。

アプリにアクセスできないのに、コアに該当する接続ログがまったくない場合は、システムプロキシとアプリ設定を確認します。デスクトップ環境では、システムプロキシはその設定に従うプログラムにしか影響しないことがあります。ターミナルツール、ゲーム、独立したブラウザーには独自のプロキシ設定がある場合があります。Androidクライアントは通常、システムのネットワークインターフェースを通じてトラフィックを処理するため、アプリの権限、現在の設定、接続状態を重点的に確認します。各プラットフォームの入口はインストールパッケージのページで確認できます。

第3層：DNS、routing、outboundの検証

接続が入ったことを確認したら、ログに表示される宛先の形式を記録します。ドメインならドメインルールを、IPならIPルールとinboundの識別を確認します。次に、実際に一致したoutboundタグを確認してください。誤ったタグに一致しているなら、ルール順、照合範囲、DNS解決結果を調整します。正しいタグに一致しているのに失敗する場合は、そのoutboundのサーバー解決、ポート、プロトコル、トランスポート層を確認します。

問題の範囲を判断するため、ルーティングルールを一時的に減らすことができます。まず内部ネットワークのdirectと、明確なプロキシ出口を1つだけ残して基本経路を確認し、その後ドメイン分類、blockルール、inbound専用ルールをグループごとに戻します。DNSも同様に、利用可能なサーバーを1つだけ使い、次にドメイングループと専用出口を戻します。一度に1グループずつ復元すれば、障害を引き起こした変更を正確に特定できます。

よくある障害の分岐

変更後の回帰チェック

設定が再び使えるようになった後も、1つのWebページだけで確認を終えないでください。少なくともドメイン宛て、直接IP宛て、ローカルネットワークアドレス、directが必要なサイト、プロキシが必要なサイトを確認し、ルールの境界が想定どおりか確かめます。UDPを有効にした場合は、実際にUDPを必要とするアプリでも検証してください。その後クライアントを再起動し、設定が安定して再生成・読み込みされることを確認します。一時的な実行ファイルだけが有効な状態を避けるためです。

サブスクリプション更新後は、カスタムルールが保持されているか、現在のノードが想定したプロキシタグに対応しているか、クライアントがコアを切り替えていないかも確認します。v2rayNはWindows、macOS、Linuxのデスクトップ環境に適しており、v2rayNGはXrayコア、v2flyNGはV2Flyコアを採用したAndroid向けの選択肢です。3者の画面は異なりますが、トラブル対処の流れは同じです。入口、識別、ルーティング、解決、出口、ハンドシェイクを順に確認します。

最後に、変更理由、対象モジュール、検証結果を記したテキスト形式の変更履歴を残してください。設定ファイルはコピーできますが、ネットワーク環境やクライアントの生成ロジックは変化します。どのルールがどの問題を解決したか分かって初めて、後からそのルールがまだ必要か判断できます。基本操作は利用ガイド、フィールド名とプロトコルの概念は用語集で確認し、具体的なエラーは対応するブログ記事へ進んでください。すべての知識を保守しにくい1つの設定へ詰め込む必要はありません。