V2Ray 高度な設定ガイド

復元可能な設定モデルを先に作る

入口・判断・出口に分けて考える

高度な設定が混乱しやすいのは、個々のパラメーターが難しいからではなく、複数の層が同時に変化するためです。完全な接続は少なくとも3段階を経ます。アプリの通信がシステムプロキシまたは仮想NICに入り、カーネルがドメイン名、IP、ポート、プロセス情報に基づいてルーティングを選び、最後にプロキシ、直接接続、ブロック、またはカスタムアウトバウンドが処理します。サブスクリプションはリモートサーバーを提供し、ルーティングは通信の行き先を決め、DNSはドメイン名をアドレスに変換し、TUNは通信がカーネルへ入る方法を変えます。まずこの4層を分けて考えれば、トラブル対処のたびにクライアントを再インストールする必要はありません。

たとえば、ブラウザーは接続できるのにコマンドラインツールが接続できない場合は、まず入口層を確認します。ブラウザーはシステムプロキシを読み込んでいても、ターミナルのプログラムは直接接続している可能性があります。通常のプロキシは使えるのにTUNを有効にすると不安定になる場合は、仮想NIC、ルーティングテーブル、DNSの引き継ぎを確認します。特定のドメインが常に誤った経路を通るなら、すぐにサブスクリプションを変更するのではなく、ルーティングルールの優先順位を調べます。ドメイン名を解決できても接続できない場合は、解決結果の誤り、アウトバウンドへの到達不能、プロトコルパラメーターの不一致を切り分ける必要があります。現象を該当する層に対応付けることが、このガイドで最も重要な方法です。

変更する変数は毎回1つだけにする

実験を始める前に、現在動作している基準状態を残します。選択中のサーバー、システムプロキシの状態、ルーティングモード、DNSモード、TUNの有効・無効を記録し、クライアントが設定のエクスポートやバックアップに対応している場合はコピーを保存します。その後は関連する設定を一度に1組だけ変更し、すぐに検証してください。同じ操作でTUNの有効化、DNSの切り替え、新しいルートの読み込み、サーバーの変更を同時に行わないでください。4項目が同時に変わると、接続が戻っても何が効いたのか分かりにくくなり、接続が切れた場合の特定コストも大幅に増えます。

検証も層ごとに行います。まずクライアントログでカーネルが正常に起動したかを確認し、次にローカルの待ち受けポートまたは仮想NICが作成されたかを調べ、その後にドメイン名の解決、最後に対象アプリをテストします。ログの最初のエラーは、後続の連鎖的なエラーより価値が高いことがよくあります。カーネルが設定形式のエラーで起動できない場合、後に出る接続タイムアウトは結果にすぎません。システムコマンドで基本状態を確認することもできますが、コマンドの出力が示すのは現在のOSから見える結果であり、クライアントログの代わりにはなりません。

Windows:
ipconfig /flushdns
ipconfig /all

macOS:
scutil --dns
route -n get default

Linux:
resolvectl status
ip route

安定した検証サンプルを用意する

検証サンプルは3種類のリクエストを含めます。直接接続を想定するサイト、プロキシ接続を想定するサイト、DNSだけを確認するドメインです。テスト対象を頻繁に変えると、対象サービス側の変動が判断を妨げます。ブラウザーでテストする場合は、プロキシやDNSを個別に引き継ぐ可能性のある拡張機能をいったん無効にし、ブラウザー独自の安全なDNS設定にも注意します。ターミナルでテストする場合は、HTTP_PROXY、HTTPS_PROXY、ALL_PROXYの環境変数を読み取るかどうかを明示します。プログラムごとにプロキシ経路へ入る方法は異なります。

変更前後の時刻も記録します。v2rayNのログは流れ続けるため、正確な操作時刻が対応するリクエストの特定に役立ちます。ログにドメイン名がなくIPだけが表示される場合、ドメイン名はカーネルに入る前にアプリが解決した可能性があります。この場合、ドメインルールだけでは一致しないことがあるため、スニッフィング、DNS、またはIPルールの調整が必要です。ログに想定どおりのドメイン名が表示されても、最終的なアウトバウンドが異なる場合は、ルールの優先順位とタグを確認します。この基準と復元手順を整えれば、以降の各章でも同じ方法を使えます。

サブスクリプショングループとサーバーフィルター

グループの目的はソースの分離であり、タグの積み重ねではない

v2rayNでは、手動サーバーと複数のサブスクリプションソースを同時に保存できます。サーバーが増えたら、最初に解決すべきなのは「より多く表示する方法」ではなく、「ソースを追跡できる状態を保つ方法」です。1つのサブスクリプションURLにつき1つのサブスクリプショングループを作り、グループ名には用途やソースを明記します。「購読1」「予備2」のような名前だけにしないでください。あるサーバー群のパラメーターに異常がある、名前が重複する、更新後に消えるといった場合、ソースが明確なら調査範囲をすぐに絞れます。手動で追加したテストサーバーも独立したグループに入れ、サブスクリプション更新時に所属を誤認しないようにします。

