v2rayNの応用設定
サブスクリプション・ルーティング・ネットワークモード

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

サブスクリプションURLはサーバー情報の更新元、サブスクリプショングループはその情報をクライアント内で管理する単位、サーバー項目は接続時に使う具体的な設定です。まずこの3つを区別してから一覧を整理しましょう。通常、グループ名を変更してもリモートのサブスクリプション内容は変わらず、一覧の絞り込みを切り替えても使用中のサーバーは自動で切り替わりません。問題を調べる際は、グループの取得元、一覧の表示範囲、現在有効な項目をそれぞれ記録し、管理画面の変化をネットワーク状態の変化と混同しないようにします。

グループを作成してからサーバーを更新

v2rayNのサブスクリプショングループ設定で、取得元ごとにグループを作成し、完全なサブスクリプションURLを入力して保存した後、そのグループを更新します。「仕事用」「予備用」のように、取得元と用途が分かる名前を付けましょう。取得元が自動生成するノード名だけで所属先を判断するのは避けてください。初回は1つのグループだけを更新し、項目を取得できること、サーバーを選べること、接続できることを確かめてから、ほかの取得元を追加します。こうすれば問題が起きても、どの操作が原因か特定しやすくなります。

サブスクリプションURLにはアクセス認証情報が含まれる場合があるため、アカウント情報と同様に扱ってください。完全なURLをスクリーンショット、公開ログ、共有メモに載せないでください。問題を説明するときは、リクエスト方法、エラーの種類、伏せ字にしたホスト部分だけを残します。URLをコピーしたら、前後の空白や改行、チャットアプリが付け加えた句読点がないか確認してください。サービス提供元がクライアント別の入口を用意している場合は、何度も貼り付けて試すのではなく、現在のクライアントに対応する形式を選びます。

更新に失敗したら、まずサブスクリプション更新ログを確認します。接続タイムアウトは期限内にリクエストが完了しなかったことを示します。認証エラーの場合は、URL内の認証情報を確認してください。リクエストは成功しても解析に失敗する場合、ログインページを取得しているか、データ形式に互換性がない可能性があります。すでに接続できる環境があれば、クライアントのプロキシ経由更新を試せます。ただし初回追加時には利用できるプロキシがないこともあるため、必ず解決できる方法とは限りません。機密情報を含む生のレスポンスを公開アップロードしないでください。

接続設定は変えずに一覧を絞り込む

サーバーの絞り込みは、特定の地域名を含む項目だけを表示したり、使わなくなった用途の項目を除外したりして候補を減らすのに便利です。条件を入力する前に、どのグループが対象か、名前だけを検索するのか、ほかの項目も対象かを確認してください。通常のキーワード検索と正規表現は別の構文です。画面に正規表現対応が明記されている場合だけ正規表現を使い、そうでなければ括弧や縦棒などは文字どおりに検索される可能性があります。絞り込んだ後も、使用中のサーバーは手動で確認してください。

絞り込み条件が正規表現に対応している場合は、次の式で2つの名称キーワードに一致させられます。これは名前を絞り込む例であり、該当サーバーの回線品質や通信の出口を示すものではありません。名前はサブスクリプションの提供元が決めるため、大文字・小文字、空白、命名規則の変更によって一致結果が変わることがあります。まず実際の項目を確認し、条件を少しずつ絞り込みましょう。最初から条件を厳しくしすぎると、グループ内にサーバーがないように見えることがあります。

(香港|シンガポール)

一覧が空になった場合は、「検索語を消す、追加の絞り込みを解除する、すべてのグループに切り替える、更新ログを確認する」の順に対処します。表示条件が原因の可能性があるため、すぐにサブスクリプションを削除しないでください。サーバーの絞り込みはアプリの通信振り分けとも異なります。前者は一覧に表示するサーバーを決め、後者は接続にどのアウトバウンドを使うかを決めます。一覧に項目が1つしかなくても、すでに確立した接続は以前の出口を使い続けることがあります。

更新による上書きとローカル変更を管理する

サブスクリプションを更新すると、取得元が管理するサーバー項目が置き換わることがあります。項目のポート、通信パラメーター、メモを直接変更した場合、次回更新で上書きされる可能性を考慮してください。長期的に残したいローカル変更は、手動管理の別グループにコピーし、メモに取得元と変更理由を記載するのがおすすめです。これなら元のサブスクリプションを引き続き更新しながら、手動コピーの同期が必要なタイミングも把握できます。手動コピーが自動更新される項目だと誤解しないようにしましょう。

