V2Ray設定ファイル完全リファレンス

JSON構造の概要と処理フロー

設定を通過するデータの流れを確認する

V2Rayの設定は、互いに独立したスイッチの集まりではなく、順序を持つ処理チェーンです。アプリの通信はまず inbounds に入り、コアはインバウンド接続から宛先アドレス、ポート、ネットワーク種別、インバウンドタグを取得します。次に routing がルールを上から順に評価し、どのアウトバウンドへ渡すかを決めます。ドメイン名は、照合時または接続確立時に dns の名前解決を通る場合があります。最後に、outbounds から選ばれたプロキシ、ダイレクト接続、ブロックの出口が処理します。policy、log、統計設定は宛先を直接変えませんが、接続のライフサイクル、可観測性、トラブルシューティングの効率に影響します。この流れを理解するほうが、フィールドを個別に暗記するより確実です。

トップレベルのオブジェクトには通常、log、dns、inbounds、outbounds、routing、policyが含まれます。配列内の各インバウンドとアウトバウンドには、ルールから参照できるよう、分かりやすい tag を設定してください。タグは設定内部の識別子であり、自動的にネットワーク接続を作るものではありません。また、サブスクリプションのノード名とも別物です。よくあるミスは、ルールに outboundTag: proxy と書いたのに、実際のアウトバウンド名が proxy-main になっているケースです。JSON構文は通っても、実行時に想定どおりの経路を選べません。

{
  "log": {
    "loglevel": "warning"
  },
  "dns": {
    "servers": [
      "1.1.1.1",
      "localhost"
    ]
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "node.example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-1111-4111-8111-111111111111",
                "security": "auto"
              }
            ]
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": []
  }
}

オブジェクト、配列、フィールドの型

JSONの書式要件は厳格です。オブジェクトには波かっこ、配列には角かっこを使い、キー名と文字列はダブルクォートで囲みます。真偽値は true または false のみ使用でき、数値をクォートしてはいけません。最後のフィールドの後にカンマを置くことも、設定内に説明用コメントを混在させることもできません。「コアの起動に失敗する」原因の多くはプロトコルではなく、コピー時に混入した全角記号、スマートクォート、重複キー、括弧の階層ミスです。編集時はUTF-8テキストを保ち、まず純粋なJSON構文を検証してから、現在のコアが各フィールドをサポートしているか確認してください。

利用できるフィールドの範囲はコアの系統によって異なります。v2rayNGは通常Xrayコアと組み合わせ、v2flyNGはV2Flyコアに対応し、v2rayNは異なる種類のコアと設定を管理できます。VMess、VLESS、トランスポート層のセキュリティ、ルーティングのフィールドには共通点が多い一方、REALITYなどの機能は実際のコアの対応状況に応じて選ぶ必要があります。別のコア専用フィールドをそのまま貼り付けると、「未知のフィールド」、アウトバウンドの初期化失敗、保存時のフィールド破棄が起こりがちです。設定を移行する際は、まずプロトコルの機能を確認し、全体を一度に置き換えず段階的に移行してください。

GUIクライアントとコア設定の境界

v2rayN、v2rayNG、v2flyNGは、GUIの設定、サブスクリプションのノード、ルーティングオプションをコア設定へ変換します。GUIにある「システムプロキシ」「VPNサービス」「LANをバイパス」などの項目は、同名のJSONフィールドに対応するとは限りません。OS側のトラフィック制御に属するものもあれば、routing.rules に入るものもあります。トラブルシューティングでは、まず問題の層を切り分けてください。クライアントが通信を取り込んでいるか、生成された設定が正しいか、コアが正常に起動したか、宛先接続が想定したアウトバウンドに一致したかを確認します。サブスクリプションのノード状態だけを見ていると、システムプロキシとルーティング層を見落としがちです。

設定を手動で管理する場合は、socks-in、http-in、proxy、direct、block のように、一貫したタグ名を使うとよいでしょう。短く意味が一意の名前にすると、後でスペルミスを減らせます。複雑な設定では、各アウトバウンドの役割も記録してください。ノード名を恒久的な識別子にしてはいけません。クライアントがサブスクリプションを更新するとノード名が変わることがありますが、役割を表すタグは安定させ、「プロキシ、ダイレクト、ブロック」という論理的な出口だけにルーティングルールを依存させられます。

inbounds（インバウンド）：通信の入口

リッスンアドレス、ポート、公開範囲

inbounds は、ローカルのアプリがどのように通信をコアへ渡すかを定義します。デスクトップクライアントではSOCKSとHTTPのインバウンドが一般的で、モバイルクライアントではシステムのネットワークインターフェースを通じてアプリの通信を取り込むこともあります。手動設定で最初に確認すべきなのは listen と port です。127.0.0.1 でリッスンするとローカルからの接続だけを受け付け、ブラウザ、ターミナル、システムプロキシに適しています。すべてのネットワークインターフェースでリッスンすると到達可能範囲が広がるため、LAN環境、認証方式、OSのファイアウォールを併せて評価する必要があります。他の端末から接続する明確な理由がない限り、ローカルのみのリッスンが管理しやすい設定です。

