v2rayN 詳細設定

設定の基本とコアの違い

詳細設定は、まず正常に動作する基本構成を用意してから始めましょう。デスクトップでは v2rayN が主な選択肢です。インストーラーはクライアントのダウンロードページから入手できます。Android では、必要なコアに応じて v2rayNG または v2flyNG を選べます。クライアントはサーバー情報の保存、設定の生成、実行状態の制御を担い、コアはプロトコル接続、ルーティング、名前解決を処理します。画面に項目があっても、実行中のすべてのコアが同じ方法で処理するとは限りません。切り分ける前に、使用中のクライアント、接続プロトコル、コア、通信の取り込み方式を確認し、異なる層の問題を混同しないようにしてください。

動作確認済みの接続経路を基準にする

まず追加の通信取り込み機能を無効にし、動作確認済みのサーバーとシンプルなルーティングを使って、ブラウザーからシステムプロキシ経由でアクセスできることを確認します。次に、ローカルの待ち受けアドレス、HTTP または SOCKS のポート、現在のルーティング方式、DNS の設定を記録します。この段階で接続できない場合は、TUN や FakeDNS をまだ有効にしないでください。機能を追加すると変数が増えるだけで、誤ったサーバーアドレス、ポート、認証情報は修正されません。サーバー名に「基本構成」などのメモを付けておくと、一覧の固定行番号に頼るより確実です。

テストではクライアント内の単発テストだけでなく、実際の利用場面も確認します。サーバーテストの成功は、通常、そのテスト先へのリクエストが該当する設定を経由したことを示すだけです。すべてのアプリがシステムプロキシに従うことや、対象サービスのあらゆる接続方式が使えることまでは保証しません。普段使うウェブサイトを開き、ログインが必要な操作を一度行って、ログで選択されたアウトバウンドも確認しましょう。ブラウザーは正常なのに特定のアプリだけ失敗する場合は、構成全体をすぐ入れ替えるのではなく、まずアプリ独自のプロキシ設定、接続プロトコル、キャッシュを調べてください。

画面上の設定と生成された設定を区別する

v2rayN のサーバー編集、ルーティング編集、DNS 設定は、設定を行うための画面です。実行時に生成されるファイルは、その設定内容が反映された結果です。生成ファイルを直接編集すると、サーバーの切り替えやコアの再起動時に上書きされることがあります。変更を継続して使う場合は、まずクライアントが用意する設定項目で行ってください。独自の設定が必要な場合は、対応するカスタム設定機能を使い、元の設定も別途保存します。メニュー名や配置は画面の変更に伴い変わることがあります。古いスクリーンショット上の位置ではなく、機能の意味と実際に生成された内容を確認してください。

このページの JSON 例は、Xray の設定断片を対象とし、該当するフィールドのみを示しています。単独で起動できる完全なクライアント設定ではありません。完全な設定には、インバウンド、サーバーへのアウトバウンド、その他の必須パラメーターも必要です。別のコアを使う場合、各フィールドをそのまま流用しないでください。「ルーティング」や「DNS」といった概念が同じでも、フィールド構成、既定値、処理手順が異なることがあります。特にデスクトップ版の TUN で使われる実行コンポーネントは、クライアントが実際に起動しているものを確認してください。選択中のサーバープロトコルだけから判断することはできません。

変更する項目は一度に一つ

設定を変更する前に、元に戻せるコピーを保存し、「テスト用ドメインを指定したアウトバウンドへ送る」など、今回の変更目的を具体的に記録します。「ネットワークを最適化する」のような曖昧な目的は避けましょう。関連する項目を一度に一つだけ変更し、必要なコンポーネントを再起動して同じテストを繰り返します。結果を記録してから次に進んでください。ルーティング、DNS、通信の取り込みは互いに影響することが多く、同時に三つを変更すると、接続が復旧しても何が効いたのか分からなくなります。次回の更新や再起動後に問題が再発するおそれもあります。

ログは必要な範囲にとどめます。一時的にログレベルを上げると、設定の読み込みやルールのマッチングを確認しやすくなりますが、ドメイン名、アドレス、接続情報が記録されることもあります。問い合わせ時はエラー前後の必要な部分だけを残し、サブスクリプションの URL、認証情報、個人のアクセス履歴は削除してください。タイムアウトが発生する場合は、ノードのタイムアウトを切り分ける手順に沿って確認できます。基本構成が安定したら、以下のサブスクリプションとルーティングの各章に進みましょう。

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

サブスクリプションは、サーバー設定をまとめて更新するための入口です。グループは、クライアント上で設定を整理・表示するための単位です。両者は関連していますが、同じものではありません。一つのグループにサブスクリプションを関連付けることも、手動で追加したサーバーを保存することもできます。すべてのサーバーを一つの一覧にまとめず、設定の入手元ごとにグループを分けるのがおすすめです。更新に失敗した際に原因となった入手元を特定しやすくなり、サブスクリプションを削除または無効化する場合も影響範囲を把握できます。グループ名には用途や入手元を記載し、長い宣伝文句のようなノード名をそのまま使う必要はありません。

まず入手元を整理し、その後サーバーを更新する

