DNS漏洩を修正する方法：VPN・ブラウザ・SOCKS5別に解説

DNS漏洩を修正する方法は、まず意図しない経路で名前解決しているアプリを特定し、そのアプリのDNS設定やプロキシ設定を直して、同じ環境で再検証することです。VPN、ブラウザ、コマンドラインツールでは、名前解決の経路が異なる場合があります。出口IPやDNSサービスを変更しただけでは、原因が残ることがあります。

このDNSリーク・ガイドは、VPN利用時の漏洩を調べたい方や、Socks5.IOのプロキシを使う業務ツールで名前解決を管理したい方に向けたものです。コードは文書化された動作に基づく設定例であり、Socks5.IOの認証済み接続による実測結果ではありません。

要点： VPNではDNS設定・スプリットトンネリング・切断時の保護を確認します。SOCKS5では接続先の名前解決をプロキシ側に任せ、curlならsocks5h://を使います。ブラウザ独自のセキュアDNSも確認し、変更後は同じアプリで新しいテスト用ホスト名を使って検証します。再接続後の確認も必要です。

DNSリークとは？まず3つの経路を区別する

DNSリークとは、ドメイン名の問い合わせが、想定した保護方針から外れたDNSリゾルバーやネットワーク経路を使うことです。DNS（Domain Name System）は、example.comのような名前を、アプリが接続できるアドレスへ変換する仕組みです。

フルトンネルのVPNでは、接続先の名前解決もVPNトンネル内を通ることが期待されます。一方、SOCKS5プロキシを使うアプリでは、端末側のインターネット接続事業者（ISP）で先に名前解決せず、接続先ホスト名をプロキシへ渡すことが目的になる場合があります。

実際の動作は、次の3点に分けると整理できます。

Web通信はプロキシを通っていても、DNSだけが端末側で処理される場合があります。逆に、DNSを暗号化していても、その接続がVPNの外を通る場合があります。テスト画面に表示された事業者名だけでなく、何を保護する設定なのかを基準に判断します。

DNSリークでどのような情報が見えるのか

意図しないリゾルバーには、問い合わせたドメイン名やその時刻などが伝わる可能性があります。保護対象の経路外で平文DNSを送信している場合は、ローカルネットワーク上の観測者にも内容が見えることがあります。

ただし、DNS問い合わせそのものに、HTTPSのURLのパス全体、ページ本文、アカウントのパスワードが含まれるわけではありません。DNSリークの検出は、HTTPSの暗号化が破られたことを意味しません。

SOCKS5のリモート名前解決と通信の暗号化も別です。 接続先ホスト名をプロキシへ渡せば、その接続のために端末側で名前解決する必要はなくなります。しかし、通常のSOCKS5自体には通信を暗号化する機能がなく、ホスト名がSOCKS5のやり取りから見える可能性は残ります。ローカルネットワークからその情報も隠す必要がある場合は、伝送経路の保護も確認してください。

設定を変える前にDNS漏洩を確認する

最初は、1つのアプリと1つの設定に対象を絞ります。ブラウザのプロファイルやクライアントのバージョン、VPN・プロキシの接続モード、想定するリゾルバーを記録してください。端末全体を保護したいのか、特定のアプリだけを対象にするのかも明確にします。

ブラウザでは、DNSLeakTestやBrowserLeaks DNSを利用できます。これらはテスト側で管理する名前への問い合わせを発生させ、観測した再帰リゾルバーを表示します。端末から送信された全パケットの経路を直接表示するものではありません。

1. 直接接続での比較が許容される場合は、通常時の結果を記録します。その間、機密情報を扱う操作は行いません。
2. 実際に使うVPNまたはプロキシ設定を有効にします。
3. 同じブラウザ・同じプロファイルで、新しいホスト名を生成するテストを実行します。
4. リゾルバーのアドレスと運営組織、ブラウザの出口IPを記録します。
5. 利用中の設定で想定されるリゾルバーと経路に照らして判断します。

ブラウザの結果を、そのままPythonスクリプトや別のアプリ、別プロファイルに当てはめることはできません。また、リゾルバーのASN（自律システム番号）はネットワークの所属を示しますが、問い合わせが通ったインターフェースを証明する情報ではありません。