ポートが他のプログラムに使用されておらず、異なるインバウンドが同じアドレスとポートの組み合わせを共有していないことを確認します。v2rayNのGUIに表示されるローカルポートは通常クライアントが管理します。設定を手動で変更してもGUIに古いポートが残っていると、システムプロキシが旧ポートを参照し続け、「コアは動作しているのにWebページが開けない」状態になります。この場合は、コアログのリッスン情報、クライアントに表示されたローカルポート、OSのプロキシ設定を確認し、3か所を一致させてください。

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true,
        "ip": "127.0.0.1"
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ],
        "routeOnly": true
      }
    },
    {
      "tag": "http-in",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

SOCKS、HTTP、透過的なトラフィック取り込み

SOCKSインバウンドは、SOCKS5に対応するアプリに適しており、udp: true によってUDPリクエストも受け付けられます。HTTPインバウンドは主にHTTPプロキシとCONNECTトンネルを処理し、多くのデスクトップソフトウェアと互換性があります。どちらも、アプリまたはシステムプロキシが対応するポートを明示的に参照する必要があります。透過的な取り込みは仕組みが異なり、OSのルーティング、仮想ネットワークインターフェース、転送ルールを通じて通信がコアへ送られるため、宛先アドレスの復元も複雑です。GUIクライアントは通常このプラットフォーム差を管理するため、システムの転送経路を理解しないまま、デスクトップ向けSOCKSの例を透過インバウンドへ変更することは推奨しません。

settings の内容はインバウンドプロトコルによって決まります。SOCKSの auth、udp と、HTTPインバウンドのアカウントフィールドを相互に流用することはできません。リッスン範囲をローカルに限定する場合、noauth は一般的な設定です。LAN内の端末に提供する場合は、まずクライアントで共有機能を有効にし、アクセス制御を設定してください。リッスンアドレスを広げるだけで共有を実現しようとしてはいけません。実際の公開範囲には、ファイアウォール、ネットワークの種類、認証も影響します。

トラフィックのスニッフィングとrouteOnly

sniffing は、HTTPリクエストやTLSハンドシェイクからドメイン名を識別し、元の宛先がIPアドレスだけの場合でもドメインルールを適用できるようにします。destOverride は識別対象のプロトコル種別を指定し、routeOnly はスニッフィング結果を主にルーティング判断へ使い、最終的な接続先を直接書き換えないことを示します。スニッフィングを有効にしても、すべての接続からドメイン名を取得できるわけではありません。暗号化されたクライアントハロー、非標準プロトコル、確立済み接続、ホスト情報を含まない通信では、IPアドレスしか確認できない場合があります。

スニッフィングを有効にしてから特定サイトへの接続に問題が出た場合は、2通りの方法で切り分けます。1つ目は一時的にスニッフィングを無効にし、ドメイン識別または宛先書き換えが原因か確認する方法です。2つ目はスニッフィングを維持したまま routeOnly を使い、ドメイン名だけをルール照合に利用する方法です。ルールが主にIPベースならスニッフィングの効果は限定的です。一方、domain、geosite、サフィックスルールを多用する設定では有効性が高くなります。最終的な選択は、固定的な性能スイッチではなくルール設計に基づいて決めてください。

outbounds（アウトバウンド）：プロキシ、ダイレクト、ブロック

アウトバウンドの役割と選択順

outbounds は、コアが利用できる出口を定義します。一般的な設定には、少なくともプロキシ用アウトバウンド、freedom によるダイレクト接続、blackhole によるブロックが含まれます。ルーティングルールは outboundTag でいずれかを選択します。ルールに一致しない場合、コアは通常、アウトバウンド配列の先頭にある利用可能な項目を使うため、配列の順序にも実際の意味があります。デフォルトをプロキシにするならプロキシ出口を先頭に置き、デフォルトをダイレクトにするなら順序を明示的に調整し、プロキシが必要な通信のルールも補ってください。タグ名だけを変更しても動作は変わりません。

1つのアウトバウンドは、プロトコル層、サーバーアカウント、トランスポート方式、安全層で構成されます。VMessまたはVLESSを例にすると、settings はサーバーアドレス、ポート、ユーザー情報を記述し、streamSettings はTCP、WebSocket、gRPCなどのトランスポートと、TLSまたはREALITYなどのセキュリティ方式を記述します。4つの要素はサーバー側のパラメータと一つずつ一致していなければなりません。アドレスが正しくてもトランスポート方式が違う場合や、ポートが正しくても安全層の名称が違う場合は、ハンドシェイクに失敗します。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "edge.example.com",
            "port": 443,
            "users": [
              {
                "id": "22222222-2222-4222-8222-222222222222",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "edge.example.com",
          "allowInsecure": false
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIP"
      }
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "response": {
          "type": "none"
        }
      }
    }
  ]
}

サーバーアドレス、ユーザー、トランスポート層

