← ブログに戻る

WebRTCおよびDNSの漏洩:アカウントに初めてログインする前に確認すべき7つのチェックポイント

WebRTCとDNSの漏洩がアンチデテクトブラウザで本物のIPをどのように暴露するかを解説し、新しいアカウントに初めてログインする前の7つのチェックリストを提供します。

📅2026年10月1日

一つの見逃されたWebRTCまたはDNSの漏洩が、アカウントのファーミングの数ヶ月を一度のログインで無にする可能性があります。Facebook、TikTok、Instagramのプラットフォームは、プロキシの「主張された」IPとブラウザを介して漏洩する実際のIPを照合する方法をすでに学んでいます。この記事では、新しいプロフィールを開く前に行うべき7つのチェックリストを具体的に示します。

WebRTCとDNSの漏洩とは何か、なぜそれがプロフィールを破壊するのか

アンチデテクトブラウザでプロフィールを立ち上げ、プロキシを接続すると、サイトはプロキシのIPしか見えないと期待します。しかし実際には、ブラウザはあなたの本当のIPを明らかにする可能性のある2つのメカニズム、WebRTC(ビデオ通話やP2P接続のための技術)とDNSリクエスト(ドメイン名をIPアドレスに変換する)を同時に使用しています。これらのチャネルがマスクされていない場合、プラットフォームは1つのプロフィールに対して2つの異なるアドレスを取得します。これはFacebook、TikTok、Instagramの詐欺システムにとっての典型的なトリガーです。

アービトラージャーにとって、これはキャンペーンを開始する前に広告アカウントが即座にバンされることを意味します。20〜30のクライアントアカウントを管理するSMM専門家にとっては、漏洩を通じて1つの実際のIPを使用している場合、複数のプロフィールが一度に大量にブロックされるリスクがあります。WildberriesやOzonをマルチアカウントでパースしているセラーにとって、DNSの漏洩はすべての「匿名」のリクエストを1つの実際のアドレスに結びつけ、地理的な理由で迅速にブロックされる可能性があります。

主な問題は、漏洩が目に見えないことです。プロフィールは正常に開かれ、広告は回り、フィードは読み込まれます。問題は数時間または数日後に現れ、プラットフォームのアルゴリズムが統計を蓄積し、異なるプロフィール間でIPアドレスを照合する時に発生します。だからこそ、チェックは最初のログイン前のルーチンの一部であるべきであり、すでに発生したバンへの反応ではありません。

WebRTCがあなたの実際のIPをどのように明らかにするか

WebRTC(Webリアルタイムコミュニケーション)は、サーバーを介さずにデバイス間で音声、ビデオ、およびデータを直接交換するためのブラウザに組み込まれたプロトコルです。この接続を確立するために、ブラウザはICE(インタラクティブ接続確立)メカニズムを介してデバイスの実際のパブリックおよびローカルIPアドレスを知る必要があります。これは、システムやブラウザに設定されたプロキシが何であれ、WebRTCがネットワークスタックのレベルで動作するため、独立して行われます。

実際には、次のようになります。ドイツのIPを持つレジデンシャルプロキシを介してFacebookにアクセスしますが、ページ上のスクリプトはWebRTCを介してあなたのロシアの自宅または職場のIPを取得します。Facebookは両方のアドレスを記録し、ジオロケーションを比較し、不一致を見てプロフィールを疑わしいものとしてマークします。たとえバンがすぐに発生しなくても、アカウントは高い監視モードに入り、アクションの制限が減少し、広告のリーチが低下します。

通常のブラウザであるChromeやFirefoxは、デフォルトでこの漏洩をブロックしません。WebRTCをフラグで無効にするか、組み込みの保護を持つアンチデテクトブラウザを使用する必要があります。Dolphin Anty、AdsPower、Multilogin、GoLogin、およびOcto Browserには、WebRTCモードのための個別のスイッチがあります。プロトコルを完全に無効にするか、パブリックIPをプロキシのアドレスに置き換えるか、パブリックIPなしでローカルIPのみを残すことができます。マルチアカウントの場合、正しい選択はプロキシのIPへの置き換えであり、完全な無効化ではありません。なぜなら、WebRTCの完全な無効化自体が検出可能なパターンになる可能性があるからです。

DNSリクエストがあなたの本当の場所をどのように明らかにするか

DNS漏洩は、ブラウザまたはオペレーティングシステムがプロキシを介さずに、プロバイダーのDNSサーバーを介してドメインをIPに変換するリクエストを送信する場合に発生します。これは特に、デフォルトでDNSトラフィックを常にキャッチしないSOCKS5プロキシに特徴的です。結果として、サイトはHTTPリクエスト用のプロキシのIPを取得しますが、プロバイダーのDNSサーバーはあなたの実際の地域を「見る」ことができ、この情報はサードパーティの分析スクリプトやアンチフロードシステムを介して照合される可能性があります。