VPN利用時のDNSリークの修正方法

1. VPNに適したDNS設定へ戻す

VPNクライアントの接続設定またはDNS設定を開き、提供元が説明しているDNS保護機能を確認します。「DNSリーク保護」という名前の機能が、すべての製品で同じ動作をするわけではありません。リゾルバーの指定、通信経路の制御、切断時の動作のどれを扱う機能かを確認してください。

手動でDNSを指定している場合は、元の値を記録したうえで、意図しない上書き設定を見直します。VPNクライアントを更新し、対応するDNSモードを選択して再接続します。その後、接続先の問い合わせが想定した経路を通るか再検証します。

組織管理の端末では、社内向けの名前解決が必要なことがあります。企業のリゾルバーや管理ポリシーは、管理者へ確認してから変更してください。

2. スプリットトンネリングと切断時の保護を確認する

スプリットトンネリングは、指定したアプリや接続先の通信を意図的にVPNから除外する仕組みです。問題のアプリが保護対象に含まれているか確認します。除外したブラウザの結果で、VPN内にある別アプリの動作を評価しないようにします。

有線LAN、Wi-Fi、仮想アダプター、別のVPNクライアントも確認対象です。OSはインターフェースごとにDNSルールを適用する場合があります。原因となる設定を特定する前に、レジストリなどを変更するのは避けてください。

VPNがキルスイッチに対応している場合は、保護範囲を調べます。特定アプリだけを遮断する実装も、端末のより広い範囲を扱う実装もあります。機密情報を扱わない通信で接続を一時的に中断し、設定どおりの動作を確認します。「切断時は通信停止」という方針なら、保護対象のリクエストは失敗し、直接接続へ自動的に切り替わらないことが必要です。

3. IPv6は対応状況を確認してから調整する

IPv4とIPv6では経路が異なる場合があります。VPNがIPv6をトンネル内で扱うのか、設計上ブロックするのかを確認し、DNSとアプリの接続にどう適用されるかを調べます。

AAAAレコードにはIPv6アドレスが含まれますが、そのレコードを取得するDNS問い合わせはIPv4でも送信できます。AAAA問い合わせが見えただけで、IPv6の漏洩とは判断できません。

まずはVPNがサポートするIPv6設定を使います。障害の切り分けに一時的な変更が必要な場合は、元の設定を記録して比較し、設定を戻してから原因を修正します。IPv6の恒久的な無効化は、すべてのDNSリークに有効な解決策ではありません。

SOCKS5プロキシでDNS漏洩を修正する方法

接続先ホスト名をプロキシへ渡す

SOCKS5の仕様であるRFC 1928では、ドメイン名を指定するアドレス形式が定義されています。クライアントは、端末で名前解決して数値のIPアドレスを送る代わりに、接続先ホスト名をプロキシへ渡せます。

どちらを使うかはクライアントの実装と設定で決まります。OSのプロキシ設定を参照しないアプリや、プロキシ接続の前に自分で名前解決するアプリもあるため、アプリ側のDNS設定を確認してください。

このリモート名前解決では、ローカルのDNSパケットをUDP ASSOCIATEで転送する必要はありません。接続要求でホスト名を渡し、サーバー側で名前解決できます。他のUDP通信を中継できるかどうかは、別途確認する互換性の問題です。

curlではsocks5h://でリモート名前解決を指定する

curlの公式リファレンスでは、次の指定が区別されています。

次の例は、curlを導入したmacOS、LinuxなどのBash環境向けです。PowerShell用の構文ではありません。最初にcurl --versionでバージョンを記録し、利用するアカウントで発行されたホスト、ポート、ユーザー名を入力します。

read -r -p "SOCKS5ホスト:ポート: " PROXY_ENDPOINT
read -r -p "プロキシのユーザー名: " PROXY_USERNAME

# 接続先ホスト名をプロキシへ渡して名前解決する
curl --proxy "socks5h://${PROXY_ENDPOINT}" \
  --proxy-user "$PROXY_USERNAME" \
  --noproxy "" \
  --connect-timeout 10 --max-time 30 \
  --output /dev/null \
  --write-out 'HTTPステータス: %{http_code}\n' \
  "https://example.com/"
