設定応用ガイド

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

サブスクリプションのグループは管理上の区分であり、通信の出口ではありません。グループには購読URLや更新設定、絞り込み条件などが保存され、サーバーの各レコードにはプロトコル、アドレス、ポートが含まれます。レコードを別のグループに移しても、接続経路が自動で変わるわけではありません。また、グループのタブをクリックすると通常は一覧の表示範囲が変わるだけで、使用中のサーバーが切り替わるわけではありません。変更前に「どのグループを表示しているか」と「どのサーバーを使用中か」を区別し、更新後の接続状態を誤認しないようにしましょう。

後から確認しやすいグループを作る

v2rayNの「サブスクリプショングループ」関連の管理画面からグループを追加し、提供元と用途が分かるメモを入力してから、購読URLをすべて貼り付けます。画面によっては、メニューやツールバーに項目があります。購読URLには個人の利用権限に関する情報が含まれることが多いため、公開スクリーンショットや質問掲示板、共有ドキュメントに貼り付けないでください。初回はグループを1つだけ追加し、更新後にプロトコルとアドレスが正しく表示されることを確認してから、別の提供元を追加します。問題が起きたとき、原因を特定しやすくなります。

更新方法は現在の接続状態に合わせて選びます。「プロキシを使用せずに更新」は、現在のネットワークから購読URLに直接アクセスできる場合に適しています。「プロキシ経由で更新」は、利用可能なプロキシ接続がすでにあることが前提です。使えるサーバーをまだ追加していない状態で更新リクエストをプロキシ経由にすると、起動時に依存関係が発生することがあります。その場合は、まず購読URLに直接アクセスできるか確認するか、提供元の単体共有リンクで初回接続を行ってから、プロキシ経由で更新してください。更新に失敗しても、すべてのサーバーが使えないとは限りません。

一覧の絞り込みとデータの変更は別

サーバーの絞り込みには、大きく分けて2種類あります。一覧の検索は一致しない行を隠すだけですが、サブスクリプションのインポート時に使うフィルターは、ローカルデータベースに取り込むレコードを決める場合があります。適用されるタイミングが異なるため、まず一覧の検索で対象レコードにキーワードが一致するか確認してから、グループ設定のインポートフィルターを使いましょう。画面に正規表現の対応が明記されている場合は、サーバー名で絞り込めます。通常のテキスト検索しか使えない場合、正規表現を入力しても一般的な検索としては機能しません。対象フィールドと照合範囲は、使用中の画面の説明を確認してください。

研究|オフィス
^(研究|オフィス)-

上の2行は、それぞれ「いずれかのキーワードを含む」「指定した接頭辞で始まる」正規表現の例です。両方を同時に設定するものではありません。前者は広く一致し、後者はサーバー名に決まった命名規則がある場合に使います。少数のレコードで先に試し、大文字と小文字を区別するか、文字列全体に一致するかを確認してから、サブスクリプション全体に適用してください。一覧が空になった場合は、まずフィルターを解除して再更新します。絞り込み条件が原因なら、購読URLを何度変更しても解決しません。

更新後の確認手順

サブスクリプションの更新時にサーバーレコードが作り直され、手動で変更したサーバー名、通信パラメーター、メモが引き継がれないことがあります。長期的に管理するカスタムレコードは手動用のグループに分け、変更理由を記録しましょう。自動更新されるグループのサーバーパラメーターを直接修正して使い続けると、次回の更新で変更内容が上書きされるおそれがあります。提供元の設定に問題がある場合は、不明なパラメーターを手当たり次第に試すのではなく、まず提供元に確認してください。

v2rayNGでは「サブスクリプショングループ設定」から提供元を管理し、サブスクリプションを更新できます。メニュー名はインストールされているバージョンの画面に従ってください。Androidではクリップボードの権限やネットワーク環境がデスクトップと異なるため、デスクトップで更新できたURLに、スマートフォンの現在のネットワークからもアクセスできるとは限りません。V2Flyコアを使う代替クライアントの v2flyNG では、サブスクリプション内のプロトコルと拡張項目が対応しているかも確認してください。一覧にレコードが表示されたことだけで、接続パラメーターがすべて互換だとは判断できません。

更新後は、グループ内に想定したレコードがあるかを確認し、使用中のサーバーを選び直す必要があるかを確認してから、実際に接続します。接続テストはサーバーへの接続を実際に確立するもので、ホストの応答を確認するだけのテストとは異なります。一括テストでは通信量が発生する場合もあります。レコードが多い場合は、対象を絞って確認し、結果に問題があればログを調べましょう。遅延と倍率の考え方はサーバーの選び方もご覧ください。一覧の並び順だけで、すべての通信の出口を決めないようにしましょう。