特定のGEOからFacebook AdsやTikTok Adsを介して広告を開始するアービトラージャーにとって、DNS漏洩は、プラットフォームが一国のプロバイダーを見て、IPアドレスが別の国から来ていることを意味します。これはプロキシの使用の直接的な信号であり、しばしば追加の検証やキャンペーンのブロックにつながります。異なる都市からクライアントのアカウントを管理するSMMエージェンシーにとって、DNS漏洩はすべてのプロフィールが物理的に同じ場所から管理されていることを明らかにし、「異なる人々が異なるアカウントを管理している」という論理を壊します。

WebRTCとは別にDNS漏洩をチェックすることは重要です。なぜなら、これは2つの異なるデータ伝送チャネルであり、1つからの保護がもう1つからの保護を保証しないからです。多くの初心者はWebRTCの置き換えだけを設定し、プロフィールが保護されていると考えていますが、DNSリクエストはネットワークアダプターの設定が間違っている場合や、アンチデテクトブラウザ内のプロキシではなくシステムプロキシを使用している場合にプロキシを通過する可能性があります。

プロフィールに初めてログインする前の7つのチェック

以下は、Facebook、Instagram、TikTokにログインする前に各新しいプロフィールで実行すべきアクションの順序です。

  1. プロキシの種類とプロトコルを確認してください。 SOCKS5またはDNSの完全トンネリングをサポートするHTTP(S)が使用されていることを確認し、「生の」SOCKS DNSプロキシなしで使用されていることを確認してください。
  2. プラットフォームに入る前に漏洩チェックサービスを開いてください。 アンチデテクトブラウザのプロフィール内でbrowserleaks.com/webrtcおよびbrowserleaks.com/dnsにアクセスしてください — 通常のChromeではなく。
  3. パブリックIPとプロキシのIPを比較してください。 WebRTCセクションでサービスが表示するアドレスは、あなたのプロキシのIPと一致する必要があり、自宅またはモバイルIPと一致してはいけません。
  4. DNSサーバーのリストを確認してください。 DNS漏洩テストセクションでは、すべてのサーバーがプロキシの国とプロバイダーに関連している必要があり、あなたの実際のインターネットプロバイダーに関連してはいけません。
  5. タイムゾーンとブラウザの言語によるジオロケーションを確認してください。 アンチデテクトブラウザのプロフィール内のタイムゾーン、システムの言語、およびジオロケーションは、プロキシのIPの国と一致する必要があります — 不一致も疑わしいパターンとして読み取られますが、形式的にはWebRTC/DNSの漏洩ではありません。
  6. whoer.netまたはipleak.netでプロフィールをテストしてください。 2つ目の独立したサービスは確認チェックを提供します — 両方のサービスが同じクリーンな結果を示す場合、漏洩のリスクは最小限です。
  7. チェックの結果をプロフィール管理表に記録してください。 複数のアカウントを管理するエージェンシーやチームにとって、記録を保持することは重要です:チェックの日付、プロキシのIP、WebRTC/DNSテストの結果。これは、大量のバンを調査する際に数時間を節約します。

重要

チェックは必ずアンチデテクトプロフィール内で、アクティブなプロキシを使用して行う必要があります。通常のChromeで合格したテストは、置き換えられたパラメータを持つ隔離されたプロフィールの状態を反映しません。

Dolphin Anty、AdsPower、Multilogin、GoLoginでの保護設定

Dolphin Antyでは、WebRTCの設定はプロフィール作成セクションの「プロキシとWebRTC」タブにあります。「無効」ではなく「変更された」モード(プロキシのIPに置き換える)を選択する必要があります。これにより、プラットフォームは合意されたアドレスを見て、プロトコルが完全に存在しないわけではありません。プロフィールを保存した後は、必ずそれを開いてbrowserleaks.comでテストしてください。その後、アカウントにログインします。

AdsPowerでは、同様のオプションはプロフィール作成時のフィンガープリンタータブにある「WebRTC」と呼ばれています。プロキシからのIPを自動的に挿入する「置き換え」オプションを選択してください。そこにはDNSブロックもあり、DNSリクエストがHTTPトラフィックと同じトンネルを通るように「プロキシDNSを使用」を有効にすることをお勧めします。

Multiloginでは、WebRTCの保護がMimicおよびStealthfoxエンジンに組み込まれており、デフォルトでパブリックIPをプロキシのアドレスに置き換えます。手動設定は不要ですが、新しいプロキシをリンクした後は、プロフィールを更新して再度テストを実行することが重要です。時々、セッションの再作成が必要です。

GoLoginとOcto Browserでは、WebRTCの設定はプロフィールのフィンガープリンター設定のネットワークセクションにあります — プロキシに基づく置き換えモードを選択し、完全なブロックではなく選択してください。Octo Browserは、プロキシの国に対応するDNSサーバーを手動で指定することも可能で、TikTok AdsやGoogle Adsのための非標準GEOで作業する際に便利です。

