v2rayN 高度な設定ガイド：サブスクリプション・ルーティング・DNS・TUN

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

サブスクリプションのグループには取得元や更新方法を、サーバー項目には個々の接続パラメーターを保存します。両者は別の階層です。グループのメモを変更してもプロトコルは変わらず、現在のサーバーを切り替えてもサブスクリプションは更新されません。まず取得元を整理してから絞り込みや選択を行うと、「一覧の変化」を「接続障害」と誤認しにくくなります。グループ名には用途や取得元を使い、パスワード、アクセストークン、個人アカウント情報はメモに記載しないでください。

グループを作成して更新結果を確認する

v2rayNのサブスクリプショングループ設定で新しいグループを作成し、メモとサブスクリプションURLを入力して保存したあと、そのグループを更新します。URLは完全な形で入力してください。特に「?」以降のパラメーターを省略しないようにします。チャットからコピーする場合は、末尾の空白、改行、句読点にも注意してください。更新後は、まずグループ内のサーバー一覧を確認してから接続先を選びます。グループを作成しただけでは取得元が登録されるだけで、内容のダウンロードや解析は行われません。

サブスクリプションの更新は、接続とは別のリクエスト経路を使います。取得元に直接アクセスできる環境もあれば、利用可能なプロキシ経由で更新する必要がある環境もあります。両方を個別に試し、接続パラメーターを何度も切り替えないでください。一覧が空の場合は、まず更新ログの応答ステータスと解析メッセージを確認します。Webページ、ログイン画面、アクセスエラーが返された場合、通信自体に成功していても有効なサーバー情報は取得できません。クライアントを再インストールするより、取得元の有効期限を確認するほうが効果的です。

絞り込みで表示対象は変わるが、プロトコルの機能は変わらない

サーバーの絞り込みは通常、メモのテキストを対象に行います。設定場所はグループ設定内の場合も、一覧のフィルター欄の場合もあります。まずは明確なキーワードを1つ指定し、目的の項目が表示されることを確認してから条件を追加します。フィルター欄によって通常の文字列を受け付けるものと正規表現を受け付けるものがあるため、入力欄の説明に従ってください。一覧検索とサブスクリプションの絞り込みは別物です。検索は一時的に表示を変えるだけの場合が多い一方、更新時のフィルターは保持する項目そのものを決めることがあります。

正規表現に対応した欄では、次のパターンでマッチ範囲を指定できます。縦棒は複数の語句のいずれかに一致させ、行頭記号はメモの先頭を指定し、否定先読みは特定の語句を除外します。メモのルールは情報提供元によって異なります。文字ラベルだけで接続機能を判断しないでください。プロトコル名がメモに含まれていても、実際の接続パラメーターがそのプロトコルを使っているとは限りません。項目のプロトコル、トランスポート、安全性に関する設定を確認し、選択したカーネルで動作するか判断してください。

仕事用|予備
^仕事用
^(?!.*テスト).*$

手動変更とサブスクリプション更新を分ける

サブスクリプション由来の項目は、更新時に再作成されることがあります。項目のアドレス、ポート、安全性に関する設定を変更しても、次回更新で上書きされたり、変更前の項目が重複して残ったりする場合があります。実験用の設定を長期保存する場合は、別の手動グループにコピーし、変更理由をメモに記録してください。取得元の更新を引き続き受けながら、提供元のデータとローカルのテスト用データを明確に区別できます。

Androidクライアントでも、まず識別しやすいサブスクリプショングループを作成し、更新後に結果を確認してください。v2rayNGとv2flyNGでは、グループ画面や絞り込み機能が異なる場合があります。専用のフィルター欄がない場合は、グループ選択や一覧検索を利用し、デスクトップ向けの手順を無理に当てはめないでください。インポートに成功したことは形式を認識できたというだけです。プロトコル項目を現在のカーネルが受け付けるかどうかは、起動ログと実際の通信で確認する必要があります。

更新記録として、取得元の名称、更新方法、結果、絞り込み条件の変更有無を簡潔に残してください。更新後に項目が急に減った場合は、一時的にフィルターを解除してから再更新します。項目が戻れば、原因はカーネルではなく絞り込み条件です。それでも解析できない場合は、接続確認と切り戻しに沿ってサブスクリプションのリクエストとサーバー接続を分けて確認してください。同じURLを何度もインポートして、重複グループを増やさないようにしましょう。

ルーティング設定の実践

ルーティングはカーネルに届いたリクエストを受け取り、使用するアウトバウンドを決めます。一方、システムプロキシの設定は、アプリがリクエストをローカルプロキシに渡すかどうかを決めます。アプリが入口を完全に迂回している場合、ルーティングを変更しても効果はありません。ルールを書く前に、アプリの通信が実際にクライアントへ届いているか確認してください。続いて生成された設定のプロキシ、直接接続、ブロックの各タグを確認し、画面上の名称だけで実際のタグを推測しないでください。

最初に一致するルールを優先して順序を決める

