V2Ray設定ファイル完全ガイド

01 / ROOT OBJECT

JSON構造の概要とデータフローの境界

トップレベルのオブジェクトは実行手順の一覧ではありません

V2Ray設定ファイルのルートノードはJSONオブジェクトです。一般的なトップレベル項目にはlog、dns、inbounds、outbounds、routing、policy、statsがあります。ファイル内での記述順は、通常、実行順を決めません。routingをinboundsより前に書いても、ルーティングが先に起動するわけではありません。実際の動作関係はモジュールの役割とタグ参照によって決まるため、設定は読みやすい順に整理できますが、見た目の順序を制御フローと考えないでください。

inboundsとoutboundsが配列なのは、1つのコアインスタンスで複数の入口を同時に待ち受け、複数の出口を用意できるためです。配列内の各オブジェクトには通常、tagで安定した名前を付けます。ルーティングルールはinboundTagで送信元を限定し、outboundTagで接続先の出口を指定します。タグは設定内部で参照するキーであり、プロトコル名ではありません。出口タグはproxy、direct、または役割が分かる名前にできますが、参照が完全に一致し、保守しやすいことが条件です。

JSON構文とクライアントが生成する設定

標準JSONでは、プロパティ名と文字列を二重引用符で囲み、末尾のカンマは使用できません。標準のコメントもサポートされません。真偽値はtrueまたはfalseと記述し、ポートなどの数値を引用符付きの文字列にしないでください。日本語、パス、ドメインはUTF-8ファイルにそのまま記述できますが、Windowsパスのバックスラッシュはエスケープが必要です。手動編集後に「設定を解析できない」といったエラーが出たら、まず構文、次にプロトコル項目を確認します。構文解析に失敗している段階では、コアはまだネットワーク接続を開始していません。

v2rayN、v2rayNG、v2flyNGは、画面の設定に応じてコア設定を生成または組み合わせます。デスクトップではv2rayNが扱いやすく、ルーティング、システムプロキシ、コアログを確認できます。Android版のv2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。クライアントが生成した一時設定は、再起動、ノード切り替え、サブスクリプション更新後に上書きされることがあります。長期的に使うルールは、クライアントが提供するカスタム設定、ルーティング設定、または対応テンプレートから管理し、実行ディレクトリ内の一時ファイルを直接編集するのは避けてください。

{
  "log": {
    "loglevel": "warning"
  },
  "dns": {
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ]
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": []
  }
}

最小構成に必要なのは、通信を受け付けるインバウンドと接続を確立できるアウトバウンドだけです。ただし実際のクライアントでは、ローカルAPI、統計、DNS、複数のルーティングが追加されます。大きな設定を読むときは、対象の問題と無関係なモジュールをいったん隠すとよいでしょう。接続自体が起動しないならJSON、インバウンド、アウトバウンドを確認し、一部のドメインだけ出口を誤るならルーティング、ドメインだけ失敗してIPは使えるならDNSを優先します。障害の範囲を絞るほうが、行単位で手当たりなく変更するより確実です。

02 / INBOUND

inbounds インバウンドの待ち受け、プロトコル、通信識別

listen、port、protocol、tag

インバウンドは、どのローカル接続またはネットワーク接続をコアへ取り込むかを決めます。一般的なローカル入口はSOCKSとHTTPプロキシです。ブラウザ、ターミナル、システムプロキシが指定の待ち受けアドレスへリクエストを送り、コアがその後のルーティングを処理します。listenを127.0.0.1にすると本機からの接続だけを受け付けるため、単体利用に適しています。すべてのインターフェースで待ち受ける設定はアクセス範囲を広げるため、LAN機器から接続する明確な理由がない限り、安易に公開しないでください。portは他のプログラムに使用されていない必要があり、同じアドレスとポートの組み合わせを2つのインバウンドで重複して割り当てることはできません。

