v2rayN 詳細設定ガイド

01 基本設定と検証の順序

詳細設定を始める前に、正常に使える状態を保存しておきましょう。選択中のサーバーで実際にWebページを開けることを確認し、所属するグループ、システムプロキシの状態、ルーティング設定名、コアの種類、TUNの有効・無効を記録します。サブスクリプションのURLやサーバーの認証情報を記録する必要はありません。これらを把握しておけば、その後の変更がどのレイヤーに影響したかを判断でき、設定に失敗したときも元の状態に戻せます。

クライアント、コア、システムの通信制御を切り分ける

v2rayNは画面操作、サブスクリプション管理、設定生成を担い、実際の接続は選択したコアが処理します。システムプロキシは、その設定に従うアプリからの通信をローカルの接続先へ渡す仕組みであり、それ自体がトンネルになるわけではありません。TUNはより低いレイヤーでネットワークパケットを受け取りますが、適切なルーティングとアウトバウンドが必要です。画面に「実行中」と表示されても、プロセスの起動が確認できるだけで、名前解決、サーバーとのハンドシェイク、接続先へのアクセスがすべて成功したとは限りません。

まず「設定」でローカルの待ち受けポートと現在のコアを確認してください。チュートリアルのスクリーンショットからポート番号を推測しないでください。ブラウザーで独立したプロキシ拡張機能を使っている場合は、一時的にシステム設定に従うよう統一します。アプリに独自のプロキシ設定がある場合は、システム側の設定を上書きしていないかも確認してください。同じPC上に複数の通信経路があると、あるページは開けても別のページは開けないことがあります。その場合、ルーティングルールが不安定だと誤解しやすくなります。

範囲を絞って検証してから、通信の制御範囲を広げる

まずTUNを無効にし、「システムプロキシ → システムプロキシを自動設定」のみを使い、シンプルなルーティング設定を残して検証することをおすすめします。一般のドメインのページ、LAN内のアドレス、実際に使うアプリの順にアクセスしてください。Webページのテストでは、キャッシュ済みのタブを再読み込みするだけでなく、ページを開き直します。LANのテストには、自宅のルーターの管理画面などを使えます。他人のネットワークのサブネットをそのまま使ったり、インターネット上の公開サービスをLAN内の接続先として扱ったりしないでください。

テスト結果には「どのアプリで、どの種類の接続先にアクセスし、どのようなエラーが出たか」を記録します。たとえば、ドメインのページは開けないがLAN内の管理画面にはアクセスできるなら、すべてのネットワークインターフェースから調べる必要はありません。特定のアプリだけ失敗する場合は、独自のプロキシ設定や暗号化DNSを使っていないかを先に確認してください。エラーが起きた時刻も記録しておくと、ログから該当する接続を見つけやすくなり、大量の履歴から原因を推測せずに済みます。

理由を説明できる項目を一度に一つだけ変更する

変更するたびに保存し、画面の案内に従って設定を再読み込みするか、サービスを再起動してください。サーバーの設定、DNS、TUNの設定を変更しても、既存の接続は以前の経路を使い続けることがあります。検証時は対象アプリの接続をいったん終了し、新しいリクエストを開始してください。サーバーの変更、FakeDNSの有効化、ルーティング設定一式の読み込みを同時に行うのは避けましょう。接続が回復しても、どの変更が効いたのか分からず、ほかの変更が問題を残していないかも判断できません。

ログを読むときは、起動時のエラーとリクエスト処理中のエラーを区別してください。設定を解析できない、待ち受けアドレスが使用中といった問題はサービスの起動段階で発生します。接続タイムアウト、名前解決の失敗、リモート側からの拒否はリクエスト処理中の問題です。前者は設定の構造を戻すか、ポートの競合を解消します。後者は接続入口、名前解決、ルール、アウトバウンドの順に確認してください。詳細ログは再現時だけ一時的に有効にし、調査後は通常のレベルに戻して、ログが増え続けないようにします。

基本的な接続がまだ成功しない場合は、先に設定ガイドに戻り、基本手順を完了してください。インストーラーやプラットフォームの選び方はクライアントのダウンロードで確認できます。現象の原因をすぐに調べたい場合はよくある質問をご覧ください。この章で紹介した記録方法は、以降の章でも役立ちます。まず変化したレイヤーを確認し、次の対応を選んでください。すべてのスイッチを順番に試す必要はありません。

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

サブスクリプショングループはサーバーの提供元を管理するものであり、通信を振り分ける設定ではありません。グループごとにサブスクリプションを割り当てたり、手動で追加したサーバーをまとめたりできます。グループ名を変更しても、サーバーの接続パラメーターは変わりません。用途や提供元が分かる名前を付けましょう。たとえば「メイン」「予備」「手動設定」などです。名前にサブスクリプションキーを含めたり、メモにURL全体を記載したりしないでください。スクリーンショットで認証情報が漏れるおそれがあります。

