v2rayN 詳細設定ガイド

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

サブスクリプションのグループ分けでは、まず取得元を整理し、次にサーバーを絞り込みます。通常、1つのサブスクリプションには複数のサーバー情報が含まれます。グループにはサブスクリプションURL、メモ、更新オプションを登録し、個々のサーバー情報にはプロトコル、アドレス、ポート、接続パラメーターを保存します。両者は別の階層です。グループのメモを変更しても、取得元のサーバー情報は変わりません。また、ローカルの情報を削除しても、次回の更新で再び取り込まれる場合があります。特定の情報を継続して除外するには、手動削除を繰り返すのではなく、グループの絞り込みを使いましょう。

見分けやすいグループを作成する

v2rayNのサブスクリプショングループ設定で新しいグループを追加し、まず取得元や用途が分かるメモを入力してから、URL全体を貼り付けます。説明用のURLはhttps://example.com/sub?token=xxxxです。実際に使う際は、自分が利用を許可されたURLに置き換えてください。疑問符以降のクエリパラメーターを削除したり、Webページに表示されたURLをサブスクリプションURLと取り違えたりしないでください。貼り付け後は、先頭や末尾の空白、改行、日本語の句読点が混入していないか確認します。URLに含まれるアクセス用パラメーターは機密情報として扱ってください。

まずはグループを1つだけ作成し、手動で更新することをおすすめします。取り込み後、サーバーのメモ、プロトコル、件数の変化が取得元の説明と一致しているか確認してから、別の取得元を追加してください。グループ名は「取得元の略称／用途」のようにすると分かりやすくなります。現在の速度や一度の測定結果を名前に使うのは避けましょう。回線の状態は変化しても、取得元は一貫して管理できます。スクリーンショット、ログ、設定のバックアップを共有する際は、サブスクリプションのパラメーターを必ず隠してください。URLだからといって公開してよいわけではありません。

自動更新を有効にする前に、そのグループを継続的に同期する必要があるか確認してください。更新時には取得元の内容を読み直すため、サーバー情報が追加・削除されたり、既存項目の接続パラメーターが変わったりすることがあります。サブスクリプションから取り込んだサーバーを手動で変更しても、その変更が恒久的に保持されるとは限りません。特殊なパラメーターが必要な場合は、取得元と変更理由を記録して、独立した設定として保存できます。元のサブスクリプショングループは同期用として残し、同じ項目を取得元の更新とローカルの上書きの両方に依存させないようにしましょう。

絞り込みキーワードと正規表現の注意点

絞り込みは通常、サーバーのメモを対象としますが、具体的な照合範囲や包含・除外の意味はクライアントの画面で確認してください。まず分かりやすい通常のキーワードで結果を確かめてから、正規表現を有効にします。ルーティング用のgeosite:をメモの絞り込み欄に入力しないでください。対象が異なります。絞り込み後の一覧が示すのは、取り込みまたは表示される項目だけです。サーバーへの接続テストに合格したことや、地域ラベルが独自に確認済みであることを示すものではありません。

複数のメモの一部に一致させるには、正規表現の縦棒で「または」を表します。たとえば(実験|予備)です。丸括弧そのものに一致させるには\(予備\)のように記述します。画面で明示的に求められていない限り、スラッシュで囲むプログラム向けの正規表現をそのまま貼り付けないでください。大文字・小文字の扱いや正規表現エンジンは環境によって異なります。テストでは、一致する項目と一致しない項目を1つずつ残し、一覧の件数から推測するのではなく、両方の結果を確認しましょう。

更新失敗と一覧が空の場合を分けて調べる

更新に失敗する場合は、取得または解析の段階で問題が起きています。更新は成功しても一覧が空の場合は、絞り込み条件とサブスクリプションの内容を確認してください。まず絞り込み条件を一時的にすべて解除し、現在のグループだけを更新します。情報が再び表示されたら、キーワードを1つずつ戻してください。それでも空の場合は、取得元が有効なサブスクリプションを返しているか、利用権限が失効していないか、応答がログインページに変わっていないかを確認します。エラーを解消せずに更新を繰り返すのは避けてください。連続リクエストによって取得元でアクセス制限がかかる場合もあります。

ネットワークからサブスクリプションの取得元に直接アクセスできず、確立済みのプロキシ経由でのみ接続できる場合は、クライアントが対応していればプロキシ経由で更新できます。ただし、現在のサーバーとプロキシの入口に依存するため、まだ取り込みに成功していないグループを使って、そのグループ自身の更新経路を構築することはできません。利用可能な設定を残したうえで、直接更新とプロキシ経由の更新のログを分けて確認してください。詳しくはサブスクリプション更新の失敗に関するトラブル対処をご覧ください。公開の相談内容にはURL全体を載せないでください。

ルーティング設定の実例

ルーティングでは、ルールを上から順に照合し、リクエストを既存のアウトバウンドへ渡します。ルールがサーバーを作成したり、利用できない接続を自動修復したりすることはありません。まず現在のプロキシアウトバウンドが利用できることを確認してから、通信を振り分けてください。ルールを読む際は、対象、条件、アウトバウンドのタグの順に確認します。ドメイン条件はドメイン、アドレス条件はIPを対象とし、ポートやネットワーク種別でさらに範囲を絞ります。各階層を分けて考えると、ルールに一致する理由やスキップされる理由を判断しやすくなります。