protocolは入口のプロトコルを指定し、settingsの構造はプロトコルによって変わります。SOCKSインバウンドではudpでUDP転送を制御することが多く、HTTPインバウンドでは通常のHTTPプロキシとCONNECTリクエストを受け取ります。tagはルーティングで送信元を識別するために使います。たとえばブラウザ専用の入口にbrowser-inというタグを付ければ、専用ルールを適用できます。タグはポートの代わりにはなりません。アプリは正しい待ち受けポートへ接続して初めて、ルーティングモジュールがタグを読み取れます。

{
  "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": "http-in",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

sniffingの用途と範囲

アプリがプロキシへ宛先IPだけを渡し、ルーティングルールでドメイン判定が必要な場合、sniffingはHTTPリクエストやTLSハンドシェイクから宛先ドメインを識別できます。destOverrideは、どの種類の通信を識別対象にするかを指定します。有効にするとルーティングモジュールがより完全なドメイン情報を取得でき、ドメイン別の振り分けが安定しやすくなります。ただし、スニッフィングはDNSの代替ではなく、あらゆる暗号化通信から任意の内容を復元するものでもありません。接続確立時に見える宛先情報だけを利用します。

スニッフィングの問題を調べるときは、「アプリが送信した元の宛先」と「ルーティングが実際に使った宛先」を分けて確認します。スニッフィングを無効にするとルールが正常に戻る場合、識別されたドメインが、より前にある別のルールに一致している可能性があります。有効にしてもドメインルールが適用されない場合は、通信が本当に想定したインバウンドを通っているか確認してください。システム内の別のプロキシポートで受け取られている可能性もあります。透過プロキシ、仮想NIC、通常のSOCKS入口では通信の流入元が異なり、クライアント画面でモードを切り替えると、生成されるインバウンドも変わります。

インバウンドの障害は、アプリがローカルプロキシへ接続できない、ポートのバインドに失敗する、UDPリクエストだけが機能しないといった形で現れます。まずクライアントログで待ち受けが成功しているか確認し、次にシステムプロキシのアドレスとポートを確認してください。ブラウザは使えるのに特定のアプリだけ使えない場合は、そのアプリが選択したプロキシ種別に対応しているか、システムプロキシを迂回していないか、UDPが必要ではないかを確認します。ローカル入口に到達できると確認する前に、遠隔ノードを何度も入れ替えないでください。通信がそもそもコアへ入っていない可能性があります。

03 / OUTBOUND

outbounds アウトバウンドのプロトコルオブジェクトと出口選択

リモート出口、ダイレクト接続、ブロック出口

アウトバウンドは、ルーティングで選ばれた接続を最終的な宛先またはリモートサービスへ送ります。一般的な構成には、リモートプロキシ出口とダイレクト接続出口を少なくとも1つずつ含め、必要に応じてブロック出口を追加します。リモート出口のprotocolには、クライアントとサーバーが共に対応するVMess、VLESS、Trojanなどを指定できます。settingsにはサーバーアドレス、ポート、認証情報を保存し、streamSettingsでは下位トランスポート、セキュリティ層、関連パラメータを定義します。各項目はサーバー側の設定と対応していなければなりません。プロトコル名が正しくても、トランスポート設定をそのまま互換利用できるとは限りません。

freedomは現在の端末から宛先へ直接アクセスする方式で、タグにはdirectを設定することが一般的です。blackholeはルールで選ばれた接続を意図的に終了させるために使い、タグにはblockを設定することが多いです。どちらも標準的なアウトバウンドなので、ルーティングルールではoutboundTagを変えるだけでよく、特殊なアクション構文は必要ありません。ルールが存在しないタグを参照すると、設定の読み込みに失敗したり、実行時に出口を見つけられなかったりします。タグを変更したら、すべての参照箇所も必ず更新してください。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-2222-3333-4444-555555555555",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "server.example.com"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "response": {
          "type": "none"
        }
      }
    }
  ]
}

streamSettingsは全体を確認する