グループ名は安定させ、サーバーの備考は変更できるようにします。地域、用途、プロトコルなどをすべてグループ名に詰め込むと、メニューとフィルター条件が次第に長くなります。グループにはソース、サーバーの備考にはノードの特徴を記録する方が適切です。たとえば、グループにはサービスのソースを記録し、備考には「地域｜回線｜プロトコル」のような固定順序を使います。備考の形式を統一すると、キーワードフィルターが機能しやすくなり、更新前後に同じサーバー群を識別するのにも便利です。

まず包含フィルターを設定し、後から除外条件を加える

サーバーフィルターには通常、キーワードに一致する項目だけを残す処理と、一致する項目を除外する処理の2種類があります。最初は地域名や用途の印など、明確な包含キーワードを1つだけ使い、結果が正しいことを確認してから除外キーワードを追加します。複雑な正規表現は簡潔でも保守コストが高く、サブスクリプション提供元が命名方法を変えるだけで、すべてのサーバーが除外される可能性があります。フィルター結果が空になったら、まず条件を一時的に消してグループを更新し、元データが存在することを確認してから条件を1つずつ戻します。

正規表現を使う場合は、大文字と小文字、空白、全角記号、括弧に注意します。サブスクリプションの備考で同じように見える横線も、ハイフン、短いダッシュ、その他の文字に分かれていることがあります。安定した文字列を対象にし、装飾記号に依存しない表現の方が安全です。次の例は、名前に「東京」または「ソウル」を含む項目を残し、「テスト」または「期限切れ」を含む項目を除外します。包含と除外の入力欄が分かれているかどうかはクライアントの画面によって異なるため、それぞれに入力し、2つのロジックを読みにくい1つの式へ連結しないでください。

包含条件：
東京|ソウル

除外条件：
テスト|期限切れ

更新・上書き・削除の違いを理解する

サブスクリプションを更新すると、クライアントは内容を再取得し、そのサブスクリプションに属するサーバーを更新します。サーバーが消えた場合、上流で削除された、フィルター条件が変わった、グループの選択を誤った、サブスクリプションの解析に失敗したなどの可能性があります。すぐに同名のサーバーを手動で追加し直すのではなく、まず更新ログを開いてリクエストが成功したかを確認し、フィルター前の元データを確認してください。手動サーバーとサブスクリプションのサーバーに同じ備考がある場合も、名前だけで同一項目と判断せず、アドレス、ポート、プロトコル、グループの所属を確認します。

サブスクリプションURLを変更する前に、既存グループの編集なのか、新しいグループの作成なのかを確認します。新しいURLで古いグループを直接上書きすると、過去のソースと新しいソースが同じ名前に混在する可能性があります。ソースが実質的に変わる場合は、新しいグループを作成してテストを完了し、その後に古いグループを無効化する方が、元に戻しやすいことが多いです。古いグループを整理する前に、現在使用中のサーバーがそのグループに属しているか、ルーティングルールやカスタム設定が関連タグを参照していないかも確認します。

複数ソースの整理方法は複数サブスクリプションのグループ管理：v2rayNのサーバーフィルターと備考設定でも詳しく解説しています。フィルターが安定したら、次の章でルーティングを設定します。フィルター機能をルーティング機能の代わりに使わないでください。フィルターはリストに表示するサーバーを決め、ルーティングは1回のリクエストで使用するアウトバウンドを決めます。両者はまったく異なる層の機能です。

ルーティング実践：一致順序からアウトバウンドタグまで

ルールは順序を持つ判断チェーン

ルーティングシステムは、リクエストに含まれる情報に基づいてアウトバウンドを選択します。よく使う条件は、ドメイン名、宛先IP、宛先ポート、ネットワーク種別、プロセス名です。重要なのはルールの数ではなく、一致する順序です。より具体的なルールをより汎用的なルールより前に置き、最後にフォールバックルールで残りの通信を処理します。「すべてのドメインをプロキシへ送る」ルールが「内部ドメインは直接接続」より前にあると、後者は通常実行されません。ルールを調整するときは、ログから実際のリクエストを1つ選び、ルールリストを上から順に判定してください。見た目だけで推測してはいけません。

ドメインルールはサイトの所属を表すのに適し、IPルールは明確なネットワーク範囲の処理に適し、ポートルールは特定サービスの制限に適しています。プロセスルールは、クライアントとOSがプロセス情報を取得できるかどうかに依存するため、プラットフォームを移行する際は再検証が必要です。1つのリクエストが最初はドメイン名としてカーネルに入り、その後IPへ解決されることもあります。ドメイン名が保持されるかどうかは、入口、スニッフィング、DNSの設定によって決まります。そのため、通常のシステムプロキシとTUNモードでは、同じドメインルールでも結果が異なる場合があります。

先にアウトバウンドを定義し、ルーティングからタグを参照する