ルールの順序を先に決める

通常のルールは上から順に評価され、最初に一致したルールのアウトバウンドが使われます。個別の例外は、より広い条件より前に配置してください。たとえば、特定のドメインをプロキシ経由にする場合、それが直結用のドメイン集合に含まれていても、個別ドメインのプロキシルールを集合ルールより先に置きます。すべてのルールを単に「直結・プロキシ・ブロック」の順で並べるのではなく、例外関係に基づいて優先順位を決めてください。通常、1つのルール内にある複数の条件はすべて満たす必要があります。同じ種類のリストには、複数の候補を指定できます。

以下はXrayのrouting部分設定の例です。既存のblock、direct、デフォルトのプロキシアウトバウンド、および対応するgeoリソースが必要です。広告の集合を最初にブロックし、次にプライベートアドレスを直結し、その後、中国ドメインの集合を直結します。この例にはデフォルトのプロキシは定義されていません。一致しなかったリクエストの処理方法は、設定全体のアウトバウンド順序やクライアントが追加するフォールバックルールも確認してください。

{
  "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"
      }
    ]
  }
}

プライベートアドレスのルールはLANへのアクセスを保護するのに便利ですが、すべてを例外扱いできるわけではありません。アプリがドメインを送信し、ルーティングがAsIsの場合、このIPルールのために自動でアドレスを問い合わせることはありません。内部サービスには明示的な内部ドメインルールを追加し、適切なローカルDNSリゾルバーで処理してください。共有フォルダー、プリンター、管理画面ではブロードキャストなど別の通信が必要な場合もあります。Webページが開くことだけを根拠に、LANの機能がすべて正常だと判断しないでください。

ドメイン・IP・名前解決の方針

domain:example.comは、指定したドメインとそのサブドメインに一致させるために使えます。full:example.comは完全一致です。明確な構造があるドメイン群には正規表現が適していますが、範囲が広すぎて無関係なドメインまで同じアウトバウンドに含めないようにしてください。例示のドメインは構文説明用です。実際のルールは自分のアクセス要件に合わせて設定してください。ドメインルールはURLのパスを参照できないため、同じドメイン内の異なるページを区別することはできません。

AsIsはリクエストに含まれる情報をできるだけそのまま使って照合します。IPIfNonMatchはドメインルールに一致しなかった場合に名前解決を試み、続けてIPルールを照合します。IPOnDemandは、IP情報が必要なルールを照合する際に名前解決を行います。後者2つはDNSへの依存や待ち時間が増えるほか、名前解決を行う場所によって結果が変わる可能性があります。「より完全」だからといって、より積極的な名前解決方針を選ぶのは避けてください。宛先IPが本当にルールに必要かを先に判断しましょう。

入口からコアにIPアドレスしか渡されない場合、ドメインルールに一致しないことがあります。アプリのハンドシェイクからドメイン情報を復元できる場合もありますが、プロトコル、暗号化方式、クライアント設定に左右されます。すべての通信でドメインを復元できると考えないでください。TUNやFakeDNSは別の方法でドメイン情報を関連付けられますが、通信が実際に対応する入口を通っているか確認が必要です。根拠となる情報がなければ、ルールが正しくても一致しません。

ルールの一致とリソースを確認する

ルールを検証する際は、対象が明確なテスト先を選び、ログに表示された宛先、入口のタグ、アウトバウンドのタグを照合してください。毎回1つのルールだけを変更し、接続を再確立してテストします。既存の接続が変更前のアウトバウンドを使い続けることがあります。ブラウザーの接続プールやアプリのバックグラウンド接続も結果に影響します。必要であればページを再読み込みするだけでなく、該当アプリを終了してから試してください。ルールの変更にコアの再起動が必要かどうかは、クライアントの実際の保存動作に基づいて確認しましょう。

コアからgeoファイルや集合が見つからないと報告された場合は、リソースのパスと集合名を先に確認してください。エラーを避けるために、すべてのgeositeルールを正規表現に置き換えるのはやめましょう。リソースの内容は取得元によって変わり、あるタグが存在しても、あらゆる用途で分類が適切とは限りません。ログを使った詳しい切り分けはコアの起動失敗と設定エラーの分析をご覧ください。接続が復旧してから集合ルールを段階的に調整しましょう。

DNS設定の最適化

DNS設定では、まず「誰が問い合わせるのか」「どのリゾルバーに問い合わせるのか」「問い合わせの通信をどのアウトバウンドに通すのか」の3点を確認します。システムの名前解決、コア内蔵DNS、プロキシサーバー側の名前解決が同時に使われる場合があります。クライアント画面の「リモートDNS」が、すべてのアプリの問い合わせを自動的に受け取るとは限りません。DNSアドレスを変更する前にリクエスト経路を整理しておくと、Web接続はプロキシ経由なのにドメインの問い合わせは別経路を通っている、といった誤認を防げます。

ルーティング用の名前解決と接続用の名前解決を区別する