すべてのブラウザに共通する原則は1つです:まずプロキシを設定し、次にWebRTCとDNSがこのプロキシと同期していることを確認し、その後に必要なプラットフォームを開きます。レジデンシャルプロキシを使用している場合、ジオロケーションの不一致のリスクは低くなります。なぜなら、IPは必要な国の実際のユーザーに属し、DNSサーバーは通常、この地域に論理的に関連しているからです。

漏洩チェック用のサービス

漏洩を監視するには、異なる詳細を提供し、結果を相互に確認できる3〜4の信頼できるサービスがあれば十分です。

サービス 何をチェックするか いつ使用するか
browserleaks.com WebRTC、DNS、Canvas、ブラウザのフィンガープリンティング 各新しいプロフィールの基本チェック
ipleak.net IP、DNSサーバー、ジオロケーションの一致 最初の後の確認チェック
whoer.net 匿名性、タイムゾーン、ブラウザの言語、プロキシフラグ 広告キャンペーンを開始する前
dnsleaktest.com 使用されているDNSサーバーの詳細リスト 特定のプロキシでDNS漏洩が疑われる場合

ルールは簡単です:サービスのいずれかが、プロキシの主張されたジオロケーションとIPまたはDNSサーバーの不一致を示す場合、問題が解決されるまでそのプロフィールをターゲットアカウントにログインするために使用することはできません。

プロキシとプロフィール設定時の一般的なミス

最初のミスは、オペレーティングシステムのシステムプロキシを使用することです。これはアンチデテクトブラウザ内に設定されたプロキシではなく、システムプロキシはすべてのプロセスに適用されず、DNSを含む一部のトラフィックがプロバイダーを介して直接流れる可能性があります。

2番目のミスは、プロキシの国に関連付けられていない無料の公開DNSを信頼することです。プロキシがポーランドで発行され、DNSサーバーがアメリカの公開リゾルバーである場合、これは論理的な不一致を生じ、FacebookやTikTokの高度なアンチフロードシステムによって記録されます。

3番目のミスは、ローテーションなしで複数のプロフィールに同じプロキシを再利用することです。WebRTCとDNSが完璧に設定されていても、10のアカウントが同じIPでログインすると、プラットフォームは関連するプロフィールのクラスターを見て、1つの違反があった場合に連鎖的にバンします。

4番目のミスは、既存のプロフィール内でプロキシを変更した後の再確認をスキップすることです。多くの人がアカウントを「更新」するためにIPを変更しますが、漏洩テストを再度実行することを忘れます — WebRTCの設定は、アンチデテクトブラウザの更新時にリセットされる可能性があります。

5番目のミスは、InstagramやTikTokなどの一般ユーザーとの類似性が重要なタスクにデータセンターのプロキシを使用することです。プラットフォームはASNの範囲によってデータセンターのIPを簡単に特定し、クリーンなWebRTC/DNSテストであっても、IPの性質のためにアカウントは高い監視に入ります。

漏洩とバンのリスクを減らすプロキシの種類

プロキシの種類の選択は、アンチデテクトブラウザが完璧に設定されていても、不一致がどれほど目立つかに直接影響します。

プロキシの種類 IPによる検出リスク 適している用途
レジデンシャルプロキシ 低い Facebook Ads、Instagram、TikTok、マルチアカウント
モバイルプロキシ 最小限 TikTok Ads、アカウントのウォームアップ、厳しいアンチフロードシステム
データセンタープロキシ 高い Wildberries、Ozonのパース、厳しい検証が必要ないタスク

広告管理やソーシャルメディアでは、レジデンシャルおよびモバイルIPが、たとえ技術的にWebRTC/DNSテストがクリアされていても、プラットフォームがプロフィールに注意を向け始める可能性を減少させます。マーケットプレイスのパースでは、速度とリクエストの量が重要であり、データセンタープロキシは定期的なIPのローテーションが条件で、実行可能なオプションとして残ります。

結論

WebRTCとDNSの漏洩は、理論的な脅威ではなく、新しいプロフィールに初めてログインした直後のほとんどの「理解できない」バンの具体的な原因です。7つのポイントからなるチェックリストによる確認は、各アカウントに3〜5分かかりますが、バンされたプロフィールの回復や、広告やInstagramアカウントが消えた理由をクライアントに説明する際に数時間を節約します。

Facebook Ads、TikTok Adsでマルチアカウントを管理している場合や、Instagramでクライアントのプロフィールを管理している場合は、Dolphin Anty、AdsPower、MultiloginでのWebRTCとDNSの正しい設定を、高品質のレジデンシャルプロキシと組み合わせることをお勧めします。これにより、アンチフロードシステムが捕捉する不一致の可能性が減り、最初のログインから各プロフィールがより安定します。