v2rayN
高度な設定ガイド

設定の階層と変更前のバックアップ

クライアント・コア・OSの役割を理解する

v2rayNのメイン画面では、サーバー情報、サブスクリプショングループ、ルーティングプリセット、画面設定を管理します。接続を開始すると、クライアントはこれらの情報をもとにコアの実行設定を生成します。一方、システムプロキシはOSの設定で、対応するアプリにローカルのプロキシポートへリクエストを送るよう指示します。この3つは連動しますが、同じ設定ではありません。サーバー一覧を変更しても、すべてのアプリの接続経路が自動で変わるわけではありません。システムプロキシを切り替えても、コアにルーティングルールが追加されるわけではありません。

設定ファイルを読む前に、クライアントで現在のサーバー、ルーティングプリセット、実行中のコアを確認し、ステータスバーとログも確認してください。このサイトでは、デスクトップ向けにv2rayN、Android向けにv2rayNGを主に扱います。V2Flyコアを使用する代替クライアントはv2flyNGです。画面構成が似ていても、設定フィールドが同じとは限りません。同じ形式の共有リンクをインポートできても、内部で生成される設定が異なる場合があります。クライアントを移行する際は、まず接続情報を移し、その後に高度な設定を一つずつ再設定してください。

元に戻せる基準状態を作る

変更前に、クライアントのバックアップまたはエクスポート機能で現在の設定を保存してください。システムプロキシの状態、待ち受けアドレス、ローカルポート、現在のルーティングプリセット、TUNの設定も記録します。クライアントのデータフォルダーをコピーする場合は、データベースや設定ファイルへの書き込みが完了するよう、先にクライアントを終了してください。バックアップにはサブスクリプションURLやサーバーの認証情報が含まれることがあります。管理されたローカル環境に保存し、公開の問い合わせに添付しないでください。

基準状態の確認は「ウェブページが開く」だけでは不十分です。普段使うアプリが接続できること、LAN内のデバイスにアクセスできること、クライアント終了後にネットワークが復旧することも確認してください。それぞれの操作がシステムプロキシとTUNのどちらに依存するか記録します。後で特定の種類のリクエストだけに問題が起きても、接続入口、ルール、名前解決のどこに原因があるか切り分けやすくなります。基本接続をやり直す場合は、使い方ガイドの手順で一度検証してから高度な設定に進んでください。

一度に変更するのは一項目だけ

サブスクリプション、ルーティング、DNS、TUNの順に調整するのがおすすめです。一度に変更するテーマは一つに絞り、保存して再読み込みした後、接続を確立し直してください。すでに確立している長時間接続は、ルールを変更してもすぐに経路が切り替わるとは限りません。ログを確認するときは、同じ接続先と同じアプリを使い、キャッシュやアプリの再試行、一時的なサイト障害を設定変更の結果と取り違えないようにします。設定を比較する場合は、「LAN内の接続先をプロキシ経由から直接接続にする」など、想定する変化を先に書き出し、実際のアウトバウンドを確認してください。

ログレベルも基準を決めておきましょう。通常利用ではクライアントの既定値を使い、トラブルシューティング時だけ一時的に詳細度を上げます。ログにはドメイン名、アドレス、パス、サブスクリプションへのリクエスト情報などが記録される場合があります。共有する前に、認証パラメーターや個人のネットワーク情報を削除してください。エラーログは何が起きたかを示しますが、原因が必ず最後の行にあるとは限りません。最初に失敗した箇所から前にさかのぼり、コアの起動、DNS、接続先への接続の順に確認しましょう。後続の連鎖的なエラーを別々の問題として扱わないようにしてください。

クライアントが一時的に生成した実行ファイルを直接編集しても、変更が維持されるとは限りません。接続の再確立、サーバーの切り替え、サブスクリプションの更新によって、ファイルが再生成されることがあります。GUIで保存できる設定は画面から変更してください。カスタム設定が必要な場合は、クライアントが明示的に用意している設定欄を使い、元の内容をバックアップします。JSONの構文チェックに通っても、現在のコアがそのフィールドに対応しているとは限りません。未知のフィールド、未対応プロトコル、設定の解析エラーが出た場合は、まずコアの種類を確認し、次に設定の階層を調べてください。

このページの設定は、クライアントが設定内容を保存し、コアがルールを実行し、OSがトラフィックの入口を管理するという役割分担を前提としています。起動失敗、ポートの競合、システムプロキシの残留などが起きた場合は、症状に応じてよくある質問をご覧ください。メイン画面の各項目については、v2rayNメイン画面の機能ガイドも参考になります。

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

サブスクリプションごとに管理単位を分ける

サブスクリプションのグループは、測定結果ではなく設定の取得元ごとに分けるのがおすすめです。v2rayNの「サブスクリプショングループ」でグループを追加し、識別しやすい名前とサブスクリプションURLを入力して保存してから、更新を実行します。グループ名には「仕事用」「テスト用」など、取得元や用途がわかる情報を付けてください。URLに含まれる認証パラメーターは名前にコピーしないでください。追加後はまずそのグループだけを更新し、想定した取得元の内容であることを確認してから、日常的に使用してください。

