サブスクリプショングループ、ルーティング、DNS、TUN設定

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

サブスクリプショングループは「設定元」を、サーバーフィルターは「一覧に表示するもの」を整理します。両者は分けて設定してください。グループは取得元を管理し、フィルターは表示範囲だけを変えるもので、設定の削除まで担わせるべきではありません。

安定したグループ境界を作る

v2rayNに複数のサブスクリプションをインポートする場合は、まず取得元ごとに独立したグループを作り、すべてのサーバーをデフォルトグループへ長期間詰め込まないようにします。グループ名は「日常用」「仕事・テスト」「手動設定」のように用途や取得元を表すものにし、変わりやすい地域名は避けてください。地域、プロトコル、回線などの分類はフィルタールールで扱う方が適しています。こうしておけば、購読URLを変更しても、既存のルーティングや絞り込みのロジックが名前の変更に引きずられて壊れません。

サブスクリプションを追加したら、まず対象グループだけを手動更新し、そのグループに設定が追加されたか確認します。問題がないことを確認してから自動更新を有効にしてください。更新結果が空でも、すぐに古いグループを削除しないでください。購読URLが完全か、現在のグループで除外ルールが有効になっていないか、更新リクエストに現在のシステムプロキシが必要かを確認します。詳しい確認手順はサブスクリプション更新失敗時のチェックリストを参照してください。新しいデータの検証が終わるまで旧データを残しておけば、誤った更新で利用可能な設定を上書きする事態を避けられます。

手動で追加した VMess、VLESS、Trojan、Shadowsocks の設定は、独立したグループに入れることをおすすめします。サブスクリプション更新では通常、リモートの内容を基準に一覧が再構築されるため、手動設定を購読グループに混在させると、各レコードがローカル由来か購読由来か判断しにくくなります。独立グループにしておけば、エクスポート、移行、通信パラメータの項目別確認も容易です。

包含・除外・正規表現フィルター

フィルターには通常、「包含キーワード」と「除外キーワード」の2種類があります。包含条件は候補を絞り、除外条件は不要と分かっているタグを取り除きます。まず除外条件を設定し、その後で包含条件を少しずつ追加するのがおすすめです。両方を設定した場合、通常は包含条件に一致し、かつ除外条件に一致しないレコードだけが表示されます。フィルターの対象は備考やサブスクリプションが提供するタグであり、サーバーの実際の所在地、プロトコルの機能、利用可能性を検証するものではありません。

単純なケースでは通常のキーワードを優先します。複数の語のうち「いずれか」を指定する場合は、正規表現の縦棒を使えます。たとえば 家用|办公 のように記述します。先頭に一致させる場合は ^、末尾に一致させる場合は $ を使います。正規表現の括弧、ドット、プラス記号には特殊な意味があるため、これらの文字そのものに一致させる場合はエスケープが必要です。設定後はフィルター結果の件数と先頭・末尾のレコードをすぐ確認し、範囲が広がりすぎていないか確認してください。

包含：^(家用|办公).*(VLESS|Trojan)$
排除：测试|到期|维护
説明：「家用」または「办公」で始まり、指定したプロトコルタグで終わるレコードだけを表示

フィルター後に一覧が空になった場合は、3段階で確認します。第1段階ではすべてのフィルター条件を一時的に消し、元の一覧が存在するか確認します。第2段階では通常のキーワードを1つだけ残し、備考欄にその語が本当に含まれているか確認します。第3段階で正規表現に戻し、式を部分ごとに追加します。最初から購読URL、グループ、正規表現を同時に変更すると、どの操作で結果が変わったのか分からなくなります。

並べ替え・選択・更新後の安定性

サーバーの並び順は画面上の表示順であり、ルーティングの優先順位ではありません。備考、アドレス、プロトコルで並べ替えても、現在選択されているサーバーはクライアントの状態によって決まります。サブスクリプション更新で一覧の順序が変わったり、レコード識別子が再生成されたりするため、「何行目」を長期的な選択条件にしないでください。分かりやすい備考、固定したグループ、再現可能なフィルタールールを使う方が安定します。

グループの設定が終わったら、各グループの更新方式、自動更新の有効・無効、フィルター条件を個別に確認します。頻繁に使うグループは定期更新を有効にし、短期テスト用グループは手動更新にすると、リモート側の変更で比較テストが中断されるのを防げます。更新前後でサーバー数に大きな差がある場合は、クライアントログとフィルター結果を確認してから現在の設定を切り替えてください。

