応用設定ガイド

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

グループ構成：配信元・用途・追跡しやすさ

サブスクリプションのグループ分けは、サーバーの配信元を整理するためのものであり、ルーティング設定の代わりにはなりません。まず設定の配信元ごとにグループを分け、日常利用、一時テスト、コアの互換性確認など、用途をメモしておくと便利です。グループ名を変えても、アプリの通信先が自動で決まるわけではありません。ドメインやアドレスに応じて出口を選ぶ場合は、ルーティング設定を行ってください。

設定画面：v2rayNのサブスクリプショングループ設定でグループを追加し、判別しやすい名前を付けて、サブスクリプションURLをアドレス欄に入力します。保存後はそのグループだけを更新し、解析が成功したことと、サーバー一覧が想定したグループに追加されたことを確認してください。画面によってメニュー名が異なる場合があります。スクリーンショットの座標を頼りにするのではなく、「グループ名」「サブスクリプションURL」「更新」の各項目を目印にしてください。

情報の保護：サブスクリプションURLには、アカウントを識別できるパスやパラメーターが含まれることが多く、アクセス資格情報として扱う必要があります。グループのメモにURL全体を貼り付けず、トラブル対応用のスクリーンショットでは機密部分を隠してください。設定をエクスポートして共有する前には、サーバーアドレス、ユーザー識別情報、認証項目も確認しましょう。サブスクリプションURLを削除しただけでは、エクスポートしたサーバー設定の匿名化は完了しません。

絞り込みルール：何を対象にしているか確認

サーバーの絞り込み：設定画面で絞り込んでいる対象が、サブスクリプションの取得内容、インポート済みサーバー、画面に表示中の一覧のどれなのか、まず確認してください。検索欄は通常、表示範囲を変えるだけで設定を削除しません。一方、サブスクリプションのフィルターは次回のインポート結果に影響することがあります。両者を混同すると、サーバーが消えたように見えますが、実際は表示条件が残っているか、更新時に絞り込まれただけかもしれません。

一致条件の構文：フィルター欄がすべて正規表現に対応しているとは限らず、大文字・小文字の扱いも異なる場合があります。まず実在する短い語句で試し、その後に条件を組み合わせてください。正規表現に対応している欄なら、办公|测试でメモがどちらかの語句に一致する条件を指定できます。通常の文字列しか扱えない場合、この内容全体が一つの文字列として処理され、結果が表示されないことがあります。

条件を段階的に絞る：最初は広めの条件で必要な設定が表示されることを確認し、その後で除外条件を少しずつ追加してください。最初から複雑な否定条件を設定するのは避けましょう。ノードのメモは配信元によって変更されることがあり、括弧、空白、地域の略称も一定とは限りません。プロトコルの対応状況は、設定内容とコアのログで確認してください。メモに含まれる特定のキーワードだけで判断することはできません。

更新結果の確認：取得失敗と解析失敗を区別する

更新経路：サブスクリプションの更新はクライアントが実行するネットワークリクエストであり、ブラウザーからWebページにアクセスできるかどうかとは別のテストです。直接接続で内容を取得できない場合、「サブスクリプション更新にプロキシを使用する」といった設定を検討できますが、その前に利用可能な出口が必要です。初回のインポートでまだ接続が確立していない場合、プロキシ経由の更新を有効にすると依存関係が循環することがあります。まず基本的な接続経路を確保してください。

解析結果：更新成功と表示されても、項目数だけで判断せず、プロトコル、アドレス、ポート、グループを確認してください。取得した内容が期限切れの案内ページや認証ページの場合もあります。ネットワークリクエストが成功しても、有効なサブスクリプションとは限りません。ログに形式エラーがある場合は、URLが完全にコピーされているか、期限切れでないかを確認してから、現在のクライアントがその形式に対応しているか調べてください。

ローカルでの変更：手動で編集したサブスクリプション内のサーバーは、次回の更新時に置き換えられる場合があります。変更を長期的に保持するには、クライアント対応の独立した設定を使うか、手動管理用のグループにコピーし、元の設定との差分を記録してください。同じ設定を複数のグループで繰り返し編集するのは避けましょう。トラブル時に、どの設定が実際に有効なのか分かりにくくなります。

復旧の順序：サーバーが急に減った場合は、まず一覧の検索をクリアし、次に追加した絞り込み条件を無効にして、影響を受けたグループだけを更新してください。エラーログと元の設定形式を比較し、すぐにすべてのサブスクリプションを削除して作り直すのは避けましょう。更新失敗の詳しい対処はv2rayNのサブスクリプション更新失敗と自動更新設定を、複数の配信元を管理する方法は複数サブスクリプションの管理を参照してください。

