V2Ray 詳細設定ガイド

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

サブスクリプションのグループ化で管理するのは設定の取得元であり、通信の経路ではありません。通常、各グループにはサブスクリプションURL、表示名、更新オプション、絞り込み条件を保存します。サーバー一覧は、サブスクリプションの更新後に生成されるものです。サーバーを別の表示グループに移しても、特定のアプリにプロキシルールが設定されるわけではありません。設定を始める前に、取得元の管理、使用するサーバーの選択、ルーティングによる振り分けを区別しましょう。設定すべき場所を取り違えないためにも重要です。

取得元ごとに管理しやすいグループを作る

v2rayNのサブスクリプショングループ設定で、取得元ごとに個別の項目を作成します。名前は「用途－取得元」の形式にし、「普段使い－メイン」「テスト－予備」などにすると分かりやすくなります。サブスクリプションURLを省略せずに貼り付け、前後の空白や改行がないことを確認します。保存後は該当グループだけを更新し、最初からすべての取得元を一括更新しないでください。まずそのグループの更新結果を確認し、サーバーが生成されることを確かめてから、ほかの購読先を追加します。

サーバー名は接続先が付けたメモにすぎず、機能を保証するものではありません。名前に記載された地域、回線、倍率などは、プロトコル項目の確認に代わるものでも、実際の接続元の所在地を保証するものでもありません。サーバーを選ぶ際は、プロトコル、伝送方式、暗号化とセキュリティの設定がコアの対応範囲内かどうかも確認してください。コアを選ぶときは、まずXrayとV2Flyのコアの違いを読み、残す設定を判断しましょう。

一時的な検索と継続的な絞り込みを分ける

一覧の検索は通常、現在の表示だけを変えます。検索語を消せば、サーバーは再び表示されます。一方、サブスクリプションの絞り込みは、次回の更新で実際に取り込まれる項目にも影響することがあります。両者は、検索を解除したときに元のサーバーが再表示されるかどうかで見分けられます。継続的な絞り込みを有効にする前に、絞り込み前の一覧を記録し、動作確認済みのサーバーを少なくとも1台残しておきましょう。そうしないと、条件の誤りで一覧が空になったとき、購読先の障害と誤認するおそれがあります。

クライアントによっては絞り込み欄で通常のキーワードを使い、別の場所では正規表現を使います。入力欄の名前だけで判断しないでください。正規表現を使うと明記されている場合、テスト|予備はどちらか一方の語句に一致します。ただし、一致した項目を残すか除外するかは、そのオプションの意味によります。まず確実に存在するサーバー名を使って試し、問題がないことを確認してから範囲を広げましょう。実装ごとに正規表現の対応が異なるため、最初から複雑な先読み・後読みを使うのは避けてください。

更新後に重複、消失、選択状態を確認

サブスクリプションの更新では、項目が再生成されたり、クライアントの仕様に応じて既存の項目と統合されたりする場合があります。そのため、選択中のサーバーが更新後も変わらないとは限りません。更新後は、選択中の表示に続いてプロトコル設定と接続可否を確認しましょう。長期的に残したい手動追加の項目は、独立したローカルグループに入れるか、更新前にバックアップをエクスポートしてください。接続先が付けたサーバー名を変更して個人設定を保存するのは避けましょう。次回の更新で上書きされる可能性があります。

更新が成功したのにサーバーが見つからない場合は、一覧の検索語を消し、現在のグループを確認してから、サブスクリプションの絞り込みを一時的に解除します。そのうえで、応答内容をクライアントが認識できるかを確認してください。更新に失敗しても、元のグループをすぐに削除しないでください。既存のサーバー一覧はまだ使える可能性があります。Androidでも、まずサブスクリプショングループと現在の表示を区別しましょう。v2rayNGとv2flyNGではメニューの場所が異なりますが、どちらも「グループを個別に更新し、結果を確認してからサーバーを選ぶ」手順が基本です。取得元を明確にしておけば、どの更新で設定が変わったのか後から追跡できます。

ルーティング設定の実例

ルーティングとは、通信がコアに入った後、使用するアウトバウンドを選ぶ処理です。判定には、宛先ドメイン、宛先アドレス、ポート、ネットワーク種別、インバウンドのタグなどが使われます。クライアントの「ルールモード」は通常、あらかじめ用意されたルーティング設定を選ぶものであり、コアがアプリの用途を自動で理解する機能ではありません。独自ルールを作る前に、現在有効な設定を確認し、既存ルールをバックアップしてください。エディターでルールを保存しただけでは、実行中のコアに読み込まれていない場合があります。

ルールの評価順と条件の組み合わせ

