V2Rayの詳細設定ガイド

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

サブスクリプションの取得元、表示リスト、接続中のサーバーを分けて考える

サブスクリプショングループは、サーバー項目を管理するための入れ物です。ルーティングのグループとは異なり、特定のアプリが自動的に特定のサーバーを使うわけではありません。サブスクリプションURLはサーバー項目を取得し、グループは項目を整理します。通常のプロキシ接続先を決めるのは、現在選択されているサーバーです。この3つを区別すれば、「グループを切り替えたのに接続先が変わらない」という誤解を防げます。リストを切り替えた後は、サーバーを選び直し、新しい設定が適用されたことも確認してください。

v2rayNでサブスクリプショングループの設定を開き、取得元ごとにグループを作成します。「普段使い」「予備」など、用途と取得元が分かる名前がおすすめです。サブスクリプションURL全体をグループ名に貼り付けないでください。URLを追加して保存したら、対象グループを更新します。初回更新後、サーバー名、プロトコル、伝送設定が正しく認識されているか確認しましょう。リストが空の場合は更新ログを確認し、同じURLを繰り返し追加して空のグループを増やさないようにしてください。

絞り込みで分かるのは項目の範囲であり、接続品質ではありません

サーバーの絞り込みは、表示または取り込む項目の範囲を限定する機能です。どの段階に適用されるかは、クライアントの設定によって異なります。表示中のリストだけに適用される場合もあれば、サブスクリプション更新時に項目を選別する場合もあります。変更前に項目の説明を確認し、比較用に絞り込みなしのグループを残しておきましょう。地域、回線の用途、倍率は提供元の命名に基づくことが多く、クライアントが個別に測定した事実ではありません。名前に地域が含まれていても、最終的な出口の所在地を名称だけで判断することはできません。

まず通常のキーワード検索で目的の項目が見つかることを確かめ、必要な場合に正規表現を使います。正規表現に対応すると明記された項目だけで使用してください。以下の式は、名前に「香港」または「シンガポール」が含まれる項目に一致します。提供元が別の名称を使っている場合は、文字列を調整してください。通常のテキスト検索欄にそのまま入力すると、縦線や括弧が文字として扱われ、検索結果が空になることがあります。

(香港|シンガポール)

絞り込みが正しく機能しているか確認するには、いったん解除して全項目を表示し、その後に条件を適用してリストを比較します。結果が空でも、サブスクリプションが無効とは限りません。大文字・小文字、全角文字、余分な空白、名称の変更が原因のこともあります。除外キーワードと含めるキーワードを併用する場合は、条件同士が打ち消し合っていないか確認しましょう。複雑な条件は一つずつ追加してください。長い式を最初からまとめて書くと、誤りの箇所を特定しにくく、後からの修正も難しくなります。

更新前に復元できる情報を残す

リモート更新によってグループ内のサーバー項目が置き換わり、手動で変更したメモや設定が維持されないことがあります。長期的に残したいカスタムサーバーは、手動用のグループに分けておくとよいでしょう。更新前に、接続中のサーバーが属するグループと識別しやすい名前を記録してください。更新後も項目の並び順が変わらないとは限りません。提供元が名前や回線を変更したり、項目を削除したりする可能性があります。リストの位置だけを頼りに選ぶと、更新後に意図しない接続先へ切り替わるおそれがあります。

サブスクリプションの更新に失敗したら、まず「URLを取得できない」のか「取得した内容を解析できない」のかを切り分けます。前者はURLの有効性、現在のネットワーク、更新時にプロキシを使う設定かどうかを確認します。後者は、返された内容がサブスクリプションではなく、ログイン画面、期限切れの通知、エラーページになっていないか確認してください。プロキシ経由で更新する場合は、接続可能なサーバーが先に必要です。すべてのサーバーが使えないと、この更新方法が依存関係のループに陥ることがあります。現在のネットワークで利用できる別の方法を試してください。

v2rayNGまたはv2flyNGにインポートした後も、グループと接続中のサーバーを改めて確認してください。クライアントによってメモ、並べ替え、絞り込み条件の保存方法が異なるため、PC版のリスト状態がスマートフォンにも同期済みだとは限りません。サブスクリプションURLにはアクセス用の認証情報が含まれることが多いため、クリップボードにコピーした後は公開チャットに貼り付けないようにしましょう。問題の報告には内容を加工したエラーの概要だけを使い、URL全体を記事のコメントやスクリーンショットに載せないでください。

ルーティング設定の実例と優先順位

デフォルトの接続先を決めてから例外ルールを追加する

ルーティングの役割は、コアに入った接続を特定のアウトバウンドへ振り分けることです。アプリの通信を自動的にクライアントへ取り込む機能ではなく、システムプロキシの設定とも異なります。ルールは通常、定義した順に評価され、最初に一致した有効なルールで経路が決まります。一致するルールがない場合は、設定されたデフォルトの動作が使われます。変更前に、デフォルトをプロキシと直接接続のどちらにするか決め、例外は少数に絞って先に記述しましょう。範囲の広すぎるルールがあると、後続の細かなルールが適用されません。

