ドイツのエクジットでプロキシを設定し、収集を実行しても、ターゲットは相変わらず間違った地域向けのコンテンツを返し続けることがあります。エクジットアドレスはドイツのものだと確認でき、リクエストは成功しているのに、結果はまるでサーバーが実際に存在する場所から来たかのように見えます。よくある原因は、接続はプロキシを通ったものの、名前解決はそうならなかったというものです。
これはDNSリークです。プライバシーの文脈では、リゾルバがあなたの訪問先ドメインを見ているという説明がされ、それは事実ですが、データ収集にとってはより直接的な結果があります。DNS解決はしばしば地理的な認識を持つため、ローカルで解決しながらリモートでエグジットすると不整合が生じ、誤った地域のエンドポイントを渡され、気づかぬうちに地理ターゲット型のデータセットを汚染してしまう可能性があるのです。
実際に何が漏れているのか、そしてなぜ重要なのか
ホスト名へのリクエストは2つのステップから成ります。名前をアドレスに変換すること、そしてそのアドレスに接続することです。プロキシが介入するのは2番目のステップです。1番目のステップに介入するかどうかは、完全にクライアント次第です。
クライアントがローカルで解決する場合、DNSクエリは自分自身のネットワークから自分自身のリゾルバへと送られ、ISPやリゾルバの運営者にドメインが明らかになり、あなたの所在地に基づいて計算された回答が返されます。
この最後の部分が収集を破綻させる原因です。大規模なサイトはCDNや地理認識型DNSの背後にあり、クエリがどこから来たかによって異なるアドレスを返すため、ローカルで解決されたルックアップは、プロキシのエグジットの近くではなく、あなたのサーバーの近くにあるエッジノードを指してしまう可能性があります。そうしてそのノードにドイツのアドレスを通して接続することになり、この不整合は誤った地域のコンテンツ、実行間で一貫性のない結果、あるいはターゲットにとって不自然に見えるシグナルを生み出す可能性があります。もしあなたの作業が市区町村レベルのターゲティングに依存しているなら、地理情報がおかしいと思われる際には、もう一つのよくある原因であるジオロケーションデータベースの差異と並んで、この障害モードをまず除外する価値があります。
HTTPプロキシはめったに漏れないが、SOCKS5はよく漏れる
この挙動はプロトコルによって分かれ、これが問題の核心です。
HTTPプロキシの場合、HTTPSリクエストはCONNECTを使用し、ホスト名をプロキシに送信し、プロキシがリモートで解決します。プレーンなHTTPも同様に、ホスト名を含む絶対URLを送信します。どちらの場合も、プロキシが設計上ルックアップを実行するため、通常のHTTPプロキシの利用ではDNSは漏れません。
SOCKS5の場合、プロトコルは両方をサポートしています。ホスト名を受け取ってリモートで解決することも、クライアント自身が解決したアドレスを受け取ることもできます。どちらになるかはクライアント側の判断であり、多くのクライアントはデフォルトでローカル解決を行います。これが、同じゲートウェイであってもある設定では漏れ、別の設定では漏れない理由であり、これはほぼ常にプロキシ側ではなくクライアント側の設定の問題です。
多くのツールでは、この違いはたった1文字です。socks5://はローカルで解決することを意味し、socks5h://はホスト名をプロキシに渡すことを意味します。このhがすべての解決策です。
クライアント別の修正方法
curl。 socks5ではなくsocks5hスキームを使うか、そのスキームで--proxyを使ってください。
# 漏れる: ローカルで解決される
curl -x socks5://customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 https://example.com
# 正しい: プロキシ側でホスト名が解決される
curl -x socks5h://customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 https://example.comPython。 requestsとPySocksでは、スキームが同じ意味を持ちますが、どちらの綴りも動作してしまうため、間違いやすいポイントです。
import requests
user = "customer-USERNAME-country-de"
PROXY = f"socks5h://{user}:PASSWORD@p.shifter.io:443" # hに注目
r = requests.get("https://example.com",
proxies={"http": PROXY, "https": PROXY}, timeout=20)最もシンプルなのは、同じゲートウェイに対してHTTPスキームを使うことです。これはデフォルトでリモート解決を行うため、この問題自体を回避できます。これはPythonでレジデンシャルプロキシDNSを使うで紹介されている構成です。
Node。 SOCKSエージェントは通常、リモート解決のためのフラグを公開しています。ライブラリやバージョンによってデフォルトが異なるため、想定するのではなく、それが有効になっているか確認してください。
ヘッドレスブラウザ。 ここが最もリークが起きやすい箇所です。なぜならブラウザはプロキシ設定とは独立した独自のリゾルバ挙動を持つからです。Chromiumは独自のスタックを通じて解決を行い、SOCKS使用時にはDNSの経路を明示的に制限する必要があります。Firefoxには、SOCKSのホスト名をリモートで解決するかどうかを制御する設定があり、それは必ずしもデフォルトで有効ではありません。ブラウザを操作する場合は、想定せずに検証してください。以下のブラウザ固有のリーク経路にも注意してください。
実際にリークしているかテストする
設定から想定するのではなく確認してください。3段階のチェックがあります。
最も手早い方法は、ターゲットが見ているものと期待するものを比較することです。観測されたアドレスを報告するエンドポイントを取得し、それがあなたのエグジット地域と一致するか確認したうえで、地理的に敏感なページを取得し、コンテンツが一致するか確認します。アドレスは正しいのにコンテンツが間違っている場合、DNSが最有力の容疑者です。
より直接的には、プロキシ経由のリクエストが実行されている間、送信されるDNSトラフィックを監視します。リクエストを発行しているマシン上で、ポート53からターゲットのホスト名に対するクエリが出ているのを確認したら、解決はローカルで行われています。
# ターミナル1
sudo tcpdump -n -i any port 53
# ターミナル2
curl -x socks5h://customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 https://example.comキャプチャの中にターゲットのホスト名へのクエリが現れたら、クライアントがローカルで解決したということであり、リークを発見したことになります。
第三に、ブラウザの自動化については、公開されているDNSリークテストページのいずれかを使い、あなたに代わって応答したリゾルバを報告させ、それがあなたのエグジットの地域にあるか、それとも自分の地域にあるかを確認してください。
知っておくべきその他のリーク経路
DNSはよくあるものですが、参考までに、同種の問題を引き起こすものが他に3つあります。
IPv6。 プロキシがIPv4のみを扱い、あなたのシステムがデュアルスタックのターゲットに対してIPv6を優先する場合、そのトラフィックはプロキシを完全に迂回する可能性があります。収集を行うマシンでIPv6を無効にするか、クライアントでIPv4を強制することで、混乱を招く結果の一群を丸ごと排除できます。
WebRTC。 実際のブラウザでは、WebRTCがプロキシ設定を無視する別のメカニズムを通じて、ローカルおよびパブリックのアドレスを露出させる可能性があります。アイデンティティに敏感な用途でブラウザを操作している場合は、これを無効にしてください。
システムおよびライブラリのデフォルト。 一部のランタイムはDNS結果を積極的にキャッシュしたり、プロキシ設定に関わらずOSのリゾルバを参照したりします。また、hostsファイルのエントリやローカルのキャッシュリゾルバは、設定したすべてを上書きしてしまいます。
あなたの作業にとってアイデンティティの一貫性が重要であれば、DNSはいくつかの層のうちの一つであり、一致させる必要があるより広範なシグナル群についてはTLSおよびHTTP/2フィンガープリンティングとブロックを回避するで取り上げています。
簡単なチェックリスト
特にSOCKS5が必要でない限り、ゲートウェイに対してHTTPスキームを優先してください。これはデフォルトでリモート解決を行うためです。SOCKS5を使う場合は、常にsocks5hを使い、コードベース内の裸のsocks5://をgrepして見落としを見つけてください。設定を信頼せず、ポート53のパケットキャプチャで検証してください。プロキシの経路がIPv4のみの場合はIPv4を強制してください。自動化されたブラウザではWebRTCを無効にしてください。そのうえで、地理的に敏感なリクエストを再実行し、コンテンツが自分の場所ではなくエグジットの地域と一致することを確認してください。
結論
DNSリークとは、トラフィックはプロキシを通ったのに名前解決はそうならなかったことを意味します。これにより、クエリするドメインが自分自身のリゾルバに露出し、さらに収集にとってより重要なことに、あなたの所在地からドメインが解決されてしまい、エグジット先からは解決されません。HTTPプロキシはデフォルトでリモート解決を行うため、めったに漏れません。SOCKS5はクライアントがローカルで解決するたびに漏れます。これが、socks5hとsocks5の違いが最も一般的な修正方法である理由です。ヘッドレスブラウザは、プロキシ設定とは独立して解決を行うため、明示的な対応が必要です。設定を信頼するのではなくパケットキャプチャでテストし、ついでにIPv6とWebRTCも除外してください。地理ターゲット型のジョブが誤った地域のコンテンツを返し、エグジットアドレスが正しく見える場合、これが最初に確認すべきことです。
このゲートウェイは同じエンドポイント上でHTTP(S)とSOCKS5の両方を話すため、テストのためにスキームを切り替えてもコストはかかりません。詳しくはゲートウェイと認証を参照してください。製品は国別・都市別ターゲティングとGB単位の価格設定を備えたレジデンシャルプロキシです。