v2rayN
高度な設定ガイド

サブスクリプションのグループ分けとサーバーの絞り込み

グループ分けはサブスクリプションの提供元を整理し、サーバーの絞り込みは一覧を検索しやすくします。どちらもサーバー側の接続品質を自動で改善するものではなく、ルーティングの代わりにもなりません。まずサブスクリプションURLを1つの分かりやすい名前のグループに登録します。更新後、そのグループにサーバーが表示されることを確認してから絞り込み条件を追加してください。グループの新規作成、URLの変更、正規表現の有効化を同時に行うと、一覧が空になった際に原因を特定しにくくなります。

グループを作成して更新先を明確にする

v2rayNのサブスクリプショングループ設定でグループを追加し、分かりやすいメモとサブスクリプションURLを入力して保存したら、メイン画面に戻ります。対象のグループを選択してからサブスクリプションを更新してください。URLは提供元のパスとクエリパラメーターを含めて、そのまま保持します。チャットアプリからコピーした際に引用符、改行、末尾の句点が混入しないよう注意してください。サブスクリプションURLには通常、アクセス用の認証情報が含まれています。URL全体をスクリーンショットやログ、公開の場に貼り付けないでください。

更新方法の「プロキシ経由」と「プロキシを経由しない」は、サブスクリプション取得時のリクエスト経路だけを指定します。更新で追加されるすべてのサーバーのルーティングを指定するものではありません。現在のプロキシが接続できない状態でプロキシ経由の更新を強制すると、接続に必要な設定を取得するために接続が必要になるという依存関係が生じます。まず到達可能な経路で更新し、設定を取り込んだ後に今後の更新方法を見直してください。

保存後は、グループのメモが正しいか、サブスクリプションURLが完全な状態か、更新ログに有効な内容を解析した記録があるかの3点を確認します。リクエストが成功しても一覧に変化がない場合、必ずしもクライアントの問題とは限りません。提供元が同じ内容を返している場合や、ログインページ、説明文が返されている場合もあります。処理完了の表示だけで判断せず、解析結果と対象グループも確認してください。必要なら一時的に絞り込みを解除して再確認します。

簡単なキーワードから正規表現を作成する

「サーバーの絞り込み（正規表現）」は通常、サーバーのメモを対象に照合します。インポート時と一覧表示時のどちらに適用されるかは、現在の画面の説明を確認してください。まず実在する名前の一部でテストし、動作を確認してから複数の候補に広げます。最初から複雑な除外パターンを作らないでください。正規表現の縦棒は「または」、丸括弧はグループ化、角括弧は文字クラスを表します。いずれも通常の文字をつなぐ記号ではありません。

香港|日本
^(香港|日本)
香港.*専用線
\[予備\]

上記はそれぞれ独立した例です。同じ入力欄にまとめて貼り付けないでください。1行目はどちらかのキーワードを含むメモ、2行目は指定したキーワードで始まるメモ、3行目は2つの文字列が順に含まれるメモ、4行目は角括弧付きの文字列に一致します。提供元が別の略称を使っている場合、これらの式では結果が出ないことがあります。実際のメモを基準に条件を作成してください。地域名をすべてのサブスクリプションに共通するルールとして扱わないでください。

入力に誤りがある場合は、まず正規表現を消して保存し、サーバーが再表示されることを確認してから少しずつ戻します。ピリオド、括弧、プラス記号などを文字そのものとして照合する場合、これらが特別な意味を持つ点に注意してください。たとえば、文字としてのピリオドは通常 \. と記述します。クライアントのビルドによって正規表現の実装が異なる場合があり、特に後読み・先読み、インラインオプション、複雑なグループで差が生じることがあります。移植しにくい高度な構文より、短く意味の分かる式を使う方が安全です。

絞り込みの誤りと更新失敗を切り分ける

絞り込み後にサーバーが見えない場合は、「すべて」または該当する提供元グループに戻し、検索欄を空にしてグループの絞り込み設定を確認します。メイン画面の検索とサブスクリプション設定の絞り込みが重なっていることがあり、片方だけ変更しても表示が戻るとは限りません。原因が絞り込みだと確認してから、残す条件を決めてください。一覧を戻すためにグループ全体を何度も削除すると、メモや更新方法などの設定も失われるおそれがあります。

