Webサイトをブロックされずにスクレイピングする方法

深刻なWebスクレイピングプロジェクトは、最終的に同じ壁に当たる:リクエストはCAPTCHAs、403エラー、または空のページを返します。 ウェブサイトは自動トラフィックを検知し、スクレーパーとアンチボットシステム間のアームレースがこれまで以上に激しくなっています。 価格データの収集、競合コンテンツの監視、AIトレーニングのデータセットの構築、学習など ブロックすることなくウェブサイトをスクレイピング もはやオプションではありません。信頼性のあるデータパイプラインの基礎です。

このガイドは、ブロックの背後にある技術上の理由、検出信号現代のアンチボットシステムが探して、スクレーパーがスムーズに動くように実証済みの戦略をカバーしています。 作業用コード例を含めて 住宅のプロキシ これらの概念が生産準備の実装にどのように変換するかを示すために。

なぜウェブサイトブロックスクレーパー

問題を解決する前に、問題に対する理解に役立ちます。 ウェブサイトでは、複数の正当な理由で、アンチボット対策を導入しています。

• インフラ保護 — 攻撃的なスクレイピングは、サーバーを圧倒し、実際のユーザーのためのパフォーマンスを劣化させ、ホスティングコストを膨脹させることができます。
• コンテンツ保護 — 出版社、eコマースサイト、データプロバイダは、競合他社がデータをスケールでコピーしないようにしたい。
• セキュリティ — クレデンシャル詰め物、DDoS攻撃、脆弱性スキャンによる自動トラフィックパターンの重複。
• 規制遵守 — 個人データを扱うサイトは、プライバシー規則を遵守して自動アクセスを制限する場合があります。

現代のウェブサイトは、Cloudflare Bot Management、Akamai Bot Manager、PerimeterX、DataDomeなどの特殊なアンチボットサービスに依存しています。 これらのサービスは、信号の組み合わせを使用してリアルタイムでトラフィックを分析し、ネットワーク全体でインテリジェンスを共有します。つまり、1つのサイト上にフラグが設定されたパターンは、何千もの他の人にブロックをトリガーできます。

ブロックされる検出信号

アンチボットシステムは、1つの指標にはほとんど依存しません。 複数の信号からリスクスコアを構築し、閾値を超える要求をブロックします。 主な検出ベクトルは次のとおりです。

IPアドレスの評判

これは最も基本的な信号です。 データセンターIPの範囲は、十分に文書化され、本質的に高いリスクスコアを運ぶ。 AWS、Google Cloud、または既知のホスティングプロバイダからのリクエストが発生した場合、多くのアンチボットシステムが即座にチャレンジまたはブロックします。 でも、 住宅IP単一アドレスからのリクエストが多すぎるとフラグが付けられます。 IP の評判データベースはリアルタイムで更新され、燃焼された IP は数週間ブラックリストに滞在できます。

リクエスト率とパターン分析

人間は、完全に均一な間隔で毎秒50ページを要求しません。 反ボット システム トラックの要求頻度、タイミング パターンおよび運行の流れ。 要求間の同じ遅延で、paginated結果を介して完全にシーケンシャルパスに従うスクレイピング - レートが保守的であっても、機械的に見えます。

HTTP の指紋

すべてのHTTPクライアントは、送信するヘッダーの組み合わせに基づいて特徴的な指紋を持っています:ヘッダの順序、TLSハンドシェイク特性(JA3/JA4指紋)、HTTP / 2設定フレーム、ヘッダー値。 Pythonの requests ライブラリは、Chromeよりも完全に異なる指紋を持っています。 アンチボットシステムは、既知のブラウザの指紋のデータベースを維持し、一致しないものをフラグします。

ブラウザの指紋とJavaScriptの課題

高度なアンチボットシステムは、ブラウザ環境を調べるJavaScriptの課題に役立ちます: キャンバスレンダリング、WebGL機能、インストールされたフォント、画面解像度、タイムゾーン、言語の好み、および何百もの他の信号。 PuppeteerやPlaywrightなどのヘッドレスブラウザは、微妙な違いによって検出できます。ブラウザープラグインが欠落し、navigatorオブジェクトのプロパティディスクリプタが不適切であるか、または期待するレンダリング動作がない場合。

