← ブログに戻る
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

SOCKS5とSOCKS5h：Python、curl、SeleniumでのDNSリクエスト漏れを修正する方法

SOCKS5を使用する際に、DNSリクエストがあなたのIPから直接送信される理由、SOCKS5hの違い、Python、curl、Selenium、アンチデテクトブラウザでこの問題を解決する方法を解説します。

📅2026年10月30日

あなたはSOCKS5プロキシを設定し、トラフィックはそれを通過しているように見え、ブラウザに表示されるIPも正しいですが、サイトは依然としてあなたの本当の地域を見たり、プロバイダーが何かを疑い始めたりします。その理由はほとんど常に同じです：DNSリクエストがあなたのコンピュータから直接送信され、プロキシをバイパスしているのです。この記事では、なぜこれが起こるのか、SOCKS5とSOCKS5hの違い、そしてコードや既存のツールでこの漏れをどのように修正するかを説明します。

SOCKS5とは何か、SOCKS5hとの違い

SOCKS5は、TCP/UDP接続レベルで動作し、パケットの内容を解析しないプロキシプロトコルです。これはHTTP(S)プロキシとは異なります。これにより、SOCKS5を介してほぼすべてのトラフィックをプロキシすることができます—ブラウザ、Telegram、トレントクライアント、Pythonのスクリプトなど。しかし、従来のSOCKS5の実装には重要な特徴があります：ドメイン名の解決（DNS）はデフォルトでクライアント側、つまりあなたのコンピュータで行われ、プロキシサーバー側では行われません。

SOCKS5hは、同じプロトコルですが、「h」（ホスト名）という修飾子が付いており、クライアントアプリケーションにドメインを自分で解決せず、そのままプロキシサーバーに送信し、プロキシが自分の名前でDNSリクエストを実行するように指示します。一文字の違いですが、匿名性と安定性に対する影響は根本的です。

重要なのは、SOCKS5hは別のプロトコルではなく、特定のライブラリやアプリケーションのレベルでプロキシへのリクエストを形成する方法に関する合意であるということです。プロキシサーバー自体は両方のケースで同じように動作します。違いは、DNS解決を開始するのがクライアントかサーバーかだけです。

なぜDNSリクエストがプロキシをバイパスするのか

あなたがhttps://example.comのようなアドレスにアクセスするとき、接続を確立する前にアプリケーションはそのドメインのIPアドレスを知る必要があります。このプロセスをDNS解決と呼びます。通常のSOCKS5を介して作業する場合、多くのライブラリやシステム設定は、プロバイダーやルーターのネットワーク設定に記載されているシステムDNSサーバーを介して解決を実行します。

結果として、逆説的な状況が生じます：HTTP/TCPトラフィック自体はプロキシを介して送信され、リクエストがプロキシサーバーのIPから来たように見えますが、DNSリクエスト「example.comのIPは何ですか？」はあなたの本当のIPからプロバイダーのDNSサーバーに直接送信されます。これがDNS漏れ（DNS leak）です。ネットワークの活動をより深いレベルで分析するサイトやサービス（このような検出手法はFacebook、Google、TikTokのアンチフロードシステムで積極的に使用されています）は、接続のIPとDNSリクエストのソースとの間に不一致を見つけることができます。

理由は、SOCKS5プロトコルが元々、名前の解決ではなく、すでに確立されたIP接続のためのトランスポートレベルとして設計されたからです。ライブラリやユーティリティの開発者は、DNSリクエストをトンネルを介して送信する機能を別途実装する必要がありました—これがSOCKS5hが「ドメインを自分で解決せず、私に任せて」という明示的な指示として登場した理由です。

実際のDNS漏れの危険性

パーサーや自動化スクリプトの開発者にとって、DNS漏れは抽象的な理論ではなく、アカウントのブロックや禁止の具体的な原因です。いくつかのシナリオを見てみましょう。

マーケットプレイスやサイトのパース。 あなたがWildberries、Ozon、または他のリソースを必要な地域のプロキシを介してパースしている場合でも、DNSリクエストがプロバイダーを通過すると、アンチボットシステムはジオロケーションの不一致を検出し、セッションの疑わしさを高める可能性があります—CAPTCHAやプロキシのIPの一時的なブロックに至ることもあります。

マルチアカウントとトラフィックの仲介。 Facebook Ads、TikTok Ads、またはGoogle Adsを複数のアカウントで操作する場合、アンチフロードシステムはDNSフィンガープリンティングを含む数十のパラメータを分析します。もし複数の「異なる」アカウントのDNSリクエストが突然同じプロバイダーのDNSサーバーを通過する場合、これはアカウントを一つのクラスターに統合する信号となり、その結果、チェーンバン（chain-ban）を引き起こします。