ルーティング用の名前解決はIPアドレスを取得してルールを判定するためのもので、接続用の名前解決は実際の宛先アドレスを取得するためのものです。両者は別の場所で行われる場合があります。ドメインをプロキシアウトバウンド経由でリモートに渡す場合、クライアント側で事前に解決する必要がないこともあります。一方、直結アウトバウンドでは通常、ローカルでアドレスを取得します。ルーティングのdomainStrategyと直結アウトバウンド自体の名前解決方針は別の設定です。一方を変更しても、もう一方が同じように変わるとは限りません。

以下の例は、Xray内蔵DNSでドメインごとにリゾルバーを使い分ける方法を示しています。中国のドメイン集合には優先してローカルシステムの名前解決を使い、それ以外の問い合わせには暗号化DNSを使用します。skipFallbackは、通常のフォールバック選択からそのサーバーを除外する設定で、あらゆるフォールバックを禁止するものではありません。この例にはgeoリソースが必要です。また、暗号化DNSのリクエストをプロキシ経由で送るには、ルーティングと利用可能なアウトバウンドを別途設定してください。URLがHTTPSだからといって、経路が正しいとは限りません。

{
  "dns": {
    "tag": "dns-query",
    "servers": [
      {
        "address": "localhost",
        "domains": ["geosite:cn"],
        "skipFallback": true
      },
      "https://1.1.1.1/dns-query"
    ],
    "queryStrategy": "UseIP"
  }
}

例にあるlocalhostはシステムの名前解決を使うという意味で、特定のローカル待ち受けポートに固定して接続するものではありません。現在のネットワークや内部DNSに追従したい場合に使えますが、結果はシステムやネットワークの設定に左右されます。システムDNSがTUN経由でコアに再び転送される場合は、ループが発生していないか確認が必要です。「ローカル」と「直結」を同じ意味だと考えると、この依存関係を見落としやすくなります。

DNS問い合わせのアウトバウンドを設定する

コアのDNS問い合わせを指定したアウトバウンド経由にするには、DNSタグとの一致を利用できます。ただし、現在のコアがその種類のリクエストをどう扱うか確認してください。以下は前の例に対応する部分設定です。先に一致する可能性のある広いルールより前に配置します。proxyアウトバウンドが定義済みであることが前提です。システムの名前解決やローカルの意味を持つアドレスは、同じプロキシ経路を通らない場合があります。タグだけを見て判断せず、個別に確認してください。

{
  "type": "field",
  "inboundTag": ["dns-query"],
  "outboundTag": "proxy"
}

リゾルバーのアドレスがドメイン名の場合、そのドメイン自体を最初に解決する方法も必要です。明示的なアドレスを使うと初期解決への依存を減らせますが、HTTPSの証明書検証とサービスの対応は引き続き必要です。経路の問題を証明書検証の無効化で解決しないでください。プロキシサーバーのアドレスを内蔵DNSで解決しようとし、その名前解決がプロキシ接続に依存すると、起動時にループする可能性があります。サーバーアドレスには独立して到達できる名前解決経路を用意するか、システムで初期解決してください。

デュアルスタック・キャッシュ・トラブル対処

UseIPでは、設定に応じてアドレスファミリーを取得できます。IPv4またはIPv6だけに限定する場合は、明確な理由が必要です。ネットワークにIPv6アドレスがあるからといって、出口やルーティングまで正常とは限りません。一部のサイトで接続に時間がかかる場合は、IPv4とIPv6を一時的に切り替えて比較し、エラーや接続の挙動を確認してください。IPv6を恒久的にすべて無効にするのは避けましょう。使用中のコアが該当フィールドと値に対応しているかも確認し、別のコア独自の拡張オプションをそのまま流用しないでください。

リゾルバーを変更した後も、システム、ブラウザー、コアのキャッシュに古い結果が残ることがあります。トラブル対処では、問い合わせ結果と接続先を分けて確認し、必要に応じてコアやアプリを再起動してください。毎回、端末全体のネットワークをリセットする必要はありません。アプリ内蔵の暗号化DNSがシステム設定を迂回する場合もあります。まずアプリ内で有効かどうかを確認し、独自設定のまま使うか、システムの名前解決を使うかを決めましょう。2つの方針が互いに打ち消し合わないようにしてください。

ドメインは解決できるのにWebページが開かない場合は、ルーティング、接続、サーバー側の対応状況を確認します。ドメインをまったく解決できない場合は、リゾルバーへの到達性、問い合わせのアウトバウンド、内部ドメイン、アドレスファミリーの制限を調べてください。問い合わせ1件の失敗ログと、その前後の接続ログを記録すると、複数のDNSアドレスを同時に変更するより有効です。DNS設定の目的は、経路を説明でき、アクセスする場所に応じた結果を得ることです。単に速そうなアドレスを選ぶことではありません。

TUNモード

TUNは仮想ネットワークインターフェースで通信を受け取るため、システムプロキシ設定に従わないアプリに適しています。変更されるのは通信の入口であり、サーバーのプロトコルや独立した接続サービスではありません。v2rayNのシステムプロキシはシステムプロキシを参照するアプリに影響しますが、TUNはインターフェース、ルーティング、関連するネットワークスタックに依存します。有効にした後も、利用可能なプロキシアウトバウンドと適切なDNS経路が必要です。TUNを有効にしても、事前の接続確認を省略することはできません。

