サブスクリプションの追加とノードへの接続は済んでいるものの、一部のドメインにアクセスできない、または日本国内のサイトが遅いmacOSユーザー向けです。まずシステムの名前解決とコアのDNS処理を区別し、直接接続DNS、リモートDNS、ドメインルールを設定します。最後にターミナルとログで実際の通信経路を確認します。この記事ではXrayコアを使うv2rayNの設定例を中心に解説します。コアを切り替えた場合はDNS項目を改めて確認し、設定をそのまま流用しないでください。
1. DNS振り分けで押さえる3つの経路
DNSはドメイン名をIPアドレスに変換する仕組みです。v2rayNはクライアントであり、接続や一部の名前解決を実行するのは選択したコアです。同じアクセスでも、ブラウザー、macOSのシステムリゾルバー、コア内蔵DNSがそれぞれ関与する場合があります。どこか一か所を変更しても、すべてのリクエストに新しい設定が適用されるとは限りません。
上記は、アプリがドメイン名をプロキシに渡す場合の簡略化した流れです。アプリが先にローカルで名前解決すると、プロキシにはIPアドレスだけが届くことがあります。プロキシサーバー側で名前解決する場合は、ローカルのコアから宛先ドメインのDNSクエリが送信されないこともあります。そのため、ログに特定ドメインのクエリがないからといって、設定が反映されていないとは限りません。
- リゾルバーの選択：国内ドメインは直接接続用リゾルバーへ、プロキシが必要なドメインはリモートリゾルバーへ振り分けます。
- DNSの通信経路：DNSクエリ自体が直接接続とプロキシのどちらから送信されるかは、別途確認が必要です。
- 通信の接続経路：IPアドレスを取得した後、Webサイトへの接続先はルーティングルールで決まります。
2. 直接接続DNSとリモートDNSの設定
v2rayNの「設定」→「DNS設定」を開き、「設定」→「パラメーター設定」で現在のコアを確認します。バージョンやコアによって項目は異なります。コアごとにDNSを設定する画面では、現在使用中のコアの設定を変更してください。まず元の設定を保存し、ルーティング、TUN、IPv6を同時に変更せず、リゾルバーだけを変更します。
| 用途 | 設定を始める際の例 | 必ず確認する条件 |
|---|---|---|
| 直接接続DNS | 223.5.5.5 | 現在のネットワークから到達可能であること。通常のDNSクエリは暗号化されません。 |
| 直接接続のDoH | https://dns.alidns.com/dns-query | コアが形式に対応し、エンドポイントのドメイン名を事前に名前解決できること |
| リモートDoH | https://dns.google/dns-query | クエリが想定どおりプロキシ経由になること。TLS検証とシステム時刻が正常であること |
掲載しているのは公開サービスのアドレス例であり、あらゆるネットワーク環境での速度順位ではありません。最初は各用途につき、確実に到達できるリゾルバーを1つ設定すれば十分です。多数のアドレスを一度に登録すると、フォールバックや並列クエリが複雑になり、ログから原因を特定しにくくなります。企業内ネットワーク、大学のネットワーク、ローカルドメインの名前解決が必要な環境では、該当する内部DNS経路を残してください。
ポート番号は通信方式を識別するためのもので、ローカルでそのポートが待ち受けていることを意味しません。v2rayNのプロキシ待ち受けポートとDNSの待ち受けポートは別の設定です。HTTPやSOCKSのプロキシポートをmacOSのDNSサーバー一覧に入力しないでください。
3. geositeルールはDNSと接続の両方を考慮する
geositeはドメインの分類データ、geoipはIPアドレスの分類データです。どちらもリゾルバーではなく、DNSサービスを自動的に提供するものではありません。たとえばXrayでは、ルーティングのgeosite:cnで中国本土のドメインを照合できます。また、内蔵DNSのサーバー項目でdomainsを指定し、優先的に処理するドメインの範囲を設定できます。両者は関連する用途ですが、互いに置き換えられるものではありません。
- まずルールデータを確認します。現在のコアが使用するドメインデータとIPデータを読み込めること、ログにファイル不足や分類未登録のエラーがないことを確認します。分類の内容は変わるため、常に正確な地理的境界を示すものとして扱わないでください。
- 直接接続で解決する範囲を設定します。
geosite:cnに該当するドメインを優先的に直接接続DNSへ渡します。内部ドメインは個別のルールで処理し、パブリックDNSへ送信されないようにします。 - リモートで解決する範囲を設定します。プロキシが必要なドメインをリモートDNSへ渡します。
geosite:geolocation-!cnを使う場合は、データに該当する分類が存在することを確認してください。これは分類データの集合であり、日本国内以外のすべてのドメインをリアルタイムに判定するものではありません。 - 通信ルーティングを確認します。国内ドメインは直接接続し、プロキシが必要なドメインはプロキシ経由にします。Xrayのルーティングルールは上から順に照合されるため、広範囲に一致するルールより、対象が明確なドメインルールを先に配置してください。
- フォールバック設定を確認します。ドメインがルールに一致しない場合、応答が空の場合、または想定外のアドレスが返された場合、クエリが別のサーバーに転送されることがあります。特定のドメインを直接接続DNSで解決したくない場合は、フォールバックの対象範囲も必ず確認してください。
Xrayのrouting.domainStrategyは、ルーティング時に名前解決の結果を使ってIPルールを照合するかどうかを制御します。AsIsではIPルールの照合のためにドメインを積極的に名前解決しません。IPIfNonMatchでは、ドメインルールに一致しなかった場合に名前解決を試み、その結果で照合します。これはDNSモジュールのqueryStrategyとは別の設定で、後者は主にクエリで使用するアドレスファミリーなどに関係します。
結論：まずドメインルールを確認し、その後にIPルールを調べる
特定のサイトが誤った経路を通る場合は、まず想定したドメイン分類に一致しているか、ルールの順序が適切かを確認します。IPアドレスによる判定が本当に必要な場合に限り、ルーティング時の名前解決方針を変更してください。DNSの変更でルーティングの誤りを覆い隠さないようにしましょう。
4. DoHによるDNS汚染対策と名前解決の準備
DoHはDNSクエリをHTTPS接続に載せ、リゾルバーまでの通信を保護することで、途中で読み取られたり改ざんされたりするリスクを抑えます。ただし、リゾルバーが必ず正しい応答を返すとは限らず、接続先のIPアドレスを隠すものでもありません。ブラウザーで独自のセキュアDNSが有効になっていると、コアに設定したリゾルバーを経由しない場合もあります。
- エンドポイントの事前名前解決：
dns.googleのようなドメイン名のエンドポイントへ接続するには、接続元でまずそのアドレスを知る必要があります。エンドポイント自体の名前解決を、まだ接続できていないDoHに依存させると、依存関係が循環して接続できません。 - ノードのドメイン名：プロキシノードにドメイン名を使っている場合も、プロキシの確立前に名前解決が必要です。ノードへの接続が必要なサービスを、ノードのドメイン名を解決する唯一の手段にしないでください。
- 証明書の検証：macOSの「システム設定」→「一般」→「日付と時刻」を開き、時刻が自動設定されているか確認します。証明書エラーが発生した場合は、時刻、エンドポイント名、ネットワーク上の遮断を確認してください。検証を無効にして回避しないでください。
- 通信の出口：リモートリゾルバーへの接続にプロキシが必要な場合は、使用するコアが対応するDNS通信方式とルーティング設定で経路を明示し、ログで確認してください。項目名だけで判断することはできません。
事前の名前解決を省くために、DoHのホスト名を任意のIPアドレスに置き換えることはおすすめしません。HTTPSでは証明書の名前とサーバーのバーチャルホストも関係します。DNSサービスがそのIPアドレスでの接続を明確にサポートしている場合に限り、公開されている形式に従ってください。
5. FakeDNSを有効にするケース
FakeDNSは、別のパブリックDNSサービスではありません。ドメイン名に合成IPアドレスを割り当て、通信が再びコアに入ったときに、そのIPアドレスを元のドメイン名に対応付けます。アプリが後続の通信でIPアドレスだけを送信しても、コアがドメイン名に基づいて振り分けられる可能性があります。透過プロキシと組み合わせることが多い機能ですが、TUNを有効にしたら必ず使うものではありません。
| 比較項目 | DoH | FakeDNS |
|---|---|---|
| 主な目的 | 実際のDNSクエリを暗号化して送信 | ドメイン名と合成IPアドレスの対応関係を保持 |
| 返される結果 | リゾルバーが返す実際のアドレスレコード | ローカルのアドレスプールから生成されたアドレス |
| 利用に必要な条件 | エンドポイントに到達でき、証明書が有効で、通信経路が適切であること | クエリと後続の接続が、どちらも連携する仕組みで処理されること |
| よくある問題 | 事前の名前解決に失敗する、接続がタイムアウトする | 合成IPが直接接続に流れる、キャッシュの対応関係がずれる |
システムプロキシだけを使い、ブラウザーがすでにドメイン名をプロキシに渡している場合は、通常FakeDNSを無効にしたままで問題ありません。TUN環境でアプリが先に名前解決し、その結果ドメインルールが機能しない場合は、使用中のコアとクライアントがDNSの透過処理とアドレス対応付けに完全対応しているか確認します。コアを切り替えた場合は改めて検証し、実装が同じだと決めつけないでください。
結論：まず透過処理の経路を確認し、その後FakeDNSを有効にする
まずDNSクエリが想定した経路で処理されることを確認し、次に合成アドレスへの接続がクライアントを迂回しないことを確認します。有効化後に一部のアプリだけ通信できなくなった場合は、すぐにノードを変更せず、キャッシュ、バイパスルール、アドレスの対応付けを先に確認してください。
6. macOSで名前解決とプロキシ接続を順に確認
設定は一度に1項目だけ変更します。保存したらコアを再起動し、起動ログにエラーがないか確認してから、次のテストを行います。コマンド内のドメイン名は例です。問題のあるサイトを調べる場合は、そのサイトのホスト名に置き換えてください。サブスクリプションURL、ノードの認証情報、接続設定全体を公開ログに貼り付けないでください。
- システムDNSを確認します。
scutil --dnsを実行し、現在のネットワーク、VPN、その他のネットワークサービスに設定されているリゾルバーを確認します。表示されるのはシステムの名前解決設定であり、Xray内蔵DNSの状態すべてを確認できるわけではありません。 - 指定したリゾルバーをテストします。次の
digコマンドを実行し、現在のネットワークからリゾルバーが応答するか確認します。このテストだけでは、v2rayNのDNS振り分けが機能しているかは分かりません。 - プロキシ接続をテストします。まず「設定」→「パラメーター設定」でローカルの待ち受けポートとプロトコルを確認し、プロキシ経由のリクエストを実行します。以下の例は
10808がHTTPまたは混合プロキシとして動作する場合を想定しています。SOCKSのみの場合はHTTP形式のコマンドを使わないでください。 - コアのログを確認します。同じテスト時間帯のログを見て、対象ドメイン、適用されたルーティング、選択されたアウトバウンド、DNSのタイムアウトを確認します。必要に応じて一時的にログレベルを上げ、テスト後に元に戻してください。
# macOSのシステムリゾルバーを確認
scutil --dns
# 指定したリゾルバーに直接問い合わせる。タイムアウトは2秒、試行は1回
dig @223.5.5.5 www.baidu.com A +time=2 +tries=1
# 10808がHTTPまたは混合プロキシの場合のみ使用
curl -I --proxy http://127.0.0.1:10808 \
--connect-timeout 10 --max-time 20 https://www.example.com/待ち受けポートがSOCKS5に対応している場合は、次の2つのコマンドも比較できます。通常、1つ目はローカルで宛先ドメインを名前解決し、2つ目はドメイン名をSOCKSプロキシに渡します。2つ目だけが成功し、1つ目が失敗する場合は、まずローカルの名前解決経路を確認してください。ただし、アドレスファミリーの違いやサイト側の接続制限も考慮し、ログと併せて判断します。
# ローカルで宛先ドメインを名前解決
curl -I --proxy socks5://127.0.0.1:10808 \
--connect-timeout 10 --max-time 20 https://www.example.com/
# 宛先ドメインをSOCKSプロキシに渡す
curl -I --proxy socks5h://127.0.0.1:10808 \
--connect-timeout 10 --max-time 20 https://www.example.com/設定変更後も古い結果が返る場合は、まずテスト中のアプリを終了して再起動してください。macOSのシステムDNSキャッシュを消去する必要がある場合は、ターミナルで次のコマンドを実行します。2つ目のコマンドには管理者権限が必要です。これらのコマンドでは、ブラウザー独自のキャッシュ、コアのキャッシュ、上流リゾルバーのキャッシュは消去されません。
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder7. DNS振り分けでよくある質問
DoHに切り替えたら、すべてのサイトが遅くなったのはなぜですか？
まず元のリゾルバーに戻し、速度が改善するか確認します。次にDoHエンドポイントの事前名前解決、プロキシの出口、タイムアウトのログを調べます。国内ドメインまでリモートリゾルバーに渡すと、現在の直接接続経路に適さないアドレスが返ることがあります。DNSアドレスだけを変更するのではなく、国内ドメインの名前解決と実際の通信を合わせて振り分けてください。
digは成功するのにブラウザーで開けない場合、何が考えられますか？
dig @223.5.5.5で分かるのは、指定したリゾルバーへの今回のクエリが応答したことだけです。ブラウザーが独自のセキュアDNSを使っている場合や、システムプロキシや拡張機能が競合している場合があります。まず上記の明示的なプロキシコマンドで再テストし、ブラウザーのプロキシとセキュアDNSの設定を確認してください。
国内サイトが海外のIPアドレスに解決されたら、必ずDNS汚染ですか？
必ずしもそうではありません。CDNの振り分け、リゾルバーの設置場所、サービスの構成などが結果に影響します。同じドメインを直接接続DNSとリモートDNSの両方で調べ、接続できるか、ルーティングが想定どおりかを比較してください。応答が異なるだけではDNS汚染の証拠になりません。また、特定の結果を長期間hostsに登録することもおすすめしません。
Aレコードがあるのに接続がタイムアウトします。IPv6を無効にすべきですか？
まずAレコードとAAAAレコードを個別に問い合わせ、curl -4とcurl -6の結果を比較します。プロキシ経由でテストする場合、使用するアドレスファミリーはプロキシ側で決まることもあるため、それだけでローカルのIPv6に問題があるとは判断できません。どのIPv6経路が失敗しているか確認してから、該当するクエリや出口の設定を変更し、システム機能全体を一度に無効にしないようにします。
Android版にもこのDNS設定をそのまま適用できますか？
振り分けの考え方は参考にできますが、設定をそのまま流用することはできません。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。VPNによる通信の取り込み、DNSの入口、対応する設定項目をクライアントごとに確認してください。移行時はまず1つのドメインと1つのリゾルバーで動作を確かめ、その後に分類ルールとフォールバック設定を追加します。
最終確認では次の3点をチェックします。国内ドメインが想定どおり直接接続DNSで解決されること、プロキシが必要なドメインが意図せず直接接続DNSへフォールバックしないこと、通信が正しい出口を通ることです。正常に動作する設定を保存してから、DoH、IPv6、FakeDNSを一つずつ追加してください。問題が起きたときの明確な戻し先を確保できます。