V2Ray JSON設定ファイルガイド

01 / JSONの構造と接続経路

設定ファイルが示すのはコアの動作

GUIクライアントはサーバー管理、サブスクリプション更新、システムプロキシ、コアの起動を担います。コア設定は接続の待ち受け、ルーティング、名前解決、outboundへの接続を定義します。両者には関係がありますが、同じデータではありません。クライアントのメイン画面に保存されたサーバー情報は、通常、コアが読み込める設定に変換されます。画面上の名前を変更しても、コア設定内のすべてのタグが連動して変わるとは限りません。

接続経路は、アプリがinboundに接続し、inboundが接続先を受け取り、ルーティングがoutboundを選び、outboundが次の接続を確立する、という4段階で考えましょう。DNSはルール判定や接続時に使われることがあります。ログには各段階の一部が記録され、policyはタイムアウトや統計の動作に影響します。設定を調べるときはこの経路に沿って確認し、ブラウザーのエラーを見てすぐにDNS設定をすべて変更するのは避けてください。

オブジェクト、配列、値の型

JSONではオブジェクトに波括弧、配列に角括弧を使います。キー名と文字列は半角の二重引用符で囲み、ポートは通常数値、スイッチは引用符なしの真偽値で指定します。末尾の余分なカンマ、全角引用符、閉じ忘れた括弧があると、厳密なJSONとして解析できません。コアや読み込み方法によってはコメントなどの拡張構文が使える場合もありますが、このページの例はツール間で確認しやすいよう厳密なJSONにしています。

トップレベルは通常、1つのオブジェクトです。inboundsとoutboundsは配列で、複数の待ち受け口や出口を定義できます。一方、routing、dns、policyはオブジェクトで、それぞれルールや下位設定を含みます。同じ名前のトップレベルキーを重複して書いても、項目の追加にはなりません。パーサーによっては前の値が上書きされたり、読み込みが拒否されたりするため、必ず1つの項目にまとめてください。

シンプルな直結設定を基準にする

以下はローカルの待ち受けを確認するための完全な設定例です。ループバックアドレス上にSOCKS inboundを用意し、すべての接続を直結outboundに送ります。リモートプロキシサーバーは含みません。ポート番号は例なので、起動前に他のプログラムが使用していないことを確認してください。この設定で確認できるのは「アプリからローカルのコアに接続できるか」であり、リモートノードの利用可否を示すものではありません。また、システムプロキシも自動では変更されません。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

例を読むときは、まず待ち受けアドレスとポート、次にinboundプロトコル、最後にデフォルトoutboundを確認してください。ルーティングルールがない場合、一般的にはoutbounds配列の先頭が使われます。つまり、配列の順序は単なる見た目の問題ではありません。クライアントが設定を再生成した後は、デフォルトの出口も確認しましょう。特定のプロキシプロトコルのオブジェクトが残っているかだけでは不十分です。

設定内のtagは、ほかの項目から参照するための識別子で、接続情報ではありません。短く、一意で、意味が変わりにくい名前を付けましょう。ファイル名だけでは設定の有効性は決まりません。config.jsonという名前でも、現在のコアプロセスが実際に読み込んでいなければ反映されません。以降の章を確認するときは、起動できる設定を手元に残し、関連する部分を1つずつ変更してください。

02 / inbounds：待ち受けアドレスと受信プロトコル

まず、どのアプリが接続するのかを確認

inboundは、コアがどのアドレスとポートで、どの種類の接続を受け付けるかを定義します。デスクトップアプリでよく使われる入口はSOCKSまたはHTTPプロキシですが、ポート番号だけを見て互換性があると考えてはいけません。アプリ側でHTTPプロキシを選択しているのに、SOCKSのハンドシェイクしか受け付けないポートへ接続すると、待ち受け中でもすぐにプロトコルエラーになる場合があります。アドレス、ポート、プロキシの種類を合わせて確認してください。

listenは待ち受ける範囲を決めます。127.0.0.1にバインドすると、主に同じ端末から利用できます。すべてのインターフェースで待ち受けるとアクセス範囲が広がり、システムのファイアウォールやネットワーク環境の影響も受けます。リモートプロキシの暗号化によって、LANに公開したローカルSOCKSポートまで自動的に保護されるわけではありません。共有が明確に必要で、アクセス制御も設定している場合を除き、ループバックで待ち受けるほうが範囲を限定できます。

SOCKSとHTTPを別々に定義