「すべて」は通常、サーバー一覧をまとめて表示するビューであり、すべての項目が一つのサブスクリプション由来という意味ではありません。削除や一括操作の前に、対象のグループへ切り替え、絞り込み条件と選択範囲を確認してください。異なるグループに同じ別名の項目がある場合もあります。別名はサーバーの一意な識別子ではありません。重複を判断する際は、プロトコル、接続先アドレス、ポート、トランスポート設定も確認し、名前が同じというだけで削除しないでください。

一覧検索と更新時のフィルターを区別する

サーバー一覧の検索は、主に現在表示されている項目を絞り込みます。一方、サブスクリプション設定のフィルターは、更新後に残す項目を左右することがあります。この2つでは影響が異なります。一覧に表示されない項目がある場合は、まず検索文字列を消し、次に選択中のグループを確認し、最後に更新時のフィルターを確認してください。絞り込みが有効なままサブスクリプションが空になったと判断したり、すぐにグループを削除して作り直したりしないでください。既存のフィルターや更新設定を失うおそれがあります。

画面によってはキーワード検索を使い、別のフィルター欄では正規表現を使います。入力欄の説明に従い、異なる構文を混同しないでください。正規表現に対応していることが明記されている場合は、まず広めの条件で試し、徐々に絞り込みます。以下は別名を基準に絞り込む例で、指定した名前の一部に一致します。ルーティングルールではなく、トラフィックのアウトバウンドを決めるものでもありません。名前はサブスクリプション側が設定するため、実際のサーバーの場所や性能を保証するものではありません。

香港|日本
^(香港|日本)
テスト|予備

1行目は名前にいずれかの語を含む項目、2行目は名前がいずれかの語で始まる項目、3行目は除外用の正規表現に対応した入力欄で使う例です。それぞれ独立した例であり、複数行をまとめて設定するものではありません。フィルター欄が一つだけの場合は、包含と除外のどちらを指定する欄か確認してください。正規表現の縦棒は「または」を表し、通常の文字列区切りではありません。サブスクリプション名に括弧やプラス記号などが含まれる場合は、正規表現でのエスケープも考慮してください。

更新前に使える項目を残す

サブスクリプションを更新すると、その取得元が管理するサーバー情報が置き換わることがあります。サブスクリプションの項目を手動編集しても、次回更新時に上書きされる可能性があります。変更を長期的に維持したい場合は、対象を専用の手動グループにコピーしてから編集し、用途がわかる名前を付けてください。これにより、取得元が管理する情報とローカルで管理する情報を区別できます。手動コピーには、サブスクリプションで変更された接続先情報が自動反映されません。定期的に有効性を確認し、コピーした項目が常に使えると考えないでください。

フィルター条件を変更した後は、まず対象のグループだけを更新し、結果メッセージを確認してください。項目が表示されない場合は、フィルターの方向、式、サブスクリプションの応答、ネットワーク接続を順に確認します。取得内容がエラーページ、ログイン画面、利用量の案内であり、解析可能なサーバー一覧ではないこともあります。更新の失敗が正規表現の問題とは限りません。元のグループ情報を残したまま、条件を緩めて再試行してください。既存の設定を上書きするような全件更新を続けて行わないでください。

共有リンクからのインポートとサブスクリプションの更新は、別の仕組みです。クリップボードからインポートするのは、その時点の接続情報です。サブスクリプションURLは、その後の更新に使います。同じサーバーを取り込める場合がありますが、管理方法は異なります。継続的に更新する設定は、取得元が明確なサブスクリプショングループに残してください。一時的なテスト用の共有リンクは、手動グループに入れると整理しやすくなります。QRコードやリンクには接続認証情報が含まれるため、一般的なスクリーンショットのように公開しないでください。

サーバーを選ぶ際は、実際の接続テストも確認してください。TCPポートへの接続が成立しても、確認できるのは通信経路の一部だけです。プロトコルのハンドシェイク、接続先の名前解決、ウェブリクエストの成功までは保証されません。一度の短時間テストを根拠に、多くの項目を恒久的に除外するフィルターは避けましょう。テスト結果の違いについては、TCPing・実接続の遅延・ダウンロード速度測定の違いを参照し、日常利用の選定基準を決めてください。

ルーティングルールの実践：順序・マッチング・アウトバウンド

まず、ルールの対象となるトラフィックを確認する

ルーティングルールが処理するのは、すでにコアに入った接続だけです。アプリがシステムプロキシを使わず、TUNにも取り込まれていない場合、コアのルールを変更しても通信経路は変わりません。「グローバル」プリセットは通常、コアに入ったリクエストを優先的にプロキシのアウトバウンドへ送る設定であり、OS上のすべての通信がプロキシに入るという意味ではありません。ルールを調べる前にアプリの接続入口を確認してください。システムプロキシとルーティングの違いは、システムプロキシとルーティングモードの解説も参考になります。