グループを確認してから更新する

「サブスクリプショングループ → サブスクリプショングループ設定」を開き、対象グループのURL、有効・無効の状態、利用できる絞り込みオプションを確認します。保存後、「サブスクリプショングループ」メニューから更新を実行し、選択中のグループだけが対象か、すべてのグループが対象かを確認してください。グループが複数ある場合、画面に表示されているグループと更新対象が一致するとは限りません。更新後は完了メッセージだけで判断せず、対象グループに戻って登録内容の変化を確認します。

サブスクリプションのURLは通常、サーバー一覧を取得するためのネットワークアドレスです。一方、共有リンクは単一の接続設定を表します。共有リンクをサブスクリプションのURL欄に入力しても、更新機能で処理できるとは限りません。クリップボードにある単一のリンクは「サーバー」メニューから該当するインポート機能で追加し、サブスクリプション提供元のURLはグループ設定に入力してください。違いについては共有リンクとサブスクリプションURLの違いもご覧ください。

表示の絞り込みと更新時のフィルターは別の機能

メイン画面の検索やグループ選択は、通常、表示範囲を絞るだけで、サーバーの記録自体は削除されません。一方、グループ設定のフィルター条件は、更新時に残すサーバーを決める場合があります。「更新後にサーバーがなくなった」ときは、まずメイン画面の検索欄を空にし、次に選択中のグループを確認し、最後に更新フィルターを調べてください。この順に確認すれば、一時的に非表示になった記録を、サブスクリプションの解析失敗と取り違えずに済みます。

ビルドによっては、名称による絞り込みや正規表現を使える場合があります。正規表現に対応すると明記された項目に限り、式を入力してください。通常のテキストフィルターでは、括弧や縦棒が正規表現として扱われないことがあります。正規表現のHK|JPはどちらかの文字列に一致し、^(HK|JP)-は指定した接頭辞で始まる名前に一致します。まず少数の既知の名称で動作を確認してから範囲を広げてください。大文字・小文字、空白、全角文字の違いによって、対象の記録がすべて除外される場合があります。

^(HK|JP)-

上の式は名称の接頭辞に一致させる例であり、実際の所在地を示したり、速度の速いサーバーを自動選択したりするものではありません。提供元が命名形式を変えると、既存のフィルター条件が機能しなくなることがあります。名称に地域名が含まれていても、実際の出口の所在地とは限りません。残すサーバーは提供元の説明と利用目的に基づいて判断してください。複雑なフィルターを接続品質の測定に使ったり、一度のテスト結果だけでグループ全体の記録を削除したりしないでください。

フィルターの問題はデータの流れに沿って調べる

更新処理を「取得」「解析」「絞り込み」「表示」の4段階に分けて確認します。取得に失敗する場合はURLの有効性と更新時のネットワーク経路を確認してください。解析に失敗する場合は、取得内容がサブスクリプションデータではなく、ログイン画面や期限切れのお知らせではないかを確認します。解析は成功しているのに一覧が空ならフィルター条件を、一覧に記録があるのに見えない場合は検索条件とグループを確認してください。段階によって対処は異なります。何度も更新ボタンを押しても、通常、新しい情報は得られません。

手動で追加した記録は、専用のグループに分けておくと管理しやすくなります。サブスクリプションの更新では、その提供元のサーバー一覧が作り直されることがあります。サブスクリプション由来の記録の名前や接続パラメーターを直接変更すると、次回更新で上書きされる場合があります。ローカルで修正する必要がある場合は、手動管理グループにコピーし、変更理由を記録してください。コピーしても独立した記録になるだけで、期限切れの認証情報が再び有効になったり、提供元側の設定変更が反映されたりするわけではありません。

サーバー一覧が復旧したら、選択中のサーバーが有効な記録を指しているか確認してください。サブスクリプションの更新で元の記録が削除または置き換えられると、以前の選択が使えなくなることがあります。サーバーを選び直し、実際に接続できることを確認してください。詳しい対処手順はサブスクリプション更新失敗時の確認手順をご覧ください。グループを整理してからルーティングを設定すると、「サーバーの選択ミス」と「ルールによる出口の誤り」を切り分けやすくなります。

03 ルーティングルールと照合順序

ルーティングルールは、コアに届いたリクエストをどのアウトバウンドで処理するかを決めます。アプリの通信をクライアントへ取り込む機能ではありません。システムプロキシを使わず、TUNにも入っていないアプリは、ドメインルールを追加してもそのルールに従って通信するようにはなりません。変更する前に、第1章の手順で通信が取り込まれる経路を確認してください。その後「設定」からルーティング設定を開き、現在の設定を複製して試します。いつでも切り替えられるよう、元の設定も残しておきましょう。

対象を決めてから出口を指定する