更新に失敗した場合は、URLの有効性、リクエスト経路、応答内容、解析形式の順に確認します。同じURLがあるネットワーク経路では取得でき、別の経路では失敗する場合は、まず接続とDNSを調べてください。取得内容がサブスクリプションではなくWebページの場合は、URLの用途と認証状態を確認します。インポート済みのサーバーが引き続き使えるなら、既存の設定を残してください。更新失敗を、すべての接続が使えなくなる問題に広げないようにします。

ルーティング設定の実例

ルーティングの基本は、ルールを順番に照合することです。コアが接続先や利用可能なメタデータを確認し、最初に一致したルールのアウトバウンドを選択します。通常、具体的なルールは広い範囲を対象とするルールより前に配置します。設定を変更する前に、現在有効なルーティングプリセットと、クライアントが起動時にコア設定を再生成するかを確認してください。一時生成ファイルだけを変更しても、サーバーの切り替えやコアの再起動で上書きされることがあり、永続的な設定にはなりません。

アウトバウンドのタグを確認してから条件を設定する

以下はXrayの routing オブジェクト形式の例です。広告ドメインのブロック、プライベートアドレスへの直接接続、指定ドメイン群への直接接続を示しています。完全な設定に direct と block という名前のアウトバウンドが定義されていることを前提とします。クライアントが実際に生成するタグが異なる場合は、同じタグに修正してください。タグは正確に参照する識別子であり、意味を自動認識する予約済みの日本語名ではありません。このオブジェクトを、ルール配列だけを受け付ける入力欄に貼り付けないでください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

通常、1つのルールに異なる種類の条件を指定すると、すべての条件を満たす必要があります。同じ配列内の複数の候補は、いずれかに一致すればよい条件として扱われます。たとえば domain と port を同時に指定すると、特定のドメインで、かつポートも条件に合う接続を表します。どちらか一方に一致すればよいという意味ではありません。ドメインまたはアドレス範囲のどちらかで一致させたい場合は、ルールを分けてください。分割後は、前の広範な条件が先に接続を処理しないよう、順序も確認します。

どのルールにも一致しない通信の処理方法は、コアのデフォルト動作とクライアントが生成する完全な設定によって異なります。上記の断片だけから最終的にプロキシ経由になるとは判断できません。Xrayでは通常、未一致の通信は最初のアウトバウンドで処理されますが、GUIクライアントがフォールバックルールを追加する場合もあります。最終設定のアウトバウンド順と末尾のルールを確認してから、デフォルト経路を明示するか決めてください。設定を確認するときは、追加した数行だけでなく、先頭から末尾まで確認します。

ドメイン、IPアドレス、ルールデータの関係を理解する

geosite はドメインの分類、geoip はIPアドレスの分類です。コアが対応するデータファイルを読み込めることと、そのファイルに該当する分類名が含まれていることが必要です。ファイルが存在していても、すべての配布元に同じ分類が含まれているとは限りません。もっともらしい分類名を入力しても、自動的に分類が作成されるわけではありません。分類の読み込みに失敗した場合は、データファイルの配布元、保存場所、コアのログを確認してください。ルールデータのエラーを解決するためにサーバーを何度も切り替える必要はありません。

domainStrategy は、ルーティング判定の際にドメインのIP情報を補完するかどうかを決めます。AsIs は、IPルールのためだけにドメインを積極的に名前解決しません。IPIfNonMatch は、ドメインルールに一致しない場合に名前解決を試みます。IPOnDemand は、IPが必要な照合時に名前解決を行うことがあります。設定によって問い合わせのタイミングや負荷は変わりますが、接続に使うDNSサーバーを直接指定するものではありません。

アプリがIPアドレスだけをプロキシに渡す場合、コアが元のドメイン名を把握できず、ドメインルールの照合に必要な情報がないことがあります。一部の通信ではスニッフィングでドメイン名を補えますが、暗号化された通信の情報をすべて復元できるわけではなく、あらゆるプロトコルを識別できるとは限りません。同じWebサイトでもアプリによって経路が異なる場合は、まずインバウンドに届くのがドメイン名かIPアドレスかを確認し、次にスニッフィングとDNSの経路を調べてください。いきなり直結やプロキシの対象を広げないようにします。

判断しやすいテストケースでルールを確認する

検証には、ルールに明記したドメイン、プライベートアドレスの接続先、どのルールにも一致しない接続先を1つずつ選び、新しい接続を作成します。ログに表示される接続先とアウトバウンドタグを確認し、想定した順にルールが適用されることを確かめてください。ブラウザーが既存の接続を再利用する場合、ルールを変更しても更新だけでは経路が変わらないことがあります。関連する接続を閉じるかテストアプリを再起動してから比較してください。ルールを読み込めたことと実際の通信が成功することは別々に確認します。

