config.jsonの構造を段階別に解説：inbounds・outbounds・routingの役割

設定がv2rayNのサブスクリプション機能で生成された場合でも、管理者が手作業で整えた場合でも、基本構造は3つの問いに整理できます。通信はどこから入り、どこから出て、どの条件で出口が決まるのか。これを理解すれば、「ポートには接続できるのにWebページが開かない」「直結対象のドメインまでプロキシを経由する」「ブロックルールが適用されない」といった障害も効率よく切り分けられます。

まず通信経路全体を把握する：入入口・マッチング・出口

アプリケーションが直接「routingに入る」わけではありません。ブラウザーなどのプログラムがまずローカルの待受ポートへリクエストを送り、inboundsが接続を受けてコア処理用の宛先情報を生成します。routingは宛先ドメイン、宛先IP、ポート、ネットワーク種別、入入口タグを読み取り、条件に一致するとルールのoutboundTagが特定のoutbounds項目を指します。どのルールにも一致しない場合は、通常outbounds配列の先頭項目がデフォルト出口になるため、配列の順序も設定ロジックの一部です。

config.jsonは、互いに無関係なパラメータの集まりではなく、有向接続グラフとして捉えると分かりやすくなります。inboundsのtagは通信元を示し、outboundsのtagは出口に名前を付け、routing.rulesがそれらの名前を参照して接続を完成させます。tag自体がデータを転送したり、自動でプロキシチェーンを構築したりするわけではありません。コア内部で使う、安定した大文字・小文字を区別する参照キーです。

inbounds：ローカルでの通信受付方法を定義

inboundsは入入口の配列で、各項目が1つの待受入口を表します。デスクトップでは、SOCKS、HTTP、またはクライアントが管理する透過プロキシ入口がよく使われます。最も基本的なSOCKS入入口では、listen、port、protocol、settingsを明示します。待受アドレスを127.0.0.1にするとローカルアプリだけがアクセスできます。0.0.0.0に変更するとすべてのネットワークインターフェースで待ち受けるため、LAN内の端末からアクセスされる可能性があります。両者を同じものとして扱ってはいけません。