一般的なフィールドルールは上から順に評価され、最初に一致した有効なルールで出口が決まります。具体的な例外を前に、広い地域やカテゴリを対象とするルールを後ろに配置してください。たとえば、後続の直接接続用セットに含まれるテスト用ドメインでも、プロキシ経由にしたい場合は、そのルールを先に記述します。複数のルールが投票するように結果を決めることはありません。同じルールに異なるフィールドを複数指定した場合、通常はすべての条件を満たす必要があります。

以下はXrayの設定に組み込めるルーティングオブジェクトです。指定したドメインとサブドメインを先にプロキシ経由にし、続いてプライベートアドレスと中国のアドレスを直接接続にし、最後に使用するドメインセットに基づいて直接接続のリクエストを振り分けます。この例では、proxyとdirectのタグを持つアウトバウンドがすでに存在し、カーネルが必要なルールデータを読み込めることを前提としています。実際のクライアントでは生成されるタグが異なる場合があるため、使用前に必ず確認してください。

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

ドメイン、IPアドレス、名前解決ポリシーを区別する

full:example.comは完全一致するドメインのみを対象とし、domain:example.comはサブドメインも含みます。接頭辞のないドメイン文字列は部分一致として扱われることがあり、対象範囲が広がりやすくなります。範囲を明確にするには、接頭辞を指定してください。正規表現は明確な命名規則があるドメインには適していますが、あらゆる通常ルールの代わりにはなりません。ルールが複雑になるほど、問題発生時にどの条件が一致したのか特定しにくくなります。

IPアドレスのルールはリクエスト先のアドレスを処理しますが、その背後のドメインがどのようなサービスかまでは自動的に判断しません。IPIfNonMatchではドメインルールに一致しなかった場合に名前解決を試み、その後IPアドレスのルールを照合します。そのためDNSへの依存が生じます。アプリがIPアドレスだけを送る場合、カーネルが元のドメインを把握できるとは限りません。一部のプロトコルではスニッフィングによってドメイン情報を取得できますが、すべての通信で有効ではなく、ドメインを確実に復元する手段とは言えません。

ルール形式	照合対象	利用上の注意
`full:`	完全一致するドメイン	単一ホストの例外に適する
`domain:`	ドメインとサブドメイン	ドメイン群の指定に適する
`geosite:`	ドメインデータセット	セット名とデータ内容に依存
`geoip:`	IPアドレスデータセット	宛先アドレスとデータファイルに依存

Webページが開くかだけで判断せず、ルールを検証する

ルールを追加したら、カーネルを再起動または再読み込みし、未知のタグ、フィールドエラー、ルールファイルの欠落がログにないことを確認します。次に、単一の対象へ新しいリクエストを送り、アクセスログに記録された出口を確認してください。ブラウザーが既存の接続を再利用すると、ルール変更後も古い経路が使われることがあります。対象のタブを閉じるか、新しい接続を確立すると、接続の再利用をルールの不具合と誤認しにくくなります。

一致するルールがない場合、通常の設定ではデフォルトのアウトバウンドが使われます。多くの場合、アウトバウンド一覧の先頭にある項目です。そのため、デフォルトの出口もルーティング設計に含め、設定漏れがないようにしてください。調査のためにブロックルールを使う場合は、対象を明確なテスト先1つに限定し、元に戻す方法を用意します。広範囲の通信を直接ブロックすると、DNS、サブスクリプションの更新、接続確立にも影響し、単純なマッチングの問題が複数の問題に発展することがあります。

クライアントのルーティングプリセットとカスタムルールが、設定の生成時に同時に反映される場合があります。保存後は編集画面の順序だけでなく、実際に適用されたルールの順序を確認してください。構文を詳しく確認するにはカスタムルーティングルールの書き方、入口とモードの役割を理解するにはシステムプロキシとルーティングモードの違いを参照してください。テスト中は一度に移動するルールを1つにし、元に戻せる順序を記録しておきましょう。

DNS設定の最適化

DNS設定では、まず「どこが名前解決しているのか」を確認します。ブラウザー、OS、クライアントのカーネル、リモート側の出口が関わる場合があります。クライアントのDNSだけを変更しても、ブラウザーの暗号化DNSやシステムキャッシュには反映されないことがあります。リクエスト経路に沿って確認してください。まずアプリがドメインとIPアドレスのどちらを送るか、次にどの段階で上流DNSへ問い合わせるか、最後にDNSリクエストがどの経路から送信されるかを調べます。

接続先ドメインの名前解決とサーバーアドレスの名前解決を分ける

Webサイトのドメインを解決する処理と、接続先サーバーのアドレスを解決する処理は、どちらもDNSを使いますが目的が異なります。サーバーにドメイン名を設定している場合、プロキシ接続の確立前に名前解決が必要になることがあります。この段階で、まだ確立していないプロキシ経由の経路を唯一の名前解決手段にすると、依存関係が循環します。まず基本ネットワーク経由でサーバーアドレスを解決できるようにし、その後で接続先サイトのルーティングに応じた名前解決を検討するのが安全です。