サブスクリプションのグループ設定でグループを作成し、入手したサブスクリプション URL を入力します。保存したことを確認したら、そのグループだけを更新してください。更新後は取得数とエラー内容を確認し、サーバー一覧に戻ってアドレス、プロトコル、メモが適切か確認します。初回の読み込み時は自動更新をすぐ有効にせず、複数の入手元も同時に追加しないでください。まず一つの入手元について、取得、解析、保存、接続がすべて正常に動作することを確認します。そうすれば、後からネットワークの問題、サブスクリプションの内容、グループ追加による設定の競合を区別しやすくなります。

サブスクリプション URL にはアカウントを識別する情報が含まれることが多いため、アカウント情報と同様に管理してください。完全な URL をサーバーのメモ、公開スクリーンショット、問い合わせ用ログに記載しないでください。URL を短くするために、信頼できない短縮サービスを利用するのも避けましょう。サービス提供元が URL やアカウント識別情報を変更した場合は、グループ設定で古い URL を更新してください。リンクを開けてもサーバー一覧が空の場合、必ずしもクライアントの障害とは限りません。アカウントの状態、コンテンツ形式、サーバーから返された案内ページも解析結果に影響します。

絞り込みでできるのは候補の削減

絞り込みは通常、サーバーのメモやクライアントが対応する条件に基づいて一覧の候補を減らす機能です。サーバーの実際の所在地、プロトコルの機能、稼働状態を変えるものではありません。また、画面上の検索とサブスクリプションのフィルターは区別が必要です。検索は条件に合わない行を一時的に隠すだけで、検索語を消せば再表示されます。一方、サブスクリプションのフィルターは更新時に項目を除外し、ローカルのグループに取り込まれないことがあります。設定がどちらに該当するかを確認し、「除外された」項目を「提供元が削除した」と誤解しないようにしてください。

画面によって、フィルター欄が受け付ける形式は通常のキーワード、複数条件、正規表現など異なります。入力欄の説明に従ってください。正規表現に対応している場合、^(テスト|予備) はメモが「テスト」または「予備」で始まる項目にマッチします。これは式の例であり、すべてのクライアントのフィルター欄で使えるわけではありません。更新後に一覧が空になった場合は、まずフィルター条件を消して再更新し、その後条件を一つずつ追加してください。大文字・小文字、空白、全角記号、サービス提供元による名称変更で、以前使えたフィルターが機能しなくなることがあります。

ローカルの変更と選択中のサーバーを保護する

サブスクリプションから取り込んだ項目は、通常、その後の更新によって管理されます。アドレス、ポート、トランスポートの項目をローカルで編集しても、次回の更新時にサブスクリプションの値へ戻ることがあります。メモなどの項目が保持されるかどうかも、クライアントのマージ方法によります。異なるパラメーターの設定を継続して使う必要がある場合は、独立した手動グループにコピーし、変更理由をメモに記載してください。サブスクリプションの項目は入手元に従って更新し、手動で追加した項目は管理可能な検証用に使えば、二つの運用方法を混同せずに済みます。

更新後は、現在使用するサーバーをもう一度確認します。一覧の順序変更、項目名の変更、古いサーバー情報の削除などにより、以前の選択が引き続き適切とは限りません。「更新成功」だけで済ませず、実際に有効なサーバーが想定したグループに属していることを確認し、実際のリクエストを一度実行して検証してください。一括テストを行う場合は、現在の用途に関係する項目に絞ります。大量の並列テストはネットワークや端末のリソースを消費し、テスト先の制限にも左右されるため、そのままサーバーの品質ランキングとみなすことはできません。

一覧が空になる場合と解析エラーへの対処

更新に失敗したら、まずどの段階でエラーが発生したか確認します。リクエスト自体が完了しない場合は、URL、ネットワーク、更新時にプロキシが必要かを確認してください。リクエストは完了したのに解析できない場合は、返された内容がサブスクリプションか、それともログイン画面や期限切れの案内かを確認します。更新成功と表示されても一覧が空の場合は、フィルター条件とプロトコルの互換性を確認してください。入手元が有効かを確認する前に、クライアントを繰り返しリセットしないでください。詳しい切り分けはサブスクリプションの更新失敗・解析エラーへの対処もご覧ください。すべての項目を削除するより、元のグループを残して新しい設定を試す方が復旧しやすくなります。

ルーティングルールと通信の振り分け

ルーティングは、接続ごとに使用するアウトバウンドを決定する機能です。サブスクリプションを生成したり、サーバーのパラメーターを修正したりするものではありません。条件を順番に確認する判定表のようなもので、ルールにマッチした通信は指定されたアウトバウンドへ渡されます。Xray の一般的なルーティングでは先にマッチしたルールが優先されるため、個別の例外は通常、広い範囲を対象とするルールより前に置きます。クライアントで「全般」やプリセットを選ぶと、生成されるルールが変わる場合があります。カスタム設定を始める前に、実際にどのルーティング設定が有効か確認してください。

具体的な目的を一つ決める

まず、変更したい動作を具体的に決めます。たとえば、テスト用ドメインを直接接続する、明確に不要な宛先アドレスを遮断する、といった目的です。出所不明のルールを大量に取り込み、ページが開くかどうかだけで効果を推測するのは避けましょう。ホスト名が安定しているサービスにはドメインルール、アドレス範囲が明確なネットワークには IP ルール、ポートルールはアプリの用途を考慮して慎重に使います。一つのサービスが複数のドメイン、コンテンツ配信先、ログイン用エンドポイントに接続することもあります。トップページのドメインだけを設定しても、すべての操作をカバーできるとは限りません。