サブスクリプショングループを削除する前に、そのグループのサーバーも一緒に削除されるか、現在のサーバーがそのグループに属しているかを確認してください。削除時の動作は画面によって異なるため、確認メッセージを読んでから操作します。残す項目は先にエクスポートまたはコピーし、サブスクリプションURLも別途安全にバックアップしてください。URLを含むエクスポートファイルも機密設定情報です。バックアップから復元した後は、名前が残っているかだけでなく、グループの有効状態、更新方法、使用中のサーバーも改めて確認します。

V2Rayルーティングルールの実践ガイド

ルーティングは、コアに届いた接続を特定のアウトバウンドに渡して処理する仕組みです。もともとクライアントを経由しないアプリの通信を、自動的にプロキシへ取り込むものではありません。ルールを設定する前に、対象アプリがクライアントのローカル入口を利用しているか、TUNで取り込まれているかを確認してください。そうでなければ、ルールの構文が正しくてもコアに接続が届かず、期待するマッチ記録もログに残りません。入口を確認し、ルールを観察してからアウトバウンドを調べる手順は、ルールの順序を何度も変えるより確実です。

上から順にマッチするようルールを並べる

XrayとV2Flyでは、一般的なフィールドルーティングはルールを上から順に評価し、最初に一致したルールがアウトバウンドを決めます。通常は、明示的に拒否する対象、プライベートネットワークへの直接接続、個別の例外を、広範囲に適用するルールより前に置きます。その後に大きなドメイン集合を設定し、最後にどのルールにも一致しない場合の動作を確認します。万人に共通する固定順序はありません。社内ドメインを専用プロキシ経由にする必要があるなら、それを直結対象に含める広範囲のルールより、ドメインを指定したルールを前に置きます。

順序を説明するためのXrayルーティング例です。実際に使うには、完全な設定へ統合してください。proxy、direct、blockという名前のアウトバウンドと、参照するルールデータがすでに存在することを前提としています。タグはローカルで使う識別名であり、名前を書いただけではアウトバウンドは作成されません。クライアントが異なるタグを生成する場合は、実際の設定に合わせて参照先を変更してください。

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

この例には、すべてを対象にする包括ルールは記述していません。ここで扱う一般的なコア設定では、どのルールにも一致しない接続は通常、アウトバウンド一覧の先頭に渡されます。クライアントが独自のデフォルト動作を実現するため、追加ルールを生成する場合もあります。そのため「final → proxy」はポリシーを示す表現であり、上記のJSONにそのまま追加できるフィールドではありません。デフォルトの動作を確かめるには、実際に生成された設定と実行ログを確認してください。画面上のモード名だけから推測しないようにしましょう。

ドメインのマッチとIPアドレスのマッチを区別する

ドメインルールがマッチするには、接続に利用可能なドメイン情報が必要です。アプリがIPアドレスへ直接アクセスする場合や、入口から宛先アドレスしか渡されない場合、ドメインルールだけでは一致しないことがあります。プロトコルのスニッフィングで一部の接続からドメインを補える場合はありますが、すべての暗号化通信に有効とは限らず、常にドメイン情報を取得できる保証もありません。まずログの宛先がドメインかIPアドレスかを確認し、ドメイン集合、アドレス範囲、DNSや入口から渡される情報のどれを調べるべきか判断します。

domainStrategyは、ルーティングのマッチ処理でドメインをいつ名前解決するかを制御します。すべてのアプリのDNS通信が取り込まれるという意味ではありません。AsIsはアドレスルールのために自動で名前解決しません。IPIfNonMatchはドメインルールに一致しなかった場合、名前解決を試みてからアドレスルールを評価します。IPOnDemandはルールの評価にIPアドレスが必要になった時点で名前解決を試みます。設定を変えると問い合わせ回数やマッチ結果が変わるため、DNS設定と合わせてテストしてください。積極的に名前解決するほど正確になるとは限りません。

単一の対象でルールを検証する

ルールを追加するたびに、再現性のある対象を1つ選び、既存の接続を閉じてから再アクセスし、アクセスログの宛先とアウトバウンドタグを確認します。ブラウザーの長時間接続、コネクションの再利用、アプリのキャッシュによって、変更前の経路が使われ続けることがあります。ページを再読み込みするだけでは新しい接続が作られない場合があります。必要なら対象アプリを終了して再テストし、その間はほかの設定を変えないでください。テスト時刻、宛先、アウトバウンドをログで対応付けられることが重要です。クライアントが起動中かどうかだけを確認しても不十分です。

ルールが効かない場合は、先行ルールが先にマッチしていないか、タグが存在するか、ルールデータが読み込まれているか、接続にドメイン情報が含まれているかを順に確認します。ルールにマッチしているのにアクセスできない場合は、アウトバウンドとDNSを調べてください。同じレイヤーに重複ルールを追加し続けないようにしましょう。ルールデータの更新で集合の範囲が変わることもあるため、更新後はよく使うサービスを確認します。保守の際は、用途を短く記したルールのほうが、重複した例外を大量に並べるより競合を見つけやすくなります。