ルーティング設定の実例

ルーティング設定は「コアに入った接続をどのアウトバウンドに渡すか」を決めます。すべてのアプリをコアに通す設定ではありません。システムプロキシの対象外のアプリは、ルーティングルールを追加しただけでは通常、通信が自動で取り込まれません。まずシステムプロキシに従うブラウザーでルールを検証し、その後にTUNを検討してください。v2rayNの「ルーティング」から、既定の設定を選ぶかルールを編集できます。「中国本土を迂回」などの名称は具体的なルールセットを指します。名前から処理内容を推測せず、使用前にルールを確認しましょう。

マッチ順とアウトバウンドの指定を確認

XrayとV2Flyの一般的なルーティングルールは、上から順に照合され、最初に一致したルールで接続先が決まります。広い条件のルールを先に置くと、後続の詳細なルールに一致しなくなることがあります。1つのルールオブジェクトにドメイン、ポート、ネットワーク種別を指定した場合、通常はすべての条件を満たす必要があります。一方、同じドメイン配列の複数項目は、いずれかに一致する候補を表します。まず明確なドメインルールを1つ設定して検証し、その後でポートやアドレスの条件を加えましょう。「AND」と「OR」の関係を混同しないようにしてください。

以下はXray / V2Flyのルーティング項目の構造例です。プライベートアドレスへの直接接続、予約用のサンプルドメインへの直接接続、その他の通信をプロキシに渡す順序を示しています。既存の設定に、directとproxyという名前のアウトバウンドが定義されていることが前提です。クライアントが生成するタグは異なる場合があるため、実際の設定に合わせてください。例の予約用ドメインは説明用であり、実際に振り分ける業務ドメインの代わりにはなりません。

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

ドメインとアドレスのマッチングを分けて検証

full:はドメインの完全一致、domain:はそのドメインとサブドメイン、regexp:は正規表現での照合に使います。接頭辞のない文字列は部分一致として解釈され、想定より広く一致することがあります。特定のサイトだけを対象にする場合は、意味が分かりやすい完全一致またはサフィックス一致を優先してください。業務サイトではログイン、静的ファイル、APIに別々のドメインを使う場合があります。トップページが開いただけでは、業務全体の通信が同じ経路を通ったとは限らないため、ログで関連リクエストを確認しましょう。

AsIsは、すでにある宛先情報をそのまま使って照合する方式です。IPIfNonMatchは、ドメインルールに一致しない場合にアドレスでの照合を続けるため、名前解決を試みます。IPOnDemandは、ルールの照合にアドレス情報が必要になった時点で名前解決する場合があります。これらの設定はルーティング時の名前解決のタイミングを変えるもので、ブラウザーのDNSを一律に指定する機能ではありません。地理情報によるアドレス分類を使う場合は、ドメインの名前解決方法、地理データの利用可否、接続にドメイン情報が含まれているかも確認してください。

既定のルールとカスタムルールの使い分け

地理情報によるドメイン分類には対応するデータファイルが必要です。分類結果はリアルタイムのネットワーク測定ではありません。データがないと起動エラーになり、古いデータでは想定と異なる分類になることがあります。まず、クライアントが現在どのルールデータを使っているかを確認し、クライアントの更新機能から更新してください。別のルールエンジンの構文をそのまま貼り付けないでください。ドメイン名や地域名が同じでも、項目、照合方式、データ形式が異なる場合があります。

ルーティングを変更したら、テスト対象のアプリで既存の接続を閉じてから再試行してください。ブラウザーの接続再利用、アプリの接続プール、キャッシュによって、新しいルールが反映されていないように見えることがあります。検証時はルールを1つだけ変更し、該当するログを開いて、新しいリクエストの宛先とアウトバウンドタグを確認してから、他の通信に進みましょう。取り込まれたすべての通信をプロキシに通すには、ルーティングの既定動作を調整します。プロキシを経由していないアプリも取り込む場合は、後述のTUNの章を確認してください。どちらも異なる設定項目であり、「グローバル」という一言でまとめてトラブルを切り分けることはできません。

ルールには、LANへのアクセスも考慮しておきましょう。プリンター、家庭用ストレージ、社内サイトはプライベートアドレスや内部ドメインを使う場合があります。プライベートアドレスだけを許可しても、内部ドメインの名前解決の問題は解決しないことがあります。ドメインだけを許可しても、アプリがアドレスを直接指定してアクセスする場合には不十分です。実際のアクセス方法を確認し、DNSとルーティングをあわせて設定してください。よくある接続方式の違いは、入門ガイドの接続確認を参考に、あらためて基準を確認しましょう。

DNS設定の見直し