通常、ルーティングルールは上から順に評価され、最初に一致したルールでアウトバウンドが決まります。そのため、具体的なルールを広い条件のルールより上に置きます。たとえば、プロキシを使う完全一致のドメインを先に置き、次にLANのアドレスを直結にし、最後に既定の動作を設定します。同じルール内の異なる条件はすべて満たす必要がある場合が多く、同じ条件項目に指定した複数の値は、いずれかに一致すればよい場合が一般的です。ドメイン、ポート、ネットワーク種別を1行にすべて設定すると、独立した3種類の一致条件が増えるのではなく、対象が絞り込まれます。

ドメインの照合方法にも粒度の違いがあります。完全一致は単一のホストに、ドメインとサブドメインの一致はサービス全体に適しています。キーワード一致は、名前が似ている別のサイトまで誤って対象にすることがあります。まず最小の範囲で確認し、必要に応じて段階的に広げましょう。ダウンロード用ドメインの問題を直すために、すべての通信をプロキシにするのは避けてください。一時的にアクセスできても、広すぎるルール、依存先ドメインの不足、DNS経路の誤りが見えなくなることがあります。

明確なルールを1つ作って検証する

以下は、よく使われるXrayのJSONルーティング項目を抜粋した例です。完全一致のドメイン、プライベートアドレス、アウトバウンドのタグの関係を示しています。クライアント設定全体ではないため、既存の実行設定に統合し、proxyとdirectのアウトバウンドが定義済みであることを確認してください。例示のドメインは照合方法を説明するためのものです。実際の検証では、対象とするドメインに置き換えてください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

AsIsは、IPルールのためにドメインを積極的に解決しません。ただし、接続に最初から宛先IPが含まれている場合は、IPルールに一致することがあります。ドメイン接続がドメインルールに一致しなかった場合、プライベートアドレスのルールを記述しただけで、必ず先に名前解決してLAN内かどうかを判定するわけではありません。LAN内のドメインを処理するには、明示的なドメインルールを追加するか、名前解決への影響を理解したうえで別のドメイン戦略を選んでください。geoip:privateを使う場合は、対応するデータファイルを読み込める必要があります。ファイルが見つからないときは、まず読み込みエラーを解消してください。

フォールバック、スニッフィング、既存の接続

どのルールにも一致しない場合、コアは通常、アウトバウンド一覧の先頭を使用します。クライアントが追加の最終ルールを生成することもあります。画面の最後の行だけでなく、実際に生成された設定を確認してください。特定のアウトバウンドを一律にフォールバック先にしたい場合は、クライアントの最終アウトバウンド設定を利用できます。手動で設定するときは、対象となるインバウンドやネットワーク種別を明示し、意味が曖昧な空条件を避けましょう。既定のアウトバウンドの順序を変えると、これまでルールに一致しなかった通信の経路も変わることがあります。

スニッフィングは、一部の接続からHTTPのホスト名やTLSのサーバー名を取得できますが、すべての暗号化プロトコルを識別できるわけではありません。暗号化されたハンドシェイク情報によってドメインが見えないこともあります。DNSの代替ではなく、追加の情報源として利用してください。ルールを変更した後は、新しい接続を作ってテストしましょう。既存の長時間接続は自動で経路が切り替わらないのが一般的です。必要に応じてテスト中のアプリを終了して再起動してください。同じページを何度も再読み込みするだけでは十分な確認になりません。

ルールが機能しない場合は、まず通信がクライアントに入っているか確認します。次に、ルールが有効か、対象が条件に一致しているか、前により広いルールがないか、アウトバウンドのタグが正確かを確認してください。システムプロキシモードでは、システムプロキシに従わないアプリの通信はルーティング処理に入りません。ここまで確認しても解決しない場合は、ヘルプセンターのプロキシモードの説明を参照し、まず通信の入口を確認してからルールを調整しましょう。

DNS設定の最適化

DNS設定では、ドメインを誰が解決するのか、また名前解決のリクエストをどのネットワーク経路に流すのか、という2つの点を考える必要があります。ブラウザー、OS、クライアントのコア、接続先サーバーが名前解決に関わることがあります。Webサイトにアクセスできても、すべてのアプリが同じ経路で名前解決しているとは限りません。システムDNSを変更しても特定のアプリに変化がない場合、設定に失敗したとは限りません。アプリが独自の暗号化DNSを使っていたり、別のキャッシュを保持していたりする可能性があります。

まず名前解決の経路を整理する

