V2Ray 設定ファイルの構造とパラメータ解説

02 / INBOUNDS

inbounds 入力設定

待ち受けアドレスが接続可能な範囲を決める

入力は、端末上のアプリケーションがコアへ通信を渡す入口です。ローカル入口として最も一般的なのはSOCKSとHTTPプロキシです。listenは待ち受けるネットワークアドレス、portはポート、protocolはアプリケーションが使うプロキシプロトコルを指定します。端末内だけで使う場合、待ち受けアドレスは127.0.0.1を推奨します。このアドレスはローカル接続だけを受け付けるため、ブラウザ、システムプロキシ、同じ端末上の他のプログラムから利用でき、LAN上の別の機器から直接接続されることはありません。

デスクトップクライアントを同じLAN上のスマートフォン、テレビ、別のPCから使う場合、入力は通常0.0.0.0または具体的なLANアドレスで待ち受けます。その場合はシステムファイアウォール、ネットワーク種別、アクセス制御も同時に設定する必要があり、待ち受けアドレスを変えるだけでは不十分です。共有する機器には、コアを実行しているPCのLANアドレスと入力ポートを指定し、127.0.0.1は指定しません。詳しくはv2rayNで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": "http-in",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

SOCKS、HTTP、透過的な取り込みの違い

SOCKS入力は、SOCKSプロキシに対応したアプリに適しており、TCPを処理でき、設定によってはUDPにも対応します。HTTP入力は、HTTP CONNECTまたは通常のHTTPプロキシを使うプログラム向けです。どちらも、アプリまたはシステムプロキシが対応するポートを明示的に指定する必要があります。アプリでHTTPプロキシを設定した場合、SOCKSポートを指定することはできません。ポートが合っていてもプロトコル種別を間違えると、接続直後に切断される、ブラウザにプロキシ応答エラーが表示される、ログに解釈できないハンドシェイクデータが出るといった症状になります。

TUNモードは通常のローカルプロキシとは異なります。仮想ネットワークインターフェースで、より広い範囲のシステム通信を受け取り、クライアント側でルーティングテーブル、DNSの取り込み、権限も設定する必要があります。TUN設定をSOCKS入力を1つ追加するだけのものと考えないでください。v2rayNはGUIのTUN項目に応じて実行パラメータを構成するため、通常はクライアント画面から有効化してログを確認します。他の環境のTUN設定全体を現在の設定へ直接貼り付けるのは避けてください。通常のシステムプロキシでブラウザや一般的なデスクトップアプリを利用できるなら、「より多くをカバーする」ために複数の取り込み方式を同時に有効にする必要はありません。

sniffingがドメインルーティングに役立つ仕組み

sniffingは、接続中のプロトコルの特徴から宛先ドメインを復元します。アプリによっては、先に自分でドメインを解決し、IPアドレスだけをプロキシへ渡します。routingがドメインルールだけを持つ場合、コアはIPしか見られず、ドメインで照合できません。嗅探を有効にすると、HTTPリクエストのホスト情報やTLSハンドシェイクのサーバー名から、ルーティングモジュールがドメインを取得できる場合があります。例のdestOverrideは、認識したHTTPまたはTLSの宛先で元の宛先アドレスを上書きし、後続ルールの判定に使えるようにします。

嗅探はDNSの代わりではなく、すべての接続でドメインを復元できるわけでもありません。認識可能なホスト情報がないプロトコルではIPしか取得できず、暗号化ハンドシェイクやアプリの動作も結果に影響します。ルーティングが一致しない場合は、アクセスログにドメインとIPのどちらが記録されているかを確認し、domainStrategyの調整、IPルールの追加、嗅探設定の確認を判断します。ログを見ずに同じドメイン条件やIP条件を繰り返し追加すると、ルールの保守が難しくなります。

ポート、認証、タグの設定原則