{
  "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：この入口をsocks-inと命名します。後続のルールではinboundTagを使い、この入口からのリクエストだけを処理できます。
• listen：バインドするアドレスを指定します。127.0.0.1はローカルループバックアドレスで、現在のPCだけで使うクライアント設定に適しています。
• port：待受ポートを指定します。例では10808を使用しているため、ブラウザーやアプリのSOCKS5プロキシポートにも10808を入力します。
• protocol：アプリケーションがローカルのコアと通信する方法を宣言します。ここではSOCKSであり、リモートノードもSOCKSを使うという意味ではありません。
• settings.udp：SOCKS入入口でUDPリクエストを受け付けます。これは入入口側の機能を有効にするだけで、実際に利用できるかはリモートプロトコル、トランスポート方式、対象アプリにも左右されます。
• sniffing：HTTPリクエストやTLSハンドシェイクから宛先ドメインを復元し、ドメインベースの振り分けルールを適用できるようにします。

ポート競合は、コアが待受ソケットを作成するときに発生します。10808が別のプロセスに使用されている場合、inboundsはまだ通信を受け付けておらず、その後のroutingやoutboundsも実行されません。v2rayNでは「設定」→「パラメータ設定」からローカルSOCKSポートを変更できます。10818に変更したら、ブラウザーのプロキシ、システムプロキシ、その他のアプリでもポートを10818に合わせてください。

outbounds：プロキシ・直結・ブロックの出口を定義

outboundsは出口の配列です。各出口には一意のtagが必要で、protocolが離脱通信の処理方法を決めます。リモートプロキシ出口にはサーバーアドレス、ポート、ユーザー識別子、トランスポートパラメータが含まれます。直結出口にはfreedom、接続を能動的に終了する出口にはblackholeを使います。3種類を同時に用意し、routingで実際の出口を選択できます。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "node.example.net",
            "port": 443,
            "users": [
              {
                "id": "11111111-1111-4111-8111-111111111111",
                "security": "auto"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/connection"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

上記のドメイン、ユーザー識別子、パスは構造を示すためのもので、サブスクリプションの実ノードパラメータの代わりにはなりません。VMessのsettingsはユーザーとサーバーを、streamSettingsはトランスポート層を定義します。アドレスとポートが正しくても、WebSocketパス、TLS設定、ユーザー識別子のいずれかが一致しなければ接続は失敗します。

routing：条件に応じてリクエストを指定出口へ渡す

routingは待受を作成せず、リモートノードの認証情報も保持しません。役割はリクエストの特徴を読み取り、出口タグを返すことです。rules配列は上から順に照合され、通常は最初に有効なルールへ一致した時点で検索を終了します。そのため、範囲が狭く優先度の高いルールを前に置き、広範囲のフォールバックルールを後ろに置きます。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": [
          "socks-in"
        ],
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

3つのルールが解決する問題

1. 1つ目はGeoSiteの分類を読み取り、広告ドメインに一致したらblockへ渡します。このルールを使うには、ローカルのGeoSiteデータをコアが正常に読み取れる必要があります。
2. 2つ目はプライベートIP範囲に一致した通信をdirectへ渡し、LANアドレスがリモートプロキシ出口へ回るのを防ぎます。
3. 3つ目は送信元をsocks-inに限定し、残りのTCP・UDPリクエストをproxyへ渡します。範囲が広いため、具体的なルールの後ろに置きます。

domainStrategyは、ドメインルールとIPルールの間で使う名前解決方針を制御します。AsIsは元のドメインを優先して照合し、すべてのIPルールのためにドメインを積極的に解決することはありません。IPIfNonMatchはまずドメインルールを試し、一致しなければIPを解決してIPルールを続けて確認します。IPOnDemandは照合中に、より積極的に名前解決を行います。一般的な振り分け設定ではIPIfNonMatchから始めると、ドメイン分類を維持しつつ、プライベートIPなどのルールも適用しやすくなります。

tagで3段階の設定を1本の経路につなぐ方法

tagで重要なのは、「定義されていること、綴りが一致していること、用途が明確であること」です。入入口タグがsocks-inで、3つの出口タグがproxy、direct、blockだとすると、routingが参照できるのは定義済みのこの4つの名前だけです。outboundTagをProxyやproxy-mainと書いても、proxyへ自動的に関連付けられることはありません。

inbounds[0].tag = "socks-in"
routing.rules[2].inboundTag = ["socks-in"]

outbounds[0].tag = "proxy"
routing.rules[2].outboundTag = "proxy"

outbounds[1].tag = "direct"
routing.rules[1].outboundTag = "direct"

outbounds[2].tag = "block"
routing.rules[0].outboundTag = "block"

リクエストが実際に通る順番で確認する

1. アプリのプロキシ種別がSOCKS5で、アドレスが127.0.0.1、ポートがinbounds.portと同じであることを確認します。例ではポート10808です。
2. コアのログに「アドレスはすでに使用されています」や設定解析失敗のメッセージがないことを確認します。待受に失敗している間は、リモートプロトコルを調べても意味がありません。
3. リクエストが想定した入入口から来ていることを確認します。ルールがinboundTagを限定している場合、別のHTTP入入口から入ったリクエストはそのルールに一致しません。
4. routing.rulesの並び順に従って最初に一致する項目を探し、そのoutboundTagを記録します。
5. outboundsから完全に同名のtagを探し、対応するprotocol、サーバーアドレス、ポート、streamSettingsを確認します。
6. どのルールにも一致しない場合は、outboundsの先頭項目が本当に使用予定のデフォルト出口か確認します。

送信元ごとにポリシーを分ける場合は、複数の入入口を設定できます。例えば10808のsocks-inはデフォルトでproxyへ、10818の別のSOCKS入入口はデフォルトでdirectへ送ります。この場合、2つの入口には異なるportと異なるtagを設定し、それぞれにinboundTag付きのルールを記述します。入入口だけをコピーして同じポートを残すと、起動時に待受ポートの競合が発生します。

設定変更時の安全な手順とよくある問題

v2rayNは、現在のノード、ルーティング設定、コアのオプションに基づいて実行用設定を生成します。生成ファイルを直接編集しても現在のプロセス中だけ有効で、ノード切り替え、サブスクリプション更新、クライアント再起動後に再生成されることがあります。長期的に保持したいルーティングは、クライアントのルーティング設定で管理するのが基本です。ローカルポートを変更するときは「設定」→「パラメータ設定」を使い、そのポートを呼び出すすべてのアプリにも反映してください。

• 変更前に現在動作している設定のコピーを保存し、毎回1つのフィールドグループだけを調整します。
• JSONを編集したら、カンマ、引用符、配列、オブジェクトの閉じ方を確認してからコアを起動します。
• outboundsの順序を変更するときは、先頭項目のtagを記録します。ルールに一致しない場合のデフォルト出口に関わるためです。
• routing.rulesを変更するときは、具体的なルールから広範囲のルールへ並べ、想定する出口を1件ずつ記録します。
• サブスクリプション更新後は、プロトコル、トランスポート、TLS、サーバーポート、ユーザー識別子が正しくインポートされているか再確認します。
• ルーティングの分類結果がおかしいときは、GeoIPとGeoSiteのデータを現在のコアが読み取れるか確認します。

config.jsonを理解するうえで重要なのは、すべてのフィールドを暗記することではありません。決まった切り分け手順を守ることです。入入口が待ち受けているか、リクエストにどの宛先情報が付いているか、どのルールが先に一致したか、outboundTagがどの出口を指すか、その出口で接続を完了できるかを順に確認します。ポート、プロトコル、ルーティングを同時に変更するより、この経路に沿って段階的に検証するほうが原因を特定しやすくなります。