JSON設定リファレンス

JSONの構造と処理の流れ

まずクライアントとカーネルを区別する

v2rayN、v2rayNG、v2flyNGは設定を管理するための画面を提供し、カーネルはポートの待ち受け、プロトコル処理、接続の転送を担います。画面上のノード情報は、通常、カーネル設定全体ではありません。クライアントはノード、ルーティングテンプレート、ローカルの待ち受け設定、実行オプションを組み合わせて実行用ファイルを生成します。そのため、一時生成されたJSONを変更しても、次回の起動後に変更が保持されるとは限りません。読む前に、対象がノード情報、カスタム設定、クライアント生成の実行設定のどれかを確認しましょう。

V2FlyとXrayの設定は共通の起源を持ちますが、完全に同じ仕様ではありません。対応プロトコル、トランスポート項目、DNS拡張、デフォルト動作には違いがある場合があります。この記事では、両方でよく使われる構造を中心に説明し、特定のプロトコルに関する違いは明記します。異なるカーネル向けのサンプルを部分的に継ぎ合わせ、エラーが出るたびに項目を削除して起動させる方法は避けてください。起動できても、意図した経路で接続されるとは限りません。

最小構成のローカルテスト設定

以下の設定は、ループバックアドレスで待ち受けるSOCKS inboundを作成し、受け取った接続を宛先へ直接転送します。設定構造、ポート、アプリのプロキシ設定を確認するためのもので、リモートノードのテストには使いません。実行前にポートが空いていることを確認してください。クライアントが同じポートをすでに使用している場合は、ポートを奪い合わないよう、クライアントが提供するカスタム設定機能で個別にテストします。

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

接続処理の流れは、アプリがinboundに接続し、inboundが宛先を識別し、ルーティングでoutboundを選び、outboundが接続を確立する、という順序で整理できます。DNSはドメイン名の解決に関わりますが、すべてのリクエストが設定内のDNSを使うとは限りません。ログは問題の記録、policyは接続動作の制御を担います。それぞれの役割を分けて考えれば、問題が入口、経路選択、出口のどこで起きたのかを切り分けられます。アクセスできない原因をすべてノードのせいにしないようにしましょう。

オブジェクト、配列、データ型

トップレベルは1つのオブジェクトです。inboundsとoutboundsは複数の入口や出口を定義できる配列です。routing、dns、policyは通常オブジェクトとして指定します。ルーティングルールの順番など、配列の並びが動作に関係する場合があります。一方、オブジェクト内の項目順は通常、実行順を決めません。トップレベルの設定項目を並べ替えても、DNSの実行がルーティングより早くなったり遅くなったりするわけではありません。

厳密なJSONでは、フィールド名と文字列を二重引用符で囲み、末尾のカンマやコメントは使用できません。ポートなどの数値を安易に文字列へ変換せず、真偽値はtrueまたはfalseと記述します。一部のローダーが緩い構文を許容する場合でも、互換性のある設定にするには厳密なJSONに従ってください。特に、同じオブジェクト内でフィールドを重複させないようにしましょう。パーサーによっては最後の値だけが残り、ファイルを読み込めても先に指定した設定が上書きされることがあります。

tagは設定内で参照する名前であり、プロトコルの種類ではありません。outboundの名前はdirectでも別の名前でも構いませんが、ルーティング側では完全に一致する文字列を指定する必要があります。大文字・小文字、空白、つづりの違いでも参照に失敗することがあります。設定を書く前に、inboundとoutboundのタグを一覧にしておくとよいでしょう。変更は一度に1つの設定項目にとどめ、元に戻せるコピーを保存すると、全体を書き換えるより原因を特定しやすくなります。

inboundsの設定

待ち受けアドレスで入口の範囲を決める

inboundはカーネルが接続を受け付ける方法を定義します。最終的な接続先サーバーを決めるものではありません。listenはバインドするローカルアドレス、portは待ち受けポート、protocolは入口のプロトコルを指定します。この端末だけで使うなら、まず127.0.0.1へのバインドを検討してください。これはリモートサーバーのアドレスとは関係ありません。サブスクリプションに記載されたサーバーのドメイン名をここに指定すると、この端末に属さないアドレスへのバインドを試みることになり、通常は待ち受けに失敗します。