行動分析

マウスの動きを追跡し、パターンをスクロールし、動作をクリックします。 ホームページを最初に訪問することなく、データ重いページに直接移動するセッション、またはマウス、信号の自動化を決して動かさないセッション。

ブロックせずにスクレイプする戦略

1. IPの回転のための住宅のプロキシを使用して下さい

IP ベースのブロックに対する単一の最も効果的な防衛は、リクエストをルーティングする 住宅のプロキシ. 住宅IPは実質ISPに属し、通常の家庭用インターネット接続と同じ評判を運ぶ。 アンチボットシステムは、正当なユーザーに影響を与えることなく、住宅の範囲をブランケットブロックすることはできません。

有効なプロキシの回転は各要求に別のIPを割り当てるか、または要求の小さいバッチを意味します。 セッションに依存するスクレイピング(ログイン状態を維持したり、複数のページフローを操作する必要がある場合)には、回転する前に同じIPを一定期間保持するスティッキーセッションを使用します。

ProxyHat は、設定可能なセッション制御で自動回転を提供します。 IP をターゲットにすることができます。 特定の国、州、または都市 住宅レベルの信頼スコアを維持しながら、地理的に制限されたコンテンツにアクセスします。

2. 技術の現実的なHTTP ヘッダー

スクレイピングライブラリからのデフォルトヘッダーは、デッドプレゼントです。 Pythonのリクエストから requests ライブラリの送信 User-Agent: python-requests/2.31.0 — すぐに自動でフラグを立てる。 実際のブラウザに正確に一致するヘッダープロファイルを作成する:

• 流れを置く、完了して下さい User-Agent 実際のブラウザバージョンに合った文字列
• 含まれるもの Accept, Accept-Language, Accept-Encodingと Sec-CH-UA ヘッダー
• あなたが偽装しているブラウザにヘッダーの注文を一致させます
• 複数のブラウザプロファイル間で回転し、単一の指紋を避ける
• 申し込む Referer ヘッダ(検索エンジン結果ページなど)

3. スマートレート制限の実装

均一な遅延は、まったく遅れがないと疑わしいほどです。 実質的な分布に従うランダム化された遅延を実行します。

• リクエスト間の2-5秒のベース遅延
• プラスまたはマイナス30〜50%のランダムジッタを追加
• 20-50 リクエストごとに長い一時停止 (15-30 秒)
• ドメインごとの通貨を削減 — 2-3 並列リクエストの最大
• レートリミット信号(429ステータスコード)を受信したときに指数関数のバックオフを実行

4. セッションとクッキーを適切に管理

多くのウェブサイトは、最初の訪問で追跡クッキーを割り当て、その後の要求にそれらを期待します。 クッキーを送らないスクレーパー、またはすべての要求に新鮮なクッキーを送信し、異常な検出をトリガーします。 セッションごとにクッキージャーを維持し、論理的な閲覧セッション内でリクエスト全体にクッキーを運ぶ。

5. JavaScript レンダリングコンテンツの処理

JavaScript の実行を必要とするサイトでは、Playwright または Puppeteer を使用して、実際のブラウザエンジンを使用します。 しかし、予防接種のないヘッドレスブラウザは簡単に検出されます。 主要な堅くなるステップは下記のものを含んでいます:

• 使用条件 playwright-extra または puppeteer-extra ステルスプラグイン
• 実質的なビューポートサイズを設定します(デフォルト800x600ではありません)
• WebGLを有効にし、一貫性のあるGPUレンダラー文字列を注入
• プロキシの地理的位置に合わせてタイムゾーンとロケールを設定
• ランダムマウスの動きを追加し、データを抽出する前にアクションをスクロール

6. Robots.txt を見直し、バックオフを実施