2. ルーティングルールの実践と一致順序

ルーティングルールは接続を異なるアウトバウンドへ振り分けます。結果は宛先情報、ルールの順序、アウトバウンドタグによって決まります。設定時は先に方針を定め、その後で構文を記述してください。

上から順に一致する仕組みを理解する

ルーティングエンジンは通常、ルールを上から順に確認し、条件を満たした最初のルールでアウトバウンドを決定します。後続のルールは処理されません。具体的なルールを上に、対象範囲の広いルールを下に置き、最後に明確なデフォルト方針を残します。たとえば、LANアドレスの直接接続は広範なプロキシルールより前に置きます。特定ドメインの直接接続・ブロックルールも、分類集合より前に配置してください。適用範囲の広いルールを先頭に置くと、後の詳細ルールは構文が正しくても適用されません。

よく使う一致対象には、ドメイン、IP、ポート、ネットワーク種別、プロセスがあります。ドメインルールには完全修飾ドメイン、サフィックス、キーワード、geosite分類を使用できます。IPルールには単一アドレス、CIDRネットワーク、geoip分類を使用できます。ポートは宛先ポートだけを表し、アプリの種類までは判断できません。プロセス一致は、OSとクライアントがプロセス情報を取得できるかどうかに依存するため、プラットフォームをまたぐ移行で唯一の条件にしないでください。

説明可能な基本順序

基本的な振り分けは3層から始められます。第1層ではプライベートアドレスを処理し、プリンター、ルーター、LANサービスがリモートのアウトバウンドへ送られないようにします。第2層では明確なドメイン分類を処理し、第3層でデフォルトのプロキシアウトバウンドを設定します。出所の不明なルールセットを一度に大量追加しないでください。ルールが増えるほど優先順位の衝突を特定しにくくなり、リソース更新の管理も難しくなります。

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

domainStrategy は、ドメインルールに一致しなかった場合にIP解決を続行するかどうかを決めます。IPIfNonMatch では、ルーティングがまずドメインルールを試し、一致しなければDNSでアドレスを取得してIPルールを確認します。geositeとgeoipを併用する構成に適しています。ドメインだけで判定する設定では、宛先IPに依存するルールが処理されない場合があります。すべてのドメインを事前解決すると、DNS問い合わせが増え、接続のタイミングも変わります。

ルールが適用されない場合の切り分け

まず、実際の宛先がドメインなのか、すでに解決済みのIPなのかを確認します。ブラウザーは通常ドメインを渡しますが、一部のアプリは自分で解決してからIPへ直接接続するため、ドメインルールには元の名前が現れません。次に、ルールが指定するアウトバウンドタグが実際に存在するか確認します。大文字と小文字を区別する場合、proxy と Proxy は別の宛先です。最後にルールの順序を確認し、特に先頭に全ポート、全ネットワーク、または広範なドメインを覆うルールがないか調べます。

単一ルールをテストするときは、条件を一時的に絞ります。たとえば分類ルールを1つの完全なドメインに置き換え、ログレベルをルーティング判定を確認できる状態にして、新しい接続を1回行い、選択されたアウトバウンドを確認します。既存の接続は古い経路を再利用する可能性があるため、ルール変更後は対象アプリの接続を閉じるか、クライアントのコアを再起動してください。ページを更新するだけでは、新しい接続が作られるとは限りません。

UDPとTCPで異なるルールを使うことはできますが、アプリの動作を明確に把握する必要があります。ドメイン解決は通常UDPを使いますが、TCPへフォールバックする場合もあります。リアルタイム通信では複数の宛先ポートを同時に使うことがあります。TCPだけを特定のアウトバウンドへ通すと、関連するUDPリクエストがデフォルトルールへ流れ、「ページは開くが一部機能に問題がある」状態になることがあります。切り分けではドメインだけでなく、ネットワーク種別、宛先ポート、最終アウトバウンドも確認してください。

3. DNS設定の最適化と問い合わせ経路

DNS設定はサーバーアドレスを入力するだけではありません。少なくとも次の3点を確認する必要があります。誰が問い合わせを開始するのか、どのアウトバウンドを経由するのか、返された結果をルーティングにどう利用するのかです。

システム解決とコア解決を区別する