あるルールが他のルールに意図せず優先される場合は、最も広い条件を一時的に外し、最小限のルールで動作を確認します。ポート、ネットワーク種別、プロセスのルールも判断に影響します。特にクライアント生成のルールとカスタムルールが併存する場合は注意してください。データファイルの更新方法や分類の記述はgeoip.dat と geosite.dat のルーティングデータベース解説をご覧ください。更新の前後で同じテストケースを使って再確認します。

DNS設定の最適化

DNS設定では、まず「どこから問い合わせるか」「どこへ送るか」「誰が結果を使うか」を確認します。システムのリゾルバー、ブラウザーのセキュアDNS、クライアント内蔵DNS、ルーティング判定用にコアが行う名前解決が、同時に使われる場合があります。クライアントにDNSサーバーを1つ設定しただけで、すべてのアプリの名前解決経路が統一されるとは限りません。目指すのは、経路の一貫性、使える結果、原因を追える状態です。設定項目をすべて有効にすることではありません。

DNSサーバーと問い合わせの出口を区別する

以下はXrayの dns オブジェクトの例で、サーバー一覧と問い合わせの種類を示しています。queryStrategy は内蔵DNSの問い合わせで必要とするアドレス種別を制御するもので、システム全体のIPv6を無効にする設定ではありません。暗号化DNSのエンドポイントもテスト用の選択肢の一つです。現在のネットワークから到達できることを確認してから利用してください。この断片にはDNS通信のルーティング設定がないため、問い合わせが必ずプロキシ経由になるとは判断できません。

{
  "dns": {
    "servers": [
      "https://1.1.1.1/dns-query"
    ],
    "queryStrategy": "UseIP"
  }
}

DNSサーバーのアドレスを指定することと、問い合わせの出口を指定することは別です。コアによっては暗号化DNSのリクエストを内部ルーティングできますが、サーバー形式によってはローカル接続を直接使う場合があります。クライアントの画面に、直結DNS、リモートDNS、独立したアウトバウンドなどの設定があることもあります。こうした名称はクライアント独自の実装を表すもので、別のコアの設定項目に機械的に対応させることはできません。まず使用するコアを確認し、対応するドキュメントに沿って最終設定を解釈してください。

ドメイン名で指定する暗号化DNSエンドポイントには、ブートストラップの名前解決も必要です。DNSサービスに接続する前に、そのサービスのアドレスを知る必要があります。ブートストラップがまだ確立していないプロキシに依存すると、循環依存が起きることがあります。固定のサービスアドレス、明確なブートストラップ経路、クライアントが提供する起動時の名前解決機能などで対処できます。用途が不明確なDNSサーバーを複数追加するのではなく、仕組みを説明できる方法を選んでください。

接続経路に合わせて名前解決の方針を決める

直結先には、現在のネットワークから到達できるアドレスを取得する必要があります。プロキシ経由の接続先も、プロキシの接続方法と整合するように名前解決してください。プロトコルによっては、ドメイン名をサーバーに渡して名前解決するため、ローカルDNSはルール判定だけに使われます。別の経路ではローカルで名前解決してから接続します。ルーティング判定に使う結果と、実際の接続に使う結果が異なると、想定した振り分けと実際のアクセスが一致しないことがあります。ドメイン名がどのように保持されるかも確認してください。

IPv6に関する問題がある場合は、まずネットワークに利用可能なIPv6経路があるか確認し、そのうえでアドレスの優先順位を決めます。AAAAレコードが返ること自体はエラーではありません。アプリが到達できないアドレスを選ぶと、待ち状態やフォールバックとして現れます。一時的にIPv4だけを問い合わせる方法は比較テストには使えますが、すべてのネットワークで常に有効な解決策ではありません。プロキシサーバー、直結経路、TUNでIPv6の方針が整合しているかも確認してください。

ブラウザーで独自のセキュアDNSを有効にすると、システムの通常の名前解決設定を経由しない場合があります。アプリが確立済みの暗号化接続を使って問い合わせる場合も、通常のDNSポートを使う通信として現れるとは限りません。トラブルシューティングでは、まずこれらの設定を記録してから、一時的に名前解決の入口を統一します。クライアント側の経路が正常だと確認した後、アプリの設定を一つずつ戻して変化を比較してください。システムのネットワーク設定を一度にすべて消去すると、アクセスが復旧してもどの変更が有効だったか分からなくなります。