Robots.txt は、すべての管轄区域で合法的に結合されていないが、それを尊重して良い信仰を示す。 より実用的に, あなたが無視するのを見るサイト robots.txt 積極的なブロックを実行する可能性が高い. 429(Too Many Requests)または503(Service Unavailable)応答を受信したときに、常に自動バックオフを実行します。これらは、低速の信号です。

コード例: ProxyHat 住宅プロキシでスクレイピング

次の例では、住宅用プロキシの回転を現実的なヘッダーで設定する方法を示します。 各例では、それぞれの言語で ProxyHat SDK を使用します。 完全のため API ドキュメントProxyHat の doc を参照してください。

Python の例

SDKをインストールします。 pip install proxyhat ( )GitHubで)

import time
import random
from proxyhat import ProxyHatClient
client = ProxyHatClient(
    api_key="your_api_key",
    country="US",
    session_type="rotating",  # New IP per request
)
headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36",
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8",
    "Accept-Language": "en-US,en;q=0.9",
    "Accept-Encoding": "gzip, deflate, br",
    "Sec-CH-UA": '"Chromium";v="131", "Not_A Brand";v="24"',
    "Sec-CH-UA-Mobile": "?0",
    "Sec-CH-UA-Platform": '"Windows"',
}
urls = [
    "https://example.com/page/1",
    "https://example.com/page/2",
    "https://example.com/page/3",
]
for url in urls:
    response = client.get(url, headers=headers)
    print(f"{response.status_code} - {url} via {response.proxy_ip}")
    # Randomized delay: 2-5 seconds with jitter
    delay = random.uniform(2.0, 5.0)
    time.sleep(delay)

Node.js 例

SDKをインストールします。 npm install @proxyhat/sdk ( )GitHubで)

const { ProxyHatClient } = require("@proxyhat/sdk");
const client = new ProxyHatClient({
  apiKey: "your_api_key",
  country: "US",
  sessionType: "rotating",
});
const headers = {
  "User-Agent":
    "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36",
  Accept:
    "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8",
  "Accept-Language": "en-US,en;q=0.9",
};
const urls = [
  "https://example.com/page/1",
  "https://example.com/page/2",
  "https://example.com/page/3",
];
async function scrape() {
  for (const url of urls) {
    const response = await client.get(url, { headers });
    console.log(`${response.status} - ${url} via ${response.proxyIp}`);
    // Randomized delay between requests
    const delay = 2000 + Math.random() * 3000;
    await new Promise((r) => setTimeout(r, delay));
  }
}
scrape();

導入事例

SDKをインストールします。 go get github.com/ProxyHatCom/go-sdk ( )GitHubで)

package main
import (
    "fmt"
    "math/rand"
    "time"
    proxyhat "github.com/ProxyHatCom/go-sdk"
)
func main() {
    client := proxyhat.NewClient(&proxyhat.Config{
        APIKey:      "your_api_key",
        Country:     "US",
        SessionType: proxyhat.Rotating,
    })
    headers := map[string]string{
        "User-Agent":      "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36",
        "Accept":          "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
        "Accept-Language": "en-US,en;q=0.9",
    }
    urls := []string{
        "https://example.com/page/1",
        "https://example.com/page/2",
        "https://example.com/page/3",
    }
    for _, url := range urls {
        resp, err := client.Get(url, proxyhat.WithHeaders(headers))
        if err != nil {
            fmt.Printf("Error: %v\n", err)
            continue
        }
        fmt.Printf("%d - %s via %s\n", resp.StatusCode, url, resp.ProxyIP)
        // Randomized delay: 2-5 seconds
        delay := time.Duration(2000+rand.Intn(3000)) * time.Millisecond
        time.Sleep(delay)
    }
}

マルチページフローの粘着セッション

いくつかのスクレイピングタスクは、複数のリクエスト間で同じIPアドレスを維持する必要があります。例えば、ペジネーションされた製品リストをナビゲートし、ログインセッションを維持したり、マルチステップフォームをコンパイルしたりします。 ProxyHat は、同一の住宅 IP を構成可能期間保持するスティッキーセッションをサポートしています。