address にはドメイン名またはIPアドレスを指定でき、port は数値でなければなりません。ドメイン名を使う場合、コアは先に名前解決を行うため、DNS設定がプロキシ接続の確立に間接的な影響を与えます。ユーザー識別子、暗号化設定、flowなどのフィールドはプロトコルによって異なります。VMessのユーザーオブジェクトを名前だけ変更してVLESS設定として使ってはいけません。共有リンクやサブスクリプションにパラメータが含まれている場合は、まずクライアントに解析させるのが安全です。手動入力はフィールド確認に適していますが、パス、ホスト名、サービス名、サーバー名の記入漏れに注意してください。

streamSettings.network は下位トランスポートを示します。WebSocketを選ぶ場合は通常、パスとリクエストヘッダーのホストが必要です。gRPCではサービス名、TCPでも特定のヘッダーや安全層を設定することがあります。トランスポート名が同じでも、他のパラメータを省略できるとは限りません。トラブルシューティングでは「プロトコルのアカウント」と「トランスポートのハンドシェイク」を分けて考えます。アカウントの誤りはプロトコル認証段階で失敗しやすく、トランスポートパラメータの誤りは、より早い段階で接続切断、TLS名の不一致、サービスパスへの到達不能として現れます。

TLS、REALITY、コアによる違い

TLS設定の serverName はサーバー名の検証とハンドシェイクに使われます。ノードが提供する情報に従って入力し、接続先アドレスと単純に同一視してはいけません。allowInsecure は証明書検証を制御するため、通常の設定では false を維持します。ノードがREALITYを必要とする場合は、現在使用しているクライアントがその機能に対応するXrayコアであることを確認し、サーバー名、公開鍵、ショートID、フィンガープリントなど、ノードが指定した項目をすべて入力してください。v2flyNGはV2Flyコアを使用するため、クライアントは画面だけでなくノードのプロトコルとの互換性を基準に選びます。

v2rayNはデスクトップのノードと複数のコア設定を管理でき、Windows、macOS、Linuxに適しています。v2rayNGはAndroid向けで、主にXrayのプロトコル対応状況を基準に選択します。v2flyNGはV2Flyコア系統の選択肢です。3つとも設定管理層に位置しており、接続できるかどうかはプロトコルパラメータ、コアの対応状況、ネットワーク経路によって決まります。対応クライアントをインストールする場合は、クライアントダウンロードページでプラットフォームを選択してください。

ダイレクト、ブロック、チェーン接続

freedom はローカルネットワークから宛先へ直接接続することを示し、LAN、機器のアドレス、ローカル出口を明示的に必要とするドメインに適しています。blackhole はルールに一致した接続を終了するために使います。ブロックルールは十分前に置き、対象範囲をできるだけ絞ってください。更新サービス、ログインAPI、LAN内の機器まで一緒に遮断しないよう注意します。ログに接続終了しか表示されない場合は、すぐに別のプロキシノードへ替えるのではなく、まず宛先が block に誤って一致していないか確認してください。

複雑な設定では、proxySettings などの仕組みを使って、1つのアウトバウンドから別のアウトバウンドへ転送し、前段プロキシやチェーン接続を構成できます。経路が長いほどトラブルシューティングのコストは増えます。どの層でDNS、トランスポート、認証に失敗しても、最終接続は中断します。チェーン設定を作る前に、各出口が単独で動作することを確認し、その後に段階的に接続してください。中間アウトバウンドのタグは一意にし、チェーン内部専用の出口がルールから直接選ばれないようにします。

routing（ルーティング）：ルールの順序と一致範囲

上から順に評価し、一致した時点で停止

routing.rules はトラフィック分岐設定の中心です。ルールは配列の順序に従って上から下へ確認され、接続が1つのルールに一致すると、通常は後続ルールを評価しません。そのため、具体的なルールを汎用ルールより前に置きます。LANへのダイレクト接続は広範囲のプロキシルールより前に、明示的なブロック対象は広いドメインサフィックスより前に配置し、最後のルールまたはデフォルトのアウトバウンドでフォールバックを処理します。分岐の不具合は条件の書き間違いではなく、前にある広すぎるルールが先に通信を捕捉していることが少なくありません。

ルールは、ドメイン、IP、ポート、ネットワーク種別、インバウンドタグ、プロトコル識別結果、ユーザー識別子などで照合できます。1つのルールに複数種類の条件を指定すると、通常はすべての条件を満たす必要があります。同じフィールドの配列内に複数の値を指定した場合は、いずれか1つに一致すればよいことが一般的です。ルールを設計する前に、自然言語の要件を分解してください。たとえば「SOCKSインバウンドから入り、宛先ポート53のUDP通信をDNSアウトバウンドへ送る」には、インバウンドタグ、ポート、ネットワークという3種類の条件が含まれます。どれか1つ欠けるだけでも対象範囲が広がる可能性があります。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "domainMatcher": "hybrid",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.internal",
          "full:router.example.internal"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

ドメインルールでよく使う4つの記法