DNS設定と名前解決の経路

DNSの問題を調べる際は、まず3つの点を確認します。誰が問い合わせを行うのか、問い合わせがどの経路でリゾルバーに届くのか、返された結果を誰が使うのか、です。アプリ自身が問い合わせる場合、OSが結果をキャッシュする場合、コアがルーティングや接続のために別途問い合わせる場合があります。複数の経路が同時に存在するため、クライアントのDNSサーバーを変更しても、ブラウザー独自の暗号化DNSが変わるとは限らず、OSに保存済みのキャッシュも更新されない場合があります。リゾルバーのアドレスだけを入れ替えるより、実際の経路を整理してから設定を変えることが大切です。

システムの名前解決とコアの名前解決を区別する

システムプロキシモードが変えるのは、主にプロキシ設定に従うアプリの通信経路です。すべてのシステムDNS問い合わせが自動的に取り込まれるわけではありません。SOCKSを使う場合も、宛先ドメインをローカルで解決するかプロキシに渡すかは、アプリの実装と呼び出し方法によって異なります。TUNとDNSの取り込みを組み合わせれば対象を広げられますが、ルーティング、取り込みポート、アプリ独自の名前解決設定も確認が必要です。TUNを有効にしただけで、システム内のすべての問い合わせが同じ経路を通るとは限りません。

v2rayNのコアDNS、TUN関連のDNS、デスクトップOSのDNSは、それぞれ異なる設定箇所で管理される場合があります。変更前に現在の実行モードと補助コンポーネントを記録し、変更する項目をどのコンポーネントが読み込むか確認してください。Androidのv2rayNGとv2flyNGでは、VPNサービスの状態やアプリ選択設定も影響します。別のプラットフォームに移すときは、デスクトップ用の設定テキストを任意の入力欄へそのままコピーするのではなく、設定の意図を移してください。

V2Fly形式の内蔵DNS設定例です。Xrayでの対応状況は、使用するコアに合わせて確認してください。通常のUDPリゾルバーと問い合わせ方針の構造を示すものであり、暗号化されたDNSを自動で使う設定でも、問い合わせ通信のアウトバウンド経路を設定するものでもありません。アドレスは現在のネットワークからの到達性と管理要件に応じて選び、設定を統合した後は生成された設定、ルーティング、ログも確認してください。

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "port": 53
      }
    ],
    "queryStrategy": "UseIP"
  }
}

用途に合わせて名前解決の方針を選ぶ

直接接続する通信では、名前解決の結果がローカルの出口から到達できる必要があります。プロキシ経由の通信では、名前解決を行う場所が出口側のネットワークと整合するかも考慮します。リゾルバーの位置によって接続先アドレスを返すサービスもあり、名前解決に成功しても接続が不安定になることがあります。ドメインごとにリゾルバーを選ぶ場合は、まず対象を明確に絞り、分かりやすい範囲を指定してからルール集合に広げてください。「名前解決に失敗した場合のフォールバック」と「ルーティングに応じた振り分け」は、条件も問い合わせ経路も異なるため混同しないようにしましょう。

ドメイン形式の暗号化DNSアドレスを使う場合は、リゾルバー自身のドメイン名をどうアドレスに変換するかも考慮します。これはブートストラップ名前解決と呼ばれることがあります。まだ確立していないプロキシを経由しなければならず、そのプロキシのアドレスも同じリゾルバーに依存していると、起動時の依存関係が循環します。ブートストラップの経路を明確にするか、クライアントが備える独立した起動時DNS設定を使ってください。予備サーバーを増やすだけでは循環を解消できません。追加したサーバーも同じ依存関係に陥る可能性があります。

IPv4とIPv6はそれぞれ個別に確認してください。両方のアドレスが返されても、どちらのアドレスファミリーでも通信できる出口があるとは限りません。OSが優先するアドレスがクライアントの想定と異なる場合もあります。一部のサイトだけ表示に時間がかかる、特定のネットワークでのみ失敗するといった場合は、IPv6ルートとプロキシサーバーのアドレスファミリー対応を確認します。IPv4のみを返す設定は比較テストに使えますが、長期的な方針はネットワーク環境に合わせて決め、ほかのアプリへの影響も記録してください。

問い合わせ結果と接続結果を照合する

次のコマンドは、OSの標準的な問い合わせ経路で得られる結果を確認するためのものです。プロキシコアがどのリゾルバーを使ったかを、これだけで証明することはできません。実行時に応答したサーバー、アドレスファミリー、エラー情報を記録し、クライアントログの名前解決イベントと照合してください。コアが該当する問い合わせを行っていない場合は、キャッシュが使われたか、アプリがすでにアドレスを渡した可能性があります。設定を変える前に理由を確認しましょう。