# Python: Sticky session example
from proxyhat import ProxyHatClient
client = ProxyHatClient(
    api_key="your_api_key",
    country="DE",
    session_type="sticky",
    session_ttl=300,  # Same IP for 5 minutes
)
# All requests within the session use the same IP
response1 = client.get("https://example.com/login", headers=headers)
response2 = client.post("https://example.com/login", data=credentials, headers=headers)
response3 = client.get("https://example.com/dashboard", headers=headers)
print(f"Session IP: {response1.proxy_ip}")  # Same IP for all three requests

トリガーブロックの一般的な間違い

経験豊富な開発者もこれらのエラーを犯します。 それぞれがプロキシの帯域幅を通して焼くことができ、IPs は必須ではありません。

• デフォルトライブラリヘッダーを使用する ・・・ python-requests ユーザエージェントの文字列は、すべてのブロックリストにあります。 常にカスタムヘッダーを設定します。
• TLS指紋を無視する — あなたのヘッダは「クローム」と言うかもしれませんが、TLSハンドシェイクは「Python」と言います。 ライブラリを使う curl_cffi または tls-client 実際のブラウザTLS指紋を偽装する。
• 初期起動時にスクレイピングも高速 — 遅くなる。 リクエスト率を時間を超えて徐々に上昇させ、分かっていません。
• エラーをうまく処理しない — ブロックされたリクエストを同じ構成廃棄物の帯域幅ですぐに再試行し、ボットであることを確認します。 バックオフを実行し、プロキシセッションをエラーに切り替えます。
• 燃焼IPの再利用 — リクエストが CAPTCHA またはブロックページを返すと、そのターゲットに対して IP が侵害されます。 すぐに新しいセッションへ。
• 地理的一貫性を無視する — US IP からリクエストを送信する Accept-Language: ja +9のタイムゾーンオフセットが疑わしいように見えます。 ヘッダーとブラウザの設定をプロキシに合わせる アクセス. .
• 成功率を監視しない — ブロックレートを追跡しなくても、戦略が機能しているかどうかは分かりません。 応答の状態をログにし、成功率の低下に警告します。

高付加価値ターゲットのための高度な技術

指紋の任意化

厳重に保護されたサイトのために、IPだけでなく、ブラウザの指紋プロファイル全体を回転させます。 各セッションには、ユーザーエージェント、画面解像度、タイムゾーン、言語、プラットフォームの一貫した組み合わせが必要です。これらは現実的な組み合わせと一致する必要があります。 Linuxプラットフォームの文字列を持つWindowsユーザーエージェントは、明らかな赤いフラグです。

要求チェーンシミュレーション

実際のユーザーは製品ページに直接ジャンプしません。 検索エンジンから到着し、カテゴリページを参照し、内部リンクに従ってください。 スクレーパーを構築して、現実的なナビゲーションパスをシミュレートします。ホームページをロードし、カテゴリページへのリンクに従い、ターゲットデータにアクセスします。 信じられないほどのセッションパターンを生成します。

SERPスクレイピング検討

検索エンジンスクレイピングは、Google、Bingなどの攻撃的なボット検出を持っているので、ユニークな課題を持っています。 住宅用プロキシは、信頼性の高いため不可欠です SERPトラッキング、複数の地理的な場所を渡ってリクエストを配布し、任意の領域からレート制限をトリガーすることを避ける必要があります。

適切なプロキシタイプを選択する

すべてのスクラップの仕事は住宅のプロキシを必要としません。 適切な選択肢は、ターゲットの防衛と予算によって異なります。 お問い合わせ プロキシタイプの詳細な比較 ディープダイビングに。 ここでは迅速な決定行列です。

ほとんどのスクレイピングプロジェクトのために、住宅の回転プロキシは、信頼性と費用対効果の高い最高の組み合わせを提供します。 ProxyHat 価格 帯域幅の消費に基づいているので、成功したデータ転送だけを支払うだけです。

キーテイクアウト

