総合ガイド · 応用設定

V2Rayの応用設定

サブスクリプション、ルーティング、DNSを段階的に設定します。まず通信の入口を決め、ルールとアウトバウンドを確認し、最後に名前解決と仮想アドレスを調整します。

初めて利用する場合は、まずクイックスタートガイド →に沿って、インポート、接続、動作確認を行ってください。このページでは、基本設定が済んだ後の応用設定を体系的に解説します。チュートリアルで経路の振り分け、名前解決、通信の取り込み範囲に迷った場合は、以下の項目を参照してください。デスクトップではv2rayN、Androidではv2rayNGを中心に説明し、v2flyNGはv2flyコアを使う場合の選択肢として取り上げます。

サブスクリプション管理 domain / ip DNS / FakeDNS TUN / VPN

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

サブスクリプションのグループ分けは設定の取得元を管理するもので、通信の接続先を決めるものではありません。通常、各グループには名前、サブスクリプションURL、絞り込み条件を登録します。更新時にクライアントがURLへアクセスし、取得した内容をサーバー一覧に変換します。サーバー名は識別に使いますが、実際の通信出口の場所を示すとは限りません。設定を始める前に、設定一覧を取得するサブスクリプションURLか、単一サーバーの共有リンクかを確認してください。登録先はそれぞれ異なります。

取得元ごとにグループを作成する

v2rayNでは「サブスクリプショングループ設定」を開き、グループを追加して分かりやすい名前を付け、サブスクリプションURLを保存します。メイン画面に戻り、サブスクリプション関連のメニューからグループを更新します。v2rayNGでは通常、サイドメニューの「サブスクリプショングループ設定」から開きます。画面によっては「サブスクリプション設定」と表示されます。保存後、サーバー一覧に戻ってサブスクリプションを更新してください。メニュー名はバージョンによって異なるため、グループ名とサブスクリプションURLを編集できる画面かどうかで判断します。

グループ名には「仕事用予備」「個人テスト」など、取得元や用途が分かる名前を付けましょう。アクセス情報を含むURLをそのまま名前に使うのは避けてください。サブスクリプションURLは、所持者が設定一覧を取得できる可能性があるため、機密情報として扱います。スクリーンショット、ログ、質問文を共有する際は、パス内のトークン、クエリパラメーター、アカウント情報を削除してください。利用可能な設定を公開しないよう、プロトコルとエラーの種類だけを残します。

初回更新では、まず絞り込みを設定せずに全項目を取得し、サーバー名、プロトコル、通信設定が正しく反映されることを確認します。既知の利用可能な設定を1つ選んで接続を確認してから、絞り込み条件を設定してください。これにより、「サブスクリプションの解析に失敗した」のか「絞り込み後に該当項目がなくなった」のかを切り分けられます。サブスクリプションURLと絞り込み式を同時に変更すると、更新後に一覧が空になった場合、原因を特定しにくくなります。

簡単なキーワードから絞り込む

サーバーの絞り込みは通常、サーバー名の文字列をもとに行われ、実際の設置場所を自動判定するものではありません。まずサーバー名から特徴的な語を1つコピーし、条件として保存してグループを更新します。大小文字、空白、全角記号、提供元による名前の変更などが一致判定に影響することがあります。サーバー名に地域名が含まれていても、その地域から通信が出ていくとは限りません。

クライアントや画面によって、絞り込み欄が通常のキーワードに対応する場合と、正規表現に対応する場合があります。複数キーワードの区切り方も統一されていません。現在の入力欄が正規表現に対応すると明記されている場合に限り、以下の例を使用してください。式中の縦棒は「または」を表し、優先順位を示すものではありません。通常のテキストしか受け付けない欄では、正規表現を流用せず、キーワードを1つずつ試してください。

(?i)(仕事|予備)

この式は、該当する正規表現構文に対応した入力欄で、サーバー名に「仕事」または「予備」が含まれる項目を一致させます。ルーティングは変更しません。元の式は手元に別途保存し、変更する際は古い条件を消してから新しい条件を1つ入力してください。除外語、括弧、複雑な組み合わせは少しずつ追加します。条件を追加するたびに更新し、残す項目と除外する項目がそれぞれ正しく判定されるか確認してください。

更新後に一覧が空になった場合の確認手順

まず絞り込み条件を一時的にすべて消し、同じグループを再度更新します。項目が戻れば、条件の書き方かサーバー名の変更が原因です。空のままなら、サブスクリプションURLの期限切れ、ログインページやエラーページが返されていないかを確認してください。ブラウザーでURLを開けても、クライアントが解析可能なサブスクリプションを取得できるとは限りません。URLによっては特定の形式での応答が必要で、ブラウザーに表示されたページ内容をそのままサブスクリプションとして使えるとは限りません。