streamSettings.networkはTCP、WebSocket、gRPCなどの下位トランスポートを定義し、securityはTLS、REALITYなどのセキュリティ層を指定します。トランスポート固有の設定は対応する子オブジェクトに置かれます。たとえばWebSocketではパスやリクエストヘッダー、TLSではサービス名などを設定します。トラブル対処では、リモートアウトバウンドを3層に分けて確認してください。まずサーバーアドレスとポートに到達できるか、次にユーザー認証とプロトコルが一致しているか、最後にトランスポートとセキュリティ層の詳細が一致しているかを確認します。「接続が切断された」という表示だけでは、どの層が原因か判断できません。

サーバーアドレスにドメインを使う場合、コアは先に名前解決を完了する必要があるため、アウトバウンドの失敗がDNSに起因することもあります。ログに解決済みのアドレスが表示されてからハンドシェイクに失敗するなら、プロトコル、時刻、サービス名、トランスポート設定を確認します。解決結果すら得られないなら、dns設定とシステムネットワークを先に確認してください。IPアドレスで直接テストすると、名前解決と接続の問題を切り分けられます。ただしTLSでは正しいサービス名が必要なことが多く、IPでのテスト結果をそのまま最終設定と見なしてはいけません。

muxなどの接続多重化設定は、基本接続が安定してから調整してください。多重化がすべてのネットワークやプロトコルで高速化につながるとは限らず、早い段階で最適化項目を加えると変数が増えます。設定を組むときは、リモート出口1つ、ダイレクト出口1つ、最小限のトランスポート項目から始め、成功後にルーティング、多重化、追加の出口を段階的に追加します。変更のたびに記録を残せば、問題発生時にすぐ切り戻せます。

クライアントでサブスクリプションをインポートすると、リモートアウトバウンドが自動生成されます。手動で上書きする前に更新の仕組みを理解してください。サブスクリプション更新でノードのパラメータが置き換わっても、ローカルルーティングは通常クライアント側で個別に管理されます。クライアントを再取得する場合はクライアントを入手し、共有リンクとサブスクリプションURLの違いは共有リンクとサブスクリプションのインポートで確認できます。

04 / ROUTING

routing ルーティングの判定順序と振り分けルール

ルールは順番に適用され、自動的には統合されません

ルーティングモジュールは接続属性を読み取り、アウトバウンドを選択します。rulesは順序を持つ配列で、通常は上から順に確認し、実行可能なルールに一致すると、そのルールが指定した出口を使用します。そのため、より具体的で優先処理したいルールを前に置き、範囲の広いフォールバックルールを後ろに置きます。条件が一部重なる2つのルールでも、「より具体的な方を優先する」と自動計算されることはありません。実際の優先順位は配列内の位置で決まります。

よく使う条件にはdomain、ip、port、network、inboundTag、protocolがあります。同じルールに異なる種類の条件を複数入れると、通常は各種類の条件をすべて満たす必要があります。同じ種類の配列に複数の値を入れた場合は、そのうち1つに一致すればよいという意味です。たとえばドメインとポートを同時に指定したルールは、ドメイン条件とポート範囲の両方に合う接続だけを処理します。関係のない条件を1つのルールに詰め込むと、項目は揃っているように見えても、まったく適用されないことがあります。

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

ドメイン、IP、domainStrategy

ドメイン条件には複数のマッチ形式があります。full:は完全なドメイン一致で、固定ホスト名に適しています。domain:は指定ドメインとサブドメインを対象にできます。regexp:は正規表現による一致を提供しますが、複雑な式は可読性を下げるため、通常の形式で表現できない場合に限って使うのが安全です。geosite:はコアのデータファイルにあるドメイン集合を参照しますが、利用できるかどうかはクライアントにデータが含まれているかに左右されます。名前を書いただけで環境に集合が存在するとは限らないため、読み込みエラーやルール無効時はログを確認してください。