ルールはドメイン、接続先アドレス、ポート、入口などの条件で照合できます。同じXrayのルール内に複数の異なる条件を指定した場合、通常はすべてを満たす必要があります。同一の一覧にある複数のドメインは、いずれかに一致すれば対象になります。ドメイン条件とアドレス条件を同じルールに書いても、「どちらか一方を満たせば直結」という意味にはなりません。条件の組み合わせ方が分からない場合は、ルールを2つに分けるとログを読みやすく、適用範囲の重なりも調べやすくなります。

ルールは上から順に評価され、最初に一致したルールで接続先が決まります。そのため、個別の例外は広い範囲に適用するルールより上に、最後に適用する条件は下に置いてください。たとえば、特定の内部ドメインを直結するルールは、すべてのドメインをプロキシ経由にするルールより先に置きます。ルールを追加しても変化がない場合は、上にあるルールがすでに一致していないかを確認してください。すぐに保存失敗を疑う必要はありません。インターフェース上の並び順も設定の一部です。インポート後は順序を確認してください。

ドメイン解決ポリシーの適用条件を理解する

domainStrategyは、ルーティングの照合中にドメインをいつアドレス解決するかを制御します。クライアント全体のDNSを有効・無効にする設定ではありません。AsIsは照合時にドメインをそのまま使います。IPIfNonMatchはドメインルールに一致しなかった場合に解決を試し、その後アドレスルールを照合します。IPOnDemandはアドレス情報が必要な照合で解決します。利用できる値は使用中のコアの対応状況を確認してください。別のコア向けの設定をそのまま流用できるとは限りません。

以下は、Xray設定におけるLAN向け直結の例です。routingフィールドだけを示しており、設定内にdirectというタグのアウトバウンドがあり、必要なルールデータが読み込まれていることを前提としています。完全なクライアント設定としてインポートせず、既存設定の該当箇所に統合してください。ドメインルールとアドレスルールを分けて書くと、ドメインとアドレスのどちらに一致したかを区別できます。

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

geosite:privateとgeoip:privateを使うには、コアから読み込めるルールデータが必要です。すべての実行環境に固定のリストとして組み込まれているわけではありません。ログにデータファイルがないと表示された場合は、クライアントが管理するルールリソースを利用できるか確認してください。自分の内部ドメインには明示的なドメインルールを、実際のLAN内のサブネットには対応するアドレス範囲を設定すると、無関係なネットワークまで直結せずに済みます。

範囲を広げる前に、対象を絞ったルールで検証する

ドメインの指定方法によって照合範囲が変わります。Xrayではfull:example.comはドメイン全体に一致し、domain:example.comはそのドメインとサブドメインに一致します。正規表現を使う場合は、その式の意味も理解しておく必要があります。無関係なドメインまで多数一致する可能性のあるキーワードを使い、単一のサイトを対象にするのは避けてください。初回の検証では完全一致のドメインを指定し、出口が正しいことを確認してから、必要に応じてサブドメインまで範囲を広げます。

検証では新しいリクエストを開始し、対応するアウトバウンドタグを確認してください。1つのWebページでも複数のドメインへアクセスするため、メインページが直結しても、画像、ログインAPI、メディアが同じ経路を使うとは限りません。一部だけ読み込めない場合は、ルール表全体を単一の出口に変更せず、実際に失敗した接続先を一つずつ確認します。ログにドメインではなくアドレスだけが表示される場合は、アプリ自身が先に名前解決していないか、ドメインを特定するための情報が利用できるかも調べてください。

ルーティングの変更後は、一般のWebページ、LAN内サービス、プロキシが必要な接続先をそれぞれテストしてください。テスト結果の意味も区別しましょう。サーバーへのTcpingが成功しても、ルールが適用されることや接続先の利用まで確認できたとは限りません。詳しくは遅延テスト結果の見方をご覧ください。複数のルールを重ねて互いに上書きするより、シンプルで説明しやすいルールを保つほうが管理しやすくなります。

04 DNSの名前解決経路と設定の見直し

DNSの問題は、解析サーバーを一つ選べば解決するとは限りません。ブラウザー、OS、プロキシコア、リモートサーバーのいずれも名前解決に関わる可能性があります。まず「どのコンポーネントが、どのドメインを解決しているか」を確認してください。ブラウザー独自の暗号化DNSが有効なら、システムのDNS設定が影響しない場合があります。ドメイン名をプロキシ経由で送る場合は、ローカルで接続先のアドレスを先に取得する必要がないこともあります。名前解決と接続の場所を同じ経路図に整理してから設定しましょう。

サーバーのドメインと接続先のドメインを区別する

プロキシサーバー自体をドメイン名で指定している場合、接続を確立する前にそのアドレスを取得する必要があります。この名前解決を、まだ確立していない同じプロキシ経路に依存させることはできません。接続先サイトのドメインは、設定に応じてローカルのコアまたはリモート側で解決できます。よくある循環依存は、DNSリクエストをプロキシ経由にする一方で、プロキシサーバーのドメイン解決にも同じDNSを必要とする状態です。起動後にすべてのリクエストが止まる場合は、タイムアウトを延ばすだけでなく、この依存関係を確認してください。