0.0.0.0にバインドすると、端末上のすべてのIPv4インターフェースで待ち受けます。同じネットワーク上の他の端末からアクセス可能になる場合があります。実際に接続できるかどうかはファイアウォールやネットワーク分離にも左右されますが、ファイアウォールを認証の代わりにしてはいけません。LAN内で共有する必要がある場合は、接続元の制限、適切な認証、待ち受けインターフェースをあわせて確認してください。接続のトラブル対処のために、すべての入口を全インターフェースへ公開するのは避けましょう。アクセス範囲が広がる別の問題が生じます。

SOCKSとHTTPのinbound

SOCKS inboundはSOCKSプロキシに対応したアプリ向け、HTTP inboundはHTTPプロキシ設定を使うアプリ向けです。どちらもローカルアドレスを使えますが、プロトコルは互換ではありません。アプリ側でHTTPプロキシを指定し、SOCKSの待ち受けポートに接続すると、TCP接続は確立しても、その後のハンドシェイクに失敗することがあります。この場合、リモートノードを切り替えても解決しません。まずアプリのプロキシ種別とinboundのプロトコルが一致しているか確認してください。

{
  "inbounds": [
    {
      "tag": "http-local",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

このHTTP inboundは、第1章のSOCKS inboundと並行して使えます。ただし、同じinbounds配列に追加してください。トップレベルに同名フィールドをもう1つ置くことはできません。2つのinboundには異なるポートを割り当てます。クライアントの画面がポートを自動管理している場合は、一時ファイルだけを変更せず、まず画面から設定してください。アプリのポート、クライアントの設定、実行ログに記録された実際の待ち受け先が一致していることを確認しましょう。

SOCKS設定のudp: trueは、そのinboundで対応するUDP転送を許可することを示します。すべてのアプリのUDP通信が自動的にカーネルへ入るという意味ではありません。アプリが適切なプロキシ方式に対応し、outboundとリモートサービスもUDPに対応している必要があります。従来のシステムHTTPプロキシは、すべてのUDP通信を中継するものではありません。音声通話などUDPを使うアプリの問題を調べるときは、inboundにこの真偽値があるかだけでなく、通信が実際にカーネルへ入っているかを確認してください。

スニッフィングとルーティングの違い

sniffingは、対応するプロトコルのハンドシェイクからドメイン名を識別する機能です。一般的にはHTTPやTLSが対象です。すべてのトラフィックを解析できるわけではなく、すべての接続でドメイン名を取得できる保証もありません。アプリがIPアドレスへ直接接続し、ハンドシェイクにも識別可能なホスト名が含まれない場合、ドメインルールに一致しないことがあります。スニッフィングを有効にすればドメイン別ルーティングが必ず機能する、とは考えず、アクセスログで実際の識別結果を確認しましょう。

カーネルによっては、スニッフィングで識別した情報をルーティングに使いつつ、実際の接続先は変更しない設定に対応しています。関連する項目と動作は、使用中のカーネルの仕様を確認してください。ここでは、そのような拡張を一般的なサンプルには含めません。使う場合は、ルーティング条件を補うのか、接続先自体を変えるのかを先に整理しましょう。この2つを混同すると、ログ上は正しいドメインに一致しているように見えても、実際の名前解決や接続先が変わることがあります。特にローカルサービスや特定のIPアドレスへのアクセスに影響します。

outboundsの設定

出口とデフォルトの選択

outboundは、受け付けた接続をカーネルがどのように処理するかを定義します。宛先へ直接接続する、リモートプロキシサービス経由で転送する、接続を破棄するといった処理ができます。ルールに一致しない場合、通常はoutbounds配列の先頭にあるoutboundが使われます。したがって、先頭のオブジェクトは単なる表示順ではなく、デフォルト動作の一部です。直結用オブジェクトを先頭へ移すと、これまでルールで指定されていなかった接続が直接接続に変わることがあります。

tagはoutboundを参照するための名前、protocolは使用するoutboundプロトコル、settingsはプロトコルごとに異なる設定項目です。ルーティングのoutboundTagで指定するのはタグであり、プロトコル名ではありません。同じプロトコルを使うoutboundを複数定義できますが、タグは一意にしてください。重複するとルールからの参照が曖昧になり、クライアントの設定生成で既存のオブジェクトが上書きされる可能性もあります。

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

freedomは、この端末から宛先へ直接接続することを示します。どのDNSを使うかまでは決まりません。blackholeは一致した接続を破棄します。アプリ側ではタイムアウトや接続失敗として見えることがあります。上記の設定だけを使う場合、デフォルトの出口は直結です。ブロック用outboundはルールで選択された場合にのみ使われます。outboundを定義しただけでは通信経路に使われません。デフォルトの順序とルーティングからの参照を両方確認してください。

リモートノードの設定項目は相互に推測できない

VMess、VLESS、Trojanなどのプロキシoutboundは、サーバー側の設定と一致させる必要があります。サーバーアドレス、ポート、認証情報、トランスポート方式、セキュリティ層はそれぞれ別の項目です。ある値から別の項目を推測することはできません。アドレスが正しくてもトランスポート経路が異なれば、認証情報が正しくてもセキュリティ層が合わなければ、接続に失敗します。実際に使うノードは、クライアントで有効なリンクやサブスクリプションからインポートしてください。Web上の設定例から、詳細不明のパラメーターを手入力することはおすすめしません。

一般的なプロキシoutboundでは、streamSettingsでトランスポートとセキュリティ層を指定することもあります。プロトコルは「プロキシリクエストをどう構成するか」、トランスポートは「バイト列をどう運ぶか」、セキュリティ層は「接続をどう保護または検証するか」を表します。自由に組み合わせられる3つのスイッチではありません。サーバーが特定の組み合わせのみを受け付ける場合、クライアント側もそれに合わせる必要があります。セキュリティ関連の項目をすべて有効にしても互換性は高まりません。サーバーが解釈できないハンドシェイクになることもあります。

接続先アドレスと、TLSで使うサーバー名も区別してください。前者はネットワーク接続に使い、後者はハンドシェイクやサーバー認証に使います。両者が異なることもありますが、サーバーの設定と証明書の条件を満たす必要があります。証明書エラーが出たら、サーバー名、端末の時刻、サーバー証明書チェーンを確認しましょう。検証のスキップを通常の対処方法にしないでください。認証条件を変えることになり、サーバー名の入力ミスを見えにくくする場合があります。

カーネルとoutboundの対応機能

v2rayNGはXrayカーネルを使用し、v2flyNGはV2Flyカーネルを使うクライアントです。v2rayNで実際に使われるカーネルは、現在の設定と実行ログで確認してください。共有リンクを画面で読み込めても、選択中のカーネルがすべての項目に対応しているとは限りません。未知のプロトコルや非対応のトランスポート項目がある場合は、まずカーネルの系統を確認し、設定に対応したカーネルが必要か判断しましょう。プロトコル名だけを書き換えても、ノードの方式は変換できません。

outboundには、UDP転送、多重化、接続再利用、ソケットオプションなども関係します。これらの機能が使えるかどうかは、カーネル、プロトコル、サーバーの組み合わせ次第です。最小構成ですべてを一度に有効にしないでください。トラブル対処では、まずクライアントが生成した基本のoutboundで単一の接続を確認し、その後に拡張項目を1つずつ戻します。一度に設定すると、失敗がinboundのUDP、リモートプロトコル、基盤ネットワークのどこで起きたのか、ログから判断しにくくなります。

複数のノードを管理するときは、クライアント画面の「現在のノード」と、カーネル設定内の「複数のoutbound」を区別しましょう。画面でノードを切り替えると、唯一のプロキシ出口が再生成される場合も、参照中のoutboundが変更される場合もあります。動作はクライアント次第です。サブスクリプションの更新後は、タグやルールからの参照が維持されているか確認してください。カーネルの関係についてはProject V、V2Fly、Xrayの系譜もご覧ください。

routingのルール

ルールの順序と条件の関係

routing.rulesは順序が重要なルール配列です。カーネルは順番に条件を確認し、一致するルールを見つけると対応するoutboundを選びます。一致するルールがなければ、デフォルトのoutboundが使われます。条件が明確で対象の狭いルールを前に置き、最後にフォールバック用の条件を置いてください。最初のルールがあるinboundのTCP・UDP通信をすべて対象にすると、後続のドメインルールは具体的に書かれていても適用されません。

1つのルール内では、異なる条件項目は通常すべて満たす必要があります。同じ項目の配列にある複数の値は、通常いずれか1つに一致すればよいという意味です。たとえばinboundTagとdomainを同時に指定すると、指定したinboundが受信し、かつ宛先ドメインが一致する接続が対象です。入口かドメインのどちらか一方に一致すればよい、という意味ではありません。独立した2つの条件を表す場合は、1つのオブジェクトに詰め込まず、ルールを分けてください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "block"
      }
    ]
  }
}

