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

1. 単体でテストできるconfig.jsonを用意する

ここでは、従来のV2Ray JSON設定形式を使います。この形式に対応するV2Flyコア向けです。まず v2ray version を実行して実際に使われているプログラムを確認し、続けて v2ray help を参照してください。V2FlyとXrayには共通する項目もありますが、拡張機能やコマンドライン引数は完全には一致しません。他のコア向け設定を汎用形式として流用しないでください。

以下をUTF-8形式の config.json として保存します。127.0.0.1:10808 でSOCKS接続を受け付け、example.org とそのサブドメインへの接続を拒否し、それ以外のリクエストはデフォルトで直接接続します。ここでいう「動作する」とは、入口、ルーティング、outboundが機能するという意味であり、リモートプロキシとして利用できるという意味ではありません。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-local",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "blocked",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["socks-local"],
        "domain": ["domain:example.org"],
        "outboundTag": "blocked"
      }
    ]
  },
  "dns": {
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ]
  }
}

• オブジェクトは波括弧、配列は角括弧で囲みます。inbounds と outbounds は項目が1つだけでも配列です。
• キー名と文字列は半角の二重引用符で囲みます。数値の 10808 や真偽値の false は引用符で囲みません。
• 最後の項目の後にカンマは付けません。複数のツールで検証しやすいよう、このサンプルではコメントや末尾のカンマも使用していません。
• トップレベル項目の記述順はリクエストの経路に影響しません。順序が重要なのは、ルーティングルールの配列とデフォルトで使われるoutboundの位置です。

2. log：エラーの確認先を決める

log はログ出力を設定する項目で、プロキシやルーティングの機能はありません。このサンプルでは loglevel のみを設定し、ログファイルのパスは指定していません。ターミナルから手動で起動した場合は、プロセスの出力を確認してください。サービスとして起動している場合は、任意のディレクトリに既定のログファイルを探すのではなく、該当サービスのログを確認します。

起動に失敗したら、まず最初に表示された明確なエラーを確認します。構文エラーは該当する項目や位置を示すことが多く、address already in use は待ち受けポートの競合を示します。権限エラーの場合は、設定ファイルやログディレクトリの権限を確認してください。ノードのアドレスを何度変更しても、ローカルポートの競合は解決しません。

3. inbounds：アプリが接続するローカルの入口

inbounds は、コアがリクエストを受け取る方法を設定します。このサンプルの protocol: socks はアプリとローカルのコア間で使うSOCKSプロトコルであり、リモートサーバーのプロトコルではありません。ブラウザーやターミナル側でこの入口を明示的に指定する必要があります。プロセスを起動しただけでは、システムプロキシは自動設定されず、すべてのアプリの通信がコアに取り込まれるわけでもありません。

listen は入口へ接続できる範囲を、port は入口のポート番号を指定します。ここではループバックアドレスを使っているため、他のLAN機器はPCのローカルIPアドレス経由で接続できません。トラブルシューティングのために安易に 0.0.0.0 へ変更し、認証なしのまま使い続けないでください。待ち受け範囲が広がります。

settings.auth が noauth の場合、ローカルSOCKS接続にユーザー名とパスワードは不要です。udp: false は、このサンプルでSOCKSのUDP転送を有効にしない設定です。この記事ではTCPリクエストだけを使って動作を確認するため、ゲーム、音声通話などのUDPアプリが使えるかどうかは判断できません。

4. outbounds：プロトコル設定とタグを分けて理解する

outbounds は、リクエストをコアから送信する方法を設定します。このサンプルの freedom は直接接続、blackhole はリクエストの拒否または破棄に使います。どちらもリモートノードではないため、サーバーアドレス、ユーザー識別情報、通信のセキュリティ設定は不要です。

1. まずprotocolを確認。settings に指定できるプロトコル項目は、ここで決まります。SOCKS inboundの認証項目をVMess outboundにコピーしないでください。
2. 次にsettingsを確認。使用するプロトコルに応じた接続パラメーターを設定します。実際のプロキシノードを追加する場合は、サーバー情報と使用中のコアのドキュメントを確認し、既定値を推測で設定しないでください。
3. 最後にtagを確認。設定内で参照するための名前です。この例の direct と blocked は独自に付けたタグであり、システム予約済みのプロトコル名ではありません。
4. streamSettingsを確認。必要に応じて、outboundオブジェクトに通信方式や通信のセキュリティ設定を指定します。settings と同じ階層に置く項目で、むやみに入れ子にしないでください。

VMessとVLESSは別のプロキシプロトコルです。protocol の値を変えるだけでは切り替えられません。VLESSを使う場合は、実際のコアのバージョンと対応範囲も確認してください。特にXray固有の通信拡張は、項目名が似ているからといって、そのままV2Flyの設定に移せるとは限りません。

5. routing：ルールの順序に沿ってリクエストをoutboundへ振り分ける

リクエストがコアに入ると、ルーティングモジュールは接続先のドメインやIPアドレス、ポート、inboundタグなどの条件に基づいてoutboundを選択します。サンプルの処理の流れは次のとおりです。仮想NICは使用せず、システムプロキシも自動設定しません。

このサンプルでは、リクエストの送信元が socks-local で、接続先ドメインが domain:example.org に一致する場合、blocked に送ります。同じルール内の2つの条件は両方とも一致する必要があります。domain 配列に複数のドメインを指定した場合は、そのうち1つに一致すればドメイン条件を満たします。