ルーティング設定の実践

リクエストの流れ：インバウンド、ルール判定、アウトバウンド

ルーティングの仕組み：アプリのリクエストはいずれかのインバウンドに入り、コアが宛先ドメイン、宛先アドレス、ポートなどの条件に基づいてルールを探し、該当するアウトバウンドに接続を渡します。システムプロキシやTUNは、リクエストがこの経路に入るかどうかを決めます。ルーティングが処理するのは、すでにコアに渡された通信だけです。アプリが端末のプロキシを使っていない場合、ドメインルールを繰り返し変更してもアクセス結果は変わりません。

ルールの適用順：通常、ルールは上から順に評価され、最初に一致したルールでアウトバウンドが決まります。対象範囲が明確な例外を先に置き、その後に広い範囲を対象とするルールを配置してください。一つのルール内にある複数の条件はすべて満たす必要がある一方、同じ条件配列内の項目は通常いずれか一つに一致すれば適用されます。ドメイン条件とアドレス条件を同じルールに記述すると、想定より対象が狭くなる場合があります。

プロトコルの役割：VMess、VLESS、Trojanは接続プロトコル、REALITYは通信のセキュリティに関する設定であり、ルーティングの代わりにはなりません。ノードをインポートできても、クライアントが設定形式を認識したことを示すだけで、実行中のすべてのコアが全フィールドに対応しているとは限りません。プロトコルはサーバー側の設定に合わせ、実際に起動しているコアも確認してください。ルーティングルールに一致させるためにノードのプロトコルを変更してはいけません。

ルールの例：部分設定の統合とタグの確認

使用例：以下はXrayのルーティング設定の一部です。プライベートアドレスと中国本土のドメインリストを、directという名前のアウトバウンドに渡します。使用する前に、対応するアウトバウンドが存在し、参照するルールデータファイルを読み込めることを確認してください。この設定にはプロキシ出口が定義されておらず、どのルールにも一致しないリクエストの行き先も指定されていません。残りの通信が必ずプロキシ経由になるとは限りません。

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

タグの参照：outboundTagはアウトバウンドの識別子を参照するフィールドであり、任意の表示名を指定するものではありません。クライアントが別のタグを生成している場合もあるため、実際に有効な設定を確認してから指定してください。保存時の検査に通っても実行時にアウトバウンドが見つからない場合は、タグの大文字・小文字と綴りを確認します。クライアントが設定を再生成した際にタグが変わる場合は、対応するルーティング編集画面から設定してください。

ドメインの判定方法：AsIsは、既存のドメイン情報で優先的にルールを判定します。アドレスルールのために新たな名前解決は行いません。IPIfNonMatchは、ドメインが一致しない場合に名前解決を試み、その後アドレスルールを判定します。IPOnDemandは、ルール判定にアドレス情報が必要になった時点で名前解決します。後者の方法では名前解決への依存が増える場合があり、積極的に解決すれば常に正確になるわけではありません。

ルールの適用確認：ログでルールの問題と接続の問題を切り分ける

利用できる情報：アプリがドメイン名をSOCKS経由で渡す場合、コアはそのままドメインルールを判定できます。アプリが先に名前解決し、アドレスだけを渡す場合は、利用できる情報が異なります。通信のスニッフィングで一部のプロトコルからドメインを補えることもありますが、すべての接続を識別できるわけではありません。ログにアドレスしか表示されない場合は、まずリクエストに含まれる情報を確認し、スニッフィングやDNS設定、TUNの調整が必要か判断してください。

確認方法：宛先が明確な操作を一つ選び、バックグラウンドアプリの影響を一時的に減らして、接続に使われたインバウンド、宛先、アウトバウンドタグを確認します。正しいアウトバウンドが選ばれているのに接続できない場合は、その出口の接続性とサーバー設定を調べてください。誤ったアウトバウンドが選ばれている場合に限り、ルールの順序、ドメイン情報の有無、アドレスリストの対象範囲を確認します。Webページの表示速度を、ルール適用の証拠として使わないでください。

デフォルトの動作：カスタム設定でどのルールにも一致しない通信は、通常デフォルトのアウトバウンドに渡されます。デフォルトのアウトバウンドはアウトバウンド一覧の順序に左右される場合があり、GUIクライアントが独自のフォールバックルールを生成することもあります。アウトバウンドの追加や順序変更を行う前に、この動作を確認してください。直結アウトバウンドを先頭に移すと、従来プロキシ経由だった未一致の通信まで直結になることがあり、影響範囲が一つのルール追加より大きくなります。