低レベルの設定では通常、タグを使ってルーティングとアウトバウンドを結び付けます。たとえば proxy は現在のプロキシアウトバウンド、direct は直接接続、block はブロックを表します。タグは内部参照名にすぎず、それだけで対応する機能が作成されるわけではありません。ルーティングルールが存在しないタグを参照すると、カーネルが起動を拒否したり、設定生成時にエラーになったりする可能性があります。v2rayNのグラフィカルなルーティングエディターでは一部の関連付けが処理されますが、カスタムJSONを読み込む場合はタグの一貫性を自分で保証する必要があります。

{
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    },
    {
      "protocol": "blackhole",
      "tag": "block"
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:intranet.example"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

上の構造はルールの関係を示すものですが、proxyアウトバウンドはクライアントが現在のサーバーに基づいて生成するため、この断片だけを完全な実行設定として保存することはできません。プライベートアドレスのルールを先に置けば、LAN内の機器がリモート側へ送られるのを防げます。その後に明確なドメインルールを一致させ、最後のルールで残りのTCPとUDPを捕捉します。一部の通信だけをプロキシに通したい場合は、全通信を捕捉するルールを追加せず、対象ドメイン用のプロキシルールを作り、デフォルトのアウトバウンドは直接接続のままにします。

適切なドメイン戦略を選ぶ

AsIsはルーターに入ったドメイン情報をそのまま使う傾向があり、IPルールのために積極的な解決は行いません。IPIfNonMatchはドメインルールに一致しなかった場合にIPを解決し、IPルールを試します。IPOnDemandはIP判定が必要になる可能性のあるリクエストを、より積極的に解決します。積極的な戦略ほど、ルーティング結果に対するDNSの影響は大きくなります。ルールの中心がドメイン名なら、まずドメイン情報を保持する方式から始めるのが一般的です。地理的なIPデータに依存する場合は、不一致時の解決を検討します。

「一致率を上げる」ために、大量のドメインルールとIPルールを同時に積み重ねないでください。ドメインの解決結果は変化し、コンテンツ配信サービスがアドレスを共有することもあります。広すぎるIP範囲は無関係なサイトまで巻き込む可能性があります。固定された内部ネットワークにはIPルールが適していますが、一般公開サイトではまずドメイン分類を使い、ログで確認します。ルールに一致しない場合は、ログに完全なドメイン名、サブドメイン、純粋なIPのどれが表示されているかを確認します。IPしかないなら、ドメイン項目を増やすのではなくDNSとスニッフィングの層に戻って対処します。

「開ける」だけでなくルーティング結果を検証する

ウェブページが開くからといって、ルーティングが正しいとは限りません。誤ったアウトバウンドでも偶然成功することがあります。検証では接続ログの宛先、適用されたルール、最終アウトバウンドタグを確認します。直接接続を想定したサンプルとプロキシ接続を想定したサンプルをそれぞれリクエストし、経路が異なることを確認します。LAN内サービスでは、ホスト名とIPの両方でアクセスをテストしてください。ホスト名はDNSでプライベートアドレスに解決されても、IPを直接入力するとドメイン名の段階を飛ばす可能性があります。

ルールが機能しない場合は、「ルールの順序、条件の形式、リクエストから見える情報、アウトバウンドタグ」の4点を確認します。まず対象ルールを一時的に先頭へ移し、それでも一致しなければ条件を1つのドメインまたはIPだけに絞ります。次に入口が必要な情報を含んでいるかを確認し、最後にタグの存在を確認します。これにより、複雑なルールを検証可能な最小サンプルへ分解できます。VLESS、VMess、REALITYなどの用語とルーティングの関係は用語集で確認できますが、プロトコル名そのものをルーティング結果の代わりに使うことはできません。

DNS設定の最適化：誰がどこで解決するかを明確にする

まず名前解決の経路を可視化する

DNS問題の最も一般的な原因は、「複数の解決者が同時に存在する」ことです。アプリが独自に解決する場合もあれば、OSにはシステムリゾルバーがあり、ブラウザーが独立した安全なDNSを有効にしている場合もあります。v2rayNのカーネルもDNSを処理でき、TUNモードがシステムクエリを引き継ぐこともあります。設定前に、3つの質問へ答えてください。ドメイン名の問い合わせを誰が開始するのか、どのサーバーへ渡すのか、問い合わせ自体を直接接続するのかプロキシ経由にするのか。経路を確認せずDNSアドレスだけを変更すると、ログは正常に見えるのに実際のリクエストが古いキャッシュを使い続けることがあります。

通常のシステムプロキシでは、多くのアプリがまずローカルでドメイン名を解決し、IPをプロキシへ渡します。一方、SOCKSのリモート解決機能によってドメイン名をカーネルへ渡すアプリもあります。TUNモードではシステム通信を一元的に引き継ぎやすくなりますが、ブラウザー内部の名前解決が想定した経路を迂回する可能性は残ります。トラブル対処では、まずアプリ層の独立DNSを無効にして比較し、システムキャッシュを消去します。その後、まだアクセスしていないサブドメインへ新たにリクエストし、対応する問い合わせがクライアントログに現れるかを確認します。

ローカルDNSとリモートDNSの役割分担

安定した構成は、すべてのドメインを同じリゾルバーへ渡すのではなく、用途ごとに分担させます。LANのホスト名や内部ドメインは、それらを認識できるローカルリゾルバーへ渡します。プロキシ側の視点で解決したい公開ドメインは、プロキシ経由でアクセスするDNSへ渡せます。通常の直接接続ドメインには、システムDNSまたは指定したローカルDNSを使います。分流する前に、プライベートアドレスと内部サフィックスの直接接続経路を残してください。そうしないと、プリンター、ルーターの管理画面、開発環境のサービスが解決できなくなる可能性があります。

DNSサーバーのアドレス形式もブートストラップに影響します。ドメイン名形式の暗号化DNSエンドポイントを使う場合、クライアントはまずそのエンドポイント自体を解決する必要があり、「リゾルバーを解決する」という初期化問題が生じます。利用可能なブートストラップDNSを用意するか、明確なIPエンドポイントを使い、サーバー名を正しく処理してください。相互依存する2つのリゾルバーをループ状に設定しないでください。Aのドメイン名をBへ渡し、Bのドメイン名をAへ渡す構成は、起動後に長時間待機したり、周期的なタイムアウトになったりします。

{
  "dns": {
    "hosts": {
      "router.internal": "192.168.1.1"
    },
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": [
          "domain:internal"
        ],
        "skipFallback": true
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

この例では、静的ホストマッピング、内部ドメイン専用リゾルバー、バックアップ用リゾルバーを示します。実際に使う際は、192.168.1.1をローカルネットワークで実際に利用できるDNSアドレスへ置き換え、そのアドレスが問い合わせに応答できることを確認してください。skipFallbackは指定ドメインに一致した後、他のサーバーへフォールバックしないことを示します。内部ドメインに適していますが、専用リゾルバーが不安定な場合は障害が直接現れるため、必ず単独でテストしてください。

問い合わせ戦略とアドレスファミリーを理解する

DNSはIPv4、IPv6、またはその両方を返し、アプリはその中から1つを選んで接続します。IPv6の対応が部分的なネットワークでは、リゾルバーがIPv6アドレスを返しても経路が使えるとは限りません。よくある症状は、最初の接続が待たされた後にIPv4へフォールバックすることです。まずシステムに完全なIPv6ルートがあるかを確認し、そのうえで問い合わせ戦略を決めます。1回接続が遅かっただけで、特定のアドレス種別を恒久的に無効にしないでください。システムのネットワークツールでデフォルトルート、DNSの応答、宛先への到達性を確認します。

UseIP、UseIPv4、UseIPv6などの戦略は、カーネルがどの種類の結果を受け入れるか、または優先するかを制御します。具体的な対応範囲は現在のカーネルによって異なります。複数の端末へ設定を移行する場合、アドレスファミリーの戦略をそのままコピーしないでください。デスクトップの有線ネットワーク、無線ネットワーク、モバイルホットスポットでは対応状況が異なる可能性があります。固定回線に適した設定が、別のネットワークでは名前解決に成功しても接続に失敗することがあります。

調整が終わったら、クライアントキャッシュ、システムキャッシュ、アプリキャッシュの順に消去してから、新しいドメインをテストします。ページを更新するだけでは、ブラウザーが既存の接続を再利用し、DNSの変化が反映されないことがあります。DNS最適化の目的は、経路を明確にし、障害を観測可能にすることです。リゾルバーの数を増やし続けることではありません。役割が明確な2〜3個の解決入口の方が、長い自動フォールバックアドレス列より保守しやすいのが普通です。

TUNモード：システム通信を引き継ぎ、境界を見失わない

TUNとシステムプロキシは異なる問題を解決する

システムプロキシは、アプリが自らプロキシ設定を読み取ることに依存します。ブラウザーや多くのデスクトップアプリは対応していますが、一部のコマンドラインツール、ゲーム、独自のネットワークコンポーネントは無視することがあります。TUNモードは仮想NICとシステムルートを使って、より多くのIP通信をカーネルへ送ります。対応範囲が広がる一方で、ルーティングテーブル、DNSの引き継ぎ、権限、仮想NICドライバーなどの新しい変数も増えます。これはシステムプロキシの「強化スイッチ」ではなく、別の入口経路です。

TUNを有効にする前に、同じサーバーが通常のプロキシモードで安定して接続できることを確認します。これにより、リモートプロトコル、サブスクリプションパラメーター、サーバーへの到達性を一時的に調査対象から外せます。その後、現在のシステムDNS、デフォルトゲートウェイ、クライアントのルーティングモードを記録し、他の仮想NICを作成する可能性のあるネットワークツールを終了してからTUNを有効にします。初回テストでは基本ルーティングだけを残し、FakeDNSや複雑なカスタムルールを同時に有効にしないでください。

権限・仮想NIC・ルーティングテーブル

仮想NICの作成やシステムルートの書き込みには、通常より高い権限が必要です。権限が不足していると、画面上のスイッチは切り替わっても、ログにはNICの作成やルートの書き込みに失敗したことが表示されます。Windowsでは仮想NICの状態、ファイアウォール、ルートの優先順位を重視します。macOSではシステム認証、ネットワーク拡張の状態、DNSサービスの順序を確認します。LinuxではTUNデバイスの権限、ポリシールーティング、ネットワーク管理サービス、ファイアウォールルールを確認します。問題が起きたら、スイッチを何度も押すのではなく、ログに最初に出たシステムコールエラーを確認してください。

仮想NICが作成されたら、想定したアドレスとルートが追加されているかを確認します。デフォルトルートが変わっていなくても、必ずしも失敗とは限りません。実装によっては、より具体的なルートやポリシールートで通信を引き継ぎます。逆に、新しいデフォルトルートが見えても、すべての通信が正しく戻るとは限りません。プライベートネットワーク、現在のゲートウェイ、DNSサーバーが誤ってプロキシへ送られ、ループを形成していないことも確認します。LANへのアクセスが途切れた場合は、まずプライベートアドレスが直接接続になっているか、「LAN接続を許可」などの待ち受け設定が本機のファイアウォールと一致しているかを確認します。

MTUとUDPの境界

TUN接続は確立するのに一部のサイトが停止する場合は、MTUを検討します。追加のカプセル化によってパケットが大きくなり、下層ネットワークが正しく分割できない、またはパスMTUを通知できないと、大きなリクエストが何も表示せず破棄されることがあります。典型的な症状は、小さなページやテキストは正常なのに、アップロード、画像、長時間接続で異常が起きることです。MTUは少しずつ調整し、変更ごとに同じリクエストをテストしてください。値をいきなり極端に下げると、分割と処理の負荷が増えます。

UDPも個別に検証する必要があります。DNSはUDPをよく使いますが、アプリによっては他のUDPプロトコルも使用します。サーバーのアウトバウンド、カーネル、TUNスタック、ルーティングルールのすべてで、該当する通信を許可する必要があります。TCPは正常なのにUDPだけ異常な場合は、まずルーティングログでUDPリクエストがカーネルへ入っているかを確認し、次にアウトバウンドの対応状況と本機のファイアウォールを調べます。すべてのUDP障害をDNSのせいにしないでください。DNSはTCPや暗号化通信で処理されることもあります。

TUN終了後にシステム状態を復元する

クライアントを正常に終了すると、仮想NIC、ルート、DNS設定は削除されるはずです。しかし、システムの強制終了、クライアントのクラッシュ、権限の変更によって古い状態が残ることがあります。TUNを無効にしてもネットワークが不安定な場合は、まずクライアントを完全に終了し、仮想NICとルートが残っていないか確認してから、現在のネットワークへ再接続します。必要に応じてシステムのネットワークサービスを再起動してください。正体の分からないシステムインターフェースを直接削除すると、正常なネットワークに影響する可能性があります。

安定性テストでは、起動、終了、スリープからの復帰、ネットワーク切り替え、システム再起動を対象にします。1回接続できたからといって、ライフサイクル処理まで完全とは限りません。これらの場面で復旧できることを確認してから、FakeDNSの設定へ進みます。ブラウザーや一般的なデスクトップソフトだけをプロキシに通すなら、システムプロキシの方が保守コストは低くなります。プロキシ設定を読み取らないプログラムが実際に存在する場合に限り、TUNの追加の複雑さに明確なメリットがあります。

FakeDNS：ドメイン情報を保持するアドレスマッピング

「偽アドレス」の用途を理解する

一部のアプリは、まずローカルでDNSを解決し、宛先IPだけをTUNへ渡します。カーネルが純粋なIPだけを受け取ると、そのリクエストが本来どのサイト向けだったかをドメインルールで判断しにくくなります。FakeDNSは、専用アドレスプールからドメインに一時アドレスを割り当てる仕組みです。アプリがそのアドレスへ接続すると、カーネルがマッピングから元のドメイン名を復元します。これにより、TUNによるIP通信の引き継ぎを維持しながら、ドメインルールも機能させられます。

専用アドレスは実在するリモートホストを指すものではなく、本機のプロキシ経路内だけで意味を持ちます。そのためFakeDNSは、マッピングを認識できる入口、DNS、ルーティングと連携して使う必要があります。アドレスプールだけを設定しても、システムの問い合わせがFakeDNSへ入らなければマッピングは作成されません。システムが偽アドレスを取得しても通信が対応するTUNへ入らなければ、接続は直接失敗します。設定では、「問い合わせが偽アドレスを返す」ことと「接続がカーネルで元に戻る」ことを一続きの循環として確認してください。

アドレスプールは既存ネットワークを避ける

FakeDNSのアドレスプールは、本機のLAN、企業ネットワーク、コンテナネットワーク、他の仮想NICのネットワーク範囲と分離する必要があります。アドレスプールが実際のルーティングと重なると、OSが誤ったインターフェースへ接続を送り、カーネルがリクエストを認識できなくなることさえあります。アドレスプールを選ぶ前に現在のルーティングテーブルを確認し、普段接続するネットワーク環境も考慮してください。自宅のネットワークで使えても、職場のネットワークへ切り替えた後に競合しないとは限りません。

アドレスプールの大きさは保存できるマッピング数に影響します。一般的なデスクトップ利用で極端に広い範囲を求める必要はなく、容量よりも安定性と競合しないことが重要です。マッピングには有効期間があり、アプリのキャッシュ時間、カーネルキャッシュ、システムDNSキャッシュが一致しないと、古い偽アドレスから元のドメイン名を見つけられないことがあります。アドレスプールを変更したりFakeDNSモードを切り替えたりした後は、システムとアプリのDNSキャッシュを消去し、接続を作り直します。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "inbounds": [
    {
      "tag": "tun-in",
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls",
          "fakedns"
        ]
      }
    }
  ]
}