同じアドレスのポートを2つのプロセスが同時に使用することはできず、2つの入力で同じアドレスとポートを待ち受けることもできません。クライアント起動直後にアドレス使用中と表示されたら、まず重複起動したインスタンスを終了し、他のプロキシツールや古いコアプロセスを確認します。ポートを適当に変更するだけでは不十分です。システムプロキシ、ブラウザ拡張、LAN機器側のポートも合わせて変更する必要があります。混乱を減らすため、SOCKSとHTTPのポートを隣接させる方法はありますが、固定の数字だけでプロトコル種別を判断しないでください。

auth: "noauth"は、ループバックアドレスだけで待ち受けるローカルSOCKS入力に適しています。LANアドレスで待ち受ける場合は、クライアントの対応状況を確認し、認証とファイアウォールの制限を組み合わせ、信頼できるネットワークからだけアクセスできるようにします。タグは入力ごとに固有の名前を付けると、inboundTagで入口ごとに異なるルーティングを設定できます。たとえば端末内の通信は通常の振り分け、LAN共有の入口は一部ポートを制限します。タグを変更したら、routing内の参照をファイル全体で確認し、古い名前が残らないようにします。

04 / ROUTING

routing ルーティングルール

ルールは上から照合され、最初に一致した結果が適用される

ルーティングモジュールは、接続先のドメイン、IP、ポート、ネットワーク種別、プロトコルの特徴、入力タグに基づいて出力を選びます。最も重要なのはルールの順序です。通常は上から順に確認し、1つ一致すると、そのルールで指定されたoutboundTagを使い、後続ルールは確認しません。したがって、具体的なルールを前に、広いルールを後ろに置きます。「すべてのTCP通信をプロキシへ送る」を1行目に置くと、後ろのドメイン別directルールは適用されません。