次の例では2つの入口を並べて定義します。SOCKSは例として10808番、HTTPは10809番を使います。ポート番号はソフトウェアの識別子ではないため、変更した場合はアプリ側も合わせてください。同じアドレス上で2つの待ち受け設定が同じTCPポートを使うことはできません。別のクライアントがバックグラウンドで動いている場合は、使用中のプロセスを確認してから、終了するか別のポートを選びましょう。

{
  "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": {}
    }
  ]
}

settings.authがnoauthの場合、SOCKS inboundではユーザー名とパスワードを要求しません。この設定は管理されたローカル待ち受け向けであり、ネットワーク上で自由に共有してよいという意味ではありません。認証が必要な場合は、使用中のコアのSOCKS inbound仕様に従ってアカウントを設定し、接続元も同じ認証方式に対応していることを確認してください。HTTP inboundには独自の設定構造があり、SOCKSの認証項目をそのまま流用できません。

udpを有効にすると、SOCKS inboundで対応するUDPリクエストを処理できますが、すべてのアプリにUDPプロキシを提供できるという意味ではありません。アプリ自体がSOCKSのUDP転送方式に対応し、outboundプロトコルとリモートサービスにも必要な機能が求められます。OSのHTTPプロキシを設定しただけでは、任意のUDPアプリが自動的にこのSOCKS入口を使うわけではありません。これはトラフィックが流入する経路の違いです。

スニッフィング情報と元の接続先

sniffingは、対応するプロトコルのハンドシェイクからドメイン名などの情報を取得しようとします。アプリが接続先IPだけを渡した場合でも、スニッフィングによってルーティングに必要なドメイン名を補えることがあります。例のdestOverrideは、接続先の上書きに使えるプロトコルの種類を指定しますが、情報を取得できるかどうかは実際のトラフィック次第です。すべてのアプリの通信内容を復号したり、元のアクセス先ドメインを必ず特定したりする機能ではありません。

スニッフィングを有効にすると、ルーティングやoutbound処理で使われる接続先情報が変わることがあります。一部のコアにはルーティング専用の関連オプションもありますが、対応項目や詳細は個別に確認してください。有効化後に特定アプリで問題が起きた場合は、無効時と有効時のログや接続先を比較し、次にoutboundがドメイン指定を受け付けるか確認しましょう。すぐにinboundポートの問題と決めつけないでください。

inboundのタグは、ルーティング内のinboundTagから参照し、ローカルアプリごとに異なる出口を割り当てることもできます。その場合はタグを一意に保ち、アプリに使わせる入口を明確にしてください。よくあるミスはinboundの名前を変更したのに、ルーティングルールの参照を更新し忘れることです。その結果、接続が後続ルールやデフォルトoutboundに流れ、inbound設定が保存されていないように見えることがあります。

変更後は、現在使用中のコアを再起動または再読み込みし、待ち受けに成功したか確認してください。システムプロキシの切り替えはクライアントまたはOS側の機能であり、inboundオブジェクトを追加しても自動では有効になりません。アプリが実際にこの入口を使っているか、クイックスタート手順と照らし合わせて確認してから、outboundやルーティングを調べましょう。レイヤーをまたいだ無駄な変更を減らせます。

03 / outbounds：出口、タグ、プロトコル設定

outboundの順序とルーティングからの参照

outboundは、コアが接続先へどう接続するかを定義します。直接接続、ブロックのほか、プロキシプロトコルでリモートサーバーへ接続する設定もできます。tagはルーティングルールから出口を選ぶために使い、protocolによってsettingsの構造が決まります。名前がproxyのoutboundが必ずプロキシとは限らないため、プロトコルの内容を確認してください。逆に、プロキシoutboundに別の一意なタグを付けることもできます。

一般的な設定では、どのルールにも一致しない接続は配列の先頭に渡されます。プロキシをデフォルト経路にする場合は先頭の項目を明確にし、必要な直結ルールも残してください。読みやすさのためだけにoutbounds配列を並べ替えてはいけません。クライアントが現在のサーバーやルーティングモードに応じて順序を再生成する場合があるため、実行中の設定を基準に確認してください。画面上の一覧順では判断できません。

直結とブロックの最小構成

freedomは端末のネットワークから直接接続し、blackholeは該当する接続をブロックします。以下の例は直結テスト用設定のoutbounds部分として使えるほか、プロキシoutboundを含む設定にも統合できます。ブロックoutboundを定義しただけでは、どの接続も自動的にブロックされません。該当するルーティングルールで選択するか、デフォルトoutboundにする必要があります。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