クライアントの「リモートDNS」「直接接続DNS」といった項目は、設定生成用の抽象的な選択肢であり、カーネルのフィールドと必ずしも1対1で対応しません。変更する前に項目の説明を確認し、生成結果も確認してください。AndroidのVPNモードはアプリ向けに専用のDNS入口を提供する場合がありますが、デスクトップのシステムプロキシがすべてのDNSリクエストを取り込むとは限りません。ブラウザーでアクセスできるからといって、システム全体で同じ名前解決経路が使われているとは判断できません。

上流DNSとポリシーを整理して設定する

以下はXray内蔵DNSの基本設定例です。指定したドメインセットには一方の上流DNSを使い、それ以外のリクエストはもう一方へ送ります。UseIPでは2種類のアドレスを返せますが、実際の結果は上流DNSとネットワークにも左右されます。例にあるパブリックDNSのアドレスはフィールドの説明用であり、あらゆるネットワークに適するとは限りません。設定に追加する前に、現在の接続環境から到達できることを確認してください。これらのDNSクエリの出口は、ルーティングオブジェクトで別途設定する必要があります。

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

ドメイン条件は上流DNSを選ぶ基準の1つであり、フォールバック時のリクエストを完全に分離するものではありません。上流DNSの一部が失敗すると、カーネルが別のサーバーを試す場合があります。フォールバックを制限できるかどうかは、現在のカーネルが対応するフィールドを確認してください。形式上の振り分けを優先してフォールバックをすべて無効にすると、一時的な上流障害であらゆるドメインが解決できなくなるおそれがあります。まず通常の名前解決が成功することを確認してから、条件を段階的に絞り込みましょう。

暗号化DNSにも適切な出口が必要

暗号化DNSは通信方式を変更できますが、上流DNSに到達できない問題や接続の循環を自動的に解消するものではありません。HTTPS形式の上流DNSを使う場合は、上流ホスト名の初回名前解決、接続先アドレス、証明書検証、ルーティングも考慮します。暗号化DNSの上流をプロキシ経由にする前に、プロキシ自体がその名前解決経路に依存していないことを確認してください。アプリ側でも暗号化DNSが有効になっていると、クライアントのドメインセットルールからは解決後のアドレスしか見えない場合があります。

IPアドレスの種類に関する問題を調べる際は、IPv4とIPv6がそれぞれ利用できるネットワークか確認してください。返すアドレスを一方に限定すると、一時的に問題を切り分けやすくなりますが、一般的な高速化策ではありません。システムがIPv6アドレスを取得できても、利用可能な出口がなければアプリは到達不能な経路を先に試すことがあります。IPv6しか提供されていないサービスでは、IPv4を強制すると接続できません。元の設定を残し、名前解決の方針だけを一度に1つ変更して結果を比べてください。

発生している症状	優先して確認する項目	確認方法
ドメインを解決できない	上流DNSへの到達性、出口の循環	カーネルのDNSログを確認
名前解決は成功するが接続できない	IPアドレスの種類、ルーティング、接続先ポート	リクエストの実際の宛先アドレスを確認
ブラウザーだけ正常	アプリ独自のDNSとシステムDNS	アプリの設定とシステム側の結果を比較

キャッシュの影響で、設定変更の効果が現れるまで時間がかかることがあります。テスト前にアプリの接続を確立し直し、必要に応じてOSの機能でDNSキャッシュを消去してください。ただし、キャッシュの削除を恒久的な解決策と考えないでください。コマンドラインからのシステムDNS検索は通常、システムの名前解決機能だけをテストし、カーネル内蔵DNSを自動的に経由するわけではありません。新しい設定がリクエストに使われているか確認するには、カーネルログも参照してください。テストに使ったドメイン、返されたアドレス、出口の記録を残し、「ページが開く速さ」だけで判断しないようにしましょう。

完成した設定では、複数のDNSサービスを積み重ねるのではなく、クエリの種類ごとにどこへ送られるかを説明できることが大切です。TUNやFakeDNSを追加すると、DNSの入口と応答内容も変わるため、該当するセクションを続けて確認してください。名前解決エラーが起きたら、まず到達可能な上流DNSを1つだけ使う設定に戻して基本接続を復旧し、その後に振り分け、暗号化、キャッシュ設定を1つずつ追加します。上流DNS、ルーティング、通信の取り込みのどこに問題があるか切り分けやすくなります。

TUNモード

TUNは仮想ネットワークインターフェースを使い、システムルーティングから取り込んだIP通信を受け取ります。システムプロキシに対応していないアプリにも適しています。取り込み範囲は広がりますが、システムプロキシの設定を変更する機能ではなく、すべてのリクエストをプロキシ経由にする機能でもありません。通信が取り込みコンポーネントに届いた後も、ルーティングルールで直接接続、プロキシ、ブロックのいずれかを選ぶ必要があります。有効にする前に通常のプロキシ経由で現在のサーバーに接続できることを確認し、入口とリモート接続を同時に調べる状況を避けてください。

権限、ルーティング、カーネルの役割を理解する