有効にする前にネットワークの状態を記録する

まず通常のプロキシモードでサーバーへの接続を確認し、デフォルトゲートウェイ、DNS設定、既存の仮想インターフェース、よく使う内部アドレスを記録してください。職場のネットワーク、リモートデスクトップ、仮想マシンを使う場合は、どの通信をTUNで処理してはいけないか特に確認します。既存のトンネル、コンテナー、仮想マシンのソフトウェアがルートを追加している場合もあります。こうした基本状態が不明だと、TUN有効化後の問題が新しいルールによるものか、以前からあるネットワーク経路の問題か判断しにくくなります。

Windowsでは、インターフェースの作成やシステムルートの変更に管理者権限が必要になるのが一般的です。macOSやLinuxでは、それぞれのシステムに応じた権限や認証を設定してください。v2rayNの画面名、補助コンポーネント、起動方法は変更されることがあるため、現在の設定説明に従ってください。Androidのv2rayNGとv2flyNGは通常、システムが提供するトンネルの許可を通じて通信を処理します。この許可方法はデスクトップの管理者権限とは異なるため、デスクトップ向けの権限設定をそのまま適用しないでください。

初めて切り替える際は、システムプロキシを無効にしてからTUNを有効にすると、2つの入口が同時に有効になる変数を減らせます。ここでいう「システムプロキシをクリア」はアプリの通信入口を変更することであり、プロキシコアを停止することではありません。仮想インターフェースが正常に作成されたことを確認したら、デフォルトルートとDNSが想定どおり変わったかを確認します。リモート管理中の接続を使っている場合は、通信経路が変わって操作できなくなるのを防ぐため、事前にローカルで切り戻す方法を用意してください。

スタック・ルート・除外設定

スタックは、仮想インターフェースが受け取ったデータの処理方法を決めます。一般的な選択肢にはシステムスタックやgvisorがありますが、実際に選べるものは使用する実装によって異なります。プロトコルの互換性、リソース消費、プラットフォーム対応にはそれぞれ違いがあります。名前だけで速度を判断しないでください。まずはクライアント推奨のデフォルトを使い、特定のアプリで互換性の問題が起きた場合に比較します。サーバーの変動をスタックの違いと取り違えないよう、同じ宛先と同じアウトバウンドでテストしてください。

プロキシサーバー自体への接続がTUNに戻るループを避ける必要があります。クライアントは通常、インターフェースのバインド、ルートの除外、その他の方法でこのアウトバウンド経路を保護しますが、カスタム設定によって保護条件が崩れることがあります。有効化後に通常のネットワークとプロキシが同時に使えなくなったり、同じアドレスへの接続がログに繰り返し記録されたりする場合があります。デフォルトルートを追加し続けるのではなく、サーバーアドレスが実際にどの経路を通るか確認してください。サーバーにドメイン名を使う場合は、アドレス変更後も除外設定が有効か確認が必要です。

LANの除外範囲は実際のアドレスに合わせて設定してください。家庭でよく使われるネットワーク範囲ですべての職場、仮想マシン、専用ネットワークをカバーできるとは限りません。プライベートアドレスを1つの範囲だけ除外すると、別の内部ネットワークを見落とす場合があります。範囲が広すぎると、プロキシ経由にすべきリクエストまで直接送信される可能性があります。必要なネットワーク範囲と内部ドメインを確認し、クライアントが対応するルート除外または直結ルールを選んでください。ルートが正しくても内部名を解決できないことがあるため、DNSも合わせて設定します。

通信の取り込みと終了後の復旧を確認する

テストでは、システムプロキシを参照しないアプリを選び、リクエストがTUNに入ることを確認してから、Web、LAN、UDPが必要な機能をそれぞれ試します。UDPの失敗は、アウトバウンドの対応状況、ファイアウォール、接続先の制限、スタックの実装が原因の場合もあり、すべてをTUNの問題と決めつけないでください。ブラウザーでページが開いても、成功したのは一部のリクエストだけです。システム通信がすべて取り込まれた証拠にはなりません。仮想インターフェースの存在だけで実際の接続テストを代用しないでください。

有効化後にネットワークへ接続できなくなった場合は、まずTUNを無効にして通常のネットワークが復旧するか確認します。次にコアを停止し、残ったインターフェース、ルート、DNSを調べてください。すぐにすべての仮想NICを削除したり、ネットワーク全体をリセットしたりせず、まずクライアントの通常の終了手順を使いましょう。基準状態に戻せたら、権限、入口、サーバーアウトバウンド、DNSの4層を順に再確認します。用語の確認には用語集を参照し、その後、使用中のプラットフォームの設定画面に戻ってください。

FakeDNSとドメインの関連付け