直結でもドメイン名の名前解決は必要です。接続先がドメイン名なら、対応するコンポーネントが接続可能なアドレスに変換しなければなりません。組み込みDNSとシステムの名前解決のどちらを使うか、またアドレスファミリーをどう選ぶかは、使用中のコアとoutbound設定によって異なります。ルーティングで「直結」を選んでも、DNSクエリの経路まで分かるわけではありません。

リモートプロトコルの項目を混ぜない

プロキシoutboundには、実在するサーバーアドレス、ポート、認証情報が必要です。VMess、VLESS、Trojan、Shadowsocksでは認証情報の構造が異なり、トランスポート層やセキュリティ層にもそれぞれ制約があります。このページでは架空のアカウントを使った完成済みプロキシ設定は提供しません。実際に使う接続情報からoutboundを生成し、サーバー側と設定項目が一致しているか確認してください。プロトコル名だけを変更し、別のプロトコル用ユーザー情報を残すのは誤りです。

トランスポート設定は通常、streamSettingsなどの対応する構造に含まれます。トランスポートの種類はサーバーの実際の構成と一致させる必要があり、対応状況はコアによって異なります。REALITYなどの機能が、どのコアでも使える共通項目だと考えないでください。コアを選ぶ前にXrayとV2Flyコアの違いを確認し、クライアントが生成する設定を利用できるか確かめましょう。

サーバーアドレス、TLSのサービス名、トランスポート層のホスト項目が同じ値になることはありますが、それぞれ意味は異なります。サーバーアドレスは接続先を決め、サービス名はハンドシェイクや認証に使われ、一部のトランスポートヘッダーはサーバー側でリクエストを振り分けます。ハンドシェイクエラーが発生したら、接続情報の各項目を個別に照合してください。ドメインに関係する項目をすべてサーバーIPに置き換えるのは避けましょう。

証明書の検証をスキップする設定を、通常の修正方法として使わないでください。プロトコルの不一致、リモートポートの誤り、システム時刻のずれは解決せず、認証の境界を変えてしまいます。証明書関連のエラーが出たら、まずシステム時刻、サービス名、証明書の適用範囲を確認してください。サーバーに特殊な構成がある場合は、明確な設定情報を入手してからセキュリティ項目を変更しましょう。

最後に依存関係を確認します。ルーティングから参照されるoutboundタグがすべて存在し、名前の大文字・小文字も一致している必要があります。古いサーバーのoutboundを削除した場合は、それを参照するルールも削除してください。複数の出口を使う場合は、まず明確な2つの出口で動作を確認し、その後に負荷分散や多段接続などを追加します。基本経路が確認できていない段階で階層を増やすと、障害箇所の特定が難しくなります。

04 / routing：一致条件とルールの順序

上から順にルールを判定

ルーティングは接続情報に基づいて出口を選びます。一般的なフィールドルールでは、typeにfieldを指定し、ドメイン、IP、ポート、inboundタグなどの条件を設定します。通常は配列の順番に判定され、一致すると指定した出口が使われます。範囲が狭く優先度の高い例外を先に、広範囲のルールを後に配置してください。そうしないと、後続ルールが判定されない場合があります。

1つのルール内では、異なる条件項目は通常すべて満たす必要があります。同じドメイン一覧やIP一覧にある複数の値は、一般にいずれかに一致する条件を表します。「特定のドメインに一致する、または特定のinboundから来た接続」を実現したい場合は、2つのルールに分けてください。1つのオブジェクトに両方の項目を並べるのは適切ではありません。設定にする前に「かつ」と「または」のどちらなのかを文章で整理しましょう。

条件を絞った接続先で順序を確認

次の例では、サンプルドメインをブロックoutboundへ、プライベートアドレスを直結outboundへ送ります。前章で定義したdirectとblockのoutboundが必要で、使用中のコアが対応する地理データを読み込めることが前提です。例のドメインはルール検証用であり、本番環境での推奨リストではありません。それ以外の接続はデフォルトoutboundへ送られるため、この2つのルールを追加しただけで全通信がプロキシ経由になるわけではありません。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

ドメインの一致条件では、完全一致、サブドメインを含む範囲、正規表現を区別してください。たとえばfull:example.comは指定したドメインだけに一致し、domain:example.comはそのドメインとサブドメインに使います。通常の文字列はこれらのプレフィックスと一致条件が異なり、想定より広い範囲にマッチすることがあります。意図を明確に表せる形式でルールを記述してください。

