V2Ray設定ファイルの構造を詳しく解説：inbounds・outbounds・routingを読み解く

まず通信の流れを確認：設定項目はどう連携するのか

V2Rayの設定は、独立したスイッチの集まりではありません。アプリがリクエストを特定のinboundへ渡すと、routingモジュールが宛先ドメイン、宛先IP、ポート、inboundタグを読み取り、指定されたoutboundへ送ります。どのルールにも一致しない場合、通常はoutbounds配列の先頭が使われるため、outboundsの並び順も結果に影響します。

inboundsは「通信がどこから入るか」、outboundsは「通信がどこから出るか」を定義し、routingが両者を結びます。設定で起動できても、JSON構造とフィールドを解析できたことを示すだけです。想定どおりに振り分けるには、タグの参照、ルールの順序、DNSの応答結果も確認する必要があります。

最小構成のひな形：完全なJSONから読み解く

以下の例では、ローカルのSOCKS inbound、VMessプロキシoutbound、直接接続outbound、ブロックoutboundを1つずつ使用します。サーバーのドメイン、ポート、ユーザーID、通信方式は構造を示すための例にすぎず、実際にはサーバー側の設定と項目ごとに一致させる必要があります。JSONにはコメントを記述できないため、説明文を正式な設定ファイルへ直接追加してはいけません。