この設定例は、第3章で定義したdirectとblockに依存します。1つ目のルールは記載されたIPv4アドレス範囲を処理し、2つ目は完全一致するドメインだけをブロックします。一般的なプライベートネットワークの完全な一覧ではなく、IPv6のすべてのケースも対象にしていません。例ではAsIsを使用しているため、まだ名前解決されていないローカルドメインが、最終的なIPアドレスを理由に1つ目のルールへ自動的に一致するとは限りません。宛先がどの形式で認識されるかも、ルール条件の一部です。

ドメインルールとルールリソース

full:example.comはドメインの完全一致、domain:example.comはドメインとサブドメインを対象にします。URL全体をドメイン項目に記述しないでください。プロトコル、パス、クエリパラメーターはドメインではありません。ルートドメインとサブドメインの両方を対象にする場合は、マッチ方法を明確に選びましょう。正規表現はパターンが必要な場合に適しています。通常のドメインでは明示的なプレフィックスを使うほうが確認しやすく、意図しない範囲まで一致するリスクも抑えられます。

geosite:とgeoip:は分類リソースを参照する記述であり、任意の日本語カテゴリ名をカーネルが自動で認識するものではありません。リソースファイルが存在し、指定したカテゴリがそのファイルに含まれている必要があります。クライアントによって参照するルールリソースが異なる場合もあります。リソースの読み込みに失敗したら、まずファイルの場所とカテゴリ名のつづりを確認してください。outboundのアドレスを変更しても解決しません。リモート接続の前にルールリソースの読み込みで失敗している可能性があります。

