V2Rayの設定ファイルを解説｜config.jsonのinbounds・outbounds・routingを読み解く

1. config.jsonの主な5つのセクション

config.jsonはコアが読み込む設定ファイルであり、サブスクリプションURLでもクライアントの全設定でもありません。v2rayNはノード、サブスクリプショングループ、画面上の設定を管理し、選択内容をコアの実行に必要な設定へ変換します。同じファイル名でも、V2RayとXrayですべての項目を相互に使えるとは限りません。

ファイルの先頭から順に読む必要はありません。まずinboundsでリクエストの入口を確認し、次にroutingで接続経路の選択方法を確認します。最後にoutboundsで実際の出口を特定します。logはトラブルの調査に役立ち、dnsにはコアが必要に応じて使う名前解決の設定が含まれます。

2. サンプル全体：ローカル接続、直接接続、ドメインのブロック

ここでは、V2RayとXrayでよく使われる従来形式のJSON項目を使い、設定の構造を確認します。ローカル端末からのみ接続できる入口を2つ用意しています。SOCKSポートは10808、HTTPポートは10809です。example.orgとそのサブドメインへの接続はブロックし、それ以外の接続はこの2つの入口から直接接続します。

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

ポート番号はこのサンプルで明示的に指定した値であり、すべてのクライアントバージョンの既定値ではありません。JSONではオブジェクトに波括弧、配列に角括弧を使います。キー名と文字列は半角の二重引用符で囲み、最後の要素の後ろにカンマは付けません。異なるコアでも読みやすいよう、このサンプルではコメント構文を使っていません。

3. inbounds：待ち受けアドレス、ポート、入口プロトコル

inboundsは配列なので、1つのコアで複数のローカル入口を提供できます。listenは待ち受けるネットワークインターフェース、portはアプリが接続するポート、protocolはアプリが使うプロキシプロトコルを指定します。ポート番号だけでなく、この3項目を合わせて確認してください。

127.0.0.1は同じ端末からの接続のみを許可します。0.0.0.0に変更すると、すべてのIPv4インターフェースで待ち受けるため、LAN内の他の端末から入口に接続できる可能性があります。サンプルのSOCKS入口はnoauthを使用しているため、トラブル調査のためだけに待ち受け範囲を広げないでください。

• アプリから入口に接続できない場合：アプリに設定したプロキシの種類とポートを確認してください。HTTPプロキシにSOCKSのポートを指定しないよう注意します。
• コアでポート使用中のエラーが出る場合：クライアントが二重に起動していないか、以前のコアプロセスが終了しているか確認してください。
• ブラウザーの通信がプロキシを通らない場合：システムプロキシまたはブラウザー独自のプロキシ設定が有効か確認してください。コアを起動しても、すべてのアプリの通信経路が自動で切り替わるわけではありません。

v2rayNでは、「設定」→「パラメーター設定」からローカルの待ち受けポートに関する項目を確認し、メイン画面の「システムプロキシ」メニューで「システムプロキシを自動設定」を選択できます。画面や項目の位置はバージョンによって異なる場合があります。現在の画面に表示される名称と実際のポートを確認してください。

4. outbounds：出力プロトコルとtagの対応

outboundsも配列ですが、コアからリクエストを送る方法を定義します。このサンプルでは、freedomが接続先への直接接続、blackholeが通信のブロックを表します。directとblockは任意に付けたタグであり、プロトコル名ではありません。

プロキシoutboundを使うには、サーバーアドレス、ポート、ユーザー識別情報に加え、サーバー側と一致する通信方式やセキュリティ設定が必要です。VMessとVLESSではユーザー情報の設定が異なり、TLS、REALITY、WebSocketなども設定場所や適用条件がそれぞれ異なります。"protocol": "freedom"を"vless"に変更するだけでは設定は完了しません。

どのルールにも一致しない接続には、通常outbounds配列の先頭にあるoutboundが使われます。この既定動作は自動フェイルオーバーではありません。サンプルではdirectを先頭に置き、2つ目のルールで2つのローカル入口からの接続を明示的に処理しているため、判定結果を確認しやすくなっています。

5. routing：ルールの順序とドメインの照合

一般的なfieldルールは配列の順番に判定され、一致すると対応する出口が選ばれます。後続の「より詳細な」ルールを探すことはありません。サンプルでは、先に指定ドメインをブロックし、次に2つの入口からのそれ以外の接続を直接接続します。2つのルールを入れ替えると入口のルールが先に一致し、ドメインのブロックが機能しなくなります。

1. 接続先を受け取る：アプリは入口を通じてドメイン名またはIPアドレスを渡し、コアはその情報を使ってルーティングを判定します。
2. 1つ目のルールを確認：domain:example.orgは該当ドメインとそのサブドメインに一致し、一致した接続にはblockが選ばれます。
3. 2つ目のルールを確認：1つ目に一致しなかった場合、local-socksまたはlocal-httpからの接続にはdirectが選ばれます。
4. どのルールにも一致しない接続を処理：ほかの入口からの接続があり、どのルールにも一致しない場合は、既定のoutbound動作に従います。