システムプロキシモードでは、アプリによってはシステムDNSを自分で呼び出し、解決したIPをプロキシへ渡します。一方、ドメインをそのままプロキシクライアントへ渡すアプリもあります。2種類のリクエストがコアに入る時点で保持している情報は異なります。前者ではIPしか残らず、ルーティングはgeoipやネットワークルールに頼ることになります。後者ではドメインが残るため、geosite、サフィックス、完全なドメインルールを先に使えます。同じサイトがアプリによって異なるアウトバウンドへ進む場合は、まずアプリ側とコア側のどちらで名前解決が行われているか確認してください。

TUNモードはより多くのシステムトラフィックを取り込めるため、DNS経路も統一しやすくなります。ただし、システムDNS、TUN DNS、ブラウザー内蔵の解決方式が同時に競合しないようにする必要があります。目的はすべての問い合わせを同じサーバーへ送ることではなく、解決結果とルーティング方針を一致させることです。ドメイン分類で振り分けるなら、できるだけドメイン情報を保持します。宛先IPで振り分けるなら、判定に使う解決結果が安定して利用できるようにします。

サーバー種別と一致条件

DNSサーバーはドメイン条件ごとにグループ化できます。直接接続するドメインにはローカルネットワークから到達しやすいリゾルバーを使い、それ以外はプロキシアウトバウンド経由で問い合わせます。設定時は、サーバーアドレス自体をどのように解決し接続するかも明確にしてください。暗号化DNSのホスト名に別のDNS問い合わせが必要な場合は、到達可能なブートストラップ用アドレスを用意しないと、循環依存が発生します。

queryStrategy はIPv4、IPv6、または両方を返すかどうかを制御します。現在のネットワークと対象サービスの実際の到達性に基づいて選択してください。IPv4だけを返すとデュアルスタック環境での不確定な分岐を減らせますが、IPv6のみを提供する宛先は除外されます。両方を返す場合は、システムのルーティングとアウトバウンド経路がデュアルスタックを正しく処理できなければなりません。ログに特定のアドレス種別が出たという理由だけで、もう一方を強制的に無効にしないでください。まずローカルネットワークで安定した接続が可能か確認します。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ]
      },
      {
        "address": "1.1.1.1",
        "domains": [
          "geosite:geolocation-!cn"
        ],
        "skipFallback": true
      },
      "localhost"
    ]
  }
}

expectIPs は、応答アドレスが想定した分類に合うかを検証します。結果を特定地域へ強制的に変更するものではなく、条件に合わない場合に名前解決処理が別の候補サーバーを試すようにする機能です。skipFallback は、そのサーバーを通常のフォールバック処理に参加させない指定で、明確なドメイン集合専用のリゾルバーに適しています。対応フィールドは使用するコアの設定形式によって異なるため、カスタム断片をインポートする前に、v2rayNが生成した完全な設定と起動ログを確認してください。

キャッシュ、フォールバック、汚染された応答の見分け方

DNSを変更しても結果がすぐ変わらない場合は、ブラウザー、システム、クライアントのコア、上流リゾルバーのいずれかがキャッシュを保持している可能性があります。切り分けでは、まずテスト対象アプリの既存接続を閉じてからコアを再起動し、必要に応じてシステムDNSキャッシュを消去します。同じページを連続更新した結果だけで判断しないでください。接続プールやキャッシュによって新しい設定が使われないことがあります。

名前解決の異常は、タイムアウト、空のレコード、到達不能なアドレス、アドレス種別の不一致に分けられます。タイムアウトではDNSリクエストに使うアウトバウンドとファイアウォールを確認します。空のレコードではドメイン自体と問い合わせ種別を確認します。到達不能なアドレスではルーティングテーブルと対象ネットワークを確認します。種別の不一致では queryStrategy を確認してください。ログ上は解決に成功していて接続に失敗する場合、問題はすでにDNS層からルーティング、アウトバウンド、またはトランスポート層へ移っています。

DNS設定を評価するときは、少なくとも3種類の対象を選びます。明確に直接接続するドメイン、明確にプロキシ経由にするドメイン、特定のアドレスファミリーだけを提供するテスト対象です。それぞれについて、解決結果、一致したルール、最終アウトバウンドを記録します。よく使うサイトを1つ試すだけでは、フォールバック順序や境界条件が正しいとは証明できません。

4. TUNモードの取り込み範囲とシステムルーティング