FakeDNSは、宛先サーバーの実IPアドレスではなく、内部マッピング用のアドレスを返します。コアは「ドメインと合成アドレス」の対応を保持し、その後、対応する復元機能を備えた入口にリクエストが届くと、ドメインを復元してアウトバウンドを選択します。主な用途はドメイン情報を維持してドメインベースのルーティングを可能にすることであり、通常のDNS高速化オプションではありません。有効化する前に、DNS問い合わせ、後続の接続、マッピングの復元が同じ処理経路にあることを確認してください。そうでなければ合成アドレスへ接続できなくなります。

処理経路全体を理解する

一連の処理では、アプリがドメインを問い合わせ、FakeDNSに問い合わせが届き、合成アドレスが返されます。次にアプリがそのアドレスへ接続し、入口でドメインを復元した後、アウトバウンドが実際の宛先へ接続します。どこかでコアを経由しなければ、失敗する可能性があります。たとえば、アプリが別の暗号化DNSを使うと合成アドレスを取得できない場合があります。また、合成アドレスを取得できても接続がTUNを迂回すると、ドメインは復元されません。DNSサーバーをfakednsに変更するだけでは、設定全体は完了しません。

以下はXrayのFakeDNSプールと内蔵DNSの部分設定例です。指定したネットワーク範囲はドキュメント用アドレス範囲ですが、ローカルですでに同じ範囲を使っていないか確認してください。poolSizeはマッピングプールの規模を設定するもので、インターネット上のサーバー用アドレス数を予約するものではありません。この例は構造を示すものです。実際に使うには、スニッフィングとルーティングに対応する入口が必要です。v2rayNで別のネットワークコンポーネントを使ってTUNを処理する場合は、そのコンポーネントの設定方法に従ってください。異なる実装の項目を混在させないでください。

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

入口にはFakeDNSアドレスを識別し、ドメインを復元する機能も必要です。以下は、対応するXrayの入口で使用できるsniffingの部分設定オブジェクトであり、独立した入口の定義ではありません。metadataOnlyはメタデータのスニッフィングに限定する設定で、マッピング復元経路の説明に適しています。HTTPやTLSのスニッフィングも必要な場合は、対象とオプションを改めて確認してください。異なる取得元のスニッフィング設定を重ねても、自動的に連携するとは限りません。

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

アドレスプール・例外・互換性

アドレスプールは使用中のマッピングを収容できる十分な大きさが必要ですが、既存のネットワークと重複してはいけません。マッピング空間とプールの規模は別の概念です。値を大きくしても、入口が通信を取り込まない問題は解決できません。頻繁に再起動するとマッピングの状態が失われる一方、アプリのキャッシュには古いアドレスが残る場合があります。アプリがその古い合成アドレスへ接続し続けると、コアがドメインを復元できず、起動直後は正常でも設定を切り替えた後に一部のアプリが失敗することがあります。

内部ドメインは、TUNの対象外にされていたり、ローカルネットワークのアドレスに依存したりするため、実際の名前解決結果が必要になることが一般的です。こうしたドメインには実アドレスを返すDNS経路を明示的に設定し、後続の接続も内部ネットワークとして処理されることを確認してください。内部IPを直結にする一方で、内部ドメインには合成アドレスを返す、といった設定は避けましょう。DNSの結果を独自に検査するアプリや、接続以外の処理に解決済みアドレスを使うアプリでは、例外が必要になる場合もあります。

FakeDNSが返すアドレスは内部マッピング用なので、「先に名前解決し、実IPで分類する」という従来の判断がそのまま成立するとは限りません。ルーティング照合の前にドメインが復元されるか、現在の実装が合成アドレス、ドメイン、IPルールをどの順序で処理するかを先に確認してください。特に直結、内部アドレス、実アドレスが必要なルールでは、1つのIP集合だけから結果を推測できません。主な目的がドメインによる振り分けなら、まず明確なドメインでテストし、段階的に範囲を広げましょう。

段階的に有効化・無効化する

テストでは、通常のDNSとTUNが使える基準状態を維持したままFakeDNSを有効にします。ドメインの問い合わせがプール内のアドレスを返すか確認し、続けて同じアプリの接続でドメインが復元されるか確認してください。両方を確認できたら、振り分けとLANのテストに進みます。問い合わせがFakeDNSに届かない場合はDNSの入口を確認します。合成アドレスを取得できても接続に失敗する場合は、接続の取り込みと入口でのマッピング復元を調べてください。上流リゾルバーを何度も変更しても解決にはなりません。

FakeDNSを無効にする際は、キャッシュも処理してください。まず実アドレスを返すDNS経路に戻し、合成アドレスを保持しているアプリを再起動します。必要に応じて、システムの方法でDNSキャッシュを消去してください。古いDNS結果が残ったまま通信の取り込みを停止すると、一時的にアクセスできなくなることがあります。トラブル対処中に合成アドレスを静的なドメイン対応表、サーバーアドレス、長期利用するルールに登録しないでください。対応するマッピングの範囲内でのみ意味を持つアドレスです。実際の名前解決に戻ったことを確認してから、切り戻しが完了したと判断しましょう。

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