切り戻し方法：条件は一度に一種類だけ追加し、変更前のルール順と現在の出口を記録してください。問題が起きたら、まず追加したルールを無効にしてから、コアを再起動するかテスト接続をやり直します。既存の接続にはルールが再適用されない場合があります。ルールセットの名称については用語集を参照してください。正しいルールが適用されても接続できない場合は、ノードのタイムアウト対処手順に沿って切り分けてください。

DNS設定の最適化

名前解決の階層：どこが問い合わせているか確認

名前解決の経路：OSのリゾルバー、ブラウザー内蔵のセキュアDNS、クライアント内蔵DNS、サーバー側の名前解決が同時に使われることがあります。クライアントのDNSを変更しても、ブラウザー自身が送る問い合わせが変わるとは限りません。システムプロキシを有効にしても、OSのすべての問い合わせがコアに入るわけではありません。調整を始める前に実際の経路を整理し、アプリがドメイン名とアドレスのどちらを渡すのか、最終的にどの階層がDNSサーバーを選ぶのかを確認してください。

問題の切り分け：ドメインを解決できない、解決したアドレスに接続できない、名前解決が遅い、誤ったルーティング先が選ばれる、これらはそれぞれ別の問題です。アドレスを取得できているのに接続がタイムアウトする場合、DNSサーバーを変えても改善しないことがあります。同じドメインでもネットワークによって異なるアドレスが返されることがあり、必ずしも異常とは限りません。分散サービスは接続元に応じて異なる結果を返す場合があるため、接続ログと宛先ネットワークを合わせて確認してください。

目標：DNSの最適化は、パブリックDNSサーバーを増やすことではなく、不要な依存関係を減らすことです。コアの起動にサーバーのドメイン解決が必要なのに、DNS問い合わせを未接続のサーバー経由に限定すると、起動時に依存関係が循環します。まず現在のネットワークで基本的な名前解決ができる経路を確保し、その後でアプリのドメインに使う問い合わせ方法を段階的に調整してください。

フィールド比較：アドレスファミリーとドメイン別の問い合わせ

基本例：以下はXray内蔵DNSの部分設定例で、問い合わせ先とアドレスファミリーの選択方法を示しています。アドレスは設定構造の例にすぎません。使用前に、現在のネットワークから到達できることと、目的に合った名前解決ができることを確認してください。この設定だけではシステムDNSの問い合わせはコアに転送されず、問い合わせ通信をどのアウトバウンドから送るかも定義されていません。端末全体のDNS通信を単独で取り込む設定ではありません。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      },
      "1.1.1.1"
    ]
  }
}

問い合わせ対象：サーバーオブジェクトのdomainsは、優先的にそのサーバーへ渡すドメインの集合を指定します。ただし、この設定だけで他のサーバーに関連する問い合わせが一切送られなくなるとは限りません。フォールバックの仕組み、想定するアドレスの条件、コアの実装も後続の処理に影響します。問い合わせ先を厳密に制限する必要がある場合は、使用中のコアが対応するフォールバック設定を確認し、ログや端末のネットワーク通信で検証してください。

アドレスファミリーの選択：ネットワークでIPv4とIPv6の両方を利用できる場合は、ログを減らすためだけに一方を恒久的に制限しないでください。一時的にUseIPv4を使うと、別のアドレスファミリーに関する問題かどうかを確認できます。テスト後はOSのルーティング、出口の対応状況、サーバーの待ち受け設定も確認してください。内蔵DNSの選択が制限するのは対象となる名前解決処理だけであり、アプリが直接アドレスを渡す場合、そのアドレスが変換されるわけではありません。

キャッシュとフォールバック：テスト結果を正しく判断する

キャッシュの影響：DNSサーバーを変更した後も、OS、ブラウザー、クライアントのキャッシュが使われ続けることがあります。古い接続を閉じ、関係するコンポーネントのキャッシュを更新するか、アプリを再起動してください。毎回端末全体を再起動する必要はありません。変更前後の応答アドレスとアウトバウンドタグを記録すれば、設定が実際に反映されたのか、接続可能な古いアドレスが使われたのかを区別できます。

フォールバックの注意点：予備のサーバーを設定すると、単一の経路が使えない場合に可用性を高められますが、名前解決の動作は複雑になります。どのサーバーもタイムアウトする場合、問題はドメインではなく、問い合わせの送信経路や現在のネットワークにあるかもしれません。特定のドメインだけに問題がある場合は、まずドメイン集合の一致条件と返されたアドレスを確認しましょう。ほかの正常なアプリまで影響する全体的なDNS変更は避けてください。