full: は完全なドメイン名に一致し、同一のホスト名だけを対象にします。domain: は通常、指定したドメインとそのサブドメインを対象にします。regexp: は正規表現を使うため柔軟ですが、範囲を広げすぎやすい点に注意が必要です。geosite: はコアが利用できる分類データを参照します。プレフィックスなしの記法は設定の文脈によって意味が変わる場合があるため、保守性を考えると一致方式を明示するのがおすすめです。ドメインルールを調べるときは、ページタイトルやサービス名ではなく、実際にアクセスしたホスト名を記録してください。

正規表現ルールでは、エスケープが二重になる点に注意が必要です。正規表現自体がバックスラッシュを使い、それをJSON文字列に入れると、さらにJSON用のエスケープが必要になります。目視だけでは漏れやすいため、full: や domain: で表現できる要件に、正規表現を優先して使う必要はありません。分類データもリアルタイムのネットワーク状態ではなく、データファイルの更新に伴って変わるドメインやアドレスの集合です。結果は、現在のコアが読み込んでいるデータ内容に左右されます。

IP、ポート、ネットワーク、インバウンドタグ

IPルールには単一のアドレス、CIDRネットワーク、geoip: 分類を指定できます。geoip:private はLANや予約アドレスをダイレクト接続にする用途でよく使われますが、実際のネットワーク環境との確認が必要です。会社や家庭のネットワークで特殊なアドレス範囲を使っている場合は、該当するサブネットを明示的に追加してください。ポートには単一値または範囲を指定でき、ネットワーク種別には tcp、udp、またはその組み合わせを使います。条件を明確にするほど、他の通信への副作用を抑えられます。

inboundTag を使うと、同じ宛先でも入口に応じて異なるポリシーを適用できます。たとえばブラウザが socks-in から入った場合はプロキシへ送り、別のインバウンドから入ったローカルサービスはダイレクト接続にできます。これはコアのインスタンスを2つ用意するより管理しやすい方法です。前提として、インバウンドタグが実在し、スペルも一致していなければなりません。タグの比較では通常、大文字と小文字や余分な空白も区別されます。クライアントが設定を再生成することでも、ルールが機能しなくなる場合があります。

domainStrategyで名前解決を発生させる方法

AsIs は接続に含まれるドメイン名を優先してルーティングし、IPルールのために能動的な名前解決を行いません。IPIfNonMatch はドメインルールに一致しなかった場合にドメイン名をIPへ解決し、IPルールへの一致を試みます。IPOnDemand はIP条件が必要になったとき、より積極的に名前解決を行います。積極的な戦略ほどIPベースの分岐能力は高まりますが、DNSへの依存も深くなります。DNSサーバーに到達できない場合や、想定外の結果が返る場合、ルーティング段階で遅延や誤判定が発生することがあります。

選択する戦略はルールセットと組み合わせて考えます。ドメインルールが中心で、IPルールが直接指定されたアドレスだけを処理する場合は、AsIs のほうが分かりやすいでしょう。ドメイン名を最終的に地域別のIP分類へ一致させたい場合は、IPIfNonMatch を検討します。変更後はドメイン宛てと直接IP宛てを別々にテストし、ログで実際に選ばれたアウトバウンドを確認してください。接続成功後に通信できない場合の体系的な確認方法は、DNS、ルーティングルール、システムプロキシの確認チェックリストも参照してください。

DNS設定：名前解決経路と分岐の整合性

内蔵DNSとシステムDNSの役割

dns モジュールは、コア内部のドメイン名解決に使うルールとサーバーを指定します。主な用途は、ルーティング判断、プロキシサーバーのドメイン解決、コアが取り込んだリクエストの処理です。ただし、OS全体のDNS動作を必ず置き換えるわけではありません。アプリが独自に暗号化DNSを使う場合、ブラウザがシステム設定を回避する場合、通信がコアへ入っていない場合は、その問い合わせがここを通らない可能性があります。トラブルシューティングでは、まず「誰が名前解決を行っているのか」を確認してからV2RayのDNS設定を調べてください。すべてのドメイン障害を同じモジュールの問題と考えてはいけません。

servers には通常のアドレス、localhost、一致するドメインを指定したサーバーオブジェクトを含められます。単純なリストでは設定した戦略に従ってリゾルバーが選ばれ、サーバーオブジェクトを使えば特定のドメインを指定したDNSサービスへ渡せます。DNSサーバー自体をドメイン名で指定すると、コアはそのサーバーアドレスを先に解決しなければならず、余計な依存関係が生まれます。基礎となるDNSサーバーには、到達性が明確なアドレスを使い、接続をダイレクトにするかプロキシ経由にするかも確認してください。

{
  "dns": {
    "queryStrategy": "UseIP",
    "disableCache": false,
    "disableFallback": false,
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": [
          "domain:example.com"
        ],
        "skipFallback": true
      },
      {
        "address": "8.8.8.8",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "localhost"
    ],
    "hosts": {
      "router.example.internal": "192.168.1.1"
    }
  }
}

hosts、キャッシュ、問い合わせ戦略