• 住宅のプロキシは基礎です — データセンターIPは、最も保護されたサイト上ですぐにブロックされます。 住宅用IPは、自然な信頼を運ぶ。
• ヘッダーはIPと同じくらい重要 — デフォルトの Python ヘッダを持つ住宅IPはブロックされます。 完全な、現実的なヘッダーのプロフィールを作成して下さい。
• すべてをランダム化 — 遅延、ヘッダの組み合わせ、ナビゲーションパス。 予測可能なパターンは検出可能なパターンです。
• モニターと適応 — 成功率を追跡します。 ブロックが増加したら、プロキシプールを通して燃焼する前に調査し、調整します。
• 指紋の一致 — すべての信号は、ユーザーエージェント、TLS 指紋、タイムゾーン、言語、地理的な位置が整列する必要があります。
• 遅くなり、徐々にスケールアップ — 保守的なレート制限から始まり、セットアップ作業を確実に確認した後にのみ増加します。
• ステートフルフローのスティッキーセッションを使用する — ログインシーケンスとマルチページナビゲーションはIPの一貫性を必要とします。 適切なTTLで粘りのあるセッションを使用してください。

よくある質問

スクレーパーがブロックされているかどうかを知る方法は?

一般的な兆候は、HTTP 403 または 429 のステータスコードを受信し、CAPTCHA ページにリダイレクトされ、HTML コンテンツを期待したり、通常のブラウザーで表示される内容よりも異なるコンテンツを受信したりする空の応答体を取得します。 応答ステータスコードとコンテンツの長さを監視します。平均応答サイズの急激な低下は、サイトが実際のコンテンツの代わりにチャレンジページを返すソフトブロックを示しています。

すべてのブロックを避けるために十分な住宅のプロキシはありますか?

住宅用プロキシは、最も一般的な検出方法であるIPベースのブロックを排除しますが、独自のソリューションではありません。 実際のヘッダー、適切なレート制限、セッション管理が必要です。 基礎としての住宅のプロキシを考える - 彼らは最も困難な問題(IPの評判)を解決しますが、あなたのスクレイピングスタックの他の層も固体でなければなりません。 最も保護された場所のために、住宅のプロキシをブラウザの指紋の偽装とのような用具を使用して結合して下さい curl_cffi またはステルス構成されたPlaywright。

1秒あたりのリクエスト数がブロックされずに送信できますか?

ターゲットのウェブサイトの防衛に依存しているため、普遍的な答えはありません。 保守的な開始点として、IPを回転させるドメインごとに1〜2秒ごとに1リクエストに制限します。 保護されていないサイトでは、5-10同時リクエストに徐々に増加させることができます。 Google や Amazon などの保護されたサイトでは、住宅のプロキシとも 3 秒あたりの 1 件のリクエストを 1 回滞在できます。 常に徐々にランプアップし、成功率を監視しましょう。95%以下にドロップすると、あまりにも高速になります。

回転と粘りのあるプロキシセッションの違いは何ですか?

セッションを回転させると、新しいIPアドレスを各リクエストに割り当て、独立したページをスクレイピングするのに最適です。 スティッキーセッションは、設定された期間(典型的に1-30分)と同じIPを維持します。これは、ログインフロー、ペジネーションナビゲーション、またはサーバーがIPを追跡する任意のマルチステッププロセスに必要なものです。 デフォルトで回転セッションを使用して、使用例がセッションの継続を必要とする場合にのみ、スティッキーに切り替えます。

Webスクレイピングは合法ですか?

Webスクレイピング法は、管轄区域、収集されるデータの種類、および使用方法により異なります。 米国では、2022 hiQ Labs v.リンク ルーリングでは、公に利用可能なデータをスクレイピングすることは、コンピュータ詐欺と虐待法に違反しないことを確立しました。 EUでは、GDPRは収集方法に関係なく個人データに適用されます。 一般ルールとして:公に利用できるスクレイピング、正当な事業目的のために非個人データが広く受け入れられます。 ウェブサイトの利用規約を常に確認し、robots.txtを礼儀として尊重し、特定のユースケースに法的相談してください。