v2rayNのプリセットルーティングモードは出発点として便利ですが、複数のプリセットをそのまま重ねて使うのは避けましょう。用途に近いものを一つ選び、ルーティング設定で実際のルールを確認します。プライベートネットワークのアドレス、指定ドメイン、地域別の集合、最終的なフォールバックを整理しておきましょう。プロキシサーバー自身の通信をループさせないための除外も重要です。TUNを有効にした場合は、プロキシ接続が再び取り込まれないようにしてください。クライアントが一部の例外を自動処理することもあるため、変更前に現在の動作を確認しましょう。

ドメイン、アドレス、集合ごとに一致条件が異なる

full: は完全一致するドメインを一つ指定する場合に適しています。domain: は指定したドメインとそのサブドメインをまとめて対象にできます。regexp: は正規表現で一致させます。geosite: はドメインの集合を参照します。アドレスルールの ip には、単一のアドレス、ネットワーク範囲、対応するアドレス集合を指定できます。集合名が常に内蔵されているとは限らず、使用できるかどうかは現在のデータファイルによります。利用前に、対象ファイルの存在と項目名を確認してください。

以下の例では、指定ドメインとそのサブドメインを direct というアウトバウンドに割り当てます。ルーティングの構造を示す例なので、既存の設定に追加する際は同じタグのアウトバウンドがないことを確認してください。例のドメインは、直接接続したい実際の宛先に置き換えます。ただし、WebページのURL全体は入力しないでください。プロトコルの接頭辞、ポート、パスはドメインの一致条件には含まれません。グラフィカルな画面で同様のルールを追加する場合も、ドメイン条件と接続先アウトバウンドをそれぞれ選択してください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

複数の条件をどう組み合わせるか

同じルール内に異なる条件項目を指定した場合、通常はすべての条件を満たす必要があります。一方、同じリスト内の候補は、いずれか一つに一致すればよい仕組みです。そのため、ドメイン、ポート、ネットワーク種別を一つのルールにまとめると、3種類の通信に個別のルールを追加するのではなく、一致範囲が狭まります。異なる状況に対応する場合は、ルールを分けると検証しやすくなります。「ドメインが正しいのに一致しない」ときは、優先順位だけでなく、実際のリクエストに合わないポートや受信側の条件が付いていないかも確認してください。

ドメインルールが使えるかどうかは、コアがドメイン名を取得できているかにも左右されます。明示的なプロキシ接続ではドメイン名が伝わる場合がありますが、透過的に取り込んだ通信では宛先アドレスしか分からず、情報の補完にスニッフィングやFakeDNSのマッピングが必要なことがあります。domainStrategy は、アドレスルールの判定時にドメインをいつ解決するかを決めます。DNSモジュールの問い合わせ方針とは別の設定です。早い段階で名前解決しても、ルーティングの精度が必ず上がるとは限りません。待ち時間が増えたり、アドレスルールの一致結果が変わったりすることもあります。

具体的な宛先を使ってルールを検証します。想定するアウトバウンドを記録し、新しい接続を作成して、ログに表示される宛先とアウトバウンドのタグを確認してください。ブラウザーが既存の接続を再利用する場合、ルール変更後にページを再読み込みするだけでは、新しいルーティングが実行されないことがあります。必要に応じて対象アプリを終了してから再試行しましょう。結果が想定と違う場合は、一時的に対象ルールを前方へ移動してテストします。一致を確認したら適切な位置に戻し、範囲の広いルールを隠すために恒久的に先頭へ置くのは避けてください。

DNS設定の最適化と名前解決の経路

どこで名前解決し、どこから問い合わせるかを整理する

一度のアクセスで、アプリ独自の名前解決、システムの名前解決、クライアント内蔵DNS、プロキシサーバー側の名前解決が関わることがあります。クライアントにリモートDNSを設定しても、すべてのアプリの問い合わせが自動的にそこへ送られるわけではありません。ブラウザーのセキュアDNS、アプリ内蔵のリゾルバー、システムキャッシュが、想定した経路を迂回する場合もあります。問題を調べる前に、テストするアプリ、通信の取り込み方法、対象ドメインを明確にし、異なる層の問い合わせを混同しないようにしましょう。Webサイトの出口アドレスだけでは、名前解決の経路が正しいか判断できません。

直接接続用DNSとリモートDNSの違いは用途であり、単純な地理的区分ではありません。直接接続する宛先には、ローカルネットワークからアクセスしやすいアドレスを返す必要があります。プロキシ経由の宛先には、プロキシの接続経路に適した結果が必要です。名前解決の結果に地域差がある場合、誤った経路を使うと、コンテンツ配信先が実際の出口に合わなくなることがあります。まずクライアントの標準設定で動作する状態を作り、対象の範囲ごとに名前解決を分けてください。最初から複数のリゾルバーや複雑なフォールバック、特殊な問い合わせ方針を同時に有効にするのは避けましょう。

DNSの問い合わせ方針とルーティング方針は分けて確認する