「設定」でDNS関連の設定を開き、現在のコアと編集可能な項目を確認してください。v2rayNでは、コアごとに異なるDNS設定を管理している場合があります。項目名が似ていても設定構造が同じとは限りません。組み込みテンプレートを使う場合は、基本構造を保ち、必要な上流サーバーやルールだけを変更します。インターネット上のJSONで設定全体を置き換えると、クライアントが生成するローカル待ち受け、ルーティングとの関連付け、TUNに必要な設定が失われることがあります。

ネットワーク環境に合わせて名前解決の方式を選ぶ

以下はXray内蔵DNSの設定例で、アドレス形式の上流サーバーを使い、serversとqueryStrategyの位置を示しています。この上流サーバーに直接接続できるかは、ローカルのネットワーク環境によって異なります。また、この例だけでOSのすべてのDNSリクエストがコアへ転送されるわけではありません。実際の設定では、信頼できるDNSサービス、ネットワーク要件、ルーティング設定全体を考慮してください。例をそのまま最適な設定として使わないでください。

{
  "dns": {
    "servers": ["1.1.1.1"],
    "queryStrategy": "UseIP"
  }
}

UseIPでは2種類のアドレスを取得できますが、特定のアドレスファミリーだけを問い合わせると、接続先までの経路に影響します。ローカルで利用できるネットワークがないのに、使えない種類のアドレスが先に返ると、初回アクセスが待ち時間の後に成功する場合があります。逆に別の種類だけに制限すると、特定のネットワークを必要とするサービスに接続できなくなることがあります。問い合わせ範囲を絞る前に、実際のインターフェース、デフォルトルート、接続先の対応状況を確認してください。

通常のDNS、暗号化DNS、プロキシ経由の通信は、それぞれ別の概念です。暗号化DNSは名前解決の通信を保護しますが、Webサイトへの接続に使う出口までは決めません。DNSサーバーのアドレスを一覧に登録しただけで、必ずプロキシ経由で問い合わせるとも限りません。暗号化された上流サーバーを使う場合は、そのサーバーのドメインをどう解決し、どの経路で接続するかも考慮します。DNSの上流サーバー、DNSリクエストのアウトバウンド、接続先へのリクエストのアウトバウンドをまとめて確認してください。

内部ドメインと一般のドメインを分けて扱う

企業や家庭の内部ドメインは、ローカルのDNSサーバーでしか解決できない場合があります。すべてをパブリックDNSに任せると、該当なしと返されたり、内部ネットワークとは無関係の結果が返されたりすることがあります。明確な内部ドメインには、ローカルから到達できるDNS経路を設定し、LANへの直結ルールも残してください。プリンターや機器の検出にLAN内の名前解決方式が使われている場合は、パブリックDNSの変更だけでは解決できません。

DNSの変更を検証するときは、複数レイヤーのキャッシュを考慮してください。OS、ブラウザー、コアがそれぞれ結果を保持している場合があります。古い接続を閉じ、関連アプリを再起動してから再テストしてください。必要に応じて、OSのキャッシュ削除機能も利用します。システムの検索ツールに表示される結果は、その問い合わせで使われた名前解決経路の結果です。プロキシコアが使う結果と一致するとは限りません。比較テストでは、どの方法で問い合わせた結果かを必ず記録してください。

設定を見直す際は、内部ドメインを正しく解決する、不要なアドレスファミリーの試行を減らす、名前解決の依存関係を解消するなど、明確な目標を決めてください。あるWebページが一度速く開いただけでDNS設定全体を切り替えると、キャッシュの違いを設定の効果と誤解することがあります。変更のたびに同じアプリ、接続先、通信の取り込み方を使い、ログの名前解決エラーが実際に解消したか確認してください。

05 TUNモードとシステムの通信制御

TUNは仮想ネットワークインターフェースでシステムのネットワークパケットを受け取ります。システムプロキシに従わないアプリの通信も取り込みたい場合に利用できます。「接続を強化する」ボタンではなく、無効なサーバー設定を直す機能でもありません。有効にする前に、システムプロキシで基本的な接続を検証し、現在のネットワークインターフェース、ほかのトンネルソフト、LANへのアクセス状況を記録してください。問題が起きたとき、元の接続経路の障害か、システムの通信制御を追加したことによる経路変更かを判断しやすくなります。

まず権限とインターフェースを確認する

v2rayNのメイン画面で「Tunを有効にする」を探し、「設定」でTUN関連の項目を確認してから、クライアントの案内に従って起動してください。Windowsでは管理者権限や対応サービスが必要な場合があります。macOSやLinuxでも、システムの許可やインターフェースの操作権限が関わることがあります。別のプラットフォーム向けのドライバー手順を流用しないでください。インストール方法とプラットフォームの説明はクライアントのダウンロードをご覧ください。必要な依存関係は使用中のビルドの案内に従ってください。