ルーティングの名前解決方針と出口の名前解決は別

AsIsは通常、IPルールのために受け取ったドメイン名を積極的に解決しません。接続先が最初からIPアドレスなら、IP条件に一致することがあります。IPIfNonMatchはドメイン段階で一致しない場合に名前解決し、IPルールとの照合を試みます。IPOnDemandはルール判定にIP情報が必要になった時点で、より早く名前解決する場合があります。いずれもルーティング判定段階の設定であり、DNS通信全体の仕組みを定義するものではありません。

例のように、受け取った接続先が完全なドメイン名example.comなら、最初のルールに一致するため、後続のプライベートアドレスルールに頼る必要はありません。ドメインルールに一致しない場合は、名前解決した結果がIPルールの判定に使われることがあります。上位に広範囲のドメイン直結ルールがあると、後方のIPブロックルールが実行されない可能性があります。名前解決方針だけを変更しても、ルール順序の問題は解決しません。

ルールデータが見つからない場合、コアは読み込み時にエラーを出すことがあります。データが古い、または分類が期待と異なる場合は、起動できても振り分けが誤ることがあります。まずこの2つを区別してから、ファイルの場所とルールの内容のどちらを確認するか決めてください。クライアントのルールデータ更新とサーバーサブスクリプションの更新は別の操作です。サブスクリプションの更新に成功しても、地理データが更新されたことにはなりません。

特定の入口に出口を割り当てる場合はinboundTagを使えます。接続先ポートで照合する場合は、使用中のコアが対応するポート表記を使ってください。まず単一の条件で確認し、その後に条件を追加しましょう。ログでは接続先と実際の出口を両方確認します。接続先が想定どおりなのに出口が違う場合に、ルーティング判定を重点的に調べてください。すぐにリモートプロトコルの項目を変更する必要はありません。

グローバル、ルール、直結などのモードは、クライアントが生成設定に適用するプリセットであることが多く、汎用JSONに独立した項目として存在するわけではありません。モードを切り替えたら、デフォルトoutboundとルール配列を改めて確認してください。振り分けに疑問がある場合は、具体的な接続先、入口、一致した条件、最終的な出口を記録しましょう。「一部のサイトにつながらない」より再現しやすく、変更前後の比較にも役立ちます。

05 / dns：名前解決元、アドレスファミリー、ルーティングとの関係

まず3つの名前解決経路を区別

アプリがプロキシに接続する前に自分でドメイン名を解決する場合も、ドメイン名をそのままプロキシへ渡す場合もあります。コアがルーティングやoutbound接続のために独自のリゾルバーを使うこともあり、最後の名前解決をリモートサービスが担う場合もあります。これらの経路は同時に存在することがあります。設定にdnsオブジェクトがあるからといって、すべてのアプリのクエリがそこで処理されるわけでも、システムDNSが置き換わるわけでもありません。

たとえば、アプリが先にIPアドレスを取得し、そのIPをSOCKSの接続先として渡すと、コアが最初に受け取る情報にドメイン名が含まれない場合があります。その場合にドメインルールを使えるかどうかは、スニッフィングなどで情報を補えるかによります。アプリがドメイン名をプロキシに渡せば、ルーティングやoutboundで接続先情報をより多く保持できます。複数のアプリの接続結果を比較する前に、ローカルプロキシへ渡しているのがドメイン名か、解決済みのアドレスかを確認してください。

基本的な組み込みDNS設定

以下は通常のDNSサーバーを2つ設定し、組み込みの名前解決でIPv4アドレスのみを問い合わせる例です。アドレスは構造を示すためのもので、あらゆるネットワークで最適とは限りません。また、OSのDNS設定も変更しません。DNSサーバーへの到達性、利用するネットワーク、プライバシー要件は個別に評価してください。アドレスを記述しただけで、そこまでの通信経路が利用可能になるわけではありません。

{
  "dns": {
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIPv4"
  }
}

serversにはシンプルなサーバー項目のほか、ドメイン範囲や期待するアドレスなどの条件を含むオブジェクトを使える場合もあります。オブジェクトの項目が「常にこのサーバーだけに問い合わせる」という意味とは限りません。実際の候補選択やフォールバックは、使用中のコアの処理にも左右されます。複雑なオプションを一度に追加せず、まず基本的な問い合わせが届くことを確認してから、対象ドメインやフォールバックの動作を一つずつ絞り込みましょう。