以下は、パブリックDNSアドレスを使い、IPv4の結果を優先するコアDNSの設定例です。servers と queryStrategy の記述位置を示すもので、あらゆるネットワークに推奨する設定ではありません。パブリックDNSへ到達できるかは、実際の環境で確認してください。この設定だけでシステムDNSが切り替わるわけではなく、問い合わせが自動的にプロキシを通ることも保証されません。クライアント側でのDNS通信の経路設定を置き換えるものでもありません。

{
  "dns": {
    "servers": ["1.1.1.1"],
    "queryStrategy": "UseIPv4"
  }
}

UseIPv4 は、このDNSモジュールが問い合わせ結果を選ぶ方法に影響します。OSのIPv6を無効化したり、アプリが別のリゾルバーからIPv6アドレスを取得することを防いだりする設定ではありません。ネットワークがIPv4とIPv6の両方に対応している場合は、動作を理解した上で適切な方針を選んでください。特定のIPv6接続だけに問題があるなら、まずシステムルーティング、プロキシのアウトバウンド、サーバーまでの経路のどこに原因があるかを確認します。アドレスファミリー全体を無効にすれば一時的に症状を回避できる場合がありますが、本当の設定不足が見えなくなるおそれがあります。

ルーティングのドメイン方針とDNS問い合わせ方針は、別の層の設定です。前者はルーティング判定のために宛先をいつ名前解決するかを決め、後者はDNSモジュールの問い合わせ方法を決めます。ドメイン集合を使って振り分ける場合は、まずドメインルールで判定し、アドレス条件が本当に必要な接続だけを解決するのが基本です。すべてのリクエストを先に解決すると、ドメインで処理するつもりだった宛先にアドレスルールが影響することがあります。変更後は、Webページが開くかどうかだけでなく、ドメインルールの一致と最終的な接続先アドレスの両方を確認してください。

暗号化DNSにも到達可能なネットワーク経路が必要

暗号化DNSは問い合わせの通信を保護できますが、DNSサービス自体への接続経路も必要です。DNSサービスのアドレスがドメイン名なら、まずその名前を解決できなければなりません。さらに、その接続をプロキシ経由にすると、プロキシサーバーのドメイン名が、まだ使えないDNSに依存することがあります。このような依存関係のループがあると、クライアントは正常に起動しても、新しいドメインへのアクセスがすべてタイムアウトする場合があります。解決するには、起点となる名前解決の経路を明確にし、プロキシサーバーのアドレスを独立して解決できるか、適切に処理できるか確認してください。

クライアントの「プロキシ経由で問い合わせる」「リモートDNS」などの設定は、使用中のコアと生成された設定を踏まえて判断してください。項目名だけから、すべての問い合わせが特定の出口を通ると決めつけないようにしましょう。ドメインに応じてリゾルバーを切り替える設定では、一致しない場合にどのサーバーが使われるか、失敗時にフォールバックするか、フォールバックで想定した経路が変わらないかも確認します。リゾルバーを増やしても、必ず信頼性が上がるわけではありません。同じドメインに一貫しない結果が返る原因になることもあります。

検証するドメインを一つ選び、まずシステムの問い合わせ結果を記録してから、対象アプリで新しい接続を開始します。コマンドラインでの問い合わせは、そのツールが使用した名前解決経路を示すだけです。ブラウザーは別途セキュアDNSを使っている場合があります。設定を切り替えた後は、キャッシュが切れるまで待つか、影響範囲を理解した上で関連キャッシュを更新してください。テストのたびにサーバーも切り替えると、出口とDNSの両方が変わり、どの変更が結果に影響したのか判断できなくなります。

LAN内の機器名、社内ドメイン、ローカルサービスも確認しましょう。LANのリゾルバーでしか解決できない場合、すべてをパブリックDNSに送ると、プリンター、社内ページ、開発環境にアクセスできなくなることがあります。実際に内部ネットワークの名前に該当するものには適切な名前解決経路を残しつつ、未知のドメインをすべてローカル名として扱わないようにしてください。検索サフィックスを使う環境では、短い名前と完全修飾ドメイン名を個別にテストし、クライアントが従来の名前解決方法を変えていないか確認します。

TUNモードでできることとシステムへの影響範囲

システムプロキシと仮想ネットワークインターフェースは役割が異なる

システムプロキシは、システム設定に従うアプリにプロキシの接続先を提供します。アプリがその設定を使うかどうかは、アプリの実装次第です。TUNは仮想ネットワークインターフェースとシステムルートを使って通信を取り込み、システムプロキシを参照しないアプリの通信も処理経路に含めます。両者は「通常モード」と「高速モード」の違いではありません。Webページに問題なくアクセスできている場合、ほかのアプリやプロトコルの通信を取り込む必要があるときに限り、TUNの権限や互換性を検討してください。