システムプロキシでは、アプリがドメインをローカルプロキシに渡し、その後アウトバウンドや接続先で名前解決する場合があります。一方、本機で先にIPアドレスを解決し、そのIPをプロキシに渡す場合もあります。TUNモードでクライアントがDNSを制御するかどうかは、仮想インターフェイス、DNSのリダイレクト、アプリのリクエスト方法によって異なります。最適化を始める前に、現在のシステムリゾルバー、クライアントのDNS設定、ブラウザーのセキュアDNS設定を記録してください。一度に一か所だけ変更すれば、どの層が結果に影響したのか確認しやすくなります。

プロキシサーバーへの接続に使うドメインは、特に重要です。クライアントはサーバーを見つけて初めて、その後の通信を送信できます。サーバーのドメイン解決を、まだ確立していないプロキシ経由にすると、起動時の依存関係が循環するおそれがあります。サーバーアドレスには到達可能な初期解決経路を確保し、直結条件を明確にするのが安全です。プロキシが切断されても必要なサーバー名を解決できなければ、再接続に失敗し続けることがあります。

ドメイン戦略とアドレスファミリー戦略を区別する

ルーティングのdomainStrategyは、IPルールとの照合のためにドメインを解決するかどうかに影響します。DNSのqueryStrategyは、クエリで使うアドレスファミリーに影響します。また、直結アウトバウンドのドメイン戦略は、実際の接続前にドメインをどう処理するかを決めます。これらは設定場所が異なるため、名前が似ているからといって置き換えることはできません。以下は内蔵DNSの最小限の抜粋例です。まずシステムリゾルバーを基準にし、複雑なDNS振り分け設定が原因かどうかを切り分けます。

{
  "dns": {
    "servers": ["localhost"],
    "queryStrategy": "UseIP"
  }
}

この設定例だけで、システム内のすべてのDNSリクエストが自動的に処理されるわけではありません。また、すべてのアウトバウンドが内蔵リゾルバーを使うとも限りません。実際の呼び出しはルーティング方針、アウトバウンド設定、クライアントとの連携方法によって決まります。元の設定にドメインで絞り込むリゾルバー項目がある場合、DNSオブジェクト全体を置き換えるとルールが消えるため、まず元の設定をエクスポートしてください。基本状態に戻して問題が解消したら、元のサーバーと絞り込み条件を一つずつ追加します。

IPv6、キャッシュ、LAN内ドメインへの対処

デュアルスタック環境では、まずIPv6が実際に到達可能かを確認します。ローカルネットワーク、プロキシサーバー、接続先サービスのそれぞれで確認が必要です。IPv6アドレスが返ってきても、接続できるとは限りません。ログにアドレスファミリーに関する接続エラーが続く場合は、比較のため一時的にIPv4に限定してもかまいません。ただし、IPv6の恒久的な無効化を、あらゆるDNS問題に対する一般的な解決策にしないでください。比較後は制限を残すか判断し、もともと使えていたLAN内サービスに影響しないか確認します。

社内LAN、ルーターの管理用ホスト名、デバイス検出名は、ローカルの名前解決環境に依存することがあります。すべてのドメインをパブリックDNSに送ると、これらの名前が解決できなくなる可能性があります。LAN内のドメインにはシステムまたは指定したローカルリゾルバーを使い、対象への通信が直結するようにしてください。DNSを変更した後は、システムとアプリでキャッシュの有効期間が異なることにも注意が必要です。リゾルバーを何度も切り替えるより、テスト対象のアプリを再起動したほうが有効な場合があります。既存の接続では、再度ドメインを問い合わせないこともあります。

トラブル対処では、「クエリがタイムアウトする」「返されたアドレスが適切でない」「アドレスは正しいが接続できない」を分けて記録します。クエリのタイムアウトではリゾルバーへの到達性とリクエストの経路を、アドレスが適切でない場合は絞り込みルールとキャッシュを確認します。接続できない場合は、アウトバウンド、接続先ポート、ネットワーク環境を調べます。暗号化DNSはクエリの転送方法を変えるものであり、ルーティングの誤りを自動で直したり、到達不能なサーバーに接続できるようにしたりするものではありません。

TUNモードとシステムネットワークの制御

TUNは仮想ネットワークインターフェイスを通じてIP層の通信をユーザー空間に渡す仕組みです。システムプロキシに従わないアプリも含め、通信を一元的に振り分けたい場合に適しています。ただし、「より強力な全体プロキシ」のスイッチではありません。TUNに通信が入った後も、ルーティングルールで直結かプロキシかを決める必要があり、アウトバウンドのプロトコル、UDP対応、DNSの処理方法にも左右されます。システムプロキシとTUNでは通信の入口が異なります。まず個別に動作を確認し、併用が必要かどうかを判断してください。

制御コンポーネント、権限、基本動作を確認する