v2rayNのルーティング設定では、まず既存のプリセットを複製し、そのコピーでルールを追加・削除してください。コアは通常、上から順にルールを確認し、最初に一致したルールでアウトバウンドを決定します。そのため、具体的な例外は広い条件のルールより前に置きます。同じルールでドメインとポートを指定した場合、通常は両方の条件を満たす必要があります。一方、同じドメイン配列内の複数の項目は、どれか一つに一致すれば適用されます。複数の条件を一つのルールに詰め込むと、想定以上に対象が絞られることがあります。

検証しやすいルール順を作る

以下の例では、LAN内のドメインとプライベートIPアドレスを先に処理し、次に特定ドメインを拒否する例、最後にドメインの集合を直接接続する例を示します。routingオブジェクトのみの例です。完全な設定には、directとblockという名前のアウトバウンドと、対応するルールデータが必要です。例で使う予約ドメインは構文の説明用であり、実在するサービスの拒否を意図したものではありません。一致しないリクエストの送信先は、完全な設定によって異なります。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:lan"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

full:はドメインとの完全一致、domain:はドメインとそのサブドメイン、geosite:はドメインの集合、geoip:はIPアドレスの集合を参照します。集合が存在するか、どの範囲を含むかは、実際に読み込まれているデータファイルによります。ルールデータがないと設定の読み込みに失敗したり、ルールが機能しなかったりします。フィールドのつづりが正しいだけで、必要な環境が整っているとは限りません。データ更新後はドメインの分類が変わる可能性があるため、重要な接続先を再検証してください。

geoip:privateが対象にするのは、プライベートアドレスなどの予約済みIPアドレスであり、「すべてのローカルサービス名」ではありません。ドメイン名でルーター、プリンター、社内サービスに接続する場合、コアが接続先IPアドレスをまだ取得していないことがあります。特にAsIsポリシーでは、内部ドメインに明示的なルールが必要です。企業ネットワークでは、一般的なプライベートアドレス範囲に含まれない内部アドレスを使う場合もあります。その際は、直結範囲をむやみに広げず、実際のネットワーク範囲をCIDRで指定してください。

ドメインポリシーとフォールバックを理解する

AsIsは、IPルールのためにすべてのドメインを積極的にIPアドレスへ解決することはありません。IPIfNonMatchは、ドメインルールに一致しなかった場合に名前解決を試み、その後IPアドレスで判定します。IPOnDemandは、IPルールに必要なときに、より積極的に名前解決します。後者の2つはルーティング結果をDNSの結果と結び付けるため、クエリや待ち時間が増えることがあります。ポリシーを選ぶ前に、ルールが主にドメインとIPアドレスのどちらを基準にするか確認してください。積極的な名前解決を、常に有効な性能改善策と考えないでください。

Xrayの完全な設定では、ルーティングルールに一致しない接続は通常、アウトバウンド配列の先頭項目を使用します。クライアントのプリセットがフォールバックルールを追加する場合もあります。そのため、設定の一部だけを見て最終的な既定動作を判断することはできません。最後のルールをフォールバックとして使う場合は、対象とするネットワークや接続先、アウトバウンドを明示し、後続のルールを先に捕捉しないことを確認してください。プリセットを変更したら、名前だけで判断せず、クライアントが生成した設定やルーティングログで実際の順序を確認します。

検証では、重要なルールごとに再現可能なリクエストを選びます。内部サービスは直結、特定ドメインは指定アウトバウンド、それ以外のドメインはフォールバックを確認します。毎回新しい接続を作り、対象ドメイン、解決されたIPアドレス、アウトバウンドのタグを記録してください。ルールが適用されない場合は、「コアに入っているか」「ルールが前方にあるか」「条件をすべて満たしているか」「アウトバウンドのタグが存在するか」の順に確認します。ブラウザーのキャッシュや接続の再利用で変更が見えないことがあります。ページを再読み込みしても、新しいネットワーク接続が作られたとは限りません。

DNS設定の最適化：名前解決とルーティングの連携

DNSリゾルバーと接続先を分けて確認する

1回のアクセスには、OSのDNS、ブラウザーのセキュアDNS、クライアント内蔵のDNS、リモート側での名前解決が関わることがあります。すべてが使われるとは限らず、同じ経路を通るとも限りません。アプリがドメイン名をプロキシに渡す場合、端末側で接続先を事前に解決する必要がないことがあります。アプリが先にIPアドレスを取得してから接続する場合、コアが受け取るのはIPアドレスだけかもしれません。DNSを最適化する前に、「どの層が、どのサーバーへ問い合わせ、クエリがどこを通るか」を確認してください。そうしないと、DNSサーバーを変更しても、実際に使われているリゾルバーは変わらないことがあります。