ローカルネットワーク：プリンター、LAN内のホスト、内部サービスは、ルーターの名前解決やローカルの検索ドメインに依存している場合があります。すべての問い合わせをパブリックDNSに送ると、こうした名前を解決できなくなることがあります。明確な内部ドメインにはローカルの名前解決経路を残し、アクセス先のアドレスが直結ルートを通ることも確認してください。名前解決の設定だけ補っても、プライベートアドレス宛ての通信が遠隔地の出口へ送られれば正常にアクセスできません。

動作確認の手順：まずシステムプロキシモードで通常のドメインを一つ選び、名前解決と接続を確認します。次にTUNを有効にし、最後にFakeDNSを検討してください。各段階で元に戻せる設定を保ち、アドレスファミリー、問い合わせ先、ルーティングを同時に変更しないでください。証明書名の不一致がある場合は、TLSハンドシェイクとSNIの確認方法を参照してください。証明書検証を無効にして、名前解決や設定の問題を隠してはいけません。

TUNモード

取り込み範囲：仮想ネットワークアダプターは出口ではない

TUNの役割：仮想ネットワークアダプターは、OSのルーティング設定に合致する通信をユーザー空間の処理に渡します。システムプロキシに従わないアプリに適しています。TUNが解決するのは、通信をクライアントに取り込む方法です。ノードの認証、サーバーへの到達性、誤ったルーティングルールを自動修正するものではありません。有効にした後も、利用可能な出口、正しいDNS経路、クライアント自身の接続を繰り返し取り込まないOSルートが必要です。

モードの違い：システムプロキシはアプリがOSのプロキシ設定を参照することを前提とします。一方、TUNはよりネットワーク層に近い位置でパケットを受信します。環境によっては両方を併用できますが、最初のトラブルシューティングでは、片方だけで動作を確認してください。ブラウザーは正常でもほかのアプリに問題がある場合、そのアプリがシステムプロキシを使っていない可能性があります。それだけで、すべてのノードやコアを変更する必要があるとは限りません。

コアの役割分担：デスクトップクライアントのTUN機能は、独立したコンポーネントとプロキシコアが連携して実装されることがあり、設定フィールドや権限要件は組み合わせによって異なります。ネット上のtunフィールドを含む設定を、任意のXray設定にそのまま入れないでください。v2rayNが提供するTUN設定画面を使い、起動ログで関連コンポーネントが実際に動作していることを確認してください。

有効化の手順：基本動作からOSルートまで

接続の基準確認：TUNを有効にする前に、システムプロキシモードで既知の利用可能なサーバーを使って接続を確認し、選択中のサーバー、ルーティングモード、DNS設定を記録します。次に、ルートを変更したり仮想ネットワークアダプターを作成したりするほかのツールを終了し、複数のコンポーネントがデフォルトルートを奪い合うのを避けてください。FakeDNSも同時に有効にせず、通常の名前解決とTUNの通信取り込みを個別に検証できる状態にします。

権限の準備：Windowsでは、ネットワークアダプターの作成やルートの追加に管理者権限が必要な場合があります。macOSやLinuxでも、OSの許可やサービスに対する権限を求められることがあります。必要な権限はクライアントの案内に従ってください。スイッチを有効にしてもすぐ戻る場合は、権限の拒否、コンポーネントの起動失敗、ネットワークアダプターの作成エラーを確認します。何度もスイッチをクリックするのではなく、許可後にルートが正しく設定されたことも確認してください。

モバイルでの動作：Android版のv2rayNGとv2flyNGは、通常、OSのVPNインターフェースを使って通信を取り込みます。初回起動時にはOSの許可が必要です。この仕組みはデスクトップ版TUNの実装と異なるため、デスクトップの設定をそのまま一つずつ適用しないでください。同じインターフェースを使うほかのアプリとは併用できない場合があります。切り替える前に、現在どのクライアントが通信を取り込んでいるか確認してください。

通信の取り込みを確認：まず、システムプロキシに従わないアプリでテストし、クライアントの接続履歴に該当する宛先が表示されるか確認します。次に通常のWebサイト、LAN内のサービス、サブスクリプション更新が引き続き利用できることを確認してください。ネットワークアダプターが存在することや、アイコンに接続済みと表示されることだけでは不十分です。アダプターの作成に成功しても、DNSルート、出口ルート、アプリからのアクセスはそれぞれ失敗する可能性があります。