Xray のルールでは、full:example.com はドメイン全体への完全一致を表し、domain:example.com はそのドメインとサブドメインにマッチします。これらのプレフィックスがない通常の文字列は、異なる照合方法で処理される場合があるため、「キーワードを含む」と「特定のドメインに属する」を混同しないでください。IP 条件では、個別のアドレスまたは CIDR のネットワーク範囲を指定できます。ルールを管理する際は、各ルールの目的、対象、テスト方法を記録しましょう。「ルールを最適化」などの名前だけでは、後から削除してよいか判断できなくなります。

一つのルール内で条件がどう組み合わさるか

一つのルールにある異なる条件は、通常すべてを満たす必要があります。たとえば、ドメインとポートの両方が一致して初めてマッチします。同じリスト内の複数候補は、選択可能な範囲を表します。あるドメインと別の IP 範囲をそれぞれ同じアウトバウンドへ送る場合は、通常、別々のルールに分けます。一つのルールに詰め込み、どちらか一方に一致すればよいと考えないでください。この違いを見落とすと、ルールが存在するのに一度もマッチしないことがあります。ルールを追加したら、実際に条件を満たすリクエストを送ってテストし、選択されたアウトバウンドも確認します。

以下の設定例は、ルールの簡単な順序を示しています。特定のテスト用ドメインを先に直接接続し、次にプライベートアドレス範囲を直接接続し、最後に TCP と UDP の通信を明示的にプロキシへ送ります。例にある direct と proxy は、実際のアウトバウンドタグに対応している必要があります。コアが自動生成する予約名ではありません。この断片は有効な Xray 設定に組み込む必要があり、単独では起動できません。プライベートアドレスのルールは実際のネットワーク構成に合わせて調整してください。すべてのプライベートアドレスが使用中の端末のローカルネットワークにあるとは限りません。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

ドメイン、名前解決、既定のアウトバウンド

AsIs は、IP ルールへのマッチングのためにルーティング段階でドメインを積極的に名前解決しないことを意味します。接続先がすでに IP アドレスであれば、引き続き IP ルールの対象になります。接続先がドメイン名しかない場合、一部の IP ルールは想定どおり機能しません。IPIfNonMatch は、ドメインルールにマッチしなかった場合に名前解決を試み、その後にルールを照合します。その場合、リゾルバーと名前解決経路への依存が生じます。一つの IP ルールを機能させるためだけに、DNS リクエスト自体が到達可能かどうかを見落とさないでください。どのルールにもマッチしなかった接続の既定アウトバウンドも確認しましょう。最後に明示的なルールを置くと、設定を読みやすくできます。

ルールがあっても、クライアントが必要なドメイン名を認識できるとは限りません。アプリが IP アドレスに直接接続する場合もあれば、自分で名前解決してから接続する場合もあります。スニッフィングが有効か、どのプロトコルを識別できるか、その結果がルーティングに使われるかによって、確認できる情報は変わります。スニッフィングですべての暗号化通信からドメイン名を復元できるわけではなく、万能な対処法でもありません。まずリクエストに含まれるのがドメイン名か IP アドレスかを確認してから、ルール、DNS、通信の取り込み方式を調整してください。条件をむやみに増やすより効果的です。

検証では、ルールの対象、対象外の宛先、ローカルサービスをそれぞれテストし、一つの経路だけが使えることを確認して終わらないようにします。ルールを追加した後に多くのリクエストが失敗する場合は、まずそのルールを無効化して基本構成に戻し、順序、条件の組み合わせ、アウトバウンドタグを確認してください。遮断ルールは特に、対象範囲が明確な位置に置く必要があります。場所を誤ると、名前解決、認証、更新のリクエストまで遮断するおそれがあります。ルーティングテーブルを長期的に使う場合は、古くなった例外を定期的に削除し、クライアントの更新やコアの変更後に生成結果を確認してください。以前の設定が常に同じように実行されるとは限りません。

DNS 設定と名前解決の経路

DNS の問題は、単に「別のリゾルバーに変更する」だけでは解決しないことがあります。アプリはシステムのリゾルバーを使う一方、クライアントのコアがルーティングや直接接続用に独自の名前解決を行う場合もあります。プロキシサーバーが接続先のドメイン名をリモート側で解決することもあります。これらのリクエストは発生する場所が異なり、それぞれ異なるルーティングやネットワーク条件の影響を受けます。適切な設定場所を選ぶには、問題がアプリの名前解決、コアの名前解決、リモート接続のどの段階で発生しているかを特定してください。ブラウザーでページが開かず、サーバーテストは正常な場合、DNS だけでなく、アプリが想定したプロキシを使っていない可能性もあります。

三つの名前解決経路を整理する

一つ目は、端末からローカルリゾルバーへの経路です。通常、アプリが利用するドメイン検索を担います。二つ目は、コアから設定済みの名前解決サービスへの経路で、IP ルールの照合や直接接続に使われることがあります。三つ目は、プロキシ経由でドメイン名をサーバーに渡し、サーバー側で名前解決する経路です。すべての接続がこの三つを通るわけではありません。現在のモードに照らして、問い合わせがどこから送信され、どのアウトバウンドを通り、どの種類のアドレスが返るのかを書き出すと、ある DNS 設定が一部のサイトに影響し、別のサイトには影響しない理由を把握できます。