この断片は、FakeDNSのアドレスプールと入口スニッフィングの関係を説明するもので、単独で動作する完全な設定ではありません。v2rayNは通常、画面の選択項目に基づいて入口とルーティングを生成します。設定を手動で統合する場合は、同名のインバウンドを重複定義していないか確認してください。destOverrideを使うと、カーネルは認識できる情報に基づいて宛先を復元できますが、スニッフィングは内容の復号を意味しません。接続確立時に見えるプロトコル情報だけを利用します。認識できない通信は、FakeDNSのマッピングまたはIPルールに依存します。

FakeDNSに適さないリクエスト

LANのホスト名、内部サービス検出用ドメイン、他の端末へ実アドレスを返す必要がある問い合わせは、通常FakeDNSを使うべきではありません。ローカルDNSへ渡し、プライベートアドレスのルールで直接接続します。プリンター、ストレージ機器、開発環境のドメインを偽アドレスへマッピングすると、アプリはカーネルへ送れても、LAN検出、証明書検証、迂回経路の機器へのアクセスに失敗する可能性があります。内部サフィックス用のDNS分流を明確に作り、公開DNSのルールより前に配置してください。

解決結果をユーザーに表示したり、他のプログラムへ渡したりするツールにも注意が必要です。コマンドラインの問い合わせで専用アドレスが表示されるのは想定どおりですが、後続のプログラムがTUNを通らなければ、その結果は使えません。調査スクリプト、監視プログラム、コンテナ環境では、「ホストで解決し、別のネットワーク名前空間で接続する」状況がよく起こります。問い合わせと接続が同じプロキシ入口を通っているかを確認することが、FakeDNSに適しているか判断する鍵です。