v2rayNのTUN機能は、付属コンポーネントが処理を担う場合があります。GUIのTUNスイッチを、Xrayに同名の項目を追加する機能だと考えないでください。始める前に通常のプロキシモードを安定させ、現在のサーバーが使えることを確認します。その後、クライアントが要求する実行権限、コンポーネントの状態、ログを確認してください。AndroidのVPN許可は通信を制御するための許可であり、デスクトップとまったく同じ仮想インターフェイスの実装や設定形式を使うという意味ではありません。

初めて有効にする際は、設定を復元できるローカルの操作手段を確保してください。まずネットワークを制御しているほかのツールを終了し、現在のWi-Fiまたは有線ネットワークのDNSとプロキシ設定を保存してからTUNを有効にします。仮想インターフェイスが作成されたか、既定ルートが変わったか、テスト通信がログに記録されるかを確認しましょう。有効と表示されているのに接続記録がない場合は、サーバーをすぐに変更せず、まずインターフェイスとルートを調べてください。

ループを防ぎ、LANへのアクセスを保つ

プロキシクライアントからサーバーへの接続まで、再び自分自身のプロキシ対象にすると、ループや再試行の繰り返しが発生します。一般的な制御コンポーネントには自動ルーティングやインターフェイスのバインド機能がありますが、手動でルートを変更すると、その保護が損なわれることがあります。TUNを有効にした直後にプロキシが切断される場合は、まずサーバーアドレスが誤ってTUNに取り込まれていないか、複数の仮想インターフェイスが既定ルートを取り合っていないかを確認してください。

LAN内の機器、プリンター、ルーターの管理画面は、通常直結が必要です。ただし、プライベートアドレスのルールだけでは機器検出までカバーできるとは限りません。ブロードキャスト、マルチキャスト、名前による検出は別の仕組みであり、仮想ネットワークを通過できるかは実装とシステム環境によります。機器のIPアドレスではアクセスできるのに名前で見つからない場合は、プロキシ範囲を広げ続けるのではなく、DNSや検出プロトコルを調べましょう。社内ネットワークではプライベートアドレスがローカルのサブネットと重なることもあるため、ルーティング範囲をより具体的に指定する必要があります。

TCP、UDP、アプリの範囲を段階的に検証する

まず明確なTCPリクエストで通信の入口とアウトバウンドを確認し、その後、実際に必要なUDPアプリを検証します。Webページは開くのに音声通話やリアルタイム通信に失敗する場合は、UDP転送、サーバー側の機能、ネットワークポリシーが原因かもしれません。TUN全体の障害とは限りません。アプリでQUIC関連の問題が起きた場合も、UDPの経路を個別に記録してください。アプリの該当機能を一時的に無効にするのは比較用のテストにすぎず、基盤となる転送機能の確認に代わるものではありません。

システムプロキシとTUNの同時使用は、クライアントが想定した動作の場合もあれば、アプリがまずローカルプロキシに接続し、その接続をTUNが再度取り込んでしまう場合もあります。トラブル対処の段階では、動作が分かっている入口を一つだけ使い、確認後に併用設定へ戻すことをおすすめします。Androidでアプリを除外すると、そのアプリはクライアントのルーティングを完全に迂回することがあります。そのアプリの接続結果でコアのルールを検証することはできません。省電力によるバックグラウンド制限で通信制御が切れることもあるため、プロセスの終了とサーバーの切断を区別してください。

TUNを無効にした後もネットワークが復旧しない場合は、まず仮想インターフェイス、既定ルート、システムDNSが元の状態に戻ったか確認します。次に、停止済みのローカル待受ポートをシステムプロキシが参照したままになっていないか調べてください。ネットワークアダプターをすべて削除したり、ネットワーク設定をすべてリセットしたりするのは避けましょう。影響範囲が広がります。今回追加したネットワーク制御設定だけを元に戻し、現在のネットワークに再接続するほうが、既存の社内ネットワークやローカル機器の設定を残しやすくなります。

FakeDNSの仕組みと利用範囲

FakeDNSは、ドメインに対してローカルで対応付けるための合成アドレスを返します。その後、接続がプロキシの処理経路に入った時点で、その対応関係を使って元のドメインを復元します。これは「アプリがドメインをIPに解決した後でも、ルーティングではドメインを判定したい」という情報の保持に使うもので、接続先サイトに実際のアドレスを割り当てる機能ではありません。合成アドレスを利用できるのは、対応する通信制御とマッピングの経路内に限られます。通常のネットワーク機器は、そのアドレスがどのドメインを示すのか分かりません。

問い合わせ、マッピング、接続時の復元を一連の流れにする