DNS設定で指定するサーバーアドレスと、DNSクエリを直結またはプロキシ経由のどちらで送るかは別の問題です。コア内のDNSリクエストがルーティング対象になる場合もあれば、特殊なモードで通常の処理を迂回する場合もあります。サーバー側で接続先を名前解決できるかどうかも、端末側で選んだリゾルバーとは別の話です。調査時はクライアントログで、どの層がリクエストを開始したかを確認し、失敗が名前解決と接続のどちらで起きているかを判断します。接続先とのハンドシェイク失敗を、安易にDNS汚染やリゾルバーの障害と決めつけないでください。

小さな範囲から振り分ける

以下はXray内蔵DNSの設定例です。通常のクエリにはパブリックDNSを使い、指定したドメインの集合とLAN内の名前には、LANのリゾルバーを優先します。192.168.1.1でDNSを提供しているネットワークでのみ使えます。設定前に、現在のゲートウェイまたは内部DNSの実際のアドレスに置き換えてください。役割を説明するため一般的なDNSを使っていますが、すべてのネットワークに適した設定ではなく、クエリが暗号化されることを示すものでもありません。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": ["geosite:cn", "domain:lan"],
        "skipFallback": true
      },
      "1.1.1.1"
    ]
  }
}

domainsは、そのサーバーを優先的に使うドメインの範囲を指定します。skipFallbackは、その他のドメインに対する一般的なフォールバック選択からそのサーバーを外すための設定であり、内部ドメインが他のサーバーへ送られないことを単独で保証するものではありません。内部ドメインを確実に分離するには、使用中のコアのフォールバック設定と実際のクエリログも確認してください。内部リゾルバーが応答しない場合は、内部レコードを修正しましょう。関係のないパブリックDNSへ内部の名前情報を送らないよう、安易にフォールバックを追加しないでください。

UseIPv4は設定例であり、すべてのユーザーにIPv6の無効化を勧めるものではありません。ネットワークで安定したIPv6が使える場合は、使用中のコアに適したデュアルスタック設定を選べます。IPv6接続が継続的に失敗する場合にのみ、アドレスファミリーを比較してテストしてください。DNSの応答にIPv6アドレスが含まれていても、アプリやアウトバウンドにIPv6の通信経路がなければ、タイムアウト後に切り替わることがあります。システムのアドレス、デフォルトルート、DNSの応答、プロキシ側の対応を個別に確認し、名前解決結果を一つ削除して済ませないでください。

DNSリクエストが自分自身に戻るループを防ぐ

暗号化DNSでサーバー名にドメインを指定すると、まずそのリゾルバーのドメイン名を解決する必要があります。これがブートストラップDNSの問題です。ブートストラップの処理が、まだ確立されていない同じ暗号化接続に依存すると、ループが発生します。クライアントにブートストラップDNSや静的ホストマッピングの機能がある場合は、使用中のコアの説明に従って設定してください。TUNを有効にした後は、リゾルバーへの接続が同じ入口に誤って戻されないことも確認します。同じクエリと接続の再試行がログに繰り返し記録される場合は、ループを疑ってください。

ドメインによる振り分けとDNSの振り分けでは、同じ方針を保つのがおすすめです。内部業務を直結する場合は、内部ネットワークで有効なアドレスを取得できる必要があります。プロキシ経由で接続する場合は、リモート側から到達できるアドレスかどうかも考慮してください。IPアドレスの集合を使うルールは、名前解決結果に依存します。リゾルバーによって返されるIPアドレスが異なれば、適用されるアウトバウンドも変わる可能性があります。接続経路が頻繁に変わる場合は、まずルーティングのドメインポリシーとDNSサーバーの選択を確認し、すぐにすべてのドメインをIPルールへ追加しないでください。

DNS設定を変更した後は、キャッシュの扱いを明確にしてください。アプリ、OS、コアがそれぞれ応答をキャッシュすることがあり、いずれか一つだけ再起動しても反映されない場合があります。まずアプリの接続を作り直し、次にOSの手順でキャッシュをクリアし、必要に応じてクライアントのコアを再起動してください。ブラウザー独自のセキュアDNSが有効だと、OSのDNS設定を迂回し続けることがあります。検証中は一時的にOSのDNSを使って比較し、原因を確認したら元の設定に戻します。ブラウザー、OS、コアのDNSを同時に変更しないでください。

設定を比較する場合はアプリと接続先を固定し、初回の名前解決、キャッシュが使われるリクエスト、接続を作り直したときの動作をそれぞれ確認してください。リゾルバーを増やしても、必ず速くなるわけではありません。フォールバックを増やしすぎると、経路が不安定になります。まず既定のリゾルバーと必要最小限の例外を決めてから、細かなルールを追加してください。問題が起きた場合は、元のルーティングを維持したまま既定のDNSに戻し、原因が本当に名前解決にあるか確認します。

TUNモード：接続範囲とルートの復旧

TUNが担うのは接続入口であり、接続情報の代わりではない

TUNは仮想ネットワークインターフェースを通じて、OSから渡されたIPトラフィックを受け取り、クライアントに付属するネットワークスタックまたはコアで処理します。システムプロキシに従わないアプリに適していますが、あらゆるプロトコルが同じように動作するとは限りません。一般的なシステムプロキシは、アプリが明示的に送るプロキシ接続を処理します。TUNはシステムルーティング、DNS、仮想インターフェースにも関わります。両者は入口が異なりますが、その後の通信には引き続き有効なサーバーと適切なルーティングルールが必要です。