「名前解決できる・接続できる・経路が正しい」を確認する

まずログで問い合わせが想定したDNSサーバーに届いたことを確認し、次に利用可能なアドレスが返ったか、最後に接続が目的のアウトバウンドを通ったかを検証します。コマンドラインで取得したシステムの名前解決結果が示すのはシステムの経路だけです。ブラウザー内部やコア内部のDNSまで確認できるわけではありません。診断記録には、テストしたアプリ、対象ドメイン、プロキシモード、テスト日時を記載し、異なる経路で得たアドレスを混同しないようにしてください。

DNSを変更した後も、古いキャッシュや接続プールに以前の結果が残ることがあります。テストアプリを終了して該当するキャッシュを消去し、必要であればクライアントのコアを再起動してから、同じ接続先を再テストしてください。一部のドメインだけ失敗する場合は、まずドメインルールとDNS応答を確認します。すべてのドメインで失敗しIPアドレスへの接続は可能な場合は、DNSサーバーへの到達性とブートストラップ経路を調べてください。通常の接続が安定するまでは、FakeDNSを追加しないでください。

TUNモード

TUNは仮想ネットワークインターフェースを通じて、システムルーティングから送られたIP通信を受け取り、クライアントに関連付けられたコンポーネントで処理します。アプリがプロキシ設定に従う必要があるシステムプロキシとは異なり、TUNはネットワーク層に近い位置で動作します。ただし、接続が実際に取り込まれるかどうかは、ルーティング、除外設定、アドレスファミリー、実行権限によって決まります。「Tunを有効にする」スイッチがオンになっても、すべての通信が想定どおり処理されているとは限りません。

通常の接続を確認してから取り込み範囲を広げる

TUNを有効にする前にオフにし、通常のシステムプロキシで正常にアクセスできることを確認します。選択したサーバーと基本的なプロトコル設定も確認してください。その後、現在のルーティングプリセット、システムDNS、他のネットワークツールの状態を記録します。デスクトップクライアントでは、TUNに別のコンポーネントや異なる設定構造を使う場合があります。メイン接続にXrayを使っているからといって、Xrayのルーティング項目を別コンポーネントのTUN設定にそのまま入力しないでください。クライアントの画面が対応している設定項目を起点にします。

初めて有効にするときは、システムの案内に従って必要な権限を許可し、仮想インターフェースとルートの設定が完了してからテストアプリを起動してください。スイッチをすばやく何度も切り替えないでください。起動に失敗した直後に再度有効にすると、古いプロセスやインターフェースの状態が判断に影響する場合があります。まずログで権限不足、インターフェースの作成失敗、アドレスの競合を確認してから再試行してください。ドライバーやシステムサービスを使う場合、画面を閉じてもバックグラウンドのコンポーネントが停止したとは限りません。

ループバックを避け、LANへのアクセスを確保する

システム通信を取り込む場合、プロキシサーバーへの外側の接続がネットワークに正しく到達できる必要があります。取り込みルールによって自分自身に繰り返し送り返されてはいけません。クライアントが通常、サーバーアドレスの除外、プロセス除外、インターフェースのバインドなどを処理しますが、カスタムルーティングや多段プロキシで保護が崩れる場合があります。TUNを有効にした直後にすべての接続が止まった場合は、ノードの設定が変わったかを調べる前に、外側の接続がループしていないか確認してください。

LAN内のサービスは個別に確認する必要があります。プリンター、ルーターの管理画面、ローカル開発サーバーはプライベートアドレスを使う場合があり、LAN内の名前解決でアドレスを取得することもあります。プライベートアドレスを直結にするだけでは、ローカル名の検出問題が解決しない場合があります。関連するDNS問い合わせ、ブロードキャスト、マルチキャストが現在の実装で取り込まれているかも確認してください。LAN内の機器1台にアクセスするためだけに、すべてのネットワーク範囲を広く除外しないでください。必要な範囲を優先して設定します。

「LANからの接続を許可」とTUNは別の設定です。前者は通常、プロキシの待ち受けアドレスと、他の端末が本機のポートに接続できるかを制御します。後者は本機の通信を取り込むかどうかを制御します。他の端末から本機のプロキシを利用する必要がなければ、待ち受け範囲を広げる必要はありません。利用する場合は、ファイアウォール、認証設定、信頼できるネットワークの範囲を確認し、不要なネットワークインターフェースにプロキシポートを公開しないようにしてください。

