V2Ray 詳細設定：サブスクリプション・ルーティング・DNS・出力先

設定の基準：再現可能な動作状態を先に固定する

最小構成の通信経路を作る

詳細設定の出発点は、すべての項目を有効にすることではなく、繰り返し検証できる最小構成を作ることです。まず、動作確認済みのサブスクリプションを1つ、サーバーを1台、デフォルトルーティングとクライアント標準DNSだけを残し、LAN共有、TUN、FakeDNS、追加の出力先は無効にします。デスクトップでは v2rayN でサーバーを選択してシステムプロキシを有効にします。Androidでは v2rayNG または v2flyNGで同様のサーバーを選び、接続を確立します。この段階で確認するのは3点だけです。クライアントコアが起動すること、ブラウザーのリクエストが想定した出口を通ること、ローカルネットワークのリソースに引き続きアクセスできることです。どれか1つでも満たさない場合は、ルーティングルールを追加せず、サブスクリプション設定またはサーバー状態に戻って確認します。

基準設定には明確な記録を残します。使用中のクライアント、利用するコアの系統、サブスクリプショングループ名、稼働中のサーバー名、システムプロキシのモード、リモートDNSの有効・無効を記録してください。目的は複雑な台帳を長期管理することではなく、変更後に「どの設定が変わったか」を正確に確認できるようにすることです。クライアントがサブスクリプションを更新するとサーバーオブジェクトは上書きされる場合がありますが、手動で変更したグローバルルーティングまでは通常復元されません。サブスクリプションの状態とグローバル設定は分けて確認します。

4つの設定レイヤーを分ける

動作するV2Ray GUIクライアントの設定は、通常4つのレイヤーで構成されます。第1層はサーバーオブジェクトで、アドレス、ポート、ユーザー識別子、通信方式、安全性に関するパラメーターを保持します。第2層はサブスクリプションとグループで、サーバーの更新、表示、絞り込み方法を決めます。第3層はローカルへの取り込み方法で、システムプロキシとTUNが含まれます。第4層はコア設定で、DNS、ルーティング、インバウンド、アウトバウンドを含みます。サーバーに接続できることは第1層が基本的に正しいことを示すだけで、DNSやルーティングが想定どおりとは限りません。逆にブラウザーでページを開けなくても、必ずしもサーバー障害とは限りません。システムプロキシが対象アプリを取り込んでいない、DNSが不適切な結果を返している、ルールが通信を誤った出口へ送っている、といった原因でも似た症状が起こります。

バックアップ、命名、ロールバック

変更前に、クライアントが提供する設定のエクスポートまたはバックアップ機能で現在の状態を保存します。ファイル名には用途を記入してください。たとえば「デフォルトルーティング」「TUNテスト前」「2つのサブスクリプション統合前」などです。複数の検証目的を1つのバックアップ名に詰め込まないでください。クライアントがルーティング設定プロファイルに対応している場合は、既存のプロファイルを複製して編集します。グローバル設定しか扱えない場合は、まずコア設定のテキストをコピーします。ロールバック時はシステムプロキシの状態も確認してください。設定ファイルを復元しても、OS側のプロキシスイッチまでは戻らないことがあります。

名前は感情的な判断ではなく用途を表すものにします。「仕事は直結優先」「グローバルプロキシのテスト」「ローカルドメインを保持」のような名前は、「設定1」「最速設定」より管理しやすくなります。サーバー名には、サブスクリプション提供元の地域、プロトコル、倍率などの元情報を残し、フィルタリングルールは安定した項目を基準に作成します。リスト番号には依存しないでください。サブスクリプション更新後に並び順が変わる可能性があるためです。ルーティングと出力先には、direct、proxy、block、dns-outのような固定ラベルを使うと、ルール参照のミスを減らせます。

ログで設定の反映を確認する

変更するたびにコアを再読み込みし、設定解析エラー、ポート競合、権限不足、DNSリクエスト失敗がログに出ていないか確認します。ログレベルはまず情報レベルを使い、具体的な問題を調べるときだけ一時的にデバッグレベルへ切り替えます。完了後は元に戻し、大量の接続詳細で重要なイベントが埋もれないようにします。読むときは最後の行から推測せず、最初に出たエラーから確認します。failed to parse configが出た場合は、JSONのカンマ、フィールド階層、ラベル参照を確認してください。コアは起動したのにリクエストがタイムアウトする場合は、サーバー、DNS、ルーティングへ進みます。

基準設定の検証が終わったら、設定を1部コピーして次の章へ進みます。以降も同じ原則を使います。まず目的を定め、1つのレイヤーだけ変更し、再読み込みし、ログと実際のアクセス結果で確認し、失敗したら戻します。具体的なエラー文を確認するときは、V2Rayの実行ログを読む方法も併用して段階的に切り分け、クライアントを何度も再インストールしないでください。

サブスクリプショングループとサーバーフィルタリング：ノードを手動削除せずリストを制御する

サブスクリプションの提供元と表示ビューを分ける

サブスクリプションはサーバーオブジェクトを提供し、グループは選択しやすい表示ビューに整理します。この2つを同じレイヤーとして扱わないでください。不要なサーバーを直接削除するのは簡単ですが、次回の更新で再び表示されることが多くあります。安定した方法は、完全なサブスクリプションを保持し、グループ、メモ、フィルター条件で表示範囲を制御することです。v2rayNはデスクトップで多数のサーバーをサブスクリプショングループごとに管理するのに向いています。v2rayNGとv2flyNGは、モバイルで候補を絞り、スクロールや誤選択の負担を減らす使い方に適しています。

グループを作るときは、まず提供元で分け、次に用途別のフィルタービューを作ります。たとえば「メイン購読」「予備購読」は提供元を、「日常利用」「低倍率」「指定プロトコル」は用途を表します。提供元グループは更新と障害の切り分けに使い、用途フィルターは実際のサーバー選択に使います。異なる提供元にまったく同じ名前を付けないでください。更新に失敗したとき、影響範囲を判断できなくなります。手動追加したサーバーは独立したグループに入れ、サブスクリプション更新時に手動オブジェクトまで同期されると誤解しないようにします。