nslookup example.com

キャッシュは段階的に消去します。まず対象アプリを再起動し、次にOSの手順に従ってシステムの名前解決キャッシュを消去し、最後に関連するコアを再起動します。同じテスト中にネットワークを切り替え、リゾルバーを変更し、端末も再起動すると、どの変更が結果に影響したか分からなくなります。名前解決できるのに接続できない場合は、アウトバウンドの到達性、証明書の時刻、宛先ポートを確認してください。名前解決がタイムアウトする場合は、問い合わせ経路とリゾルバーへの到達性を調べます。この2種類の障害に同じ対処を適用しないでください。

企業ネットワークやLAN内の専用ドメインでは、社内リゾルバーや検索ドメインが必要な場合があります。すべての問い合わせをパブリックリゾルバーに送ると、社内サービスを名前解決できなくなることがあります。内部ドメイン用の経路を明示し、短い名前と完全修飾ドメイン名の両方をテストしてください。インターネット接続は正常なのに社内サービスが開けない場合、プロキシサーバーやグローバルルーティングを変更する前に、検索ドメインが失われていないか確認しましょう。

TUNモードと取り込み範囲

TUNは仮想ネットワークインターフェースを使い、選択した通信をユーザー空間のコンポーネントに渡して処理します。システムプロキシ設定に従わないアプリにも適しています。変更されるのは通信の入口とルーティング範囲であり、すべてのプロトコルや宛先に自動で接続できるようになるわけではありません。TUNに入った接続も、名前解決、ルールのマッチ、アウトバウンドによる処理が必要です。TUNを使うべきかどうかは、対象アプリがプロキシに対応しているかを基準に判断してください。あらゆる接続問題を直す汎用スイッチではありません。

問題が起きても戻せる手順で有効にする

有効にする前に、通常のシステムプロキシモードでサーバーが接続できることを確認し、現在のシステムプロキシ状態、DNS設定、LANへのアクセス状況を記録してください。次に、競合する可能性があるネットワーク制御ソフトを終了し、クライアントの指示に従って管理者権限またはネットワーク拡張の権限を付与します。初回はTUNの基本設定だけを有効にし、複雑なDNS、FakeDNS、カスタムアウトバウンドは追加しません。複数の機能を一度に有効にすると、接続できなくなった際に依存関係を切り分けにくくなります。

v2rayNのTUN機能は、仮想インターフェースやルーティングの処理に独立したコンポーネントを使う場合があります。コアの接続ログだけですべての稼働状況を確認できるとは限りません。TUNコンポーネントが起動したか、インターフェースが作成されたか、デフォルトルートが想定どおり変わったかを併せて確認してください。Androidのv2rayNGとv2flyNGは、システムのVPN権限を使って通信の取り込み口を作ります。初回の許可画面では、要求元が現在使っているクライアントであることを確認してください。ほかのVPNサービスが動作中の場合は、使用中のリソースも確認します。

ループを防ぎ、ローカルアクセスを維持する

プロキシサーバー自身への接続を同じプロキシ経路で繰り返し取り込むと、ループになることがあります。クライアントは通常、ルートの除外、インターフェースのバインド、プロセス処理などで防止しますが、ルートを手動で追加した場合、上流をカスタマイズした場合、古い設定を流用した場合は検証が必要です。TUNを有効にすると既存サーバーにも接続できない、ログに似た接続が繰り返し出る、リクエストがタイムアウトし続けるといった症状が現れます。この場合はまずTUNを無効にして基準状態へ戻し、プロキシチェーンを追加し続けないでください。

LANへアクセスするには、ネットワーク層での迂回とコアのルールの両方を考慮します。ルーティングテーブルはデータが仮想インターフェースに入るかを決め、コアのルールは取り込まれた後にどのアウトバウンドを使うかを決めます。片方だけの設定では目的を達成できない場合があります。ルーターの管理画面、LANプリンター、内部ドメインをテストする際は、IPアドレスでのアクセスとドメイン名でのアクセスを別々に記録してください。IPアドレスで接続できて名前で失敗するなら、内部DNSを重点的に調べます。どちらも失敗する場合は、プライベートネットワークのルートと直結ルールを確認します。

アプリ単位の振り分けと宛先単位の振り分けも区別しましょう。Androidのアプリ選択は通常、どのアプリをVPNに通すかを決め、その後、取り込まれた接続をコアのルーティングで処理します。デスクトップでプロセス単位の振り分けができるかは、実際に使うコンポーネントの機能によります。ドメインルールをプロセス分離ルールと混同したり、あるプラットフォームのアプリ除外方法を別のプラットフォームにそのまま適用したりしないでください。アプリごとに通信を分ける場合は、まず入口レイヤーが何に対応しているか確認し、検証できる方法を選びます。