UDPを正常に利用するには、アプリの通信が取り込み対象であること、クライアントの関連コンポーネントが対応していること、使用するプロトコルとサーバー側の経路がUDPをサポートしていることなど、複数の条件を満たす必要があります。リアルタイム通信が失敗しても、DNSだけが原因とは限りません。UDP転送、宛先ポート、経路の制限も考えられます。まず通常のWeb接続で基本経路を確認し、実際に利用するアプリでUDPを検証してください。TCPだけのテストが成功しても、すべての通信が正常だとは判断できません。

競合を特定し、段階的に元へ戻す

他のVPN、仮想マシンやコンテナのネットワーク、企業向けネットワークツールが同時にルートやDNSを書き換えることがあります。トラブルシューティングでは、一度に有効にする通信取り込みツールを1つにしてください。ソフトウェアをアンインストールするのではなく、まず他の取り込み機能を停止します。インターフェースの有効・無効に合わせて問題が発生するか観察し、インターフェースとネットワーク範囲の関係を記録してください。スリープからの復帰、Wi-Fiの切り替え、有線接続の開始後に動作しなくなる場合は、出口インターフェースが正しく再選択されるかも確認します。

元に戻す場合は、まずTUNをオフにし、バックグラウンドのコンポーネントが停止したことを確認してから、システムプロキシ、DNS、デフォルトルートが想定どおりに戻ったか確認します。通常のネットワークがまだ使えない場合は、記録しておいた元の値に合わせてシステムのネットワーク設定を戻してください。ネットワーク全体のリセットを最初に試さないでください。macOSの権限に関する問題はインストールの許可とネットワーク権限の設定手順を参照してください。Androidでバックグラウンド通信が中断される場合は、アプリの省電力設定を別途確認します。

FakeDNS

FakeDNSは実際の名前解決結果の代わりに合成アドレスを返し、「合成アドレスとドメイン名」の対応を保存します。アプリが合成アドレスへ接続すると、コアは対応情報からドメイン名を復元し、ルーティングやプロキシ処理を行います。目的はドメイン名との関連を保ち、事前の名前解決が必要な場面を減らすことです。公共ネットワークでそのまま接続できる実サーバーのアドレスを提供する機能ではありません。この仕組みを理解すると、通信の取り込みを迂回した際に接続がすぐ失敗する理由を判断できます。

DNSと接続が同じ経路で処理されることを確認する

FakeDNSを利用するには、合成応答を返すコンポーネントと、その後の接続を処理するコンポーネントが対応情報を共有できる必要があります。DNSを一方のコンポーネントが処理し、その後の接続を対応情報を知らない別のコンポーネントに渡すと、接続できない合成アドレスだけが残ります。デスクトップクライアントはモードごとに異なるコアを使う場合があるため、切り替える前に実装を確認してください。どちらもFakeDNSという名前だからといって、設定形式や対応情報の有効期間が同じとは限りません。

以下はXray関連の設定例です。アドレスプールを定義し、内蔵DNSでFakeDNSを使い、指定したインバウンドで対応するスニッフィングのオーバーライドを有効にします。3つの部分はそれぞれ、完全な設定の該当する階層に統合してください。特にインバウンドの設定例でインバウンド全体を置き換えないでください。待ち受けアドレス、ポート、プロトコルなど既存の項目を保持する必要があります。これらの項目は、関連する設定経路がつながって初めて連携して動作します。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  }
}

対応するインバウンドのスニッフィング設定例：

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"]
  }
}

ipPool は合成アドレスプールを指定し、poolSize は対応情報の容量を制限します。例のアドレス範囲はテスト用であり、通常のインターネット上の接続先として直結しないでください。設定前に、仮想マシン、検証環境、社内ネットワークですでに同じ範囲が使われていないか確認します。競合がある場合は、利用するコアが対応する範囲から別の案を選び、取り込みルートも合わせて確認してください。アドレスプールの文字列だけ変更して終わりにしないでください。

キャッシュ、対応情報の消失、アプリの互換性への対処

対応情報は通常、実行中のコアの状態に依存します。コアを再起動した後、アプリに古い合成アドレスがキャッシュされている一方、新しいコアには元のドメイン名との対応情報がないことがあります。再起動後に一部のアプリが失敗し、キャッシュを消去すると復旧する場合は、この状態が考えられます。FakeDNSを有効・無効にする際は、システムの名前解決キャッシュ、ブラウザーのキャッシュ、長時間接続も考慮してください。テストアプリを順番に再起動し、古いキャッシュをルールの誤りと混同しないようにします。