hosts は静的なドメイン名マッピングを提供し、固定されたLAN内サービスやテスト環境に適しています。通常は外部問い合わせより優先されるため、古いマッピングが実際の名前解決結果を長期間上書きすることがあります。サーバーアドレスを変更しても古いIPへ接続される場合は、まず hosts を確認し、次にDNSキャッシュを調べます。静的マッピングは本当に安定した宛先だけに限定し、ネットワーク変更時には忘れず更新してください。

disableCache はコアのDNSキャッシュを制御します。キャッシュを有効にすると、再問い合わせと接続待ちを減らせます。名前解決の変化を調べる場合は一時的に無効にできますが、長期間無効にすると問い合わせ数が増えます。queryStrategy は優先して問い合わせるアドレスファミリーを決めます。よくある選択肢にはIPを使う設定、IPv4のみ、IPv6のみがありますが、具体的な名称と対応範囲は現在のコアに従ってください。ローカルネットワークに安定したIPv6経路がないのにIPv6アドレスを取得して優先接続すると、名前解決は成功しても接続がタイムアウトすることがあります。

ドメインごとにリゾルバーを指定する

サーバーオブジェクトの domains は、そのリゾルバーが担当するドメインを限定します。一致方式はルーティングのドメインルールに近く、完全一致、サフィックス、分類データなどを使用できます。skipFallback は、そのサーバーに一致したドメインを共通のフォールバック処理へ進ませない設定です。特定のDNSサーバーを必ず使う内部ドメインに適していますが、範囲を広げすぎると、そのサーバーで失敗した後に他の名前解決経路を失います。

disableFallback はフォールバックの動作全体を変えるため、サーバーの一致順序を理解しないまま有効にするのは適切ではありません。まずはフォールバックを残し、ログで特定のドメインがどのサーバーを選んだか確認してから、確実な対象に限って skipFallback を追加するほうが安全です。DNSの分岐とルーティングの分岐は整合させてください。あるドメインのDNS問い合わせをプロキシへ送ったのに、解決後の接続をダイレクトへ送ると、出口から見た経路が一致しないことがあります。逆の場合も同様で、名前解決と接続の経路が分かれるほど原因特定は難しくなります。

プロキシサーバーのドメイン名に関する起動時の依存関係

プロキシアウトバウンドの address にドメイン名を指定すると、コアはプロキシ接続を確立する前に名前解決を行う必要があります。この時点ではプロキシトンネルがまだ使えないため、プロキシ経由でしか到達できないDNSリゾルバーに依存すると、起動時の循環依存が発生します。対処はノードを無作為に変更することではありません。プロキシ確立前から動作する基礎DNS経路を少なくとも1つ用意し、プロキシサーバーのドメイン名解決をその経路へ通してください。複雑なDNSアウトバウンドを構成する場合は、特にこの点を確認します。

DNSが根本原因かどうかは、4段階で範囲を絞れます。まず固定IPの宛先でアウトバウンド経路を確認し、次にノードのサーバードメインが解決できるか調べます。その後、対象ドメインのAレコードとAAAAレコードを確認し、最後に解決結果によってルーティング先が変わっていないか観察します。固定IPでも失敗するなら、原因は通常DNSだけではありません。ノードには接続できるのに一部のドメインだけ失敗する場合は、ドメインの一致、キャッシュ、アドレスファミリーの選択を調べます。

policy（ポリシー）：接続のライフサイクルと統計設定

システムポリシーとユーザーレベル

policy は接続のタイムアウト、ハンドシェイク時間、上下方向のアイドル判定、統計機能を制御します。通信をどのノードへ送るかは決めず、ルーティングルールの代わりにもなりません。設定は通常、levels と system に分かれます。levels はユーザーレベルごとに接続ポリシーを適用し、プロトコルのユーザーオブジェクトにある level と対応します。system は全体の統計項目を制御します。ユーザーにレベルが明示されていない場合は、通常デフォルトのレベルポリシーが適用されます。

レベルのキーはJSON内では "0" のような文字列で記述します。プロトコルによってユーザーレベルの参照方法が異なり、クライアントが自動生成する設定では未使用のポリシーが省略されることもあります。レベルを手動で追加する前に、対応するインバウンドまたはユーザーオブジェクトが実際に参照しているか確認してください。"1" のポリシーを作成しても、level: 1 を設定したユーザーがいなければ、すべての接続が自動的にそのレベルへ移行することはありません。

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5,
        "statsUserUplink": false,
        "statsUserDownlink": false,
        "bufferSize": 0
      }
    },
    "system": {
      "statsInboundUplink": true,
      "statsInboundDownlink": true,
      "statsOutboundUplink": true,
      "statsOutboundDownlink": true
    }
  },
  "stats": {}
}

handshakeとconnIdle

handshake は接続確立段階で待機できる時間を制限し、単位は通常秒です。値が小さすぎると、高遅延ネットワーク、初回DNS問い合わせ、複雑なハンドシェイクが完了する前に切断されます。大きすぎると、明らかに失敗した接続が長時間リソースを占有します。調整する前に、「接続確立が遅い」のか「確立後の転送が遅い」のかを分けて考えてください。ログにアウトバウンド確立済みと表示されている場合、ハンドシェイク時間を増やしても通常は改善しません。