名前解決サービスへの接続方法も確認してください。従来の UDP クエリと暗号化された HTTPS クエリでは、必要な伝送方式が異なります。アドレスを URL に変えるだけで、すべてのコアが自動的に対応するとは限りません。Xray の DNS サービス設定には、アドレス形式に応じた処理上の意味があり、コアのルーティングを使うか、ローカル接続するかといった違いもあります。他のコンポーネントでは異なるフィールドが使われる場合があります。現在のコアが対応する形式を確認し、名前解決リクエストが実際に希望するアウトバウンドを通っているか検証してください。

名前解決の循環依存を先に解消する

ドメイン名で指定した名前解決サービスを使うには、まずそのサービスの IP アドレスを知る必要があります。プロキシサーバーのアドレスもドメイン名であれば、プロキシ接続を確立する前に必要な名前解決を済ませなければなりません。「すべての DNS を、まだ確立していないプロキシ経由にする」一方で、プロキシサーバーへの接続にも同じ DNS が必要な設定は循環依存になります。起動後にすべてのリクエストがタイムアウトすることがあります。サーバーアドレスや名前解決サービスに到達可能な初期解決経路を用意し、まだ確立していない接続から独立させてください。タイムアウトや再試行を増やしても解決にはなりません。

以下は、Xray 内蔵 DNS の簡略例です。静的マッピングでテスト用ドメインを上書きし、サーバーリストとクエリポリシーで内蔵リゾルバーの動作を制御する方法を示しています。この例だけでは、オペレーティングシステムのすべての DNS を取り込むことはできず、DNS リクエストのアウトバウンドも定義していません。example.com とドキュメント用アドレスは構造の理解を目的とした例であり、本番環境の設定には使わないでください。実際の名前解決サービスは、接続元ネットワークからの到達性や管理要件に基づいて選択します。