実際のネットワークに合わせてアドレスファミリーを選択

queryStrategyは、組み込みDNSで問い合わせるアドレスファミリーを制御します。IPv4のみの問い合わせは特定のアドレスファミリーに関する問題を切り分けるのに使えますが、あらゆる接続障害に効く汎用的な対処ではありません。IPv6が利用できるネットワークでは、IPv6の問い合わせを維持する必要がある場合もあります。反対に、システムがIPv6アドレスを取得できても、リモートサービスへのIPv6経路、プロキシサーバー、outbound設定が同じように対応しているとは限りません。

最終的に選ばれるアドレスファミリーは、アプリが先に行う名前解決、outbound側の解決方法、リモート側の処理にも影響されます。トップレベルDNSの問い合わせ方針を変えても、すべての接続が特定のアドレスファミリーだけを使うとは限りません。調査時はDNSの応答と実際の接続先アドレスを比較してください。異なる場合は、別のリゾルバーやリモート側で処理されていないか確認し、互いに矛盾するDNSオプションを重ねて追加しないでください。

名前解決とプロキシの循環依存を避ける

プロキシサーバーのアドレスがドメイン名で、その名前解決にも、まだ確立していないプロキシ経由のリゾルバーが必要だと、起動時に循環依存が発生することがあります。暗号化DNSを使い、リゾルバーの接続先もドメイン名の場合は、その接続先を最初にどう名前解決するかも考慮してください。どの段階で初期の名前解決を行うか、プロキシの起動に依存しない経路はどれか、現在のネットワークから実際に到達できるかを明確にしましょう。

DNSクエリのルーティング、タグ、ローカル名前解決の扱いはコアによって異なります。暗号化DNSのアドレスを文字列にコピーしただけで、クエリが指定したoutboundを必ず通るとは限りません。リモート側での名前解決が必要な場合は、接続先の形式、対応状況、outbound経路を合わせて確認してください。システムの名前解決を使う場合は、OS独自のキャッシュやネットワーク設定の影響も考慮しましょう。

DNS設定の変更を試すときは、アプリやシステムのキャッシュ、既存の接続が変化を隠すことがあります。テスト中のページの古い接続を閉じ、各OSの通常の方法でキャッシュを処理してから、同じドメインで再テストしてください。計画的な検証の代わりに大量のランダムなドメインを使うのは避けましょう。変更前後の名前解決結果とログを残せば、「応答が変わった」のか「出口が変わった」のかを区別できます。

DNSはルーティングと切り離された単独の最適化スイッチではありません。ルーティングが名前解決結果に依存する一方、名前解決の接続もoutbound経路の影響を受けることがあります。まず依存関係を整理してからドメインルールやアドレスファミリーを調整しましょう。基本的な接続が確立していないなら、シンプルなDNS設定に戻してください。複雑なドメイン分類、フォールバック制限、多段転送を先に追加するのは避けましょう。

06 / policy：タイムアウト、ユーザーレベル、統計

policyは表示名ではなくレベル番号で適用

policyは接続処理の方針と一部の統計スイッチを設定します。levelsの下にあるキーは、ユーザーレベル番号を文字列で表したものです。接続にどのレベルが適用されるかは、プロトコルのユーザー項目やinbound関連設定によって異なります。クライアントのグループ名、サーバーのメモ、サブスクリプション名はpolicyのレベルではありません。画面上の名前を変えても、別のタイムアウト設定が自動的に選ばれるわけではありません。

ユーザーレベルを明示的に設定していない一般的なケースでは、通常レベル0が使われますが、使用中のプロトコルとコアの動作を確認してください。レベルを分ける場合は、対応するユーザー項目でレベルを設定するフィールドを特定し、同じ番号をpolicyにも記述します。どの接続からも使われないレベルを定義しても、既存の接続には反映されず、policyが正常に対応しているかの判断にも使えません。

タイムアウト値が示すのは処理段階の境界

以下の数値は説明用の例であり、コアのデフォルト値を示すものではありません。handshakeはハンドシェイク段階、connIdleはアイドル状態の接続、uplinkOnlyとdownlinkOnlyは片方向の終了後に待機する動作に関係します。一般に各項目は秒単位ですが、実際の意味は使用するコアのドキュメントで確認してください。速度測定や帯域幅の設定ではありません。

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