システムプロキシは、プロキシ設定を参照するアプリにだけ影響します。TUNモードは仮想ネットワークインターフェースを通じて、より広いトラフィックを取り込みます。両者は単純な強弱の関係ではなく、異なる接続方式です。

TUNを有効にするタイミング

ブラウザー、ダウンロードツール、多くのデスクトップアプリがシステムプロキシを読み取れる場合は、経路が短く個別に終了しやすいシステムプロキシを優先します。ゲームランチャー、コマンドラインプログラム、一部のストアコンポーネント、固定的に直接接続するアプリがシステムプロキシを読み取らない場合に、TUNを検討してください。有効化する前に通常のシステムプロキシが利用できることを確認します。基本経路を検証しないまま仮想NICとルーティングテーブルを追加すると、切り分け範囲が広がるだけです。

TUNを起動すると、クライアントは仮想インターフェースを作成し、設定に従ってシステムルートを書き込みます。トラフィックはまず仮想インターフェースへ入り、その後コアがルーティングとアウトバウンドを判定します。DNSもコア処理へリダイレクトされる場合があります。クライアント終了時には元のルートへ戻る必要があります。プロセスが異常終了すると、一時インターフェースやルートが残り、クライアント終了後もネットワークが不安定になることがあります。その場合は、まずクライアントを再起動してTUNを正常に終了し、その後システムのネットワーク設定を確認してください。

よく使うパラメータの意味

stack はTUNが使用するネットワークスタックの実装を表します。実装ごとにTCP、UDP、デュアルスタック、システム互換性の重点が異なります。通常はクライアント推奨値を維持し、特定のアプリが接続できない、UDPに異常がある、高負荷になるといった場合にだけ個別に切り替えてテストします。ネットワークスタックを切り替えた後はコアを完全に再起動する必要があり、既存の接続は自動移行されません。

autoRoute はルートを自動追加し、対象トラフィックを仮想インターフェースへ送ります。無効にするとシステムルートを自分で管理する必要があるため、明確なネットワーク構成がある環境向けで、初回設定には適しません。strictRoute は迂回経路をより厳密に制限し、TUNから流出するトラフィックを減らしますが、LAN検出、仮想マシン、その他のネットワークツールに影響する場合があります。mtu は1パケットの最大転送単位を制御します。大きすぎると一部の経路で断片化やパケット損失が発生し、小さすぎると余分なオーバーヘッドが増えます。

LAN、仮想マシン、その他のネットワークツール

TUNを有効にしてルーターの管理画面、ネットワークストレージ、プリンターへアクセスできない場合は、まず geoip:private が直接接続になっているか確認し、厳格ルートがローカルネットワークを遮断していないか調べます。LANでは一般的でないプライベートネットワークを使うこともあるため、分類データだけに頼らないでください。必要に応じて、実際のネットワーク向けに 192.168.50.0/24 のようなCIDR直接接続ルールを追加します。ルールはデフォルトのプロキシルールより前に置く必要があります。

仮想マシン、コンテナ、企業ネットワーク用クライアントもルーティングテーブルを書き換えます。複数のツールを同時に有効にすると、システムはプレフィックス長やメトリックに基づいて異なるインターフェースを選ぶことがあります。すべてのツールを何度もオン・オフして運任せにしないでください。まずTUN起動前後のルーティングテーブルの差分を記録し、ネットワークスタックを変更する他のソフトを終了して、単独で正常に動作するか確認します。単独で正常なら、他のコンポーネントを1つずつ戻します。

スリープからの復帰、有線から無線への切り替え、自宅ネットワークから職場ネットワークへの切り替え後は、以前のインターフェースインデックスが変わることがあります。接続が停滞した場合は、まずTUNを無効にして仮想インターフェースが終了するまで待ち、その後もう一度有効にします。クライアントがインターフェース作成失敗を繰り返す場合は、実行権限、システムのネットワークコンポーネントの状態、同名の残存インターフェースがないかを確認してください。

5. FakeDNSの仕組みと適用範囲

FakeDNSはドメインに一時的な予約アドレスを割り当て、宛先IPしか持たない接続から元のドメインを復元できるようにします。主に、アプリが名前解決した段階でドメイン情報が失われる問題を解決します。

問い合わせから接続までのマッピング

FakeDNSを有効にすると、取り込まれたDNS問い合わせは実際の宛先アドレスをすぐにアプリへ返さず、専用アドレスプールから一時アドレスを返します。アプリがそのアドレスへ接続すると、コアはマッピングテーブルから元のドメインを復元し、ドメインルーティングと実際の名前解決を実行します。この仕組みにより、TUN環境でのドメインルールが安定します。アプリが先に解決してから接続しても、コアは接続が最初に対応していた名前を把握できるためです。