1つのルールにある複数の条件は、通常すべて満たす必要があります。一方、同じ条件の配列に複数の値がある場合は、通常どれか1つに一致すればよいという意味です。たとえば1つのルールにinboundTagとdomainを指定すると、「指定した入口から来て、かつ対象ドメインに一致する」という条件になります。どちらか一方だけを満たせばよいわけではありません。

このサンプルではトラフィックのスニッフィングを設定していません。アプリがドメイン名をIPアドレスに解決してから、そのIPアドレスだけをコアに渡す場合、ドメインルールに一致しないことがあります。その場合は、ブロックルールをすぐに広げるのではなく、アプリからプロキシへドメイン名が渡されているか確認してください。ドメインによる振り分けでは、URL内のパス（/accountなど）は照合できません。

6. dns：リゾルバーの設定とシステム全体のDNS制御は別

dns.serversでは、組み込みDNSが使うサーバーを定義します。サンプルの1.1.1.1は、明示的に指定したリゾルバーのアドレスです。このアドレスを設定しても、システムDNSが変更されるわけではなく、ブラウザー独自の暗号化DNSがそこを経由するとも限りません。組み込みDNSが使われるかどうかは、ルーティングポリシー、outboundの設定、実際のリクエストの種類によって異なります。

• AsIs：ルーティング時に既存の宛先情報を使い、IPルールのためにドメインを積極的に解決しません。サンプルでは、ドメインルールの動作を確認しやすいようこの値を使います。
• IPIfNonMatch：ドメインルールに一致しなかった場合、対象ドメインを解決してからIPルールを試すことができます。
• IPOnDemand：判定中にIPアドレスが必要なルールがあると、ドメイン名の解決を行うことができます。

これらの値はrouting.domainStrategyの設定です。outboundごとのdomainStrategyと混同しないでください。ルーティングは「どの出口を使うか」を決め、outboundの解決ポリシーは「接続先へどのように接続するか」に影響します。名前は似ていますが、適用される段階が異なります。

設定にgeoip:やgeosite:の条件がある場合は、実行環境に対応するデータがあるかも確認してください。この記事のサンプルではこれらの条件を使わず、データファイルの不足とJSON構造の問題を切り分けています。

7. logと安全な調整：変更は一度に1項目

サンプルのloglevelはwarningです。警告やエラーの確認には適していますが、接続ごとのルーティングの詳細までは記録されないことがあります。問題の特定が必要な場合は、一時的にinfoへ変更してください。さらに詳しいdebugは、短時間の診断に適しています。ログには接続先のドメイン名やアドレスが含まれる場合があるため、他の人に送る前に機密情報を削除してください。

1. 設定の出所を確認：クライアントが生成した実行用ファイルなのか、個別に管理しているカスタム設定なのかを確認してください。インストール先にある、名前が似たファイルをむやみに編集しないでください。
2. 現在の状態を保存：選択中のノード、システムプロキシの状態、待ち受けポートを記録し、元の設定ファイルも保存しておくと、変更を戻す際に役立ちます。
3. まず画面上の設定を変更：ローカルポートはv2rayNの「設定」→「パラメーター設定」で調整し、振り分けルールは「設定」→「ルーティング設定」で確認します。項目名は使用中のバージョンによって異なる場合があります。
4. 一度に変更するのは1項目：まずポートを変更して入口を確認し、次にルールの順序を変更します。DNS、通信パラメーター、outboundタグを同時に変更しないでください。
5. 再読み込み後、最初のエラーを確認：まずJSONの解析エラー、ポートの待ち受けエラー、タグ参照エラーを解消してから、ネットワークに接続できるかを確認してください。
6. ログレベルを通常の設定に戻す：調査が終わったら適切なレベルに戻し、詳細な接続記録が大量に残り続けないようにしてください。

v2rayNはデスクトップクライアントです。Android向けのv2rayNGはXrayコアを、v2flyNGはV2Flyコアを使用します。設定のインポート方法や対応する項目には違いがあります。サブスクリプションをインポートできたことは、クライアントが内容を解析できたことを示すだけで、すべてのプロトコルの組み合わせが現在のコアで使えるとは限りません。

8. 設定エラーとWebページが開けない場合の調査手順

問題を「設定が読み込まれているか」「アプリがプロキシに接続しているか」「ルーティング先が正しいか」「出口に接続できるか」の4段階に分けて調べると、サブスクリプションを何度もインポートし直すより効率的です。以下の症状は原因を絞るための手掛かりです。ログの1行だけでサーバー障害と決めつけないでください。

最後に、次の3点を覚えておきましょう。入口のポートはリモートサーバーのポートとは別です。outboundタグはプロトコル名ではありません。DNSの設定はシステム全体の通信をDNSに振り向ける設定ではありません。この3つを区別してから実際のノード設定を読むと、複雑な通信パラメーターも正しい場所に整理しやすくなります。