v2rayNのTUN機能は、対応するネットワークスタックのコンポーネントに依存する場合があります。実際の動作はクライアントの画面と生成された設定を確認してください。プロキシのアウトバウンドにXrayを使っているからといって、任意のTUNインバウンド項目をXrayの設定に追加できるわけではありません。コア、通信を取り込むコンポーネント、グラフィカルクライアントはそれぞれ役割が異なります。有効にする前に、現在のクライアントの項目説明を読み、必要なコンポーネントが準備できていることを確認してください。その後、権限、仮想ネットワークインターフェースの作成、システムルートの設定が成功したかを調べます。

まず単独で有効にし、その後で競合を調べる

通常のプロキシ接続が使えることを確認してから、システムネットワークを取り込む可能性のあるほかのツールを終了し、作業内容を保存した上でTUNを有効にします。初回テストではDNS、ルーティング、サーバーを同時に変更しないでください。クライアントが権限の昇格を求めた場合は、スイッチを何度も押すのではなく、システムの案内に従って必要な権限を許可します。有効化後はログを見て、「インターフェースの作成失敗」「ルートの追加失敗」「プロキシ接続失敗」を切り分けます。それぞれ発生する層が異なり、対処方法も異なります。

AndroidクライアントはシステムのVPNサービスを使って通信を取り込むため、PC版の仮想ネットワークインターフェース向けのトラブルシューティングをそのまま適用できません。同じユーザー環境でVPNサービスを使う別のアプリがあると、競合することがあります。アプリごとのプロキシ設定を使う場合は、対象アプリが取り込み範囲に含まれているかも確認してください。システムのバックグラウンド制限によって、画面消灯後に接続が切れることがあります。まず切断のタイミングを確認し、必要な場合だけバックグラウンド実行の設定を調整しましょう。断続的な切断をすべてサーバー品質の問題と決めつけないでください。

ルーティングループとLANアクセス

TUNで通信を取り込む場合、プロキシサーバー自身への接続には正しい迂回経路が必要です。この接続が再び仮想インターフェースに送られるとループが発生し、再接続の繰り返し、リソース使用量の増加、完全な通信不能につながることがあります。クライアントは通常必要な迂回を処理しますが、カスタムルーティング、追加のネットワークツール、手動設定したシステムルートによって崩れる場合があります。この症状が出たら、まずTUNを無効にして元の状態へ戻し、プロキシの接続先とシステムルートを確認してください。例外ルールを次々に追加して解決しようとしないでください。

LAN上の宛先は個別にテストします。まずルーターの管理画面を開き、次にファイル共有、プリンター、社内ドメインを確認してください。プライベートアドレスの範囲を除外しても、通信経路が変わるだけで内部名の名前解決は解決しないことがあります。逆に、DNSで正しいアドレスが返っても、システムルートがそこへ直接接続するとは限りません。複数のネットワークセグメントを使っている場合や企業VPNを利用している場合は、除外範囲が相手側のネットワークと重複していないか確認します。広いアドレス範囲をまとめて除外すると、ほかの用途に影響することがあります。

UDPが使えるかどうかは、通信取り込みコンポーネント、コア設定、ノードのプロトコル、サーバーの対応、宛先ネットワークまでの経路全体によって決まります。TUNのスイッチだけでは保証できません。Webアクセスに成功しても、リアルタイム通信などほかのUDP通信が正常とは限りません。実際に使うアプリでテストし、特定のネットワークだけで失敗するかも確認してください。TCPが使えてUDPだけ失敗する場合は、システムプロキシの設定を何度も切り替えるのではなく、プロトコルの対応状況と関連ログを優先して調べます。

ネットワークを切り替えた後も再テストしてください。Wi-Fiから有線LANへの切り替え、スリープからの復帰、企業ネットワークへの接続によって、デフォルトゲートウェイ、インターフェースの優先順位、DNSが変わることがあります。クライアントがルートを正しく再設定できないと、古い状態が接続に影響し続ける場合があります。いったん通信の取り込みを停止してから再び有効にし、インターフェースの状態が復旧したか確認しましょう。確認せずにシステム上の仮想ネットワークインターフェースをすべて削除しないでください。ほかの正規のネットワークツールに影響し、復旧も難しくなることがあります。

FakeDNSのマッピングとドメイン名の復元

仮想アドレスは対応関係を引くための索引であり、接続先サーバーの実アドレスではありません

FakeDNSは、問い合わせたドメインに管理対象の仮想アドレスを返し、ドメインとアドレスの対応関係を記録します。アプリがそのアドレスへ接続すると、通信を取り込む経路でマッピングを使ってドメイン名を復元し、以降のルーティングやプロキシ接続に利用します。このアドレスはWebサイトの実アドレスでも、パブリックネットワーク上の実際の出口でもありません。アプリが特殊なアドレス範囲を取得しても、すぐに名前解決エラーと判断せず、マッピングが正しく復元されているか、想定したアウトバウンドで実際の接続が確立しているかを確認しましょう。