よくある競合：除外ルート、ループ、パケットサイズ

クライアント自身の通信を除外：プロキシコンポーネントからサーバーへの通信は、適切に除外ルートを通す必要があります。そうしないと、仮想ネットワークアダプターに再度取り込まれてループすることがあります。クライアントは通常、必要なルートを自動生成しますが、デフォルトルート、インターフェースのバインド、カスタムアウトバウンドを手動で変更すると、除外設定が壊れる場合があります。同種の接続がログに繰り返し記録され、全般的にアクセスできなくなった場合は、追加した設定を無効にし、クライアントのデフォルトの取り込み設定に戻してください。

LANへのアクセス：リモートデスクトップ、プリンター、内部アドレスにアクセスできなくなった場合は、まずプライベートネットワークの範囲がTUNに取り込まれているか確認し、次に直結アウトバウンドに送られているかを確認してください。ネットワークによっては、標準的なプライベートアドレス以外が内部リソースに使われることもあります。そのため、プライベートネットワークのルールを追加するだけでは不十分な場合があります。実際に使われている範囲に合わせて必要最小限の除外を追加し、関係のない通信まで広くバイパスしないでください。

パケットサイズ：一部のサイトは開けるのに、大きなファイルのダウンロードや長時間接続が止まる場合は、MTUを後の確認項目として検討します。最初から理由なく変更せず、まずDNS、プロトコル、サーバーの問題を除外してください。その後、クライアントで設定できる項目を使って一つずつテストし、元の値を記録します。ネットワークごとにカプセル化のオーバーヘッドが異なるため、あらゆる端末や回線に共通する最適値はありません。

安定性の確認：スリープからの復帰、Wi-Fiネットワークの切り替え、デフォルトのネットワークアダプターの変更後は、古いインターフェースやルートが無効になっている場合があるため、毎回動作を確認してください。基本の通信取り込みが安定してから、ドメイン別ルーティングやFakeDNSを追加します。用語の違いはFAQを参照してください。初回接続がまだ完了していない場合は、セットアップガイドに戻り、未確認の設定階層を行き来しながら変更するのは避けましょう。

FakeDNS

仕組み：偽のアドレスを使ってドメイン情報を保持する

動作の仕組み：FakeDNSは、接続先サーバーの実アドレスではなく、ドメインに対して対応付け用のアドレスを返します。アプリがそのアドレスに接続すると、連携するコンポーネントが対応表から元のドメインを復元し、ルーティングやアウトバウンドに引き渡します。アドレスだけを送る通信でもドメインとの関連を維持できるのが利点です。遠隔ネットワークに、そのアドレスを持つ実サーバーが存在するという意味ではありません。

利用条件：アプリのDNS問い合わせが指定されたFakeDNSの経路に入り、その後の接続も対応表を認識するコンポーネントで処理される必要があります。片方だけでは動作しません。偽アドレスを受け取った後、通常のネットワークに直接送ってしまうと、実際の宛先には通常到達できません。逆に、接続を取り込んでもDNS問い合わせがマッピングを行うサービスを経由していなければ、元のドメインを復元できません。

ルーティング上の利点：ドメインルールが十分に整っており、アプリが名前解決後に接続する場合、マッピングによってドメイン単位のルーティングを一貫させやすくなります。ルールの順序ミスを修正したり、実際のDNSのすべての用途を代替したりするものではありません。アプリが固定アドレスに直接アクセスする場合や、独自の暗号化DNSを使う場合は、このマッピング経路を通らないことがあります。

設定の関係：アドレスプール、DNSの入口、スニッフィング

構成例：以下はXrayでアドレスプールとDNSサービスを関連付ける設定例です。198.18.0.0/15はベンチマーク用のアドレス空間であり、遠隔サービスの実アドレスではありません。設定前に、既存のネットワーク設計、ほかの仮想ネットワークアダプター、テスト環境と重複しないか確認してください。重複する場合は、すぐに有効化するのではなく、先にアドレス設計を見直します。

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

インバウンドとの連携：これらの接続を受け取るインバウンドも、対応表から元の情報を復元できる必要があります。以下は対象のインバウンドオブジェクトに統合できるスニッフィング用フィールドのみを示しており、インバウンドのプロトコル、待ち受けアドレス、ポートは定義していません。GUIクライアントが同等の設定をすでに生成している場合もあるため、実際の設定を先に確認し、重複追加を避けてください。異なる通信取り込みコンポーネントが管理する対応表は、フィールドをコピーするだけでは共有できません。

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