通信経路には、少なくとも3つの段階が必要です。アプリがドメインを問い合わせて合成アドレスを受け取り、そのアドレスへ接続し、通信制御コンポーネントがアドレスからドメインを復元して後続のルーティングに渡します。最初の段階だけを有効にすると、アプリは直接接続できないアドレスを受け取るおそれがあります。ドメインのスニッフィングを有効にしただけで、FakeDNSのマッピングが必ず復元されるわけでもありません。クライアントが提供する統合オプションを使い、DNSと通信制御を互換性のあるコンポーネントが連携して処理しているか確認してください。

v2rayNでは、ネットで見つけたコア設定の断片をすべての設定欄に貼り付けるのではなく、現在のTUNコンポーネントが対応機能を提供しているか確認してください。v2rayNG、v2flyNG、デスクトップ版では連携方法が異なることがあり、対応状況はコアとクライアントの実装によって決まります。メニューに機能がない場合、項目を1つ追加するだけでインターフェイス、DNSリダイレクト、アドレス復元の全経路が整うと考えないでください。

アドレスプールとマッピング容量を理解する

以下は、よく使われるXrayのFakeDNSオブジェクト形式を示した例です。合成アドレスのプールには、テスト専用のアドレス範囲を使っています。これは構文の一部を示す例であり、そのまま実行できる通信制御設定ではありません。内蔵DNSからFakeDNSを呼び出し、対応するインバウンドでマッピングを復元する必要もあります。現在のクライアントが別の通信制御コンポーネントを使っている場合は、そのコンポーネント独自の構文を使い、設定項目を混在させないでください。

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

ipPoolはマッピングに使用できる合成アドレスの範囲を、poolSizeはマッピングプールの容量を決めます。並列接続数ではなく、値を大きくすれば速くなるわけでもありません。設定前に、合成ネットワークが現在のテスト環境や特殊なルートで使われていないことを確認してください。家庭内でよく使われるLANのアドレス範囲を安易にプールに使わないでください。実際の機器のアドレスと合成アドレスが重なり、一部の機器に突然アクセスできなくなることがあります。

マッピングの有効期間も考慮してください。コアの再起動後に以前のマッピングが消えても、システムやアプリには古い合成アドレスがキャッシュされている場合があります。その状態で新しい接続がクライアントに入っても、対応するドメインを復元できず、「有効にした直後は動くのに、再起動後に一部のアプリが失敗する」ことがあります。アプリにDNSを再問い合わせさせ、必要に応じて終了して関連キャッシュを消してください。マッピングの有効期間の不一致を隠すためにアドレスプールを広げ続けるのは避けましょう。

実際のアドレスが必要なアプリを見極める

DNSの応答アドレスを検査するアプリ、アドレスと証明書情報を照合するアプリ、解決結果をプロキシを通らない別プロセスに渡すアプリもあります。こうした用途では合成アドレスが適さない場合があります。LAN管理、機器検出、一部のリアルタイム通信、実アドレスの判定に依存するプログラムは、個別に動作確認してください。クライアントがドメインごとの実際の名前解決に対応している場合は、対象に例外を設定できます。その際は、対応するルーティングとDNSリクエストの経路も確認しましょう。

ブラウザー独自の暗号化DNSが想定したFakeDNSの問い合わせ先を迂回し、同じ端末内でもアプリによって実アドレスと合成アドレスが混在することがあります。このような状態になったら、まず各アプリの名前解決方法を記録してください。Webページを開けるというだけで、経路全体が正常だと判断しないでください。少なくとも通常のWebサイト、ドメインによる振り分けが必要な接続先、LAN内アドレス、プロキシに入らないはずのアプリをテストします。

無効にする際は依存する設定も同時に戻す

FakeDNSを無効にするときは、マッピングプールのスイッチを切るだけでは不十分です。通常の名前解決経路を復元し、クライアントがアプリに合成アドレスを返さなくなったことを確認して、既存のキャッシュも無効にしてください。通信制御を先に止めて合成DNS応答を残すと、アプリは通常のネットワークから合成アドレスへ接続しようとするため、障害が続きます。戻す順番はクライアントの連携方式に従いますが、最終的にDNSの応答と通信制御の方式を一致させる必要があります。

FakeDNSを導入するのは、通常のDNS、ルーティング、TUNが安定してからにしましょう。特定のドメインの振り分けを直すのが目的なら、まず明示的なドメインルールで解決できるか確認してください。ドメイン情報が実際に失われており、通信制御経路で復元できる場合に限り、このマッピングを追加する価値があります。機能の効果はログで説明できるようにし、有効にした後の一度のアクセス速度が速く感じられたかどうかだけで判断しないでください。

複数購読の管理と更新方針