有効にした後、ログでインターフェースとルートが正常に作成されたかを確認してください。権限不足、インターフェースの作成失敗、デバイスの使用中といったエラーが出た場合は、Webサイトへの接続を試す前に起動時の問題を解決します。通信がまだコアに届いていない可能性があるため、この段階でサーバーを何度も切り替えても効果はありません。インターフェースが正常に作成されたのにすべての接続が失敗する場合は、デフォルトルート、DNS、サーバーアドレスが正しいインターフェースから送信されているかを調べます。

複数の通信制御機能で経路を取り合わないようにする

ほかのVPN、仮想マシンのネットワーク、コンテナブリッジ、セキュリティソフトも、インターフェースの優先順位やルーティングを変えることがあります。調査中は、複数の全通信を制御する仕組みを同時に動かさないでください。一時的に不要なものを終了してからTUNを再度有効にします。併用が必要な環境では、どの接続先がどのルートを通るのかを個別に明確にしてください。タスクバーのアイコンだけでは終了を確認できません。必要に応じて、OSのネットワーク設定でインターフェースとルートを確認します。

設定によってはシステムプロキシとTUNを併用できますが、初回の検証ではどちらか一方だけを使うのがおすすめです。両方を使うと、ブラウザーのリクエストが最初にローカルプロキシへ送られ、その後システムルーティングで処理されるなど、経路を把握しにくくなります。完全な通信経路を理解していない場合、ローカルのプロキシポートを別レイヤーのプロキシ上流として設定しないでください。誤った転送設定は接続のループやリソースの消費を引き起こします。

LANと名前解決を合わせて検証する

TUNを有効にした後は、ルーターの管理画面、LAN内の共有リソース、内部業務ドメインをテストしてください。アクセスできない原因は、接続先アドレスが誤ってプロキシへ送られていることや、内部ドメインがパブリックDNSで解決されていることなどが考えられます。前者はLAN向けのアドレスルールとシステム側の除外ルートを、後者はDNSの章を確認してください。特定の機器の問題を直すために、アドレス範囲全体を直結にしないでください。実際のサブネットと接続先アドレスを確認し、例外の範囲を説明できる状態に保ちましょう。

デフォルトルートをTUNで制御する場合は、プロキシ接続が仮想インターフェースに戻ってしまわないようにする必要があります。通常、クライアントが保護用のルールを作成しますが、複数のネットワークカード、ネットワークの切り替え、カスタム設定によって条件が変わることがあります。有効にした直後にサーバーへの接続がタイムアウトし、TUNを無効にすると回復する場合は、サーバーへの通信に使う出口と実際のネットワークインターフェースを重点的に確認してください。まずクライアントの標準TUN設定に戻して検証し、その後でカスタム項目を一つずつ戻します。

モバイル端末の通信制御は、デスクトップの仮想インターフェースと完全に同じ仕組みではありません。v2rayNGとv2flyNGはAndroidの接続許可機能を使います。同種のアプリが同じ機能を使用中の場合、競合することがあります。バックグラウンドの省電力制限によって接続が切れる場合もあります。アプリごとのプロキシ設定は、どのアプリを通信制御の対象にするかを決めるもので、デスクトップのルーティングルールとは異なります。許可設定やバックグラウンド設定の詳細はAndroidの接続許可とアプリごとのプロキシ設定をご覧ください。

無効にした後、システムが元の状態に戻ったか確認する

検証が終わったら、通常の手順でTUNを無効にし、インターフェース、ルート、名前解決が元に戻るか確認してください。クライアントが異常終了してネットワークが復旧しない場合は、クライアントを再起動して正常に通信制御を停止し、システムプロキシの設定が残っていないかを確認します。必要に応じてOSのネットワーク設定から元の状態に戻してください。用途の分からないインターフェースやルートを直接削除しないでください。Wi-Fiの切り替えやスリープからの復帰後も、実際のインターフェースが変わると以前の通信制御が機能しなくなることがあるため、再テストしてください。

TUNの検証では、少なくとも4点を確認します。従来どおりWebページを開けること、システムプロキシに従わないアプリが接続できること、LANへのアクセスが想定どおりであること、通信制御を無効にすると通常のネットワークが復旧することです。一つでも失敗した場合は、動作が確認できている基本設定に戻し、インターフェース、ルーティング、DNS、アウトバウンドの順に調べてください。この順序を守ると、低レイヤーの設定を何度も変更するより、再現可能な原因を見つけやすくなります。

06 FakeDNSとドメインのマッピング