保守しやすいフィルター式を設計する

サーバーフィルタリングは通常、名前に含まれる地域、プロトコル、倍率、用途ラベルを基準に行います。まずサブスクリプション名の安定した構造を確認してから、包含・除外ルールを作成します。名前が「地域｜プロトコル｜倍率」の形式で統一されているならキーワードを組み合わせられます。区切り文字が頻繁に変わる場合は、安定した語だけに依存してください。正規表現は同義の名前をまとめる場合に便利ですが、短く保ちます。「香港またはシンガポール」を絞り込むなら香港|HK|シンガポール|SG、テストや期限切れの項目を除外するならテスト|期限切れ|残り通信量を使えます。包含ルールと除外ルールを同時に使う場合は、クライアントの実行順を先に確認します。一般的には、まず包含項目を残し、その結果から除外項目を取り除きます。

包含：
香港|HK|シンガポール|SG

除外：
テスト|期限切れ|残り通信量|公式サイト

プロトコルの優先設定：
VLESS|VMess|Trojan

倍率フィルター：
(^|[^0-9])1(\.0)?x([^0-9]|$)

倍率フィルターは特に誤マッチしやすい項目です。1という文字だけで検索すると、ポート番号、番号、あるいは「1.5x」まで同時に一致する可能性があります。できるだけ境界を限定してください。サブスクリプションの命名が統一されていない場合、倍率フィルターを料金や契約内容の判断材料にしないでください。まず提供元の情報を確認し、名前フィルターはリスト整理の道具として使います。地域フィルターも名前上のラベルを表すだけで、実際のネットワーク経路と同じ意味ではありません。サーバー選択では、実接続テスト、プロトコル互換性、実際のアクセス状況も確認します。詳しくは遅延・倍率・地域でサーバーを絞り込む方法を参照してください。

並べ替え、テスト、選択の役割を分ける

リストの並べ替えは候補を絞るために使い、遅延テストは接続できない項目を除外するために使います。最終的な選択は、実際に利用する通信で判断してください。基本遅延は測定先の応答だけを示し、ページ読み込み、長時間接続、大容量ファイル転送を完全に表すものではありません。実接続の遅延はコアがプロキシ接続を確立するまでの時間に近いものの、測定先やその時点のネットワーク状態にも左右されます。正しい流れは、まずフィルターで候補を少数に絞り、次に実接続テストを行い、最後に実際のアプリで確認することです。1回のテスト結果をグループ名に固定してはいけません。

自動並べ替え後も、検証済みで安定したサーバーを1台、復旧用として残します。常に先頭である必要はありませんが、分かりやすいメモを付けてください。サブスクリプションを頻繁に更新する場合は、並べ替えの範囲を現在のグループに限定し、異なる提供元や用途のサーバーが混在しないようにします。グループが突然空になったら、まずフィルターを無効にして元のリストを確認します。元のリストが存在するならフィルター条件が合わなくなっただけです。元のリストも空の場合に、サブスクリプション更新を確認します。

同名サーバーと重複オブジェクトを処理する

複数のサブスクリプションが同名のサーバーを提供することがあります。表示名だけで同一と判断しないでください。アドレス、ポート、ユーザー識別子、トランスポートパラメーター、提供元のいずれかが異なれば、別のオブジェクトとして扱います。クライアントの重複除去機能が完全な設定で判定するなら、通常は安全に使えます。表示名だけで判定する場合は、有効な候補まで誤って削除する可能性があります。より安全なのは、グループ側で提供元情報を保持し、表示名のプレフィックスで区別する方法です。サブスクリプション内のコアパラメーターを直接変更しないでください。

フィルタールールは定期的に逆方向から確認します。除外項目に正常なサーバーが混ざっていないか、未分類項目に新しい命名形式が現れていないかを確認してください。サブスクリプション更新のたびに全面的な見直しをする必要はありません。包含、除外、未一致の3つの集合を抜き打ちで確認すれば十分です。これによりリストを整理しながら、厳しすぎる式で利用可能なサーバーを失うことも防げます。

複数購読の管理：更新の分離、優先順位、障害時の切り替え

メイン購読と予備購読の役割を決める

複数購読とは、すべてのサーバーを1つのリストに詰め込むことではなく、提供元ごとに明確な役割を割り当てることです。メイン購読は日常の選択に使い、予備購読はメインの更新失敗、プロトコル非互換、特定地域の利用不能時だけ有効にします。手動グループには、長期固定または一時テストのオブジェクトを保存します。役割を明確にすれば、更新の問題が全リストに波及しません。v2rayNではサブスクリプショングループごとに更新し、結果を確認できます。モバイルでは有効にする購読数を抑え、更新のたびに巨大なサーバーリストを再構築しないようにします。

各サブスクリプションに個別のメモを残し、使用するフィルター条件も記録します。同じグループ内で「提供元」と「用途」の命名ルールを混在させないでください。たとえば「メイン購読」「予備購読」は提供元、「オフィス」「ストリーミングテスト」は用途です。横断的に管理する場合は、元のオブジェクトを移動するのではなく、提供元グループからフィルタービューを作って候補を生成します。これなら更新後にビューを再計算でき、提供元ごとの境界も保てます。

更新順序と失敗時の処理を決める

サブスクリプションは提供元ごとに順番に更新します。まずメイン購読を更新し、返された内容を解析できること、サーバー数に異常な変化がないこと、以前の安定したオブジェクトが残っていることを確認してから、予備購読を更新します。すべてを一括更新すると操作は減りますが、どのURL、内容形式、ネットワーク経路で失敗したか分かりにくくなります。更新成功と表示されたのにリストが空なら、フィルターですべて除外されていないか確認します。解析失敗と表示された場合は、古いリストを保持し、サブスクリプションURLと返却形式を確認してください。先にローカルデータを消去しないでください。