複数購読を管理する目的は、取得元、用途、変更履歴を追跡しやすくすることであり、すべてのサーバーを長い一覧にまとめることではありません。まずメイン、予備、テストの役割を決めましょう。メインは普段使い、予備は手動切り替え用、テストは新しいプロトコルや設定の確認用です。サーバーが別のグループにあるからといって、自動フェイルオーバーができるわけでも、グループ名に応じて通信が自動で振り分けられるわけでもありません。

取得元ごとに独立した管理範囲を設ける

取得元を追加するときは個別のグループを作り、そのグループだけを更新してから、プロトコルの種類、項目名、絞り込み結果を確認します。異なる取得元に同じ名前の項目があっても、取得元の情報は残してください。同じ名前でも同じサーバーとは限りません。アドレス、ポート、伝送パラメーターを比較する場合は、ローカルで作業し、トラブル対処用の資料を共有するときは認証情報を隠します。一覧を整えるためだけに取得元を統合すると、後からどの更新で追加された項目か追跡しにくくなります。

項目の重複は実際の用途を考慮して判断してください。同じサーバーアドレスとポートでも、ユーザー認証情報、伝送経路、セキュリティ設定が異なれば別の設定である可能性があります。名前が異なっても同じサービスを指すことがあります。クライアントの重複排除機能は限られた項目だけで判定する場合があり、手動での確認に代わるものではありません。一括で重複を削除する前にローカルのバックアップをエクスポートし、接続可能な項目を少なくとも1つ残してください。誤って削除すると、取得元から再配信されるまで復旧できないことがあります。

状況を確認できる更新手順を整える

サブスクリプションの更新でサーバー一覧が変わるため、長時間のダウンロード、リモート管理、重要な通信の最中は避けましょう。まず予備またはテストのグループを更新し、問題がないことを確認してからメイングループを更新します。自動更新の間隔を指定できる場合は、実際の変更頻度に合わせてください。更新回数を増やせばよいわけではありません。頻繁なリクエストは取得元の制限にかかる可能性があり、ローカルの一覧が絶えず変わることで、トラブル対処も難しくなります。

サブスクリプションの更新がプロキシ経由かどうかは、個別に確認が必要です。取得元によっては現在のネットワークから直結できますが、既存のプロキシ経路が必要な場合もあります。現在のサーバーに依存して更新していると、サーバーが使えなくなったとき「復旧には更新が必要なのに、更新にも使えない接続が必要」という状態になります。クライアントに更新方法の選択肢がある場合は、取得元の安全性を確認したうえでリクエスト経路を切り替えてください。サブスクリプションURLを、信頼できないオンライン変換サービスに貼り付けて修復を試みるのは避けましょう。

個人設定と取得元の内容を分離する

サブスクリプションから取得するサーバー情報と個人用のルーティング設定は、分けて管理してください。LANの直結ルール、アプリの対象範囲、DNSの例外などは、サブスクリプションから生成された一時設定を直接編集するのではなく、クライアントが対応する独立設定として保存するのがおすすめです。生成ファイルはサーバーの切り替え、サブスクリプションの更新、再起動時に作り直されることがあります。一時ファイルにしか変更がなければ、再生成時に消え、保存されていないと誤解する原因になります。

取得元のサブスクリプションに複雑な設定が含まれる場合もあるため、クライアントがサーバー一覧と完全設定のどちらをインポートするのか確認してください。両者の権限範囲は異なります。サーバー一覧は通常、接続パラメーターを追加するだけですが、完全設定はルーティング、DNS、待受動作まで変更することがあります。インポート前に形式の説明を読み、完了後は実際の実行設定を確認してください。特にLAN向けの待受設定と既定のアウトバウンドに注意し、ファイルの拡張子だけで内容を判断しないでください。

更新失敗時に既存設定を保護して復元する

一度更新に失敗したからといって、すぐに既存の一覧を削除する必要はありません。接続タイムアウト、異常な応答ステータス、空の応答、形式の解析失敗のどれかを確認します。状況によって対処は異なります。既存のサーバーにまだ接続できるなら、いったん残して更新を何度も繰り返さないでください。サブスクリプションURLが変更された場合は、信頼できる情報源から新しいURLを入手し、元のグループ内で置き換えます。意味や状態の似た記録を複数作るのは避けましょう。

予備のサブスクリプションは、独立して動作確認できる点に価値があります。メインの障害が起きてから初めて試すのではなく、普段から更新できるか、利用可能なサーバーがあるか、コアが対応しているかをときどき確認してください。各クライアントの機能範囲については、3つのクライアントのプラットフォームと機能の比較をご覧ください。取得元を分けて管理した後に自動選択や負荷分散を検討すれば、サブスクリプション管理の問題をアウトバウンドの振り分けと取り違えずに済みます。