FakeDNSはドメインの問い合わせに対し、専用アドレスプール内の合成アドレスを返し、そのアドレスとドメインの対応を記録します。アプリがそのアドレスに接続すると、通信を取り込む仕組みが対応関係からドメインを復元します。主な目的は、後続のルーティングでドメイン情報を保持することです。Webサイトに新たな実アドレスを割り当てたり、接続できないサーバーを接続可能にしたりする機能ではありません。最終的な接続は、適切なアウトバウンドで処理する必要があります。

同じ通信経路の中でマッピングを完結させる

FakeDNSを利用するには、少なくとも3つの段階が連携している必要があります。問い合わせが実際に合成アドレスを返すDNSへ届くこと、返されたアドレスがシステムのルーティングによって通信制御側へ戻ること、接続処理中にコアが対応するドメインを復元できることです。スイッチを一つだけ有効にすると、アプリが合成アドレスを受け取っても、通常のネットワークから接続してしまう場合があります。問い合わせ結果にアドレスプールの範囲が表示されただけで、正常に動作していると判断せず、経路全体を確認してください。

XrayのFakeDNSと、ほかのコアが使う合成アドレス機能では設定構造が異なります。v2rayNのTUNは、現在のプロキシ接続で使うコアとは別のコンポーネントを使う場合があります。メイン画面で選択したサーバーのコアから、TUNの設定も同じ構文だと推測しないでください。まずどのレイヤーの設定を編集しているかを確認し、クライアントに対応するテンプレートがあるか調べます。対応する画面上の項目が用意されている場合は、それを使って必要な設定を生成してください。

アドレスプールと容量の設定を理解する

以下はXrayのトップレベルにあるfakednsフィールドの例で、アドレスプールと容量の指定方法を示しています。198.18.0.0/15は特殊用途のアドレス範囲で、一般のWebサイトが使用する実アドレスではありません。この例にはDNSの問い合わせ先、通信の取り込み、ドメインの復元に必要な設定が含まれていないため、単独では動作するクライアント設定になりません。統合する前に、自分のネットワークでこの範囲を内部業務に使っていないことを確認してください。

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

ipPoolは割り当て可能なアドレス範囲を指定し、poolSizeはマッピングプールの容量を設定します。容量を増やしても一般的な高速化にはならず、リモート側の帯域も変わりません。マッピングの維持に必要なリソースと、保持できる件数に影響します。長時間にわたって多くの異なるドメインへアクセスする環境では、実際の動作を確認し、根拠なく極端に大きな値を設定しないでください。アドレスプールを変更すると、アプリにキャッシュ済みの古い結果にも影響します。

互換性の問題は、経路の迂回やキャッシュで起きやすい

アプリによっては暗号化DNSを独自に使うため、問い合わせがFakeDNSを経由せず、その後に実アドレスへ直接接続する場合があります。また、名前解決の結果を通信制御を経由しない子プロセスに渡すアプリでは、合成アドレスからドメインを復元できないことがあります。特殊用途のアドレス範囲を受け付けないアプリもあります。その場合はアドレスプールを何度も変更するのではなく、対象のアプリやドメインで実際のDNS解決を使うようにし、ルーティングの例外も確認してください。

内部ドメインでは特に慎重に設定してください。ローカル機器へのアクセスに使うドメインが合成アドレスに置き換えられ、不適切なプロキシ出口へ送られると、LANにアクセスできなくなります。内部ドメインに実アドレスが必要か、ローカルDNSが応答しているかを確認してから、該当する除外設定を行ってください。合成アドレスの除外、DNSの上流サーバー選択、LANへの直結はそれぞれ異なるレイヤーです。一つだけ変更すれば残りも自動的に連動すると考えないでください。

比較テストで必要性を判断する

検証では同じサーバー、ルーティング設定、アプリを使い、通常の名前解決とFakeDNSを比較してください。ドメインルールが安定して適用されるか、接続先にアクセスできるか、LANが正常に使えるかを確認します。ページの読み込み時間を一度比較するだけでは不十分です。キャッシュ、接続の再利用、サーバー負荷によって結果が変わる場合があります。明確な問題を解決できず、互換性のための例外だけが増えるなら、通常の名前解決を使うほうが管理しやすいでしょう。

ログでは合成アドレス自体より、ドメインを復元できるか、アウトバウンドの選択が想定どおりかを確認してください。マッピング情報は実行中の状態として保持される場合があり、コアを再起動した後も以前のマッピングが残るとは限りません。アプリが古い結果を長時間保持すると、再起動後に初めて接続が失敗することがあります。まずアプリに再度名前解決させてから、設定を変更する必要があるか判断してください。

通常のDNS、TUN、ルーティングが安定してからFakeDNSを導入してください。この順番なら、問題が起きても追加したレイヤーだけを戻せます。使用中のビルドに対応する明確な設定画面がなく、必要な設定一式の説明もない場合は、別のコア向けの設定例を無理にテンプレートへ追加しないでください。説明できる実際の名前解決経路を維持し、明確な必要性がある場合にだけ試してください。

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