一時アドレスは現在のマッピングが有効な間だけ意味を持ちます。対象サーバーの実アドレスとして保存、共有したり、長期ルールへ書き込んだりしないでください。アプリが解決結果を長時間キャッシュし、コアのマッピングが期限切れになると、接続に失敗することがあります。アプリを再起動するかDNSキャッシュを消去すると、新しいマッピングを作成できる場合があります。クライアントのコアを再起動した後は、古い一時アドレスが元のドメインに対応しなくなることもあります。

アドレスプールと例外ドメイン

FakeDNSのアドレスプールは、現在のLAN、仮想マシンネットワーク、コンテナネットワーク、その他のトンネルのアドレス範囲と重複させないでください。重複すると、システムが一時アドレスを誤ったインターフェースへ送り、ログにも接続がコアへ入った形跡が現れないことがあります。プールを選ぶ前に、現在の無線ネットワークだけでなく、本機のルーティングテーブルと普段使うネットワーク環境を確認してください。

すべてのドメインがFakeDNSに適しているわけではありません。LAN機器名、社内ドメイン、特定のシステムリゾルバーで処理する必要がある名前、実IPを使ってローカル判定するアプリは例外にできます。例外リストは正確に保ち、完全なドメインまたは明確なサフィックスを優先してください。広すぎる分類をまとめて除外すると、FakeDNSがドメインを復元する効果が弱まります。

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

198.18.0.0/15 はベンチマーク用ネットワークに使われることが多く、実在する対象の所在地を表すものではありません。設定前に、現在の仮想ネットワークで使われていないことを確認してください。poolSize は管理できるマッピング数を決めます。一般的なデスクトップ利用で、むやみに大きくする必要はありません。プールを大きくしても1回の名前解決が速くなるわけではなく、競合範囲の確認が難しくなります。

実DNS、スニッフィング、ルーティングとの関係

FakeDNSは実DNSの代わりにはなりません。まずアプリへ一時アドレスを返し、コアは接続を準備する際に実際の宛先アドレスを取得します。実際の解決に使うサーバー、問い合わせ方針、アウトバウンド経路はDNS設定によって決まります。実際の名前解決がタイムアウトすると、アプリからは一時アドレスへの接続失敗に見えることがあります。そのため、切り分けではFakeDNSのマッピングと後続の解決ログを同時に確認してください。

プロトコルスニッフィングでも、TLSハンドシェイクやHTTPリクエストからホスト情報を読み取り、一部のトラフィックでドメインを復元できます。ただし、トラフィックに判別可能なフィールドが存在する必要があります。FakeDNSは接続確立前にマッピングでドメインを復元するため、動作する段階が異なります。一方を有効にしたからといって、もう一方も必ず有効にする必要はありません。実際にログで不足している情報に基づいて設定し、関連するスイッチをすべて同時に有効にしないでください。

FakeDNSが適しているか判断するには、まず明確なドメインルールを1つ選び、無効な状態でTUN接続がIPルールにしか一致しないか確認します。次にFakeDNSを有効にし、アプリのキャッシュを消去して新しい接続を作り、ログでドメインが復元され、想定したアウトバウンドに一致するか確認します。ドメインがすでに安定してコアへ渡っているなら、FakeDNSを追加しても効果は限定的です。

6. 複数購読の管理と更新運用

複数購読の管理で重要なのは、アドレスを増やすことではなく、更新、絞り込み、切り替え、ロールバックを追跡可能にすることです。各サブスクリプションには独立した範囲と明確な用途を持たせてください。

命名・更新・責任の分離

サブスクリプション名には「日常用メイン」「一時テスト」「手動アーカイブ」のように用途と取得元の区分を含めると管理しやすくなります。更新日時を名前に入れないでください。日時はすぐ古くなり、自動フィルタリングも難しくなります。同じ取得元が異なるプロトコルや用途の購読を提供している場合も、別々にインポートし、各グループを独立して更新・停止できるようにします。