ハンドシェイクの時間を短くしすぎると、ネットワークの揺らぎやサーバーの応答遅延で接続が途中終了することがあります。長く設定しても、誤ったパスワードや不一致のトランスポートが正しく動くようにはなりません。ハンドシェイクに失敗したら、ログでタイムアウト、認証エラー、プロトコル不一致のどれに該当するか確認してください。接続可能な経路で、実際に待機時間の制限によって終了している場合に限り、タイムアウトの調整を検討しましょう。

アイドル状態の接続とデータを継続して転送する接続は異なります。ブラウザーの接続プール、メッセージアプリの長時間接続、ターミナルセッションは、一定時間アプリデータを送らないことがあります。アイドル制限を短くしすぎると、再接続が必要になる場合があります。「しばらく放置すると最初のアクセスに失敗する」場合は、アプリの再接続、ネットワーク機器のセッション維持、リモート側の動作も考慮してください。時間が空いたというだけでローカルpolicyが原因と決めつけないでください。

片方向の終了はセッション全体の終了とは限らない

一部のプロトコルでは、片方が送信を終了した後も、残りのデータを受信できます。片方向の待機時間を指定する項目は、このような接続状態を扱うもので、ダウンロード時間を延ばすスイッチではありません。待機時間を極端に短くすると必要な終了処理を中断することがあり、長くすると不要な接続が残り続ける場合があります。具体的な問題がなければ、いわゆる「最適化設定」をそのままコピーするより、コアのデフォルトを維持するほうが管理しやすいでしょう。

policyでは、基盤ネットワークのパケットロス、リモート側による接続拒否、証明書のサービス名エラーは修正できません。TCP接続の確立前に起きる問題に対して、プロトコルのハンドシェイク後に適用されるアイドル時間を変更しても効果はありません。エラーの段階を見分けましょう。ローカル待ち受け、名前解決、リモートへの接続、プロトコルのハンドシェイク、安定したデータ転送では、確認すべき項目が異なります。段階をまたいだ推測は避けてください。

統計スイッチと表示方法は別に設定

例では、関連する統計スイッチを明示的に無効にしています。これは項目の位置を示すためのものです。ユーザー統計を有効にするには、通常、識別可能なユーザー情報と対応する統計機能も必要です。外部プログラムからデータを取得するには、統計オブジェクト、APIサービス、アクセスを制限した接続口が必要になる場合もあります。真偽値を1つ変更しただけで、クライアント画面に使える統計パネルが自動表示されるわけではありません。

統計項目はサービス提供元の課金データと同じではありません。コアが特定のレイヤーで接続量を集計する一方、リモートサービスでは別の基準を使う場合があります。再起動、コアの切り替え、状態の消去によってローカルで集計する範囲が変わることもあります。記録が必要な場合は、対象、期間、リセット条件を先に決めてください。ローカルで観測した値を、アカウント残高や最終的な請求額と解釈しないでください。

policyを安全に変更するには、まずデフォルト値を維持し、再現できた症状に関係する項目だけを調整します。元の値、改善したい症状、再テストの結果を記録してください。改善しなければ元に戻します。接続が本当に再確立されたか確認し、古い接続を使い続けるアプリが変更の効果を隠していないか注意しましょう。policyは接続のライフサイクル管理に関わるため、基本的なプロトコルとルーティングを確認した後に扱います。

07 / クライアントによる設定生成、サブスクリプション、TUN

編集対象は元データか実行設定か

v2rayNはデスクトップでのサーバー管理とコアの起動に適しています。Androidでは主にv2rayNGが使われ、v2flyNGはV2Flyコアを使う場合の選択肢です。3つのクライアントでは画面設定や保存方法が完全には共通していませんが、どれもサーバーデータ、クライアント設定、最終的なコア設定を区別する必要があります。あるクライアントの設定フォルダー構成を、別のクライアントにそのまま当てはめないでください。

クライアントが自動生成する実行設定ファイルは、サーバーやルーティングの切り替え、再起動時に上書きされることがあります。一時ファイルを直接編集すると、短時間は変更が見えても、長期間保持されない場合があります。編集前に対象が「カスタム設定」、ルーティング設定、通常のサーバー項目のどれかを確認してください。JSON全体を細かく制御したい場合は、クライアントが正式に対応するカスタム設定機能を使い、適用範囲も確認しましょう。

サブスクリプションはサーバー情報の取得元であり、汎用トップレベル項目ではない