一部のアプリはアドレスの種類を独自に検証したり、名前解決の結果を保存したり、別のプロセスにアドレスを渡したりします。こうした処理で合成アドレスとの互換性に問題が生じることがあります。LAN内の名前、機器の検出、IPアドレスを直接使う一部の通信は、すべてFakeDNSの対象にするのに適さない場合があります。特定のアプリだけに問題がある場合は、まず通常の名前解決と比較してから、ドメインやアプリを除外するか検討してください。除外設定の場所と構文は、実際に使っているDNSコンポーネントに合わせます。

ルールで合成アドレスの範囲をシステムネットワークへ直接除外すると、ドメイン名を復元する前に通信が取り込み経路から外れる場合があります。一方、合成アドレスだけに「プロキシ」ルールを追加しても正しいとは限りません。コアがルールの照合前に元のドメイン名を復元することがあるためです。ログの最終的な接続先を確認し、現在の実装が復元と照合のどちらを先に行うかを把握してからルールを調整してください。実アドレスの振り分け方を合成アドレスにそのまま適用しないでください。

有効・無効を切り替えて効果と制約を比較する

比較テストではサーバー、ルーティングプリセット、テストアプリを変えず、FakeDNSだけを切り替えます。対象ドメインに合成アドレスが返ることを確認し、その後の接続でドメイン名が復元され、最終的なアウトバウンドがルールどおりになるか観察してください。合成アドレスが確認できない場合は、アプリが対象のDNSを迂回している可能性があります。合成アドレスが返るのに接続できない場合は、DNSサーバーを次々に変更するのではなく、取り込み範囲、対応情報、インバウンドの復元機能を確認します。

無効にする場合は、まずアプリが新しい接続を開始しない状態にしてから関連機能をオフにし、古いキャッシュを消去します。その後、通常の名前解決で接続を確認してください。FakeDNSはどの設定にも必須ではありません。通常のDNSとルーティングで要件を満たせるなら、そのまま使い続けてください。ドメイン名との関連付けが明確に必要で、通信を取り込む経路全体を維持できる場合にのみ導入します。原因が分かりにくい問題が起きたら、通常の名前解決に戻すことが有効な最初の比較テストになります。

複数サブスクリプションの管理

複数サブスクリプションの管理で大切なのは、すべての提供元を1つの一覧にまとめることではなく、提供元、更新経路、用途の対応関係を保つことです。提供元ごとにグループを分け、メモで用途を記録する方法がおすすめです。仕事用、自宅用、テスト用など独自の命名規則を設けてもかまいませんが、パスワード、アカウント名、サブスクリプションURL全体をグループ名に含めないでください。グループのメモは、インポート直後だけでなく時間がたってからも設定内容を理解できるものにします。

提供元の記録と更新頻度を決める

各グループには、用途、更新方法、絞り込み条件を最低限記録します。記録は自分の端末に保存すれば十分です。自動更新の間隔は実際の必要性と提供元の制限に合わせてください。一覧を「最新に見せる」ために頻繁にリクエストする必要はありません。更新回数を増やしてもサブスクリプションの内容が改善するわけではなく、連続したリクエストで制限されるおそれもあります。更新に失敗した場合は、最後に使えた設定を残して該当グループの問題を調べ、すべての提供元を一度に変更しないでください。

最初に整理するときは、各グループを個別に更新し、それぞれ独立して取得・解析できることを確認してから一括更新を検討します。どのURLが無効なのか、どのグループでリクエスト経路を変える必要があるのかを特定しやすくなります。一括更新の一部だけ失敗した場合は、失敗したグループの応答と認証状態を先に確認してください。すぐに全体のDNSやプロキシモードを変更しないでください。全体設定の変更は、正常なグループにも影響し、問題の範囲を広げることがあります。

同じ提供元が複数形式のURLを用意している場合、見た目だけでは返される内容が同じかどうか判断できません。クライアントと互換性のあるURLを選び、必要なパラメーターを維持してください。Web管理画面のURLとサブスクリプションURLを混同しないようにします。ログインが必要なURLや有効期限切れのURLは、クライアントで再試行しても認証を修復できません。その場合は提供元の正規の管理画面から有効なURLを取得してください。クライアント内でパスを推測して組み立てないでください。