複数のサブスクリプションを管理する目的は、すべての情報を1つの長い一覧にまとめることではありません。取得元、更新、利用状況を追跡できる状態に保つことです。取得元が異なっていても似たメモが使われていたり、同じサーバーに別のパラメーターが設定されていたりする場合があります。グループは更新の境界、現在使うサーバーは接続の境界、ルーティングは通信の境界として管理してください。役割を分けることで、1つの取得元が使えなくなっても、他のグループや現在の接続を残せます。設定全体を作り直す必要もありません。

取得元ごとに更新を分ける

取得元ごとにグループを1つ作り、複数のURLを1つの欄に連結しないことをおすすめします。メモには用途を記し、アクセス用パラメーターや個人情報は含めないでください。まずグループごとに手動で更新し、取り込み形式、絞り込み条件、サーバーの変化を確認してから自動更新を設定します。2つのグループが同じ取得元で、絞り込み範囲だけが異なる場合は、同じサービスへ重複してリクエストすることになります。不要な重複更新は適切にまとめましょう。

更新頻度は、取得元の変更頻度と実際の利用状況に合わせてください。頻繁に更新すればよいわけではありません。更新回数が増えるほか、テスト中にサーバー情報が変わる可能性もあります。接続状況を比較する場合は、関連するグループの自動更新を一時停止し、設定を固定してからテストしてください。更新後は、意図したサーバーが引き続き選択されているか確認します。特に元の情報が削除された場合や、パラメーターが再生成された場合は注意してください。クライアントが選択状態を保持することだけに頼らず、手動でも確認しましょう。

特定のグループで更新エラーが起きた場合は、そのグループだけを調べます。まずURLと利用権限を確認し、次に直接接続とプロキシ経由の結果を比較し、最後に応答形式を確認してください。他のグループを正常に更新できても、失敗した取得元のURLに問題がないことの証明にはなりません。すべてのグループで同時に失敗する場合は、共有のネットワーク、名前解決、プロキシ入口の変化が原因である可能性が高まります。このように対象範囲を見極めれば、すべての取得元を再インポートする無駄を減らせます。

重複情報と測定結果

重複情報をメモだけで判断して削除しないでください。同じメモでも、ポート、プロトコル、トランスポート、暗号化パラメーターが異なる場合があります。メモが異なっていても同じ接続先を指していることがあります。削除する前に重要な接続項目を比較し、取得元との対応を残してください。説明や相談では違いを示しても、接続パラメーター全体を公開しないでください。長期利用する項目を残す場合は、次回更新後に分からなくならないよう取得元と用途を記録しましょう。

レイテンシーテスト、実際のリクエスト、帯域テストでは測定する内容が異なります。一度の順位付けを恒久的な選定結果とみなさないでください。テスト結果は、ローカルネットワーク、測定先、同時実行数、サーバー負荷にも左右されます。複数グループを比較する際は、同じ方法、同じ測定先、近い時間帯でテストし、正常に使えると分かっている情報も比較用に残してください。詳しくはTcping・実接続レイテンシー・ダウンロード速度測定の違いをご覧ください。

地域名だけでサーバーを選ばないでください。地域ラベルは通常、取得元が付けたメモであり、入口や出口の位置、実際の経路を正確に示すとは限りません。倍率、プロトコルの互換性、用途の制限も選択に影響します。測定レイテンシーが低くても、長時間の転送や特定のアプリに適しているとは限りません。頻繁に変わる一覧全体の順位を保存するより、「普段使い」「特定用途」「予備」のように候補を少数に絞ると管理しやすくなります。

バックアップと取得元の整理

設定のバックアップには、サブスクリプションURL、サーバーの識別パラメーター、カスタムアウトバウンド、ルーティングが含まれることがあります。バックアップは管理された場所に保管し、通常のスクリーンショットと一緒に共有しないでください。復元時は、まずクライアントとコアの互換性を確認してから、グループごとに取り込みます。古いバックアップに含まれる無効なURLを、新しい更新元として自動的に使わないでください。復元に成功したということは設定を読み込めたというだけです。接続、DNS、現在のネットワークでのルーティングを改めて確認してください。

取得元を使わなくなった場合は、まず使用中のサーバーを切り替え、その取得元の更新を停止して、関連するルーティングやカスタムアウトバウンドが参照されていないか確認してください。依存関係がないことを確認してからグループを削除します。ローカルのグループを削除しても、取得元側の利用権限やサービスは解約されません。取得元の管理方法に従って手続きしてください。一時的に使わないだけなら、グループを残して明確に無効化するほうが、URLを複数の仮項目にコピーするより復元しやすく、機密情報の保存範囲も管理しやすくなります。

カスタムアウトバウンドとコアの境界

カスタムアウトバウンドでは、リクエストがコアから送出される方法を定義します。主な用途は、直接接続、ブロック、既存のプロキシサービスを経由した転送です。ルーティングはタグでアウトバウンドを参照します。タグは内部識別子であり、サーバーのメモやサブスクリプショングループ名ではありません。まずアウトバウンドごとの役割を明確にしてから照合ルールを作ると、タグの不一致、デフォルト経路の変化、クライアントの設定生成によるローカル編集の上書きなどを避けやすくなります。通常の利用では、v2rayNのGUIで設定する方法を優先してください。

タグとデフォルト経路を決める