Selenium/Playwrightでの自動化。 ブラウザ内でユーザーの行動をエミュレートするスクリプトは特に脆弱です：ブラウザ自体がシステム設定を介してDNSを解決し、HTTPトラフィックのためにのみ設定されたプロキシを無視する可能性があります。その結果、他のすべてのネットワークフィンガープリントが実際の位置を示します。

これらのタスクのほとんどでは、レジデンシャルプロキシを使用して、サーバー側で正しく設定されたDNS解決を行うことが重要です—これにより、ネットワークの兆候による検出のリスクが大幅に低下します。

DNS漏れがあるかどうかを確認する方法

問題を修正する前に、実際に問題が存在するかどうかを確認する必要があります。以下は、確認のためのいくつかの簡単な方法です。

  1. dnsleaktest.comまたはipleak.netのサイトをプロキシ接続を介して開き、拡張テスト（Extended test）を実行します。
  2. 結果のDNSサーバーのリストを、実際のインターネットプロバイダーが誰であるかと比較します。プロキシのデータセンターの代わりにプロバイダーが表示される場合—漏れが確認されます。
  3. コマンドラインでは、tcpdumpまたはWiresharkを使用して、ポート53（DNS）でトラフィックをフィルタリングします—パケットがプロキシトンネルを介さずにプロバイダーのサーバーに直接送信されている場合、問題はあなたの側にあります。
  4. Pythonでは、socket.getaddrinfo()を使用して、プロキシを有効にする前後で手動で解決を迅速に確認できます—IPがプロキシなしの結果と一致する場合、解決はローカルで行われています。

Pythonでの修正（requests、PySocks、urllib3）

Pythonスクリプトで最も一般的なエラーは、requestsライブラリをPySocksと共に使用する際に、socks5hスキームを明示的に指定しないことです。一文字の違いですが、どちらがドメインを解決するかを決定します。 

import requests

# 悪い: DNSはローカルで解決され、プロキシをバイパスします
proxies_leak = {
    "http": "socks5://user:pass@proxy_host:1080",
    "https": "socks5://user:pass@proxy_host:1080",
}

# 良い: DNSはプロキシサーバー側で解決されます
proxies_safe = {
    "http": "socks5h://user:pass@proxy_host:1080",
    "https": "socks5h://user:pass@proxy_host:1080",
}

response = requests.get("https://example.com", proxies=proxies_safe, timeout=10)
print(response.status_code)
print(response.text[:200])

socks5hスキームをrequestsを介して正しく機能させるには、依存関係をインストールする必要があります： 

pip install "requests[socks]" PySocks

低レベルのurllib3を直接使用する場合、例は次のようになります： 

from urllib3.contrib.socks import SOCKSProxyManager

proxy = SOCKSProxyManager(
    "socks5h://user:pass@proxy_host:1080",
    num_pools=10
)

response = proxy.request("GET", "https://example.com")
print(response.status)

aiohttpの非同期スクリプトでは、aiohttp-socksライブラリを使用し、スキームは同様に指定します： 

import aiohttp
from aiohttp_socks import ProxyConnector

connector = ProxyConnector.from_url("socks5h://user:pass@proxy_host:1080")

async def fetch():
    async with aiohttp.ClientSession(connector=connector) as session:
        async with session.get("https://example.com") as resp:
            print(await resp.text())

curlでの修正

curlにもSOCKS5プロキシ用の2つの異なるフラグがあり、それらの間の混乱はbashスクリプトにおけるDNS漏れの古典的な原因です。 

# 悪い: ローカルマシンでの解決
curl --socks5 proxy_host:1080 https://example.com

# 良い: プロキシサーバー側での解決
curl --socks5-hostname proxy_host:1080 https://example.com

# 認証付き
curl --socks5-hostname user:pass@proxy_host:1080 https://example.com

フラグ--socks5-hostnameは、他のツールにおけるsocks5hの直接のアナログです。これはcurlに「DNSを触らず、ドメインをそのままプロキシサーバーに渡せ」と指示します。

SeleniumとPlaywrightでの修正

ブラウザの自動化では、状況がより複雑です：ChromeやFirefoxはデフォルトでシステム設定を介してDNSを解決し、ネットワークリクエストレベルで設定されたプロキシを無視する可能性があります。SeleniumでChromeを使用する場合、ブラウザの起動フラグを使用してプロキシを介した解決を明示的に有効にする必要があります。 

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

options = Options()
options.add_argument("--proxy-server=socks5://proxy_host:1080")
# 重要なフラグ: プロキシを介してDNSを解決する
options.add_argument("--host-resolver-rules=MAP * ~NOTFOUND , EXCLUDE proxy_host")