v2rayNのTUN機能は、クライアントに組み込まれた通信取り込みコンポーネントと対応する設定によって動作します。通常のXray設定例を汎用的なTUN設定として扱わないでください。仮想インターフェースの作成、システムルートの追加、DNSの取り込みはそれぞれ別の処理で、その一部には権限の昇格が必要です。画面の案内に従って必要な権限を付与し、インターフェースの初期化が完了したかログで確認してください。スイッチがオンになっているだけでは、ルーティングが有効になったとは限りません。

有効にする前に、現在のデフォルトルート、DNS設定、起動中のほかの通信取り込みツールを記録しておきます。複数のコンポーネントが同時にデフォルトルートを変更すると、リクエストが循環したり、出口が競合したりする可能性があります。テストでは取り込み方式を1つだけ残し、通信を取り込むほかのプログラムは一時的に無効にしてください。LAN内の機器、共有フォルダー、社内ネットワークへ接続する必要がある場合は、対象のネットワークセグメントを事前に記録します。設定後にアクセス経路を失う事態を避けられます。

プラットフォーム	主な確認項目	利用上の注意
Windows	仮想インターフェース、権限昇格、ファイアウォール	クライアントの案内に従ってインターフェースを作成
macOS	システム権限、ルーティング、DNS	元に戻せるネットワーク設定を残す
Linux	インターフェースの権限、ルーティング、名前解決サービス	ネットワーク管理サービスによる設定変更に注意
Android	VPNの権限、対象アプリの選択	通常はクライアントのVPNモードを使用

プロキシ接続が取り込み経路に戻らないようにする

プロキシ接続自体が、通信取り込みのループから抜けられる必要があります。リモートサーバーへの通信が仮想インターフェースへ戻されると、カーネルが自分自身を出口として接続し続けてしまいます。クライアントには、出口のバインド、プロセスの除外、ルートの例外などの仕組みが用意されていることがあります。どれを使うかは実装によって異なります。サーバーアドレスの例外を手動で追加する場合は、ドメインの名前解決結果が変わる可能性も考慮してください。古いアドレスを固定すると、接続先の切り替え後に使えなくなることがあります。

LANへの直接接続とシステムルートからの除外は別の概念です。ルーティングで直接接続のアウトバウンドを使うと、カーネルが接続を開始します。システム側で除外すると、リクエストはカーネルに入りません。プリンターの検出、ブロードキャスト、一部のローカルサービスでは後者が必要な場合があります。プライベートアドレスを直接接続に指定するだけでは、すべての要件を満たせないことがあります。まず具体的なローカルアドレスへの接続を確認し、その後にデバイス検出をテストして、現象に応じて調整する階層を判断してください。

取り込み範囲を最小限にして検証する

初回テストでは、初期状態で動作を把握しやすい取り込み設定を使います。まず既知のアクセス可能なサイトを開き、続けてシステムプロキシに対応していないアプリを試してください。アプリの通信がカーネルのログに記録されているか確認します。記録がない場合は、サーバーを切り替える前にシステムルートとアプリの除外設定を確認してください。ログに記録されているのに失敗する場合は、出口とDNSを調べます。アプリ選択機能に対象の包含モードと除外モードの両方がある場合は、現在のモードの意味を確かめてください。

UDP、IPアドレスの種類、MTUはよくある注意点です。Webページは表示できても一部のリアルタイムアプリが失敗する場合は、UDP転送機能やファイアウォールが原因かもしれません。小さなリクエストは成功する一方、大きなデータ転送が停止する場合に、経路MTUを詳しく調べます。根拠なく固定のMTU値を設定しないでください。ログやネットワーク診断で現象を確認してから、小さく調整して比較します。ICMPを必要とする機能が、通常のTCPと同じように処理されるとは限りません。

テストを終了する際は、先にTUNを無効にし、通常のネットワークとLANへの接続が復旧したか確認してください。クライアントを終了しても問題が残る場合は、仮想インターフェース、デフォルトルート、DNSが元に戻ったか調べます。プロセスを強制終了するより、クライアントを再起動して通信の取り込みを正常に終了するほうが、後処理が実行されやすい場合があります。記録を取らずにシステムルートを削除しないでください。常用する場合は通常のプロキシモードを切り戻し手段として残し、除外が必要なアプリやネットワークセグメントを記録してください。

FakeDNS

FakeDNSは、ドメインに内部利用の合成アドレスを割り当てます。カーネルは後からマッピングを使ってドメインを復元します。目的はドメイン情報を保持し、ドメインに基づくルーティングを可能にすることであり、パブリックDNSの検索を高速化することではありません。合成アドレスは実在するサービスのアドレスではないため、生成元のマッピングや通信取り込み経路から切り離して使うことはできません。アプリがIPアドレスを送ったことでドメイン情報が失われる問題が実際にある場合に有効化し、標準の高速化スイッチとして使わないでください。

名前解決から接続までマッピングを維持する