domainStrategyによる名前解決の範囲

AsIsは可能な限り元の宛先を使ってルーティングします。IPIfNonMatchはドメインが一致しない場合に名前解決を試み、IP条件を確認できます。IPOnDemandは、ルーティングでIP条件を確認する必要があるときに名前解決する場合があります。後者2つは、ルーティング段階で必要となるDNS処理を変えます。「全通信をプロキシする」「直接接続する」と同じ意味ではなく、リモートプロキシサーバーが最終的な宛先をどこで名前解決するかも直接決めません。

クライアント画面のルーティングモードは、単一のdomainStrategyの値ではなく、ルール一式のテンプレートであることがよくあります。モードを切り替えると、ルールの順番、デフォルトoutbound、分類リソースが置き換わることがあります。振り分けの動作を確認する際は、最終的に生成されたroutingを調べ、宛先ドメイン、inboundタグ、一致したoutbound、ルールの位置を記録してください。ブラウザーでページが開けるかだけでは、デフォルトoutboundと個別ルールのどちらが使われたか判断できません。

小規模なテスト項目を用意し、完全一致ドメイン、サブドメイン、直接IP、ローカルサービスをそれぞれ確認しましょう。変更は一度に1つのルールだけにします。アクセスログにIPしか表示されない場合は、カーネルに入る前にアプリが名前解決していないか、inboundからドメイン情報が渡されているかを確認してください。DNSとルーティングは連携しますが、互いの代わりにはなりません。名前解決の振り分けについてはV2Ray DNSの振り分け設定を詳しく解説をご覧ください。

dnsの設定

まず、どの層が名前解決を行うか確認する

1回のアクセスで、複数の名前解決が行われる場合があります。システムがアプリの宛先を解決し、カーネルがルーティング用にドメイン名を解決し、outboundがリモートサーバーのアドレスを解決し、さらにリモートサービスが最終的な宛先を解決することもあります。dnsの設定項目はカーネル内のリゾルバーの動作を定義するもので、システムやすべてのアプリのDNS問い合わせを自動的に取り込むわけではありません。トラブル対処では、まず「どのプロセスが、どの名前を問い合わせたか」を確認してください。ブラウザー自身の名前解決結果をカーネルDNSの結果と誤認しやすいためです。

inboundがドメイン名を受け取った場合、カーネルはドメイン名をそのままプロキシoutboundへ渡すことがあります。inboundがIPアドレスしか受け取らない場合、DNSのドメイン分類に使える元の名前がないことが多いです。実際の問い合わせ経路は、ルーティングポリシー、直結outboundの名前解決設定、クライアントのネットワーク取り込み方法にも左右されます。そのため、DNSアドレスを変更してもアクセス経路が変わらない場合、設定の反映に失敗したとは限りません。そのリクエストが組み込みDNSを使っていない可能性もあります。