v2rayNで「TUNモードを有効にする」をオンにする前に、通常のプロキシ方式で接続先へアクセスできることを確認してください。サーバー自体が使えない状態でTUNを追加すると、障害の影響範囲が広がるだけです。クライアントによっては管理者権限、OSのネットワーク拡張の許可、または補助コンポーネントが必要です。表示される指示はプラットフォームやインストール方法によって異なります。画面の案内に従って許可してください。エラーを回避するために、システムの保護機能をむやみに無効にしたり、アプリのフォルダー全体を書き込み可能にしたりしないでください。

まず最小限の通信取り込みをテストする

初回のテストでは、仮想NICを作成したりデフォルトルートを変更したりする他のソフトを終了し、現在のネットワークインターフェースを記録してからTUNを有効にしてください。起動ログでインターフェースの作成が完了したか、OSに対応する仮想インターフェースが表示されるかを確認し、もともとシステムプロキシを使っていないアプリで接続を試します。画面上でスイッチがオンでも、コアが起動していなければ、トラフィックが正しく取り込まれていない可能性があります。スイッチの色だけで判断せず、ログと実際のリクエストを確認してください。

デスクトップクライアントでは、異なるコンポーネントがTUN画面の機能を担う場合があります。Xrayのルーティング設定を汎用TUN設定として使わないでください。まずクライアントの既定テンプレートで基本動作を確認し、その後に除外するネットワーク範囲、DNSの取り込み、ネットワークスタックのオプションを変更します。Android版v2rayNGはOSのVPNインターフェースを使ってアプリの通信を取り込みます。デスクトップとは設定が異なるため、アプリの対象範囲を変更したら接続を作り直して検証してください。

入口での除外とコアでの直結を区別する

入口で除外すると、トラフィックはTUNに入りません。コアのdirectは、トラフィックがコアに入った後で接続先へ直接接続する設定です。どちらもLANにアクセスできる場合がありますが、ログ、DNS、システムルーティングへの影響は異なります。プリンター、ファイル共有、社内サービスに接続する場合は、プロトコルが現在のネットワークスタックで使えるかを確認してから、入口で除外するか、コアで直結するかを決めてください。ウェブページを開けたからといって、LAN内のすべてのデバイス検出プロトコルが使えるとは限りません。

特に注意したいのが、サーバー自身への接続経路です。プロキシのアウトバウンドからサーバーへ送る接続は、実ネットワークへ到達できなければなりません。同じTUN入口に戻され、ループにならないようにしてください。クライアントの既定テンプレートでは、通常、必要な除外やバインドが設定されていますが、カスタムルーティング、複数の仮想インターフェース、外部ネットワークツールによって崩れることがあります。同じサーバーへの接続がログに繰り返し記録される、CPU使用率が異常に高い、接続がすぐにタイムアウトするといった場合は、サーバーを次々と切り替える前に、アウトバウンドのループを確認してください。

システムプロキシとTUNを同時に有効にすることが、必ずしも誤りというわけではありません。ただし、接続入口の切り分けが難しくなります。システムプロキシ経由でローカルポートに入るアプリもあれば、TUNが直接取り込むアプリもあり、問題を調べる際に混同しやすくなります。基準状態を作るときは、まずシステムプロキシを解除し、TUNだけで検証してください。通常のプロキシ方式に戻す場合は、TUNをオフにしてシステムプロキシを有効にします。作業中は各手順を記録し、クライアントを終了した後に停止済みポートを指すシステムプロキシが残らないようにしてください。

スリープからの復帰、Wi-Fiの切り替え、有線接続の追加後は、既定のインターフェースやゲートウェイが変わることがあります。そのタイミングでだけ問題が起きる場合は、まずクライアントの接続を作り直し、インターフェースとDNSがネットワークの変更に追従するか確認してください。復旧の問題を隠すために、通信を取り込む範囲を恒久的に広げないでください。テストを終える際はTUNをオフにして仮想ルートが削除されたことを確認し、クライアントを経由しない方法で基本ネットワークを検証します。問題が残る場合は、OSのネットワーク設定を一つずつ元に戻してください。

FakeDNS：仮想アドレスとドメイン名の復元

仮想アドレスは接続先サーバーのアドレスではない

FakeDNSは、ドメイン名に内部用の仮想アドレスを割り当て、コア内にドメイン名とアドレスの対応を保存します。アプリがそのアドレスを取得して接続すると、対応を読み取れる処理経路にトラフィックが再び入る必要があります。コアがドメイン名を復元し、その後のルーティングを行うためです。ドメイン名の情報を保持できるため、アプリが先に名前解決してから接続するケースに特に適しています。仮想アドレス自体がリモートサービスを提供するわけではなく、通常のネットワーク上でそのまま接続先として使えるものでもありません。

