V2Ray設定ファイルのJSON構造を解説｜inbounds・outbounds・routingの読み方

まず確認：クライアント設定・サブスクリプション・コア設定の違い

v2rayNは、ノードやサブスクリプション、ルーティング、コアの実行を管理するデスクトップクライアントです。実際に通信を受け付けて接続するのはコアです。クライアントに保存される画面設定やサブスクリプションURL、グループ情報は、コア起動時に読み込まれるJSON設定とは別物です。クライアントが生成した一時設定を直接編集しても、ノードの切り替えやサブスクリプション更新、コアの再起動で上書きされることがあります。

この記事では、V2Rayでよく使われる従来形式のJSON設定を扱います。V2Rayの異なる設定形式とXray独自の拡張項目は、ファイルの拡張子だけを見て混在させることはできません。特にVLESSやトランスポート層・セキュリティ層の設定は、実際に動作するコアとそのバージョンのドキュメントを確認してください。「どちらもJSON」だからといって、すべての項目に互換性があるわけではありません。

v2rayNでは、まず「設定」→「パラメーター設定」でローカルの待ち受け設定を確認し、「設定」→「ルーティング設定」で振り分けルールを確認します。項目名や場所はバージョンによって変わることがあるため、実際のメニューを確認してください。コア名、起動オプション、設定ファイルの場所は、起動ログから確認するのが確実です。サブスクリプションファイルを実行時の設定一式と混同しないようにしましょう。

通信の流れ：inboundsで受信し、routingで選び、outboundsで接続

inboundsは入口の配列で、コアがどこで、どのプロトコルを使ってリクエストを受け付けるかを定義します。たとえば、アプリがローカルの127.0.0.1:10808にあるSOCKSサービスへ接続すると、その通信が入口に届きます。コアを起動しただけでは、すべてのアプリが自動的にコアを使うわけではありません。システムプロキシ、アプリごとのプロキシ設定、TUNはそれぞれ異なる接続方法です。

outboundsは出口の配列で、リモートプロキシ、直結、ブロックなどを定義できます。routingはドメイン、IP、ポート、入口のタグなどの条件に基づいて出口を選びます。tagは設定内で参照する識別子であり、プロトコル名ではありません。同じ名前の出口が自動で作成されるわけでもありません。

• inboundTag：どの入口から来た通信を対象にするかを指定します。入口のtagを参照します。
• outboundTag：ルールに一致した通信に使う出口を指定します。出口のtagと完全に一致させる必要があります。
• ルールは記述順に評価され、最初に一致したルールが適用されます。どのルールにも一致しない場合は、通常outbounds配列の先頭にある出口が使われます。
• 1つのルール内では、ドメインリストの複数項目は通常「いずれかに一致」で判定されます。一方、ドメインやポートなど異なる条件項目を併記した場合は、すべての条件を満たす必要があります。

完全な設定例：ローカルSOCKS、直結、ドメインブロック

以下は構造を理解するための、従来形式による完全なJSON設定例です。SOCKSはローカルでのみ待ち受け、example.comというドメインそのものをブロックし、そのほかの入口経由のリクエストは直結します。VMessやVLESSのサーバー設定は含まれていないため、ウェブページを表示できても、確認できるのはローカル入口と直結経路の動作だけです。