名前の重複、設定の重複、現在の選択を区別する

サーバーのメモは一意な識別子ではありません。異なる提供元が同じメモを使っていても接続先は異なる場合があり、同じサーバーでもメモが変わると新しい項目のように見えることがあります。重複を判断するときは、名前だけで削除せず、プロトコル、アドレス、ポート、認証パラメーターを端末内で比較してください。クライアント独自の重複判定が使われる場合もあります。実行前に対象範囲を確認し、必要なら現在の設定をエクスポートして誤削除に備えます。

サブスクリプションを更新すると、サーバー項目が置き換わったり、順序やメモが変わったりすることがあります。現在選択中の項目が維持されるかどうかは、クライアントが新旧の設定をどのように関連付けるかによって異なり、常に同じだとは限りません。大規模な更新の後は、普段使う前に現在のグループと選択中のサーバーを確認してください。元の項目が提供元から削除されていた場合は、現在使える別の項目を選びます。一覧の同じ位置にあることだけで接続先が変わっていないと判断しないでください。

サブスクリプション内の項目は通常、提供元が管理しています。手動で設定を変更しても次回の更新時に上書きされることがあります。長期的に維持したいカスタム設定は、手動管理専用のグループに分け、変更理由を記録してください。用途を明記せず同じサーバーを複数のグループに複製すると、問題の調査時に別の項目を変更するおそれがあります。複雑なメモを書くことより、設定の提供元を明確にする方が重要です。

移行、バックアップ、プライバシーの保護

別の端末に移行する前に、クライアント設定、サブスクリプション情報、個別サーバー設定のどれを移すのか確認します。エクスポート方法によって含まれる情報は異なり、QRコードや共有リンクに接続情報全体が含まれることもあります。信頼できる経路だけで転送し、作業後は不要な一時ファイルを削除してください。公開の場で相談する際は、エクスポートファイル全体ではなく、必要な部分だけに編集した設定情報を使います。ログに含まれるサブスクリプションのパスやクエリパラメーターも削除してください。

デスクトップ版v2rayNとAndroid版v2rayNG、v2flyNGは互換性のあるサブスクリプションをインポートできますが、GUIのグループ設定、ルーティングプリセット、アプリごとの対象範囲は必ずしも一緒に移行されません。特にカスタムルーティングとDNSは、移行先のコアに合わせて設定し直し、動作を確認してください。インストーラーはクライアントのインストーラーページから選べます。旧端末のファイル名だけで移行先のアーキテクチャを判断しないでください。

Androidのバックグラウンドで接続が切れる原因は、複数サブスクリプションの競合ではなく省電力制限の場合もあります。まずアプリを前面で実行した状態で接続できることを確認し、次にVPN権限、アプリごとの対象範囲、バックグラウンド制限を調べてください。手順はv2rayNGのアプリ別プロキシ設定と省電力対象外の設定をご覧ください。定期的に無効になった提供元を削除し、必要な記録を残すことで、実際の用途に合った一覧を維持できます。

カスタムアウトバウンド

カスタムアウトバウンドは、指定した接続先をローカルの別プロキシ待ち受けに渡すなど、クライアントの通常の画面では設定できない接続経路を表します。アウトバウンドのプロトコル、タグ参照、待ち受けへの到達性、ループ防止が関係するため、ルールを1つ追加するだけではありません。設定を編集する前に「アプリがどのインバウンドに入るか」「ルールがどのタグを選ぶか」「そのタグがどこに接続するか」を整理してください。通常のプロキシ経路を理解するまでは、複数のカスタム転送を重ねないことをおすすめします。

ローカルSOCKSアウトバウンドで最小構成を作る

以下はXray形式のアウトバウンドオブジェクト3つです。直結、ブロック、ローカルのSOCKSサービスへの接続をそれぞれ示しています。完全な設定の outbounds 配列に統合してください。既存の配列をそのまま置き換えると、現在のサーバー用アウトバウンドが削除されたり、デフォルトの順序が変わったりするおそれがあります。ローカルアドレスは接続先を示すだけです。ポートを実際に動作しているサービスに合わせてください。対応するサービスが待ち受けていなければ、設定を読み込めても転送はできません。

[
  {
    "tag": "direct",
    "protocol": "freedom",
    "settings": {}
  },
  {
    "tag": "block",
    "protocol": "blackhole",
    "settings": {}
  },
  {
    "tag": "local-socks",
    "protocol": "socks",
    "settings": {
      "servers": [
        {
          "address": "127.0.0.1",
          "port": 1080
        }
      ]
    }
  }
]