すべてのグループを同じ短い間隔で自動更新する必要はありません。メインのグループは安定した周期で更新し、テストグループは手動で実行します。一時的に使わないグループは、自動更新を無効にしてURLを残しておくこともできます。更新時にはクライアントが購読URLへアクセスするため、「サブスクリプション更新時にプロキシを使用する」または同等の項目が現在のネットワークと一致しているか確認してください。現在のサーバーが使えない状態で、そのサーバー経由の購読更新に依存すると循環が起こります。更新URLへ直接アクセスできる経路、または古い設定から手動復旧できる手段を残しておきましょう。

一括更新を実行する前に、まず1つのグループだけを更新して結果を確認します。成功と表示されたかだけでなく、レコード数に異常がないか、備考が変わっていないか、プロトコルフィールドが完全か、フィルターが引き続き一致するかも確認してください。リモートの購読形式が変わると、クライアントはダウンロードに成功しても解析結果が空になることがあります。取得成功とサーバー一覧の生成成功は同じではありません。

重複排除と衝突への対応

異なるサブスクリプションに、アドレス、ポート、プロトコルは同じでも備考が異なるレコードが含まれる場合があります。逆に、備考は同じでも通信パラメータが異なることもあります。備考だけで重複排除すると有効な設定を誤って削除し、アドレスだけで重複排除するとポート、ユーザー識別子、トランスポート、安全設定を見落とします。長期管理では、プロトコル、アドレス、ポート、認証フィールド、通信方式、安全設定を1組の設定フィンガープリントとして扱い、クライアントに表示される各フィールドを比較してください。

重複レコードを見つけても、すぐに取得元を削除する必要はありません。まず、どのグループを長期更新用にするか、もう一方が一時バックアップにすぎないかを決めます。単一レコードを削除しても、次回のサブスクリプション更新で再び現れることがあります。本来の管理場所は、グループフィルターまたは購読元です。備考が衝突する場合は、クライアントで可能な範囲でグループ接頭辞を使って区別し、リモートで生成されたコアパラメータは変更しないでください。

安全なロールバックと移行

サブスクリプションの取得元を変更したり、広範なフィルターを調整したりする前に、現在のクライアント設定とルーティング設定をエクスポートします。エクスポートファイルには購読URLやサーバー認証情報が含まれる可能性があるため、管理された場所に保管し、公開共有しないでください。復元時は新しいグループへインポートし、使用中のグループを直接上書きしないでください。接続、ルーティング、DNSを検証してから、古い取得元を停止します。

デバイス間で移行する場合は、「サーバー設定」と「クライアントの環境設定」を分けて考える必要があります。サーバーリンクには通常、システムプロキシモード、TUNパラメータ、ルーティングルール、DNS、自動起動、画面フィルターなどは含まれません。購読だけをインポートしても、作業環境全体を複製することはできません。サブスクリプショングループ、現在のサーバー、ルーティングルール、DNS、TUN、自動更新周期、カスタムアウトバウンドを分けて記録する移行チェックリストを用意するのがおすすめです。

v2rayNはWindows、macOS、Linuxのデスクトップ環境に適しています。Androidではv2rayNGを使用するか、コアの要件に応じてv2flyNGを選べます。クライアントによってメニュー構成やインポート可能なフィールドは完全には一致しません。ルーティングを移行する際は、デスクトップ設定全体をそのまま使えると考えず、移行先クライアントが対応するルール表現へ変換してください。クライアントの入口とプラットフォーム別の説明はダウンロードページで確認できます。

7. カスタムアウトバウンドとチェーン選択

アウトバウンドは、接続が最終的にコアからどのように外へ出るかを定義します。よく使うタグにはプロキシ、直接接続、ブロックがあります。カスタムアウトバウンドでは、タグを一意にし、参照先を一致させ、循環を避けることが重要です。

アウトバウンドタグとルーティング参照

各アウトバウンドは tag によってルーティングルールから参照されます。タグには proxy、direct、block、dns-out のような短く安定した英語名を使ってください。タグを変更したら、すべてのルーティングルール、DNSアウトバウンドの参照、チェーンプロキシ設定、統計ポリシーも合わせて変更します。起動ログの「アウトバウンドが見つからない」というエラーは、綴りの不一致や設定統合時のタグ上書きが原因であることが多いです。

直接接続アウトバウンドは本機のネットワークから直接接続し、ブロックアウトバウンドは一致したトラフィックを明示的に拒否します。ブロックルールは正確に保ち、まず完全なドメインや特定ポートからテストしてください。範囲が広すぎると、通常の接続が明確なエラーではなく無応答に見えることがあります。プロキシアウトバウンドは通常、現在のサーバー設定から生成されます。手動編集する場合はトランスポート、安全設定、認証フィールドを忘れないでください。

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