複数のサブスクリプションを使う場合は、提供元を追跡できること、更新範囲を制御できること、問題の影響を切り分けられることが重要です。すべてのサーバーを提供元が分からない一つのグループにコピーしないでください。一覧は統一されて見えますが、更新に失敗したときにどの記録が無効になったか分かりにくくなります。提供元ごとにグループを分け、手動設定用のグループも別に用意しましょう。メモには用途と管理上の注意だけを記載し、URLは専用の項目に保存します。

更新対象と更新時の通信経路を個別に設定する

まず現在のグループだけを更新するのか、すべてのグループを更新するのかを決め、クライアントが提供する更新方法を選択します。提供元によっては直接接続で取得できるものもあれば、利用可能なプロキシを経由する必要があるものもあります。これはサブスクリプションを取得するリクエストの通信経路を決めるもので、更新後のサーバーのデフォルトルートを決める設定ではありません。更新方法を切り替える前に、取得に使う現在の接続が有効であることを確認してください。更新に新しいサーバーが必要なのに、そのサーバーを取得するには旧サーバーが必要という循環が起こりえます。

メインのサブスクリプションが無効で、更新にもその中の選択中サーバーが必要な場合は、接続を検証済みの予備サーバーに切り替えるか、提供元が許可する方法で直接取得してください。まだ検証していない記録を復旧手段として使わないでください。少なくとも一つは単独で接続を確認できる代替手段を残し、提供元と利用条件を記録します。代替手段の価値は依存関係を減らすことにあります。似た名前のサーバーを増やすことではありません。

頻繁な更新と重複インポートを避ける

サブスクリプションの更新は、接続を再試行するボタンではありません。提供元に変更がなければ、何度更新しても同じ設定を取得するだけでなく、提供元側で頻度制限がかかることもあります。自動更新の間隔は提供元の説明と実際の更新頻度に合わせ、手動更新は設定変更を確認するときに行います。接続に失敗したら、まずエラーの種類を確認してください。認証の失効、リモート側のタイムアウト、サブスクリプションの取得失敗は別の問題であり、同じ更新操作で解決できるとは限りません。

同じ提供元を複数回追加すると、一覧に重複した記録が表示されることがあります。整理する前に、グループのURLが同じか、用途ごとに異なる絞り込み条件を使っているか、選択中のサーバーがどのグループに属しているかを確認してください。表示名が同じでも、サーバーアドレス、通信方式、認証パラメーターが異なる場合があります。表示名だけで一括削除せず、まず正常に使える記録を残してから、グループごとに整理します。

手動修正を独立して管理する

サブスクリプションの記録は提供元によって管理され、更新時にローカルの変更が上書きされる場合があります。通信パラメーター、サーバーアドレス、表示用のメモを修正する必要がある場合は、まず手動管理グループにコピーし、何を修正したか記録してください。その後、提供元が設定を変更しても手動コピーには反映されないことがあります。定期的に提供元の説明と照らし合わせてください。手動コピーとサブスクリプションの記録を分ければ、変更の上書きを防げるだけでなく、ローカルで管理する責任があることも分かります。

一連の管理作業は順序を決めて進めます。現在の設定をバックアップし、一つの提供元を更新して、取得した記録が妥当か確認します。次に選択中のサーバーを検証し、最後にほかのグループを処理してください。すべての提供元を更新した直後に一括で重複を削除したり、フィルターやルーティングを変更したりしないでください。作業を分けておけば、ある提供元から予期しない内容が返ってきても、どの操作が変更の原因かを特定でき、サーバー一覧全体が不明な状態になるのを防げます。

予備のサーバーがあっても自動で切り替わるとは限らない

グループ内に複数の記録があっても、クライアントが自動的に利用可能なサーバーを選ぶとは限りません。現在選択中のサーバー、ルーティングで指定された出口、選択ポリシーがある場合はその動作を、それぞれ確認してください。接続テストの結果がハンドシェイクの成功だけを示し、実際の接続先にアクセスできることまでは確認できない場合があります。ダウンロード速度も特定の時間帯の実測値にすぎません。テスト方法の違いはTcpingと実接続の遅延テストの違いをご覧ください。

管理後は、グループごとの更新結果、保留したグループ、選択中サーバーの再検証結果、手動コピーの確認要否を簡潔に記録してください。状態だけを記録し、機密情報は書き写さないでください。次回問題が起きたとき、一覧を最初から整理せず、前回確認した状態から調査を再開できます。更新に失敗した場合は、取得、解析、絞り込み、表示の4段階に分けて対処します。サブスクリプションが増えても、この手順は変わりません。

08 カスタムアウトバウンドと設定の復元