DNSの問題は「プロキシには接続できているのに、Webページが開かない」という形で現れることがあります。ただし、すべてのドメインが同じ場所で名前解決されるとは限りません。OS、ブラウザー、アプリ内蔵のリゾルバー、プロキシコアが、それぞれ別のキャッシュや名前解決経路を使うことがあります。設定を変更する前に、リクエストの流れを整理しましょう。アプリがドメイン名をローカルプロキシに渡すのか、先にアドレスへ変換してから接続するのか。また、コアがドメインでルーティングするのか、アドレスに変換してから照合するのか。ドメイン名がどの段階でアドレスに変わるかが分かれば、変更すべき設定箇所を判断できます。

3種類の名前解決を区別する

1つ目は、プロキシサーバー自体のドメイン名の名前解決です。プロキシ接続を確立する前に必要なため、その時点で利用できる経路が必要です。2つ目は、接続先となる業務ドメインの名前解決で、ローカルで行う場合もあれば、リモート側で処理する場合もあります。3つ目は、アドレスによるルーティングルールの照合を補助する名前解決です。この3つをすべて、プロキシ経由でしかアクセスできないDNSサービスに向けると、起動時に依存関係が循環することがあります。プロキシがまだ接続されていないのに、サーバーのアドレスを解決するためにプロキシが必要になるためです。

v2rayNの「DNS設定」を変更する前に、使用中のコアと設定方式を確認してください。Xray設定の生成に使う項目もあれば、TUNで使うネットワークコンポーネントに適用される項目もあります。画面上で名前が似ていても、同じ設定項目に書き込まれるとは限りません。v2rayNGの「ローカルDNSを有効にする」はローカルでの名前解決処理に関係するため、リモートDNSや直接接続用DNSなど、実際の項目とあわせて確認してください。適用範囲が分からないまま、複数のDNS取り込み機能を同時に有効にしないでください。