freedom アウトバウンドの domainStrategy は、直接接続の段階でドメインをどう処理するかを決めます。ルーティング段階ですでに解決済みなら、得られたアドレスをそのまま使う場合があります。ドメインが残っていれば、アウトバウンドがこの方針に従って解決します。グローバルDNSやルーティング方針と連携させ、同じドメインが段階によって異なる結果にならないようにしてください。

カスタムアウトバウンドの実用例

独立した直接接続アウトバウンドは特定のインターフェースやアドレスにバインドでき、多くのNICを使う環境に利用できます。独立したブロックアウトバウンドは明確に不要な宛先を処理し、DNS専用アウトバウンドは名前解決を指定経路へ送れます。アウトバウンドを追加するたびに、入口となるルール、依存条件、フォールバック方法を書き留めてください。アウトバウンドを作るだけでルーティング参照がなければ、自動的に接続へ参加することはありません。

複数NICをバインドする場合は、選択した送信元アドレスが現在アクティブなインターフェースに実際に属しているか確認します。ネットワーク切り替え後に古いアドレスが無効になると、バインドしたアウトバウンドだけが接続できなくなります。異なるネットワーク間を長期的に移動するデバイスでは、変わりやすい送信元アドレスを固定しない方がよいでしょう。システムルーティングに出口を任せ、インターフェース分離が必要な場合だけバインドする方が安定します。

チェーンアウトバウンドと循環リスク

チェーンプロキシは、あるアウトバウンドの接続を別のアウトバウンド経由で確立する構成です。明確な上流関係がある場面には適していますが、ハンドシェイク、名前解決、障害点が増えます。設定前に各区間が単独で動作することを確認してから、経路を組み合わせてください。基礎となるアウトバウンドが不安定な場合、チェーン構成にすると問題の判断がさらに難しくなります。

チェーン関係を閉路にしないでください。たとえばAがB経由で接続し、Bの接続がルーティングによってAへ戻ると、失敗するまで再帰が続きます。循環を避けるには、上流サーバーのアドレスに対して、より具体的な直接接続または指定アウトバウンドのルールを設定し、通常のプロキシルールより前に置きます。上流アドレスがドメインの場合は、その名前解決リクエストがどのアウトバウンドを通るかも考慮してください。

チェーンアウトバウンドをテストするときは、まずログで接続の順序を確認し、対象リクエストと上流接続がそれぞれどのルールに一致したかを確認します。最終的にページが開いたかだけで正しさを判断しないでください。システムが想定した経路を迂回し、デフォルトのアウトバウンドを使っている可能性があります。デフォルトのフォールバックを短時間無効にすると抜け漏れを見つけやすくなりますが、テスト終了後は制御可能なフォールバック方針へ戻してください。

完全なカスタム設定を作る前に、v2rayNが自動生成した設定を比較用に残すことをおすすめします。まず生成結果をエクスポートし、outbounds、routing、dns の3つのブロックを確認してから、最小限の変更で新しいタグを追加します。保存後はコアの起動ログを確認し、設定の解析に成功したか確認してください。起動に失敗した場合は、直近に追加した1つのブロックから戻し、構造全体を同時に書き換えないでください。

8. 設定の検証、ログの読み方、ロールバック手順

上級設定が完了したら、段階的なテストで各工程が有効であることを確認します。設定の読み込みから始め、名前解決、ルーティング、アウトバウンド、システムへの取り込みの順にテストしてください。

まずコアが設定を受け入れたか確認する

設定を保存しただけでは、コアが新しい設定を使用しているとは限りません。最初に起動ログを確認し、設定ファイルが解析できること、ポートが競合していないこと、参照先のアウトバウンドタグが存在すること、リソースファイルを読み込めることを確認します。構文エラーでは、フィールドの位置や周辺構造が示されることが多いです。エラーが出たら直近の変更から戻し、特にJSONのカンマ、配列とオブジェクトの階層、タグの綴り、未対応フィールドを確認してください。

コアが正常に起動したら、ローカルのリスニングポートとシステムプロキシの向き先が一致しているか確認します。クライアントは動作中と表示されているのにアプリが接続できない場合、システムプロキシが古いポートを参照しているか、別のプログラムがリスニングアドレスを使用している可能性があります。TUNモードでは、仮想インターフェースが作成され、ルーティングテーブルが書き込まれ、DNSの取り込みに失敗していないことも確認してください。