connIdle はデータの動きがない接続をどれだけ維持するかを制御します。インスタントメッセージ、ロングポーリング、リモートターミナル、バックグラウンド同期では長時間目立った通信がないことがあり、短すぎるアイドル時間は周期的な切断を招きます。通常のWeb接続では、より短いアイドル回収でも問題ない場合があります。変更前に、問題が一定のアイドル時間後に必ず発生するか確認してください。通信中も切断されるなら、ポリシーだけでなくネットワーク経路、サーバー制限、トランスポート層を調べます。

uplinkOnly、downlinkOnly、バッファ

uplinkOnly と downlinkOnly は、片側を閉じた状態の接続を回収するために使います。一方向のデータが終了した後も、コアはもう一方向の残りの転送を待機できます。待機時間が短すぎるとレスポンス末尾が途切れ、長すぎると終了済み接続が長く残ります。通常は妥当なデフォルト値のままで問題ありません。ログやパケット取得の結果が片側終了の段階を明確に示す場合に限り、調整を検討してください。

bufferSize は接続ごとのバッファ戦略に影響し、その意味や単位はコアの実装によって変わる場合があります。バッファを大きくしても速度が上がるとは限らず、多数の同時接続ではメモリ使用量が増えます。性能調整の前に、ボトルネックがCPU、ネットワーク、プロトコルハンドシェイク、アプリの読み取り速度のどこにあるか確認してください。測定結果がない場合は、クライアントまたはコアのデフォルト設定を維持するほうが安定します。

統計データを有効にする方法

system の統計スイッチは、インバウンドとアウトバウンドの上り下りデータを記録するかどうかを決めます。通常はトップレベルに stats オブジェクトも必要です。ユーザー単位の統計を使う場合は、対応するレベルで statsUserUplink と statsUserDownlink も有効にします。stats: {} と書くだけで全項目が自動生成されるわけではありません。ポリシーのスイッチだけを開いても、統計データを読み取るAPIがなければ、クライアント画面にグラフが突然表示されることもありません。

統計機能を有効にすると、状態を管理するためのコストが増えます。必要性に応じて有効化してください。分岐を調べる場合は、アウトバウンド統計で通信がプロキシ、ダイレクト、ブロックのどこへ入ったかを確認できます。個別ユーザーを調べる場合に限り、ユーザー単位の統計が役立ちます。個人のデスクトップ設定では通常アウトバウンド単位だけで十分で、すべてのユーザー統計を有効にする必要はありません。GUIクライアントが通信量を表示する場合は、クライアントが生成する設定と読み取り方式を優先し、複数の統計経路を重複して設定しないでください。

ポリシー変更後の検証では、3種類の接続をテストします。短時間で終わる接続、継続的にデータを転送する接続、長時間アイドル状態になった後に復帰する接続です。Webページを1つ開くだけでは、アイドル回収が適切か、片側終了の待機が機能するかを判断できません。クライアントがノードを保存するたびに設定を再生成する場合、手動で変更したポリシーが上書きされることがあります。クライアントのカスタム設定機能に利用可能な項目を書き込むか、サブスクリプション更新後に生成結果を再確認してください。

ログ、統計、実行状態

ログレベルとファイル出力

log は設定のトラブルシューティングにおける最初の入口です。詳細度の高い順に、debug、info、warning、error、noneなどのレベルがありますが、具体的な名称は現在のコアに従ってください。通常運用ではwarningが重要な異常を残しつつ、重複情報を抑えやすい設定です。ルールやハンドシェイクを調べる場合は、一時的にinfoまたはdebugへ上げます。再現確認が終わったら通常のレベルへ戻し、大量のログによるディスク消費や検索の妨げを防いでください。

access と error には、アクセスログとエラーログの保存先を指定できます。相対パスを使う場合の基準ディレクトリはコアの起動場所に依存し、GUIクライアント、ターミナル、システムサービスで異なることがあります。設定上はファイルへ出力されているのに見つからない場合は、まずプロセスの作業ディレクトリとファイル権限を確認してください。保存先のディレクトリは事前に存在し、現在のユーザーが書き込めなければなりません。ログをインストールパッケージ内部や一時展開ディレクトリへ向けないでください。

{
  "log": {
    "access": "./logs/access.log",
    "error": "./logs/error.log",
    "loglevel": "warning",
    "dnsLog": false
  },
  "stats": {}
}

接続ログを読む方法

ログを読むときは、時刻を追いながら同じ接続の段階をつなげて考えます。インバウンドが接続を受け付け、宛先を識別し、ルーティングに一致し、アウトバウンドを選び、サーバーアドレスを解決し、トランスポートを確立し、プロトコルハンドシェイクを行い、終了理由が記録されます。「connection closed」だけを見ても、ノードの障害、宛先による切断、ルーティングによるブロックのどれかは判断できません。同じ時刻付近の宛先アドレス、インバウンドタグ、アウトバウンドタグを照合し、どの層で切断されたかを確認してください。