コアによる違い：上記の設定例はXrayの関連項目を説明するためのものであり、確認せずにv2flyNGや別のTUNコンポーネントへ移植できるとは限りません。クライアントにFakeDNSのスイッチがある場合は、その画面を優先して使い、実際に動作するコアも確認してください。対応情報が明確でない場合は、異なる実装のフィールドを無理に組み合わせるより、通常のDNS経路を維持するほうが管理しやすくなります。

互換性と通常の名前解決への切り替え

アプリとの互換性：実際の名前解決アドレスの表示、アドレスの所有者確認、LAN内デバイスの検出、名前解決結果の別プロセスへの受け渡しが必要なアプリでは、マッピングを全面的に使うのが適さない場合があります。プログラムによっては偽アドレスをキャッシュし、クライアント停止後も接続を試みます。特定のアプリだけに問題がある場合は、そのアプリのDNS問い合わせと接続が同じ処理経路を通っているかを確認してから、除外範囲を決めてください。

キャッシュの有効期間：対応表とアプリのキャッシュの有効期間が一致しないことは、再起動後に断続的な障害が起こる原因の一つです。コアの再起動後に古い対応表が消えても、アプリには以前受け取ったアドレスが残る場合があります。この場合、ノードを変えるだけでは改善しないことがあります。古い接続を閉じ、対象アプリのDNSキャッシュを更新してから再度問い合わせ、新しい対応関係を作成してください。

確認方法：有効にした後、OSまたはアプリが対象ドメインを問い合わせると、マッピング用アドレスプール内のアドレスが返されます。クライアントが接続を元のドメインに関連付け、想定したアウトバウンドを選択することも確認してください。予約アドレスが表示されるだけでは設定全体が正しいとは限りません。実際の通信が成功すること、LANにアクセスできること、マッピングを使用しない実アドレスへの通信が従来のルールどおり処理されることも確認します。

無効化の手順：まずFakeDNS関連の設定を無効にし、通常のDNSサーバーに戻します。次にOSとアプリのキャッシュを更新し、古いマッピングアドレスを使っている接続を閉じてください。仮想ネットワークアダプターだけを無効にして、アプリにマッピングアドレスがキャッシュされたままだと、引き続き接続に失敗することがあります。復旧後はDNSの応答を再確認し、アドレスプールの値が遠隔サーバーの実アドレスとして扱われていないことを確認してください。

導入の判断：通常のDNSとTUNが安定し、ドメイン情報が実際に失われる問題がある場合に限り、この階層を追加する価値があります。サブスクリプション切れ、サーバーのタイムアウト、認証失敗が主な問題であれば、FakeDNSで改善することはありません。仕組みと用途の詳細はFakeDNSの仕組みとv2rayNで有効にするタイミングを参照し、無効時の設定も比較用に残しておいてください。

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

管理の基本：配信元を分け、名前を統一する

配信元を分ける：複数のサブスクリプションを管理する場合は、まず更新範囲を分け、それぞれの配信元に個別のグループを使い、手動管理の設定も別に保管してください。一覧をきれいに見せるためだけに、すべてのサーバーを配信元が追跡できない一つの大きなグループへコピーしないでください。障害、形式の変更、更新による上書きが発生したときに、配信元が分かれば問題の範囲を絞り込み、影響する部分だけを停止できます。

命名ルール：配信元の略称、用途、管理方法をグループ名やメモに含めると便利ですが、アカウント情報やサブスクリプションURL全体は含めないでください。ノードのメモには配信元のテキストを残し、必要に応じてローカルの識別用マークを追加します。手動で変更した名前が更新後も保持されるかはクライアントの実装によります。メモに依存する絞り込みルールは定期的に見直し、恒久的な識別子と考えないでください。

選択範囲の注意点：サブスクリプションを追加しても、自動的に負荷分散、フェイルオーバー、アプリ別ルーティングが行われるわけではありません。通常のサーバー一覧では、引き続き現在選択中の項目が一つだけとなり、複数の配信元は候補を増やすだけです。通信ごとに異なるアウトバウンドを使う場合は、ルーティングと出口の対応関係を明示的に設定してください。グループの順番や一覧の並び替えを、コアが出口を選ぶ優先順位と混同しないでください。

更新頻度：連鎖する障害を防ぐ

手動での確認：新しい配信元を追加したら、まず単独でインポートと更新を行い、プロトコルとコアの対応状況を確認してから実際に接続してください。利用できることを確認してから定期更新の対象に加えます。最初から既存の配信元と一斉に更新すると、接続が失敗した際に、新しく追加した内容の変更と既存の配信元の変更を区別しにくくなり、調査に時間がかかります。