サブスクリプションを更新すると、通常、そのグループの項目が再生成されます。手動で変更したサーバー名や接続パラメーターは保持されないことがあります。長期間残したい設定は、独立したローカル項目にコピーし、取得元を記録してください。その後のサーバーパラメーターの変更は、利用者自身で同期する必要があります。インポート先と形式の違いはサブスクリプションリンクのインポート方法、キーワードの整理例は複数サブスクリプショングループの絞り込み実例を参照してください。

ルーティングルールと評価順序

ルーティングルールは、コアに届いた接続をどのアウトバウンドへ送るかを決めます。アプリの通信を自動的にプロキシへ取り込む機能ではなく、利用できないサーバーを復旧させるものでもありません。ルーティングを理解するには、入口、マッチ条件、アウトバウンドを区別します。入口が接続を受け取り、条件がドメイン、宛先IP、ポートなどを判定し、アウトバウンドが直接接続、プロキシ、遮断を実行します。アプリの通信が入口に届いていなければ、どれだけルールを設定しても機能しません。

生成された設定のタグを確認する

v2rayNとv2rayNGには、ルーティングルールやプリセットを変更する設定画面があります。編集前に現在の設定または実行ログを確認し、プロキシ、直接接続、遮断に使われる実際のタグを調べてください。以下の例では、proxy、direct、blockという名前のアウトバウンドがあるものとします。これらは識別用の名前にすぎず、実際のクライアントが同じタグを使っているとは限りません。

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

これはルールの順序を説明するための例で、クライアント設定全体ではありません。例示ドメインは実際の業務用ドメインに置き換え、分類データセットが利用可能な状態にしてください。ルールは上から順に評価され、最初に一致したルールで通信先が決まります。末尾の全一致ルールは、残りのTCPとUDP通信を受け取ります。そのため個別ルールより前に置くと、後続のドメインやIP条件が評価されません。

ドメイン条件とIP条件の違い

full: はドメインの完全一致、domain: はドメインとサブドメインへの一致に使います。geosite: はドメインの分類データセット、geoip: はIPアドレスのデータセットを参照します。同じルールにドメインとポートを両方指定した場合、通常は両方の条件を満たす接続が対象となり、どちらか一方で一致するわけではありません。「特定ドメインまたは特定IPを直結」したい場合は、ルールを分けて作成してください。

domainStrategy は、ルーティング時にドメインを名前解決して判定に使うかどうかを制御します。AsIs は元の宛先をできるだけそのまま使用します。IPIfNonMatch はドメイン条件に一致しなかった場合に名前解決を試み、IP条件で再判定します。IPOnDemand はIP判定が必要なルールに応じて、名前解決を行う場合があります。これはDNSサーバーの一覧ではなく、アプリ自身が行う名前解決をコアが必ず処理する設定でもありません。

ドメインが最終的に複数のサービスで共有されるIPアドレスへ解決される場合、IP分類だけでは異なるサービスが同じ出口に振り分けられることがあります。明確に制御したい通信には具体的なドメインルールを使い、広い分類ルールより前に配置してください。ログイン、画像表示、認証、更新などで複数のドメインを使うソフトウェアでは、メインのドメインだけでは足りないことがあります。接続ログを参考に必要なドメインを追加し、すべての通信を対象にするよう安易に範囲を広げないでください。

スニッフィングとLAN向けルール

「トラフィックのスニッフィングを有効にする」と、対応する接続内容からドメイン情報を復元し、ドメインによる振り分けに利用できる場合があります。ただし、すべてのプロトコルを識別できるわけではなく、暗号化された内容を解読する機能でもありません。宛先IPしか分からない接続から、必ずドメインを復元できるとは限りません。有効化後に特定のアプリで問題が起きた場合は、まずスニッフィングによる宛先の上書き動作を確認し、この設定だけを元に戻してください。DNSとルーティングも同時に変更すると原因を特定しにくくなります。

LANへ直接接続するには通常、プライベートIPアドレス向けのルールが必要です。また、クライアントの「LANをバイパス」、システムルート、TUNの除外ネットワークも影響します。コアに直結ルールを追加しただけで、LANへのすべての通信が仮想ネットワークインターフェースを迂回するとは限りません。プライベートIP範囲を安易にリモート側へプロキシするのも避けてください。社内ネットワークのドメインとアドレスは実際のネットワーク設計に合わせて設定し、特にリモート側とローカル側でプライベートIP範囲が重複していないか確認します。

検証時はサーバーを1つに固定し、完全一致するドメイン、分類ドメイン、どのルールにも一致しない宛先の順にテストして、ログのアウトバウンドタグを確認します。ルールを編集しても変化がない場合は、変更したルーティング設定が選択されているか、接続の再起動が必要かを確認してください。分類データが読み込まれていない場合は、まず読み込みエラーを解消します。安易に範囲の広い直結ルールへ変更しないでください。基本的な用語はヘルプセンターで確認できます。

DNS設定と名前解決の経路