IP条件では、単一アドレス、CIDRネットワーク、geoip:集合を指定できます。プライベートアドレスは通常ダイレクト接続を優先し、LANサービスがリモート出口へ送られないようにします。ドメイン条件で先にIP解決を行うかどうかはdomainStrategyに左右されます。AsIsは主に元のドメインで一致させます。IPIfNonMatchはドメインルールに一致しない場合に解決を試み、IPルールの確認を続けます。IPOnDemandはIPルールが必要になった時点で、より積極的に解決を行います。積極的な解決はDNSクエリを増やしたり振り分け結果を変えたりするため、名前だけで「高機能」と判断しないでください。

ルーティングを検証するときは、サイトが開くかどうかだけで判断しないでください。複数の出口で接続に成功する可能性があるためです。対象ドメインを一時的に、位置が前でタグが明確なルールへ追加し、ログでどの出口が選ばれたか確認します。ルールが適用されない場合は、想定したインバウンドを通っているか、スニッフィングでドメインを取得できているか、マッチング接頭辞が正しいか、前のルールに先取りされていないか、出口タグが存在するかを順に確認してください。DNSの振り分けと汚染回避については、V2Ray DNS振り分け・名前解決ガイドで詳しく解説しています。

05 / DNS

DNS設定のサーバー選択、hosts、名前解決経路

内蔵DNSは、その経路に入ったクエリだけを処理します

dnsモジュールは、コアがドメインを解決する方法を定義します。ただしDNSサーバーを設定したからといって、システム上のすべてのクエリが自動的にコア経由になるわけではありません。アプリが独自に解決する場合もあれば、OSが先に解決してIPだけをプロキシへ渡す場合もあります。内蔵DNSへ入るかどうかは、クライアントモード、インバウンドの種類、ルーティングポリシー、アプリの動作によって決まります。DNSの問題が起きたら、まずサーバーアドレスを何度も入れ替えるのではなく、どの層でクエリが発生しているか確認してください。

serversには単純なアドレスだけでなく、マッチング対象のドメインを指定したサーバーオブジェクトも設定できます。単純な形式では、一覧に並べた汎用の名前解決先を使います。オブジェクト形式では、domainsで特定のドメイン群を指定し、そのドメインを優先して特定サーバーへ渡せます。さらにexpectIPsで期待するアドレス範囲を制限できます。hostsは静的な対応付けやエイリアスに使え、固定結果の分かっている名前、内部サービスのマッピング、テストルールに便利です。ただし、頻繁に変化する公開ドメインを大量に管理する用途には向きません。

{
  "dns": {
    "hosts": {
      "domain:internal.example": "192.168.10.20",
      "dns-alias.example": "target.example"
    },
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ]
      },
      {
        "address": "1.1.1.1",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

クエリ戦略とDNSアウトバウンド

queryStrategyは、IPv4とIPv6の両方を許可するか、どちらか一方だけを要求するかなど、アドレスファミリーの優先傾向を制御します。選択前に、現在のネットワーク、リモート出口、対象サービスが実際にそのアドレスファミリーで通信できるか確認してください。IPv6経路が安定していないのにIPv6の結果を優先すると、名前解決は成功しても接続がタイムアウトすることがあります。これはDNSサーバーの障害ではなく、解決結果と実際の出口性能が合っていない状態です。

高度な設定ではdnsプロトコルのアウトバウンドを追加し、ルーティングによってコアが開始するDNS通信を指定の出口へ送れます。この場合は3つの対象を同時に確認します。dns.serversは問い合わせ先を決め、DNSアウトバウンドは問い合わせの送信方法を決め、routing.rulesはその通信に使う出口を決めます。1つだけ変更すると、問い合わせループや想定と逆の経路が生じることがあります。特に、リモートサーバーのドメインを解決するDNSリクエストを、まだ確立していない同じリモート接続に依存させないでください。

{
  "outbounds": [
    {
      "tag": "dns-out",
      "protocol": "dns"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "protocol": [
          "dns"
        ],
        "outboundTag": "dns-out"
      }
    ]
  }
}