正常な通信経路は3段階です。アプリが取り込み対象のDNS入口に問い合わせ、FakeDNSが合成アドレスを返し、アプリがそのアドレスに接続すると、カーネルがマッピングを使ってドメインを復元します。アドレスプールだけを有効にしても、アプリの問い合わせが該当する入口に届かなければマッピングは機能しません。合成アドレスを返しても、その後の接続を取り込めなければ、アプリはインターネット上では利用できないアドレスへ接続しようとします。そのため透明な通信取り込みと併用することが多いものの、両方を個別に確認する必要があります。

以下はXrayのFakeDNSに関する設定例です。fakednsでアドレスプールを定義し、DNSサーバー一覧から参照します。198.18.0.0/15はテスト用のアドレス範囲であり、実在するサイトのアドレスではありません。この例には通信取り込みの入口や完全なスニッフィング設定は含まれておらず、単独では動作する構成になりません。v2rayNの通信取り込みコンポーネントが合成アドレスの仕組みを独自に実装している場合は、別のカーネル用設定を混在させず、そのコンポーネントのフィールドを使ってください。

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

アドレスプールの容量と再利用がマッピングの有効期間を左右する

アドレスプールには十分な容量が必要で、既存ネットワークと重複してはいけません。企業ネットワークや実験環境ですでに同様のテスト用アドレスを使っている場合があるため、事前にルーティングテーブルを確認してください。プールサイズは維持できるマッピングの範囲を決めるもので、ネットワークの容量や通信速度を示す指標ではありません。長時間動作させるとマッピングが再利用されても、アプリ側には古いキャッシュが残る場合があります。カーネルの再起動後にマッピングが作り直されると、同じ合成アドレスが別のドメインに対応することもあります。

スニッフィング関連の設定でカーネルがドメイン情報を取得しやすくなる場合がありますが、情報の読み取りと接続先の書き換えは区別してください。FakeDNSのマッピングからドメインを復元する処理と、HTTPやTLSからドメインを抽出する処理は同じではありません。ルーティング向けのスニッフィングだけで、現在の構成に必要な接続先の復元までできるかどうかは、通信取り込みコンポーネントの実装を確認する必要があります。まずクライアントに用意されている関連オプションを利用し、生成された設定で各項目が同時に反映されているか確認してください。

実際のアドレスが必要な通信には例外を設ける

DNSの結果を別プロセスに渡す、設定に保存する、返されたアドレスを使ってLAN内のセッションを確立するアプリがあります。このような動作では、合成アドレスが元の通信取り込み経路から外れることがあります。その場合はドメインやアプリごとに実アドレスを返す例外を設定してください。LAN機器の検出、IPアドレスによる判定が必要なサービス、ほかの端末と名前解決結果を共有する作業は、特に個別のテストが必要です。すべてのDNSクエリを一度に合成アドレスへ切り替えないでください。

アプリ内蔵の暗号化DNSを使うと、問い合わせがFakeDNSを通らず、実アドレスが返されることがあります。これは必ずしも接続失敗につながるわけではありませんが、ドメインルールの判定条件は変わります。逆に、システムDNSが合成アドレスを取得しても、そのアプリの接続が取り込み対象から除外されていると失敗する場合があります。問い合わせの入口と接続の入口の両方を確認してください。DNSの応答だけを見て正常動作と判断しないでください。

FakeDNSを無効にしたら、まずアプリが古い結果を使わない状態にしてから接続を確立し直してください。必要に応じて、システムとアプリそれぞれのDNSキャッシュを消去します。古い合成アドレスへのリクエストが残っていると、機能を無効にしたあとにネットワークが悪化したように見えることがあります。切り戻しを確認する際は、名前解決結果が実アドレスに戻ったことと、同じ接続先に元のDNS・ルーティング経路でアクセスできることを確認してください。キャッシュの復旧とカーネルの復旧は、別々の確認項目として扱います。

FakeDNSは、ドメイン情報を保持する必要がある範囲に限って有効にしてください。特定のアプリで問題が起きたら、アドレスプールを広げたり何度も再起動したりする前に、そのアプリを実アドレスで名前解決する設定に戻して比較します。通常のDNSと通常のプロキシモードで要件を満たせるなら、よりシンプルな構成を維持できます。カーネルごとの機能差についてはXrayとV2Flyのカーネル比較を参照してください。特定の実装のフィールドを、すべてのクライアントに共通する機能として扱わないようにしましょう。

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

複数のサブスクリプションを管理する際は、すべてのアドレスを1つの大きな一覧に統合するのではなく、取得元を分け、更新を追跡し、現在のサーバーを把握できるようにすることが重要です。取得元によって同じメモが使われたり、プロトコルや更新間隔が異なったりします。混在させると選択ミスが起きやすくなります。取得元ごとにグループを作り、用途のメモで補足すると、削除、更新、障害時の切り戻しを明確な範囲で行えます。

取得元の情報とローカルの運用方針を分ける