循環的な手順でマッピング失敗を調べる

調査手順は4段階に固定します。まずDNS問い合わせがクライアントへ入っていることを確認し、次に返されたアドレスが設定したアドレスプール内にあることを確認します。その後、アプリのそのアドレスへの接続がTUNへ入っていることを確認し、最後にログで元のドメイン名が復元され、正しいルーティングに一致したことを確認します。1段階目で失敗したらシステムまたはアプリのDNSを確認し、2段階目ならFakeDNSルールとキャッシュを確認します。3段階目なら仮想NICとルートを確認し、4段階目ならマッピングの有効期間、スニッフィング、ルールの順序を確認します。

有効化後に一部のプログラムだけが異常になる場合、すぐにアドレスプールを広げないでください。まず異常なプログラムと正常なプログラムのDNS動作を比較し、独立した名前解決を使っているか、古いアドレスをキャッシュしているか、システムルートを迂回しているか、解決結果を別のプロセスへ渡しているかを確認します。FakeDNSは「TUNに入る前にドメイン情報が失われる」問題を解決するもので、すべてのDNS障害を直すものではありません。通常のDNSとTUNが安定してから有効にしてこそ、具体的な変化を確認できます。

複数購読の管理：更新・移行・無効化の分離

サブスクリプションを設定ソースとして管理する