curl_status=$?
printf 'curl終了ステータス: %s\n' "$curl_status"

unset PROXY_ENDPOINT PROXY_USERNAME curl_status

ユーザー名だけを指定し、オプションにパスワードを含めない場合、curlは対話形式でパスワード入力を求めます。この例はユーザー名・パスワード認証と対話可能な端末を前提にしています。他の認証方式では、それに対応する設定が必要です。共有するコマンドにパスワードを追記したり、認証情報を扱う箇所でシェルのトレース出力を有効にしたりしないでください。

--noproxy ""は、このリクエストのプロキシ除外指定を空にします。接続タイムアウトは10秒、処理全体の上限は30秒です。これらは診断用の設定値であり、サービスの速度保証ではありません。$?は後続コマンドで変わるため、curlの直後に終了ステータスを保存しています。

エラー時はcurlのメッセージと終了コードの説明を使い、プロキシのホスト名解決、接続タイムアウト、認証、プロキシ側の接続先処理を切り分けます。診断情報を共有する前に、認証情報を取り除いてください。

任意の比較：ローカル名前解決との差を調べる

次の比較では、接続先を意図的にローカルで名前解決します。ローカル問い合わせがプライバシー要件に合わない場合は実行しないでください。 ローカルとプロキシ側の違いを切り分ける必要がある場合に限り、同じエンドポイント、アカウント、接続先、ネットワーク条件で比較します。

read -r -p "SOCKS5ホスト:ポート: " PROXY_ENDPOINT
read -r -p "プロキシのユーザー名: " PROXY_USERNAME

curl --proxy "socks5://${PROXY_ENDPOINT}" \
  --proxy-user "$PROXY_USERNAME" \
  --noproxy "" \
  --connect-timeout 10 --max-time 30 \
  --output /dev/null \
  --write-out 'HTTPステータス: %{http_code}\n' \
  "https://example.com/"
curl_status=$?
printf 'curl終了ステータス: %s\n' "$curl_status"

unset PROXY_ENDPOINT PROXY_USERNAME curl_status

HTTP応答は、リクエストが応答可能なサービスへ到達したことを示します。名前解決そのものを調べるには、新しい管理可能なテスト用ホスト名と、リゾルバーログや関連インターフェースの通信記録を照合します。ここで使う固定のexample.comは接続確認の例であり、キャッシュの影響を避けたDNSリークテストではありません。

プロキシの入口をドメイン名で指定した場合は、接続前にその入口をローカルで名前解決する必要があることもあります。この初期問い合わせと、プロキシ接続後の接続先ドメインへの問い合わせは分けて判断します。

Socks5.IOの接続を業務に組み込むには

Socks5.IOを利用する際は、選択したサービスの現在の説明で対応プロトコルと認証方式を確認します。SOCKS5を利用できる場合は、アカウントで発行されたホスト、ポート、認証情報を設定し、必要に応じてそのサービスのセッション設定を適用します。HTTP(S)接続用のサンプルとSOCKS5の設定は区別してください。

診断中は接続条件をできるだけ固定し、名前解決の方式だけを変えて比較します。静的住宅プロキシは、固定した出口アドレスを必要とする継続的な作業で検討する選択肢です。出口を変更する収集処理では、ローテーションやセッションの条件を別に確認します。

たとえば、市場調査向けプロキシを使って特定市場の公開商品ページを比較する場合、Socks5.IOが提供する代理接続とIPリソースを調査ツールへ設定します。そのツールがホスト名をローカルで解決するのか、プロキシへ渡すのかは、クライアントの設定で管理します。

リモート名前解決により、その処理で意図しないローカル問い合わせを避けられます。ただし、ページの通貨、言語、地域別コンテンツは、それ以外の設定にも左右されます。調査対象の地域、観測された出口、名前解決の結果を分けて記録してください。

処理を拡大する前に、実際に使うクライアントと1つの発行済みエンドポイントで、認証、名前解決、出口、接続失敗時の動作を確認します。リモート名前解決に失敗する場合は、バージョンと失敗した段階を記録し、認証情報を除いたログを添えてサポートへ相談します。IPを次々に変更するより、再利用できる設定を確立することが先です。

失敗した段階ごとに原因を切り分ける