取得元に関する情報には、サブスクリプションURL、取得した項目、サーバー側のパラメーターが含まれます。ローカルの運用方針には、グループのメモ、一覧の絞り込み、現在の選択、ルーティングルールが含まれます。サブスクリプション更新で変更されるパラメーターに、ローカルの方針を書き込まないようにしてください。あるグループを仕事用にしても、それだけで仕事用アプリがそのグループを経由するわけではありません。アプリと出口の関連付けには、ルーティングルールまたはクライアントの対応機能が必要です。

新しい取得元を初めて追加する際は、既存の接続先をすぐに置き換えず、独立したグループで更新して項目を確認します。形式、カーネルの対応状況、接続経路を確かめてから、日常的な選択肢に加えるか判断してください。取得元がサーバー一覧ではなくクライアント設定を返す場合は、該当するインポート形式で扱います。更新ボタンを何度も切り替えて無理に解析しないでください。形式エラーはネットワークタイムアウトと分けて記録します。

更新スケジュールと障害の影響範囲を一致させる

取得元ごとに適切な更新間隔を設定し、短時間に同じ取得元へ何度もリクエストを送らないようにします。頻繁に更新しても無効なアクセス情報は修復されず、取得元側のアクセス制限を受ける可能性があります。更新に失敗した場合は、まず単一のグループを更新してください。すべての取得元を一括更新する必要はありません。特定の取得元だけの問題なら、通常はシステムDNSを変更したり、ほかのグループを削除したりする必要はありません。すべての取得元で同時に失敗する場合は、共通の基本ネットワークと更新時の出口を確認します。

更新前に、現在選択している項目の取得元を確認します。更新後は、その項目が残っているか確認してください。取得元が項目を削除したり識別子を変更したりすると、クライアントが以前の選択を保持する、別の項目に切り替える、再選択を求めるといった動作をすることがあります。実際の挙動は一覧とログで確認してください。クライアントに「更新成功」と表示されても、それは今回の処理が完了したという意味にすぎません。現在の項目が新しいパラメーターに切り替わったことや、リモート接続が確認済みであることを保証するものではありません。

管理項目	推奨する方法	避けるべきこと
取得元のグループ	取得元ごとに明確なグループを作成	同じURLを複数のグループに重複してインポート
手動でのテスト	独立した手動グループに保存	直接変更して更新時の上書きを待つ
更新時のトラブル	取得元を1つずつ更新	すべての取得元と出口を同時に変更
設定のバックアップ	管理されたローカルの場所に保存	アクセス情報を含むエクスポートファイルを公開

メモだけを見て重複と判断しない

メモが同じでもサーバー項目が同一とは限りません。同じアドレスとポートでも、認証情報や安全性の設定が異なることがあります。重複を整理する前に、プロトコル、アドレス、ポート、ユーザーID、トランスポート、安全性に関するフィールドを比較してください。一覧をすっきりさせるために、取得元にある類似項目を手動で一括削除しないでください。異なる接続方式が意図的に提供されている場合があります。クライアントの重複削除機能を使う場合は、比較対象のフィールドを事前に確認し、切り戻し用に元のグループを残してください。

予備の取得元も、メインの取得元が故障してから初めて使うのではなく、個別に接続を確認しておきます。テスト時は現在のサーバーを明示的に切り替えて、新しいリクエストを送ってください。一覧の行を選択しただけでは、現在の接続先が切り替わっていない場合があります。取得元が複数あっても自動フェイルオーバーにはなりません。自動選択や負荷分散を行うには、対応する仕組み、稼働状況の判定、アウトバウンド設定が必要です。複数のグループがあるだけで自動切り替え用のプールができていると誤解しないでください。

端末を移行する際は、サブスクリプションURLだけを移行するのか、クライアント設定一式を移行するのか区別してください。設定全体のエクスポートには、ローカル待ち受け、ルーティング、DNS、端末固有のオプションが含まれることがあります。そのまま別のプラットフォームにコピーすると、新しい端末に適さない設定が持ち込まれます。通常は取得元をインポートしてから、新しい端末の入口やルーティングを設定するほうが検証しやすくなります。デスクトップとAndroidではカーネルの対応状況を個別に確認し、片方で動作したプロトコルの組み合わせが移行先で起動しない事態を避けてください。

使われなくなった取得元は定期的に整理します。ただし、その項目がルーティング、固定出口、手動テストで使われていないことを先に確認してください。グループを削除する前に用途を記録し、利用可能なサーバーへ切り替えてから削除します。取得元URLが変更された場合は、提供元の案内に従って元のグループを更新し、同じ名前のグループを増やし続けないでください。サブスクリプションの更新に失敗した場合は、サブスクリプショングループのセクションでURLと絞り込みを確認し、段階的なトラブルシューティングで更新経路を調べます。すべての失敗をサーバーの問題と決めつける必要はありません。

カスタムアウトバウンド

アウトバウンドは、カーネルが接続を開始する方法です。ルーティングタグは、リクエストの送信先となるアウトバウンドの名前を指定します。カスタムアウトバウンドは、出口を固定する、特定の通信だけをブロックする、ローカルプロキシへ接続するといった明確な用途に適しています。サーバーを選んで既定のルーティングを使うだけで、基本操作ができる場合も多くあります。アウトバウンドを追加する必要性を説明できる場合に限り、全体設定の編集を検討してください。設定が増えるほど、起動時の確認と切り戻しの記録が重要になります。