{
  "dns": {
    "servers": [
      {
        "address": "localhost",
        "domains": ["domain:example.com"],
        "skipFallback": true
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

このXray / V2Fly形式のDNS設定例では、ドメインに応じたDNSサーバーの選択と、それ以外の問い合わせに使う一般的なDNSアドレスを示しています。そのDNSアドレスにアクセスできるかどうかは、実際のネットワーク環境によります。localhostはシステムのリゾルバーを使う指定であり、ローカルで独立したDNSサービスを必ず動かすという意味ではありません。skipFallbackは、指定外のドメインのフォールバック問い合わせにそのサーバーを使わないための設定です。名前解決の失敗後に再試行するすべての動作を禁止するものではありません。この設定例はコアのDNSに適用され、すべてのアプリを直接制御するものではありません。

暗号化DNSでもルーティングの確認が必要

暗号化DNSを使う場合は、DNSサービスのドメインを最初に名前解決する方法、接続ポート、リクエストのアウトバウンドをあわせて確認します。暗号化通信を選んでも、ネットワークに接続できない問題が自動で直るわけではなく、業務通信のルーティングルールを置き換えるものでもありません。DNSサービスへの接続にプロキシが必要な場合は、そのプロキシ自体が、まだ確立していない接続経路に依存していないか確認してください。すでに使える設定がある場合は、まず業務用DNSサーバーだけを置き換えて検証し、その後でシステムDNSの取り込みを検討しましょう。一度に複数の依存関係を増やさずに済みます。

IPv4とIPv6もセットで確認しましょう。IPv6アドレスが返ってきても、現在のネットワークや選択中のアウトバウンドにIPv6の通信経路があるとは限りません。IPv4だけを要求して一時的に問題を避けても、IPv6が直ったことにはなりません。一部のサイトでタイムアウトが起きる場合は、返されたアドレスの種類、実際に接続したアドレス、ルーティングの出口をそれぞれ確認してください。UseIP、UseIPv4、UseIPv6の対応範囲や適用先は、使用中のコアの説明に従ってください。異なるコンポーネントの設定をそのまま流用しないでください。

キャッシュの段階を追って変更を確認

DNSを変更したら、まずクライアントに関連するネットワークコンポーネントを再起動し、テスト対象アプリの古い接続を閉じます。必要に応じてOSやブラウザーのキャッシュも削除してください。ブラウザーで独自のセキュアDNSを有効にしている場合、テスト通信がシステムのリゾルバーを迂回することがあります。テスト結果を記録するときは、その設定状態も記載してください。コマンドラインの問い合わせ結果が示すのは、そのコマンドが使用した名前解決経路だけです。ブラウザー、チャットアプリ、プロキシコアも同じ結果を得たとは限りません。

社内ドメインでは、特に既存の名前解決経路を維持する必要があります。パブリックDNSでは通常、内部ホスト名を解決できません。DNSを一律に置き換えると、外部サイトは直っても社内システムが使えなくなることがあります。内部ドメインにはシステムまたは社内DNSを使い、対応するアドレスには直接接続のルールを設定してください。社内ドメインのDNSがネットワークから動的に配布されている場合、ある時点で確認したサーバーアドレスを固定しないでください。社内ネットワークを切り替えたら再確認し、特定の環境向け設定を別の場所に持ち込まないようにしましょう。

トラブル対処の手順を決めておきましょう。まずプロキシサーバーのドメイン名を解決できるか確認し、次に業務ドメインが想定した種類のアドレスを返すか確認します。その後、リクエストがどのアウトバウンドを通るかを確認し、最後に接続エラーを調べます。DNSが想定どおりに動作していない場合に限って設定を変更してください。証明書名の不一致、ハンドシェイクの失敗、アカウント認証エラーが発生している場合は、該当する接続パラメーターを確認します。DNSサーバーを何度も変更しても、通常これらの問題は解決しません。仮想アドレスへのマッピングを使う場合は、FakeDNSの章を参照してください。

TUNモード

TUNモードは仮想ネットワークアダプターでIPパケットを受け取り、システムプロキシの設定に従わないアプリの通信を取り込むときによく使われます。「システムプロキシを自動設定」とは別の機能であり、すべての通信がプロキシサーバーに送られるわけでもありません。接続が取り込まれるかどうかは、ネットワークアダプターとルーティングによって決まり、取り込まれた後に直接接続するかプロキシに通すかはルールで決まります。そのためTUNのトラブル対処では、パケットが取り込み経路に入ったか、入った後にどのアウトバウンドが選ばれたかを分けて確認します。

有効にする前にシステムプロキシの基準を確認

まずTUNを無効にした状態で、システムプロキシ経由のWebアクセスと実際の接続を確認し、サーバーパラメーターが使えることを確かめます。使用中のサーバー、ルーティング設定、DNS設定を記録してからTUNを有効にしてください。システムプロキシの段階で接続できない場合、TUNを追加して要因を増やすのは避けましょう。v2rayNのTUN実装はOSや配布パッケージによって異なり、関連コンポーネントがメインのプロキシコアとは限りません。Xrayのルーティング設定例を別のコンポーネント用の設定として、変換せずに使うことはできません。

仮想ネットワークアダプターやシステムルートの操作には、適切な権限が必要です。Windowsでは管理者権限、macOSではネットワーク関連の許可、Linuxではデバイスアクセスやルーティング管理の権限が必要になる場合があります。有効化に失敗したら、まずログでネットワークアダプターが作成されたか、ルートの追加に成功したかを確認し、権限の問題かネットワーク設定の問題かを切り分けます。すべてのクライアントを常に最高権限で実行することを、既定の対処方法にしないでください。使用中のパッケージで案内されている権限の付与方法と具体的なエラーを確認しましょう。

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

システムの通信を取り込んだ後も、プロキシプログラム自身がサーバーに接続できるよう、接続を取り込み経路から正しく外す必要があります。そうしないと、通信が再び自分自身に送り返される場合があります。一般的なクライアントは、インターフェースのバインド、ルートの除外、プロセスの保護などで対処しますが、複数のネットワークアダプター、他のVPN、手動ルート、ファイアウォールの設定が条件を崩すことがあります。有効にした直後にネットワークが切れた場合は、他のネットワーク取り込みツールを一時停止し、クライアントを1つだけにして、有効化前後のルートとログを比較しましょう。

システムプロキシとTUNを同時に有効にしても、必ず問題が起きるわけではありませんが、通信経路が分かりにくくなります。一部のアプリはローカルプロキシポートに接続し、他のアプリは仮想ネットワークアダプターに直接入る場合があります。トラブル対処では、まず取り込み方式を1つに絞って安定性を確認し、その後、同時利用が必要か判断してください。Androidのv2rayNGとv2flyNGは通常、システムのVPNインターフェースで通信を取り込みます。同じユーザー環境にある別のVPNアプリが許可を取り合うこともあります。接続ボタンが起動状態でも、実際のネットワーク通信を確認する必要があります。

アプリの対象範囲、LAN、UDP

v2rayNGの「アプリごとのプロキシ」は、VPN経由で処理するアプリと対象外にするアプリを指定します。選択項目の意味は、使用中のモードの説明を確認してください。アプリを選択しても、常に「選択したアプリだけをプロキシ経由にする」という意味ではありません。対象アプリを含めるモードと除外するモードでは動作が逆になります。まずテスト用のアプリを1つ選び、完全に終了してから起動し直して、クライアントのログに通信が表示されるか確認してから対象を増やしましょう。システムコンポーネント、ダウンロードマネージャー、埋め込みブラウザーは別のプロセスから通信する場合があるため、実際の用途に沿って検証してください。

LAN内のデバイス検索、印刷、画面投影ではブロードキャストやマルチキャストを使うことがあり、プライベートアドレスへの直接接続ルールだけでは復旧しない場合があります。該当する通信をTUNに通す必要があるかを確認し、クライアントにLANの迂回設定があれば確認してください。リアルタイム通信やゲームではUDPを使うことがあります。Webページが開いても、UDP経路が正常だとは限りません。端末側の取り込み機能、アウトバウンドのプロトコル、サーバー側の対応をあわせて確認しましょう。プロトコルがUDPに対応していても、すべてのネットワーク環境で通信できるとは限りません。

MTUは、1つのパケットで送信できるデータ量に影響します。特定の大きなリクエストで停止する、接続は確立するのに通信が不安定になるなど、原因を示す手がかりがある場合に限って変更を検討し、元の値を記録して少しずつ検証しましょう。根拠なくMTUを小さくしすぎると、効率が下がったり、別の問題を見えにくくしたりすることがあります。まずDNS、アウトバウンドへの接続、二重取り込みの問題を除外してから調整してください。どのOSやネットワークでも使える固定値はありません。

終了時は、クライアントからTUNを無効にしてからプログラムを終了し、通常のネットワーク接続が復旧したことを確認してください。異常終了で通信できなくなった場合は、クライアントを再度開いて正常に終了し、システムプロキシと仮想ネットワークアダプターの状態を確認します。必要なら現在のネットワークに再接続してください。用途が分からないシステムアダプターを削除したり、すべてのファイアウォールルールを消去したりしないでください。macOSの許可に関する問題はインストールの許可とネットワーク権限を参照してください。起動時の問題は、まずクライアント自体を確認しましょう。

FakeDNS

FakeDNSが返すのはローカルでのマッピングに使う仮想アドレスであり、接続先サーバーの実際のパブリックアドレスではありません。アプリは仮想アドレスを受け取って接続し、通信を取り込むコンポーネントがマッピングから元のドメイン名を特定して、ドメインに応じたルーティングやプロキシ処理を行います。ドメイン情報を維持するのに役立つ仕組みですが、DNS問い合わせとその後の接続が、マッピング情報を共有できる経路を通ることが条件です。「FakeDNS」という項目を有効にしただけでは、必要な経路が自動で整うわけではありません。

仮想アドレスへのマッピングが本当に必要か確認

アプリがすでにローカルプロキシへドメイン名を渡している場合、通常はコアがそのままドメインに基づいて照合できるため、設定を「最適化」する目的でFakeDNSを追加する必要はありません。FakeDNSは、IPレベルで通信を取り込みながらドメイン情報を復元したい場合に適しています。有効にするかどうかは、通信の取り込み方式とクライアントの対応状況で判断しましょう。項目があるからといって、すべてを有効にする必要はありません。コンポーネントによってFakeDNSとfake-ipの設定名が似ていても、設定項目、アドレスプール、キャッシュの仕組みが同じとは限りません。

以下は、Xray / V2Fly形式の設定におけるアドレスプール、DNS、インバウンドのスニッフィングの関係を示しています。v2rayNのすべてのTUN実装で使える共通設定ではなく、完全なインバウンドやアウトバウンドも含みません。使用中のコアがこれらの設定項目に対応し、DNS問い合わせを実際にそのコアが処理していると確認できた場合に限り、該当する部分をカスタム設定に追加してください。クライアントの画面から設定できる場合は、まずクライアントに設定を生成させましょう。別の設定を手書きで重ねて、競合させないようにしてください。

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

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

2つ目の設定ブロックは、マッピングの復元が必要なインバウンドオブジェクト内に記述します。完全な設定の任意の位置に置くことはできません。アドレスプールは通信を取り込むルートと一致させ、実際に使っているネットワークと重複しないようにしてください。例では専用のテスト用アドレス範囲を使っています。アプリから直接アクセスできるパブリックサービスのアドレスではありません。poolSizeはマッピング可能な数を表し、サーバー数や性能を保証する値ではありません。クライアントがマッピング用プールを管理している場合は、明確な問題が確認できるまで既定値を使ってください。

マッピング、キャッシュ、通信スニッフィングの関係

一般的な通信スニッフィングは接続開始時のデータからドメイン名を識別しようとします。一方、FakeDNSによる復元では、事前に作成されたアドレスのマッピングが必要です。単純に置き換えられる機能ではありません。プロトコルや暗号化ハンドシェイクによっては識別可能なドメイン名が公開されず、スニッフィングできないことがあります。マッピングが失われた場合も、仮想アドレスだけでは元のドメイン名を特定できません。v2rayNGの「トラフィックスニッフィングを有効にする」は、使用中のコアの設定とあわせて理解してください。あらゆる接続先を復元できる万能機能ではありません。

特に起きやすいのは、クライアントの再起動後にマッピングが消えたのに、アプリが古い仮想アドレスをキャッシュしているケースです。アプリは古いアドレスに接続し続けますが、現在のコアには対応するマッピングがありません。その結果、一部のアプリだけが失敗し、再起動すると直ることがあります。古い接続を閉じ、関連するDNSキャッシュを消去するかテストアプリを再起動してから、ドメイン名をもう一度検索してください。アプリの接続を維持したままプロキシだけを再起動すると、不整合が長引いて、検証結果に食い違いが出ることがあります。

特定の通信では通常の名前解決を維持

アプリによっては、名前解決したアドレスを比較したり、後続のプロトコルフィールドに書き込んだり、独自のリゾルバーでシステムDNSを迂回したりします。LAN内のデバイス検索や、アドレスの意味に依存するアプリも、仮想アドレスに対応できない場合があります。互換性の問題が起きたら、まず該当ドメインまたはアプリを実際の名前解決経路に戻して、機能を確認してください。スニッフィングの設定を追加し続けるのは避けましょう。LAN内のドメインは通常、仮想アドレスを一律に返すのではなく、社内DNSと組み合わせて処理します。

テストツールで接続先が仮想アドレスプール内にあると表示されても、それだけで業務サーバーがどの地域にあるかは判断できません。また、そのアドレスを使って遅延を比較したり、サーバーアドレスとして固定したりしないでください。実際の接続先を確認するには、アウトバウンドとリモート接続先のログを見ます。反対に、ブラウザーに通常のパブリックアドレスが表示されても、FakeDNSがまったく機能していないとは限りません。ブラウザーが独自DNSを使用しているか、有効期限の切れていないキャッシュを使っている可能性があります。検証は新しい名前解決から始めてください。

FakeDNSを無効にする場合も、キャッシュとルーティングを正しい順序で切り替えます。まず通常の名前解決設定に戻してクライアントを再読み込みし、アプリが保持する仮想アドレスを消去します。新しい名前解決でアドレスプール内のアドレスが返らないことを確認し、最後に通信の取り込みルールが想定どおりに戻ったかを確認してください。変更後に一部のアプリだけが失敗するなら、まずキャッシュを調べます。すべての通信がすぐに失敗する場合は、サーバーレコードを変更するのではなく、設定の生成、DNSへの接続、通信の取り込み経路を確認しましょう。

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

複数のサブスクリプションを管理する目的は、提供元ごとの情報を保ち、重複した変更を減らし、更新に失敗したときに確実に元へ戻せるようにすることです。購読数が増えても、自動でフェイルオーバーが有効になったり、業務に最適なサーバーが自動選択されたりするわけではありません。「提供元の管理」「使用するサーバーの選択」「業務通信のルーティング」を別々に設計してください。提供元はサーバーレコードを提供し、使用中のサーバーは既定のプロキシ出口を決め、ルーティングはその出口に渡す通信を決めます。これらを混同すると、更新時に変更履歴を追いにくくなります。

一時的な用途ではなく、管理方法でグループ分け

自動更新する提供元と、手動で管理するレコードは分けておくのがおすすめです。自動更新グループには提供元が返すパラメーターだけを保存し、手動グループには明確に検証したローカル変更を保存します。メモには用途と変更理由を記録してください。提供元の名前は固定し、現在使用中のサーバーに合わせて変更する必要はありません。業務用途はメモやフィルターで区別しましょう。「仕事用」「動画用」などの用途ごとに同じサブスクリプションを何度も取り込むと、同じレコードかどうか分かりにくくなります。

重複レコードかどうかをサーバー名だけで判断しないでください。名前が似ている2つのサーバーでも、トランスポート層、ポート、認証情報、サービス名が異なることがあります。名前が異なっていても、接続パラメーターが同じレコードもあります。重複を削除する前に、クライアントがどの項目で重複を判定するか確認し、バックアップを取ってください。判定方法が分からない場合は、提供元ごとのグループを残し、表示フィルターで一覧を整理する方が安全です。追跡できない一括削除は避けましょう。

更新スケジュールと失敗時の復元

自動更新は、パラメーターが安定していて提供元から確実に応答があるサブスクリプションに適しています。ただし、実際の必要以上に更新頻度を上げないでください。頻繁な更新は提供元のレート制限にかかったり、一時的なエラーを再現しにくくしたりすることがあります。定期更新を設定したら、通常の更新を一度確認し、失敗時に既存レコードが保持されるか、成功時に使用中のサーバーがどう扱われるかを確認しましょう。クライアントや更新操作によって動作が異なるため、「更新失敗ならローカルデータは変わらない」と決めつけないでください。

一括更新の前に、少なくとも1つ、検証済みで復元に使える接続経路があることを確認してください。更新にプロキシが必要な場合は、現在使えるレコードを残すことが特に重要です。更新後に提供元から空のデータが返ってきたら、レスポンスのエラーとフィルター条件を先に確認します。すべてのグループをすぐに削除しないでください。復元するときは、ローカルのバックアップを戻すか、確認済みの提供元設定を再インポートします。古い認証付きURLを公開して、他の人にテストを依頼しないでください。利用権限の情報が失効した場合は、提供元に再発行を依頼してください。

デバイス間の移行と形式の選択

デスクトップとAndroid間で移行する場合は、クライアントのデータフォルダー全体をコピーするのではなく、購読URLまたはクライアントが対応する単体共有リンクを使ってください。データベース、画面の状態、ファイルパス、実行コンポーネントはOSによって異なります。フォルダーをコピーすると、使えないパスや古い権限情報が引き継がれる場合があります。移行後はプロトコル、トランスポートパラメーター、安全設定を確認してから、実際に接続できるか検証してください。v2rayNで使える拡張項目が、v2flyNGのコアでも使えるとは限りません。

Base64形式のサブスクリプションには通常、複数の共有レコードが含まれます。完全なJSONにはインバウンド、アウトバウンド、ルーティング、DNSが含まれる場合があります。完全なJSONを通常のサブスクリプションとして読み込んでも、クライアントがサーバー一覧を抽出できるとは限りません。共有リンクを完全な設定として読み込んでも、元のルーティング設定が自動で反映されるわけではありません。インポートでエラーが出たら、まずデータの形式とクライアントの読み込み方法を確認してください。具体的な形式はサブスクリプション形式と共有リンクの解説をご覧ください。拡張子の変更だけで変換しようとしないでください。

エクスポートする範囲にも注意しましょう。選択したサーバーだけを出力する操作、現在のグループを出力する操作、すべてのグループと設定を含む完全バックアップがあります。自分の別デバイスに渡す前に、移行する必要のない提供元情報がファイルに含まれていないか確認してください。古いデバイスを整理するときは、エクスポートファイル、クリップボードの履歴、クラウド上のコピーも確認します。クライアントの画面からレコードを削除しただけで、引き続きアクセスに使える購読URLが残らないようにしてください。

試行錯誤を繰り返す代わりに変更履歴を記録

大きな変更を行うたびに、変更前のルーティング設定、使用中のコア、通信の取り込み方法、変更理由を記録してください。認証情報を保存する必要はありません。「どの変更から異常が始まったか」が分かれば十分です。複数の提供元で同時に問題が起きる場合は、現在のネットワーク、DNS、システム時刻、クライアントの権限、更新時のプロキシ経路など、共通する要因を先に確認します。1つの提供元だけで失敗する場合は、URLの有効性、レスポンス形式、利用権限を調べてください。この順序なら、3つのクライアントを順番に再インストールするよりも、問題解決の手がかりを残しやすくなります。

バックアップからの復元も、実際に試しておきましょう。バックアップを再インポートできること、手動で追加したレコードを識別できること、ルーティングとDNSの設定に漏れがないことを確認してから、自動更新に任せて運用してください。復元の検証は時間に余裕のあるときに行い、業務で接続中の設定を一度に切り替えないようにしましょう。デスクトップクライアントが起動しない場合は、まず起動時にクラッシュする場合の対処方法で実行環境を確認してください。設定の破損と提供元の失効は別の問題なので、それぞれ個別に対処しましょう。

カスタムアウトバウンド

アウトバウンドは、コアが接続先との通信を実際に確立するためのオブジェクトです。ルーティングルールはタグを使って接続をアウトバウンドに渡します。v2rayNを通常の用途で使う場合、クライアントが選択中のサーバーに合わせてプロキシ用アウトバウンドを生成し、直接接続用やブロック用のアウトバウンドと組み合わせます。複数の出口、特殊な接続経路、完全なカスタム設定が必要な場合に限り、アウトバウンドの構造を直接管理してください。手書きの設定に進む前に、画面上のサーバー選択とルーティングルールで目的を実現できないか確認しましょう。クライアントによる生成設定と手動の変更が互いに上書きされるリスクを減らせます。

検証できる最小構成から始める

以下は、ローカルのSOCKSインバウンド、直接接続用アウトバウンド、ブロック用アウトバウンドのみを含む、Xray / V2Fly形式の学習用設定です。リモートプロキシサーバーには接続しません。ローカルのループバックアドレスだけで待ち受けるため、プロキシを誤ってLANに公開することもありません。この例では、インバウンド、ルーティング、アウトバウンドタグの参照関係を確認できます。購読で提供されるリモートサーバーに接続する場合は、確認済みのサーバーパラメーターを使い、認証項目を推測で設定しないでください。

{
  "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:blocked.example.com"],
        "outboundTag": "block"
      }
    ]
  }
}