どのルールにも一致しない場合は、outbounds の1番目が使われます。この記事では1番目が direct のため、通常のリクエストは直接接続します。プロキシoutboundを先頭に移すと、ルールに一致しないリクエストの動作も変わります。「どのサイトも同じ出口になる」場合は、ルールだけでなく配列の先頭項目も確認してください。

domainStrategy: AsIs は、現在の接続先情報を使ってルーティング時に照合し、IPルールとの照合のためにドメインを積極的に名前解決しない設定です。アプリからSOCKSへIPアドレスが渡された場合、このドメインルールだけでは元のドメイン名を復元できません。この例ではスニッフィングを設定していないため、テスト時はアプリからドメイン名をSOCKS入口へ渡す必要があります。

6. dns：DNSサーバーの設定はシステムDNSの制御とは別

トップレベルの dns は、コア内蔵のDNSモジュールを設定します。このサンプルでは 1.1.1.1 と 8.8.8.8 の2つのサーバーを指定していますが、この設定を追加してもOSのDNSは変更されず、すべてのアプリのDNS問い合わせが自動的にコアへ送られるわけでもありません。

• アプリが先に名前解決する：アプリが接続先のIPアドレスを取得してから、そのIPをSOCKSへ渡します。この場合、コアから元のドメイン名が見えず、ドメインによる振り分けが一致しないことがあります。
• アプリがドメイン名を渡す：アプリがSOCKSの接続先としてドメイン名を渡すため、ルーティングモジュールはドメイン条件を直接照合できます。
• ルーティングが名前解決を実行する：名前解決が必要なルーティング方針を使う場合、IPルールとの照合を続けるためにルーティングモジュールが内蔵DNSを呼び出すことがあります。
• outboundで名前解決する：direct outboundの名前解決は、そのoutbound自身の設定にも左右されます。既定の AsIs を使用している場合、トップレベルで指定したDNSサーバーが必ず使われるとは限りません。

このため、この例のDNS設定は主に構造を示すものであり、すべてのテストで実際に呼び出されるとは限りません。routingの domainStrategy とdirect outboundの settings.domainStrategy は異なる階層の設定です。前者はルールの照合方法、後者はdirect接続での接続先アドレスの扱いに影響します。同じ名前だからといって、どちらか一方を変えればすべての名前解決経路が変わるわけではありません。

7. 設定のテストと2種類のリクエストによる確認

test と run サブコマンドが使えるV2Flyのバージョンでは、設定ファイルのあるディレクトリで次のコマンドを実行できます。Windowsでカレントディレクトリから実行する場合は、プログラム名を .\v2ray.exe とします。他のバージョンでは、ローカルのヘルプで引数を確認してください。起動前に、デスクトップクライアントが 10808 を使用していないことを確認します。

v2ray version
v2ray help
v2ray test -c config.json
v2ray run -c config.json

test の成功は、現在のコアが設定を受け付けたことを示すだけで、ネットワークに接続できることを保証しません。コアを起動したまま、別のターミナルで次のコマンドを実行してください。Windowsでは curl.exe を使うと、コマンド名がターミナルのエイリアスに置き換わるのを防げます。

curl --connect-timeout 10 --max-time 20 --proxy socks5h://127.0.0.1:10808 -I https://example.com/
curl --connect-timeout 10 --max-time 20 --proxy socks5h://127.0.0.1:10808 -I https://example.org/

1. 1つ目のテストでは直接接続を確認します。現在のネットワークから接続先にアクセスできる場合、最初のコマンドでHTTPレスポンスヘッダーが返ります。ステータスコードは接続先サイトによって異なり、必ず 200 になるわけではありません。
2. 2つ目のテストでは接続拒否を確認します。2つ目のリクエストでは、正常なHTTPSレスポンスが返らないはずです。エラーの内容はcurlやコアのバージョンで異なるため、特定のエラーメッセージだけで成否を判断しないでください。
3. タイムアウトも確認します。コマンドでは接続タイムアウトを10秒、全体のタイムアウトを20秒に設定し、長時間の待機を避けています。これは応答速度の測定でも、性能の評価でもありません。
4. 設定を1項目ずつ変更します。まず拒否ルールの outboundTag を direct に変更し、再テストしてからコアを再起動します。2つ目のリクエストが再び応答すれば、タグ参照とルールが処理に反映されていることを確認できます。

ディスク上のJSONを変更しても、実行中のプロセスが自動的に読み直すとは限りません。この記事の手動実行手順では、旧プロセスを停止し、設定をテストしてから再起動してください。v2rayNでサブスクリプションのノードを使う場合、クライアントが実行用設定を再生成することがあります。クライアントが生成したファイルと、自分で管理するカスタム設定を区別し、編集前にコピーを保存してください。

8. よくある設定トラブルと対処法

最終確認は、JSONを解析できる、コアが起動する、inboundに接続できる、ルールに一致する、outboundから接続先へ到達できる、の順に行います。一度に変更するのは1つの階層だけにし、動作する基準設定を残してください。後からVMess、VLESSや複雑なDNS振り分けを追加する場合も、設定全体を入れ替えて試行錯誤するのではなく、問題のある項目を絞り込めます。