段階ごとにテストし、1つの結果で全体を判断しない

第1層では購読とサーバー設定をテストします。接続可能と分かっているレコードを1つ選び、ルーティングを最小構成にします。第2層ではDNSをテストし、直接接続するドメインとプロキシ経由のドメインを別々に問い合わせ、返された種別と使用されたリゾルバーを記録します。第3層ではルーティングをテストし、完全なドメインに一時ルールを追加してログで一致を確認します。第4層ではシステムへの取り込みをテストし、まずシステムプロキシ、次にTUNを有効にします。各層を通過してから次の設定を追加してください。

遅延テストで分かるのは、特定の探測方法でその時点に応答を受け取れたかどうかだけで、実際の接続の代わりにはなりません。単純な探測には応答しなくても実際のプロトコル接続は許可するサーバーや、探測は正常でも対象接続に失敗するサーバーがあります。設定の判断には、コアログ、接続確立の結果、アプリの挙動を組み合わせ、一覧の単一ステータスだけを見ないでください。

ルールを変更した後は、新しい接続を作成します。ブラウザーの接続プール、DNSキャッシュ、アプリのバックグラウンドプロセスが古い経路を再利用する可能性があります。確実なテスト方法は、テスト対象アプリを終了し、接続が解放されるまで待ってから再起動することです。必要に応じてコアも再起動します。問題がスリープ復帰やネットワーク切り替え後だけ発生する場合は、ネットワーク状態の変化を再現手順に含めてください。

最小限の実用構成を作る

最小構成には、利用可能なサーバー1台、プロキシアウトバウンド1つ、直接接続アウトバウンド1つ、プライベートアドレスの直接接続ルール、明確なデフォルト方針を含めます。DNSには単純で到達可能なサーバーを使い、FakeDNS、チェーンアウトバウンド、複雑なプロセスルールはまだ有効にしません。最小構成が正常なら、「サブスクリプションフィルター、ドメインルーティング、条件付きDNS、TUN、FakeDNS、カスタムアウトバウンド」の順に1項目ずつ戻します。

項目を1つ戻すたびに、変更内容、テスト対象、結果を記録します。設定メモに認証フィールドを保存する必要はなく、スイッチ、タグ、ルール順だけで十分です。こうしておけば、コアの更新やデバイス移行の際に、問題がバージョンの挙動変化、システムネットワークの変化、ローカルルールの調整のどれに由来するか判断できます。

検証チェックリスト
1. コアの起動ログに設定解析エラーがない
2. 現在のサーバーとローカルのリスニングポートが正しい
3. DNS問い合わせが想定したアドレス種別を返す
4. テストドメインが想定したルーティングルールに一致する
5. 対象接続が正しいアウトバウンドへ入る
6. システムプロキシを無効にするとネットワークが復旧する
7. TUNを無効にすると仮想インターフェースと一時ルートが終了する

よくある現象の切り分け方

すべてのアプリが接続できない場合は、まずコア、リスニングポート、サーバー設定を確認します。特定のアプリだけ異常なら、システムプロキシを読み取るか、自分でDNSを解決するか、UDPを使うかを確認します。LANだけ異常なら、プライベートネットワークの直接接続と厳格ルートを確認します。ドメインルールに一致しない場合は、アプリがIPしか渡していないか、FakeDNSまたはスニッフィングでドメインを復元できるかを確認します。サブスクリプション更新は成功したのに一覧が空なら、解決結果とグループフィルターを確認してください。

ログの情報が不足している場合は、短時間だけログレベルを上げて再現し、完全な接続を1回記録したら通常のレベルへ戻します。細かすぎるログを長期間維持するとファイルサイズが増え、重要なエラーが大量の正常記録に埋もれます。ログを共有する前に、購読URL、ユーザー識別子、サーバー認証パラメータ、ローカルファイルパスを削除してください。

それでも原因を特定できない場合は、まずFAQのトラブルシューティングを確認し、次にv2rayNメイン画面の機能一覧で設定場所を確認します。プロトコルフィールドの違いはVMess、VLESS、Trojan、Shadowsocksの比較を参照してください。問題を報告する際は、OS、クライアント名、取り込みモード、再現手順、加工済みのエラーログを含め、「使えない」とだけ書かないようにします。