更新失敗は3種類に分けます。リクエストが完了しない、内容は返ったが解析できない、解析は成功したが結果が想定と違う、の3つです。リクエスト未完了ではネットワーク、システムプロキシ、サブスクリプションURLから確認します。解析失敗では内容形式とクライアント互換性を重点的に確認します。結果の異常では更新前後の名前とグループを比較します。予備購読は接続能力を維持するためだけに使い、メイン購読を自動で上書きしないでください。メインが復旧したら通常の順序で戻し、2つの提供元が同時に頻繁に変化しないようにします。

自動更新の範囲を管理する

自動更新は安定した提供元に向いていますが、サーバーの自動選択と結び付けて、確認できないブラックボックスにしてはいけません。サブスクリプションの内容が変わると、新しいオブジェクトが並べ替えによって先頭に表示されることがあります。さらにクライアントが先頭項目を自動選択すると、明示的な操作なしに実際の出口が変わります。より安全な設定は、定期更新を許可しつつ現在のアクティブサーバーを保持し、現在のオブジェクトが無効になったときだけ手動で切り替える方法です。高い安定性が必要な環境では更新頻度を下げ、更新前に設定をエクスポートします。

複数の端末で同じサブスクリプションを使う場合、リストを完全に同じにする必要はありません。デスクトップではテスト用に多くの地域やプロトコルを残し、Androidではよく使う候補だけに絞れます。設定同期で重視すべきなのは、リストの順番ではなく、グループのロジック、ルーティング先、DNSポリシーです。クライアントごとにサブスクリプション項目、ルーティング画面、コアオプションの表示方法は異なります。データディレクトリ全体を無理にコピーすると、プラットフォーム固有の設定まで持ち込む可能性があります。

サブスクリプション内容がグローバル設定を汚染しないようにする

サブスクリプション更新の理想的な範囲は、サーバーオブジェクトの更新に限り、グローバルDNS、ルーティング、ローカルインバウンドを上書きしないことです。クライアントに「サブスクリプション更新時に追加設定を読み込む」機能がある場合は、有効にする前にどのレイヤーが変更されるか理解してください。提供元不明のルーティングテンプレートはデフォルト出口を変更する可能性があり、リモートDNS設定が検証済みの名前解決経路を置き換えることもあります。安定運用では、グローバルルールをローカル設定プロファイルに保存し、サブスクリプションはサーバーだけを提供する構成がおすすめです。

手動サーバーも分離して管理します。手動オブジェクトは独立したグループに入れ、明確なメモを付け、サブスクリプション由来に見せないでください。手動オブジェクトを変更するときは、まず複製して編集し、元のオブジェクトを復旧用に残します。2つの設定がトランスポートパラメーターだけ異なる場合は、「WSテスト」「gRPCテスト」のように差分を名前へ記載し、「予備1」「予備2」だけにしないでください。こうした情報が後のログ調査に直結します。

制御可能なフェイルオーバーを実行する

切り替える前に、問題が本当に現在のサーバーにあるのか、DNSやローカル取り込みにあるのかを確認します。予備サーバーを選んだらコアを再読み込みし、ログでアクティブなアウトバウンドを確認してから、同じ対象へのアクセスをテストします。切り替えに成功したら原因を記録し、元のオブジェクトをすぐに削除しないでください。ネットワーク経路が復旧した後、比較対象として必要になります。メイン購読の全オブジェクトが失敗し、予備購読だけ正常なら、メイン側で共通するプロトコルやトランスポート条件を優先的に確認します。両方の提供元が同時に失敗する場合は、システムプロキシ、TUN、DNS、ローカルネットワークのレイヤーに戻って調査します。

複数購読の整理が終わったら、1分以内に4つの質問へ答えられる状態にします。現在のサーバーはどの購読由来か、更新に失敗したときはどの予備グループを使うか、どのフィルターがサーバーを隠すか、グローバルルーティングは購読から独立しているか、です。大量のリストを探さないと答えられない場合は、グループ名や役割がまだ不明確です。複雑なルーティング設定へ進む前に整理してください。

ルーティングルールの実践：マッチ順序で通信の出口を決める

インバウンドからアウトバウンドまでの判定を理解する

ルーティングルールが処理するのは、すでにコアへ入った接続です。アプリはまずシステムプロキシ、TUN、またはローカルプロキシポートを通ってインバウンドへ入り、コアがドメイン、対象IP、ポート、ネットワーク種別、プロセス、インバウンドラベルを読み取り、ルールの順番に従ってアウトバウンドを選択します。ルーティングは、まだクライアントに入っていない通信を取り込めず、誤ったサーバーパラメーターも修正できません。設定前に、アプリのリクエストがコアのログへ届いていることを確認してから、直結、プロキシ、ブロックのどれを通すか検討します。

ルールは通常、上から下へ順番に照合し、マッチすると以降のルールへ進みません。具体的な条件を前に置き、広い条件を後ろに置き、最後にデフォルト出力先で未一致の通信を受けます。一般的な基準は、プライベートアドレスを直結、ローカルドメインとIPセットを直結、明確にプロキシが必要なドメインをプロキシへ送り、その他は現在のポリシーに従ってデフォルト出口へ送る構成です。「すべてのドメインをプロキシ」が1行目にあると、後続の直結ルールは実行されません。

ドメイン判定ポリシーを選ぶ

ルーティングのドメイン判定ポリシーは、IPルールとの照合前にコアがドメインをIPへ解決するタイミングを決めます。AsIsではドメインリクエストを優先してドメインルールで判定し、ルーティングのために能動的な名前解決は行いません。IPIfNonMatchではドメインルールに一致しなかった場合に解決し、IPルールを試します。IPOnDemandでは、後続にIPが必要な判定があれば名前解決が発生する可能性があります。一般的な設定はIPIfNonMatchから始めると、ドメインルールとIPセットを両立できます。ただしDNSが安定した結果を返せることを確認してください。