サブスクリプションが増えると、管理の重点は「最速のサーバーを選ぶこと」から「設定変更を制御すること」へ移ります。各サブスクリプションは変化する外部ソースです。サーバーが追加、削除、改名されたり、パラメーターが変更されたりします。ソースの用途、更新方法、最後に成功した更新時刻、現在の日常選択に参加しているかを記録してください。クライアントのグループ名はソースを表し、備考の接頭辞はサーバーの特徴を表し、フィルター条件は表示範囲を絞ります。この3層を混同しないでください。

サブスクリプションは、通常使用、予備、テストの3種類に分けると管理しやすくなりますが、複雑な階層にする必要はありません。通常使用のソースは日常の更新に参加させ、予備のソースには少数の検証サンプルを残し、テストのソースでは新しい設定を確認します。新しいサブスクリプションはまずテストグループへ入れ、解析、接続、DNS、ルーティングを検証してから通常使用のリストへ加えます。こうすれば、新しいソースに異常なパラメーターが含まれていても、現在動作している経路がすぐに置き換わることはありません。

観測可能な更新手順を組む

すべてのサブスクリプションを同時に更新するのは便利ですが、失敗箇所の特定には向きません。最初の整理ではグループごとに手動更新し、成功したか、サーバー数が大きく変化したか、フィルター後も結果が残っているかを記録します。安定したことを確認してから一括更新を使います。あるグループの更新に失敗した場合は、高頻度で連続再試行しないでください。まず応答エラーなのか、解析エラーなのか、フィルター結果が空なのかを確認します。ネットワークリクエストが成功したことは、内容をクライアントが正しく解析できたことを意味しません。