自動更新の間隔：更新頻度は配信元の設定変更のペースやサービス要件に合わせてください。頻繁に更新すれば信頼性が上がるわけではありません。過度に短い間隔でリクエストすると、不要な更新が増えたり、配信元で制限されたりすることがあります。グループごとに更新間隔を設定できる場合は、実際の用途に合わせて調整してください。共通の間隔しか設定できない場合は、安定して管理できる頻度を選び、臨時の変更に備えて手動更新の方法も残します。

プロキシへの依存：プロキシ経由の更新で、直接接続できない一部の配信元を利用できる場合があります。ただし、すべての配信元を未検証の同じ出口に依存させないでください。現在のノードに問題があると、プロキシ経由の更新も失敗し、すべてのサブスクリプションが無効になったように見えることがあります。まず更新リクエストの通信経路を確認してから、リンクの状態を調べてください。必要であれば、利用可能と分かっている設定に切り替えて、個別に更新を再試行します。

重複削除、移行、バックアップの注意点

重複削除の基本：名前が同じでも設定が同じとは限らず、アドレスが同じでも認証や通信パラメーターが同一とは限りません。重複項目を削除する前に、プロトコル、ポート、ユーザー識別情報、通信方式、セキュリティ項目を比較してください。一部のフィールドだけで判定する自動重複削除では、異なる接続方式で使う設定まで誤って削除することがあります。判定条件が分からない場合は、コピー上で試してから主要なグループを整理してください。

クライアント間の移行：v2rayN、v2rayNG、v2flyNGでは、サブスクリプションの解析、画面での設定保存、カスタム設定の対応範囲が完全には一致しません。移行時は、サブスクリプションを解析できるか、ノードが動作するか、ルーティングとDNSが再構築されているかを個別に確認してください。サーバー一覧をインポートできても、デスクトップのTUNやシステムプロキシ、すべてのカスタムルールがモバイル端末へ同期されたとは限りません。

バックアップする内容：グループ構成、必要なサブスクリプション情報、独立して管理する設定、ルール設定を保存し、アクセスを制限できる場所に保管してください。一時的に生成されたコアの設定ファイルだけでは、画面側の配信元情報や更新設定が含まれないことがあります。復元前に、バックアップがどのクライアントと設定画面に対応するか確認し、構造の異なる新しい環境へ古いフィールドを上書きしないようにしてください。

変更履歴：大きな変更を行うたびに、必要な動作の変更だけを記録します。たとえば、特定のグループをプロキシ経由の更新に変更した、フィルター条件を緩めた、ルールを上位に移動した、といった内容です。機密性の高いアドレスを記録する必要はなく、認証情報を含む設定を公開メモに貼り付けるのも避けてください。問題が起きたときは、最後に変更した設定階層が分かるほうが、説明のない設定コピーを大量に保存するより役立ちます。

使用終了時の処理：配信元を使わなくなったら、まず現在のサーバー、自動更新タスク、カスタムアウトバウンドで参照されていないことを確認し、グループを無効にします。ほかの配信元が単独で正常に動作することを確認してから削除してください。先に削除すると、参照先のないタグが残る場合があります。一時的なネットワーク障害であれば、既存の設定を残して更新を一時停止するのが適切です。サブスクリプションの失効や解析の問題はよくある質問とサブスクリプションのグループ分けを照らし合わせて確認してください。

カスタムアウトバウンド

コアとエコシステム：設定の対象を確認

コアの関係：Project Vはこの種のプロキシツールを理解するためのエコシステム上の背景であり、V2FlyとXrayは区別が必要なコアの系統です。GUIクライアントはサブスクリプション、画面、設定生成を担当し、コアは実際の接続を処理します。画面が似ている2つのクライアントでも、同じ設定を受け付けるとは限りません。同じクライアントでも、実行するコアを変更した場合は、プロトコルとフィールドの対応状況を改めて確認してください。

Xrayの設定：v2rayNGはXrayコアを採用し、v2flyNGはV2Flyコアを使う選択肢です。v2rayNの実際の動作は、現在実行中のコンポーネントを基準にしてください。カスタムアウトバウンドを追加する前に、ログの起動情報とクライアントの設定を確認し、どのコアの設定を使っているか特定します。オープンソースであることは、コードを調査・保守できることを示しますが、実装の違いを無視して設定を自由に相互利用できるという意味ではありません。