driver = webdriver.Chrome(options=options)
driver.get("https://example.com")

Playwrightでは、ライブラリはデフォルトでプロキシがブラウザのコンテキスト設定に指定されている場合、DNSをプロキシを介して解決します。 

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(
        proxy={"server": "socks5://proxy_host:1080"}
    )
    page = browser.new_page()
    page.goto("https://example.com")
    print(page.title())
    browser.close()

それでも、設定後にdnsleaktest.comで実際の動作を常に確認することをお勧めします—動作はChromiumのバージョンによって異なる場合があります。

アンチデテクトブラウザでの設定

あなたがコードを書いていない場合、Dolphin Anty、AdsPower、Multilogin、またはGoLoginのようなアンチデテクトブラウザを使用している場合、良いニュースは、これらのほとんどがSOCKS5プロトコルを選択する際に自動的にプロキシサーバーを介してDNSを解決することです。「h」を手動で指定する必要はありません。これは自作スクリプトに対する彼らの主な利点の一つです。

ただし、実際にこれを確認する価値があります：アンチデテクトブラウザのプロファイルを開き、dnsleaktest.comに移動し、プロファイル内で拡張テストを実行します。プロキシの地域に一致するDNSサーバーが表示され、あなたの本当のプロバイダーではない場合—設定は正しいです。そうでない場合は、特定のアンチデテクトブラウザのサポートに問い合わせるか、DNS解決の問題がそれほど深刻でないHTTP(S)プロキシのタイプに変更してください。HTTPプロキシは常に完全なURLで動作します。

Instagram、TikTokのアカウントを作成し、Facebook Adsの広告管理を行うためには、モバイルプロキシが非常に効果的です—携帯電話の運営者によるIPの動的ローテーションにより、アンチフロードシステムの疑いを受けにくくなります。たとえどこかのチェーンで小さなDNS漏れが発生したとしても。

プロトコルの比較表

プロトコル 誰がDNSを解決するか 漏れのリスク どこで使用するか
SOCKS5 クライアント（あなたのコンピュータ） 高い DNSが重要でない場合のみ（ローカルテスト）
SOCKS5h プロキシサーバー 低い パース、マルチアカウント、自動化
HTTP/HTTPSプロキシ プロキシサーバー（デフォルト） 低い ウェブトラフィック、ブラウザ、APIリクエスト

あなたのタスクが特定のユーザー地域に依存しない高速データ収集である場合、データセンタープロキシを検討してください—トラフィック量に対して安価で、SOCKS5hと組み合わせてパースに最適です。ここでは速度が重要であり、居住者ユーザーに偽装する必要はありません。

プロジェクト開始前のチェックリスト

  • socks5h://スキームをすべてのライブラリと設定で使用し、socks5://を使用しないこと。
  • curlでは--socks5-hostnameフラグを使用し、--socks5を使用しないこと。
  • Seleniumでは--host-resolver-rulesフラグを追加するか、組み込みのプロキシ解決を持つPlaywrightを使用すること。
  • 設定後にdnsleaktest.comまたはipleak.netで結果を確認し、設定前ではないこと。
  • アンチデテクトブラウザでプロファイル内のDNSフィンガープリンティングをテストし、外部IPだけでなく。
  • 高い匿名性が求められるタスクには、データセンタープロキシの代わりにレジデンシャルまたはモバイルプロキシを検討すること。

結論

SOCKS5とSOCKS5hの違いは文字通り一文字ですが、それはDNSリクエストを解決するのがあなたのコンピュータかプロキシサーバーかを決定します。DNS漏れは、パース、マルチアカウント、自動化広告管理における検出の最も目立たないが一般的な原因の一つです。dnsleaktest.comを介した確認と、コード、curlコマンド、またはブラウザ自動化の設定でsocks5hスキームを明示的に指定することで、この穴を数分で閉じることができます。

あなたがタスクのためのインフラを選んでいる場合—パースやAPI作業には<а href="https://proxycove.com/ja/datacenter-proxies/" style="color:#2563eb;">データセンタープロキシが最適で、マルチアカウントやソーシャルメディアには<а href="https://proxycove.com/ja/residential-proxies/" style="color:#2563eb;">レジデンシャルプロキシが適しており、モバイルアプリケーションでの自然なネットワークフィンガープリンティングには<а href="https://proxycove.com/ja/mobile-proxies/" style="color:#2563eb;">モバイルプロキシが最適です。いずれの場合でも、SOCKS5hを介したDNS解決の正しい設定は、プロジェクトを本番環境に展開する前の必須ステップです。

関連記事