能動的な名前解決を行うと、ルーティングとDNSが密接に結び付きます。DNSの返答が安定しない場合や、異なる経路によって別の地域へ割り当てられる場合、IPルールの結果も変わります。そのため、明確なドメインセットで表現できる対象にはドメインルールを優先し、対象アドレスによる判定が本当に必要な場合だけIPルールに頼ります。ログでルール結果が想定と異なるときは、元のドメイン、解決後のIP、最終アウトバウンドラベルを同時に確認します。

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

ドメイン、IP、ポート、インバウンド条件を組み合わせる

同じルール内の異なるフィールドは通常「すべて満たす」条件として処理され、同じフィールド内の複数値は通常「いずれかに一致」として処理されます。たとえばnetwork: tcpとport: 80,443を同時に指定すると、TCPの80番または443番ポートだけを処理します。ドメイン配列に複数のセットを入れた場合は、いずれかのセットに一致すればマッチします。関係のない対象を1つのルールに詰め込まず、用途を明記して複数のルールへ分けたほうが調査しやすくなります。

インバウンドラベルは、異なるローカル入口に別々のポリシーを設定するのに向いています。たとえばブラウザーにはローカルSOCKSインバウンド、業務ソフトには別のHTTPインバウンドを使い、それぞれをプロキシまたは直結へ振り分けられます。プロセスルールはクライアント、コア、OS権限の対応状況に左右され、プラットフォームによって挙動が完全には一致しません。細かな振り分けの補助として使い、唯一の判断材料にはしないでください。ポートルールは明確なサービスに適していますが、最新のアプリは別ポートやQUICを使うこともあり、ポートだけでアプリ種別を推測するとマッチ漏れが起こりやすくなります。

3層のルール構造を作る

第1層では、リモートプロキシへ送れないローカル対象、たとえばループバック、LAN、プライベートアドレスを処理します。第2層では、指定ドメインの直結、特定ドメインのプロキシ、広告や既知のリスク対象のブロックなど、業務上の例外を処理します。第3層でデフォルト出口を定義します。各層の内部では具体的な条件から広い条件へ並べます。ルールを変更したら、直結、プロキシ、デフォルト経路をそれぞれ通る3つのテスト対象で順序を確認し、注目している1つのルールだけを検証しないでください。

ブロックルールは説明可能な状態に保ちます。アプリの起動に問題がある場合は、まずブロックルールを一時的に無効にして確認し、すぐにサーバー障害と判断しないでください。UDPルールにも注意が必要です。UDP全体をブロックすると、DNS、リアルタイム通信、QUICベースの接続に影響する可能性があります。特定ドメインをTCPへフォールバックさせたいだけなら、対象アプリまたはコアのトランスポート設定で処理するのが優先です。LANアクセスでは、プライベートアドレスの直結とTUNのバイパス範囲も併せて確認します。

ログでルールのマッチを確認する

検証時は、まずログを消去するか時刻の目印を付けてから、1回だけリクエストを送ります。どのインバウンドに入ったか、認識されたドメインまたはIP、マッチしたルール、最終アウトバウンドを確認します。ログにIPしか表示されずドメインがない場合、アプリが自分で名前解決している可能性があり、ドメインルールでは直接マッチできません。その場合は、TUNのドメインスニッフィング、FakeDNS、信頼できるIPルールの追加を検討します。ルールが正しくマッチしているのに接続できない場合は、該当するアウトバウンドまたはサーバーの問題です。

ルーティングを保守するうえで重要なのはルール数ではありません。各ルールに説明可能な目的、安定したデータソース、明確なフォールバックがあることです。四半期ごと、またはサブスクリプションの構造が変わったときに、無効なドメイン、重複セット、永遠にマッチしない下位ルールを確認します。「一部のアプリは正常だが、一部は失敗する」場合は、同じインバウンドに入っているか、同じDNSを使っているか、同じアウトバウンドにマッチしているかを比較し、該当する障害分岐をヘルプセンターで確認してください。

DNS設定の最適化：名前解決経路とルーティング基準を統一する

まず1回の名前解決経路を図にする

DNSの問題はサーバーの問題と誤認されがちです。ドメインへのアクセスでは、アプリ自身の名前解決、OSの名前解決、クライアント内蔵DNS、リモート名前解決のうち、1つまたは複数の層を通ることがあります。ブラウザーが独自の暗号化DNSを有効にしていると、システム設定を迂回する可能性があります。TUNで取り込んだ後は、システムの問い合わせがコアへ渡されることがあります。FakeDNSではローカルに合成アドレスを返し、実際の名前解決を後回しにします。最適化の前に、誰が問い合わせを発行し、どのサーバーへ入り、結果がどこでルーティングに使われるかを確認してください。

基本設定では、できるだけ1本の主経路を作ります。通常のアプリはシステムへ問い合わせを渡し、システムの問い合わせはクライアントが取り込みます。コアはドメインセットに応じてローカルまたはリモートDNSを選び、接続とルーティングの両方で使える結果を返します。アプリが自分で名前解決し、IPだけをクライアントへ渡す場合、コアは元のドメイン情報を失い、ドメインベースの振り分け能力が低下します。その場合はアプリの設定を統一するか、TUN環境でスニッフィングとFakeDNSを使ってドメインとの関連を復元します。

ドメインセットでDNSサーバーを選ぶ

DNSの振り分けと通信の振り分けは、同じ方向性を保つ必要があります。直結する予定のローカルドメインは、ローカルから到達しやすいDNSへ優先的に送り、プロキシする予定のドメインは、プロキシ出力先からアクセスするリモートDNSへ送ります。これにより、名前解決結果と実際の出口が合わなくなる事態を減らせます。すべての問い合わせを複数サーバーへ送り、最速の応答を採用するだけの設定は避けてください。最速の返答がルーティング意図に最適とは限らず、並列問い合わせは結果の不確実性を高めます。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": ["geosite:geolocation-!cn"]
      },
      "223.5.5.5"
    ]
  }
}