REALITYの適用範囲：接続のセキュリティに関するパラメーターを含むため、サーバーから指定された設定に合わせる必要があります。ローカルのルーティングを切り替える機能ではありません。アウトバウンドタグの変更、直結ルールの調整、ローカルSOCKSアウトバウンドの追加では、サーバー名や公開鍵などの誤った接続パラメーターを補えません。該当するノードでは元の設定を保存し、基本接続を確認してからカスタム経路を追加してください。

アウトバウンドの定義：直結とブロックの最小構成

定義方法：アウトバウンドオブジェクトでは、tagでルーティングから参照できる識別子を設定し、protocolで動作を指定します。以下はXrayにおける直結とブロックのアウトバウンド一覧の一部で、タグは説明用です。前述のルーティング例と対応させてください。既存の設定に統合するときは、元のプロキシアウトバウンドを上書きしないでください。デフォルトの動作を確認する前に、一覧全体の順序を変更するのも避けてください。

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

デフォルトの動作：この例には遠隔プロキシの出口も完全なルーティング設定も含まれていません。完全なアウトバウンド一覧として使うと、ルールに一致しないリクエストは先頭の直結アウトバウンドへ送られる可能性があります。ブロックアウトバウンドも、ルールで選択された場合にだけ機能します。オブジェクトを追加した後は、生成された設定とデフォルト出口を確認し、対象範囲の小さい明確なルールを一つ使ってタグの参照をテストしてください。

ローカルの上流：自身へ接続を戻さない

チェーン転送：特定のリクエストを、ローカルで稼働する別の管理下のSOCKSサービスに渡す場合があります。以下の設定例は、local-upstreamというアウトバウンドを定義し、指定ポートのループバックアドレスへ接続します。そのポートで互換性のあるサービスが待ち受けており、現在のクライアントが同じ通信を受け取るインバウンドではないことが前提です。上流サービスがなければ、この定義だけで利用可能な出口ができるわけではありません。

{
  "tag": "local-upstream",
  "protocol": "socks",
  "settings": {
    "servers": [
      {
        "address": "127.0.0.1",
        "port": 10810
      }
    ]
  }
}

ループの確認：ローカルのインバウンドが同じアドレスとポートを待ち受けている場合、転送された通信が自身に戻り、接続が再帰したりすぐに失敗したりすることがあります。TUNモードでは、上流プロセスの外部通信が再び取り込まれ、別のループを形成しないかも確認してください。まず上流を単独で検証し、次にテスト用ルールを一つだけ割り当て、最後に適用範囲を広げます。最初からすべての通信を取り込まないでください。

対応機能の確認：SOCKS上流が認証、ドメイン名の転送、UDPに対応するか、それぞれ確認してください。Webページにアクセスできても、その接続経路が使えることを示すだけで、すべての種類のデータを転送できる証拠にはなりません。一部のアプリだけに問題がある場合は、リクエストの種類と上流の対応状況を確認してください。観察しにくい入れ子構造を増やすために、すぐにプロキシ設定を追加しないでください。

動作の確認：設定画面、構文、永続化

編集画面：完全なカスタム設定モードと、画面から設定を生成するモードでは、管理上の責任範囲が異なります。前者ではインバウンド、ルーティング、DNS、アウトバウンドを自分で定義する必要がある一方、後者ではクライアントが一部を管理します。保存前に、どのフィールドが上書きされるか、ノード切り替え後もカスタム内容が残るかを確認してください。一時ファイルにフィールドが存在したことだけでは、設定が永続的に反映されているとは判断できません。

エラーの切り分け：起動直後に失敗する場合は、JSONのカンマや括弧、フィールドの型、プロトコル名を確認します。起動は成功してもルールに一致しない場合は、ルーティングのタグを調べてください。ルールには一致するのに接続できない場合は、待ち受け、認証、ネットワークの到達性を確認します。管理下のテスト中だけログレベルを一時的に上げ、原因が分かったら通常のレベルに戻してください。宛先アドレスや認証情報を含むログ全体を公開しないでください。

保守の要点：アウトバウンドを一段追加するたびに、入力元、出力先、失敗時の戻し方を明確に記録してください。この3点を説明できない場合は、クライアントのデフォルト設定を優先します。インストーラーやコンポーネントの選び方はダウンロードページで、基本的な接続確認は設定ガイドで確認してください。基本動作が安定してから、このガイドに沿ってルーティング、名前解決、通信の取り込みを段階的に追加し、複数の独立した問題が再現できない一つの問題に混ざるのを防ぎます。