1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

データ収集の悩みを一気に解決！Bright Dataの次世代Webスクレイピングにチャレンジ
@harupythoninDisnana

Bright Dataのプロキシは本当に検知されないのか？475個のIPで検証してみた

Last updated at Posted at 2026-01-21

はじめに

「プロキシサービスは検知されない」と謳うサービスは多いですが、本当でしょうか。

今回、データ収集の悩みを解決するBright Dataのキャンペーンに参加し、proxycheck.io v3 APIを使って475個のIPアドレスを検証しました。結果は予想を超えるものでした。

TL;DR（結論）

  • 475個のユニークIPを検証
  • プロキシ検知されたのはわずか2件（0.4%）
  • VPN検知は0件（0.0%）
  • 平均リスクスコアは0.42と極めて低い
  • 60カ国以上からのアクセスを確認

proxycheck.ioのv3 APIは、v2と比較してより高精度な検知アルゴリズムを実装していますが、それでもBright Dataの99.6%が検知を回避しました

検証環境

  • プロキシ: Bright Data（住宅用プロキシ）
  • 検証API: proxycheck.io v3
  • 検証IP数: 475個
  • 収集方法: Bright Data経由のアクセスログ
  • 言語: Python 3.11

実装の流れ

今回は3段階のプロセスで検証を行いました。

ステップ1: IPアドレス収集（logger.py）

Bright Data経由でアクセスを行い、実際に使用されたIPアドレスを収集します。

主要な実装ポイント

def create_proxy_opener():
    """Bright Dataのプロキシを設定"""
    proxy_handler = urllib.request.ProxyHandler({
        'https': PROXY_URL,
        'http': PROXY_URL
    })
    https_handler = urllib.request.HTTPSHandler(
        context=ssl._create_unverified_context()
    )
    return urllib.request.build_opener(proxy_handler, https_handler)

IPLoggerなどのサービスは、アクセス元のIPアドレスを記録する目的で使用しますが、プライバシーに配慮した利用を心がけてください

ステップ2: 検証実行（proxycheck.py）

収集したIPアドレスをproxycheck.io v3 APIで検証します。

重要な実装部分を抜粋

def check_ip_proxycheck(ip_address, max_retries=3, retry_delay=2, verbose=False):
    """
    proxycheck.io v3でIPアドレスをチェック
    ⚠️ 重要: ローカル接続（プロキシなし）で実行
    """
    # ローカル接続用のopener（プロキシなし）
    opener = urllib.request.build_opener(
        urllib.request.HTTPSHandler(
            context=ssl._create_unverified_context()
        )
    )
    
    # v3 APIエンドポイント
    if PROXYCHECK_API_KEY:
        url = f"https://proxycheck.io/v3/{ip_address}?key={PROXYCHECK_API_KEY}"
    else:
        url = f"https://proxycheck.io/v3/{ip_address}"

proxycheck.ioのAPIは、プロキシ経由でアクセスすると429エラーが頻発します。検証時は必ずローカル接続を使用してください

ステップ3: 並列処理で大量検証

ThreadPoolExecutorで効率的に検証します。

進捗表示にはtqdmを使用しています

with ThreadPoolExecutor(max_workers=MAX_WORKERS) as executor:
    futures = {}
    
    # タスク投入（レート制限対策）
    for ip in ips:
        future = executor.submit(check_ip_proxycheck, ip)
        futures[future] = ip
        time.sleep(DELAY)
    
    # 進捗バーで結果収集
    if use_tqdm:
        pbar = tqdm(
            total=len(ips),
            desc="Checking IPs",
            unit="ip"
        )

完全なコードはGitHubで公開しています。

検証結果

全体統計

475個のIPアドレスを検証した結果がこちらです。

項目 結果
総IP数 475個
プロキシ検知 2件 (0.4%)
VPN検知 0件 (0.0%)
Tor検知 0件 (0.0%)
平均リスクスコア 0.42
最大リスクスコア 100
検出国数 60カ国以上

驚くべきことに、99.6%のIPがプロキシ/VPN検知を完全に回避しました。

国別分布

使用されたIPの国別分布（上位10カ国）