編集画面が設定全体を受け付けるか確認する

v2rayNのサーバー編集、ルーティング編集、カスタム設定の各画面は、異なる階層の設定を扱います。サーバーの入力フォームに任意のトップレベルJSONを入力することはできず、ルーティング編集でアウトバウンドが自動作成されることもありません。カスタム設定を使う前に、クライアントがファイルを直接読み込むのか、生成した設定に断片を統合するのか確認してください。実行ディレクトリに保存したファイルは次回起動時に再生成されることがあります。一時的な変更に頼らず、クライアントが用意する永続化用の設定画面を使ってください。

以下は、ローカルマシンだけで待ち受ける完全なXray設定例です。SOCKS入口を用意し、デフォルトでは直接接続にして、指定したテスト用ドメインをブロックします。リモートのプロキシサーバーは設定されていないため、サブスクリプション接続の代わりにはなりません。入口、タグ、ルーティングの参照関係を確認するための例です。ポート番号は例として設定しています。すでに使用中の場合は、設定とテストコマンドの両方を変更してください。アクセス制御を設定せずに、待ち受けアドレスをすべてのネットワークインターフェースに変更しないでください。

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

タグ、デフォルトの出口、参照関係を確認する

参照される各アウトバウンドには、明確で重複しないタグを設定してください。ルーティングのoutboundTagは、実際に存在するアウトバウンドに対応している必要があります。大文字・小文字の違いや前後の空白だけでも、設定エラーや想定外の動作につながることがあります。ルールに一致しないリクエストには、通常、一覧の先頭にあるアウトバウンドが使われるため、一覧の順序を変えるとデフォルトの動作も変わります。ルールのテキストだけでなく、デフォルトの出口と例外用の出口も分けて記録してください。

直接接続のアウトバウンドは、カーネルがローカルネットワークから接続先へ接続することを意味します。リクエストがクライアントに入らなかったという意味ではありません。ブロック用アウトバウンドは、一致した通信を明示的に終了します。別のローカルSOCKSサービスへ接続するには、待ち受けアドレス、ポート、認証方式を明確にし、リクエストが現在の入口へ戻らないようにしてください。同じ待ち受けポートを入口と下流の出口の両方に使うのは、よくあるループの原因です。2つのサービスが同じアドレスとポートを同時に使うこともできません。

リモート側のパラメーターはサーバー設定に合わせる

リモートのプロトコル用アウトバウンドを追加する場合、アドレス、ポート、認証情報のほかに、トランスポートのパス、サービス名、サーバー名、公鍵などが必要になることがあります。各項目はサーバー側の設定に合わせ、別の項目からパラメーターを組み合わせないでください。REALITYはトランスポートのセキュリティ方式であり、プロトコル名をREALITYに変更するだけでは有効になりません。関連するパラメーターの説明はREALITYの概要を参照してください。

クライアントに特定のプロトコルが表示されても、選択したカーネルがすべてのセキュリティ設定やトランスポートの組み合わせに対応するとは限りません。XrayとV2Flyでは対応範囲が異なります。Androidのv2rayNGとv2flyNGでも、設定フィールドをそのまま置き換えられるとは限りません。設定を読み込む前に選択中のカーネルを確認し、続いて起動ログを確認してください。フィールドが未対応と表示された場合は、パラメーターを削り続けて無理に起動させるのではなく、どの実装に属するフィールドか調べてください。

プロキシを多段化する場合は、各段の接続経路と名前解決経路を個別に確認する必要があります。外側の出口が確立する前に、内側の接続をその出口経由で行うことはできません。タイムアウト、証明書、IPアドレスの種類に関する問題が重なることもあります。初めて設定する場合は、各出口が単独で動作することを確認してから、カーネルが対応する多段接続の仕組みで連結してください。画面に複数のサーバーが表示されているだけでは、多段プロキシが構成されたことにも、通信が一覧の順に通過することにもなりません。

カスタム設定の検証は、起動成功、入口への接続、単一のルーティングルールの順に進めてください。通常のGUI設定を基準として残し、実験に失敗したらその設定に戻します。失敗した状態にアウトバウンドを追加し続けないでください。ログではプロトコルのフィールド、タグの参照関係、待ち受けポートの競合を重点的に確認します。認証情報を含む設定ファイル全体を公開する必要はありません。この3段階の関係を確認してから、複雑な出口の組み合わせを検討すれば、保守の負担を抑えられます。

接続確認と切り戻し

接続トラブルは、アプリの入口、ローカルカーネル、名前解決、ルーティングの出口、リモート側のハンドシェイク、接続先サービスの順に調べます。エラーが発生する階層はそれぞれ異なります。すべてを「サーバーの故障」と扱うと、最も簡単に確認できる箇所を見落とします。安定して再現できるテスト先を選び、クライアント、カーネル、入口のモード、現在のサーバーを記録してから設定を変更してください。変数を1つずつ変えれば、どの設定で復旧したかを把握できます。