servers、hosts、問い合わせタイプ

{
  "dns": {
    "hosts": {
      "full:example.com": "192.0.2.1"
    },
    "servers": [
      "localhost"
    ],
    "queryStrategy": "UseIPv4"
  }
}

この設定例では、静的な名前解決とシステムの名前解決経路を説明します。192.0.2.1はドキュメント用の例示アドレスで、実際にアクセスできるWebサイトのアドレスではありません。このマッピングを残したままでは、組み込みDNSに依存する接続が正常にアクセスできるか検証できません。localhostはシステムの名前解決機構を使うことを意味し、任意のUDPポートへ問い合わせを送るという意味ではありません。実際に使う際は例示用マッピングを削除し、環境に合う名前解決方法を選んでください。

hostsを使うと特定の名前の解決結果を固定できます。トラブルの切り分けや、既知の内部名の利用には便利ですが、その名前の通常の動的な名前解決を迂回します。サービスのアドレスが変わると、古いマッピングが残り、誤った接続先を使い続けることがあります。特定のドメインがいつも異常なアドレスに解決される場合は、カーネル内のマッピング、システムのhostsファイル、アプリのキャッシュをそれぞれ確認してください。サブスクリプションを更新するだけでは、別の層にある設定やキャッシュは消えません。

queryStrategyは、組み込みDNSで使うアドレスファミリーを制御します。たとえばUseIPv4、UseIPv6、UseIPを指定できます。システムのネットワークプロトコルを変更する設定ではなく、すべての接続が特定のアドレスファミリーだけを使う保証もありません。端末にIPv6アドレスがあっても通信経路が使えない場合は、名前解決と接続を別々に検証してください。AAAAレコードが返ったことは、解決結果が得られた証拠にすぎず、そのアドレスへの通信が完了するとは限りません。

ドメインに応じてリゾルバーを選ぶ

servers配列にはサーバーオブジェクトを複数指定できます。よく使われる項目はaddress、domains、expectIPsです。domainsでは、そのサーバーで優先的に処理するドメインを指定します。expectIPsは受け入れる結果の範囲を制限します。後者はドメインへ静的にアドレスを割り当てる設定でも、outboundルールでもありません。結果が除外された後に別のサーバーへフォールバックするかどうかは、他のサーバーや使用中のカーネルの設定によります。

広いドメイン範囲に対して、狭すぎるIP条件を指定しないでください。コンテンツ配信、デュアルスタック環境、サービス移行によって、正常な応答のアドレスは変わることがあります。厳しく絞り込みすぎると、正常な応答が名前解決エラーに変わり、リモートノードの障害のように見える場合があります。設定前に分類ルールと実際のアドレス分布を確認し、設定後は受け入れられた結果と除外された結果を記録しましょう。情報が不足している場合は、対象を絞った小さなルールから検証してください。

通常のDNS、暗号化DNS、システムの名前解決では、接続経路が異なる場合があります。アドレスの形式によっては通常のoutbound処理を通らず、カーネルのルーティング対象になるものもあります。具体的な動作は使用中のカーネルが定めるサーバーアドレスの仕様で確認してください。「暗号化」という言葉だけで、必ずプロキシ経由になるとは判断できません。プロキシ経由でリゾルバーに接続する必要がある一方、プロキシサーバー名の解決も同じリゾルバーに依存すると、起動時に依存関係が循環します。プロキシサーバー名を独立して解決する経路を先に用意してください。

policy：接続と統計の設定

levelはルーティングの優先順位ではない

policyは接続のライフサイクルや一部の統計動作を設定する項目で、ノードを選択するものではありません。levels以下のキーはユーザーレベルの番号ですが、JSONオブジェクトのキーは文字列で記述します。プロトコルのユーザー設定や対応するinbound設定からユーザーレベルを参照できますが、参照項目はプロトコルによって異なります。明示的なレベルがなければ通常はデフォルトのレベルが使われます。数字が大きいほど高速という意味ではなく、ルーティングルールの順番を置き換えるものでもありません。

