まずDNS解決とトラフィックルーティングを切り分ける
V2Ray設定におけるDNSとルーティングは、連続して動作しますが別々の処理です。DNSはドメインをアドレスに変換し、ルーティングは接続をどのアウトバウンドへ渡すかを決めます。名前解決が正しくても、トラフィックが必ずプロキシを通るとは限りません。逆に、トラフィックがプロキシのルールに一致しても、それ以前の名前解決がリモートサーバーを経由したとは限りません。振り分けの問題を調べるときは、この2段階を分けて確認する必要があります。
アプリケーションがV2Rayへドメイン形式の宛先を渡すと、ルーティングモジュールはドメインルールだけでアウトバウンドを判断できます。ルールで宛先アドレスの判定が必要な場合や、アウトバウンドが接続を確立する前にアドレスを取得する必要がある場合に、内蔵DNSモジュールが名前解決を行います。設定の routing.domainStrategy がこの動作に影響します。代表的な値は AsIs、IPIfNonMatch、IPOnDemand ですが、対応範囲や具体的な挙動はカーネルのバージョンによって異なるため、使用中のバージョンのドキュメントを確認してください。
AsIs：ドメインを優先して保持し、IPルーティングルールとの照合のために能動的な名前解決は行いません。IPIfNonMatch：ドメインルールに一致しなかった場合だけアドレスを解決し、続けてIPルールを確認します。IPOnDemand：ルーティング判定にアドレスが必要になると早い段階で名前解決を行います。設定によっては問い合わせ数が増えます。
大半の「中国国内サイトは直結、それ以外はプロキシ」という設定では、IPIfNonMatch が理解しやすい出発点です。まず geosite のドメインルールを適用し、一致しなかった宛先だけDNSでアドレスを取得して、最後に geoip ルールで判定します。これによりドメインによる振り分けを維持しつつ、アドレスでの判定が必要な接続にも対応できます。
dns設定セクションの主要フィールド
dns.servers は設定全体の入口です。配列の各項目にはサーバーアドレスだけでなく、マッチ条件付きのオブジェクトも指定できます。オブジェクト形式では address、port、domains、expectIPs を設定できます。実際に利用できるフィールドはV2Ray、Xray、クライアントに組み込まれたカーネルのバージョンによって変わるため、設定を移行するときはクライアント画面のバージョンだけを基準にしないでください。
| フィールド | 役割 | 設定のポイント |
|---|---|---|
servers |
利用可能なDNSサーバーとマッチ条件を定義します | domains を持つサーバーが対象ドメインを優先して処理し、それ以外はデフォルトサーバーが処理します |
hosts |
指定したドメインに静的マッピングまたはドメインマッピングを提供します | 固定エントリや起動時の名前解決に適していますが、大量の動的アドレスの管理には向きません |
queryStrategy |
IPv4、IPv6、または両方のアドレスを問い合わせるかを制御します | ローカルネットワークとアウトバウンドの到達性に合わせる必要があります |
clientIp |
対応する仕組みを備えたDNSサービスへクライアントのサブネット情報を提供します | 位置情報の判定とプライバシーに関わるため、用途を理解せずに設定しないでください |
disableCache |
内蔵DNSキャッシュを制御します | 長期間無効にすると重複問い合わせが増えるため、通常は短時間の診断にのみ使用します |
hosts の処理は外部DNSへ問い合わせる前に行われます。少数の固定ドメインが必要とする起動時の依存関係を解消するのに適しています。たとえば、リモートDNSサービスの入口がドメイン形式で、そのドメイン自体を先に解決する必要がある場合です。このとき確認済みの固定アドレスで初期マッピングを作成すれば、「リモートDNSへ接続するには、まずリモートDNSのドメインを解決しなければならない」という循環を避けられます。
queryStrategy はネットワーク環境に合わせて設定します。安定したIPv4接続しか利用できないネットワークでは、UseIPv4 から始めると、到達できないIPv6アドレスを取得した後の待ち時間を減らせます。完全なデュアルスタック環境なら、両方を同時に問い合わせる設定も選べます。ここで決まるのはアドレスファミリーの選択であり、プロキシの振り分けではありません。IPv4だけを問い合わせる場合でも、ドメインは中国国内外のルールに応じて異なるDNSサーバーを選択できます。
中国国内ドメインはローカルDNS、それ以外はリモートDNSへ
以下はメイン設定に組み込めるDNSの例です。中国国内ドメインには geosite:cn を使ってローカルDNSサーバーを選び、応答範囲を geoip:cn で確認します。この専用ルールに一致しないドメインは、後段のリモートHTTPS DNSへ渡します。例のアドレスは構造の説明用なので、実際に導入する際は現在のネットワーク、カーネルのバージョン、リモート向けアウトバウンドから各サービスへ接続できることを確認してください。
{
"dns": {
"queryStrategy": "UseIPv4",
"servers": [
{
"address": "223.5.5.5",
"port": 53,
"domains": [
"geosite:cn"
],
"expectIPs": [
"geoip:cn"
]
},
{
"address": "https://1.1.1.1/dns-query",
"domains": [
"geosite:geolocation-!cn"
]
},
"https://1.1.1.1/dns-query"
]
}
}domains を持たない最後の項目がデフォルトのDNSサーバーです。前のルールで明示的に処理されなかったドメインを担当します。分類データがすべてのドメインを網羅することはないため、デフォルト項目を残すことが重要です。新しく登録されたドメイン、プライベートな業務ドメイン、分類データがまだ更新されていないドメインにも、明確な行き先が必要です。
この例では、同じリモートDNSアドレスを「中国国外ドメイン専用サーバー」と「デフォルトサーバー」に分けて記述し、マッチングの仕組みを分かりやすく示しています。実際の設定は、使用中のカーネルにおけるDNS選択の仕組みに応じて簡略化できます。同じアドレスの重複項目が想定どおり処理されないバージョンでは、デフォルトのリモートサーバーだけを残しても構いません。中国国内ドメインは1つ目に一致し、それ以外は自然にデフォルト項目へ入ります。
geosite:cn はドメイン分類であり、解決結果が必ず中国国内のアドレスになることを意味しません。中国国内のサイトでもグローバルCDNを利用している場合があり、解決結果はネットワークの場所によって変わります。反対に、中国国内分類に含まれないドメインが中国国内のノードを返すこともあります。したがって、ドメイン分類とアドレスの帰属は組み合わせて使う必要がありますが、どちらも絶対的な判定材料ではありません。
expectIPsで異常な応答を判定する方法
expectIPs は、DNSサーバーの応答に期待するアドレス範囲を指定します。中国国内ドメインをローカルDNSで解決する場合は、geoip:cn を設定できます。応答アドレスが期待範囲に合わない場合、カーネルは条件を満たさない結果として扱い、DNSサーバーの選択ロジックに従って別の候補を試します。これは誤った解決結果の影響を抑えるためのチェックであり、これだけですべての対策を行うスイッチではありません。
ルールの境界が明確な環境で特に有効です。たとえば、中国国内分類のドメインだけを担当するローカルサーバーなら、応答の多くは中国国内のアドレス範囲に入ると期待できます。明らかに合わないアドレスが返された場合は、リモートサーバーで再問い合わせするほうが合理的です。ただしCDN、越境サービス、Anycastによってアドレスの帰属は複雑になります。条件を厳しくしすぎると、正常な応答を異常と誤判定する可能性があります。
すべての中国国外ドメインに一律で geoip:!cn を付けることはおすすめしません。多くの国際サービスはアクセス地域に応じて近いノードを返すため、中国国内のアドレスが含まれることがあります。また、複数地域のアドレスを同時に返すドメインもあります。すべての結果に中国国外の範囲を強制すると、再問い合わせ、名前解決の失敗、接続遅延につながる可能性があります。
expectIPs の設定は、次の3段階で進められます。
- まず
domainsによるグループだけを設定し、各ドメインが実際に対象サーバーへ送られることを確認します。 - 次に、判定範囲が安定しているサーバーへ
expectIPsを追加し、よく使うサイトが誤判定されないか確認します。 - 最後にフォールバックの動作を確認し、異常な応答が適切な候補サーバーへ切り替わり、名前解決がそのまま終了しないことを確かめます。
expectIPs の追加後に断続的な失敗が起きた場合は、まず失敗したドメインが実際に返したアドレスを確認してください。そのうえで期待範囲を広げるか、該当ドメインを分類から外すか、そのサーバーのアドレス制限を取り消すかを判断します。サーバーの順番を何度も入れ替えて、分類ミスを隠すのは避けてください。
リモートDNS問い合わせをプロキシ経由にする
リモートDNSを dns.servers に記述しても、使用するDNSサービスが指定されるだけで、接続経路まで自動的に保証されるわけではありません。リモートDNSへの通信もルーティングとアウトバウンドを通ります。直接接続すれば、問い合わせはローカルネットワークの経路に影響される可能性があります。プロキシ経由にするなら、DNSサービスの宛先アドレスに明確なルールを設定してください。
以下のルーティング断片では、リモートDNSのアドレスを proxy というタグのアウトバウンドへ渡し、中国国内のドメインとアドレスは direct を通します。最後のルールで、それ以外のTCPおよびUDPトラフィックを受けます。ルールは上から順に評価されるため、リモートDNSのアドレスは、範囲の広い直結アドレスルールより前に置いてください。
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": [
"1.1.1.1"
],
"outboundTag": "proxy"
},
{
"type": "field",
"domain": [
"geosite:cn"
],
"outboundTag": "direct"
},
{
"type": "field",
"ip": [
"geoip:private",
"geoip:cn"
],
"outboundTag": "direct"
},
{
"type": "field",
"network": "tcp,udp",
"outboundTag": "proxy"
}
]
}
}これはルーティングの一部だけを示したものです。メイン設定には、タグが完全に一致する proxy と direct のアウトバウンドも必要です。タグは大文字と小文字を区別するため、存在しないタグを参照すると設定の読み込みに失敗したり、接続が想定どおり確立できなかったりします。
リモートDNSのサービス入口をドメイン形式で指定する場合は、起動時の名前解決も考慮する必要があります。カーネルはまず入口のアドレスを取得しなければ、HTTPS接続を確立できません。入口をアドレス形式で指定する、hosts で確認済みの起動時マッピングを提供する、システムDNSにこの段階だけを担わせる、といった方法があります。リモートDNSのドメインを、そのリモートDNS自身でしか解決できない構成にはしないでください。
プロキシサーバーのアドレスにも同じ起動時の依存関係があります。購読ノードがドメイン形式の場合、プロキシ経路が確立する前にV2Rayがノードのアドレスを取得しなければなりません。このようなドメインには信頼できる起動時の解決経路を用意し、まだ利用できないプロキシアウトバウンド経由での問い合わせを強制しないでください。
DNS汚染対策の重要な設定
汚染対策は、ローカルDNSを別のアドレスへ置き換えるだけではありません。少なくとも問い合わせ先の選択、通信経路、応答チェック、キャッシュ、実際の接続という5つの要素が関わります。どれか1つでも誤った経路を通ると、「最初は開くのに更新すると失敗する」「名前解決は正しいのに接続が直結になる」「ノードを切り替えても古いアドレスが使われる」といった現象が起こります。
ドメイン分類で問い合わせ先を振り分ける
中国国内ドメインには優先してローカルDNSを使うと、現在のネットワークに近いCDNアドレスを取得しやすくなります。それ以外のドメインにはリモートDNSを使い、ローカルの再帰解決経路による結果への影響を抑えます。未分類のドメインにもDNSサーバーが割り当てられるよう、分類ルールにはデフォルトの出口を用意してください。
リモート問い合わせを管理可能なアウトバウンドへ通す
通常のUDP問い合わせは、宛先サーバーが異なっていても途中のネットワーク経路の影響を受ける可能性があります。HTTPS DNSは暗号化通信を提供しますが、想定したアウトバウンドを通っているかは別途確認が必要です。サーバーアドレスを変更するだけで経路を確認しなければ、最終的な通信経路を判断するには不十分です。
キャッシュの調整は診断用であり、長期的な回避策ではない
V2Ray内蔵DNS、OS、アプリケーションはいずれも解決結果を保存する可能性があります。設定変更後すぐにテストすると、古い結果が使われ続けることがあります。カーネルを再読み込みし、システムDNSキャッシュを消去して、関連アプリを再起動してください。キャッシュ無効化を一時的に有効にすると問題の切り分けに役立ちますが、長期間無効にすると問い合わせ回数と初回接続までの待ち時間が増えます。
ブラウザーやアプリ独自の名前解決
一部のアプリは独自の暗号化DNS設定を使用するため、名前解決をOSやV2Rayへ渡さないことがあります。この場合、V2Rayから見えるのは後続の接続アドレスだけになり、ドメインによるルーティング能力も影響を受けます。テスト時はまずアプリの名前解決方式を確認し、内蔵DNSが実際に使われているかを判断してください。
v2rayNでの適用と確認の順番
v2rayNの購読はサーバー設定を提供し、DNSとルーティングは通常クライアント側の実行パラメーターに属します。購読を更新しても、カスタムDNSルールが自動的に維持されるとは限りません。使用している設定方式、ルーティング設定、クライアントのバージョンによって異なります。変更前に動作中の設定を保存し、変更後はシステムプロキシの切り替えだけで済ませず、カーネルを再読み込みしてください。
検証では、最初から大量のサイトをテストしないでください。まず中国国内分類に明確に属するドメインを1つ、次にリモートDNSで解決すべきドメインを1つ選び、それぞれのDNSログとルーティングログを確認します。確認項目は、使用されたDNSサーバー、解決されたアドレス、一致したアウトバウンドタグ、最終接続の成否です。
- 設定が正常に読み込まれ、ログに未知のフィールド、タグの不足、JSON形式のエラーがないことを確認します。
- 中国国内ドメインを問い合わせ、
geosite:cnを含むローカルサーバーオブジェクトに一致することを確認します。 - その他のドメインを問い合わせ、リモートのデフォルトサーバーへ入り、リモートDNSへの接続がプロキシアウトバウンドを通っていることを確認します。
- 実際の接続におけるルーティング結果を確認し、DNSはプロキシ経由なのに、後続ルールで実際の通信が直結へ変更されていないか確認します。
- テスト用ドメインを1つ切り替えるかキャッシュを消去し、古い結果の影響を除外します。
v2rayNGまたはv2flyNGを使用する場合も確認方法は同じですが、利用できる設定フィールドはアプリに組み込まれたXrayまたはv2flyカーネルのバージョンによって異なります。デスクトップ向け設定を、バージョンを確認せずにAndroid端末へそのままコピーしないでください。フィールドが認識されない場合は、まずカーネルの種類とバージョンを確認し、対応する設定形式へ調整します。
よくあるトラブルと切り分け方法
中国国内サイトの表示が遅くなった
まず、中国国内ドメインがリモートのデフォルトサーバーへ入っていないか確認します。geosite のデータが読み込まれていない、分類ファイルのバージョンが合っていない、ドメイン自体が登録されていないといった場合、デフォルト項目へ進みます。expectIPs の条件が厳しすぎて、ローカルサーバーが返した正常なCDNアドレスを拒否し、リモート問い合わせへ切り替わっていないかも確認してください。
リモートDNSを設定しても名前解決がおかしい
まず、リモート問い合わせのアウトバウンドを確認します。宛先アドレスが geoip ルールで先に直結へ振り分けられているか、ルール順序の誤りによって proxy に入っていない可能性があります。HTTPS DNSの接続失敗は、システム時刻の異常、宛先アドレスへのネットワーク到達不能、プロキシノードがまだ確立していないことでも起こります。
設定の起動時に名前解決がループする
多くの場合、プロキシノードのドメインやリモートDNSのドメインがプロキシ経由でしか解決できず、そのプロキシ自体も同じ解決結果に依存しています。解決策は、独立した起動時の名前解決経路を用意することです。ノードのドメイン、ローカルDNSサーバー、リモートDNSの入口という3者の依存関係を、直結段階から順に構築できるようにしてください。
アドレスは正しいのにサイトが誤ったアウトバウンドへ進む
DNSと実際の通信のルーティングは分けて確認する必要があります。ドメインが正しく解決されても、後続の geoip:cn ルールによって返されたアドレスが直結へ送られることがあります。また、より前のドメインルールですでに別のアウトバウンドが指定されている可能性もあります。ルーティングルールを上から順に確認し、最初に一致した項目を特定してください。最後のフォールバックルールだけを見て判断しないでください。
変更後しばらく結果が安定しない
多層キャッシュ、CDNによる複数アドレス応答、アプリ独自の名前解決が原因であることが多いです。関連アプリを終了して再起動し、V2Rayカーネルを再読み込みしてから、1つのテストドメインで繰り返し確認してください。新しい問い合わせがログに記録されているのに毎回アドレスが異なる場合、DNSサービスが正常に負荷分散を行っている可能性があります。アドレスが変わっただけで汚染と判断しないでください。
設定の最終チェック
DNSの振り分けが完了したら、まず中国国内ドメイン、ローカルネットワークのアドレス、リモートドメインそれぞれに明確な処理経路があることを確認します。続いて、リモートDNSの接続アウトバウンド、プロキシノードの起動時名前解決、デフォルトサーバー、最終フォールバックルーティングがすべて存在することを確認してください。最後は、Webページが開くかどうかだけで判断せず、ログで検証します。
保守しやすい設定は、通常シンプルに保ちます。DNSサーバーは少数に絞り、ドメイングループを明確にし、expectIPs の条件を必要最小限にして、順序の分かりやすいルーティングルールを使います。分類を細かくするほど保守コストは高くなり、条件を厳しくするほどCDNや動的アドレスによる誤判定が増えます。まず動作する2つの解決グループを構築し、実際のログを見ながら例外を追加するほうが、多数のルールを一度に詰め込むより安定します。
完全なJSON構造を引き続き確認する場合は、本サイトのJSONマニュアルと照らし合わせて dns、routing、outbounds の階層関係を確認できます。クライアント設定の読み込みに成功したら、購読ノード、システムプロキシ、ルーティングの振り分けを順にテストし、接続問題をすべてDNSのせいにしないようにしてください。