UDP、スリープ、ネットワーク切り替えを確認する

Webページを開けても、関連する通信が使えることを示すだけで、UDPを使うアプリも正常とは限りません。音声通話、リアルタイム通信、一部の名前解決はUDPを使う場合があり、対応状況はサーバー、通信方式、アウトバウンド設定にも左右されます。テストではまず対象プロトコルを確認し、該当する接続がログに出るかを調べます。UDPを使う通信だけに問題がある場合は、UDPの処理と上流側の対応に絞って調査してください。ブラウザーでページが開けるからといって、通信経路の問題を除外しないようにしましょう。

スリープからの復帰、Wi-Fiの切り替え、有線接続の再接続によって、デフォルトゲートウェイ、DNS、インターフェースの優先順位が変わることがあります。TUNを有効にした後は、日常的な状況でも動作を確認してください。まず接続を確立し、ネットワークを切り替えてから、コンポーネントが復旧するか、LANへ引き続きアクセスできるかを観察します。切り替え後に動かなくなった場合は、TUNコンポーネントを再起動して確認します。何度も再現する場合は、「クライアントが切断した」という曖昧な記録だけでなく、インターフェースとルートの変化を記録してください。

元に戻す場合は、まずTUNを無効にしてからクライアントを終了し、システムプロキシが想定どおり復元されているかを確認します。最後に通常のネットワークとローカルサービスをテストしてください。不明な仮想インターフェースを削除したり、ネットワーク設定を広範囲にリセットしたりすると、ほかの正常なソフトに影響することがあります。終了後も問題が残る場合は、OSのネットワーク設定で残存するDNS、プロキシ、ルートを1つずつ確認します。内容を把握できない設定を変更する前に記録し、復元できるようにしてください。

FakeDNSとドメインの対応付け

FakeDNSは実際の宛先アドレスをそのままアプリに返すのではなく、指定したアドレスプールから合成アドレスを割り当て、そのアドレスとドメインの対応関係を内部に保存します。アプリが合成アドレスへ接続すると、取り込みコンポーネントが元のドメインを復元し、ルーティングとアウトバウンド処理に渡します。ドメイン情報を保持できるため、特に透過的な通信の取り込みに役立ちます。パブリックDNSサーバーでも、実際のサービスアドレスの代替手段でもありません。

有効にする前に一連の経路が成立するか確認する

問い合わせと後続の接続が、対応関係を共有できる処理経路に入ることが前提です。アプリが合成アドレスを取得した後、取り込みコンポーネントを経由せず直接接続すると、そのアドレスは意味を失います。問い合わせを生成したコンポーネントと、接続を受け取るコンポーネントが異なり、対応表を共有していない場合も失敗することがあります。DNS一覧に名前を1つ追加しただけで設定完了とは考えないでください。アドレスプールへのルート、入口での受信、ドメインの復元が互いに対応していることを確認する必要があります。

v2rayNのTUNコンポーネントとXray、V2FlyのFakeDNSは、自由に組み合わせられる同一の設定ではありません。コアや補助コンポーネントによって、設定フィールド、アドレスプール、対応関係の有効期間が異なる場合があります。まず実際の通信をどのコンポーネントが処理しているか確認し、それに対応する仕組みを選んでください。クライアントに関連機能の一式がプリセットされている場合は、まずそれを使い、生成結果を確認します。別のコア用フィールドを現在の設定に貼り付けて、不足しているように見える機能を補わないでください。

Xray設定におけるFakeDNS関連の例です。アドレスプールとDNSの選択だけを示しています。単独で動作する設定ではなく、実際の入口におけるドメイン復元設定と、合成アドレスを取り込む経路も必要です。例のアドレス範囲はベンチマーク用のアドレス空間であり、実在するサイトのアドレスではありません。現在のネットワークで同じ範囲を使用している場合は、そのまま流用せず、まず競合を解消してください。

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

アドレスプールと対応関係の有効期間を理解する

ipPoolは割り当て可能なアドレスの範囲、poolSizeはプールの容量を指定します。プール容量はスループットの指標ではなく、同時に維持できる通信数を表すものでもありません。アプリがアドレスを長期間キャッシュする場合があり、コアを再起動すると対応関係が失われることがあります。その後、アプリが古い合成アドレスへ接続しようとしても、新しいプロセスは対応するドメインを特定できない場合があります。関連コンポーネントを有効化、無効化、再起動した後は、対象アプリに再度名前解決させてください。