policyを設定する前に、実際にどのユーザー設定が使われているかを確認してください。inboundプロトコルに対応するユーザー設定がない場合や、クライアントが生成したファイルに想定するレベルが記載されていない場合、追加したレベルは参照されない可能性があります。levelsオブジェクトの存在だけで有効と判断せず、実行用ファイルで関連項目を確認しましょう。1人で使うローカルクライアントなら、参照先のない複数のレベルを作るより、デフォルトの動作を明確にしておくほうが管理しやすい場合があります。

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

これらの時間値は、秒単位で指定する一般的なpolicyの書き方を示す例であり、あらゆる環境に適した推奨値ではありません。各カーネルのデフォルト値と対応項目を確認してください。接続が切れるとき、最初に大きなタイムアウト値をコピーするのは避けましょう。ハンドシェイクが終わらないのか、接続が長時間アイドルなのか、どちらかの方向がすでに閉じられたのかを切り分けます。policyが効果を発揮するのは該当する段階だけです。認証エラー、証明書エラー、リモートサービスの待ち受け停止は解決できません。

4種類のタイムアウトが関係する段階

handshakeは、接続のハンドシェイクで待機できる時間を制限します。ネットワークの確立に時間がかかるとき、制限が短すぎると、本来完了できるハンドシェイクが途中で終了する場合があります。一方、上限をむやみに大きくすると失敗の判定が遅れるだけです。connIdleは接続のアイドル時間を対象とし、長期間使われていない接続の整理などに使います。アプリ自身のリクエストタイムアウトや、リモートのリバースプロキシのタイムアウトとは別のタイマーです。実際の切断は、どの層の制限が先に発生したかによって決まります。

uplinkOnlyとdownlinkOnlyは、通信が一方向だけになった接続を維持する時間に関係します。ダウンロード、長時間接続、片方向だけを閉じる処理に影響する場合がありますが、名前の上下行をそのまま「アップロード高速化」「ダウンロード高速化」と解釈しないでください。アプリが送信を終えた後も長い応答を待つ場合、片方向のタイムアウトが短すぎると接続が早く終了することがあります。アプリのプロトコルとログをあわせて確認しましょう。

policyを変更する必要があるか判断するには、同じくらいのアイドル時間が経過した後に問題が安定して起きるか、通信を再開すると切断を回避できるかを確認します。接続開始直後に毎回失敗するなら、プロトコルや認証を確認してください。ネットワークを切り替えた後だけ失敗する場合は、接続の再確立とシステムのネットワーク状態を調べましょう。すべての不具合をタイムアウトのせいにすると本当の原因を見落とし、使われない接続がリソースを占有する時間も長くなる可能性があります。

統計を有効にしても統計用インターフェースは作られない

policy.systemのinbound・outbound通信量の統計設定は、それぞれのカウンターを制御します。ユーザーレベルにもユーザー統計の設定がある場合があります。項目を有効にしても、画面に通信量グラフが自動表示されるわけではなく、外部向けの照会インターフェースが作られるわけでもありません。クライアント側では、統計モジュール、照会サービス、タグの関連付けが別途必要です。クライアントに通信量を表示したい場合は、重複するインターフェースを手動で作る前に、まずクライアントの標準機能を確認してください。

統計サービスや管理インターフェースで待ち受けアドレスが必要な場合は、適切なローカル範囲に制限してください。LAN向けinboundと一緒に公開しないようにしましょう。統計タグも実際のinbound・outboundに合わせないと、カウンターが空になったり、別の通信に誤って紐付いたりします。未対応の統計項目を設定に追加しても、カーネルが自動的に対応することはありません。項目やサービスの読み込みに失敗したら、基本設定に戻し、拡張機能が対応しているかを個別に確認してください。

policyの検証には、再現可能な1つの接続を使い、Webページを開いたときの体感だけで判断しないでください。変更前後の待機段階、終了理由、アプリの動作を記録し、どの変更を残すか決めます。カーネルの再起動は既存の接続やメモリー上のカウンターに影響します。比較する際は開始条件を揃えてください。日常的なクライアント利用では、生成された妥当なデフォルトを維持し、必要性を示す根拠がある項目だけを変更すると、更新やトラブル対処がしやすくなります。

クライアントと設定管理

継続して反映される設定の場所を確認する

GUIクライアントは通常、ノード情報、サブスクリプションのグループ、ルーティングテンプレート、画面上の設定を個別に保存し、現在の選択内容からカーネルの実行ファイルを生成します。これらは同じデータではありません。サブスクリプションの更新は主にリモートノード情報を変更し、ルーティングモードの切り替えは主にルールを変更します。システムプロキシはアプリからの接続入口に影響します。変更前に、要望がどの層に属するか確認しましょう。ブラウザーの入口を変えるためにリモートoutboundを編集したり、ルーティング変更のためにサブスクリプション全体を再インポートしたりする必要はありません。