以下はXrayの直結およびブロック用アウトバウンドの部分設定例で、プロキシサーバーは含まれていません。freedomとblackholeの構造を理解するためのものであり、現在のアウトバウンド一覧全体を置き換えるものではありません。この2つだけを残した場合、一致しない接続は通常、先頭の直結アウトバウンドに送られます。デフォルトでプロキシを使うには、クライアントが生成したプロキシアウトバウンドを残し、アウトバウンドの順序とフォールバックルートを確認してください。タグをproxyに変更するだけでは不十分です。

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

タグは短く、役割が変わらないものにしてください。たとえば、直結、ブロック、特定のプロキシ入口には、それぞれ別の識別子を使います。タグを重複させたり、ファイルごとに同じタグへ別の意味を持たせたりしないでください。ルーティングから参照するタグは、アウトバウンド側と完全に一致する必要があります。アウトバウンドを変更したら、関連ルールやその他の参照箇所も検索してください。特にDNS問い合わせと特定アプリ向けのルールに注意します。未参照のアウトバウンドが存在しても、リクエストが自動的にそこへ送られるわけではありません。

ブロック用アウトバウンドは、送信する必要がないと明確に判断できるリクエストに適していますが、あらゆる接続エラーへの対処として使わないでください。不明なドメインをすべてブロックすると、アプリが必要とする認証、リソース、更新のリクエストまで失敗する可能性があります。直結アウトバウンドも、現在の端末のネットワークや名前解決機能に依存します。すべての宛先へ接続できるという意味ではありません。「高速」や「安全」と名付けるだけでなく、各アウトバウンドの適用範囲と確認先を決めましょう。

ローカル転送とプロキシチェーン

以下は、ローカルのSOCKSサービスへ転送するアウトバウンドの部分設定例です。独立したサービスが127.0.0.1:10808で待ち受けていることを前提としており、この例自体がサービスを起動するわけではありません。そのポートが同じコアの入口であり、その入口がこのアウトバウンドに戻る場合、ループが発生する可能性があります。待ち受けプロセス、入口からの経路、最終的な出口を必ず確認してください。ローカルポートへの接続が成功しても、転送経路全体が正しいとは限りません。

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

プロキシチェーンでは複数の処理段階をつなぐため、接続、名前解決、障害に関する依存関係が増えます。設計時には各ホップの入口と出口を図にし、ドメインをどのホップで解決するか、UDPを転送できるか、どこかの段階が停止した場合にどうなるかを確認してください。すべてのアウトバウンドが同じチェーン設定項目に対応するとは限りません。チェーン転送が必要な場合は、使用中のコアの設定構造に従い、別の実装の項目を既存のオブジェクトにそのまま貼り付けないでください。

待ち受けアドレスもアクセス範囲の一部です。ローカル専用の入口は通常、ループバックアドレスに限定します。すべてのインターフェースで待ち受ける場合はアクセス範囲が広がるため、認証とファイアウォールを併用してください。別の端末から接続するために、認証のないプロキシ入口をそのまま公開しないでください。ローカルSOCKSの例に対応するサービスについても、ポートの競合、起動順序、終了時の動作を明確にしてください。上流サービスが起動していないのに下流のコアだけが起動する状況を防げます。

クライアントによる設定生成とコアの互換性

v2rayNは画面上の選択内容に基づいて実行設定を生成します。一時生成ファイルを直接編集しても、サーバーの切り替え、設定の保存、再起動の際に上書きされる可能性があります。クライアントが提供するカスタム設定または拡張用の入口を優先し、「部分設定のマージ」なのか「設定全体の置き換え」なのか確認してください。両者で必要な作業は異なります。全体を置き換える場合は、通常、入口、アウトバウンド、ルーティング、DNSを自分で用意します。マージする場合は、タグの競合や上書き順序を理解する必要があります。

XrayとV2Flyには共通する基本概念がありますが、プロトコルの機能や拡張項目が完全に同じとは限りません。v2rayNGではXrayエコシステムの設定を主な参考にし、v2flyNGではV2Flyの対応状況を確認してください。画面でプロトコル名が認識されても、すべてのトランスポートとの組み合わせが使えるとは限りません。コアの違いについてはクライアントとコアの比較およびXrayとV2Flyの違いをご覧ください。

コアを切り替える前に基準となる設定を保存し、プロトコル、トランスポート、セキュリティ項目、ルーティング、DNSを1つずつ確認してください。テストでは、まず接続を1つだけ検証し、その後にカスタムアウトバウンドと複雑なルールを戻します。起動に失敗した場合は、ログを見て項目を修正してください。分からない項目をすべて削除するだけでは不十分です。起動できても構文や初期化の一部を通過しただけであり、実際のリクエストで各アウトバウンドとルーティングが想定どおり動くことを確認する必要があります。

設定の確認と切り戻し手順

詳細設定後は、Webページが1つ開くかどうかだけで判断せず、決まった手順で検証してください。少なくとも起動、プロキシ接続、名前解決、ルールの一致、特殊な入口、終了後の復旧を個別に確認します。項目ごとに対象を明確にし、変更内容と確認結果を記録してください。異常が起きたら、直近で変更したモジュールから切り戻し、ほかの利用可能な設定は残します。正常な設定を誤って削除せず、次回も再現できるテスト条件を維持できます。