DNSの問題はサーバーの障害と間違われがちです。通常、通信先のIPアドレスを取得してから接続しますが、ブラウザー、OS、プロキシコアがそれぞれ名前解決する場合があります。クライアントでDNSアドレスを変更しても、実際にクライアントが処理する問い合わせにしか影響しません。まずドメインがどこへ渡されるかを確認し、そのうえでリゾルバー、問い合わせ方式、通信方法を選びます。すべてのDNS欄に同じアドレスを入力するだけでは解決しません。

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

1つ目は、アプリがOSの名前解決を利用し、得られた宛先IPをプロキシへ渡す方法です。2つ目は、アプリがドメインをローカルプロキシへ渡し、コアまたはリモート側で名前解決する方法です。3つ目は、アプリが暗号化DNSを直接利用し、その通信が通常の暗号化接続として見える方法です。これらは同じ端末で併用されることがあります。あるブラウザーでは正常でも別のアプリでは失敗するからといって、クライアントのDNS設定全体が正しい、または間違っているとは判断できません。

設定レイヤー主な役割確認場所
アプリ・システムのDNS通信がプロキシに入る前に名前解決アプリのネットワーク設定、システムのネットワーク設定
コアのDNS接続先の振り分けと指定された名前解決クライアントのDNS設定、生成された設定
TUNによるDNSの取り込み指定されたDNS問い合わせを処理コンポーネントへ渡すTUN設定、仮想ネットワークインターフェース、ログ

v2rayNでは、設定画面のDNS関連項目から名前解決の動作を設定できます。TUNのDNS設定は別レイヤーにある場合があります。v2rayNGでは、DNS設定、VPNモード、FakeDNSの有効・無効をあわせて確認してください。v2flyNGはv2flyコアを使用するため、Xray専用の項目をそのまま流用しないでください。設定名が似ていても、クライアントが生成した設定とコアが受け付ける内容を確認する必要があります。

単独で動作する基本の名前解決を用意する

まずFakeDNSを無効にして通常の名前解決経路を使い、サーバーのアドレス自体を名前解決できることを確認します。サーバーアドレスがドメインで、その解決に使う暗号化DNSが、まだ確立していないプロキシを経由する必要があると、起動時の依存関係が発生します。その場合は、サーバーのドメインを解決できる到達可能な経路を用意するか、サービス提供元が明示した接続先を使用してください。TLSのドメイン名とSNIも正しく設定します。