除外リスト、NO_PROXY、直接接続へのフォールバック、独自のネットワーク処理によって、アプリがプロキシを使わない場合もあります。OSのプロキシ画面だけでなく、アプリで実際に有効な設定を確認します。

ブラウザのDNSリークとセキュアDNSの競合を修正する

Firefox・Chrome・Edgeで該当プロファイルを確認する

Firefoxデスクトップ版では「設定→一般→ネットワーク設定→接続設定」を開きます。現在のバージョンで手動SOCKS設定が利用でき、認証方式も対応している場合は、実際のホストとポートを入力し、SOCKS v5を選択します。接続先をプロキシ側で名前解決するには、該当するDNSオプションを有効にします。英語表記は「Proxy DNS when using SOCKS v5」です。

除外先を確認して保存し、同じプロファイルで新しいDNSテストを実行してください。日本語の項目名や配置はバージョンによって異なるため、Mozillaの接続設定に関する説明と実際の画面を照合します。認証段階で失敗する場合は、対応する認証方式を先に確認します。DNSのチェック項目だけで認証の互換性は変わりません。

ChromeやEdgeでは、設定画面で「セキュアDNS」を検索して現在のモードを確認します。プロキシ拡張機能と管理ポリシーも確認対象です。ブラウザのプロキシ設定からOSの設定画面が開く場合、その変更は他のアプリにも影響する可能性があります。

元の状態を記録し、関連する設定を1つずつ変更します。必要に応じてブラウザを再起動し、問題が出たプロファイルで再検証します。

暗号化DNSとVPN・プロキシの経路をそろえる

DNS over HTTPS（DoH）はHTTPSでDNSメッセージを運ぶ方式で、RFC 8484に定義されています。DNS over TLS（DoT）はTLSでリゾルバーへの通信を保護します。どちらも暗号化の仕組みであり、その接続がVPNやプロキシを通るかは経路設定で決まります。

ブラウザが信頼するDoHリゾルバーへ直接接続している場合、問い合わせ内容はローカルネットワークから保護されていても、「すべての関連通信をVPN内に収める」という方針からは外れる可能性があります。

DoHだけが想定外の経路を使っているなら、クライアントが対応する方法で経路を調整します。OSのDNSがVPNによって適切に処理されることを確認できている場合は、ブラウザがOSの名前解決を使う設定も検討できます。変更後は再検証し、暗号化DNSに失敗した際の代替リゾルバーや経路も確認してください。

セキュアDNSを一律に無効化すると、経路を直さないまま暗号化だけ失うことがあります。一律に有効化しても、意図しない直接接続が残る場合があります。

Windows・macOS・Linux・スマートフォンの確認項目

OS側の確認は、現在の構成を把握するためのものです。アプリがその構成に従っているかは、アプリ側のテストと合わせて判断します。

DNS Clientモジュールを利用できるWindows PowerShellでは、次のコマンドで設定済みDNSサーバーを確認できます。

Get-DnsClientServerAddress

macOSでは、次のコマンドでDNS設定を確認できます。

scutil --dns

systemd-resolvedを使うLinuxでは、次のコマンドを利用できます。

resolvectl status

Windowsではインターフェース名とアドレスファミリーを確認します。macOSで適用範囲の異なる複数のリゾルバーが表示されても、それ自体は異常ではありません。Linuxの127.0.0.53のようなループバックアドレスは、通常は端末内のリゾルバーを示し、実際の上流DNS事業者のアドレスではありません。

ブラウザ独自のDoHは、これらのコマンドで表示するOS設定と異なる動作をする場合があります。コマンドが使えないときは、OS、モジュール、名前解決サービスを確認してからツールの導入を判断します。管理対象のプロファイルを維持し、一時変更では元の値と戻し方を記録してください。

DNS設定を変更してもテスト結果が気になる理由

公開DNSへの変更だけでは経路が変わらない

通常のDNS入力欄に1.1.1.1や8.8.8.8を指定しても、自動的にDoH、DoT、VPN経由になるわけではありません。変わるのはリゾルバーの指定です。平文DNSをトンネル外で送信すれば、その経路上で問い合わせが見える可能性があります。