例では、まずgeosite:cnにローカルDNSを割り当て、expectIPsで返されるアドレス範囲を制限します。その他の明確な非ローカルドメインは暗号化DNSへ送り、最後の項目を未一致の問い合わせに対するフォールバックにします。実際には、利用地域のネットワークから安定してアクセスできるDNSを選び、例のアドレスを機械的に残さないでください。リモートDNSへプロキシ経由でアクセスする場合は、そのドメインやIPを自分自身の名前解決時に参照してループしないようにします。

問い合わせポリシーとアドレスファミリーを選ぶ

UseIPv4はIPv4アドレスだけを要求し、ローカルでIPv6が使えない環境やルーティングが未整備の環境に適しています。UseIPv6はIPv6だけを要求し、UseIPは両方のアドレスファミリーを許可します。選択は、ローカル回線、プロキシ出力先、対象サービスの3者が共通して対応できるかで判断してください。いずれか1層でもIPv6を安定して運べない場合、IPv6を強制すると「名前解決はできるのに接続がタイムアウトする」状態になる可能性があります。逆にネットワークと出力先が対応しているのにIPv6を長期的に無効にすると、利用可能な経路を失います。

判断基準は、システムにIPv6アドレスが割り当てられているかではありません。ローカル直結、プロキシ出力、DNSの返答を個別にテストします。ログで到達できないIPv6を先に試してIPv4へフォールバックしている場合、ページの初回表示が遅くなります。まず一時的にUseIPv4を使って確認し、その後IPv6ルーティングを整えます。アドレスファミリーとドメイン振り分けを同時に変更しないでください。どの変更が改善につながったか分からなくなります。

DNSループと漏洩経路を避ける

DNSループは、「DNSサーバー自身のドメインを解決するために、同じDNSをもう一度呼び出す」場合に起こります。対策として、そのサーバーに直接使えるIPを指定する、hostsで導入用アドレスを固定する、独立したブートストラップリゾルバーを設定する方法があります。DNS出力先が通常のプロキシ入口へルーティングされ、再びDNSを呼び出す場合もループが発生します。DNS問い合わせ専用の出力先ラベルを作り、ルーティングで優先的に処理すれば、経路を一方向に保てます。

{
  "dns": {
    "hosts": {
      "resolver.example": "192.0.2.53"
    },
    "servers": [
      {
        "address": "https://resolver.example/dns-query",
        "skipFallback": true
      }
    ]
  }
}

例にある予約アドレスはフィールドの関係を説明するためだけのものです。実際の設定では、利用する名前解決サービスが明示しているアドレスへ必ず置き換えてください。漏洩経路は設定の目的から判断します。あるドメイン群をリモートDNSで解決する予定なのに、アプリ自身やシステムの別インターフェースが直接問い合わせていれば、経路が逸脱しています。確認時はクライアントのDNSログとシステムのネットワーク活動を同時に観察し、Webテストの結果だけに頼らないでください。

キャッシュ、更新、障害の切り分け

DNSを変更しても古いキャッシュが結果に影響する場合があります。まずクライアントのコアを再読み込みし、テスト対象のアプリを終了して再起動します。必要に応じてOSのキャッシュも更新してください。Windowsではターミナルでipconfig /flushdnsを実行します。systemd-resolvedを使うLinuxではresolvectl flush-cachesを実行できます。macOSとAndroidのキャッシュ動作はシステムやネットワーク状態によって変わるため、ネットワークインターフェースを切り替えるか、クライアント接続を再確立すると更新されることがあります。これらのコマンドで消去できるのはシステムキャッシュで、ブラウザー内部のキャッシュまで消えるとは限りません。

ipconfig /flushdns

resolvectl flush-caches

調査の順序を固定します。まず明示的なDNSツールで問い合わせが返るかを確認し、次に返されたアドレスファミリーを確認します。その後、ルーティングがそのアドレスをどう処理するか、最後に該当する出力先への接続を確認します。1つのドメインだけ失敗するなら、ドメインルール、キャッシュ、サーバー応答を確認します。すべてのドメインが失敗するのにIPへの直接アクセスが正常なら、DNSインバウンド、サーバーアドレス、ルーティングループを重点的に確認します。ドメインもIPも失敗する場合は、取り込みと出力先のレイヤーへ戻ります。

TUNモード：システムプロキシを読まないアプリを取り込む

本当にTUNが必要か判断する

システムプロキシが影響するのは、プロキシ設定を自動的に読み取るアプリだけです。コマンドラインツール、一部のデスクトップソフト、ゲーム、独自のネットワークスタックを持つプログラムは、直接接続することがあります。その場合、クライアントのログにリクエストが現れません。TUNモードは仮想ネットワークインターフェースを通じて、より多くのシステム通信を取り込めます。統一した振り分けが必要な場面に適していますが、同時にルーティングテーブル、DNSハイジャック、権限、バイパスルールなどの変数も増えます。ブラウザーや普段使うデスクトップソフトがシステムプロキシで正常に動作しているなら、「設定を完全にする」ためだけにTUNを有効にする必要はありません。

有効にする前に、前章までの基準を完了します。サーバーが使えること、ルーティングルールを説明できること、DNSが安定して解決できることを確認してください。仮想インターフェースを作成したりデフォルトルートを変更したりする他のソフトを終了し、もともとのシステムプロキシ状態と復旧方法を記録します。TUNの有効化に失敗した場合は、まずクライアントを終了して仮想インターフェースとルーティングテーブルを復元し、その後に再調整します。残ったインターフェース上で複数の実装を連続して切り替えないでください。

スタック実装と基本パラメーターを選ぶ