DNSのトラブル対処は決まった順序で行うと効率的です。まずシステムツールで端末自体がネットワークに接続できるか確認します。次にコアログで、クエリを開始したか、どのサーバーへ渡したか、どの種類のアドレスが返ったかを確認し、最後に選択した出口からそのアドレスへ到達できるか確認します。ドメインへのアクセスに失敗してもテストIPへはTCP接続できる場合、名前解決とTLSのサービス名を確認します。解決結果はあるのにすべてのアドレスがタイムアウトする場合は、ルーティングと出口を確認してください。キャッシュ削除で古い結果は消せますが、誤ったルールチェーンは直せません。

振り分け設定は説明しやすい構造に保ちます。ローカルドメイン、ローカルアドレス、明確な内部サービスはローカルの名前解決へ渡し、それ以外を必要に応じてリモート解決へ振り分ける方法が、多数の例外を積み重ねるより安定した出発点です。変更のたびに1つの変数だけを変え、変更前後のクエリログを記録してください。項目の詳しい分解とDNSリーク対策は、前述のDNS設定詳解と合わせて確認できます。

06 / POLICY

policy ポリシーの接続時間、統計、リソース制約

levelとポリシーオブジェクトの対応関係

policyはユーザー単位およびシステム単位の実行ポリシーを設定します。ユーザー単位のポリシーはlevelsに置き、キーにはレベル番号を文字列で指定します。プロトコルのユーザーオブジェクトにあるlevelが、使用するポリシーグループを決めます。これはネットワーク品質の評価でも権限の高さでもなく、接続パラメータの組を特定ユーザーへ割り当てる仕組みです。単一ユーザーのクライアントでは多くの場合レベル0で十分で、複数の接続動作を分ける必要がある場合だけレベルを追加します。

ユーザー単位でよく使う項目には、ハンドシェイクのタイムアウト、接続アイドル時間、上りまたは下りだけになった場合の保持時間、ユーザーの上り下り統計を有効にするかどうかなどがあります。時間項目の単位や適用範囲は、コアのドキュメントとログを確認してください。すべての数値をミリ秒と考えてはいけません。短すぎる値は長時間接続、バックグラウンド同期、低頻度リクエストを早期切断し、長すぎる値は活動を失った接続がリソースを占有する原因になります。最適化の前に実際の障害を観察し、ポリシーオブジェクトを汎用的な高速化スイッチとして扱わないでください。

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

policy、stats、APIの関係

ポリシーの統計スイッチを有効にしても、対応するデータの収集を許可するだけです。通常はトップレベルにstatsオブジェクトも必要です。クライアント画面で統計情報を読む場合、ローカルAPIインバウンドと関連ルーティングが生成されることもあります。3つの役割は異なります。policyは収集する項目を決め、statsは統計モジュールを起動し、APIは読み取り口を提供します。一部だけをコピーすると、画面にデータが表示されないことがあります。

統計収集には一定の処理負荷がかかり、必要性はクライアントの機能によって異なります。接続できるかだけを確認するなら、累積統計よりログのほうが直接的です。インバウンドとアウトバウンドの通信量を長期的に観察したい場合は、必要な項目だけ有効にしてください。「設定を完全にする」ためにすべてのスイッチをオンにしたり、短時間の統計値だけでプロトコルの優劣を判断したりしないでください。アプリのキャッシュ、同時接続、システム更新、バックグラウンドタスクも結果に影響します。

ポリシーのトラブル対処はデフォルト値から始めます。一定のアイドル時間後に特定の接続が切れるならconnIdleを確認します。リモートネットワークが一時的に遅い場合だけ失敗するなら、ハンドシェイク時間を短くしすぎていないか確認してください。接続は正常なのに統計だけ欠ける場合は、アウトバウンドプロトコルではなく、統計スイッチ、トップレベルモジュール、クライアントAPIを確認します。接続の動作と観測の仕組みを分けることで、画面の統計表示を直すために正常な通信経路を壊す事態を避けられます。

クライアントはグラフィカルインターフェースに基づいて、ポリシーや統計項目を自動管理することがあります。手動設定とクライアント設定を併用する場合は、カスタム断片だけでなく最終的に生成されたファイルを確認してください。v2rayNはデスクトップ環境で生成結果とログを確認しやすく、v2rayNGやv2flyNGのモバイル設定は通常アプリが管理します。手動項目は対応するインポート機能から追加してください。コアによって拡張項目の対応範囲が異なるため、設定を移行するときは基本項目から少しずつ追加します。