FakeDNSは、名前解決とその後の接続の両方を制御できる状況で役立ちます。DNS問い合わせだけがFakeDNSに届き、接続がクライアントを迂回すると、仮想アドレスでは想定どおりにアクセスできません。反対に、接続だけがクライアントに取り込まれても、問い合わせを別のリゾルバーで行えば対応するマッピングは作成されません。有効にする前に、TUNなどの透過的な通信取り込みが基本動作することを確認してください。明示的なプロキシでドメイン名を伝えられる場合は、この仕組みを追加する必要がないこともあります。コンポーネントを増やすと、管理する状態も増えます。

コアのアドレスプール、DNSサービス、スニッフィングを連携させる

以下は、対応する項目を備えたコアでアドレスプールを定義し、FakeDNSをDNSサービスとして使う例です。部分的な設定例であり、マッピングを復元できるインバウンド、正しいルーティング、DNSの取り込みと組み合わせて初めて意味があります。これらの項目に対応しないネットワークスタックの設定へ、そのまま追加しないでください。クライアントがすでにFakeDNSの設定を生成している場合は、手動設定との二重適用を避けるため、画面上の設定を優先してください。

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

例のアドレスプールには、ベンチマークテスト用に予約されたアドレス範囲を使っていますが、あらゆる環境でほかの用途に使われていないことを保証するものではありません。企業ネットワーク、実験環境、別の通信取り込みツールで使われている場合があります。有効にする前にローカルルートと既存設定を確認し、アドレスが重複しないようにしてください。プール容量はマッピングに使えるリソースを管理するためのもので、大きければよいわけではありません。接続可能なノード数を表すものでもありません。適切な容量は、リソース使用量と有効なドメイン数によって異なります。例の値を性能改善の根拠として扱わないでください。

FakeDNSスニッフィングによる復元に対応するインバウンドでは、既存のインバウンドオブジェクトに次の sniffing 項目を追加できます。ここでは項目の構造だけを示し、リッスンアドレスやポートは追加しません。通信取り込みコンポーネントが別の設定形式を使う場合は、その実装に従ってください。スニッフィングだけを有効にしてもDNSの取り込みを代替できず、失われたマッピングを新たに作ることもできません。検証では、問い合わせ、仮想アドレス、その後の接続を一連の流れとして確認してください。

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

キャッシュ、再起動、複数の名前解決方式の注意点

FakeDNSのマッピングは通常、実行中の状態として保持されます。コアを再起動しても、アプリには以前取得した仮想アドレスがキャッシュされている一方、新しいプロセスには対応するマッピングが残っていないことがあります。この場合、一部のアプリだけ失敗し、再起動後に復旧することがあります。調査する際は、まず影響を受けたアプリの既存接続を終了し、必要に応じて関連するDNSキャッシュを処理してから、再度名前解決とアクセスを試します。すぐにアドレスプール全体を変更すると、古いキャッシュと新しいマッピングが混在し、原因の特定が難しくなります。

ブラウザーやアプリに内蔵された暗号化DNSがFakeDNSを迂回すると、アプリごとに異なる種類のアドレスが返されることがあります。すべての設定が無効になったとは限りませんが、一つのアプリの結果からシステム全体を判断できなくなります。ドメイン名で統一してルーティングする場合は、アプリの名前解決設定と通信の取り込み範囲を確認してください。対象アプリが独自の名前解決方式を必要とする場合は、ドメインを識別する別の経路が残っているかを確認し、場合によってはアドレスルールだけで処理することになる点を理解しておきましょう。

LAN内のサービスに、理由なく仮想アドレスを返すのは避けましょう。内部名の解決には、LANのDNSに設定された検索サフィックスや特殊なレコードが必要な場合があり、解決結果のアドレスを直接比較するアプリもあります。まず内部ドメインを実際のアドレスへ解決できる経路を確保し、その後、FakeDNSに適した外部宛先を選んでください。実アドレスを必要とする診断ツール、アドレスに基づくアクセス制御、一部の機器検出機能は個別にテストします。Webページを開けることだけで、すべての用途を代表させないでください。

FakeDNSを無効にする際は、DNSサービスの選択、マッピングの復元設定、関連ルートも合わせて取り消し、アプリに実際の名前解決結果を取得させてください。仮想アドレスを返すDNS経路を残したままアドレスプールだけを無効にすると、設定が中途半端になります。復元後は、通常のドメインに想定どおりの実アドレスが返ることと、元のルーティングが引き続き動作することを確認します。FakeDNSを有効にした場合だけ問題が起きるなら、通常のDNS設定を基準として残し、設定を段階ごとに確認してください。故障をノードの利用不可だけに結び付けないようにしましょう。

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

取得元ごとに分けてから、用途別に整理する

複数のサブスクリプションを、一つの巨大なサーバーリストに単純にまとめないでください。取得元によって更新間隔、命名規則、利用できる範囲が異なることがあります。まず取得元ごとに独立したグループを作り、日常の選択には検索や絞り込みを使いましょう。一つの取得元で更新に問題が起きても、ほかのグループに影響させずに無効化や再インポートができます。用途のラベルはグループのメモに記載できますが、提供元の宣伝文句を、確認済みの性能を示すものとして扱わないでください。