{
  "log": {
    "loglevel": "warning"
  },
  "dns": {
    "servers": [
      "1.1.1.1",
      "localhost"
    ]
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-2222-3333-4444-555555555555",
                "security": "auto"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "none"
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "protocol": [
          "bittorrent"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:cn"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

この設定では、どのルールにも一致しないリクエストを先頭のoutbound proxyへ渡します。プライベートアドレス、中国本土のドメイン、中国本土のIPはdirectへ、特定のプロトコルはblockへ振り分けます。directをoutbounds配列の先頭に置き、明示的なプロキシルールを追加しない場合、未一致の通信は直接接続になります。

• tagは設定内部で使う名前です。自由に決められますが、参照先では大文字・小文字を含めて完全に一致させる必要があります。
• listenが127.0.0.1の場合は、同じ端末からの接続だけを受け付けます。一般的なデスクトップ向けプロキシの入口に適しています。
• portは数値で指定し、引用符付きの文字列にはしません。同じアドレスのポートを別のプログラムが使用していないことも確認してください。
• streamSettingsはサーバー側の通信パラメータと一致させる必要があり、プロトコル名だけから判断することはできません。

inbounds（受信）：アプリからカーネルへ通信を渡す仕組み

inboundは、V2Rayがローカルで開く受信入口です。例では127.0.0.1:10808をSOCKSとして待ち受けます。ブラウザー、ダウンロードツール、またはシステムプロキシにこのSOCKSアドレスを設定すると、リクエストがV2Rayへ入ります。カーネルを起動しただけで、アプリがinboundポートを向いていなければ、通常のアプリ通信が自動的に取り込まれることはありません。

settings.authをnoauthにすると、このSOCKS入口ではユーザー名とパスワードを要求しません。そのため、ローカルでの待ち受けを維持してください。udp: trueはSOCKS UDPリクエストの受け入れを許可しますが、後続のoutboundプロトコル、サーバー、ネットワーク環境も対応している必要があります。このフィールドを有効にするだけで、すべてのUDP通信が正常に通るわけではありません。

複数のinboundを同時に使用することもできます。たとえば10808をSOCKS用に残し、10809をHTTP用に追加します。各inboundには個別のタグを設定し、ルーティングルールでinboundTagを使って送信元を区別できるようにします。v2rayNのローカルポートを変更する場合は、「設定」→「パラメータ設定」でSOCKSとHTTPのポートを確認してください。アプリ側のプロキシポートも同時に変更する必要があります。

outbounds（送信）：プロキシ・直接接続・ブロックの役割

outboundは、リクエストがV2Rayから外へ出る方法を定義します。プロキシoutboundには通常、サーバーアドレス、サーバーポート、ユーザー認証情報、通信設定が含まれます。直接接続outboundにはfreedom、ブロックoutboundにはblackholeを使用します。routingモジュールはリモート接続を直接確立せず、ルールに基づいてoutboundタグを選択します。

VMessの例にあるvnextはサーバー一覧で、各サーバーには複数のユーザーを登録できます。addressとportはサーバー側の待受情報と一致させ、idはサーバーが認識するユーザー識別子にします。TCP、WebSocket、TLSなどのトランスポート設定も確認してください。クライアントとサーバーのどれか1項目でも異なると、接続直後に切断されたり、タイムアウトが続いたりする場合があります。

routing（ルーティング）：ルールの順序が最終的な出口を決める

routing.rulesは上から順に確認するルール配列です。リクエストが1つのルールに一致すると、そのルールで指定されたoutboundTagが使われ、後続のルールは処理されません。そのため、対象範囲が狭く優先度の高いルールを前に、範囲の広いルールを後ろに配置します。

domainStrategy: IPIfNonMatchは、まずドメインルールで照合し、一致しなければIPを解決してIPルールを続けて確認する設定です。これによりgeosite:cnとgeoip:cnを組み合わせられますが、DNSの結果がIPルールの判定に影響します。

1. まず、明示的にブロックしたいプロトコルや宛先を処理し、後続の広範な直接接続ルールが先に処理しないようにします。
2. 次にgeoip:privateを処理し、LANアドレスやプライベートアドレスを直接接続にします。
3. 続いてgeosite:cnを照合し、ドメイン分類に基づいて直接接続へ振り分けます。
4. ドメインに一致しない場合は、geoip:cnで解決後の宛先IPを確認します。
5. 残りの通信がどのルールにも一致しなければ、outbounds配列の先頭にあるproxyへ送られます。

ルール内のoutboundTagはプロトコル名ではなく、outboundオブジェクトのtagです。outboundタグがproxyなのに、ルールへProxyと書いても同じタグとはみなされません。outboundを削除・改名する場合は、ファイル全体を検索してすべての参照も更新してください。

DNSとログ：設定が正しくても振り分けが不安定になる理由

DNSはドメインをIPに変換するだけではありません。ドメインとIPを組み合わせて照合する場合、解決結果がルーティング判定に使われます。例ではサーバー一覧に1.1.1.1とlocalhostを指定し、特定のDNSを使う方法とローカルのリゾルバーへ任せる方法を示しています。実際の環境では、到達性、解決結果、振り分け先に応じて適切な方法を選んでください。

loglevelをwarningにすると、日常運用で警告とエラーを確認できます。ルールを調査するときは一時的にinfoへ変更して、より詳しい実行情報を取得してください。問題を確認したら元に戻し、ログの急増を避けます。JSON文字列は二重引用符で囲み、配列やオブジェクトの最後に余分なカンマを付けないでください。

{
  "log": {
    "access": "access.log",
    "error": "error.log",
    "loglevel": "info"
  },
  "dns": {
    "hosts": {
      "domain:internal.example.com": "192.168.1.20"
    },
    "servers": [
      "1.1.1.1",
      "localhost"
    ]
  }
}

• failed to listenのようなメッセージが出たら、まず待受アドレスとポートの使用状況を確認します。
• outboundタグが見つからない場合は、各outboundTagとoutboundのtagを照合します。
• リモートサーバーへの接続がタイムアウトするときは、アドレス、ポート、通信方式、現在のネットワークからの到達性を確認します。
• ドメインの直接接続結果が想定と異なる場合は、ルールの順序、domainStrategy、DNSが返すアドレスを確認します。

よくある変更トラブル：エラー箇所からフィールドを特定する

設定を手動で変更すると、JSON構文の破損、フィールド階層の誤り、タグ参照の断絶という3種類の問題が起こりがちです。構文エラーは通常カーネルの起動を妨げます。階層を誤ると未知のフィールドと表示される場合があります。タグの誤りは、リクエストが実際にルールへ一致したとき初めて判明することもあります。調査はファイル、入口、通信経路の順に確認しましょう。

v2rayNGとv2flyNGでも、サブスクリプションや共有リンクからクライアントの実行に必要な設定が生成されます。v2rayNGはXrayカーネル、v2flyNGはv2flyカーネルを使用するため、画面上のフィールド名や利用できる通信機能はカーネルによって異なる場合があります。一方のクライアントが出力した完全な設定を、別のカーネル環境へそのまま上書きしないでください。少なくともプロトコル、通信フィールド、ルーティング用リソースの互換性を確認します。

1. 現在正常に動作しているconfig.jsonをバックアップし、ローカルinboundポートを記録します。
2. 毎回1つのブロックだけ変更し、保存後にまず設定テストを実行します。
3. カーネルを起動し、127.0.0.1:10808が正常に待ち受けていることを確認します。
4. 単一の宛先でプロキシoutboundをテストし、その後に直接接続ルールとブロックルールを確認します。
5. ログの宛先アドレス、照合結果、接続エラーを確認し、問題がないことを確かめてから次の変更へ進みます。