ルールを設計するときは、まずデフォルト方針を書き出し、次に例外を並べます。デフォルト出口がプロキシなら、ブロック条件と明確なdirect条件を先に置き、その他をデフォルトのプロキシへ流します。デフォルト出口がdirectなら、プロキシが必要な宛先を先に並べます。出力配列の順序、複雑なドメイン一覧、複数のフォールバックルールを同じ方針の表現として同時に使わないでください。分かりやすいデフォルト動作を1つ選び、ルールは例外だけを記述すると保守しやすくなります。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "protocol": [
          "bittorrent"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:intranet.example.com",
          "full:printer.example.net"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

ドメイン照合方式がルールの範囲を決める

ドメイン条件には、完全一致、ドメインとサブドメインへの一致、キーワード一致、あらかじめ用意されたドメイン集合などがあります。full:printer.example.netは完全なホスト名だけに一致し、単一サービスの範囲を明確にしたい場合に適しています。domain:example.comは通常、そのドメインとサブドメインを対象にし、関連ホストのまとまりに適しています。接頭辞のない文字列は文脈によって解釈が変わる場合があるため、保守時は照合方式を明示して本来の意図を残します。

キーワード一致は範囲が広く、短い文字列が無関係なドメインに誤って一致することがあります。名前の一部で分類する必要が本当にある場合を除き、fullまたはdomainを優先してください。ルールに一致しない場合は、まずコアが見ている宛先がドメインか確認します。アプリがすでにドメインをIPへ解決し、入力の嗅探でもドメインを復元できないなら、どれだけ正確なドメインルールを作っても適用されません。アクセスログを確認し、適切なsniffingを有効にするか、既知のアドレス範囲にIP条件を追加します。

domainStrategyがドメインルールとIPルールをつなぐ

domainStrategyは、IPルールとの照合のためにドメインを解決する条件を制御します。AsIsは受け取った宛先形式をそのまま判定する方針で、ルーティング照合のためだけにドメインをIPへ変換しません。IPIfNonMatchは通常、ドメインルールに一致しなかった後で名前解決し、IPルールを試します。ほかのポリシーはより積極的に解決する場合があります。積極的なポリシーほどドメイン通信をIP分類へ回しやすくなりますが、DNSの動作とルーティング結果の結び付きも強くなります。

ポリシーを選ぶ前に、現在のルールが主にドメイン依存かIP依存かを確認します。大部分が明確なドメインルールで、一部のネットワークだけ補足判定するなら、IPIfNonMatchは理解しやすい選択です。すべてのドメインを先にアドレス分類するなら、DNS設定と想定する出口を一致させる必要があります。解決サーバー、キャッシュ、アドレス族が違うと同じドメインでも結果が変わり、ルーティングも変化します。domainStrategyを変更したら、ドメインルール、IPルール、未一致の宛先をそれぞれテストし、1つのページを開くだけで判断しないでください。

IP、ポート、ネットワーク、入力タグは組み合わせて使える

IP条件には、単一アドレス、CIDRネットワーク、コアが対応する定義済み集合を指定できます。プライベートアドレスは通常directにし、ルーター、プリンター、LANサービスへのアクセスをリモートへ送らないようにします。ポート条件は53や80,443のように対象サービスを絞るのに適しており、範囲も表現できます。ネットワーク条件ではtcp、udp、または両方がよく使われます。異なる項目を同じルールに置くと通常はすべてを満たす必要があり、同じ項目の配列内の複数値はどれか1つに一致すれば適用されます。

inboundTagは接続元の区別に適しています。たとえばsocks-inは通常の振り分け、lan-inは指定した出口だけを許可する設定にできます。接続元ごとに複数のコアを起動する必要はありません。設定時は入力タグが実際に存在することを確認し、接続元の制限をルールの前方に置き、広い宛先ルールに先に一致しないようにします。ポートやプロトコルをブロックする場合も範囲を絞ってください。広すぎると、アプリのトップページは開くのに再生、ログイン、同期ができないといった症状になります。

ログでルールを検証し、推測に頼らない

ルーティングを検証する最も有効な方法は、目的が明確なテスト項目を用意することです。directになる内部ドメイン、プロキシへ送る対象、ブロックされる条件を1つずつ用意し、アクセスログの出力タグを確認します。ログに宛先は表示されても想定したタグが出ない場合は、一時的にログの詳細度を上げ、テスト後に控えめなレベルへ戻します。ルールを変更したらコアを再起動または再読み込みし、クライアントが古い実行設定を使い続けていないことを確認します。

ルールが増えたら、設定の外部に各グループの保守メモを残し、「なぜ必要か」を記録します。ドメイン一覧だけを残すより価値があります。標準JSONにはコメントを書けないため、説明は別の文書で管理します。サブスクリプション更新は通常ノードとプロキシ出力に影響するもので、手動ルーティングまで上書きするべきではありません。更新のたびにルールが消えるなら、一時生成ファイルを編集している可能性があるため、クライアントのルーティング設定入口を使います。

06 / POLICY

policy ポリシーと統計

policyは動作を制御し、振り分け方向は決めない

policyはroutingの補助だと思われがちですが、主に接続セッションのタイムアウト、アイドル判定、統計スイッチを制御します。通信をプロキシへ送るかdirectにするかは、routingと出力が決めます。ポリシーは通常、ユーザーレベルごとに整理し、出力のユーザーオブジェクトにあるlevelで対応するレベルを指定できます。特別な設定がなければ、多くの構成はデフォルトレベルを使います。異なるセッション動作が明確に必要な場合だけ、複数レベルを追加してください。

タイムアウトは短ければよいとは限りません。短時間データが流れないからといって、接続が無効になったとは限りません。ロングポーリング、断続的なファイル転送、リモート端末、常時接続アプリではアイドル状態が発生します。アイドル時間を短くしすぎると再接続が頻発し、長すぎると無効な接続の破棄が遅れます。まずクライアントやコアのデフォルト動作を使い、ログとアプリの症状から必要性が確認できた場合だけ調整します。

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

handshakeとconnIdleは異なる段階を処理する

handshakeは接続確立段階で待機できる時間を制限します。まだハンドシェイクが完了していない接続が対象で、ページ全体の読み込み時間とは異なります。短すぎるとネットワークの揺らぎやリモートの応答遅延で早期に失敗し、長すぎると明らかに確立できない接続が長くリソースを占有します。ハンドシェイクがタイムアウトしたら、数値をすぐ大きくするのではなく、サーバーアドレス、ポート、トランスポート、ローカルネットワークを確認します。

connIdleはデータの活動がない接続をどれだけ保持するかに関係します。アイドル接続が閉じられると通常は再接続されますが、アプリによってはセッション切断として表示されます。毎回ほぼ同じアイドル時間で切断されるかを比較してください。一定ならポリシーを確認し、切断時刻が不規則でログにリモートリセットがあるなら、経路またはサーバー側の動作である可能性が高くなります。

uplinkOnlyとdownlinkOnlyは、一方向だけデータが流れる接続を処理するための項目です。アップロードやダウンロードの速度制限ではなく、アプリへ帯域幅を割り当てる機能でもありません。既存の接続動作が分からない状態で、最適化のために短くするのは避けてください。GUIクライアントが生成するデフォルトポリシーは通常の利用に適しており、長時間接続、リソース制約、明確なサービス要件がある場合だけ個別に評価します。

統計スイッチは収集の許可だけを担当する

statsUserUplink、statsUserDownlink、system配下の入力・出力統計項目は、該当方向の通信情報をコアが記録することを許可します。これらの真偽値を有効にしても、目に見えるグラフや画面上の数値が自動的に表示されるとは限りません。対応する統計モジュールと照会方法も必要です。クライアントがデータを利用しないなら、すべての統計項目を有効にしても不要な状態管理が増えるだけです。

統計項目を接続成功の判定に使わないでください。ある方向のバイト数が増えたことは、その範囲を通過するデータがあったことを示すだけで、宛先の内容が完全に返ったことや、想定どおりにルーティングされたことを単独で証明しません。接続品質はアクセス結果とエラーログを合わせて判断します。クライアント画面の通信統計は、システムAPI、コアAPI、クライアント独自のカウンターから取得される場合があり、policyの各スイッチと完全に同じ基準とは限りません。

複数のユーザーレベルには明確な対応付けが必要

複数のユーザーオブジェクトを含む場合、ユーザーごとに異なるlevelを指定し、policyのlevelsで対応するポリシーを定義できます。JSONではレベルのキーは文字列として記述し、例として"0"、"1"があります。ユーザーが未定義のレベルを参照すると、実装によってデフォルト動作が使われたり、問題が報告されたりします。保守時はユーザーレベルとポリシーレベルを一緒に確認し、片方だけをコピーしないようにします。

通常のクライアント出力に複雑なレベル体系は必要ありません。ノードサブスクリプションのユーザー識別情報は主にリモートプロトコル認証に使われ、各ノードにローカルのpolicyレベルを作る必要があるという意味ではありません。入力サービスとして運用し、セッションポリシーを分ける必要がある場合に複数レベルがよく使われます。本ページはクライアント設定を中心に扱うため、デフォルトの単一レベルを維持し、入力の安全性、出力パラメータ、ルーティングの可読性を優先してください。

ログレベルとポリシーを組み合わせて調べる

ポリシーの問題は「接続確立後に切断される」という形で現れることが多く、ログの時系列が必要です。通常運用ではwarningなど控えめなレベルを使い、調査中だけ詳細度を上げて開始時刻と再現手順を記録します。ログの保存先に書き込み権限がなければ、コアが起動できない、診断情報を残せないといった問題が起こります。GUIクライアントは通常ログの場所を処理するため、独立したコアを手動設定する場合にファイルパスを重点的に確認します。

再現後は、接続開始、最後のデータ活動、接続終了の3つの時刻を比較します。終了がポリシーの閾値直後なら、1項目だけ調整して再テストします。ログにリモート切断や基盤接続の失敗が明記されているなら、主な原因はpolicyではありません。調査が終わったら適切なログレベルへ戻し、テストのためだけに有効にした統計項目を削除して、実行設定を簡潔に保ちます。

08 / TROUBLESHOOTING

設定エラーと接続障害のトラブル対処

起動直後に失敗する場合：最初の明確なエラーを確認する

コアの起動に失敗すると、ログの後半に連鎖的なメッセージが複数出ることがあります。本当の原因は通常、最初に現れる明確なエラーの近くにあります。よくある種類は、JSON解析失敗、未知の項目、データ型の不一致、ポート競合、アクセスできないファイルパス、routingから参照されたタグの不存在です。まず最初のエラーを処理して再起動し、後続メッセージを根拠に複数箇所を同時に変更しないでください。後続エラーは最初の失敗の結果である可能性があります。

JSON解析エラーには通常、行番号や文字位置が示されます。その行の前後で、カンマの不足、余分な末尾カンマ、閉じていない引用符、全角記号の混入を確認します。エラー位置はパーサーが問題を発見した場所であり、本当の不足は前の行にある場合もあります。ファイルが長い場合は、最近追加したオブジェクト全体を一時的に削除し、基本設定が戻ったことを確認してから、断片を段階的に戻します。

コアは動作しているがアプリがローカルプロキシへ接続できない

この場合、まずリモートノードを調べないでください。アプリのプロキシアドレスが127.0.0.1か、ポートが入力設定と一致するか、プロキシ種別が合っているかを確認します。システムプロキシを使う場合は、クライアントで対応するモードが有効か確認します。コアを起動しただけでシステム設定が自動変更されるとは限りません。ブラウザ拡張、アプリ内プロキシ、システムプロキシが同時に存在すると、二重プロキシや古いポートへの接続が起きるため、テスト時は経路を1つに整理します。

Windows、macOS、Linuxのデスクトップ環境では、古いプロセスがポートを使用していることがあります。クライアントを終了した後、コアプロセスも終了しているか確認してから再起動します。入力ポートを変更した場合は、システムプロキシも更新します。Androidクライアントはシステムのネットワークインターフェースを通じてアプリ通信を取り込むため、デスクトップのローカルSOCKSポートとは確認点が異なります。まずクライアントが接続状態か、ログでコアが正常に起動したかを確認します。

ローカルプロキシには接続できるが、リモートハンドシェイクに失敗する

ログに接続拒否、ハンドシェイク失敗、リモートによる早期切断が出たら、「アドレスとポート → ユーザー識別情報 → プロトコル → トランスポート → セキュリティ層」の順に確認します。ドメインを解決できても、ポートが正しいサービスを指しているとは限りません。TCP接続が確立しても、TLS名とアプリケーション層のトランスポートが一致するとは限りません。サブスクリプションのノードはまず通常の更新を実行し、古いパラメータを使っていないことを確認します。手動ノードは元の設定情報と項目ごとに比較します。

システム時刻が大きくずれていると、時刻に依存する安全な接続へ影響します。まず端末の時刻を正常に戻してください。ネットワークを切り替えて問題が消えるなら、プロトコルだけでなく現在のネットワーク、DNS、アドレス族も確認します。ノードのタイムアウトはノードのタイムアウトを確認する手順に沿って段階的に調べ、ローカルネットワークやシステム時刻を飛ばして出力オブジェクトだけを何度も変更しないようにします。

一部のウェブサイトやアプリだけ失敗する

一部の宛先だけ失敗する場合、基本的な入力と少なくとも1つの出力は使える可能性が高く、次にルーティング、DNS、UDP、宛先の特徴を確認します。成功した対象と失敗した対象がそれぞれどの出力を使ったかを比較し、失敗対象がコアへ入った時点でドメインかIPかを確認します。誤ったルールでドメインがdirectへ送られていれば、ノードが正常でもその接続にプロキシは使われません。domainStrategyが別のアドレスを解決した場合も、想定したドメインルールと結果が異なることがあります。

アプリのログイン、音声、動画、同期機能は、異なるドメイン、ポート、ネットワーク種別を使う場合があります。トップページが開くのは、一部のリクエストが成功したことを示すだけです。トップページの結果だけでアプリ全体のドメインを広いルールへまとめないでください。再現時は、失敗した機能に対応するログの宛先を記録し、必要な条件を1つずつ追加します。UDPを使う場合は、SOCKS入力がUDPを許可しているか、プロキシプロトコルとサーバーが経路に対応しているか、routingがUDPを正しい出口へ送っているかを確認します。

ルールは正しそうなのに常に一致しない

まずルールの位置を確認します。前に、より広いdomain、IP、network、port条件がありませんか。次に宛先形式を確認します。ログに完全なドメイン、サブドメイン、IP、sniffingで復元された名前のどれが表示されていますか。さらに照合接頭辞が目的に合っているかを見ます。fullはすべてのサブドメインを自動的に含まず、キーワードは広すぎる可能性があります。最後にoutboundTagの表記と実行中のファイルを確認し、バックアップを編集していないか、クライアントが別の設定を読み込んでいないかを調べます。

特定のルールを検証するには、そのルールを一時的に前方へ移し、対象を明確なドメイン1つに絞ります。テスト後、ログの出力タグを確認します。それでも一致しないなら、宛先形式または設定未読み込みが原因です。前方へ移すと一致するなら、元の位置より前のルールが通信を先に取得しています。原因を特定したら順序を整理し、新しいルールをすべて最上部へ積み上げる運用は避けてください。具体的なルール同士が徐々に上書きし合うためです。

接続がしばらくすると切断される

まず切断が一定の時間間隔で起きるか判断します。毎回connIdleや一方向接続ポリシーの時間に近いならpolicyを確認します。時刻が不規則なら、リモートリセット、ネットワーク切り替え、端末のスリープ、アドレス変更を調べます。ノートPCが別のネットワークへ切り替わった後に古い接続が無効になるのは自然な動作で、クライアントは通常リンクを再確立する必要があります。スリープ復帰後の1回の切断を、すぐノードパラメータの問題と決めつけないでください。

ログのtimeout、context canceled、connection resetは、発生段階と原因が異なります。「エラー」と表示されたからといって同じ対処をしないでください。timeoutは直前の記録と合わせ、DNS、ダイヤル、ハンドシェイクのどこかを判断します。context canceledは上位リクエストが意図的に終了した可能性があり、resetはどちらか一方が接続をリセットしたことを示します。まず時系列で最初の異常を探し、後続のエラーが単なるキャンセルや後処理かを判断します。

再現可能なトラブル対処記録を作る

複雑な設定では、クライアント名、使用中のコア系統、入力ポート、デフォルト出力、最近変更した範囲、再現手順を短く記録します。ノードの機密情報を保存する必要はなく、構造が分かれば十分です。テストごとに「変更内容、予想、実際のログ」を書くと、2〜3回の試行で大部分の推測を排除できます。複数の項目を記録せずに切り替え続けると、偶然直った後も原因を特定できません。

復旧が必要な場合は、まず最小限の実用設定へ戻し、DNS、振り分け、ポリシーを1つずつ追加します。最小構成でも失敗するなら、クライアントのインストール、ローカルネットワーク、ノード自体に問題がある可能性が高いため、クイックスタートの手順に戻ってインポートと接続を確認します。カスタムルールだけが失敗するなら、検証済みのノード出力を残し、routingと宛先ログに集中して確認します。クライアントを再インストールする必要はありません。