更新前に、検証済みのアクティブサーバーを1つ保持します。更新直後に古い項目を消去せず、新しい結果から1つを選んで接続とルーティングが正常なことを確認してから、明らかに無効なデータを削除します。更新によってグループ全体が上書きされる場合は、大幅に変更する前にクライアント設定をエクスポートしてください。バックアップの価値はサブスクリプションURLだけでなく、グループ、備考、ルールの関係を復元できる点にあります。

重複サーバーと備考の揺れに対処する

2つのソースが、パラメーターは同じでも備考が異なるサーバーを提供することがあります。また、同じ備考が異なるパラメーターを指すこともあります。重複排除で名前だけを見てはいけません。少なくともプロトコル、アドレス、ポート、通信方式、セキュリティ層のパラメーター、主要な識別情報を比較します。パラメーターが完全に同じなら、ソースがより安定し、命名が明確な方を残せます。一部だけが同じ場合は別の設定として扱い、統合しないでください。

備考の揺れはキーワードフィルターを壊します。解決策は正規表現を際限なく広げることではなく、重要なサーバーにローカルで統一した備考を付けるか、フィルター語を比較的安定した地域・用途の項目だけに依存させることです。更新時にクライアントが備考をリセットする場合は、フィルターをやや緩く設計し、グループで範囲を絞ります。上流の表記に依存するほど、フィルター式の保守頻度は高くなります。

端末移行では層ごとに復元する

端末間で移行する場合、OSに依存する設定を一度にすべてコピーしないでください。まずプラットフォームに合ったクライアントをインストールします。デスクトップではv2rayNを優先し、Androidではカーネルの要件に応じてv2rayNGまたはv2flyNGを選びます。次にサブスクリプションとグループを読み込み、通常のプロキシ接続を検証します。その後にルーティングルールとDNSを移行し、最後に新しいシステムの機能に合わせてTUNを再設定します。仮想NICの権限、DNSサービス、プロセスルールにはプラットフォーム差があるため、古い端末からそのままコピーしないでください。

移行後の最初の検証では、サブスクリプション1つ、サーバー1つ、シンプルなルーティング1組だけを使います。安定してからフィルター条件と複数ソースの更新を戻します。古い端末からエクスポートしたカスタム設定に絶対ファイルパス、ローカルポート、LANのDNSアドレスが含まれている場合は、1つずつ置き換えてください。特に127.0.0.1の待ち受けポートは、新しい端末で別のプログラムが使用している可能性があり、カーネルの起動失敗につながります。

頻繁に削除するのではなく、無効化を分離して管理する

異常なサーバーを見つけたら、まず停止またはテストグループへ移し、比較用にログとパラメーターを残します。すぐに削除すると比較対象を失い、次回のサブスクリプション更新で再び現れる可能性もあります。ソースから削除されたこと、パラメーターが長期的に無効であること、重複項目が置き換えられたことを確認してから記録を整理します。更新後にグループ全体で異常が起きた場合は、自動選択に参加させ続けるのではなく、一時的にそのグループを無効にします。

長期的な保守では、短い周期を固定すると便利です。サブスクリプションの更新、失敗ログの確認、よく使うサーバーの検証、不要なフィルター語の整理、設定のバックアップを行います。毎日すべてをやり直す必要はありませんが、大きな変更の前には実施してください。クライアント本体の更新とサブスクリプション内容の更新も分けて扱います。クライアントのインストールパッケージを変更する前にダウンロードページのプラットフォーム説明を確認し、現在のプラットフォームとクライアントの種類を確かめてから、基準手順で設定を復元します。

カスタムアウトバウンド：ローカルサービスと明確なフォールバック経路をつなぐ

カスタムアウトバウンドが必要な場面

通常の利用では、現在のサーバーから生成されるプロキシアウトバウンド、直接接続、ブロックで十分です。カスタムアウトバウンドは、特定の通信を本機の別のSOCKSサービスへ渡す、特定の対象に独立した出口を割り当てる、制御可能なフォールバック経路を作るなど、明確な技術要件がある場合に適しています。サブスクリプション設定の誤りを隠すために使うものではありません。現在のサーバー自体が接続できない場合は、まずプロトコルパラメーターとネットワーク到達性を直してから、アウトバウンドの追加を検討します。