国名 件数 割合
United States 120 25.3%
Brazil 90 18.9%
Mexico 32 6.7%
Vietnam 31 6.5%
Argentina 23 4.8%
Colombia 17 3.6%
Philippines 12 2.5%
Peru 9 1.9%
United Kingdom 8 1.7%
Indonesia 8 1.7%

詳細な国別データはproxycheck_stats_countries.csvで公開しています。

Bright Dataの住宅用プロキシは、世界中の一般家庭や企業のISP回線を使用しているため、地理的に分散したアクセスが可能です。

成功例の詳細

検知されなかった473件の特徴を見てみましょう。

{
  "proxy": "no",
  "type": "Residential",
  "risk": 0,
  "isocode": "US",
  "provider": "Comcast Cable Communications"
}

ほとんどのリクエストで以下が確認できました

  • proxy: no - プロキシとして検知されず
  • type: Residential - 住宅用回線として認識
  • risk: 0 - リスクスコア完全にゼロ
  • ISP名が一般的な通信事業者（Comcast、KDDI、Cox Communicationsなど）

つまり、proxycheck.ioは完全に騙されています。

失敗例の分析

興味深いのは、475件中2件だけ検知された事例です。

検知されたケース1

{
  "proxy": "yes",
  "type": "VPN",
  "risk": 100,
  "asn": "AS13335",
  "provider": "Cloudflare, Inc."
}

検知されたケース2

{
  "proxy": "yes",
  "type": "Hosting",
  "risk": 75,
  "asn": "AS16509",
  "provider": "Amazon.com, Inc."
}

両方ともクラウドプロバイダーのASNを経由していました。Bright Dataの住宅用プロキシは通常ISPネットワークを使用しますが、稀にCDNやクラウド経由のIPが割り当てられることがあるようです。

CloudflareやAWSなどのクラウドプロバイダーのIPは、住宅用プロキシでも検知されるリスクがあります。ただし、発生率は0.4%と極めて低いです

なぜ99.6%も回避できたのか

proxycheck.io v3は以下の方法でプロキシを検知します

  1. ASNブラックリスト - データセンターやVPNプロバイダーのASNを記録
  2. ポート開放チェック - プロキシで一般的なポートの開放状況
  3. リバースDNS検証 - ホスト名の分析
  4. IPレピュテーション - 過去の使用履歴
  5. 機械学習モデル - v3で強化された検知アルゴリズム

Bright Dataの住宅用プロキシは、実際の家庭や企業のISP回線を使用しているため、これらのチェックをすり抜けます。

検証結果を見ると、ComcastやKDDIといった一般的なISPからの接続として認識されています。これが高い回避率の秘密です。

API v2からv3への変更点

今回使用したv3 APIの主な改善点

エンドポイント変更

# v2
url = f"https://proxycheck.io/v2/{ip}?vpn=1&asn=1"

# v3
url = f"https://proxycheck.io/v3/{ip}?key={api_key}"

レスポンス形式の改善

v3では、より詳細な情報が返されます。

{
  "status": "ok",
  "proxy": "no",
  "type": "Residential",
  "risk": 0,
  "port": "no",
  "seen": "no",
  "days": 0,
  "tag": "none"
}

検知精度の向上

v3では機械学習ベースの検知が追加され、理論的には検知精度が向上しているはずですが、Bright Dataは依然として高い回避率を維持しています。

実用的な活用例

GitHub API制限の突破

未認証で60リクエスト/時、認証でも5,000リクエスト/時の制限があります。Bright Data経由なら、実質無制限に近い大規模リポジトリ分析が可能になります。

def fetch_github_trends():
    """GitHubのトレンドリポジトリを大量取得"""
    proxy_opener = create_proxy_opener()
    results = []
    
    for page in range(1, 100):  # 通常なら制限でブロック
        url = f"https://api.github.com/search/repositories?q=stars:>1000&page={page}"
        with proxy_opener.open(url) as response:
            data = json.loads(response.read())
            results.extend(data['items'])
        time.sleep(1)
    
    return results

毎回異なるIPからアクセスするため、GitHub側では別々のユーザーからのリクエストに見えます。これにより、レート制限を実質的に回避できます

並列スクレイピング

単一IPからの大量アクセスを制限するサイトでも、並列処理と組み合わせることで驚異的なスループットが実現できます。

from concurrent.futures import ThreadPoolExecutor