起動から接続まで段階的に確認する

最初の段階では、コアが起動できるか確認します。明確なエラーの最初の行と、その前後にある項目の説明を確認し、JSON構文、未知の項目、リソース不足、ポートの競合を切り分けてください。JSONにはコメントや末尾のカンマを含められません。部分設定を複数のトップレベルオブジェクトのまま連結することもできません。クライアント画面に「実行中」と表示されても、コアがすぐ終了していないか確認が必要です。同じエラーが繰り返される場合は、自動再起動や再実行を停止してから、一度のエラー全体を読みましょう。

次の段階では、入口がリクエストを受け付けるか確認します。アプリで使うプロキシのアドレスとポートが、現在の待ち受け設定に一致しているか確認してください。システムプロキシの状態も、実際に使う入口と一致させます。入口が接続を受け付けるようになったら、サーバーへの接続とプロトコルのハンドシェイクを確認します。タイムアウト、接続拒否、認証失敗は別々の問題です。すべてを「DNSを変更する」だけで解決しようとしないでください。サーバーのパラメーターは許可された設定から取得し、アドレスだけでなく必要な項目をすべて確認しましょう。

3番目の段階では、名前解決とルーティングを確認します。直結される想定の宛先と、プロキシ経由の想定の宛先を1つずつ選び、ログに表示された宛先情報とアウトバウンドタグを照合してください。新しいルールを試す際は接続を再確立し、既存の接続を再利用しないようにします。ログにIPしか表示されない場合は、入口でドメイン情報が保持されているか、スニッフィングが機能しているか、FakeDNSが正しく復元できているかを確認してください。ドメイン情報の欠落とルールの優先順位の誤りでは、未一致の原因も対処方法も異なります。

範囲を絞って再現可能なテスト項目を用意する

テスト項目は多くなくても構いませんが、設定の目的をカバーしてください。通常のWeb、直結する内部サービス、プロキシが必要なリクエスト、実際に使う特殊なアプリを含めます。テスト時のTUNとFakeDNSの有効・無効、使用サーバー、ネットワーク環境も記録してください。モバイルネットワークと固定ネットワークの結果を同じ条件として扱わないでください。特定のネットワークでだけ問題が起きる場合は、その違いを残し、ネットワーク側の名前解決、出口、ファイアウォールを優先して確認します。

速度測定は参考情報になりますが、機能テストの代わりにはなりません。ハンドシェイクのレイテンシーが低くてもアプリの認証に成功するとは限らず、ダウンロード速度が高くてもルーティングやDNSが設計どおりとは限りません。テストに失敗した場合は、まず最小限の設定で実際のリクエストを1つ成功させてから、絞り込み、ルーティング、TUNなどを戻してください。サーバーとコアを同時に切り替えて比較すると、どちらの変更で復旧したのか判断できません。変更を一度に少なくするほど、長期的に維持できる対処を見つけやすくなります。

トラブル対処中だけ必要な範囲でログレベルを上げ、原因を特定したら通常の設定に戻してください。ログには宛先ドメイン、サーバーアドレス、機密パラメーターが含まれる場合があります。共有する前に項目ごとに確認しましょう。エラーの種類、項目名、必要な前後の情報、再現手順を残せば十分です。サブスクリプション全体、設定全体、長時間分のログを公開しないでください。相談時には失敗画面の画像だけを貼るのではなく、「何を変更し、何を想定し、実際に何が起きたか」を説明しましょう。

段階的な切り戻しとメンテナンス記録

切り戻しは変更した順序を逆にたどります。まず最後に追加したルールやアウトバウンドを戻し、次にDNSを戻して、最後にTUNやFakeDNSなど入口の変更を取り消します。直近の変更が入口であれば、その入口を先に無効にして操作経路を復旧してください。切り戻しのたびにテストし、複数のモジュールを一度に戻して検証材料を失わないようにします。基準状態に戻ったことを確認したら、設定の作業用コピーを作り、次の調整を始めてください。原因を説明できない混在状態にルールを追加し続けないようにしましょう。

メンテナンス記録には、日付、対象モジュール、変更理由、確認結果、切り戻し位置だけを記載し、認証情報は保存しないでください。サブスクリプションの自動更新、ネットワークの切り替え、コアの切り替えは、再確認が必要になるタイミングです。取得元の更新後は使用中のサーバー、ネットワークの切り替え後は内部DNSとルーティング、コアの切り替え後は項目の互換性を重点的に確認してください。変更範囲に応じて再テストすれば、毎回設定を最初から作り直すより手間を減らし、障害の境界も把握しやすくなります。

日常の接続を復旧することが目的なら、サブスクリプションの追加と接続の手順に戻れば十分です。詳細機能をすべて一度に設定する必要はありません。インストール環境を調整する場合はプラットフォーム別ダウンロードを、エラーごとの対処はヘルプセンターをご覧ください。このガイドの各項目は必要に応じて個別に適用してください。設定を増やすより、少数の項目を明確に保ち、検証できる状態で維持するほうが長期的な管理に適しています。