{
  "dns": {
    "hosts": {
      "resolver.home.arpa": "192.168.1.53"
    },
    "servers": [
      {
        "address": "192.168.1.53",
        "domains": ["domain:home.arpa"]
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

これは一般的なDNS設定の例です。家庭内のリゾルバーアドレスは実際に使うものへ置き換え、そのアドレスへ到達できることを確認してください。home.arpa は家庭内ネットワークの名前解決に使います。この例は、特定ドメインと一般的な問い合わせを別々に処理できることを示しています。サーバーの配列が厳密な順番で切り替わるフェイルオーバーキューであることを示すものではありません。マッチング、フォールバック、並列処理の動作は、コアの実装や追加パラメーターによって異なるため、ログで確認してください。

アドレスファミリーと暗号化DNSの調整

問い合わせ方式によって、返されるアドレスファミリーが変わります。端末にIPv6アドレスがあっても、利用中のサーバー、リモート側の出口、接続先サイトのすべてでIPv6が使えるとは限りません。一部のサイトだけ読み込みに時間がかかる場合は、一時的にIPv4のみで問い合わせて比較できます。原因を確認したら、IPv6ルートまたは出口の対応状況を修正してください。特定のアドレスファミリーを恒久的に無効化して、あらゆる名前解決の問題を解決しようとしないでください。

暗号化DNSを使う場合は、リゾルバーのドメインの初回名前解決、証明書の検証、接続ルートをあわせて考える必要があります。リゾルバーをプロキシ経由にするなら、プロキシの起動前にサーバーのドメインをどう名前解決するか確認してください。直接接続するなら、ローカルネットワークからアクセスできることを確認します。DNSの通信方式を変えても、アプリの通信の出口が自動的に変わるわけではありません。逆にアプリ通信をプロキシに設定しても、すべてのDNS問い合わせが同じ経路を通るとは限りません。

テストには、存在が分かっている完全なドメインを使います。アドレスが取得できたか、どの種類のアドレスが返されたか、その後どの出口から接続したかをそれぞれ確認してください。名前解決に成功してTLSで失敗する場合は、リゾルバーを次々に変更するのではなく、システム時刻、SNI、証明書を確認します。関連する項目はTLSハンドシェイクと証明書のトラブル対処を参照してください。内部ドメインが失敗する場合は、指定リゾルバーとプライベートネットワークへのルートを確認し、パブリックDNSへの再問い合わせを繰り返さないでください。

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

TUNは仮想ネットワークインターフェースを通じてIP通信を受け取り、システムプロキシに従わないアプリにも対応できます。ただし、サーバーのプロトコルとは別の仕組みであり、すべてのアプリが正常に動作することを保証するものではありません。利用する前に通常のプロキシモードで接続できることを確認し、その後で仮想ネットワークインターフェースによる取り込みを有効にします。こうすれば、サーバーの利用可否とシステムルートの問題を切り分けられます。デスクトップでは、まずv2rayNの既存設定から始めてください。接続失敗時に理由なくTUNを切り替えるのは避けましょう。

デスクトップのTUNとAndroidのVPNモード

v2rayNのシステムプロキシは、プロキシ設定を参照するアプリで主に使われます。一方、TUNはネットワークインターフェースのレイヤーから通信の取り込み範囲を広げます。両者は同じものではありません。Android版v2rayNGはシステムVPNサービスを使ってアプリの通信を受け取ります。設定画面には「VPNモード」や「プロキシのみモード」などの項目があります。プロキシのみモードでは、アプリ自身がローカルの待ち受けポートへ接続する必要があるため、端末全体の通信が自動的にその入口を使うわけではありません。

デスクトップでTUNを有効にすると、管理者権限やシステムのネットワーク許可が必要になる場合があります。まず仮想インターフェースを作成できることを確認し、起動が完了したかログを確認してください。Windowsでは権限とセキュリティソフトによる通信の遮断、macOSではシステムの許可とプロキシ設定の残存、Linuxではインターフェース作成に必要な権限とルート変更を確認します。トラブル対処のためにセキュリティ設定をすべて無効にせず、ログで根拠のある遮断だけに対処してください。

Androidで初めて接続すると、システムのVPN許可画面が表示されます。アプリ名を確認してから許可してください。同時に別のVPN系ツールを使うと、通信の取り込み機能が競合する場合があります。バックグラウンド制限によって接続が中断されることもあります。アプリを切り替えた後に接続が止まる場合は、バッテリー最適化、バックグラウンド実行の許可、別のネットワークツールによる通信の取り込みを確認してください。サーバーの通信パラメーターを何度も変更する必要はありません。

ルーティングとDNSを順番に確認する

TUNを起動する前に、デフォルトのネットワークインターフェース、既存のシステムプロキシ、実行中の他のネットワークツールを記録します。起動後は仮想インターフェースが作成されたか、ルートが設定されたか、サーバー接続が再び仮想インターフェースへ送られていないかを確認してください。リモートサーバーへの接続には適切な出口経路が必要です。その接続まで繰り返し取り込まれるとルーティングループが発生し、起動後に端末全体でネットワークへ接続できなくなったり、ログに同じ接続が繰り返し記録されたりします。

TUNによるDNSの取り込みとコアのDNS設定は、別々のコンポーネントが処理する場合があります。まず通常のドメインを名前解決し、次にIP宛ての接続とLAN内のリソースをテストしてください。ドメインだけ失敗し、IP通信ができる場合はDNSを重点的に確認します。どちらも失敗する場合は、インターフェース、デフォルトルート、アウトバウンド接続を確認してください。仮想インターフェースが正常に動作する前にFakeDNSも有効にすると、アドレスマッピングという変数が増えてしまいます。

通信の入口取り込みの条件よくある制約
システムプロキシアプリがシステムプロキシを参照するか、手動で設定するシステムプロキシを使わないアプリがある
デスクトップTUNインターフェースの権限、ルート、DNSの連携ルーティングループ、ネットワーク範囲の競合、UDP対応
Android VPNモードシステムの許可とアプリの取り込み範囲が適切であることアプリごとの選択とバックグラウンド制限

アプリごとのプロキシ設定とLANアクセス

v2rayNGの「アプリごとのプロキシ」では、どのアプリをVPNの取り込み対象にするかを設定します。現在の画面が「選択したアプリのみをプロキシ」する設定なのか、「選択したアプリを除外」する設定なのか確認してから対象を選んでください。アプリ名の横にチェックがあるかだけでは、設定の意味を判断できません。保存後に接続を再起動し、テスト対象のアプリも完全に終了してから開き直してください。すでに確立済みの接続は、以前の経路を使い続ける場合があります。

デスクトップでは、プロセスごとの振り分けがTUNの実装レイヤーで提供されることがあります。プロセス名を従来のV2Rayルーティングルールに直接書いても有効とは限りません。アプリごとに設定する場合は、使用中のクライアントが明示的に提供する機能を使い、子プロセスやアップデーターも確認してください。アプリ単位の取り込み除外と、ドメインを直接接続するルールは異なるレイヤーです。前者では通信がコアに届かない場合がありますが、後者ではコアに届いた後で直接接続を選択します。

LANプリンター、共有フォルダー、社内サービスに接続できない場合は、「LANをバイパス」と除外ネットワークを確認してください。職場と家庭のネットワークでプライベートIP範囲が重複している場合は、実際の宛先に合わせて細かく設定します。プライベートIP範囲全体をリモート側へ送るのは避けてください。TUNを無効にした後は、システムのデフォルトルートとプロキシ設定が復旧したことを確認してから次のテストを行います。インストールや権限の準備については、クライアントのダウンロードページとmacOSのインストールとアクセス許可を参照してください。

FakeDNSと仮想アドレスのマッピング

FakeDNSは、接続先サーバーの実際のアドレスではなく内部用の仮想アドレスをアプリへ返し、そのアドレスとドメインの対応関係を保持します。アプリが仮想アドレスへ接続すると、通信を取り込むコンポーネントがドメインを特定し、ルーティングルールとアウトバウンドに従って処理します。この仕組みの目的はドメイン情報を保持することであり、仮想アドレスを通常のネットワークから直接アクセス可能にすることではありません。マッピング環境の外では、仮想アドレス自体に接続先としての意味はほとんどありません。

通信を取り込むための条件を満たす

FakeDNSを動作させるには、対象のDNS問い合わせがFakeDNSの処理経路に入り、アプリから仮想アドレスへの接続も同じ仕組みで取り込まれる必要があります。片方だけが有効だと、名前解決は成功しても接続できないことがあります。ブラウザーが独自の暗号化DNSを使うとFakeDNSを迂回する場合があります。また、アプリが古いアドレスをキャッシュしていると、実際のアドレスを使い続けることがあり、同じ端末でも動作が一致しないように見えます。

v2rayNGの「FakeDNSを有効にする」は、VPNモード、DNS設定、スニッフィング関連の設定とあわせて確認してください。画面上のスイッチが、コアの複数の設定項目を自動生成する場合があります。1つの真偽値だけを見比べないでください。v2rayNのTUN DNSでも、通信を取り込むコンポーネントが同様の仕組みを実装する場合があります。設定項目や保存場所はXrayコアと異なることがあるため、一方の設定例を他方へそのまま貼り付けないでください。

v2flyNGはv2flyコアを使用します。具体的な機能は、現在の画面と設定の解析結果を基準に判断してください。未知の項目がある場合は、エラーメッセージを削除して有効化するのではなく、そのコアが対応する設定形式に戻してください。クライアント名、画面上のスイッチ、コアの設定はそれぞれ異なるレイヤーです。機能名が同じでも設定項目まで互換とは限らず、クライアント間でDNS設定を移行する際には特に注意が必要です。

アドレスプールとスニッフィングの連携

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

上の例は、対応するXray設定におけるアドレスプール部分だけを示したもので、FakeDNSを有効にする設定全体ではありません。DNSでFakeDNSを使用し、該当する入口でドメインを復元し、仮想アドレス範囲の通信を取り込む必要があります。ipPool は割り当て範囲、poolSize はマッピング容量を設定します。サーバー数やネットワークの性能を表す値ではありません。クライアントが生成する互換性のある設定を優先し、この部分だけを追加してテストを始めないでください。

マッピング用のアドレス範囲が、現在のネットワークや他の仮想ネットワークと重複しないようにしてください。社内の検証ネットワークや別のトンネルツールが同じ範囲を使っている場合は、範囲を統一して設計する必要があります。仮想アドレスプールを通信取り込みの除外対象にすると、アプリの接続が通常のネットワークへ直接送られてしまいます。また、この範囲を実際の宛先とみなしてリモート側の直結ルールに追加しないでください。マッピングは適切なローカル処理レイヤーで復元する必要があります。

トラフィックのスニッフィングとFakeDNSは連携できますが、役割は異なります。通常のスニッフィングは接続内容からドメインの復元を試みます。一方、FakeDNSは事前に作成されたマッピングを使って復元します。接続時にマッピングがすでに失われていると、通常のスニッフィングだけでは補えない場合があります。クライアントの再起動、マッピングの削除、コンポーネント間の状態不一致などにより、アプリに残った仮想アドレスからドメインを特定できなくなることがあります。

適用する場面と復旧方法

ドメインによる安定した振り分けが必要で、通信の入口ではIPしか取得できない場合は、基本の通信経路が安定してからFakeDNSを試してください。固定IPに直接接続するプログラム、LAN内のデバイス検出、DNSの結果を検証する一部のアプリには、この仕組みが適さない場合があります。そのようなアプリには、通信の取り込みを明示的に除外するか、通常の名前解決を検討してください。対象を絞らず、全体設定をさらに増やして対処するのは避けましょう。

有効にした後は、通常のウェブ閲覧、ログイン、メディア、バックグラウンド処理の順にテストします。一部のアプリだけ失敗する場合は、独自の暗号化DNSを使っているか、接続先IPを固定しているか、有効化前から起動していたかを記録します。まずアプリを完全に終了してから再試行してください。それでも問題が続く場合は、他の設定を変えずにFakeDNSを無効にし、同じ宛先で比較します。これでアドレスマッピングが原因かどうか判断できます。

問題を記録する場合は、ドメイン、問題が起きた通信の取り込みモード、アウトバウンドタグだけを残し、設定全体を公開する必要はありません。無効にすると復旧し、再び有効にすると安定して再現する場合は、DNSの取り込み、アドレスプールのルーティング、マッピングの復元を順に確認します。どちらのモードでも失敗する場合は、サーバー接続と通常のDNSの確認に戻り、FakeDNSと無関係な設定を変更し続けないでください。

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

複数のサブスクリプションを使う場合、重要なのはインポートできるかどうかだけでなく、取得元、用途、更新による変更を追跡できることです。取得元ごとにグループを分け、サーバー名やローカルのメモで用途を記録しましょう。取得元が分からなくなる一覧にすべてのリンクをまとめないでください。URLの期限切れ、形式の変更、項目の削除が発生した場合も、グループを分けておけば影響範囲を特定しやすく、他の利用可能な設定も保護できます。

取得元、サーバー選択、通信ポリシーを分けて管理する

サブスクリプショングループは取得元を管理し、現在選択しているサーバーはプロキシの出口を決め、ルーティングルールはどの接続にその出口を使うかを決めます。この3つを混同しないでください。「仕事用」グループに項目があっても、仕事用アプリが自動的にその項目を使うわけではありません。グループの表示を切り替えても、現在使用中のサーバーが切り替わるとは限りません。操作後は、一覧でどのグループを表示しているかだけでなく、メイン画面で現在選択されている項目を確認してください。

最初に整理する際は、取得元ごとにサブスクリプションの種類、グループ名、絞り込み条件、利用可否の確認方法を記録してください。記録はローカルに保存し、公開されるスクリーンショットには載せないでください。「手動更新後にどの通信をテストするか」を簡単な表にまとめるのは便利ですが、サブスクリプションのトークンや接続パスワードを共有文書に記載しないでください。取得元の認証情報が漏れた場合は、グループ名を変えるだけでなく、提供元が案内する方法で認証情報を更新してください。

ローカルで独立して管理する項目と、サブスクリプションから生成された項目は分けて管理するのがおすすめです。前者は手動管理が必要な設定の保持に、後者は取得元に合わせた更新に向いています。項目をコピーしたら、誰が更新を管理するか記録してください。サブスクリプションのサーバーでポート、認証、TLSの設定が変更されても、ローカルのコピーには通常反映されません。この点を忘れると、一覧に名前は似ていても実際の設定が異なる項目が残ってしまいます。

まず手動で更新し、その後に自動更新を設定する

各グループで一度手動更新を行い、ネットワークに接続できること、内容を解析できること、絞り込み結果が意図どおりであることを確認します。その後、取得元の更新頻度に合わせて自動更新を設定してください。現在の画面に自動更新の項目がなければ、手動更新を続けます。Androidではバックグラウンド制限によりスケジュールされた処理が遅れる場合があります。自動更新が有効でも、接続に問題が起きた際すぐにサーバーが切り替わるとは限りません。両者は別々に判断してください。

クライアントによっては、現在のプロキシを経由して更新する方法と、経由しない方法を選べます。既存の接続が正常な場合は、プロキシ経由でサブスクリプションを取得できるか試せます。初回起動時や現在のサーバーが利用できない場合は、他に更新できる経路があるか確認してください。すべての取得元を、利用できない同じ出口だけに依存させないでください。まず独立して利用できる設定を1つ確保し、それから更新方法を変更します。更新と接続の依存関係が互いにロックされるのを防げます。

更新後は、現在の選択項目が引き続き有効か確認してください。取得元が項目の名前を変更、削除、置換することがあります。クライアントが選択項目を再特定する場合もあれば、無効になった参照を保持する場合もあります。サーバー名を固定しても、同じサーバーを示し続ける保証はありません。重要な通信をテストする前に、一覧の位置を頼りにせず、実際の接続パラメーターとログのアウトバウンドを確認してください。

名前の重複、同一項目、形式変更への対処

異なる取得元で同じサーバー名が使われたり、同じサーバーが別の名前で重複したりすることがあります。名前が同じでも接続パラメーターが同じとは限らず、パラメーターが同じでも更新のタイミングや取得元が同じとは限りません。整理する前にアドレス、ポート、プロトコル、通信方式、TLS設定を比較し、ローカルのコピーを残すか決めてください。名前だけで一括削除すると、別の用途で使う有効な設定を削除するおそれがあります。

絞り込みルールはグループごとに設定し、個別に検証してください。取得元がサーバー名の付け方を変更すると、以前のキーワードがすべて一致しなくなることがあります。別の取得元のグループは正常なままの場合もあります。この場合は、問題が起きたグループだけ一時的に絞り込みを解除すればよく、クライアントの全設定をリセットする必要はありません。取得元が返す形式を変更した場合は、現在のクライアント向けのサブスクリプションURLを提供元に確認してください。ウェブページの内容を何度もインポートするのは避けましょう。

新しい端末へ移行するときは、まずグループ構成を移し、1つずつ更新して動作を確認します。DNS、ルーティング、通信の取り込み設定をすぐにすべて上書きしないでください。サブスクリプションの内容だけでは、ローカルのポリシーをすべて復元できないことがあります。新しい端末での確認が終わるまでは、古い端末の利用可能な設定を残し、その後エクスポートファイルを整理してください。ダウンロードやアーキテクチャの選択はダウンロードページから行います。整理方法はサーバーのキーワード絞り込み実例も参考になります。

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

アウトバウンドは、接続がコアから出ていく方法を定義します。直接接続、プロキシ、遮断は代表的な種類で、ルーティングルールからタグで参照します。カスタムアウトバウンドは、出口を固定したい場合や特殊なネットワーク構成が必要な場合に使うもので、初回設定の出発点ではありません。まずv2rayNまたはv2rayNGの標準的なサーバー項目で接続を確認してから、カスタム設定を検討してください。画面から生成された設定と手書き設定の競合を減らせます。

設定断片を追加するレイヤーを確認する

クライアントには、サーバー編集、カスタム設定、ルーティング編集、追加設定などの入力欄が用意されている場合があります。入力欄によって、完全なJSON、一つのオブジェクト、配列など受け付ける内容が異なります。貼り付ける前に入力欄の説明と保存後に生成される設定を確認してください。完全な設定には、入口、アウトバウンド、ルーティングなどが含まれます。outbounds だけの断片を完全な設定として動かしても、アプリが接続する入口がなく、動作しない場合があります。

{
  "outbounds": [
    {
      "tag": "local-egress",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 10810
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "local-egress"
      }
    ]
  }
}

この例は、指定ドメインをローカルにあるSOCKSサービスへ転送します。その他の動作は設定全体に依存し、入口やリモートサーバーは定義していません。利用前に、ローカルで例示ポートを待ち受けるサービスが実際に動作していることを確認してください。既存の設定に統合する場合は、元のデフォルトアウトバウンドの順序を維持するか、末尾にルーティングルールを明示的に追加します。従来の設定では、ルールに一致しない接続は通常、最初のアウトバウンドに渡されます。順序を誤って変更すると、全体の動作が変わります。

タグ、ポート、ループを確認する

tag は内部で参照する名前です。重複しない名前にし、ルーティングルールの outboundTag と一致させてください。表記が似ていても、同じタグとは限りません。名前を変える場合は、参照している箇所もすべて変更してから接続を再起動します。設定で対象のアウトバウンドが見つからないと表示された場合は、サーバーアドレスではなく、生成後のタグを確認してください。このエラーは設定の構成段階で起きており、リモート接続にはまだ進んでいません。

ローカル転送では、アウトバウンドが入口へ戻らないようにしてください。たとえば、現在のコアがあるポートでSOCKS接続を受け取り、アウトバウンドも同じポートへ送信すると、ループが発生します。他のサービスを中継する場合は、「アプリ、入口、コア、次のサービス、リモート」の流れを図にし、各段階の待ち受けアドレスとポートを確認してください。ポートの競合についてはローカル待ち受けポートの競合対処を参照してください。

127.0.0.1 で待ち受けると、ローカル端末からだけアクセスできます。ローカル転送に適した設定です。接続問題を解決するために、待ち受け範囲をすべてのネットワークインターフェースへ安易に広げないでください。LAN内の端末から利用する必要がある場合は、認証、アクセス制限、ファイアウォールを別途設定します。カスタムアウトバウンドで指定するローカルアドレスは、コアが動作する端末を指し、サーバー側のローカルアドレスではありません。端末間で設定をコピーする際に特に間違えやすい点です。

UDP、TLS、コア間の違い

上位のサービスがSOCKSだからといって、UDPが必ず使えるとは限りません。入口、コア、次のサービス、最終的なサーバーすべてが対応した転送方式を使える必要があります。どこか1か所でも対応していないと、TCPだけが動作する場合があります。一般的なウェブページが開けても、必要な通信経路すべてが正常とは限りません。実際に必要なプロトコルごとにテストし、1つの成功例だけで転送経路全体を判断しないでください。

TLSのサーバー名は、証明書の検証とハンドシェイクに使われます。接続先をIPアドレスに変更したからといって、安易に消さないでください。設定に失敗した場合は実際のサービスパラメーターを確認し、証明書検証を無効にした状態を常用しないでください。アウトバウンドのプロトコルを変更する際は、通信方式、認証、TLSの項目もあわせて確認します。プロトコル名だけを変更し、旧設定の無関係な項目を残しても、正しく移行できるとは限りません。

Xrayとv2flyには共通する設定概念もありますが、対応項目、プロトコルの拡張、デフォルト動作は完全には一致しません。カスタム設定をv2rayNGからv2flyNGへ移行する場合は、まず最小限の構成で動作を確認し、拡張項目を一つずつ追加してください。サブスクリプションの更新で、クライアントが生成したアウトバウンドが上書きされることもあります。手書きの設定は別途バックアップし、一覧内の通常の項目ではなく、実際にカスタム設定が実行されていることを確認してください。

設定の検証と段階的な復旧

応用設定の確認で目指すのは、「たまにページが開く」ことではありません。通信がどこから入り、どのように名前解決され、どのルールに一致し、最終的にどのアウトバウンドから出ていくかを説明できる状態にすることです。まず最小限の基準設定を作り、その後にサブスクリプションの絞り込み、ルーティング、TUN、FakeDNSを1つずつ追加します。各段階で復元可能な状態を残せば、問題の範囲を絞り込めます。原因を特定せず、クライアントを再インストールして済ませるのは避けてください。

条件を固定して検証する

基準設定には、利用できることを確認済みのサーバー、通常のDNS、最も簡単なルーティングルール、明確な通信の入口を含めます。日常的に使う完全なドメイン、LAN内のリソース、プロキシが必要な通信を1つずつテスト対象として固定してください。検証中は端末のネットワークとサーバーを変えずに進めます。Wi-Fiの切り替えとリゾルバーの変更を同時に行い、その結果から特定の設定が有効だったと判断しないでください。

変更前に元の値、変更する内容、予想される結果を記録します。たとえば完全一致するドメインの直結ルールを追加するなら、漠然と「安定性が上がる」ことを期待するのではなく、ログのアウトバウンドタグが変わることを予想します。保存して接続を再起動した後、テスト対象のアプリに残っている古い接続を閉じてからアクセスしてください。サブスクリプション更新では項目が生成されること、TUNではインターフェースとルートが設定されること、FakeDNSでは仮想アドレスからドメインを復元できることをそれぞれ確認します。

確認された現象優先して確認する項目比較テストの方法
サブスクリプションの更新後に一覧が空になる絞り込み条件、URL、応答形式現在のグループの絞り込みを解除して手動更新する
名前解決はできるが接続できないアウトバウンド、TLS、接続先ポート基準設定で同じ宛先にアクセスする
TUNを有効にすると全体に問題が起きる権限、システムルート、ルーティングループTUNを無効にし、通常のプロキシでテストする
FakeDNSを無効にしても問題が続くアプリのキャッシュ、残っている仮想アドレス接続とテスト対象のアプリを再起動して比較する

ログで失敗した段階を切り分ける

設定の解析エラーは通常、起動時に発生し、項目、構文、タグに関する問題として現れます。待ち受けの失敗は、ポートの競合や権限が原因の場合が多くあります。接続確立後のタイムアウトが発生した場合は、ネットワークとリモート側を確認します。最初に発生したエラーを探し、繰り返し表示される後続の接続エラーだけをコピーしないでください。前の段階が成功していない場合、後続のエラーはその結果である可能性があります。後続部分を変更しても、根本原因は解決しません。

一時的にログの詳細度を上げると、宛先とアウトバウンドの確認に役立ちます。ただし、詳細なログを常時使用するのは避けてください。ログにはドメイン、アドレス、通信内容が含まれる場合があります。共有する前に機密情報を削除してください。スクリーンショットにサブスクリプションURL、接続情報、完全な共有リンクが写っていないかも確認します。トラブル対処が終わったら普段のログレベルに戻し、一時ファイルを削除して、機密性のある設定がダウンロードフォルダーや共有フォルダーに残らないようにしてください。

同じサービスでも複数の接続を確立する場合があります。メインページは開けてもログインに失敗する場合、関連ドメインが別のルールを通っていることがあります。画像の読み込み失敗は、画像の配信ドメイン、名前解決の結果、アドレスファミリーの違いが原因かもしれません。失敗した通信を特定してルールを追加・検証し、問題が1つ見つかっただけですべての通信を同じ経路に変更しないでください。必要に応じて一時的に簡単なルーティングで比較し、テスト後に元の設定へ戻します。

直近の変更から順に元へ戻す

続けて設定を変更した後に問題が起きた場合は、直近の変更から順に戻してください。追加したFakeDNSを無効にし、通常のDNSへ戻してから、追加したルーティングルールを削除します。最後にTUNまたはVPNによる通信の取り込みを終了し、元の入口に戻します。変更を1つ戻すたびに、同じテスト対象で確認してください。グループの全消去、サーバーの削除、システムネットワークのリセットを同時に行うと、復旧しても原因を特定できません。

クライアントを停止した後もネットワークに接続できない場合は、システムプロキシの設定が残っていないか、仮想ルートが復旧したか、他のネットワークツールが動作していないかを確認してください。正体の分からないネットワークインターフェースをすぐに削除したり、システムルートを一括変更したりしないでください。まず現在の状態を保存し、どのソフトウェアに属するか確認します。ブラウザーだけに問題がある場合は、ブラウザー独自のプロキシ設定と暗号化DNSを確認してください。1つのアプリだけに問題がある場合は、アプリごとの通信取り込み設定とアプリ内のネットワーク設定を確認します。

設定の流れを最初から確認する場合は、クイックスタートガイドに戻り、インポート、モード選択、接続、動作確認の順に進めてください。個別の現象を調べるにはヘルプセンターを利用できます。インストールファイルはダウンロードページから選択してください。このガイドの設定例は各レイヤーの説明を目的としており、完全な設定に代わるものではありません。実際の環境で使用する前に、クライアント、コア、現在生成されている設定の構造を確認してください。