カスタムアウトバウンドと設定の組み合わせ

アウトバウンドはコアから接続をどう送り出すかを定義し、ルーティングはタグを参照して使うアウトバウンドを決めます。一般的なアウトバウンドには、プロキシプロトコル、直結、ブロックがあります。アウトバウンドオブジェクトを追加しただけでは、通信はその設定を使いません。ルールを一致させるか、既定のアウトバウンドに設定する必要があります。逆に、ルーティングが存在しないタグを参照しても、接続方式が自動で作られるわけではありません。カスタム設定では、まずタグが一致しているか確認しましょう。

まず設定の生成元を確認する

v2rayNの通常のサーバーモードでは、現在の選択内容と画面上の設定から実行設定が生成されます。生成された設定を直接編集しても、次回サーバーを切り替えたときに失われることがあります。カスタムアウトバウンドが必要な場合は、クライアントが明示的に用意している詳細設定画面を優先してください。完全なカスタム設定を使う場合は、どの画面上のスイッチが引き続き有効で、どの項目がカスタムファイルに引き継がれるのかを確認します。2つの管理方式を混在させると、「画面では変更したのに実行結果が変わらない」という問題が起きやすくなります。

Androidクライアントでも、通常の設定編集と完全設定のインポートを区別する必要があります。v2rayNGは主にXrayを、v2flyNGはV2Flyを使用します。どちらも同じサーバー一覧を扱えるからといって、すべてのアウトバウンド項目に互換性があるとは限りません。特定のプロトコルやセキュリティ層のパラメーターを使う場合は、対象コアの対応範囲を確認してください。コミュニティの関係についてはProject Vのオープンソース生態系をご覧ください。クライアント名から内部機能を推測しないでください。

直結とブロックでタグの連携を検証する

以下は、Xrayで使用できる最小限のローカルSOCKS設定です。インバウンド、ルーティング、アウトバウンドのタグの関係を確認できます。直結と例示ドメインのブロックのみで、プロキシサーバーは含みません。待受先はローカルのループバックアドレスに限定し、UDPを無効にしているため、独立したテストに適しています。使用中のメイン設定を上書きしないでください。テスト前にローカルポートが使用中でないことも確認しましょう。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "block"
      }
    ]
  }
}

テストするアプリでは、ドメインをローカルでIPに解決するのではなく、SOCKSプロキシに渡す必要があります。そうしないと、例の完全一致ドメインルールに一致しないことがあります。この設定では、ドメイン情報を補うスニッフィングを有効にしていません。検証条件を明確にするためです。一致しない通信には先頭のアウトバウンド、つまりdirectが使われます。アウトバウンドの順序を変えると既定の動作も変わるため、保守時はタグだけでなく並び順も確認してください。

プロキシアウトバウンドの追加とチェーン接続の理解

プロキシアウトバウンドを追加する場合は、動作確認済みのサーバー設定をもとにし、プロトコル、サーバーアドレス、ポート、ユーザーパラメーター、伝送とセキュリティの設定を保持したうえで、一意のタグを割り当てます。アドレスとポートだけをコピーするのは避けてください。ハンドシェイクの失敗は、伝送経路、サーバー名、セキュリティパラメーターの不一致が原因になることがあります。メインと予備のように、タグごとの役割を明確にすると、ログから実際に使われた接続先を識別しやすくなります。

チェーン接続では、あるアウトバウンドを別のアウトバウンド経由で接続します。2つのルーティングルールを順番に実行することではありません。通常、最初に一致したルールの後、同じ接続が次のルールに渡されることはありません。アウトバウンドの中継項目と伝送方式の対応はコアによって異なるため、対象コアの構文に従ってください。AがBに依存し、BもAに依存する構成や、チェーンの確立前にそのチェーンを使ったドメイン解決が必要になる構成は避けましょう。

負荷分散は候補アウトバウンドから接続先を選ぶ仕組みであり、稼働状況の確認、選択方式、セッション維持も関わります。複数のアウトバウンドを配列に入れただけで自動的に切り替わったり、障害を検出したりするわけではありません。予備サーバーにときどき手動で切り替えるだけなら、手動選択のほうが確認しやすくなります。自動振り分けが明確に必要で、各候補の状態を把握できる場合に限り、複雑な設定を導入してください。

設定の検証、ログの確認、ロールバック

設定を保存できても、起動できるとは限りません。コアが起動しても、対象の通信が想定どおりのアウトバウンドを使うとは限りません。詳細設定は段階的に検証しましょう。まず構文とリソースの読み込み、次にローカルの入口、その後ルーティング、名前解決、リモート接続を確認します。変更前に、「指定した完全一致ドメインだけをプロキシにし、LANは直結する」のように期待する結果を明記してください。テストに失敗したとき、どの層で条件を満たせなかったか判断しやすくなります。