サブスクリプションURLとサーバー共有リンクは別の情報です。前者はサーバー項目の一覧を継続的に取得するもので、後者は通常、一つのサーバーを記述します。単一ノードのリンクをサブスクリプション更新欄に入力すると解析に失敗することがあり、サブスクリプションの内容を単一ノードとしてインポートすると管理関係が失われることがあります。新しい取得元を追加する前に、内容の種類を確認して適切な画面を選んでください。動作を確認したら、用途と直近の確認結果だけを記録します。アクセス用の認証情報を含むURL全体を公開メモに保存しないでください。

自動更新には取得可能な経路が必要

自動更新には、クライアントが起動していてタスクが実行できること、サブスクリプションサービスに到達できること、リクエストに使うネットワーク経路が正しいことが必要です。システムがスリープ中、またはクライアントが終了している間も更新され続けるとは限りません。更新間隔は、提供元が許可するリクエスト頻度と実際の必要性に合わせ、過度に短く設定しないでください。一時的なリクエスト制限が発生した場合、手動更新を連打してもリクエストが増えるだけです。まずエラーの種類を確認し、少し待ってから再試行し、現在使えるサーバー項目を残しておきましょう。

プロキシ経由で更新する場合は、接続中のノードが、更新によって初めて復旧する状態ではないことを確認します。動作確認済みの予備の取得元を残す方法もありますが、リストにあるだけで利用可能と判断せず、個別にテストしてください。更新サービスへ直接接続できるネットワークなら、まずその経路を試します。重要なのは依存関係のループを避けることです。ノード一覧の取得、プロキシサーバーの名前解決、プロキシ接続の確立が、未準備の別の処理を互いに待ち続けないようにしましょう。

更新後は成功通知だけで判断せず、実際の変更内容を確認します。接続中のサーバーが残っているか、名前が変わっていないか、プロトコル設定が置き換わっていないか、絞り込みによってリストが大幅に減っていないかを確認してください。提供元が項目を削除しても、クライアントが元の用途に合う代替先を自動選択するとは限りません。必要に応じて手動で選び直し、新しい接続を確立します。長時間動作するアプリでは、接続を作り直すまで更新前の経路を使い続けることがあります。

同じノードに見えても、重複項目を安易に削除しない

異なるサブスクリプションに同じ表示名の項目がある場合もあれば、名前が違っても同じサービスを指す場合もあります。重複かどうかはメモだけでなく、プロトコル、サーバーアドレス、ポート、伝送設定を確認して判断してください。技術的な設定が同じでも、別の管理元に属する項目かもしれません。削除した項目が次回更新で再び追加されるかどうかも、サブスクリプションの管理方法によって異なります。まずグループや絞り込みで見やすくし、未確認の項目を大きなリストからまとめて削除しないでください。

手動で調整したサーバーは、リモートのサブスクリプション項目と分けて管理します。伝送設定を変更する必要がある場合は、許可されていることを確認した上で手動項目として複製し、用途が分かる名前を付けてください。元の取得元に変更があっても、手動コピーには自動反映されないため、自分で再確認する必要があります。コピーを残す目的は、正しい更新を長期的に回避することではなく、テスト条件を制御しやすくすることです。テスト後は使わなくなったコピーを削除し、古い設定を誤って選ばないようにしましょう。

PCとスマートフォンに同じ取得元をインポートしても、絞り込みルール、接続中のノード、ルーティング設定まで自動的に一致するわけではありません。v2rayN、v2rayNG、v2flyNGでは、サブスクリプション形式や設定項目の対応状況が異なる場合があります。一方で使える項目が、もう一方でも完全に互換性があるとは限りません。複数の端末で問題を調べる場合は、まずプロトコルと伝送条件を揃え、それぞれで動作を確認します。認証情報を含む設定全体を送って画面を比較しないでください。必要なら、加工済みの項目名だけを比較しましょう。

バックアップをエクスポートする前に、どのデータを含めるか確認してください。サーバー設定、サブスクリプションURL、認証情報は機密情報になり得るため、バックアップファイルはアクセスを制限した場所に保存します。別の端末へ復元した後は、ローカルのリッスンポート、ネットワークインターフェースの権限、システムプロキシの状態も確認してください。これらの環境情報は、サブスクリプションのコピーだけでは引き継げません。古い端末を整理する際は不要な設定も削除し、使っていないクライアントのフォルダーにアカウント情報が長期間残らないようにしましょう。

カスタムアウトバウンドと設定の適用範囲

アウトバウンドのタグがルーティングの接続先になる

アウトバウンドはコアから外部へ接続する方法を定義し、ルーティングはタグを使って対象のアウトバウンドを選びます。タグはローカルで参照する名前にすぎず、プロトコルや地域を自動判定する機能はありません。「direct」という名前を付けても、必ず直接接続になるわけではありません。実際の動作は、そのオブジェクトのプロトコルと設定で決まります。追加する前に既存のタグを確認し、重複がないことと、ルーティングが意図したオブジェクトを参照していることを確かめてください。タグの誤記は設定チェックの失敗や、想定した経路を確立できない原因になります。