クライアントにはsystem、gVisor、mixedなどのネットワークスタック विकल्पが用意されている場合があります。systemスタックはOSの機能に依存し、通常は直接的な性能経路を使います。gVisorはユーザー空間のネットワークスタックを使うため、systemスタックとは互換性の挙動が異なります。mixedはTCPとUDPを組み合わせて処理します。すべての環境に最適な選択肢はありません。まずクライアントのデフォルト値を使い、特定のアプリだけ接続できない、UDPに異常がある、スリープ復帰後に失敗するといった症状が出たときだけ、1項目ずつ切り替えてログを比較します。

MTUは仮想インターフェースが運べるパケットサイズを決めます。大きすぎると複雑な経路でフラグメント化やパケットロスが起こり、小さなページは開けるのに大きなリクエストが停止することがあります。小さすぎるとパケット数と処理負荷が増えます。明確な根拠がない場合はデフォルトのままにしてください。調査が必要なら、MTUを少しずつ下げて同じ対象をテストします。ネットワークスタックとDNSを同時に変更しないでください。厳格なルーティング設定は通信の迂回を減らしますが、ローカルネットワークアクセスに影響する場合もあるため、バイパスするアドレスと併用します。

LANと予約アドレスのバイパスを設定する

TUNで取り込んだ後、プリンター、ネットワークストレージ、ルーターの管理画面、開発環境が誤ってプロキシへ送られることがあります。まずループバック、プライベートアドレス、リンクローカルアドレスを直結にし、LAN検出に必要なUDP通信が広範なブロックルールに巻き込まれていないことを確認します。一般的なプライベート範囲には10.0.0.0/8、172.16.0.0/12、192.168.0.0/16があります。ただし企業ネットワークでは別の内部アドレスを使う場合があるため、実際のルーティングテーブルを基準にしてください。

プライベートアドレスをバイパスしても、LAN上のデバイスからクライアントのプロキシポートへアクセスできるようになるわけではありません。LAN共有は別のインバウンド設定であり、有効にするかどうかを個別に決める必要があります。リッスンするアドレスとファイアウォールの範囲も制限してください。本機だけで使う場合、プロキシインバウンドは引き続きループバックアドレスにバインドします。共有を有効にするなら、まずローカルネットワークを信頼できるか確認し、アクセス範囲を設定します。TUNのルーティングバイパスでインバウンドのアクセス制御を代替することはできません。

DNSハイジャックとドメイン識別を処理する

TUNモードで信頼性の高いドメイン振り分けを行うには、通常、システムのDNS問い合わせをコアへ取り込む必要があります。接続だけを取り込んでDNSを取り込まない場合、アプリがシステム外部でIPを取得し、コアはIPだけでルーティングすることになります。DNSハイジャックを有効にしたら、問い合わせがクライアント内蔵DNSへ入っていることを確認し、クライアント自身の名前解決リクエストが再びハイジャックされないようにします。53番ポートは従来のDNS入口として一般的ですが、アプリ内蔵の暗号化DNSは迂回する可能性があるため、アプリ設定とルーティング層の両方で対応します。

スニッフィングで一部の接続から対象ドメインを復元できますが、すべてのプロトコルで確実に使えるわけではありません。有効にした後は、特にカスタム証明書、内部ドメイン、特殊なサービス検出を使うアプリで、対象アドレスが誤って書き換えられていないか確認します。接続確立直後に切断される場合は、対象の上書きを一時的に無効にし、ドメイン識別だけを残して比較します。FakeDNSもドメインと接続の対応を保つ方法で、TUN環境に適しています。ただし独立したアドレスプールと正しい回収方法が必要なため、次章で個別に説明します。

症状からTUNの障害を切り分ける

有効化後に完全に通信できなくなった場合は、まずコアが正常に起動したか、仮想インターフェースが作成されたか、デフォルトルートが想定した場所を指しているか、DNSに到達可能な経路が残っているかを確認します。LANだけが失敗するなら、プライベートアドレスの直結と厳格なルーティングを確認します。UDPアプリだけが失敗するなら、ネットワークスタック、UDPルーティング、サーバーのプロトコル対応を比較します。スリープ復帰後に失敗した場合は、TUNインターフェースを再確立し、古いルートが残っていないか確認します。クライアント設定をすべて削除するのは後回しにしてください。TUNの障害は通常、取り込みレイヤーにあります。

検証が終わったら、ブラウザー、従来システムプロキシを読まないアプリ、LANリソース、DNS問い合わせ、UDP通信をそれぞれテストします。5種類すべての経路を説明できて、TUNは安定したと判断できます。必要なのが特定のコマンドラインプログラムだけなら、システム全体を取り込むより、そのプログラムに明示的なプロキシ環境変数を設定するほうが管理しやすくなります。

FakeDNS：ドメイン情報を保持し、実際の名前解決を後回しにする

合成アドレスの役割を理解する

FakeDNSはドメイン問い合わせを受けても、実際の対象アドレスをすぐにアプリへ渡しません。あらかじめ設定したアドレスプールから合成IPを返し、「合成IP—元のドメイン」の対応を保存します。アプリがその合成IPへ接続すると、TUNまたは透過的な取り込み層が接続をコアへ戻します。コアは対応表からドメインを復元し、ドメインルールに基づいてDNSと出力先を選択します。これにより、アプリがIPにしか接続しない場合でも、コアは元のドメインを取得でき、ドメイン振り分けが安定します。

合成アドレスはリモートサーバーのアドレスではなく、通常のルーティングでパブリックな宛先として扱うものでもありません。本機の取り込み経路内でマッピングの索引として使うだけです。リクエストがTUNを迂回して直接ネットワークへ送られると、合成アドレスには当然アクセスできません。そのためFakeDNSは、後続の接続を捕捉できる取り込み方式と組み合わせる必要があります。内蔵DNSのFakeDNSオプションだけを有効にしても、処理全体は完結しません。

独立し、競合しないアドレスプールを計画する