v2rayNでは、通常の調整は対応するローカル待ち受け、ルーティング、カーネル設定の画面から行ってください。JSON全体をカスタマイズする必要がある場合は、クライアントのカスタム設定機能を使います。画面の種類によってメニュー名は異なる場合があるため、他のスクリーンショットにあるファイルパスをそのまま使わず、機能で確認しましょう。特に、実行中の一時設定だけを開いて変更するのは避けてください。ノードを選び直したり再起動したりすると、設定生成機能によってすぐに上書きされることがあります。

インポート、保存、実行はそれぞれ別の操作

クライアントがファイルを受け付けたという事実から分かるのは、形式やリンクを認識できたことだけかもしれません。該当する設定を選び、カーネルを起動し、実行ログを確認する必要があります。保存後に再読み込みしていなければ、プロセスは古い内容を使い続けている可能性があります。起動ログと実際の待ち受け情報を確認してください。設定一覧で名前が変わっただけでは、反映を確認したことにはなりません。生成設定をプレビューできるクライアントなら、起動前後の重要な項目を比べ、今回の実行で想定したinboundタグとoutbound参照が使われているか確認しましょう。

Androidでは、v2rayNGとv2flyNGがシステムの通信を取り込む際、通常はシステムの許可を得て仮想ネットワークの入口を作ります。対象アプリの選択やバックグラウンド実行の設定も、どの通信が取り込まれるかに影響します。デスクトップのシステムプロキシと同じ動作だと考えないでください。SOCKS inboundを手動で追加しても、クライアントのネットワーク取り込み機能の代わりにはなりません。逆に、システムの取り込みを有効にしても、カスタム設定のすべてのinboundがアプリに使われているとは限りません。

3つのクライアント間で移行する場合、移行できるノード情報と設定全体は分けて考えてください。共有リンクに含まれるのはノード情報であり、ローカルポート、DNS、ルーティングリソース、policyまで含まれるとは限りません。JSONの項目が移行先のカーネルで対応していても、クライアント側で特定のタグ、inbound、実行方法が必要な場合があります。移行後はノード一覧に表示されることだけでなく、inbound、デフォルトoutbound、DNS、ルールリソースを確認してください。

設定を安全に統合する手順

設定の断片を統合する場合は、現在動作している設定を基準にして、まずバックアップを作成し、設定項目を1つずつ丸ごと置き換えてください。配列には要素を追加し、オブジェクトにはフィールドを統合します。トップレベルのオブジェクトを2つ、そのまま貼り合わせることはできません。タグが重複する場合は、名前を変更してからすべての参照先を更新します。特に、ルーティングルールから新しいタグを参照する場合は、先に対応するoutboundが存在することを確認してください。出口がない状態でルールを有効にすると、設定の読み込み時点でカーネルが起動を拒否することがあります。

サブスクリプションURLやノードの認証情報は機密情報です。設定のコピーを保存する場合、スクリーンショットを提出する場合、他の人に相談する場合は、アドレスのアクセス用パラメーター、認証情報、サブスクリプションリンクを削除してください。ログにもサーバーアドレスやアクセス先が含まれる場合があるため、共有前に確認しましょう。この記事の例に含まれるのはローカルの入口とドキュメント用アドレスだけで、リモートサービスの情報ではありません。実際の認証情報はサービスの設定から取得し、公開ドキュメントに記載しないでください。

システムプロキシとカーネルの動作は分けて確認してください。カーネルが正常でも、システムプロキシが古いポートを指していればアプリは接続に失敗します。クライアント終了後もシステムプロキシが元に戻らないと、存在しない入口へ接続し続けることがあります。一方、システムプロキシを使わず、個別設定が必要なアプリもあります。「1つのアプリだけ接続できない」場合は、そのアプリの接続設定を先に確認し、カーネル設定全体をすぐに置き換えないでください。

クライアントを更新したりカーネルを切り替えたりした後は、元の設定を保存し、拡張項目と設定生成の動作を改めて確認してください。画面に古い項目が残っていても、新しいカーネルが以前と同じ意味で解釈するとは限りません。基本的な使い方はクイックスタートガイドをご覧ください。サブスクリプションについてはサブスクリプションの更新と自動更新の設定を確認し、取得の失敗とカーネルの転送エラーを混同しないようにしましょう。