そのため、FakeDNSはDNSサーバーを一つ切り替えるだけで使える機能ではありません。DNS応答、仮想ネットワークの取り込み、マッピングの参照、アウトバウンド処理を連携させる必要があります。アプリに仮想アドレスを返しても、接続が対応するコアに入らなければリクエストはタイムアウトします。DNSに応答するプロセスと接続を処理するプロセスが別で、マッピングを共有していない場合も、ドメイン名を確実に復元できません。設定前にこの経路を図にして確認することは、アドレスプールのサイズを調整するより重要です。

設定例はインバウンドと組み合わせて使う

以下はXray形式の設定例で、仮想アドレスプールとDNSの選択を示しています。TUNによる通信の取り込み、完全なインバウンド、アウトバウンドは含まれないため、単独では動作しません。このアドレス範囲は予約用途ですが、使用前に現在のネットワークや他の仮想インターフェースと競合しないか確認してください。異なるフィールド構造を使うTUNコアに、この設定をそのまま貼り付けないでください。クライアントに完全なFakeDNSテンプレートがある場合は、各項目の整合性を保つため、テンプレートを優先してください。

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

この機能に対応するXrayインバウンドでは、ドメイン名を復元する機能も必要です。以下はインバウンドオブジェクト内のsniffingフィールドだけを示しており、単独で使えるインバウンドではありません。ここでのfakednsは、仮想アドレスのマッピングを使って接続先のドメイン名を復元する処理を指します。あらゆる暗号化プロトコルからアプリケーション層の情報を読み取れるという意味ではありません。他の接続先検出オプションも有効にするかどうかは、実際のプロトコルとコアの動作に応じて決めてください。

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

アドレスプールのサイズは、維持できるマッピング数を決めるものであり、通信速度を決めるものではありません。プールが小さすぎる、同時に扱うドメインが多い、キャッシュの有効期間が長すぎるといった場合、古いマッピングが置き換わることがあります。アプリが古いアドレスを使い続けると、その後の接続で元のドメイン名との対応を失う可能性があります。プールの拡張は対処方法の一つにすぎません。メモリ使用量、アプリのキャッシュ、再接続時の動作も確認してください。偶発的な接続エラーすべてを、アドレスプールの拡張だけで解決しようとしないでください。

実際のアドレスが必要な接続先を例外にする

LAN内の名前、社内の認証サービス、名前解決結果を別のデバイスに渡す必要があるアプリでは、実際のIPアドレスが必要な場合があります。こうしたクエリは、ドメイン名や用途に応じてFakeDNSの対象から外し、適切な内部リゾルバーへ送ってください。例外設定はDNSルールだけで完結しません。ルーティングも一致させる必要があります。実アドレスへのリクエストは正しいアウトバウンドへ送り、仮想アドレスへのリクエストはマッピングを処理できる経路に残してください。同じドメインに実アドレスと仮想アドレスが交互に返される場合は、まずリゾルバーの選択とキャッシュの取得元を確認します。

アプリ独自のセキュアDNSがFakeDNSを迂回する場合もあります。その結果、一部の接続では実アドレスが使われ、別の接続では仮想アドレスが使われるため、動作が一定しないように見えます。検証ではまずDNSの入口を固定し、応答が設定したアドレスプールに含まれるかを確認してから、コアがドメイン名を復元できるか調べてください。仮想アドレスが返されたことだけでは、その後の接続が成功したとは限りません。リクエストが想定したドメインルールに一致し、最終的に実際の接続先へ到達することも確認してください。

安全に元へ戻すには、通常のDNS設定を復元し、コアを再読み込みし、OSとアプリのDNSキャッシュをクリアしてから、接続を再確立します。接続プールを保持しているアプリは、必要に応じて終了してください。仮想アドレスが返されなくなったことを確認した後、通常の名前解決とルーティングを検証します。FakeDNSを有効にした場合に特定のアプリだけ失敗するなら、対象を限定した例外を設けて比較してください。すぐにアドレスプールを拡張したり、すべての通信を直結にしたりしないでください。

FakeDNSを使うかどうかは、ドメイン名が失われて振り分けに支障が出る問題を解決する必要があるかで決まります。ドメイン名による接続が安定し、通常のDNSとルーティングが正しく動作しているなら、現状のままでも構いません。FakeDNSは名前解決と接続の関係を変える仕組みであり、必須の高速化スイッチではありません。処理経路が一貫していること、例外が明確なこと、キャッシュを消去して元に戻せる手順があることが、安定した運用につながります。

複数サブスクリプションの管理：更新・重複整理・デバイス間の移行

まず命名規則と更新ルールを決める

複数のサブスクリプションを使うとき、管理が複雑になる原因は数よりも、取得元と用途が混在することです。取得元ごとにグループを分け、正式利用、短期テスト、手動で保持する項目などを名前で区別しましょう。グループ名は固定し、サーバーの別名は取得元による更新に任せるのがおすすめです。認証情報を含む可能性があり、スクリーンショットやログでも安全に扱いにくいため、サブスクリプションURLをグループ名にしないでください。使用頻度順にグループを並べると、「すべて」の一覧から毎回探す手間を減らせます。