再現可能な変更記録を作る

バックアップにはサーバー一覧だけでなく、サブスクリプショングループ、手動追加したサーバー、ルーティングルール、DNS、通信制御の設定も含めてください。エクスポートファイルには認証情報が含まれる場合があるため、安全な場所に保管します。変更時は、項目名、変更前の値、変更後の値を記録し、クライアントが生成する設定と完全なカスタム設定の違いも残してください。複数の画面上のスイッチで設定が決まる場合は、元に戻す際に見落とさないよう、項目ごとにスクリーンショットを保存するとよいでしょう。

一度に変更するテーマは1つにします。まずサブスクリプションの更新を検証し、次にルーティング、続いてDNSを調整し、最後にTUNとFakeDNSを導入してください。変更後はコアを再起動するか、クライアントの明示的な再読み込み機能を使います。起動に成功したことを確認してから、実際の通信をテストしましょう。同じ作業中にサブスクリプションの更新、コアの切り替え、DNSの変更を同時に行うと、接続が回復してもどの変更が有効だったのか分かりにくくなります。

通信経路に沿ってログを読む

まず、ローカルの入口に接続が届いているか確認します。入口の記録がない場合は、リモートのハンドシェイクを調べるのではなく、アプリのプロキシ設定、ポート、TUNの対象範囲、アプリ単位の除外を確認してください。入口が確認できたら、ルーティング先とアウトバウンドのタグを調べます。タグが違う場合は、ルールの順序と対象情報を見直しましょう。タグが正しいことを確認してから、名前解決、接続開始、ハンドシェイク、サーバーからの応答を確認します。この順序で調べると、見当違いの階層で設定を何度も変える事態を減らせます。

ログの詳細度を一時的に上げる場合は、テスト時間を制限し、終了後に通常のレベルへ戻してください。ログにはアクセス先のドメイン、サーバーアドレス、接続の詳細が記録されることがあります。共有前に情報を隠しましょう。接続タイムアウトは、発生した段階と併せて判断します。名前解決のタイムアウトならDNS、接続開始のタイムアウトならネットワークとポート、ハンドシェイク時の異常ならプロトコル、セキュリティ設定、システム時刻を確認します。最後の1行だけでは、本当の原因が分からないことがよくあります。

一度の速度測定ではなく比較テストを行う

テストには、プロキシが必要な接続先、直結すべき接続先、LAN内アドレス、実際に使用するアプリを含めてください。ルールの変化が既存セッションの再利用で隠れないよう、それぞれ新しい接続でテストします。接続の可否、接続遅延、実際の転送速度はそれぞれ異なることを示します。一度の遅延測定に成功しても、DNS、UDP、大容量ファイルの転送が正常だとは限りません。接続先サービス自身のエラー応答を、すぐにプロキシ設定の問題だと判断するのも避けてください。

特定のアプリだけが失敗する場合は、同じ端末上の別のアプリと比較し、独自DNS、プロキシへの追従方法、キャッシュを確認してください。すべてのアプリで失敗する場合は、システムネットワークとクライアントの入口まで範囲を絞ります。通常のプロキシは動作し、TUNだけが失敗する場合は、同じサーバーを使ったまま入口の方式だけを変えて比較しましょう。サーバーを切り替えても失敗する場合は、サーバーを次々に交換するのではなく、共通するローカル設定を優先して確認してください。

変更を最後に加えたものから順に戻す

ロールバックでは、まず最後に追加した複雑な層を無効にし、その後、以前のルーティングとDNS設定を復元します。FakeDNSを無効にしたら合成アドレスのキャッシュを処理し、TUNを無効にしたらシステムルートとリゾルバーの復元を確認します。クライアントを終了する前に、システムプロキシが停止するポートを参照していないことも確認してください。サブスクリプション更新が原因なら、該当グループのバックアップを復元します。関係のないローカルルールまで削除する必要はありません。ロールバックの範囲を絞るほど、すでに検証できた部分を保ちやすくなります。

問題の原因を特定できない場合は、クライアント名、OS、通信の入口モード、コアの種類、再現手順、情報を隠したログの抜粋をまとめ、実行ログのエラーから原因を特定する方法を参照して順に確認してください。最初の基本設定に戻しても接続できない場合は、クイックスタートガイドに戻り、基本の通信経路を改めて検証します。設定管理の目標はオプションを増やすことではなく、それぞれの設定に明確な用途、確認できる結果、確実に元へ戻す方法を持たせることです。