この例では、どのルールにも一致しない接続は先頭のアウトバウンド、つまり直接接続に渡されます。予約用のサンプルドメインはブロックルールの説明に使っています。テスト前に、待ち受けポートが使用中のクライアントと重複していないか確認してください。同じポートで2つ目のインスタンスを起動しないでください。クライアントに完全なカスタム設定を読み込ませたとき、画面上の使用中サーバー、DNS、ルーティングのスイッチが引き続き反映されるかは、読み込み方法によって異なります。実際に生成された設定やログで確認し、画面の設定がすべて自動で追加されると決めつけないでください。

タグの命名と既定動作

tagはローカルで参照するための名前であり、プロトコル名でも、サーバーが自動で認識するパラメーターでもありません。ルーティングのoutboundTagには、定義済みのアウトバウンドを正確に指定する必要があります。名前が一致しないと、起動や実行時に問題が起こります。意味が分かりやすく、重複しない短い名前を使い、既定のアウトバウンドを置く順序も記録しておきましょう。サーバーの表示名がアウトバウンドタグに自動変換されるとは限りません。クライアント一覧の表示名と、コア設定の項目は別の層にあります。

変更前に、正常に動作する完全な設定を保存してから、構文と起動を検証します。JSONでは通常のコメントや末尾の余分なカンマは使えません。編集画面で受け付けられても、コアがその項目に対応しているとは限りません。ログに未対応のプロトコルや項目が表示されたら、まず実際に起動しているコアがXrayかV2Flyか、設定項目がどの階層にあるかを確認しましょう。同じJSON形式でも、別のネットワークコンポーネントの設定をそのまま読み込むことはできません。後続のエラーに惑わされないよう、最初に発生した有効なエラーから調べてください。