サブスクリプションURLは通常、サーバー項目やクライアント対応の設定内容を取得するために使われ、解析はクライアント側で行われます。subscriptionは、V2Rayのトップレベルオブジェクトに自由に追加できる汎用項目ではありません。サブスクリプションを更新しても、コアが新しいサーバーに切り替わるとは限りません。クライアントの一覧が更新されても、選択中の項目、接続中のセッション、実行中のプロセスが以前のままの場合があります。それぞれ確認してください。

更新に失敗したら、まずURLが完全か、引き続きアクセス権があるか、返された内容がクライアント対応の形式かを確認してください。ログイン画面、エラーメッセージ、空のテキストが返ると、解析失敗として表示されることがあります。サブスクリプションURLを公開ページに載せたり、アクセス情報を含むクエリ部分をログのスクリーンショットに貼ったりしないでください。詳しい手順はサブスクリプション更新失敗時の確認リストをご覧ください。

TUNはトラフィックを取り込む入口と、それに伴うルーティングの仕組み

TUNは仮想ネットワークアダプターを通じてトラフィックを処理経路に取り込みます。クライアントがこの入口に対応する別のコアや補助コンポーネントを使う場合があり、その設定モデルはこのページで扱うV2Ray形式のJSONとは限りません。画面にTUNスイッチがあるからといって、設定トップレベルに同じ名前のオブジェクトを追加しないでください。実際に使われるTUNコンポーネント、権限要件、設定形式を確認してから、対応する項目を調べましょう。

システムプロキシが影響するのは主にプロキシ設定に従うアプリです。TUNの対象範囲は、システムルート、除外設定、アドレスファミリー、トラフィック取り込み方式によって決まります。有効にしても取り込まれない通信が残ることがあり、ルーティング設定の誤りでネットワークに問題が起きる場合もあります。「グローバル」だからといって、すべてのプログラムやプロトコルが必ず同じ出口を使うわけではありません。分流ルールとアプリの動作を合わせて確認してください。

TUNを使う場合は、プロキシ接続自身が仮想ネットワークアダプターに再び取り込まれる状態を避ける必要があります。通常、クライアントが必要な迂回や除外を設定します。手動でルートを追加すると、この設定を壊すことがあります。有効化後にコアがサーバーへ接続できない場合は、まずループ状に取り込まれていないか確認し、次に権限、ネットワークアダプター、DNSを調べてください。設定手順はv2rayNのTUNモード設定ガイドをご覧ください。

設定を移行する際は、まずクライアント名と実際に使用するコア名を記録し、次に使用プロトコルと拡張機能を記録してください。Xrayに対応するoutboundやセキュリティ設定でも、V2Flyでそのまま読み込めるとは限りません。Project Vエコシステムのコア同士でも、設定項目が常に互換とは限りません。コアを変更したら、ウィンドウが開くことだけでなく、設定の読み込み、ハンドシェイク、ルーティングを改めて検証しましょう。

バックアップには、一時的に生成されたファイルだけでなく、復元方法を理解するために必要な元データも含めてください。カスタムルール、変更内容の説明、必要なクライアントのエクスポートデータを保管し、サーバーの認証情報を適切に保護しましょう。トラブルシューティング用の資料を共有する場合は、認証情報などの機密データをサンプル値に置き換えてください。置き換え後は、入れ子のオブジェクト、メモ、サブスクリプションのクエリ部分も再確認し、画面の先頭だけを隠して終わりにしないでください。

再インストールが必要な場合は、クライアント・各プラットフォームのダウンロードページから使用するOSとアーキテクチャに合ったものを選んでください。ファイル名が似ているだけで互換性を判断しないでください。インストール後は最小限の設定を復元し、サブスクリプション、ルーティング、トラフィック取り込みの設定を順番に戻します。古い設定をすべて一度に読み込んでからテストすると、環境の変化と設定の互換性のどちらが原因か区別できません。

08 / 設定の検証、ログ、ロールバックの順序

失敗した段階から原因を絞り込む

トラブルシューティングでは、まず現在の問題がどのレイヤーで起きているかを特定します。ウィンドウが開くことから分かるのは、クライアント画面が動作していることだけです。コアプロセスが起動して初めて、設定の読み込みが少なくとも所定の段階を通過したと判断できます。ローカルポートに接続できても、リモート認証の成功は確認できません。条件を分けて検証すれば、JSON構文エラーのままノードを何度も変更したり、アプリがプロキシを使っていないのにルーティングを繰り返し変更したりする事態を避けられます。