DNSSEC（DNS Security Extensions）も別の仕組みです。DNSデータの検証を目的とし、問い合わせの暗号化やプロキシ経由の強制は行いません。

キャッシュ・転送・Anycastが比較に影響する

キャッシュ済みの名前では、新しい上流問い合わせが発生しない場合があります。同じホスト名へ繰り返しアクセスして「通信が見えないから保護されている」と判断せず、新しいテスト名を生成する方法を使います。

リゾルバーが別のリゾルバーへ問い合わせを転送する場合もあります。また、Anycastでは同じアドレスに対して異なる場所のノードがサービスを提供します。検出結果はテスト側から観測した情報であり、端末のDNS経路全体の地図ではありません。

ルーターの制御が一部のDNS通信しか扱っていない

ルーターやローカルのフィルタリング用リゾルバーでDNSを処理する場合は、その上流接続も確認します。端末からローカルリゾルバーまでは想定どおりでも、そこから先がVPNの外へ出ている可能性があります。

通常のDNSはUDPとTCPの両方を使い、一般的なポートは53です。UDP 53だけを制限しても、他の経路は残ります。DoTは通常853番ポート、DoHはHTTPSを使うため、53番ポートのルールだけですべてのDNSを管理することはできません。

DoTを任意のサーバーへ無断で転送すると、TLSで検証するサーバーの識別情報が一致しない可能性があります。5353番ポートは通常マルチキャストDNSに使われ、公開DNS用の汎用代替ポートではありません。ルーターでの制御は、許可するリゾルバー、維持すべきサービス、復旧手順を把握した管理者が行います。

修正結果を検証し、再接続後の再発を防ぐ

修正の判断基準は、該当アプリが発生させる新しい問い合わせが、テストした条件で想定どおりに処理されることです。

1. 同じアプリで、新しい接続先名を使って検証します。
2. 観測したリゾルバーと、取得できる経路の証拠を設定方針に照らします。
3. IPv4とIPv6の両方に対応する場合は、それぞれ確認します。
4. 再接続、スリープ復帰、関連するネットワークの切り替え後も検証します。
5. 機密情報を扱わない管理された中断テストで、VPNやプロキシの切断時動作を確認します。
6. バージョン、変更点、時刻、実際の結果を記録し、ネットワーク設定やクライアントの更新後に再確認します。

ブラウザは同じプロファイルで新しいDNSテストを実行します。スクリプトを調べる場合は、管理できるテストドメインとログがあれば、リクエストごとに異なる有効なサブドメインを使い、時刻を照合できます。権威DNSのログで分かるのは、そのサーバーへ問い合わせたリゾルバーです。トンネルを通ったかどうかは、別途経路の記録と組み合わせて判断します。

パケット単位で調べる権限がある場合は、関連する物理・仮想インターフェースで記録を取り、一意のテスト名と時刻で通信を対応付けます。53番ポートだけのフィルターでは暗号化DNSを見落とします。VPNのカプセル化やDoHがあるため、平文DNSが見えないことだけで迂回経路がないとは判断できません。

OSのバックグラウンド問い合わせは、対象アプリの通信と分けます。記録する結論は「このクライアントと設定では、想定外の接続先問い合わせは観測されなかった」のように、検証範囲を明確にします。

まとめ：DNSの経路を直してから、用途に合うプロキシを選ぶ

DNS漏洩を修正する方法の基本は、問題のアプリと想定する名前解決経路を特定し、そこから外れる設定を修正することです。VPNではDNSと切断時の保護、ブラウザではセキュアDNSとプロキシの整合性を確認します。curlでSOCKS5のリモート名前解決を使う場合はsocks5h://を指定し、新しいテスト名と再接続後の検証で結果を確かめます。

Socks5.IOは、許可された市場調査や地域別表示の確認など、プロキシ接続とIPリソースを必要とする作業で検討できます。継続的な確認には安定した出口を、独立したサンプルの取得で出口変更が必要ならローテーション住宅プロキシを検討してください。

購入前に、対象地域、認証、セッション、課金条件を確認し、まず1つのエンドポイントを実際のアプリで検証します。用途に合うIPを選ぶことと、クライアントのDNS設定を直すことを組み合わせて、再現できる接続環境を整えましょう。