07 / LOGGING

ログと可観測性：エラーが発生した段階からモジュールを特定

loglevelが情報量を決める

logは設定トラブル対処の最初の入口です。一般的なloglevelには、詳細なものから簡潔なものまで、debug、info、warning、error、noneなどがあります。通常の運用ではwarningを維持し、複雑なルーティングやDNSの問題を再現するときだけinfoまたはdebugへ一時的に上げ、記録後に戻してください。詳細なログには対象ドメイン、アドレス、タグ、接続過程が含まれる場合があるため、整理していない完全なファイルをそのまま公開しないでください。

accessとerrorでは、アクセスログとエラーログの出力先を指定できます。ファイルパスを省略すると、クライアントは通常、標準出力または独自のログ画面から内容を収集します。相対パスはプロセスの作業ディレクトリを基準とし、設定ファイルのある場所とは限りません。権限制限のあるディレクトリでは書き込みに失敗することもあります。GUIクライアントにログ画面がある場合は、クライアント管理の出力方法を優先し、カスタムパスと更新、権限、ポータブルディレクトリの競合を避けてください。

{
  "log": {
    "access": "",
    "error": "",
    "loglevel": "warning",
    "dnsLog": false
  }
}

errorだけを検索せず、段階ごとにログを読む

1つの接続は、おおむね設定の読み込み、インバウンドでの受信、宛先の識別、DNS解決、ルーティング選択、アウトバウンドの接続開始、プロトコルとセキュリティ層のハンドシェイク、データ転送という段階を経ます。ログの最後の行は表面的な結果にすぎず、実際の原因は数行前にあることがよくあります。たとえば「接続が閉じられた」はリモート側の切断、ハンドシェイクパラメータの不一致、上流のタイムアウトが原因かもしれません。「出口が見つからない」はタグ参照の問題に近く、「アドレスがすでに使用中」はインバウンドの待ち受け段階で起きるため、ノードのパラメータとは関係ありません。

トラブル対処では、まず再現時刻と対象を記録し、古いログを消すか、その時刻付近から読み始めます。何度も試すと記録が混在し、複数のアプリを同時に使うと、どの行がテスト対象の接続か判断しにくくなります。不要なプログラムを終了し、ブラウザから1つだけリクエストを送って、インバウンドからアウトバウンドまでの経路を観察してください。ルーティングではインバウンドタグ、ドメインまたはIP条件、最終的なアウトバウンドタグを確認します。DNSでは問い合わせ先、返されたアドレス、その後の接続を確認します。ハンドシェイクではサービス名、トランスポート、セキュリティ層、システム時刻を確認します。

クライアントが起動直後に終了する場合は、実行環境、ディレクトリ権限、コアファイル、ポートの使用状況を先に確認してください。Windowsデスクトップではランタイムや保護されたディレクトリへの書き込み制限、Androidクライアントではシステムによるバックグラウンド実行制限の影響も考えられます。対処手順はv2rayNの起動クラッシュとv2rayNGの突然終了への対処で確認できます。この種の問題は設定経路の外側または読み込み初期に発生するため、すぐにリモートプロトコルのせいだと判断しないでください。

ログの比較は、1回のスクリーンショットより価値があります。動作する設定の起動・接続記録を保存し、変更後の記録と比較してください。待ち受けが減っていないか、DNSの返答が変わっていないか、同じドメインで選ばれるアウトバウンドが変わっていないか、ハンドシェイクの失敗が解決前と解決後のどちらで起きているかを確認します。段階ごとの差分を比べると、範囲をすばやく絞れます。診断が終わったら、一時的なdebug設定とテストルールを削除し、大量のログが蓄積したり高優先度のテストルールが日常の振り分けに残ったりしないようにしてください。

08 / VALIDATION