保存前に静的チェックを行います。括弧が対応しているか、文字列が閉じているか、配列要素の間にカンマがあるか、値の型が正しいか確認してください。次に構造上の意味を確認します。参照先のoutboundが存在するか、ルールデータを読み込めるか、プロトコル項目が現在のコアに対応しているかを調べます。厳密なJSONとして解析できても、構文が正しいと分かるだけです。コアがすべての項目を認識することや、実際のサーバー要件に合っていることまでは保証されません。

ログレベルは原因特定に必要な範囲で使い、終わったら戻す

warningは通常の実行情報を減らすのに適していますが、outboundの選択を確認するには不十分な場合があります。原因を調べるときは一時的にinfoへ変更し、必要に応じて使用中のコアが対応する詳細レベルを短時間使ってください。ログレベルによって記録されるイベントは異なるため、特定のログがないからといって、動作自体がなかったとは限りません。詳細ログに接続先アドレスが含まれる場合もあります。必要な時間だけ取得し、共有範囲を制限しましょう。

{
  "log": {
    "loglevel": "info"
  }
}

この例はログオブジェクトの置き換え用で、単独で起動できる完全な設定ではありません。出力ファイルのパスを別途指定する場合は、コアプロセスに書き込み権限があり、現在の実行環境からアクセスできる場所を選んでください。ポータブル版のフォルダー、保護されたインストール先、モバイル端末ではストレージ権限が異なることがあります。ログファイルが空の場合は、コアが何も記録しなかったと判断する前に、出力先と権限を確認しましょう。

よくある症状の確認順

ローカル接続が拒否された場合、まずリモートDNSを調べる必要はありません。現在のクライアントが終了していないか、コアが起動直後にクラッシュしていないか、アプリが実際の待ち受けポートを使っているか確認してください。複数のクライアントを同時に動かしている場合は、どのプロセスをテストしているか特定しましょう。ポートの競合はバックグラウンドプロセスが残っていると起きやすく、画面のウィンドウを閉じただけでは対応するサービスが終了しないことがあります。

リモート接続のタイムアウトと認証失敗は分けて対処してください。タイムアウトでは、接続先への到達性、ドメイン名が想定どおりのアドレスに解決されるか、outboundが自分自身へ戻る経路になっていないかを優先して確認します。認証失敗では、プロトコル、パスワードやユーザーID、トランスポートとセキュリティの設定を照合してください。関係のない項目を次々と変更すると、明確だったエラーに複数の問題が重なり、ログの比較も難しくなります。

特定の接続先だけで問題が起きる場合は、同じアプリと接続先を使ってテストしてください。そのアプリがプロキシを迂回していないか、独自DNSを使っていないか、古い接続を保持していないか確認し、一致したルールと最終的な出口を調べましょう。速度測定の成功は、実際のアプリで正常に動作することの証明にはなりません。測定では接続先、接続方式、ルーティング条件が異なる場合があります。関連用語は用語集をご覧ください。

変更を1つずつ試し、ロールバック記録を残す

毎回、直接因果関係のある項目だけを変更してください。たとえばローカルポートを変更する場合は、アプリが接続するポートも合わせて変更できますが、DNS、outboundプロトコル、ルーティングモードを同時に変えるのは避けましょう。保存後はクライアントの指示に従ってコアを再読み込みまたは再起動し、新しいテスト接続を作成してください。長時間接続は古い経路を使い続けることがあり、ページを更新しても新しい接続になるとは限りません。

テスト記録には、変更の目的、変更前後の設定、テスト対象、ログに現れた症状を含めます。根拠のない性能評価を記録する必要も、すべてのログを長期間保存する必要もありません。文脈のない「ネットワークが遅い」より、「特定のルールが誤った出口に一致する」のように安定して再現できる情報のほうが役立ちます。改善しなければ元の値に戻し、基準となる動作が維持されているか再確認しましょう。

日常利用に戻るときは、クライアントで安定して設定できる項目はクライアントに任せ、カスタムJSONは明確に必要な動作に限って使いましょう。操作箇所が分からない場合はv2rayNメイン画面ガイドをご覧ください。初回設定の順序は引き続き入門ガイドを参照してください。このガイドでは項目と設定範囲を解説しますが、実際の動作は使用中のコア、実行設定、再テストの結果に基づいて判断してください。