この例では認証を設定していません。接続先の待ち受けが想定どおり接続を許可する場合にのみ使用してください。実際のサービスに認証が必要な場合は、コアが対応するユーザー情報の項目を使い、認証情報は端末内だけに保存します。設定の手間を省くために待ち受け範囲を広げたり、既存の認証を無効にしたりしないでください。ループバックアドレスはコアが動作する同じネットワーク環境を指します。コアがコンテナや隔離環境内で動作している場合、ホスト上のサービスを指すとは限りません。

アウトバウンドを準備してから、最も具体的なテストルールを追加します。以下ではタグ参照を説明するために予約済みの例示用ドメインを使っています。このドメインが実際のサービスを提供する必要はありません。実際に検証するときは、自分が確認したい接続先に置き換え、ルールを適切な位置に配置してください。outboundTag はアウトバウンドの tag と完全に一致させる必要があります。大文字・小文字、ハイフン、綴りを変えないでください。

{
  "type": "field",
  "domain": ["full:example.com"],
  "outboundTag": "local-socks"
}

転送と多段プロキシの違いを理解する

通信をローカルのSOCKSサービスに渡すと、そのサービスが後続の通信を処理します。しかし、それだけで複数のプロキシサーバーが指定した順に連結されるわけではありません。多段プロキシを構成するには、外側の接続方法、ドメイン名を解決する場所、各段階の認証を明確にする必要があります。コアによって多段接続の設定項目は異なります。sing-boxのフィールド名をXrayの設定にそのまま移したり、名前が似ていることだけで同じ動作だと判断したりしないでください。

特に危険なのは、2つのプロキシが互いを接続先として指定することです。クライアントAがBにリクエストを渡し、Bの上流がAへ戻る場合や、TUNがローカルプロキシの外側の接続を元のインバウンドへ再び送り返す場合があります。問題を調べるときは最終出口から逆向きに経路をたどり、各段階が次の接続先に到達できることと、明確な終点があることを確認してください。まずTUNをオフにし、1つのアプリだけでカスタムアウトバウンドを検証します。その後、システム全体の通信取り込みを段階的に戻すと、原因の範囲を絞れます。

アウトバウンドを複数使うと、DNSやUDPの違いも問題になりやすくなります。ローカルのSOCKSサービスがTCPに対応していても、必要なUDP転送に対応しているとは限りません。ドメイン名を前段で解決するか後段に渡すかによっても、ルールや接続性が変わります。検証では、ドメイン名の接続先、IPアドレスの接続先、実際に使うアプリのプロトコルをそれぞれ確認してください。「ポートに接続できた」だけで経路全体の検証が済んだと判断しないでください。

設定の保存、確認、復旧

まず、クライアントが用意しているカスタム設定、アウトバウンド、ルーティングの編集画面を利用してください。完全な設定を受け取る画面もあれば、オブジェクトの一部だけを受け取る画面もあります。貼り付ける前に、画面の説明と既存の設定構造を確認してください。JSONのオブジェクト、配列、文字列は正しい形式を保つ必要があります。コメントや末尾のカンマは追加できません。タグの重複、存在しないタグの参照、配列をオブジェクト用の項目に入れる操作は、起動失敗や気付きにくい設定の上書きにつながることがあります。

保存後は、まずコアが設定を正常に読み込めたか確認します。次に新しい接続を作成し、ログのアウトバウンドタグが想定した待ち受け先と一致しているか調べてください。設定の読み込みに失敗した場合は、サーバーの切り替えやサブスクリプションの更新を同時に行わず、変更前の設定に戻します。読み込みに成功して接続が拒否される場合は、ローカルサービスの起動状態、待ち受けアドレス、ポートを確認してください。接続が確立しても通信が失敗する場合は、次の接続先に沿ってプロトコル、認証、名前解決を確認します。

設定を継続して使える状態にしたら、用途、依存するサービス、待ち受けポート、元に戻す手順を記録しておきます。次回起動時に上流サービスの起動を忘れないためです。コアとクライアントの関係はProject V、V2Fly、Xrayのエコシステム解説をご覧ください。複数の項目にまたがる問題はよくある質問から症状に合わせて探せます。通常のシステムプロキシで動作する設定を必ず維持し、カスタムアウトバウンドで問題が起きたら、まず最短の経路に戻してください。