カスタムアウトバウンドは、グラフィカルな画面の選択肢では表現できず、管理者が通信経路全体を説明できる場合に適しています。まず、特定の接続先に専用の直結出口を用意するのか、より複雑な転送経路が必要なのかを明確にします。単一のドメインを直結するだけなら、設定全体を置き換えず、ルーティングエディターを使ってください。カスタム設定で自由度が上がる一方、項目の互換性、タグの参照、更新後の管理は利用者自身が担うことになります。

まず設定の管理元を確認する

v2rayNでは、通常のサーバー記録はクライアントが実行用の設定を生成します。一方、カスタム設定では元の構造がより多く保持されることがあり、両者の画面連携が同じだとは限りません。「サーバー」メニューからカスタム設定関連の項目を使う前に、完全なファイルをインポートするのか、既存ファイルを参照するのかを確認し、対応するコアを選んでください。ファイルをインポートできても、現在のコアがすべての項目に対応しているとは限りません。

編集前に動作確認済みのファイルを複製し、コピー上で作業してください。XrayとV2Flyには共通する概念がありますが、具体的なフィールドと拡張機能はそれぞれ確認が必要です。ほかのコアのアウトバウンド種別やルーティング構造も、そのまま入れ替えられるとは限りません。まずトップレベルの項目、インバウンドの待ち受け、アウトバウンドのタグを確認してから、新しい機能を追加します。クライアントが生成する入口を最初に置き換えると、システムプロキシが古いポートを参照したままになり、クライアント全体が使えなくなる場合があります。

最小限の例でタグの参照を確認する

以下のXray設定例では、直結アウトバウンドと拒否アウトバウンドを定義し、例示したドメインを拒否側へ送ります。outboundsとroutingだけを示しており、ローカルの待ち受けは含まないため、完全な実行設定ではありません。統合時は既存のプロキシ用アウトバウンドと必要なルールを残し、同名タグを重複させないでください。これは参照関係を説明する例であり、実際に使うドメインを拒否する必要はありません。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "reject",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "reject"
      }
    ]
  }
}

outboundTagはアウトバウンドのtagと完全に一致させる必要があります。画面上の表示名とタグは別のものです。大文字・小文字やスペルが違うだけでも参照が機能しなくなることがあります。一般的なXray設定では、どのルールにも一致しない通信は最初のアウトバウンドを使うため、配列の順序を変えるとデフォルトの動作も変わる可能性があります。設定例を統合するときは、新しいルールだけでなく、元のデフォルト出口が維持されているかも確認してください。

複雑な転送は依存関係を整理してから設定する

複数段階の転送が必要な場合は、ローカルの入口、最初の接続先、その後の接続、最終的な接続先の関係を文章で整理してから設定してください。各サーバーのドメインをどこで解決し、それぞれの接続をどのアウトバウンドで確立するのか、個別に説明できる必要があります。コアによって転送経路を設定する項目は異なるため、「上流プロキシ」という言葉だけを根拠に設定を流用しないでください。経路の途中が自身の接続に依存すると、接続が再帰したり起動できなくなったりするおそれがあります。

設定ファイルは、まずJSON構文、次にコアの仕様を確認してください。JSONではコメントと末尾の余分なカンマは使えません。文字列内のバックスラッシュと二重引用符も正しく処理する必要があります。構文が正しくても、未対応の項目、存在しないタグ、ルールデータの不足などが原因で失敗する場合があります。クライアントログに表示される最初の有効なエラーを確認し、まず起動失敗の原因を修正してから、その後の接続情報を調べてください。エラーが繰り返し表示され、原因を見失わないようにします。

元に戻せることを完了条件にする

起動に成功したら、まず最小限の接続先をテストし、次に以前から使えていた一般の接続とLAN内の接続を確認してください。ログには、想定したアウトバウンドが使われたことが分かる情報が必要です。エラーが表示されないことだけでは不十分です。カスタム設定で元の設定を置き換えた場合は、システムプロキシやTUNを無効にした後もローカルポートが残っていないか確認してください。元の設定へ戻す手順を明確にしておき、いくつかのスイッチを覚えていることに頼らないでください。

クライアントの更新やコアの変更後は、カスタム項目とデフォルト動作を改めて検証してください。動作確認済みの設定を残してから、コピー上で移行します。唯一の設定に新しいテンプレートを直接重ねないでください。ルーティング、DNS、グループ管理の画面で要件を実現できる場合は、クライアント管理の設定に戻すことで、手動で同期する内容を減らせます。カスタム設定は明確な要件を満たすために使い、設定の保守自体を目的にしないでください。

このページの確認順は、そのままトラブルシューティングの順序になります。まずサーバーと通信の入口を確認し、次にルーティングと名前解決、最後にTUN、FakeDNS、カスタム経路を調べてください。基本操作はクイックスタートガイド、よくある現象はよくある質問、クライアントの選び方とインストール方法はダウンロードページをご覧ください。動作確認済みの状態を一つ残しておけば、次の変更を確実に比較できます。