設定の検証とログによるトラブル対処

設定の読み込み、待ち受け、接続の順に確認する

検証は、最初に失敗する段階から始めてください。第1段階はJSONを解析できるか、第2段階はカーネルが項目やタグを受け付けるか、第3段階はinboundが待ち受けるか、第4段階はアプリの通信が入ってくるか、最後にルーティング、名前解決、リモート接続を確認します。ログにポートのバインド失敗が出ているなら、DNSを変更しても意味はありません。カーネルが起動していない場合、ブラウザーの接続失敗からoutboundプロトコルの正否を判断することもできません。

まずクライアントのログ画面で、選択中のカーネルと今回の起動結果を確認し、最初に表示されたエラーを調べてください。その後に出る「プロセス終了」「接続拒否」は、先行するエラーの結果にすぎない場合があります。ログは時系列を保ち、起動時のエラーとアクセス時のエラーを区別しましょう。同じ画面に前回の実行記録が混在することもあります。変更後の新しい起動がどこから始まったか明確にし、古いエラーを修正未反映の証拠と取り違えないようにしてください。

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

接続の様子を確認する場合は、ログレベルを一時的にinfoに設定できます。さらに詳細なデバッグレベルは、必要なときに限って短時間だけ有効にしてください。ログ設定は既存のlogオブジェクトに統合し、重複して定義しないようにします。アクセスログやエラーログの出力方法はクライアントが管理している場合があるため、書き込み権限のないパスを安易に指定しないでください。トラブル対処が終わったら適切なレベルに戻し、アクセス先の記録や大量のファイル生成を抑えましょう。

エラーの種類から設定箇所を特定する

解析エラーの原因は、引用符、カンマ、括弧、データ型であることがよくあります。エディターが示す場所はエラーを検出した位置であり、原因の発生箇所とは限りません。直前の項目に区切りが抜けていないか、前に戻って確認してください。未知のプロトコル、フィールド、列挙値は、カーネルとの互換性の問題である可能性があります。まず現在のカーネルを確認しましょう。仕様で対応関係が明記されていない限り、似た名前の別項目に書き換えないでください。

待ち受けに失敗したら、ポートを別のプロセスが使っていないか、バインド先がこの端末のアドレスか、クライアントが同じinboundをすでに作成していないか確認してください。ルーティングの読み込みに失敗した場合は、参照先のタグが存在するか、リソースファイルを読み込めるか、カテゴリ名が正しいかを調べます。DNSの失敗では、問い合わせ先、サーバーへの到達性、フォールバック条件を確認してください。問題が起きている場所はそれぞれ異なります。クライアントをすぐ再インストールするより、種類ごとに対処するほうが原因を追いやすくなります。

再現可能で元に戻せるテストを行う

安定して起動できる基本設定を基準として保存し、inboundの拡張、プロキシoutbound、ルール、DNS、policyを1つずつ追加します。追加するたびに、起動を確認してから対応するテストを行ってください。直結の基準設定で検証できるのはローカルの入口と基本的なネットワーク接続までで、リモートノードの動作は確認できません。プロキシ経由のアクセスに成功しても、デフォルトoutboundを使った可能性があるため、ルールが正しいとは限りません。テストの結論は、実際に確認した範囲に限定しましょう。

変更した項目、想定した結果、実際のログ、元に戻す方法を毎回記録してください。ルーティングのテストには、ドメイン名と直接IPの両方を含めます。DNSのテストでは、アドレスファミリーとキャッシュを区別します。policyのテストでは、接続確立とアイドル状態を分けて確認してください。期待した結果にならなければ、まず直前の基準設定に戻し、変更によって問題が発生したことを確かめてから、対象を絞り込みます。すでに壊れた設定に修正を重ねていくのは避けましょう。

設定ファイルは、役割の明確な項目を組み合わせたものです。長ければ機能が充実しているとは限りません。用途を説明できる項目を残し、不要と確認できた試験設定は削除します。クライアントが生成する設定は、適切な画面から管理してください。よくある症状はよくある質問をご覧ください。起動エラーの読み方はカーネルの起動失敗とログの確認方法で解説しています。トラブル対処が終わったら、最終的に動作する設定を保存してから通常の利用に戻りましょう。