ログにインバウンドの記録しかなく、アウトバウンドの選択がない場合は、まずルーティングルールと設定の読み込みを確認します。アウトバウンドは選ばれているのにサーバーアドレスの解決に失敗するならDNSを調べます。リモートTCPは確立しているのにプロトコルハンドシェイクに失敗する場合は、ユーザー、トランスポート、安全パラメータを確認します。ハンドシェイク成功後に特定の宛先だけ失敗する場合は、宛先ルーティング、アドレスファミリー、アプリの挙動を調べます。段階ごとに切り分けることで、複数モジュールを行き来する試行錯誤を避けられます。

アクセスログとエラーログの役割分担

アクセスログは「どの宛先がどの入口から処理されたか」を確認するのに適し、エラーログは「なぜ処理が中断したか」を調べるのに適しています。ルーティングを検証する場合は、識別しやすいテスト用ドメインを1つ選び、古いログを消去してからリクエストを1回だけ送信し、新しい記録を確認します。多数のWebページを同時に開くと、バックグラウンド通信、更新確認、メディア接続が発生し、対象が混在してルールの一致を判断しにくくなります。

ログに表示されるドメイン名とIPアドレスは、異なる段階の情報である可能性があります。スニッフィングで識別されたドメイン名はルール照合に使われ、DNSが返したIPアドレスは接続確立に使われます。最終的なアクセスログにどちらが表示されるかは、コアとログの位置によって変わります。IPが表示されたからといってドメインルールが実行されていないとは限らず、ドメイン名が表示されたからといって解決が行われていないとも限りません。domainStrategy、スニッフィング設定、ルーティングログを組み合わせて判断してください。

統計、API、クライアントGUI

統計モジュールはカウンターを記録し、APIまたはクライアントGUIが読み取って表示します。コアAPIを使う場合は通常、専用インバウンド、サービス用タグ、API通信を対応するアウトバウンドへ送るルーティングルールも必要です。この構造はコアによる違いとクライアントの管理範囲が大きいため、手動で追加する前に、クライアントが同名のタグをすでに作成していないか確認してください。APIインバウンドのポートが重複すると起動に失敗し、ルーティングタグが重複すると、状態照会が通常のプロキシ出口へ送られる可能性があります。

v2rayNなどのGUIクライアントには通常、実行ログ、コアログ、接続状態を確認する入口があります。トラブルシューティングでは、クライアントが実際に起動した設定とエラー情報を優先してください。GUIの設定は起動前にフィールドへ変換される場合があるためです。手動で編集したJSONとは別の一時設定をクライアントが読み込んでいるケースは、よくある情報の食い違いです。設定元を確認するには、起動ログに記録された設定ファイルのパス、リッスンポート、アウトバウンドタグを確認し、編集中のファイルと一つずつ照合します。

ログのプライバシーと保存期間

アクセスログには、ドメイン、宛先アドレス、ローカルアカウント識別子、接続時刻が含まれることがあります。詳細ログを有効にする前に、保存場所と利用範囲を確認してください。トラブルシューティングが終わったらレベルを下げ、不要になったデバッグファイルを削除します。エラーの断片を共有する際は、障害に直接関係する段階だけを残し、ノードアドレス、ユーザー識別子、パス、アカウントフィールドを置き換えてください。サーバーアドレスを1行削除するだけでは不十分です。周辺のハンドシェイク情報から設定の詳細が漏れることもあります。

ログ分析の目的は、再現可能な因果関係を組み立てることであり、情報をできるだけ多く集めることではありません。一度に1つの問題だけを再現し、変更前後の差分、明確な時刻、テスト対象を記録します。ノード交換、DNS変更、ルーティング調整、システムプロキシ切り替えを同時に行うと、問題が解消しても、どの変更が有効だったか分かりません。安定したトラブルシューティング記録には、使用中のクライアント、コアの系統、インバウンド方式、命中したアウトバウンド、最終的なエラー段階を含めてください。

設定の検証、移行、トラブルシューティング

3層のチェックを先に通す

設定の検証は3層に分けます。第1層はJSON構文で、括弧、カンマ、クォート、フィールドの型が正しくなければなりません。第2層は設定の意味で、現在のコアがプロトコルフィールドを認識するか、タグの参照先が存在するか、ポートが競合していないかを確認します。第3層は実行経路で、インバウンドが通信を受け、ルーティングが一致し、アウトバウンドが確立し、宛先が応答するかを見ます。3層は互いに代替できません。JSONを解析できても、テキスト構造が正しいことしか分からず、ノードパラメータやルーティング結果の正しさまでは保証されません。

一部のコアには、サービスを長時間稼働させずに設定を読み込み、エラーを返すテストモードがあります。コマンド形式はコアやパッケージ方法によって異なるため、クライアントに付属するコアのヘルプを確認してください。デスクトップクライアントでは、GUIの検査、コアの再起動、起動ログの確認機能を先に使うほうが安全です。テスト時は、クライアントが実際に使用しているコアファイルを呼び出しているか確認してください。システムパスにある別のコアは、異なるフィールドにしか対応していない可能性があります。