設定検証とトラブル対処の固定手順

まず構文、次に参照、その後にネットワーク

安定した検証は段階的に行います。第1段階ではJSON構文を確認します。括弧が対応しているか、カンマが正しいか、文字列が閉じているか、数値と真偽値の型が正しいかを確認してください。第2段階では内部参照を確認します。すべてのoutboundTag、inboundTag、ポリシーレベルに対応するオブジェクトが存在し、タグの大文字・小文字が一致しているかを確認します。第3段階で初めて、待ち受けポート、DNS、サーバーアドレス、プロトコル認証、トランスポート、セキュリティ層を確認します。前の2段階を飛ばしてノードを交換すると、単純なミスがネットワーク現象に隠れてしまいます。

コアには設定テストや指定した設定で起動する機能が用意されていることがありますが、クライアントのラッピング方法やコアのコマンド引数はそれぞれ異なります。GUIクライアントでは、クライアントの設定チェックとログ画面を優先して確認し、実行ディレクトリを理解しないままコマンドを直接実行するのは避けてください。独立したコア環境を使う場合は、現在の実行ファイルのヘルプを確認してから、対応する引数で設定を読み込みます。検証に成功しても、構造と項目が受け入れられたことを示すだけで、リモートサービスへ到達できるとは限りません。

{
  "log": {
    "loglevel": "info"
  },
  "inbounds": [
    {
      "tag": "test-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": [
          "test-in"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

最小構成で障害範囲を切り分ける

上記の最小構成では、ローカルSOCKSインバウンド、ルーティングタグ、ダイレクト接続アウトバウンドだけを検証します。起動できなければ、問題は構文、ポート、端末の実行環境に絞られます。起動して対象へアクセスできたら、実際のリモートアウトバウンドに置き換え、障害がリモートプロトコル層に入ったか判断できます。その後、DNS、ドメインルール、IPルール、ブロックルール、統計、ポリシーを順に戻します。毎回1組の項目だけを復元すれば、障害が見つかった時点で追加したモジュールに範囲を絞れます。

よくあるエラーは症状で分類できます。起動直後に失敗する場合は、JSON、未知の項目、タグ参照、ポート競合、ファイル権限が主な原因です。ローカルプロキシへ接続できない場合は、待ち受けアドレス、ポート、アプリのプロキシ種別の不一致を確認します。すべてのドメインに失敗する一方で一部のIPへ到達できる場合は、DNS経路の問題が考えられます。特定のドメインだけ出口を誤る場合は、ルール順序、スニッフィング、マッチング接頭辞を確認します。接続確立後すぐに切断される場合は、ポリシーの時間制限、リモートハンドシェイク、ネットワークの安定性を調べます。分類は最終結論ではありませんが、最初に読むべきログの範囲を決める助けになります。

クライアント環境では設定の上書きも考慮する必要があります。v2rayNでノードを切り替えたり、サブスクリプションを更新したり、ルーティングモードを変更したりすると、実行設定が再生成されることがあります。v2rayNGとv2flyNGも、アプリの設定に応じてコアのパラメータを構築します。一時ファイルを手動で変更して一時的に動作しても、再起動後に戻るなら、コアが設定を無視しているのではなく、クライアントがファイルを再生成している可能性が高いです。長期的な設定は、クライアントが対応するカスタムルーティング、テンプレート、インポート機能に保存してください。

最終確認では、1つのWebページが開くかだけを見ないでください。少なくともローカルアドレスへの直接接続、通常のドメイン解決、想定したプロキシドメイン、UDPの要件、クライアント再起動、サブスクリプション更新後の動作を確認し、ログで設計どおりの出口タグが選ばれているか確認します。クライアントを初めて使う場合は、まず使用ガイドで基本経路を完成させてから、このページに戻ってルールを追加してください。インストールパッケージを選び直す場合は、クライアントを入手し、Windows、macOS、Android、Linux向けにダウンロードします。複雑な設定の信頼性は、項目数ではなく、明確な境界、段階的な検証、切り戻せる記録によって決まります。