{
  "dns": {
    "hosts": {
      "example.com": "192.0.2.10"
    },
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

静的マッピングは、そのドメインの通常の動的な名前解決を迂回します。短期間の診断には使えますが、コンテンツ配信サービスのアドレスを安易に固定する用途には向きません。サービスは地域、負荷、時間帯によって異なるアドレスを返すことがあり、固定した結果が古くなると接続に失敗します。診断が終わったら一時的なマッピングを削除し、リクエストを再実行してください。名前解決の結果が正しくても、サービスが使えるとは限りません。接続エラーをすべて DNS の問題とみなさず、宛先ポート、トランスポートプロトコル、サーバー側の接続処理も確認してください。

IPv4、IPv6、キャッシュ

UseIP は IPv4 と IPv6 のアドレスを検索し、UseIPv4 または UseIPv6 は検索するアドレスの種類を制限します。IPv4 に限定するのは、IPv6 経路の障害を切り分けるための比較テストとしては使えますが、一般に速い設定と説明すべきではありません。端末が IPv6 アドレスを取得できても、選択したアウトバウンドがそのアドレスへ正常に接続できるとは限りません。反対に、IPv6 のみで利用できる宛先は、IPv4 に限定しても解決できません。端末のネットワーク、プロキシサーバー、対象サービスの三者が対応する方式を踏まえて判断してください。

名前解決のキャッシュは、オペレーティングシステム、ブラウザー、アプリ、コアにそれぞれ存在することがあります。DNS を変更した直後に開いているページを更新しても、以前のアドレスや既存の接続が使われる場合があります。テストでは新しい接続を作り、必要に応じて影響を受けるアプリやコアを再起動してください。Windows ではシステムの DNS キャッシュ消去機能を使えます。macOS と Linux では、キャッシュの管理方法がシステムサービスによって異なるため、他のプラットフォームのコマンドをそのまま使わないでください。設定をすべて繰り返し消去するより、変更前後の名前解決結果を記録する方が有益です。

リゾルバー名だけでなく、現象から切り分ける

ドメイン名では失敗し、同じサービスの既知の IP 経路では正常な場合は、クエリのタイムアウト、アドレスの種類、返された結果を優先して確認します。ドメイン名を解決できても接続に失敗する場合は、ルーティング、ポート、サーバーパラメーターを調べます。TUN 使用時だけ失敗するなら、DNS の取り込みと仮想ネットワークインターフェースの経路も確認してください。リゾルバーを変更して復旧しても、今回のテストで以前の経路に問題があったと分かるだけで、新しいリゾルバーがすべてのアプリに適している証明にはなりません。最終的な設定はルーティングの目的に合わせ、基本構成に戻せる名前解決方法も残しておきましょう。

TUN モードと通信の取り込み

システムプロキシは、システム設定に従うアプリが利用します。TUN は仮想ネットワークインターフェースを通じて、選択した IP 通信を処理コンポーネントへ送る仕組みです。両者が取り込むレイヤーは異なります。システムプロキシを参照しないアプリには、TUN が別の経路を提供できる場合がありますが、「すべての通信が必ずプロキシ経由になる」という意味ではありません。実際の動作は、システムルーティング、除外ルール、DNS の取り込み、UDP の対応状況、アウトバウンド設定にも左右されます。システムプロキシで正常に動作する基本構成は、TUN を有効にする前の重要な比較対象です。サーバー接続の失敗を直すために TUN を使わないでください。

実行コンポーネントとシステム権限を確認する

v2rayN で TUN を有効にする前に、現在のクライアントが提供する関連設定と、起動ログに表示される実行コンポーネントを確認してください。サーバーが Xray プロトコルを使っていても、TUN インターフェースを同じコアが直接作成するとは限りません。コンポーネントによって設定構造、通信スタック、DNS の動作が異なるため、元の Xray フィールドを別のコンポーネントの TUN 設定にそのまま適用することはできません。初回の有効化では既定値を使うか、変更を最小限にします。細かなパラメーターを調整する前に、インターフェースの作成、ルートの設定、リクエスト経路を確認してください。

仮想インターフェースの作成やシステムルートの変更には、通常、追加の権限が必要です。Windows ではクライアントの指示に従って必要な権限を付与します。Linux ではインターフェースの作成とルートの変更に必要な権限が必要です。macOS ではクライアントが要求するシステム許可を完了してください。権限エラーはログやシステムの通知で確認し、スイッチの状態だけで成功と判断しないでください。有効表示になっていてもインターフェースが作成されず、ルートも設定されていなければ、アプリは引き続き元の経路を使うことがあります。この場合は、振り分けルールを変更する前に権限または起動エラーを解消してください。

ループと二重の通信取り込みを防ぐ

TUN で取り込んだ接続は、アウトバウンドを通じてネットワークに接続します。アウトバウンド自身の接続をそのまま入口へ戻すと、ループが発生します。クライアントは通常、インターフェースの選択、ルートの除外、その他の仕組みでこれを防ぎます。端末で別の VPN、ゲートウェイソフト、二つ目の通信取り込みツールを同時に実行すると、これらの仕組みが競合することがあります。まず他のツールを停止して比較し、その後一つずつ再開してルートの競合を確認してください。どちらのソフトも「接続済み」と表示しているだけでは、併用できるとは判断できません。

TUN を有効にした後も、システムプロキシを有効にしておくか検討します。アプリがリクエストをローカルプロキシへ送信し、その後にもう一つの経路で処理されると、二重の取り込みや迂回が発生し、ログも分かりにくくなることがあります。クライアントやモードによって設計は異なるため、両方を必ず有効にする、または必ず無効にすると決めつけないでください。現在のモードの説明に従って設定し、それぞれテストします。ローカルのプロキシポートが引き続きリクエストを処理しているか確認すると、システムプロキシを無効にした後に一部アプリの動作が変わった理由を把握できます。

MTU、UDP、ローカルネットワークへのアクセス

MTU はインターフェースで扱えるパケットサイズを決めます。経路上のカプセル化やネットワーク環境によって、大きなパケットの処理に問題が生じることがありますが、MTU をむやみに小さくすると、分割や処理の負荷が増える可能性もあります。「ハンドシェイクは成功するが転送が止まる」「特定の大きなリクエストだけ失敗する」といった兆候がある場合に、MTU を切り分け項目に加えてください。少しずつ調整し、同じリクエストを再テストします。すべてのプラットフォームで使える万能な数値はありません。UDP は別途確認してください。ウェブページの TCP 通信が正常でも、UDP に依存するアプリが使えるとは限りません。

ローカルネットワークのプリンター、ファイル共有、デバイス検出には特に注意が必要です。一部の機能はブロードキャストやマルチキャストに依存しており、プライベートアドレスを直接接続するルールを追加するだけでは復旧しません。まず通常のローカルネットワークアドレスに接続できることを確認し、仮想インターフェースやファイアウォールがデバイス検出に影響しているかを調べてください。TUN でこの端末の通信を取り込んでも、他の端末がこの端末のプロキシを使えるようになるわけではありません。プロキシを共有するには、待ち受け範囲とファイアウォールを別途設定する必要があります。詳しくはローカルネットワークからの接続を許可する方法をご覧ください。

段階ごとの検証と終了後の復元

有効化後は、コンポーネントの起動、インターフェースとルート、DNS の順に確認し、最後にブラウザー、通常はシステムプロキシを使わないアプリ、ローカルサービスをそれぞれテストします。Android でシステム VPN による通信の取り込みを行う場合は、対象または除外するアプリとバックグラウンド実行の制限も確認してください。通信の取り込みを無効にしてもネットワークの状態が戻らない場合は、システムプロキシ、DNS、残存ルートが復元されているかを確認します。スイッチを繰り返し切り替えて残った状態を隠さないでください。基本構成に戻した後、ヘルプセンターの症状別ガイドに沿って切り分けを続けましょう。

FakeDNS とドメイン名の復元

FakeDNS は対象サービスの実際のアドレスを返すのではなく、ドメイン名に管理対象のアドレスを割り当て、その対応関係を保存します。アプリがそのアドレスへ接続すると、処理コンポーネントは対応関係から元のドメイン名を復元し、ルーティングとアウトバウンドの処理を行います。アプリがネットワーク層に IP アドレスしか渡さない場合でもドメイン名を保持できますが、名前解決とその後の接続が連携する処理経路を通ることが前提です。通常の DNS の別名機能ではなく、リゾルバーアドレスを一つ入力するだけで設定が完了するものでもありません。

リクエストの一連の経路を確認する

完全な処理経路は、アプリによる名前解決、FakeDNS が対応するアドレスを返す処理、アプリからそのアドレスへの接続、入口でのドメイン名復元の四段階です。どこか一段階でも処理コンポーネントを迂回すると、アプリが到達できない管理対象アドレスへ接続する可能性があります。よくある原因は、システム DNS が取り込まれていない、アプリが独自の名前解決経路を使っている、対象アドレスが想定したインターフェースを通らない、クライアントの入口でドメイン名復元機能が有効になっていない、といったものです。まず DNS と通信の取り込みが正常に動作することを確認してから FakeDNS を導入してください。DNS がすでに不安定な状態で機能を追加しないようにしましょう。

コアや TUN コンポーネントによって、似た概念でもフィールドが異なる場合があります。Xray の FakeDNS は、内蔵 DNS や入口のスニッフィングなどの設定と連携させる必要があります。別のコンポーネントの fake-IP 機能に Xray のフィールドをそのまま使うことはできません。現在の実行コンポーネントが明確に対応し、該当する入口を提供している場合に限って設定してください。クライアントに通常の DNS 方式を選ぶ項目しかない場合は、以下の断片を用途不明の入力欄に貼り付けないでください。サブスクリプションのサーバーアドレスを変更してマッピングを再現しようとするのも避けましょう。

アドレスプールとマッピング容量

以下は Xray のアドレスプールの断片です。これだけでは FakeDNS のリクエスト経路全体は有効になりません。ipPool は管理対象のアドレス範囲を指定し、poolSize はマッピングプールの容量を指定します。例のネットワーク範囲には特別な用途があり、アプリが直接アクセスできるパブリックサービスのアドレスではありません。端末の既存ネットワークや他の通信取り込みツールの範囲と重複しないことも確認してください。容量はコンポーネントが対応する範囲内に設定します。「パフォーマンス向上」のためにむやみに増やしたり、アドレス範囲が収容できる数を超えたりしないでください。

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

マッピングプールには上限があり、容量が逼迫するとコンポーネントが古いマッピングを回収することがあります。アプリが管理対象アドレスを長期間キャッシュしている場合、その後の接続でマッピングが見つからなくなったり、変更されたりする可能性があります。マッピングの有効期間とアプリのキャッシュをあわせて考えてください。長時間の稼働後だけ発生し、再起動後に一時的に解消する問題を、すぐサーバーの不安定さと判断することはできません。アプリが古いアドレスを保持している場合や、通信取り込みコンポーネントの再起動でマッピングが消えた場合もあります。調査時には、再起動、キャッシュ、問題の再現時刻の関係を記録してください。

マッピングに向かないケースを見分ける

ローカルネットワーク上のサービス、実際の IP アドレスだけを受け付けるツール、名前解決の結果を別の端末へ渡すアプリでは、管理対象アドレスをそのまま使えない場合があります。たとえば、この端末が受け取ったマッピングアドレスをローカルネットワーク上の別の端末に送っても、その端末が同じマッピングを持たなければ接続できません。例外を設定する場合は、現在のコンポーネントが対応するドメインの除外機能または実アドレスによる名前解決を使い、例外リクエスト以降のルーティングも一貫していることを確認してください。DNS クエリだけを除外し、実際の接続を不適切なアウトバウンドへ送らないようにしましょう。

アプリが暗号化 DNS を独自に使う場合や IP アドレスに直接接続する場合、FakeDNS がまったく関与しないことがあります。この場合、ログにマッピングが表示されなくても機能の故障とは限らず、別の経路でリクエストが処理されています。アプリの名前解決動作を変更する必要がある場合は、アプリ自身が提供する設定を使ってください。すべてのクエリが透過的に取り込まれると想定すると、誤った判断につながります。スニッフィングにもプロトコル上の制限があり、ホスト情報を識別できないリクエストなど、あらゆる接続から元のドメイン名を復元できるわけではありません。

小規模なテストで効果を確認する

まず、繰り返しアクセスできる一般的なテスト先を一つ選びます。名前解決で管理対象アドレスが返ること、接続が取り込まれること、ログに元のドメイン名が記録されること、最終的に想定したアウトバウンドが選ばれることを確認してください。次に、ローカルネットワーク上の宛先と、例外設定した宛先をテストし、実際の名前解決が使われていることを確認します。現在のリクエストにすでにドメイン名が含まれていて、既存のドメインルールを使えるなら、FakeDNS を導入しても効果がない場合があります。シンプルなルーティングと DNS 設定の方が管理しやすいことも多いため、機能を有効にするためだけに複雑さを増やす必要はありません。

元に戻すときは、関連するマッピング設定を順番に無効にし、名前解決方式を復元してから、影響を受けるコンポーネントとアプリを再起動し、基本構成を再テストします。スイッチを一つ切っただけで古いアドレスプールのルートを残したり、DNS だけを変更してアプリにマッピングアドレスを保持させたりすると、問題が続くことがあります。検証用の設定と安定した設定を別々に保存しておけば、次回のメンテナンス時に FakeDNS 用の設定を把握できます。フィールドを一つ削除した結果、分かりにくい不完全な処理経路が残るのも防げます。

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

複数のサブスクリプションを管理する目的は、一覧を長くすることではなく、入手元ごとの管理範囲を明確にすることです。日常接続用と特定環境用または予備用を分けるなら、それぞれ別のグループを作り、用途を記録してください。サブスクリプションの取得成功、サーバーパラメーターの正しさ、実際の接続可否は、それぞれ別に確認する必要があります。入手元同士で、出所の分からない認証情報を使い回さないでください。提供元や用途を説明できない URL は、長期利用する自動更新の仕組みに追加すべきではありません。

入手元の一覧と更新間隔を決める

各サブスクリプションについて、入手元の名称、用途、最後に手動確認した結果、更新時にプロキシが必要かどうかを記録します。記録を公開ファイルに含める必要はなく、完全な URL を保存する必要もありません。問題が発生した際に、どの入手元へ確認すればよいか分かることが重要です。自動更新の頻度は、提供元の更新方式と利用状況に合わせて設定します。頻繁に取得するとサーバー側で制限される可能性があり、クライアントの一覧も過度に入れ替わります。利用頻度が低いグループや、互換性を検証中のグループには手動更新が適しています。

起動時の自動更新は便利に見えますが、起動直後にネットワークが安定していない場合も考慮してください。端末が Wi-Fi に接続した直後や、プロキシがまだ起動していないとき、アカウントページで認証が必要なときは、サブスクリプションの取得に失敗することがあります。まず保存済みの動作する接続を確立し、必要に応じてプロキシ経由で更新する入手元を取得してください。利用可能な唯一の接続をサブスクリプションから取得する必要があるのに、そのサブスクリプションの取得にはまだ存在しない接続が必要、という循環依存を作らないようにします。

すべての入手元を一括更新せず、グループごとに更新する

複数の入手元を管理する場合は、一つのグループを更新して追加・削除された項目とエラーを確認し、重要なサーバーをテストしてから次のグループに進みます。そうすれば、ある入手元が誤った内容を返しても、すべての比較対象を同時に失わずに済みます。重要な手動編集は事前に独立したグループへコピーしてください。サブスクリプションの内容が変更された場合は、その項目が入手元によって管理されていることを前提にします。提供元が削除したサーバーを、クライアントが永久に保持すると期待しないでください。更新方法とローカル編集の運用方法は分けて設計します。

更新後にノード数が大きく変わった場合は、実際に内容が変更されたと判断する前に、フィルター条件、プロトコルの互換性、サーバー側の案内を確認します。件数だけでは品質は分かりません。同じサーバーが複数のトランスポート設定を持つことも、同じ名前の項目が異なるアドレスを指すこともあります。必要に応じてアドレス、ポート、プロトコル、トランスポートのパラメーターを比較し、メモだけで判断しないでください。クライアントで解析できない項目は、必要なコアの機能を確認します。ソフトウェアの更新で一部の互換性の問題を解決できる場合はありますが、正しいサーバーパラメーターの代わりにはなりません。

重複項目と障害の関連性

二つの入手元に同じメモがあっても、別々の予備サーバーとは限りません。アドレス、ポート、認証、トランスポートの条件が同じなら、同じ設定が重複して配布されている可能性があります。アドレスが異なっても同じサービス基盤を共有している場合があるため、サブスクリプションの数だけで障害が分散しているとは判断できません。整理する際は入手元の情報を残し、重複項目を同時に管理する必要があるか確認してから、非表示または削除を決めます。見た目を整えるためにすべての入手元のラベルを統合すると、今後の更新やトラブル対処に必要な手がかりを失います。

障害が起きたときは、まず影響範囲を判断します。一つの項目だけが失敗する場合は、その項目のパラメーターを優先して確認します。一つのグループ全体が失敗する場合は、入手元の状態と共通設定を調べます。すべての入手元で失敗する場合は、端末のネットワーク、時刻、実行中のコア、DNS、通信の取り込み方式を確認します。この順序なら、不要な一括削除や再読み込みを減らせます。予備の入手元も、一覧に残しておくだけでなく、実際のリクエストを少数定期的にテストしてください。記録に基づいた利用可能性の結果は、「サーバーがまだたくさんある」という見た目より参考になります。

入手元の無効化と設定の復元

使わなくなった入手元は、まず自動更新を無効にします。次に、現在使用中のサーバーがそのグループに属しているか確認し、必要に応じて削除します。削除する前に、ルーティングやカスタム設定がそのグループの項目に間接的に依存していないか、唯一利用可能な接続を残していないか確認してください。端末を移行する場合、設定のコピーにサブスクリプション URL や認証情報が含まれることがあります。自分で管理する方法で移行し、新しい端末でテストを終えてから古いコピーを削除してください。クライアント設定のバックアップは、公開して共有するチュートリアル用の添付ファイルには適しません。

簡単なメンテナンス記録を残しておきましょう。今回どの入手元を更新したか、どのフィルターを変更したか、現在安定して使えるグループはどれか、異常時にどう戻すかを記録します。すべてのリクエストを細かく記録する必要はありませんが、重要な変更は分かりやすく残してください。主な問題がサブスクリプションを解析できないことであれば、グループ分けと絞り込みに戻って読み込み経路を確認します。サブスクリプションは正常なのに特定のアプリだけ失敗する場合は、ルーティング、DNS、TUN を調べてください。設定の問題を隠すために入手元を増やし続けないでください。

カスタムアウトバウンドと設定の検証

アウトバウンドは、コアから通信を送出する方法を表し、ルーティングは使用するアウトバウンドを選択します。サーバー一覧にある項目を、メモの名前でカスタムルールから直接参照できるとは限りません。ルールが参照するのは通常、実行設定で定義されたアウトバウンドタグです。カスタム設定を始める前に、追加の直接接続、明示的な遮断、特定サーバー経由のアウトバウンド、複数アウトバウンドの連鎖のどれが必要かを明確にしてください。目的によって必要なフィールドは異なります。カスタム機能は、通常のクライアント設定では表現できない要件を解決するために使います。日常設定の最初の手段にしないでください。

タグは同じ設定内で定義する

各アウトバウンドには、分かりやすく重複しない tag を指定します。ルール内の outboundTag は、そのタグと完全に一致させてください。タグは画面に表示する名前ではなく、大文字・小文字が似ていても自動的に関連付けられません。ルールをコピーした際によくある誤りは、他の設定のタグを参照したまま、対応するアウトバウンドを定義していないことです。もう一つの問題は、クライアントが設定を再生成したときにアウトバウンドの構成を変更することです。長期的に使うルールは、対応する設定画面から保存し、編集欄のテキストだけでなく、実際に生成された設定も確認してください。

以下の Xray の例では、基本的なアウトバウンドを二つだけ定義します。freedom は直接接続用、blackhole は遮断用です。プロキシサーバーへのアウトバウンド、インバウンド、完全なルーティングは含まれていないため、このままでは完全な設定として起動できません。既存の設定に統合する際はタグを確認し、重複定義を避けてください。前述のルーティング例にある proxy を使う場合は、同じ設定内に実際のサーバー情報を含む正しいプロキシアウトバウンドを定義する必要があります。空のオブジェクトでサーバーパラメーターを代用することはできません。

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

直接接続時の名前解決とサーバープロトコルの設定

直接接続のアウトバウンドは、最終的に実際の宛先アドレスへ接続します。宛先がドメイン名なら、名前解決の経路も考慮してください。Xray の freedom 設定にある domainStrategy は、直接接続の段階でドメインをどう処理するか変更できます。ただし、routing.domainStrategy とは異なる設定です。前者はアウトバウンド接続の確立に関わり、後者はルーティングルールの照合に関わります。名前が同じだからといって、両方を同時に変更しないでください。問題がルール選択前に起きているのか、接続確立時に起きているのかを判断してから、該当するレイヤーを調整します。

プロキシアウトバウンドには、サービス提供元が指定するプロトコルとパラメーターを使用してください。プロトコル名だけから他のフィールドを推測することはできません。アドレス、ポート、認証、トランスポート、安全性の設定は整合させる必要があります。REALITY を有効にする場合は、サーバー提供元から指定された関連パラメーターも必要です。各フィールドの用途はREALITY 用語の説明をご覧ください。コアによって対応範囲は異なります。コアの系統についてはXray の解説を確認してください。構文チェックを通すために、必須パラメーターを空欄のままにしないでください。

アウトバウンドを連鎖させても自動でフェイルオーバーするわけではない

あるアウトバウンドが別のアウトバウンド経由で接続を確立する場合は、下位の接続先に到達できるか、どこで名前解決するか、UDP に対応するかをあわせて考える必要があります。Xray では proxySettings を使ったアウトバウンド間の接続が関係する場合がありますが、他のコンポーネントでは異なるフィールドを使います。現在のコアの構造に合わせて参照を設定し、そのまま流用しないでください。依存関係がループしないようにする必要もあります。たとえば甲が乙に依存し、乙も甲に依存する構成は避けてください。接続を一段追加すると、障害の依存箇所も増えます。自動的に可用性が上がるわけではなく、タグの順序だけで自動切り替えが行われるわけでもありません。

自動選択やフェイルオーバーには、それに対応する検出・選択機能が別途必要です。何を失敗と判定するか、いつ切り替えるか、既存の接続をどう扱うかも明確にしてください。こうした機能を定義せずにアウトバウンドを複数設定しただけでは、コアが自動的に順番に試すことはありません。設定内容を確認する場合は、まず各アウトバウンドを個別にテストし、明確な目的に対して固定ルールを設定する方が確実です。連鎖接続では、下位のアウトバウンド、上位のサーバー接続、最後に対象リクエストの順に検証します。三段階のエラーを「ノードのタイムアウト」の一言でまとめないようにしてください。

実行前に構造を確認し、比較テストを行う

設定は三段階で検証します。まず、JSON に余分なカンマ、閉じていない引用符、重複フィールドがないか確認します。次に、現在のコアが各フィールドに対応しているか、タグ参照がすべて定義されているかを確認します。最後にコンポーネントを起動して、実際のリクエストを観察します。構文が正しくてもフィールドが有効とは限らず、コアが起動してもルールが意図どおり選ばれるとは限りません。他のコンポーネントからコピーした同名フィールドや、断片を誤った階層に配置していないかにも注意してください。設定に問題がある場合は、保存済みの元設定へ戻してから必要な内容を段階的に追加します。

動作検証では、少なくとも対象ルール、既定の経路、DNS、ローカルサービスをテストします。ログで新しい設定が読み込まれたか、想定したアウトバウンドが選択されたか、失敗が名前解決、ハンドシェイク、データ転送のどの段階で起きたかを確認してください。テスト後は、一時的に詳細化したログを日常利用に適したレベルへ戻し、不要になった検証用ルールを削除します。安定した設定では、各アウトバウンドの用途と例外ルールの理由を説明できるようにしてください。説明できない設定が大量に残ると、最初の問題よりもメンテナンスのリスクが高くなることがあります。

カスタム設定によって基本接続に影響が出た場合は、まず使い方ガイドに沿って初回接続の手順に戻し、現象に応じて該当する章を確認してください。クライアントを入れ替える必要がある場合はダウンロードページを利用し、設定の問題をインストーラーの不具合とすぐに決めつけないでください。詳細設定の基準はフィールドの数ではありません。リクエスト経路が明確で、問題を再現でき、変更を元に戻せること、そして日常的に必要なアプリで実際に動作確認できていることです。