v2ray run -test -config ./config.json
xray run -test -config ./config.json

コマンドで引数形式がサポートされていないと表示された場合は、まず対象プログラムのヘルプコマンドを実行し、ローカルの構文を確認してください。それだけで設定内容が誤っていると判断してはいけません。検証に成功したらコアを起動し、ログに想定したリッスンポートが現れるか確認します。ポートが現れない場合は、実行設定、権限、ポート競合に問題が残っています。ポートは現れるのにアプリの通信が入ってこない場合は、システムプロキシまたはアプリのプロキシ設定に戻って確認します。

モジュール単位で二分して調べる

複雑な設定に対して最も早い方法は、全フィールドを逐一読むことではなく、動作する最小経路まで縮小することです。ローカルSOCKSインバウンド、パラメータが完全で既知のプロキシアウトバウンド、ダイレクトアウトバウンド、空のルーティングルールだけを残します。まずプロキシ出口が接続できることを確認し、次にプライベートアドレスのダイレクト接続、ドメイン分類、DNS分岐、ブロックルールを順に追加します。追加するたびに、戻せる設定のコピーを残してください。どこかで障害が起きれば、直前に追加したモジュールに範囲を限定できます。

ノードが接続成功と表示されるのにWebページが開かない場合は、「アプリによる取り込み、インバウンドのリッスン、ノード接続、DNS、ルーティング、システムプロキシ」の順に確認します。クライアントの状態表示は、プロセスが起動したことや、あるテストが完了したことを示すだけで、現在のブラウザ通信が実際にインバウンドへ入っているとは限りません。最も直接的な確認方法は、アクセスログにテスト対象が現れるかを見ることです。記録がなければ入口を先に直し、記録があればアウトバウンドを分析します。

サブスクリプション更新後の設定変更

サブスクリプションを更新するとノード一覧と一部のノードパラメータが更新され、クライアントが現在のルーティングモードに応じて実行設定を再生成することもあります。一時ファイルへの手動変更は長く保持できない場合があります。永続化したいルーティングルールは、クライアントが提供するカスタムルール、プリセット設定、対応テンプレートの場所に記述してください。更新後は、ノードのプロトコル、トランスポート方式、サーバー名、アウトバウンドタグ、ルール順序を重点的に確認します。特に異なるコア系統からノードをインポートする場合は注意が必要です。

単一の vmess:// または vless:// 共有リンクは通常1つのノードを表し、サブスクリプションURLは更新可能なノード一覧を返します。クライアントでのインポート入口と更新動作は両者で異なります。詳しい違いは共有リンクとサブスクリプションURLの使い方を参照してください。更新後にノードが表示されない、またはエラーが返る場合は、サブスクリプション更新失敗のトラブルシューティングと自動更新設定も確認できます。

コア間移行のチェックリスト

V2Flyの設定からXrayへ、またはその逆へ移行する場合は、まず両方が対応する基本構造を残します。SOCKSインバウンド、通常のダイレクト出口、シンプルなドメインとIPのルーティングが対象です。その後、プロトコルごとにユーザーフィールド、トランスポート層、安全層、フロー制御を確認します。未知のフィールドがあっても、安全設定全体を削除して接続を続けてはいけません。そのフィールドがノードの動作に必要な可能性があるためです。正しい方法は、移行先のコアが同じプロトコル機能を表現できるか確認することです。表現できない場合は、そのノードに合ったクライアントとコアを選択してください。

REALITYノードは通常、対応機能を持つXrayコア系統で使用します。Androidではv2rayNGを優先的に検討できます。V2Flyの設定やノードを使う場合は、要件に応じてv2flyNGを選択してください。デスクトップではv2rayNを第一候補とし、コア設定で実際に有効なコアを確認します。エコシステムとコアの関係は、Project V、V2Fly、Xray、クライアントの関係とXrayとV2Flyのコア選択ガイドで詳しく確認できます。

保守しやすい設定の基準を作る

長期的に保守しやすい設定には、明確なタグ、限定されたルール階層、説明可能なDNS経路、適度なログが必要です。変更のたびにフィールドの値だけでなく目的を記録してください。たとえば「LANのサブネットをダイレクト接続にする」と記録するほうが、「geoip項目を追加」と書くより、後から必要性を判断しやすくなります。ルールはブロック、特別なダイレクト、特別なプロキシ、フォールバックという論理で分類し、各グループ内では具体的なものから広いものへ並べます。

変更が終わったら、少なくともローカルアドレス、通常のドメイン、直接IP、TCPリクエスト、UDPが必要なアプリのケースを検証します。その後クライアントを一度再起動し、設定が現在のプロセス内だけで一時的に有効になっていないことを確認してください。サブスクリプションを利用している場合は、更新も1回実行し、カスタムルールが保持されているか確認します。すぐに使う手順はv2rayNとv2rayNGの設定チュートリアルに戻り、インストーラーを選び直す場合はV2Rayクライアントダウンロードページへ進んでください。