DNSキャッシュと対応関係のキャッシュで有効期間が異なることは、断続的な障害のよくある原因です。有効化直後は使えるのに再起動後に一部のアプリだけ失敗し、アプリのキャッシュを消すと復旧する場合があります。問題が起きる前にモードの切り替え、コアの再起動、スリープからの復帰があったか記録してください。古いアドレスと対応関係が失われた問題は、プール容量を増やしても解決しません。むしろ既存のキャッシュとの対応を追いにくくすることがあります。

一部のアプリはネットワークの確認、地域判定、独自プロトコル通信のために実アドレスを必要とします。また、独自の暗号化DNSを使い、想定した問い合わせ入口を迂回することもあります。このような互換性の問題がある場合は、特定のドメインやアプリを実アドレスで名前解決する経路にし、接続にも対応するルーティングを設定してください。例外はできるだけ限定し、まず対象を1つ検証してから関連ドメインの集合に広げます。広範囲の通信を除外して、従来のドメイン対応付けが失われないようにしましょう。

名前解決、復元、アウトバウンドを個別に検証する

最初に、対象の問い合わせが合成アドレスを返し、そのアドレスが想定したプール内にあることを確認します。次に、そのアドレスへの接続時にログで対応するドメインが復元されるか確認します。その後で初めて、どのルールとアウトバウンドに一致したかを調べます。合成アドレスが返ったことは、最初の段階が完了したことしか示しません。その後の経路が正常とは限りません。ログに合成アドレスだけが表示され、ドメインが記録されない場合は、実アドレスを対象としたルールを追加する前に、取り込み入口と復元設定を確認してください。

ルーティングにアドレスルールがある場合は、合成アドレスと実際に名前解決されたアドレスを区別してください。合成アドレスを通常の宛先と誤認して地理判定やプライベートアドレス判定を行うと、実際の用途と無関係な結果になります。ルールを設計する際は、どの判定が復元後のドメインを基準にするのか、どの判定に実アドレスが必要なのかを明確にします。アドレスで判定する接続では実際の問い合わせが必要になることもあります。FakeDNSを使えば、あらゆる状況で後続のDNS処理を省略できるわけではありません。

FakeDNSを無効にする場合は、まず通常のDNS設定に戻し、アドレスプールの取り込みを停止してから、対象アプリを再起動し、残ったキャッシュを処理します。無効化後もアプリが合成アドレスへ接続しようとするなら、キャッシュが更新されていません。サーバーを何度も切り替えても、通常は解決しません。復元後は通常のDNSとLAN通信を改めて確認してください。安定して有効化でき、動作を明確に確認でき、完全に終了できる場合に限り、日常設定に取り入れることを検討しましょう。

複数サブスクリプションの管理と更新方針

複数サブスクリプションの管理は、取得元の分離、更新タイミング、復元のしやすさを整えるためのもので、自動ロードバランシングを実現する機能ではありません。複数の取得元を1つのクライアントに追加しても、通常は使用中のサーバーが1つだけで、ほかの項目は候補として残るだけの場合があります。日常利用、予備、履歴保存のどれに使うサブスクリプションかを明確にしてから、グループ分けと更新を設定してください。目指すのは、変更があったときに理由を説明できる状態です。サーバー数をできるだけ増やすことではありません。

取得元ごとに管理し、用途に応じて絞り込む

グループはまず取得元ごとに分け、更新時にどの取得元の項目か分からなくならないようにします。用途はメモ、キーワード、ローカルの絞り込みで管理してください。1つの取得元に複数用途の項目が含まれていても、用途ごとに同じURLを繰り返し追加するのは避けましょう。重複登録は更新リクエストを増やすだけでなく、同じパラメーターが複数箇所に存在する原因になり、切り替え時にどれを管理すべきか分かりにくくします。独立して管理する必要がある場合は、コピーの理由と今後の同期方法を明記してください。

取得元が異なる項目は、名前が同じでも重複と判断できません。同じ名前でもアドレス、ポート、プロトコル、通信設定が異なる場合があり、同じ接続設定に別の名前が付いていることもあります。重複項目を整理する際は、実際の設定と取得元を照合し、先にバックアップを残してください。サブスクリプションから生成された項目を大量に削除すると、次の更新で再び表示されることがあります。まず表示上の絞り込みを使うか、取得元が対応していれば提供側のサブスクリプション設定を変更してください。

取得元ごとに、用途、更新方法、既存のプロキシ接続が必要かを記録しておけば十分です。通常のメモに認証情報を含む完全なURLを保存する必要はありません。アカウントの期限切れ、認証情報の変更、プランの変更によって一覧が変わることがありますが、クライアントは名前だけからそうした状態を判断できません。項目が大量に消えた場合は、古い設定を復元する前に、その取得元の応答とアカウント状態を確認します。以前の一覧を復元しても、利用できなくなったリモートサービスが再び使えるとは限りません。