カスタムアウトバウンドを設計するときは、3つの情報を先に明確にします。入口のリクエストがどのルールに一致するか、対象アウトバウンドがどのプロトコルとアドレスを使うか、アウトバウンドが失敗した場合にフォールバックを許可するかです。各アウトバウンドには、local-socksやdirectのように一意で意味の分かるタグを付けます。proxy1やproxy2のような意味のない名前は使わないでください。設定が増えると、ログから実際の経路を判断しにくくなります。

ローカルSOCKSアウトバウンドへ接続する

次の例では、domain:service.exampleに一致する通信を、本機の127.0.0.1:1081で動作するSOCKSサービスへ渡します。このローカルサービスは事前に起動しておく必要があり、通信をv2rayNの現在の入口へ再び送ってループを作らないようにしてください。待ち受けアドレスにループバックインターフェースを使うと、アクセス範囲を制限できます。LAN内のサービスへ接続する必要がある場合は、ファイアウォールとアクセス制御を別途検討してください。

{
  "outbounds": [
    {
      "tag": "local-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1081
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:service.example"
        ],
        "outboundTag": "local-socks"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

保存前にJSONの構造、ポートの型、タグのスペルを確認します。ポートは数値で指定し、引用符付きの文字列にしないでください。v2rayNの設定断片統合機能を使う場合は、統合位置も確認します。完全なoutbounds配列でクライアント生成設定を上書きすると、現在のサーバーに対応するプロキシアウトバウンドが削除される可能性があります。クライアントが対応するカスタムアウトバウンドまたは高度な設定の入口を使い、生成後の実行設定で既存のアウトバウンドが残っていることを確認する方が安全です。

ループと二重プロキシを避ける

ループは通常、2つのローカルサービスが互いに通信を渡すことで発生します。たとえばv2rayNの入口が127.0.0.1:10808で待ち受け、カスタムアウトバウンドが別のローカルサービスへ接続し、そのサービスの上流が127.0.0.1:10808を指している場合です。ログには重複接続、ポート枯渇、接続タイムアウトがすぐに現れます。アプリから最終的なネットワーク出口まで、一方向の経路を描いてください。どの段階も上流の入口へ戻らないことを確認します。

システムプロキシと環境変数が、見えにくいループを作ることもあります。ローカルの上流プログラムがシステムプロキシを自動的に読み取ると、そのプログラムのアウトバウンド接続が再びv2rayNへ入る可能性があります。ローカル上流を実行するときは、システムプロキシを無視するか、プロセスに直接接続ルールを設定するかを明確にします。プロセスルールの対応状況はプラットフォームによって異なるため、補助として対象アドレスの直接接続も用意します。ただし、アドレスが変わる場合は保守が必要です。

フォールバックは自動的な「耐障害」ではない

複数のアウトバウンドが並んでいても、カーネルが失敗した回線から次の回線へ自動的に切り替えるとは限りません。フォールバック、負荷分散、ヘルスチェックには、それぞれ対応するポリシーオブジェクトと観測可能な条件が必要です。明確な設定がなければ、各ルーティングは確定した選択として扱ってください。一致した後は指定されたアウトバウンドへ渡されます。トラブル対処を明確にするため、初期段階ではカスタムアウトバウンドを1つだけ設定し、安定してからポリシーを追加します。

フォールバック経路では、接続失敗とアプリケーション応答の失敗も区別する必要があります。カーネルが確認できるのは通常、ネットワーク接続が確立したかどうかであり、すべてのアプリケーション層の状態を「切り替えるべき」と判断できるわけではありません。積極的すぎるフォールバックは同じリクエストを複数回送る可能性があり、送信操作を伴う処理には適さないことがあります。戦略はプロトコルと処理内容に応じて設計し、すべての失敗を再試行可能とみなさないでください。

起動ログから単一リクエストまで検証する

カスタム設定を保存したら、まずカーネルを再起動し、設定読み込み段階を確認します。未知のフィールド、存在しないタグ、ポート形式の誤り、配列の上書きが表示された場合は、最初のエラーから修正します。カーネルが正常に起動したら、対象リクエストを1つだけ送り、ログに対象ドメイン、適用ルール、local-socksタグが表示されることを確認します。その後、ローカルSOCKSサービスを停止して再度リクエストし、エラーがローカルポートを明確に指すかを確認します。この逆向きのテストにより、通信が実際にカスタムアウトバウンドを通ったことを証明できます。

カーネルを起動してすぐ終了する場合は、ログを1行ずつ確認して設定エラーを特定する方法を参照してください。システムプロキシを有効にした後、ブラウザーとターミナルの動作が一致しない場合は、ブラウザーとターミナルを分けて調べる方法をお読みください。カスタムアウトバウンドの設定後は、動作する設定のコピーを保存し、依存するローカルポートとサービスの起動順序を記録します。システム再起動、クライアント移行、ポート競合が起きても、明確な基準状態へすぐに戻せます。