V2Ray config.jsonの読み方｜inbounds・outbounds・routingを項目ごとに解説

1. クライアント設定とコアの実行設定を区別する

config.jsonは通常、コアが読み込むJSONファイルを指します。ファイル名だけで中身が決まるわけではありません。v2rayNが保存するサーバー一覧、サブスクリプショングループ、画面設定はクライアント側の管理データです。コアの起動時には、選択中のサーバーやルーティング設定をもとに、クライアントが実行用の設定を生成します。共有リンクを1つだけエクスポートしても、inboundsやroutingを含む完全な設定にはなりません。

確認するときは、実際に使われている設定ファイルを基準にしてください。v2rayNはバージョンによってエクスポート方法や生成ファイルの保存場所が異なる場合があります。エクスポート対象がサーバー共有情報ではなく、完全な設定であることを確認しましょう。Android版のv2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。基本構造は似ていますが、拡張項目まで共通とは限りません。

• inbounds：アプリからの接続を受け付けます。例：PC上のSOCKSまたはHTTPプロキシポート。
• outbounds：通信の出口を定義します。例：VMessプロキシ、直接接続、接続拒否。
• routing：ルールに応じて接続先のoutboundを選びます。outbound自体を作成する機能ではありません。
• logとdns：ログと内蔵DNSの動作をそれぞれ設定します。システムプロキシの切り替えとは別の設定です。

2. 個人情報を除いたconfig.jsonの全体例

以下はクライアントが出力する完全な設定の構成をもとにした例です。ローカルinboundsを2つ、outboundsを3つ、routingルールを2つ含み、アドレスや認証情報は例示用に置き換えています。完全なJSONドキュメントですが、接続可能なノードではありません。example.com:443にVMessサーバーが存在するわけではないため、このままネットワーク接続のテストには使えません。

{
  "log": {
    "loglevel": "warning"
  },
  "dns": {
    "servers": ["localhost"]
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "http-in",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-1111-4111-8111-111111111111",
                "alterId": 0,
                "security": "auto"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "example.com"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.org"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

3. inbounds：待ち受けアドレス・ポート・プロキシ方式

1つ目のinboundは127.0.0.1:10808でSOCKSリクエストを受け付け、2つ目は127.0.0.1:10809でHTTPプロキシリクエストを受け付けます。これらはこの記事のサンプルで指定したポートであり、お使いのクライアントと同じとは限りません。アプリに設定するポートは、アプリで選んだプロキシ方式によって決まります。接続先サイトがHTTPかHTTPSかで決まるものではありません。

listenがループバックアドレスの場合、接続できるのは同じ端末上だけです。LAN内で共有するために0.0.0.0へ変更すると、待ち受け範囲が広がります。認証とファイアウォールもあわせて検討し、アドレスだけを変更しないでください。この例のSOCKS inboundにあるauth: "noauth"は認証を要求しない設定です。ローカル利用の範囲で使ってください。

udp: trueはSOCKS inboundでUDPを使えるようにする設定です。システム全体のUDP通信を自動でプロキシに送る機能ではなく、HTTP inboundにも同じ機能があるという意味ではありません。アプリがこのポートを使っていなければ、コアが起動しても期待するプロキシ接続は行われません。

4. outbounds：ノード情報・通信方式・出口タグ

outboundsは複数の出口を登録できる配列です。この例では、1つ目の出口にproxyというタグを付け、プロトコルにVMessを指定しています。vnext内のaddressとportは接続先サーバーのアドレスとポート、users内のidはユーザー認証情報です。ここでの443はリモートサーバーのポートで、ローカルの10808や10809とは役割が異なります。

directはfreedomで接続先へ直接アクセスし、blockはblackholeで通信を拒否します。これらは単なるタグ名で、実際の動作はprotocolで決まります。freedomのタグを「proxy」に変えても、リモートプロキシにはなりません。この例ではblockを参照するルールがないため、outboundを定義しただけではリクエストは遮断されません。

5. routing：ルールの順序・tagの参照・デフォルトの出口

routingルールは上から順に確認され、条件に一致すると、そのルールで指定した出口が選ばれます。この例の1つ目のルールは、完全一致するドメインexample.orgだけをdirectへ送ります。full:はドメイン全体との完全一致を表し、サブドメインには一致しません。2つ目のルールは、プライベートアドレス範囲に一致する接続先を同じ出口へ送ります。どのルールにも一致しない接続には、outboundsの先頭にあるproxyが使われます。

1. 接続先がドメインexample.orgの場合：1つ目のルールに一致し、tag: "direct"のoutboundが選ばれます。
2. 接続先が192.168.1.20の場合：2つ目のプライベートアドレスルールに一致し、LAN内の接続先へ直接アクセスします。
3. 接続先がほかのルールに一致しないドメインの場合：先頭のoutboundproxyが選ばれ、サンプルのVMessサーバーへの接続を試みます。

outboundTagはoutboundのtagと大文字・小文字も含めて完全に一致させる必要があります。inboundのタグは、ルールのinboundTag配列で条件に使えます。たとえば["socks-in"]からの接続だけを対象にできます。inboundとoutboundのタグが自動で対応付けられるわけではなく、同じ名前にする必要もありません。

この例ではdomainStrategy: "AsIs"を指定しているため、ルーティング時にIPルールを適用する目的でドメイン名を積極的にIPアドレスへ解決しません。接続がドメイン名のまま渡される場合、2つ目のプライベートIPルールでは、最終的な接続先がLAN内のアドレスかどうかを判定できないことがあります。この動作が必要な場合は、IPIfNonMatchやIPOnDemandで名前解決が行われるタイミングを理解し、DNS設定と合わせて調整してください。すべてのドメインリクエストに接続先IPがあると決めつけないようにしましょう。

6. dnsとlog：「読み込める」ことと「接続できる」ことは別

この例のdns.serversではlocalhostを指定しています。名前解決が必要な場合に、内蔵DNSからシステムの名前解決機能を利用できる設定です。ローカルでDNSサーバーのポートを開く設定ではなく、アプリからほかのDNSサーバーへ送られるリクエストを自動で引き受けるものでもありません。ルーティング用、outbound用、アプリ自身の名前解決はそれぞれ異なる段階で行われるため、実際のinbound方式とあわせて確認してください。

loglevel: "warning"では、通常の接続情報が少なくなります。問題を調べる間だけinfoに変更し、コアを再起動して失敗するリクエストを一度再現してください。確認後は元に戻します。ログにはアクセス先のドメイン、接続先アドレス、設定ファイルのパスが含まれる場合があります。公開の場で相談する前に、サブスクリプションURL、ユーザー認証情報、個人用のパスを削除してください。

• 起動直後に終了する：まずJSONの構文、項目の型、コアが認識しないプロトコル設定を確認します。ポートは10808のような数値で指定し、説明文を含めた文字列にしないでください。
• 待ち受けに失敗する：10808や10809が別のクライアントのプロセスに使用されていないか確認してください。先にリモートサーバーのポートを変更する必要はありません。
• ローカルポートには接続できるが、リモート側で失敗する：サーバーアドレス、443番ポート、ユーザー認証情報、TLS名がサーバー側の設定と一致しているか確認してください。
• 一部の接続先だけ出口が違う：ルールの順序、タグの参照先、リクエストがドメイン名とIPアドレスのどちらで渡されているか、ルールに一致しない場合のデフォルト出口を確認してください。

7. config.jsonのよくある質問