実際の変更頻度に合わせて更新する

自動更新の間隔は、取得元の更新頻度とクライアントの利用状況に合わせて設定し、過度に短くしないでください。リモート側の一時的なエラーに対して再試行を繰り返すと、リクエスト制限を招いたり、ログが読みにくくなったりする可能性があります。自動更新を初めて設定したら、一連の動作を確認し、ネットワークがまだ準備できていない場合の失敗処理と、使用中のサーバー選択への影響を確かめてください。クライアントが起動していない場合や、OSによってバックグラウンド動作が制限されている場合は、スケジュールどおりに実行されるとは限りません。

プロキシ経由の更新と直接更新は、異なるアクセス経路として扱い、それぞれの依存関係を把握してください。使用中のサーバーが更新対象のサブスクリプションから取得されていて、そのサーバーがすでに使えない場合は、プロキシ経由の更新も失敗する可能性があります。別の正常な取得元のサーバーに切り替えてから問題のグループを更新するか、直接接続できる場合は直接更新を個別に試します。すべてのグループの更新方法を一度に切り替えると、特定の取得元の問題か共通のネットワーク経路の問題か判断できません。

更新前後のサーバー数の変化は、問題の調査に役立ちますが、数そのものはサービス品質の指標ではありません。より重要なのは、使用中の項目が残っているか、パラメーターが変わったか、手動メモが保持されたか、重要な業務を継続できるかです。更新に成功したら、一覧を整理する前に実際の業務を確認してください。更新時に選択中の項目を保持する機能がある場合も、実際に保持されるか確認しましょう。名前が同じだからといって、同じサーバーだとは限りません。

速度測定、切り替え、実際の通信確認を分ける

遅延テスト、接続テスト、実際のサービスへのアクセスは、それぞれ異なるものを測定しています。1回のテストで接続できても、長時間接続、UDP、特定のドメインが利用できるとは限りません。テストの失敗も、対象や名前解決経路が原因の場合があります。複数のサブスクリプションを使う場合は、並列処理による影響を抑えるため、グループごとに分けてテストし、最後に実際の業務で確認してください。1回の順位付けを長期的な選択基準にしたり、一覧での表示順をクライアントが自動切り替えした証拠と見なしたりしないでください。

使用中のサーバーを手動で切り替えても、以前の接続が古い経路を使い続けることがあります。予備サーバーを確認する際は、新しいテスト接続を確立し、ログのアウトバウンドと宛先を調べてください。カスタムルーティングや固定アウトバウンドを設定している場合、一部の通信はメインサーバーの切り替えに追従しないことがあります。これは設定した方針によるもので、切り替えの失敗とは限りません。「メインの選択に従う通信」と「出口を固定する通信」を簡潔に記録し、問題発生時の誤認を防ぎましょう。

バックアップには、グループ設定、手動項目、ローカルルールを含め、アクセスを適切に制限してください。復元する際は、まず基本設定をインポートし、取得元ごとに動作を確認してから複雑なルールを戻します。古い環境の設定全体を、現在使える状態へそのまま上書きしないでください。取得元を無効にする場合は、まず更新を停止し、使用中の設定から参照を外して、依存関係がないことを確認してから削除できます。この手順なら、必要なときも範囲を明確にして復元でき、すべてのサブスクリプションを一から整理し直さずに済みます。

カスタムアウトバウンドと設定の復元

アウトバウンドは、コアが接続を次のネットワーク区間へ送る方法を示し、ルーティングは使用するアウトバウンドを選択します。通常のサーバー切り替えでは、クライアントが対応するアウトバウンドを生成します。カスタムアウトバウンドは、出口の固定、明確な直結や拒否の方針、ローカルプロキシサービスとの連携が必要な場合に適しています。手動編集を始める前に、通常の設定では必要な方針を実現できないか確認してください。画面から安定して管理できる設定を、別のカスタム設定に重複して記述する必要はありません。

設定を管理するコンポーネントを確認する

v2rayNは起動時やサーバー切り替え時に実行設定を再生成することがあり、一時的に生成されたファイルを直接編集しても変更が保持されるとは限りません。クライアントがサポートするカスタム設定の入口から管理し、「完全な設定」と「追加する断片」のインポート方法を区別してください。完全な設定には必要なすべての入口とアウトバウンドが必要です。断片は統合ルールに依存します。入口を間違えると、既存の構造を上書きする可能性があります。編集前に動作中の設定を保存し、復元時にどのファイルをインポートするか確認してください。