アドレスプールは、実際のローカルネットワーク、企業内ネットワーク、コンテナネットワーク、既存の仮想インターフェースが使用する範囲を避ける必要があります。設定前にシステムのルーティングテーブルを確認し、候補ネットワークが実際のルートで使われていないことを確認してください。アドレスプールが小さすぎると、多数のドメインを同時に扱う際にマッピングの回収が頻発します。大きすぎると、他のネットワーク設計と競合する可能性があります。通常はクライアントのデフォルト範囲が最も安全です。競合が確認できた場合だけ変更し、TUNルーティングが新しい範囲をカバーしているかも併せて確認します。

{
  "dns": {
    "servers": [
      {
        "address": "fakedns",
        "domains": ["geosite:geolocation-!cn"]
      },
      "223.5.5.5"
    ],
    "queryStrategy": "UseIPv4"
  },
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

198.18.0.0/15はベンチマーク用ネットワークによく使われ、一部のクライアントでは合成アドレスにデフォルトで利用されます。ただし、ローカルネットワークに同じ範囲のルートがないか確認してください。poolSizeは利用可能なマッピング数を制御し、アドレスプールの実容量を超えてはいけません。設定フィールドはコアの系統やクライアントの生成方式によって異なります。GUIを使う場合は、まずクライアントに構造を生成させ、最終的なコア設定を確認してください。例全体を互換性のない階層へそのまま上書きしないでください。

FakeDNSを使うドメインを決める

すべての問い合わせに合成アドレスが必要なわけではありません。ローカルドメイン、LANサービス、プリンター検出、アプリへ実IPを返す必要があるツールは、通常のDNSを使い続けるべきです。ドメイン単位でプロキシする予定のパブリックな対象は、FakeDNSに適しています。まず明確な非ローカルドメインの集合だけで有効にし、安定性を確認してから範囲を広げます。すべての問い合わせをFakeDNSへ送ると、ローカルサービスが利用できない合成結果を受け取る可能性があります。

除外リストには、LANのサフィックス、開発環境のドメイン、実IPに依存する診断ツールを含めます。DNSの結果をユーザーに表示したり、設定へ書き込んだり、別のデバイスへ渡したりするアプリも、本機専用の合成IPを受け取る用途には適しません。FakeDNSが解決するのは透過的な取り込みにおけるドメインの関連付けであり、汎用DNSアクセラレーターではありません。合成結果をLAN上の他のデバイスへ広めないでください。

スニッフィング、ルーティング、実際の名前解決を連携させる

FakeDNSが元のドメインを復元したら、まずルーティングがドメインルールで出口を決め、その後、実際のDNS問い合わせを同じ出口と整合する経路で実行します。ドメインが直結と判定された場合は直結経路に適したリゾルバーを使い、プロキシを通る場合はプロキシ経路用のリゾルバーを使います。そうしなければドメインの復元に成功しても、出口に合わないアドレスを取得する可能性があります。ログには、合成マッピング、ドメインのマッチ、実際の対象への接続が連続して表示される必要があります。

スニッフィングとFakeDNSは併用できますが、役割は異なります。FakeDNSは問い合わせのマッピングでドメインを復元し、スニッフィングは接続内容からドメインを識別します。両方を有効にする場合は、対象アドレスの上書きを許可するか明確にしてください。同じ接続でドメイン判定が競合するなら、まずスニッフィングによる上書きだけを無効にし、FakeDNSを残して比較します。アプリが取り込み可能なDNS問い合わせをまったく発行しない場合、FakeDNSはマッピングを作れません。その場合でもスニッフィングで情報を得られる可能性があります。

キャッシュとマッピングの失効を確認する

アプリ、システム、クライアントのそれぞれが合成結果をキャッシュする可能性があります。アドレスプールを変更したりFakeDNSを無効にしたりした後も、古い合成IPが使われ続け、一部のドメインだけ失敗することがあります。TUNを切断し、コアを再読み込みし、システムDNSキャッシュを更新し、テストアプリを再起動してから、接続を再確立する順番で処理します。接続が有効なままアドレスプールを頻繁に切り替えないでください。古いマッピングと新しいルーティングが一時的に共存します。

長時間動作した後だけ失敗する場合は、アドレスプールの容量、マッピングの回収、アプリのDNSキャッシュ期間を確認します。特定のドメインが初回は正常で、その後に異常になる場合は、実際のDNS返答が変化していないか、古い接続が期限切れのマッピングを再利用していないかを比較します。すべての合成アドレスへ接続できない場合は、リモートサーバーを変更するのではなく、TUNがそのネットワーク範囲を取り込んでいるかを重点的に確認します。

最終検証では、通常のパブリックドメイン、明確な直結ドメイン、LANドメイン、アプリ内蔵の名前解決という4種類の対象を用意します。通常のパブリック対象はマッピングを生成してドメインルーティングを通り、直結対象とLAN対象は除外ポリシーに従って実アドレスを取得します。アプリ内蔵の名前解決を使う対象では、取り込み経路へ入っているかを確認します。4種類すべてが設計どおりに動いて初めて、FakeDNSが新たな不透明層を増やすのではなく、ドメイン振り分けを改善したと判断できます。

カスタム出力先：ラベル、チェーン転送、最終的な障害切り分け

まず出力先の役割とラベルを定義する

アウトバウンドはルーティングルールの最終的な宛先です。最小構成には通常、プロキシ、直結、ブロックの3つの役割があり、安定したラベルとしてproxy、direct、blockを使います。カスタム出力先は、特定インターフェースによる直結、独立したDNS出力先、チェーン転送を追加する場合に適しています。ただし出力先を1つ増やすたびに、ラベル、ルーティング参照、障害時のフォールバックも管理する必要があります。ラベルは大文字と小文字を区別するため、名前を変更したらすべてのルールを検索し、古い名前を参照していないか確認してください。

GUIクライアントは通常、現在のサーバーからメインのプロキシ出力先を生成します。生成されたオブジェクトを直接変更すると、サーバー切り替えやサブスクリプション更新で上書きされる可能性があります。そのためカスタム部分は、クライアントが対応する追加設定、プリセットプロファイル、カスタム出力先の領域に配置します。まずクライアントのマージ順序を確認してください。同名フィールドが上書き、追加、拒否のどれになるかを確認します。分からない場合は、最終的なコア設定をエクスポートして実際の結果を確認し、画面上の入力断片だけで判断しないでください。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIP"
      }
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "response": {
          "type": "none"
        }
      }
    }
  ]
}

