まず、アプリがドメイン名をどこへ渡すかを確認し、ローカルDNSとリモートDNSを設定します。最後にDNSリクエストと通信それぞれの接続経路を確認しましょう。設定をインポート済みなのに一部のサイトが開けない、または名前解決の結果がおかしい場合に役立つ手順です。中国国内向けの直接接続ではローカルDNS、海外向けでは必要に応じてリモートDNSを使うための確認項目を整理し、DNS汚染・DNS漏えい・通常の接続障害を切り分けます。
1. 名前解決・ルーティング・プロキシの出力先を区別する
DNSはドメイン名をIPアドレスに変換します。ルーティングは通信を直接接続にするか、プロキシ経由にするかを決めます。両者は関連しますが、同じ設定ではありません。リモートDNSのアドレスを入力しても、そのDNSリクエストが必ずプロキシ経由になるとは限りません。また、あるサイトをプロキシ経由に設定しても、ブラウザーが事前にシステムDNSで名前解決していないとは限りません。
この流れは確認する順序を示したもので、すべての通信で名前解決を先にローカルで行うという意味ではありません。HTTPプロキシやSOCKSプロキシは、受け取ったドメイン名をリモート側で処理できます。一方、IPアドレスで判定するルールでは、ローカルのコアが名前解決する場合があります。アプリが先に名前解決し、そのIPアドレスをプロキシへ渡す場合、クライアント側で元のドメイン名を利用できる範囲が狭まることがあります。
- クライアントとコアを区別する：v2rayNはデスクトップ向けの設定画面です。実際のDNS動作は、使用中のコア、実行設定、通信の取り込み方式によって異なります。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用するため、異なるコアのDNS項目をそのまま流用することはできません。
- 汚染と漏えいを区別する：DNS汚染とは、誤った応答や干渉を受けた名前解決結果が返されることです。DNS漏えいとは、想定外の経路で問い合わせが行われることです。結果が正しくても、問い合わせ経路が漏れる場合があります。
- 名前解決エラーと接続エラーを区別する：ログにドメイン名の名前解決タイムアウトがある場合は、まずDNSサーバーへの到達性を確認します。IPアドレスを取得できているのに接続がタイムアウトする場合は、ルーティング、ノード、宛先ポート、ネットワーク制限も確認してください。
2. ローカルDNS・リモートDNS・通信方式を選ぶ
「ローカルDNS」は通常、直接接続に使う名前解決サーバーを指し、必ずしもPC上で動作するサービスではありません。「リモートDNS」は通常、プロキシ接続に使う名前解決サーバーを指しますが、自動的にプロキシ経由になるわけではありません。用途を分けたうえで、通信プロトコル、サーバーアドレス、実際の接続経路をそれぞれ確認しましょう。
これらは各プロトコルで一般的なポートであり、クライアントの待ち受けポートとして一律に入力するものではありません。入力欄にDoHのアドレスを指定できるかどうかは、使用中のバージョンと項目の説明を確認してください。DoHがHTTPSを使うからといって、一般的なWebサイトのトップページをDNSエンドポイントとして使えるわけではありません。DoTも、すべてのDNS入力欄で利用できる形式ではありません。
| 名前解決の用途 | 設定の目安 | 確認すること |
|---|---|---|
| 中国国内向けの直接接続ドメイン | 現在のネットワークから到達できるローカルDNSを使用します。例：契約中のプロバイダーのDNS、必要に応じて223.5.5.5 | 問い合わせが直接接続されるか、返されたアドレスが現在のネットワークに適しているか |
| 海外向けのプロキシ接続ドメイン | プロキシ経由でアクセスできるリモートDNSを使用します。DoH対応の入力欄には、必要に応じてhttps://dns.google/dns-queryを指定できます。 | エンドポイントがサポートされているか、到達可能か、リクエストが想定どおりプロキシ経由になるか |
| プロキシサーバーのドメイン名 | プロキシ接続を確立する前から使える名前解決経路を確保する | まだ接続できていないプロキシに依存していないか、循環依存になっていないか |
| LAN内のデバイス名 | ルーターや社内DNSなど、LAN内DNSの名前解決機能を優先して使う | LAN内の名前がパブリックDNSへ誤って送信されていないか |
判断のポイント：DNSリクエストの経路を確認してからサーバーを変更する
リモートDNSへの接続が干渉を受ける直接接続経路を通っている場合、アドレスだけを変更しても解決しないことがあります。まずログや接続記録で経路を確認し、そのうえでサーバーや通信方式を調整してください。
3. v2rayNのDNS・ルーティング設定を確認する
現在の動作モードとコアを記録してから、「設定」→「DNS設定」を開きます。リリースによっては、関連項目が設定画面のDNSタブにまとめられています。実際の画面に表示される項目の説明に従ってください。意味の異なる入力欄に、ネット上のJSONを丸ごと貼り付けないでください。また、コアを切り替えてもDNS設定の意味がすべて同じままとは限りません。
- 現在の設定を記録する。ローカルDNS、リモートDNS、ルーティングモード、使用中のコアの設定を保存します。カスタムDNS設定を有効にしている場合は、テスト後に元へ戻せるよう、設定内容を事前にバックアップしてください。
- 直接接続用のDNSを設定する。ローカルDNSまたは直接接続用DNSの項目に、到達可能なサーバーを指定します。223.5.5.5を使う場合は、現在のネットワークからアクセスできることを確認してください。社内ネットワークの内部ドメインは、一律にパブリックDNSへ変更せず、社内DNSを優先して使用します。
- リモートDNSを設定する。現在のコアがサポートする形式で、リモートDNSの項目を設定します。DoHに対応している場合は、必要に応じて
https://dns.google/dns-queryを使用できます。このアドレスは設定例であり、すべてのネットワークからアクセスできるとは限りません。 - ルーティングルールを確認する。「設定」→「ルーティング設定」を開き、中国国内向けドメイン、プロキシ接続するドメイン、デフォルトの出力先に関するルールを確認します。ドメイン別に振り分ける場合、IPルールだけを残してドメインルールを無視しないでください。
- 保存してコアを再起動する。新しい設定を読み込ませ、DNS設定の形式エラー、名前解決タイムアウト、サーバー接続失敗などがログに出ていないか確認します。画面上で保存に成功しても、実際の通信経路が正しいとは限りません。
実行設定でV2Ray／Xrayのrouting.domainStrategyを使用している場合は、代表的な3つの値の違いを確認してください。AsIsは、ルーティング時に元のドメイン名を使い、IPルールのための名前解決を行いません。IPIfNonMatchは、ドメインルールに一致しなかった場合に名前解決を試み、その後のルール判定を続けます。IPOnDemandは、IPが必要なルールを判定する際に、必要に応じて名前解決します。これらは「直接接続・プロキシ・グローバル」の言い換えではありません。
4. v2rayNGのVPN取り込みとDNSを確認する
v2rayNGのサイドメニューから「設定」を開き、「リモートDNS」「ローカルDNS」と、使用中のバージョンにあるローカルDNSの有効化項目を確認します。項目名はバージョンによって異なる場合があります。ローカルDNSを入力しただけで有効になったと判断せず、対応する機能のスイッチも確認してください。
- 接続モードを確認する。設定を起動し、システムのVPN接続状態を確認します。プロキシモードだけを使っている場合、そのプロキシを経由しないアプリは、このDNS設定の対象になりません。
- ローカルDNSを確認する。現在のネットワークで直接接続に使えるDNSを指定し、機能が有効になっているか確認します。LAN内の名前解決も考慮してください。社内ネットワークの名前や家庭内デバイス名は、通常パブリックDNSでは解決できません。
- リモートDNSを確認する。使用中のバージョンがサポートするアドレスを指定し、保存後に接続を停止してから再起動します。暗号化DNSを使う場合は、該当する通信方式が入力欄でサポートされていることを確認してください。アドレスの先頭に独自の文字列を付け加えないでください。
- ルーティングとアプリごとの設定を確認する。「設定」→「ルーティング設定」で、中国国内向け通信の処理方法を確認します。あわせてアプリごとのプロキシ設定も確認してください。除外されたアプリは、システムのネットワークとDNSを引き続き使う場合があります。
- システムとブラウザーを確認する。Androidの「プライベートDNS」と、ブラウザーの「セキュアDNS」が有効かどうかを記録します。トラブルシューティングでは、一度に変更する項目を1つに絞り、接続を再確立してログと名前解決の動作を比較してください。
AndroidのプライベートDNS、ブラウザー内蔵のDoH、コアのDNSによって、複数の名前解決経路が生じることがあります。あるスイッチが別のスイッチを必ず上書きすると決めつけず、VPNで取り込まれる範囲、対象アプリが除外されているか、実際の接続記録を確認しましょう。特にブラウザー独自のDoHは、通常のHTTPS通信としてルーティングされても、クライアント内蔵のDNSを使用しない場合があります。
5. DNSルールと接続ルールをセットで設定する
「中国国内向けドメインはローカルDNS、海外向けドメインはリモートDNS」という設定には、DNS層とルーティング層の両方が必要です。DNS層では名前解決サーバーを選び、ルーティング層では通信の出力先を選びます。DNSだけを変更しても通信が自動的にプロキシ経由になるわけではありません。通信ルールだけを変更しても、アプリがすでにシステムへ送信したDNS問い合わせを取り消すことはできません。
- まず個別の例外を設定する。直接接続するLAN内ドメイン、社内サービス、ローカルアドレスには、明確な処理ルールを設け、広範なプロキシルールに上書きされないようにします。
- 次にドメイン分類を設定する。
geosite:cnなどのルールを使う場合は、使用中のコアが対応しており、必要なルールデータを読み込めていることを確認してください。分類データベースはリアルタイムの位置情報ではなく、中国国内のすべてのWebサイトを網羅するものでもありません。 - IPルールで補完する。
geoip:cnはIPアドレスを分類するルールであり、ドメイン名による分類とは意味が異なります。中国国内向けドメインが海外のIPアドレスを使う場合もあれば、海外向けドメインが中国国内のCDNアドレスを返す場合もあります。 - ルールに一致しない場合の動作を確認する。分類リストにないドメインが最終的にどの出力先を通るか、DNSが別のサーバーへフォールバックするかを確認します。フォールバックの動作を把握していない場合、海外向けのDNS問い合わせがローカル経路を通らないと断言しないでください。
プロキシサーバー自体のドメイン名も個別に考慮する必要があります。ノードへの接続に事前の名前解決が必要なのに、その名前解決もまだ確立していないプロキシ経由に限定すると、起動時に循環依存が発生します。リモートDoHサーバーがドメイン名で指定されている場合も、初回接続にあたって名前解決が必要になることがあります。すべてのDNSを一律にプロキシ経由にするのではなく、現在のコアが初回接続をどう確立するか確認してください。
判断のポイント：接続可能な起動経路を確保してから振り分けを厳密にする
まずノードのドメイン名とDNSサーバーに、利用可能な初期接続経路を確保します。その後、通信先ドメインの名前解決ルールを段階的に調整してください。変更のたびに再接続してテストすれば、起動失敗をノードの障害と誤認しにくくなります。
6. ログ・キャッシュ・比較用クエリで確認する
検証では、問い合わせ先、問い合わせが通る経路、通信の出力先という3点を分けて確認します。IPアドレスを取得できても、DNSが想定外の経路を通っていないとは限りません。ブラウザーでWebページを開けても、すべてのアプリの通信が取り込まれているとは限りません。
- テスト対象を決める。中国国内の一般的なドメイン、プロキシ経由でアクセスするドメイン、実際に使用するLAN内の名前をそれぞれ選びます。毎回同じ対象を使い、テスト結果を比較できるようにしてください。
- 接続を確立し直す。DNS設定を保存したらクライアントの接続を再起動し、テスト対象のアプリも終了してから開き直します。ブラウザー、システム、コアにはそれぞれキャッシュがあるため、1か所だけ消去しても古い結果が再利用されることがあります。
- クライアントのログを確認する。まず設定の読み込みに失敗していないか確認し、次に名前解決エラーと出力先の記録を調べます。DNSの詳細がログに表示されるかどうかは、コアとログレベルによって異なります。ログに記録がないからといって、DNS問い合わせがなかったとは限りません。
- システム側の結果と比較する。Windowsのターミナルで次のコマンドを実行し、既定のDNSサーバーと指定したDNSサーバーの結果を比べます。これらが確認するのはシステム側の問い合わせであり、クライアントコアのDNSを検証する代わりにはなりません。
nslookup www.qq.com
nslookup www.qq.com 223.5.5.5
ipconfig /flushdns1つ目のコマンドは通常、現在のシステムDNSを使います。2つ目は指定したアドレスに問い合わせます。3つ目はWindowsのDNSキャッシュを消去します。DNSサーバーによって異なるCDNアドレスが返るのはよくあることで、アドレスが一致しないだけでDNS汚染とは判断できません。アドレスの妥当性、名前解決の安定性、宛先への接続可否、クライアントログをあわせて確認してください。
7. 症状別にDNSの問題を切り分ける
リモートDNSを変更したのに、Webページが開けないのはなぜ？
まずログで名前解決のタイムアウトと接続タイムアウトを区別します。リモートDNSのアドレス形式がサポートされているか、サーバーに到達できるか、リクエストが正しい経路を通るか確認してください。IPアドレスを取得できている場合は、DNSを何度も変更せず、ノードへの接続と通信のルーティングを確認します。
ブラウザーは使えるのに、ほかのアプリで名前解決に失敗する場合は？
まず、そのアプリがVPNやアプリごとのプロキシ設定から除外されていないか確認し、独自のDNSを使用していないか調べます。デスクトップでシステムプロキシだけを有効にしている場合は、アプリがシステムのプロキシ設定を参照するかどうかも確認してください。ブラウザーで接続できても、端末内のすべてのアプリが通信対象になっている証拠にはなりません。
DNSを変更したら、中国国内のサイトが遅くなったのはなぜ？
中国国内向けのドメインがリモートDNSへ送られていないか、通信自体は直接接続になっているかを確認してください。名前解決を行う場所と通信の出口が一致しないと、適切でないCDNアドレスが返されることがあります。中国国内向けの名前解決をローカルDNSに戻し、接続を確立し直して、同じサイトで速度を比較してください。
一部のサイトだけ開けない場合、IPv6を無効にすべき？
まずAレコードとAAAAレコードそれぞれの接続状況を比較し、現在の接続経路でIPv6が利用できるか確認します。比較のためにIPv6の名前解決設定を一時的に変更してもかまいませんが、元の値を記録してください。IPv6を無効にするだけで、IPv6のルーティングや通信の取り込み範囲を確認しないままにしないでください。
サブスクリプションを更新すると、DNS設定も同期される？
一般的なノードのサブスクリプションはサーバー設定を更新するもので、クライアント全体のDNSやルーティング設定まで含むとは限りません。更新後にローカル設定を確認してください。カスタム設定全体を使用している場合は、実行設定が画面上のDNS項目を上書きしていないかも確認します。
復元できる設定記録を残しましょう。使用中のコア、通信の取り込み方式、ローカルDNSとリモートDNS、ルーティング方針、ブラウザーのDNS設定、変更日を記録します。次に問題が起きたときは、ノード・DNS・ルーティングを同時に変更するより、最後に変更した項目から戻すほうが原因を特定しやすくなります。