自動更新は、頻繁にするほどよいというものではありません。まず手動更新が正常に動作することを確認してから、適切な更新間隔を設定してください。複数のサブスクリプションを同時に更新すると、ネットワーク接続が確立していない場合や取得元の応答が遅い場合に、エラーが重なりやすくなります。クライアントで個別に更新間隔を設定できる場合は、テスト用と日常用で分けてください。できない場合でも、ネットワークを切り替えた後に基本接続を確認してから一括更新しましょう。

サブスクリプション更新に必要な通信経路を確保する

サブスクリプションの更新は、クライアントの設定によって直結または現在のプロキシ経由で行われます。更新に現在のサーバーが必要なのに、そのサーバーが使えなくなると、管理上の依存ループが発生します。復旧用に、最近の動作確認で使えた設定を一組残すか、取得元が許可するネットワーク環境から直結で更新できるようにしてください。新しい接続情報を取得できる前に最後の使用可能なサーバーを削除しないでください。更新失敗を、サブスクリプション自体が無効になったという意味にすぐ結び付けないでください。

更新に失敗した場合は、接続タイムアウト、応答内容の異常、解析エラーを切り分けます。接続タイムアウトなら通信経路、応答内容に問題があればサブスクリプションデータが返されたか、解析エラーなら形式とクライアントの対応範囲を確認してください。エラーページが正常なHTTP応答として返る場合もあります。「リクエスト完了」は、インポート成功を意味しません。元のグループを残し、エラーの種類を記録してください。同じURLを繰り返し貼り付けるより、原因を調べやすくなります。エラー情報を共有するときは、URLから認証情報を削除してください。

重複の判断は別名だけに頼らない

2つのサブスクリプションに同じサーバーが含まれることもあれば、接続先アドレスが同じでも、認証情報、トランスポート、TLS設定が異なることもあります。重複を整理する際は、接続パラメーター全体を比較し、クライアントの重複判定がどの項目を基準にするか確認してください。別名だけで削除すると、名前が同じでも設定が異なる項目を誤って消すおそれがあります。アドレスだけで削除した場合も、別のサービスを一つにまとめてしまうことがあります。本格的な整理の前にバックアップを取り、まず一つのグループを処理してから、選択中のサーバーが残っていることを確認してください。

サブスクリプション内のサーバーが置き換えられたり削除されたりすると、クライアントで選択していた項目が無効になったり、別の項目が自動選択されたりすることがあります。更新後は、現在のサーバー、ルーティングプリセット、接続状態を確認してください。一覧に項目が残っているだけで、セッションが復旧したと判断しないでください。自動選択がテスト結果に基づく場合は、そのテスト方法が実際の用途に合っているかも確認します。安定した接続経路が必要な場合は、一覧全体を頻繁に並べ替えるより、手動で選ぶ手順を明確にしておく方が問題を特定しやすくなります。

実行環境をむやみにコピーせず、接続情報を移行する

パソコンとスマートフォンで同じサブスクリプションURLを使うと、両方のデバイスが同じ取得元から情報を取得できます。ただし、ルーティング、DNS、アプリの通信を取り込む範囲まで自動的に同期されるわけではありません。v2rayNGやv2flyNGへ移行したら、コアの対応状況、VPNの許可、対象アプリを改めて確認してください。デスクトップのローカルファイルパス、待ち受けポート、TUNテンプレートを別のプラットフォームへそのまま移すこともできません。まず移行先のデバイスで基本接続を確認し、その後に必要な高度なルールを追加します。

完全なバックアップは同じような環境の復元向け、単一サーバーの共有は一時的な移行向け、サブスクリプションURLは継続的な管理向けです。方法を選ぶ際は、取得元が複数デバイスでの利用を許可しているか、デバイス数の制限、更新頻度を考慮してください。バックアップにはサーバー一覧だけでなく、画面設定やローカルパスが含まれることもあります。復元後は、ログの保存先、待ち受けアドレス、起動オプションを確認してください。3つの方法の詳しい比較は、パソコンとスマートフォンで設定を共有する方法をご覧ください。

サブスクリプションURLが誤って公開された場合、スクリーンショットを削除するだけでは古いURLを無効にできません。取得元の管理画面でURLを変更または無効化してから、各デバイスを更新してください。日常の管理記録は認証情報を含めず、グループの用途、フィルターの意図、復旧手順を記録しておくと便利です。デバイスを交換しても、記憶に頼らず管理構成を再構築できます。

カスタムアウトバウンド：タグ・インターフェース・接続経路

アウトバウンドのタグは設定内に実在している必要がある

アウトバウンドは、コアが接続を次の処理へ渡す場所です。direct、block、proxyはよく使われるタグですが、タグは設定内の名前にすぎません。単語があるだけで機能が自動生成されるわけではありません。ルーティングのoutboundTagは、実際に存在するアウトバウンドオブジェクトに対応させる必要があります。directというタグに別のプロトコルを設定すれば、名前を変えただけで動作が直結に変わるわけではありません。カスタム設定を読むときは、タグ、プロトコル、パラメーターを合わせて確認してください。

