REFERENCE CATALOGUE
JSONで設定を理解
4つのOS
3つのクライアント
JSONは設定構造を理解するための共通の手がかりですが、同じファイルを異なるカーネルでそのまま使えるとは限りません。クライアント、カーネル、プロトコルにはそれぞれ適用範囲があります。同じ項目名でも、値とバージョンごとのドキュメントを確認してください。
初めて使う場合は、まずGUIからサブスクリプションとシステムプロキシを設定できます。ドメインごとの振り分け、ローカルの待ち受け、名前解決を調整する際は、生成された設定をフィールドガイドと照らし合わせてください。実行設定全体を通常のサブスクリプションURLとして読み込んだり、クライアントのバックアップファイルをカーネル設定として扱ったりしないでください。
JSONガイドを見る →
ルーティングルールは上から順に適用
ルーティングが処理するのは、すでにカーネルに届いたトラフィックです。まず出力先に明確なタグを設定し、ドメイン、アドレス、ポートでルールを照合して振り分けます。複数のルールが重なる場合は、対象範囲の狭い例外を先に配置しましょう。システムプロキシが影響するのは、その設定に従うアプリだけで、ルーティングルールの代わりにはなりません。接続先が意図と異なる場合は、まず適用されたルールを確認し、次にデフォルトの出力先と名前解決の方針を見直してください。サーバーを一つずつ切り替えるより、ルールによる振り分けなら通信経路を一定に保てますが、ルールデータの管理は必要です。
- domainStrategy
- AsIs
- rules[].type
- field
- rules[].outboundTag
- direct
サブスクリプションURLとサーバー設定を分けて管理
サブスクリプションを追加すると、URLからサーバー情報を取得できます。定期的に同期する設定の管理に便利です。まずグループを作成してサブスクリプションURLを保存し、更新を実行します。サーバー一覧に項目が表示されたことを確認してから、使用するサーバーを選択してください。更新に失敗した場合は、URLの期限切れ、応答内容の形式違い、接続エラーを切り分けましょう。同じURLを繰り返し追加しても解決しません。通常、サブスクリプションが更新するのはサーバー情報で、すべてのローカル設定を一元管理するわけではありません。待ち受けポート、システムプロキシ、カスタムルーティングは個別に確認してください。サブスクリプションURLにはアクセス権限が含まれるため、公開しないでください。
- outbounds[].protocol
- サブスクリプション項目から生成
- outbounds[].tag
- ルーティングから参照
プロトコル名だけでカーネルの互換性は判断できない
クライアント画面にプロトコルの種類が表示されていても、実行中のカーネルがその設定項目をすべてサポートしているとは限りません。プロトコル、トランスポート方式、セキュリティ層、カーネルの対応状況をあわせて確認してください。特定のセキュリティ機能を使う設定は特に注意が必要です。v2rayNGは主にXrayカーネルを、v2flyNGはV2Flyカーネルを使用します。デスクトップ版の動作は、選択中のカーネルと設定によって異なります。サーバー名だけでなく設定項目の構造を確認すると、追加には成功しても接続できない原因を特定しやすくなります。カーネルを切り替える前に元の設定を保存し、互換性の問題をネットワークの問題と取り違えないようにしましょう。
- outbounds[].protocol
- vless / vmess / trojan
- streamSettings.security
- tls / reality
ローカル待ち受けはアプリからカーネルへの入口
受信設定では、ローカルの待ち受けアドレス、ポート、接続を受け付けるプロトコルを指定します。自分の端末だけで使う場合は、ループバックアドレスを維持するのが基本です。LAN内からアクセスさせる場合は、ファイアウォールとアクセス制御もあわせて設定してください。トラフィック識別を使うと、一部の接続に宛先ドメイン情報を補い、ルーティングの照合に役立てられますが、ドメイン名前解決の設定を置き換えるものではありません。システムプロキシとは異なり、受信設定はカーネルが接続を受け付ける層の設定です。ポートが使用中だとクライアント画面が開いていても、入口が作成されないことがあります。待ち受けポートを変更したら、そのポートを手動設定しているアプリも更新してください。
- listen
- 127.0.0.1
- sniffing.enabled
- true
- sniffing.destOverride
- ["http", "tls"]
名前解決の設定とルーティング方針をあわせて確認
DNS設定では、カーネルがドメイン名をどのように問い合わせるかを指定します。一方、アプリやOSが別の名前解決経路を使う場合もあります。名前解決に失敗したら、まずリクエストの送信元を特定し、DNSサーバーに到達できるか、現在のネットワークに適した問い合わせ方針かを確認しましょう。ルーティングのドメイン判定では、照合時に名前解決を試みるかどうかが影響します。また、出力先での宛先解決には別の設定がある場合もあります。DNSサーバーのアドレスを一つ変更しただけで、すべての通信経路が変わったと判断しないでください。IPアドレスへ直接接続する場合と比べ、ドメイン名を保持すればドメインルールを適用しやすくなります。どの方法を使うかは、実際の設定とカーネルの動作に応じて判断してください。
- dns.queryStrategy
- UseIP
- routing.domainStrategy
- AsIs
セキュリティ層の設定をサーバー側と合わせる
トランスポート方式、セキュリティ層、サーバー認証はそれぞれ異なる設定項目です。TLSを使う場合は、サーバー名、証明書チェーン、システム時刻を確認してください。REALITYを使う場合は、サーバー側の情報に従って必要な値を設定します。TLSの設定例をそのまま流用しないでください。証明書エラーが発生したら、まず具体的なエラー内容を記録し、名前と時刻を確認しましょう。検証を無効にする方法を通常の解決策にしないでください。プロトコル名だけを変更するより、トランスポート関連の項目を一つずつ照合するほうが設定の不一致を見つけやすくなります。対処後はログを確認し、想定した設定が実際に使われているかを確かめてください。
- tlsSettings.allowInsecure
- false
- streamSettings.security
- tls
- tlsSettings.serverName
- サーバー証明書の名前と一致させる