直結出口にアドレスファミリーまたはインターフェースを指定する

複数のネットワークインターフェースを持つデバイスでは、有線、無線、仮想ネットワーク、企業ネットワークが同時に接続されることがあります。デフォルトの直結はシステムルーティングがインターフェースを選びますが、カスタム直結出力先では、コアが対応していれば送信元アドレスやアドレスファミリーを指定し、特定の通信を特定のローカルインターフェースへ固定できます。設定前に、そのアドレスが長期的に存在することを確認してください。動的に割り当てられるアドレスは、スリープ、再接続、ネットワーク切り替え後に無効になる可能性があります。目的がLANへのアクセスだけなら、システムルーティングとプライベートアドレスの直結を優先し、インターフェースを強制的に固定する必要はありません。

アドレスファミリーを指定する場合は、DNSの問い合わせポリシーと一致させます。直結出力先がIPv4だけを許可し、DNSがIPv6を返すと、接続は失敗します。プロキシ出力先がデュアルスタックに対応していても、ローカル直結が対応しているとは限りません。調査ではDNSの結果、ルーティングラベル、出力先が実際に発信したアドレスを個別に記録します。複数インターフェース環境では、TUNが作成したルートの優先順位も確認し、カスタム直結が再びTUNへ入り込んでループしないようにします。

チェーン転送の適用範囲を理解する

チェーン転送では、あるプロキシ出力先が別の出力先を通って接続を確立します。明確なネットワーク構成や入口制限には使えますが、ハンドシェイクの層、遅延、障害点が増えるため、サーバー選別の代わりにはなりません。チェーンを設定する前に、前段の出力先と最終出力先がそれぞれ単独で動作することを確認してから接続します。どこかのDNS、アドレスファミリー、UDP対応、トランスポートが失敗すると、最終接続も失敗します。

チェーンにはループを作らないでください。出力先AがBを通るなら、BはAを通ってはいけません。DNS出力先も、最終的にそのDNSで解決しなければならないプロキシへ依存してはいけません。各層にproxy-entryやproxy-exitのような明確なラベルを付けると、ログでどの段階に失敗したか判断できます。デフォルトルーティングは最終的な業務出口だけを指し、前段の出力先は通常、転送関係から呼び出すため、広範なルールで直接マッチさせる必要はありません。

独立したDNS出力先を作る

コアがDNS出力先に対応している場合、内部DNSの問い合わせを専用ラベルで指定した経路へ送れます。これにより、ルーティングルールでDNS通信と通常の接続を分離し、ループを減らせます。典型的な構成では、内蔵DNSが問い合わせを生成し、DNS出力先が送信を担当します。ルーティングでは、該当するインバウンドまたはプロトコルをdns-outへ優先的に向けます。リモートリゾルバーへのアクセスにプロキシが必要なら、dns-outを明確なプロキシ経路に通し、デフォルトルールの推測に任せないでください。

{
  "outbounds": [
    {
      "tag": "dns-out",
      "protocol": "dns",
      "settings": {
        "address": "1.1.1.1",
        "port": 53,
        "network": "tcp"
      }
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": ["dns-in"],
        "outboundTag": "dns-out"
      }
    ]
  }
}

この例はラベル同士の関係を示すものであり、すべてのクライアントが同じフィールドからDNS出力先を生成するとは限りません。暗号化DNSを使う場合、アドレス、ポート、トランスポートもコアの対応方式に合わせて設定します。検証では、問い合わせが1つのインバウンドと1つのアウトバウンドだけを通り、通常のDNS入口へ戻っていないことを確認します。同じドメインがログに繰り返し現れる場合は、まず名前解決ループを疑ってください。

レイヤーごとに最終的な障害を切り分ける

複雑な設定が失敗した場合は、リクエストの入口から外側へ向かって層ごとに確認します。第1段階では、アプリの通信がシステムプロキシまたはTUNへ入っているかを確認します。第2段階では、DNSが利用可能な結果を取得し、ドメイン情報を保持しているかを確認します。第3段階では、ルーティングが想定したラベルにマッチしているかを確認します。第4段階では、そのラベルに対応する出力先が存在し、パラメーターが有効かを確認します。第5段階で初めてリモート接続を調べます。各段階にはログによる根拠が必要です。入口とルーティングを飛ばしてサーバーだけを変更すると、一時的に症状が変わるだけになりがちです。

エラーは影響範囲で絞り込めます。すべてのアプリが失敗するなら、コアの起動、取り込み、デフォルト出力先が主な原因です。特定のアプリだけなら、プロキシ方式、プロトコル、DNSの挙動を比較します。特定のドメインだけなら、ドメインルール、キャッシュ、実際の名前解決を確認します。UDPだけが失敗するなら、ネットワークスタック、ルーティング、出力先の能力を確認します。LANだけが失敗するなら、プライベートアドレスとTUNのバイパスを確認します。症状を設定レイヤーへ対応付けるほうが、個別の「修復コマンド」を暗記するより確実です。

設定が完了しても、最終結果を永久に不変なものと考えないでください。サブスクリプションの命名、ネットワークインターフェース、システム権限、利用するドメインは変化するため、挙動に明らかな変化があれば基準テストを再実行します。クライアントを変更する場合は、まずv2rayN、v2rayNG、v2flyNGの比較レビューを確認してください。再インストールが必要ならクライアントダウンロードページへ進みます。具体的なログエラーがある場合は、実行ログから切り分ける手順と併用して対応します。設定をレイヤーごとに分け、ラベルを安定させ、変更を戻せる状態に保つことが、ルールを増やし続けるより重要です。