まずローカルの入口とカーネルの起動を確認する

カーネルの起動に失敗すると、システムプロキシが設定済みでも、アプリがローカルの待ち受けポートに接続できない場合があります。まずログでフィールドのエラー、ポートの競合、権限不足がないか確認し、次に待ち受けアドレスとポートを確認してください。画面に表示されるローカルポートとカスタム設定のポートが異なる場合があるため、実際に動作している設定を参照します。HTTPプロキシ用のポートをSOCKSポートとしてテストしないでください。入口のハンドシェイク方式が異なるため、ポートを間違えるとすぐに失敗することがあります。

次のコマンドではSOCKS入口を明示し、ドメインの名前解決をプロキシ経由で行えます。curlがインストールされ、入口に例のポートが使われている端末でのみ利用してください。このコマンドで、すべてのアプリやTUNによる通信取り込みを確認できるわけではありません。接続が拒否された場合は、まずローカルの待ち受けを確認します。プロキシに接続した後で失敗する場合は、ルーティングとリモート側のログを調べてください。テスト用ドメインは通常のリクエストを送るためのもので、すべてのサービスで同じネットワーク条件になるとは限りません。

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

名前解決の失敗とハンドシェイクの失敗を分ける

サーバーのドメインを解決できない場合、リモートとのハンドシェイクはまだ始まっていません。まず基本DNS、現在のネットワーク、プロキシ経由の名前解決が循環していないか確認してください。名前解決には成功するものの接続がタイムアウトする場合は、ポートへの到達性、ファイアウォール、取得元の状態を調べます。タイムアウトしたからといって、プロトコルのパラメーターが正しいとは限りません。単に何らかの待機が時間内に終わらなかったという意味です。接続直後に切断される場合は、プロトコル、安全性、トランスポートのパラメーターがサーバー側と一致しているか確認してください。

証明書関連のエラーでは、検証を無効にして原因を隠すのではなく、システム時刻、サーバー名、証明書チェーンを確認してください。パスやサービス名を指定するトランスポートでは、大文字・小文字、先頭のスラッシュ、空白が一致に影響する場合があります。REALITYのパラメーターも取得元の情報に照らして確認し、似た項目から流用しないでください。調査情報を公開する場合は、エラーの種類とフィールド名だけを残し、識別子やアドレスのトークンなどの機密情報を隠してください。

失敗した段階	よくある兆候	次に行う確認
ローカルの入口	接続拒否、待ち受け失敗	ポートとカーネルの起動を確認
名前解決	ドメイン検索の失敗	上流DNSと名前解決の循環を確認
リモート接続	タイムアウト、接続切断	ポートとトランスポートの設定を確認
接続先へのリクエスト	一部のサービスだけ失敗	ルール、出口、IPアドレスの種類を確認

機能を逆順に無効化して設定を戻す

問題が特定の機能を有効にした直後に発生した場合は、まずその機能を無効にします。複雑な構成は、FakeDNS、TUN、カスタムDNS、カスタムルーティングの順に、通常のプロキシ設定へ段階的に戻します。切り戻すたびに再テストしてください。FakeDNSを無効にした後は古いキャッシュへの対処が必要です。TUNを無効にした後は、システムルートが復旧したことも確認します。画面のスイッチを元に戻すだけでは、既存の接続やキャッシュによる影響が残る場合があります。

サブスクリプションの更新失敗とWebページへのアクセス失敗は、分けてテストしてください。プロキシ経由の通信は正常でサブスクリプションだけ失敗する場合は、URL、応答内容、更新方法を確認します。更新には成功してもサーバーに接続できない場合、更新成功は接続パラメーターが有効であることを示しません。複数の取得元で同時に問題が起きる場合は、共通の入口と基本ネットワークを調べます。特定の項目だけが失敗する場合は、ほかの利用可能な項目を比較用に残し、すべての取得元を同時に削除しないでください。

一部のアプリだけで問題が起きる場合は、正常なアプリとの間で入口の方式、独自DNS、UDPの利用、アプリの除外設定を比較します。Webページが開いてもUDPが正常とは限らず、システムプロキシが正常でも仮想インターフェースが正常とは限りません。アプリの既存の長時間接続が古い出口を使い続ける場合もあるため、接続を確立し直してから判断してください。リモート側を詳しく確認する手順はノードのタイムアウト調査ガイドを参照してください。

問題が解決したら、発生した現象、確認できた失敗段階、変更内容、復旧テストを記録します。一時的にログレベルを上げた場合は、日常使用の設定に戻してください。接続先アドレスを含むログを長期間保存しないようにします。問題を再現できない場合は、安定した基準設定を維持し、未検証の最適化を追加しないでください。初回接続の手順を確認するにはクイックスタートに戻り、別のプラットフォーム用のインストール方法はクライアントのダウンロードページを参照してください。説明、検証、切り戻しが可能な設定経路を1つ保つほうが、スイッチを増やし続けるより長期運用に適しています。