XrayとV2Flyには、入口、ルーティング、アウトバウンドなど共通する概念がありますが、プロトコル対応やフィールドの詳細は異なる場合があります。TUN補助コンポーネントも別の設定構造を使うことがあります。どちらもJSONだからといって、コンポーネント間で互換性があるとは限りません。実際に起動するコアを確認し、フィールドの用途を照合してください。クライアントとコアの役割分担については、Project V、V2Fly、Xrayのエコシステムと関係をご覧ください。クライアント名だけから、すべての内部機能を推測しないようにしましょう。

Xrayでよく使われる2種類のアウトバウンドの例です。freedomは宛先へ直接接続し、blackholeは接続を破棄します。タグはルーティングから参照できます。プロキシサーバー用のアウトバウンドは含まれていないため、アウトバウンド一覧全体の代わりにはなりません。直結を一覧の先頭に置き、該当ルールの包括的な方針を設定しないと、どのルールにも一致しない通信が直結になる可能性があります。追加と並び順の両方を確認してください。

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

タグでルールとアウトバウンドを接続する

タグは短く、重複せず、用途が分かる名前にしてください。タグを変更する際は、ルーティング、チェーン転送、その他の参照箇所も合わせて確認します。アウトバウンド名だけを変更して参照を直さないと、起動に失敗したり、実行時にルーティングが異常になったりすることがあります。アウトバウンドを追加したら、まずドメインを限定したルールを1つ作ってテストし、広範囲の集合をすぐに割り当てないでください。タグの参照、接続経路、ログが想定どおりであることを確認してから、段階的に適用範囲を広げます。

ローカルのSOCKSサービスと連携する場合は、指定したアドレスとポートで実際に待ち受けていることを確認してから、対応するアウトバウンドを追加します。同じ端末からの接続には、ループバックアドレスでの待ち受けが適しています。手軽だからといって、すべてのネットワークインターフェースに公開しないでください。コンテナや別のネットワーク名前空間では、ループバックアドレスの意味も変わります。接続拒否が発生したら、ルーティング集合を変更する前に、待ち受けプロセスとアドレス範囲を確認します。タイムアウトする場合は、ファイアウォールと経路の到達性も調べてください。

プロキシチェーンは依存関係を増やします。前のホップに到達できなければ後続の出口を確立できず、いずれかのホップが対象プロトコルに対応しなければ、一部の通信だけ失敗することもあります。複数のサブスクリプション項目を配列に並べただけでチェーンができるわけではありません。配列の順序は、チェーンの構成を意味しません。転送の仕組みは使用するコアの対応状況に合わせて設定し、自己参照がないか確認してください。認証が必要な例はローカル環境で安全に入力し、実際の認証情報を公開設定の説明に含めないでください。

構文、参照、接続の3段階で検証する

最初に、カンマ、引用符、括弧、フィールドの型など、JSONの構文を確認します。次に、タグの存在、プロトコルフィールドの対応状況、ルールデータの読み込みなど、設定内の参照関係を確認します。実際の接続を調べるのはその後です。構文検証に通っても、ファイルを解析できることしか分からず、サーバーへの到達性やルーティングが意図どおりとは限りません。クライアントに設定テスト機能がある場合は、起動前に実行してください。失敗した場合は、後続のログに埋もれないよう、最初に出た重要なエラーを記録します。

ログレベルは調査に必要な期間だけ変更してください。詳細ログは接続経路の特定に役立つ一方、アクセス先やネットワーク情報を記録することもあります。保管する範囲を制限し、調査後は通常のレベルに戻してください。ログを共有する前に、サブスクリプションURL、ユーザー識別情報、認証情報を削除します。コアが起動しない場合は、まず設定テストの出力を確認します。起動するのに一部の接続だけ失敗する場合は、対象を限定して再現させてください。原因を特定する前に、クライアントを再インストールしたり設定全体を書き換えたりしないでください。

変更する前に、元に戻す手順を用意します。動作する基準設定を保存し、今回追加するフィールドと期待する結果を記録し、クライアントの自動生成モードへ戻す方法を明確にしてください。変更を1つ加えるたびに、通常のアクセス、個別ルール、LAN、終了後のシステムネットワークをそれぞれ検証します。追加したルールだけに問題がある場合は、そのルールを取り消します。コア全体が起動しない場合は、基準設定一式を復元してください。小さな単位で戻せば、確認済みの設定を保ったまま調査を続けられ、一括リセットより原因を追いやすくなります。

システムのアップグレード、コアの変更、クライアントの移行後は、同じ検証手順をもう一度実施してください。以前のフィールドが使えなくなったり、デフォルト値が変わったりすることがあります。設定ファイルを読み込めるだけで、動作も以前と同じだと判断しないでください。各カスタム設定が解決する問題、依存するコンポーネント、検証対象を簡潔に記録しておきます。用途がなくなった設定は削除して再テストし、長期的に保守する設定を説明可能で、復元しやすい状態に保ちましょう。