一般的なクライアント設定には、プロキシ、直接接続、ブロックなどのアウトバウンドがすでに生成されています。特定のドメインだけを直接接続にしたい場合は、同じ機能のアウトバウンドを追加するより、ルーティングルールを追加する方法を優先してください。カスタムアウトバウンドは、異なる接続方法が本当に必要な場合、たとえば特定の通信を管理下にあるローカルプロキシサービスへ渡す場合に適しています。その場合も、クライアントがカスタム項目の統合に対応しているか、サーバー切り替え時に手動変更が上書きされないか確認しましょう。

基本オブジェクトで設定の構造を把握する

以下の例では、直接接続とブロックの基本的なアウトバウンドオブジェクトを示します。これらのプロトコルに対応するコアで利用できます。プロキシサーバーは含まれておらず、クライアント設定全体を置き換えるものでもありません。既存の設定に同じタグがある場合は、重ねて追加しないでください。また、ルールに一致しない通信は最初のアウトバウンドを使う場合があります。例の配列をそのまま置き換えると、デフォルトの接続先がプロキシから直接接続に変わる可能性があるため注意してください。

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

ブロックのアウトバウンドは、特定の接続を明示的に拒否するために使います。ネットワークの問題を直す機能ではありません。テスト中に範囲の広すぎるドメインやアドレス集合を割り当てると、ページの一部のリソースだけが欠けるなど、原因を特定しにくい状態になります。まず宛先を一つに絞ってテストしてから、対象範囲を広げてください。直接接続のアウトバウンドも、システム設定をすべて回避できるわけではありません。OSのルーティング、ファイアウォール、下位ネットワークの状況に左右されます。コアがアウトバウンドを選べたことは、経路を決定できたという意味に限られます。

別のローカルプロキシへ接続する際は自己参照を避ける

別のローカルプロキシを経由させる場合は、まずそのサービスが待ち受け中であることを単独で確認し、プロトコル、アドレス、ポート、認証方式を調べてください。待ち受け先がループバックアドレスかLANアドレスかによって、接続できる範囲が変わります。手軽だからといって、すべてのネットワークインターフェースで待ち受ける設定にしないでください。LANからの接続が本当に必要なら、システムファイアウォールとアクセス制御も合わせて検討し、ローカル専用の接続口を関係のない機器に公開しないようにしましょう。

よくある誤りは、カスタムアウトバウンドから現在のクライアント自身のプロキシ待ち受け先へ再接続することです。通信がクライアントに入った後、再び同じアウトバウンドを選ぶとループが生じます。ポート番号が同じでも同じサービスとは限らないため、待ち受けプロセスと接続処理の全経路を確認してください。多段プロキシを使う場合は各段を図にし、どの層がドメイン名を解決し、どの層がUDPを処理し、最後の接続を誰が行うかを明確にします。経路が長いほど、一段ずつ確認することが重要です。

プロキシのプロトコルによって、ドメイン名、UDP、認証の処理方法は異なります。上流プロキシで通常のWeb閲覧ができても、すべてのアプリ通信に対応するとは限りません。ローカルの上流プロキシが特定のリクエストだけを受け付ける場合は、検証済みの用途にルーティング範囲を限定します。別のコンポーネント用のアウトバウンドオブジェクトをそのまま現在のコアに貼り付けないでください。項目名が似ていても、設定形式が互換とは限りません。使用するコアとドキュメントの説明を確認し、設定チェックと起動ログで正しく受け入れられたか判断しましょう。

サーバーの切り替え、サブスクリプションの更新、ルーティングの変更に伴い、クライアントが実行設定を再生成することがあります。そのため、一時ファイルに手動で追加したアウトバウンドが消える場合があります。クライアントが正式に提供しているカスタム設定欄を優先し、設定をオブジェクトとして追加するのか、項目全体を置き換えるのか記録しておきましょう。設定全体をカスタマイズすると、接続中のサーバー選択などのグラフィカルな機能が通常どおり動かなくなる場合もあります。設定前に適用範囲を確認し、画面上では切り替えに成功しているのに、実際には固定設定が使われ続ける事態を避けてください。

カスタムアウトバウンドを検証する際は、まずテスト用のドメインを一つだけ割り当てます。ログでタグと上流への接続状況を確認してから、対象範囲を少しずつ広げてください。失敗した場合は、対象ルールが一致しているか、上流の待ち受け先に接続できるか、認証が正しいか、ドメインを解決できるかの順に確認します。複数の層を同時に変更しないでください。元に戻す際は、テスト用ルールを取り消し、参照されなくなったアウトバウンドを削除した後、デフォルトのプロキシと直接接続のルールが元の順序と動作を維持しているか確認します。

設定の検証、原因の特定、元の状態への復元

「起動できる」と「想定どおりに動く」を分けて確認する