def scrape_with_parallel():
    """並列処理で高速スクレイピング"""
    urls = [f"https://example.com/page/{i}" for i in range(1000)]
    
    with ThreadPoolExecutor(max_workers=10) as executor:
        # 10並列で処理しても各リクエストが異なるIPから送信される
        futures = [executor.submit(fetch_via_proxy, url) for url in urls]
        results = [f.result() for f in futures]
    
    return results

並列処理を行う際は、対象サーバーへの負荷に注意してください。適切なリクエスト間隔を設けることを推奨します

結果分析ツール

検証結果の分析には専用スクリプトを用意しています。

以下のCSVファイルが自動生成されます：

  • proxycheck_stats.csv - 全IP詳細データ
  • proxycheck_stats_summary.csv - サマリー統計
  • proxycheck_stats_countries.csv - 国別分布

パフォーマンス考察

処理時間と効率

475個のIPを検証するのに約8分かかりました。

  • 処理速度: 約1 IP/秒
  • 並列度: 3ワーカー
  • リクエスト間隔: 1秒

proxycheck.ioのレート制限対策として、リクエスト間隔を1秒に設定しています。APIキーを使用することで、より高速な処理も可能です。

コストパフォーマンス

今回の検証で発生したコスト

Bright Dataのコスト

  • 住宅用プロキシ（共有・GBごとの支払い）: $8/GB
  • 今回の使用量: 約30MB
  • コスト: 約$0.23

proxycheck.ioのコスト

  • 無料プラン: 1,000リクエスト/日
  • 今回の使用量: 475リクエスト
  • コスト: $0（無料枠内）

合計でわずか$0.23で、475個のIPアドレスを検証できました。商用レベルのプロキシサービスとしては驚異的なコストパフォーマンスです

有料プランとの比較

proxycheck.ioの有料プラン（$43.89/年、10,000リクエスト/日）と比較すると、Bright Dataを使えば：

  • レート制限を実質的に無制限化できる
  • 毎回異なるIPからアクセスするため、サーバー側では別ユーザーに見える
  • 475リクエストあたり$0.23という低コスト

すごい点のまとめ

1. 並列処理が可能

通常のプロキシサービスは、同一IPからの並列リクエストで制限されがちですが、Bright Dataは毎回異なるIPを使用するため、高い並列度を維持できます。

# 10並列でも問題なし！
with ThreadPoolExecutor(max_workers=10) as executor:
    futures = [executor.submit(fetch_data, i) for i in range(100)]

2. レート制限がかからない

各リクエストが異なるIPから送信されるため、サーバー側のレート制限を実質的に回避できます。これは他のプロキシサービスでは実現困難です。

3. 検知されない

99.6%という圧倒的な検知回避率により、bot対策の厳しいサイトでも安定してアクセスできます。

この3つの特性を組み合わせることで、従来では不可能だった大規模データ収集が現実的になります

注意事項と倫理的配慮

レート制限回避の倫理的問題

レート制限は、サーバー保護やサービス品質維持のために設けられています。Bright Dataを使えば技術的には回避できますが、以下の点に注意してください

  • 対象サイトの利用規約を必ず確認する
  • サーバーに過度な負荷をかけない
  • 適切なリクエスト間隔を設ける
  • 収集したデータの取り扱いに注意する

本記事は技術検証を目的としており、悪用を推奨するものではありません

まとめ

Bright Dataのプロキシは、proxycheck.io v3の検知を99.6%回避できることが実証されました。

検証のポイント

  • 475個のユニークIPを使用し、ほぼ全てが検知を回避
  • 平均リスクスコアは0.42と極めて低い
  • CloudflareやAWS経由のIPは稀に検知される（0.4%）
  • 60カ国以上からの分散アクセスが可能
  • 並列処理とレート制限回避を両立
  • コストパフォーマンスに優れる（475リクエストで$0.23）

今回の検証で、プロキシサービスの性能を数値的に評価できました。データ収集やAPI利用において、Bright Dataは強力な選択肢となります。

ただし、技術的に可能であることと、それを実行すべきかは別問題です。サーバーへの過度な負荷を避け、利用規約を遵守した上での活用を心がけましょう。

完全なコードと実行結果はGitHubで公開しています。

参考資料

1
1
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?