以下はXrayのアウトバウンドを2つ定義する例です。一方はFreedomプロトコルで接続先へ直接接続し、もう一方はBlackholeプロトコルで接続を拒否します。ルーティング先の説明用であり、リモートのプロキシサーバーは含みません。直結アウトバウンドが配列の先頭にあるため、一致するルールがない場合、完全な設定では直結になる可能性があります。既存の設定に統合する際は、順序を必ず確認してください。クライアントが生成したアウトバウンド配列をそのまま置き換えないでください。

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

リモートプロキシのアウトバウンドには、サーバー情報、認証情報、トランスポート設定、安全性に関するパラメーターが必要です。このページでは、架空のサーバー設定を提供しません。実際の設定はインポート済みの接続情報から生成し、クライアントが対応するルーティングまたはカスタム設定欄から参照してください。クライアントがproxyタグを自動生成する場合は、確認せずに同じ名前のオブジェクトを追加しないでください。タグの重複は設定エラーや予期しない選択につながることがあります。用途ごとに、明確で重複のない名前を使ってください。

接続が何段階のプロキシを経由するかを明確にする

複数のアウトバウンドを並べても、通常は複数の選択肢になるだけで、接続経路が自動的につながるわけではありません。ルーティングでアウトバウンドを一つ選ぶと、通常、リクエストはそのアウトバウンドが処理します。あるプロキシのアウトバウンドを別のアウトバウンド経由で接続するには、使用中のコアが対応する転送機能または接続チェーンの設定が必要です。関連するフィールドはコアによって異なるため、異なる形式の設定を混在させないでください。変更前に、アプリ、ローカルインバウンド、第1ホップ、次のホップ、接続先を図にして、各段階の役割を確認しましょう。

接続チェーンを使っても、必ず性能が向上するとは限りません。ハンドシェイクや障害箇所が増え、問題の切り分けが難しくなります。また、DNSをどの段階で実行するかが変わる場合もあります。第1ホップに接続できなければ、その後の設定が正しくても接続できません。まず各アウトバウンドを個別に検証してから、組み合わせた経路をテストしてください。ログでは、プロキシサーバーへの接続失敗と、プロキシ経由で接続先へつなぐ際の失敗を区別します。一般的なTCP接続が成功しても、UDPや他のトランスポートが同様に使えるとは限りません。実際の用途ごとに検証してください。

カスタムのローカルアウトバウンドと待ち受け範囲

リクエストをローカルの別のプロキシソフトに渡す場合は、相手側の待ち受けアドレス、ポート、プロトコルを確認してください。SOCKSとHTTPプロキシは同じものではありません。また、2つのプログラムが同じアドレスとポートの組み合わせで待ち受けることはできません。ローカルサービスへの接続には、まずループバックアドレスを使用してください。LAN内のデバイスから使う必要がある場合に限って待ち受け範囲を広げ、ファイアウォールとアクセス制御も確認します。待ち受けを公開しても、自動で認証が有効になるわけではありません。

アウトバウンドをネットワークインターフェースやローカルアドレスにバインドする設定は、複数のネットワークを明確に使い分ける場合に適していますが、環境を移したときに動作しにくくなります。Wi-Fiの切り替え、有線接続の切断、スリープ後に、バインド先が存在しなくなる場合があります。特定の出口に固定する必要があり、その設定を維持できる場合を除き、まずOS標準のルーティングを使う方が復旧しやすくなります。TUN環境では、バインドによって仮想入口を迂回できるか確認し、アウトバウンド接続が自身へ戻るループを防いでください。インターフェース設定を変更した後は、現在の接続だけでなく、切断後の再接続もテストします。

カスタムアウトバウンドは、特定ドメインに一致するルールを一つ作り、テスト対象だけを新しいタグへ送るところから検証できます。それ以外のリクエストは既存のプリセットのままにします。コアの起動、タグの存在、ルールの一致、接続先へのリクエスト成功を確認してから、対象範囲を広げてください。ログに未知のアウトバウンドと表示される場合は、つづりと、クライアントによる設定の上書きがないかを確認します。アウトバウンドが存在しても接続がタイムアウトする場合は、ローカルの待ち受け、リモートへの到達性、トランスポートの対応状況を調べてください。設定を読み込めたことは最初の確認にすぎません。リクエスト全体の成功が最終的な検証結果です。

日常利用では、多段のカスタム接続を長期的に管理することより、復旧に使える標準設定を維持する方が重要です。新しいサーバーを追加する場合は、まずクライアントのダウンロードで使用するクライアントを確認し、使い方ガイドに沿って基本接続を確立してください。標準の設定では要件を満たせない場合に限り、カスタムアウトバウンドを追加します。設定の意図、重要なタグ、元に戻す方法を記録しておけば、次回の変更も明確な基準から始められます。