設定チェックに合格しても、構造や一部の項目がコアの要件に合っていることを示すだけです。サブスクリプションサービスへの接続、プロキシノードの利用、ルーティング結果の正しさまでは保証されません。クライアントの起動、コアの動作、通信の取り込み、ルールの一致、名前解決の経路、実際のサービス利用を順番に検証してください。それぞれの層に固有の確認材料があり、一つのWebリクエストが成功しただけではすべてを確認できません。TUNとFakeDNSは、システムの状態や実行中のマッピングも関係するため、特に段階を分けて確認する必要があります。

変更を始める前に基準となる状態を記録します。使用中のクライアントとコア、接続中のサーバー、システムプロキシの状態、TUNの状態、ルーティングモード、アクセス可能と分かっているテスト先を記録してください。設定名と動作だけを記録すればよく、サーバーアドレスや認証情報を公開する必要はありません。今回の変更目標を「指定したドメインを直接接続にする」のように一文で明確にします。目標が具体的なほど検証しやすくなります。「ネットワーク全体を最適化する」では範囲が広すぎて、変更が役立ったか判断できません。

症状に合わせて最短の確認手順を選ぶ

クライアントが起動しない場合は、DNSの変更を続けるのではなく、実行環境、ディレクトリ権限、設定ファイルの読み込みを先に確認します。クライアントは起動するのにコアが終了する場合は、直近で変更した項目、タグ、ポートの競合を調べてください。コアは動作しているのにアプリがまったくプロキシを使わない場合は、システムプロキシ、アプリの設定、通信の取り込み範囲を確認します。通信がすでにコアに入っている場合に限り、ルーティングやアウトバウンドを調べる意味があります。問題が起きている層を見極めるほうが、すべてのコンポーネントを一度に再インストールするより効果的です。

遅延テストと実際の接続テストは分けて考えてください。テストによっては特定の宛先だけを特定のリクエスト方法で確認するため、すべてのプロトコルや用途を代表するものではありません。テストに成功した後も、実際に必要な宛先へアクセスし、出口とルーティングが想定どおりか確認します。一つのサイトだけが失敗する場合は、プロキシ経路全体が使えないと判断する前に、そのサイトが使用する関連ドメインや接続方式を確認してください。ページ本体は表示されるのに画像やログインが失敗する場合は、リソースごとに異なる振り分けが必要なことがあります。

ログは時刻と一回のリクエストを手がかりに読みます。まずテストを実行した時刻を記録し、該当する宛先、インバウンド、アウトバウンドのタグを確認してください。名前解決失敗、接続拒否、接続タイムアウト、認証失敗はそれぞれ異なる原因を示します。接続拒否は通常、相手が明示的に拒否したか、そのポートでサービスが待ち受けていないことを意味します。タイムアウトは経路、ファイアウォール、相手側の応答などが関係する可能性があります。ログの情報が足りない場合は一時的に詳細度を上げ、調査後に元へ戻してください。機密性のある宛先情報を長期間記録しないようにしましょう。

依存関係に沿って設定を元に戻す

今回複数の層を変更した場合は、まず新しい通信を開始するのをやめ、外側の通信取り込みや追加ルールを取り消してから、DNSとアウトバウンドを基準の状態に戻します。FakeDNSを無効にする場合は、前述のとおりマッピング関連の設定とアプリのキャッシュも処理してください。TUNに問題がある場合は、まず通常のシステムネットワークを復旧してから、クライアントのプロキシを確認します。誤った通信取り込みを残したままサーバーを何度も変更しても、復旧にはつながらず、新たな変数が増えるだけです。

スイッチがオフになっただけで終わらせず、復元後も必ず再テストします。クライアントが関連コアを停止したか、正しい設定を再読み込みしたかを確認し、システムプロキシが現在待ち受けている接続先を指していること、通常のWeb閲覧とLANアクセスが復旧したことを確かめてください。クライアントを終了してもプロキシ設定が残る場合は、システムのネットワーク設定を確認します。古い接続先を隠すために別のクライアントを起動しないでください。基準の状態に戻ったことを確認してから、失敗した設定を再導入し、変更範囲を最小限に絞ります。

さらにサポートを求める場合は、クライアント名、プラットフォーム、使用中のコア、再現に必要な最小手順、加工済みのエラー概要を伝えてください。サブスクリプションURL、認証項目、サーバー設定全体、プライベートなドメイン名を含むログをそのまま送らないでください。スクリーンショットを撮る前に、アドレスバー、QRコード、クリップボードの通知を確認しましょう。起動直後に終了する問題の詳しい調べ方はv2rayNが起動しない・クラッシュする場合の対処法をご覧ください。起動の問題と接続の問題を同じ故障として扱わないようにしましょう。

安定した設定には、動作を説明できること、検証できること、元に戻せることが必要です。スイッチを次々に増やすより、必要なサブスクリプショングループ、明確なルーティング順序、現在のネットワークに合った名前解決経路を保つほうが管理しやすくなります。新しい端末ではクイックスタートガイドに沿って接続を再設定し、理解できているルールだけを移行してください。用語は用語クイックリファレンスで確認できます。機能は一度に一つずつ追加し、効果と適用範囲を確かめてから残すことで、このガイドを再現可能な作業手順として活用できます。