チェーン接続と複数出口の注意点

チェーン接続では、各段の役割を明確にする必要があります。前段は次の段に到達するために使い、次の段が最終的な接続先にアクセスします。他のアウトバウンドを参照する方法、使用できるトランスポート、対応項目はコアの実装によって異なります。2つのサーバーオブジェクトを並べればチェーンになる、と考えて設定しないでください。各段を個別に検証してから、組み合わせた状態でDNS、UDP、接続再利用をテストします。経路を組み合わせるほど依存関係が増え、どこか1段が失敗するだけで最終接続にも影響します。

アウトバウンドが複数定義されていても、自動測定、負荷分散、フェイルオーバーが有効とは限りません。選択機能や分散方式が必要な場合は、候補、選択ロジック、ヘルスチェックを別途設定し、使用中のコアが対応していることを確認してください。使用中のサーバーを切り替えたいだけなら、デスクトップではv2rayNの既存のサーバー選択機能を使うのがおすすめです。複雑な設定を日常環境に導入する前に、シンプルな設定では解決できない具体的な問題を説明できるようにしましょう。

業務通信で最終確認

設定が終わったら、インバウンドの待ち受け、ルーティングの一致、アウトバウンドの接続、業務通信の応答という4つの段階で検証します。ポートが待ち受け状態になっただけでは、プログラムが起動の途中まで進んだことしか分かりません。実際に接続できても、すべてのドメインやUDPが使えるとは限りません。再現できる業務操作を1つ選び、既存の接続を閉じてから実行して、どの段階でエラーが出たか記録しましょう。一時的にログの詳細度を上げる場合は、接続先のドメインやアドレスが含まれることがあります。トラブル対処後は、通常のログレベルに戻してください。

カスタム設定で失敗し、画面から生成した設定なら正常に動作する場合は、まず正常な設定に戻してから、インバウンド、既定のアウトバウンド、DNS、ルーティングの違いを比較してください。サブスクリプションの認証パラメーターを続けて変更しないでください。カスタム設定を長期的に使う場合は、対応するコア、必要なリソース、復元手順をローカルのメモに残しましょう。基本用語は用語集、3種類のクライアントの用途はクライアントの選び方をご覧ください。最初の接続がまだ確立していない場合は、入門ガイドに戻り、まず最小限の設定で接続できる状態にしてください。