{
  "log": {
    "loglevel": "warning"
  },
  "dns": {
    "servers": [
      "1.1.1.1"
    ]
  },
  "inbounds": [
    {
      "tag": "socks-local",
      "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": [
      {
        "type": "field",
        "domain": [
          "full:example.com"
        ],
        "outboundTag": "block"
      }
    ]
  }
}

JSONではオブジェクトに波括弧、配列に角括弧を使い、文字列は半角のダブルクォーテーションで囲みます。パーサーによる解釈の違いを避けるため、この例ではコメントと末尾のカンマを使っていません。構文が正しいことは最初の確認事項にすぎません。項目名や型、プロトコルのパラメーターは、引き続きコアで検証する必要があります。

入口と出口：待ち受けアドレスはサーバーアドレスではない

入口のlistenはローカルでバインドするアドレスです。リモートプロキシサーバーのアドレスは、該当する出口のプロトコル設定に記述します。サーバーのドメインをローカルの待ち受けアドレスに入力しても、プロキシ接続は確立できず、入口がバインドできなくなることがあります。127.0.0.1はローカル端末からのアクセスのみを許可します。0.0.0.0に変更すると、すべてのIPv4ネットワークインターフェースで待ち受けるため、認証やファイアウォール、LANからのアクセス範囲もあわせて検討してください。

udp: trueは、SOCKS入口でUDP転送を許可する設定です。すべてのアプリのUDP通信が自動的に取り込まれるわけではありません。アプリがSOCKS5のUDP ASSOCIATEに対応していることに加え、後続の出口とネットワーク経路もUDPに対応している必要があります。システムにHTTPプロキシを設定しただけでは、UDPリクエストがこのSOCKS入口に自動で送られることはありません。

VMessまたはVLESSの出口を追加するには、サーバーアドレス、ポート、ユーザー識別情報、対応するトランスポート設定が必要です。VMessではsettings.vnextを使う設定が一般的です。VLESSにもユーザー情報とサーバー情報の構造がありますが、認証の仕組みは異なります。protocolの文字列だけを変更しても動作しません。TLSを有効にする場合はサーバー名も確認してください。サーバーのポートが443だからといって、必ずTLSが有効になっているわけではありません。

• リモートノードの情報はサービス提供元または有効なサブスクリプションから取得してください。接続失敗の状況からユーザー識別情報を推測しないでください。
• コアがあるプロトコルに対応していても、そのプロトコルの新しいトランスポート方式やセキュリティ拡張すべてに対応するとは限りません。
• v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。ノードを移行した後も、各パラメーターの互換性を確認してください。

ルール設定：順序、ドメインの照合、デフォルト出口

この例のfull:example.comは、ドメインそのものに完全一致する条件です。www.example.comには自動で一致しません。ドメインとサブドメインを対象にする場合、従来形式のルーティングルールではdomain:example.comを使えます。このドメイン照合をURL全体の照合と混同しないでください。通常、ルーティングではウェブページの/accountのようなパスを使って、同じサイト内のページを区別できません。

domainStrategy: "AsIs"は、ルーティング時にIPルールのためのドメイン解決を積極的に行わない設定です。接続全体でDNS問い合わせが行われないという意味ではありません。出口が実際に宛先へ接続する際、名前解決が必要になることがあります。IPIfNonMatchでは、ドメインルールに一致しない場合にIPを解決して照合を試みます。IPOnDemandでは、IPを必要とするルールに遭遇した時点で名前解決が行われることがあります。

ルールは具体的な条件から広い条件へ並べます。最初のルールで特定の入口からのすべての通信を直結にすると、後続の同じ入口を対象としたドメインブロックルールは実行されません。geoip:やgeosite:を使う場合は、対応するデータファイルが利用可能かも確認してください。データが見つからないエラーと、ネットワークに接続できないエラーは別の問題です。

DNSとログ：リゾルバーを定義しても、すべての問い合わせが処理されるわけではない

dns.serversでは、コア内蔵DNSが利用する上流リゾルバーを指定します。この例では1.1.1.1を使用します。通常のIPアドレス形式で指定した場合、一般に従来型のDNS問い合わせとなり、暗号化DNSではありません。接続できるか、問い合わせがどの経路から送信されるかは、ネットワークや関連設定にも左右されます。この項目だけで名前解決の経路を判断することはできません。

アプリが先にOSのDNSでIPアドレスを取得し、そのIPをSOCKSに渡す場合もあります。その場合、コアが受け取る宛先は元のドメイン名ではないため、先ほどのドメインルールに一致しないことがあります。スニッフィングは対応するプロトコルでドメインの特定を補助できますが、すべてのリクエストで元のドメイン名を復元できるとは限りません。内蔵DNSを設定するだけで自動的に使える機能でもありません。

1. まず入力内容を確認します。リクエストログにはドメイン名とIPアドレスのどちらが表示されていますか？SOCKSを使うアプリで、プロキシ側の名前解決が有効になっていますか？
2. 次に、どの段階で失敗したかを確認します。名前解決の失敗、接続タイムアウト、TLSハンドシェイクの失敗は、それぞれ異なる段階で発生します。すべてをDNSの問題と決めつけないでください。
3. ログレベルを一時的に上げます。loglevelをwarningからinfoまたはdebugに変更し、問題を一度再現したら元に戻します。接続の詳細を大量に記録し続けないようにしてください。
4. 必要に応じてログファイルを設定します。accessとerrorには、アクセスログとエラーログの保存先を指定できます。保存先のディレクトリが存在し、実行ユーザーに書き込み権限があることを確認してください。

検証手順：まず構文を確認し、次に実際の通信をテスト

例の設定をconfig.jsonとして別名保存し、クライアントが使用中の設定を上書きせず、独立したテスト環境で確認することをおすすめします。該当コマンドに対応したV2Rayでは、以下の方法で設定をテストできます。コマンドラインの起動方法は配布版によって異なります。未知のコマンドと表示された場合は、まずv2ray helpを実行して、利用可能なオプションを確認してください。

v2ray test -c config.json

設定テストに合格しても、ポートを正常にバインドできること、リモートに接続できること、ルーティングが想定どおりであることは保証されません。コアを起動した後、プロキシプロトコルを明示したリクエストで検証します。以下のコマンドはcurlをインストール済みの環境向けです。Windowsのターミナルでは、コマンドエイリアスの違いを避けるためcurl.exeを使えます。

curl --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 https://example.com/

--socks5-hostnameは宛先ドメインをSOCKSプロキシに渡すため、この例のドメインルールを検証するのに適しています。想定される結果は、このリクエストでウェブページを正常に取得できず、ログにはリクエストがコアに届いたことが記録されることです。表示されるエラー文はコアやcurlのバージョンによって異なります。エラーが1つ表示されただけで、どのルールが適用されたか判断しないでください。

1. ブロックを確認します。完全な設定にあるfull:example.comルールを残し、上記のコマンドを実行してログを確認します。
2. 直結を確認します。テスト用コピーのrulesを空配列[]に変更し、コアを再起動して同じリクエストを実行します。ネットワークから宛先にアクセスできる場合、先頭の直結出口で接続されるはずです。
3. 入口を確認します。ログにリクエストがまったく記録されない場合は、待ち受けアドレス、ポート、アプリの設定を確認してください。ルーティングの変更を続けても解決しません。
4. テスト環境を元に戻します。単独で起動したテスト用コアを終了し、元の設定に戻してからクライアントを起動してください。同じポートを複数のプロセスで取り合わないようにします。

よくある質問：起動するのに振り分けが変わらない

設定を読むときは、次の3点を順に確認します。アプリの通信が想定した入口に届いているか、リクエストが想定したルールに一致しているか、選ばれた出口に必要なパラメーターが設定されているか。名前解決、ルーティング、接続を分けて検証すると、複数の設定を同時に変更するより原因を特定しやすくなります。