コンテンツにスキップ

403 禁止: Web スクレイパーの悩み (そしてそれを回避する方法)

Web サイトからデータを収集しようとしたことがあるなら、ほぼ確実に、ある時点で恐ろしい「403 Forbidden」エラーに遭遇したことがあるはずです。この HTTP ステータス コードは、サーバーがリクエストを理解したが、そのリクエストを満たすことを拒否していることを示します。つまり、要求したリソースにアクセスする権限がありません。

Web スクレイパーにとって、403 エラーは常に頭痛の種です。 Web サイトはこれらを使用して、ページへの不正アクセスを防止し、人間のユーザーではなくボットやスクレイパーから送信されたと思われるトラフィックをブロックします。 403 応答を受け取ると、Web スクレイピング プロジェクトが金切り声を上げて停止する可能性があります。

でも絶望しないでください! 403 エラーはイライラすることもありますが、克服できないわけではありません。適切なテクニックを使用すれば、403 のトリガーを回避し、Web スクレイパーをスムーズに実行し続けることができます。このガイドでは、403 エラーの原因を詳しく説明し、それを防ぐ戦略を探ります。始めましょう!

Web スクレイパーで 403 エラーが発生する理由

Web スクレイパーが Web サイトから 403 Forbidden 応答を受け取る主な理由はいくつかあります。

  1. 制限付きリソースのリクエスト: 一部のページは、権限のないユーザーが立ち入り禁止になっているだけです。たとえば、有効なセッションがない場合、ユーザー ダッシュボードなどのログインが必要なページにアクセスしようとすると、多くの場合 403 エラーが発生します。

  2. 認証がありません: 多くの Web サイトでは、特定のページにアクセスするために、ユーザー名とパスワードでのログインなど、何らかの形式の認証が必要です。 Web スクレイパーが必要な認証資格情報を提供しない場合、403 応答が返される可能性があります。

  3. ボットの検出: Web サイトでは、ボットやスクレイパーから送信されたと思われるトラフィックを検出してブロックするために、さまざまな技術が採用されていることがよくあります。 Web スクレイパーが人間のユーザーではなく自動ツールであるとサイトが判断した場合、403 エラーが返される可能性があります。

  4. アンチボットシステム:一部の Web サイトでは、スクレイピングやその他の自動化された脅威から保護するために、Cloudflare、Imperva、PerimeterX などの専用のボット対策ソリューションを使用しています。これらのシステムはトラフィック パターンを分析し、疑わしいと思われるリクエストをブロックし、多くの場合 403 エラーを返します。

Web サイトを正常にスクレイピングするには、これらの問題を回避し、Web スクレイパーが正規の許可されたユーザーであることをサイトに納得させる方法が必要です。幸いなことに、私たちが取れるアプローチはいくつかあります。最も効果的な戦術をいくつか見てみましょう。

認証の提供

Web サイトでスクレイピングするコンテンツにアクセスするためにログインが必要な場合は、Web スクレイピング プロセスに認証を含める必要があります。これには通常、次の 2 つの手順が必要です。

  1. ログインプロセスの検査: ブラウザの開発者ツールを使用して、サイトに手動でログインするときのネットワーク トラフィックを観察します。ログイン認証情報を送信するリクエストを探し、URL、リクエスト メソッド、ヘッダー、およびリクエスト本文をメモします。このリクエストを Web スクレイパーで複製する必要があります。

  2. プログラムによるログイン: Python の Requests や Node.js の Axios などのライブラリを使用して、観察したものを模倣したログイン リクエストを送信します。サイトから返される Cookie をキャプチャします。これらの Cookie には後続のリクエストの認証に必要なセッション トークンが含まれることがよくあります。有効なログイン セッションを維持するには、Web スクレイピング リクエストのヘッダーにこれらの Cookie を含めます。

以下は、Python とリクエストを使用してプログラムでサイトにログインする例です。

import requests

# Start a new session
session = requests.Session() 

# Send a POST request to the login URL with the necessary credentials
login_data = {
    ‘username‘: ‘my_username‘,
    ‘password‘: ‘my_password‘,
}
response = session.post(‘https://example.com/login‘, data=login_data)

# The session now contains the cookies needed to authenticate future requests
response = session.get(‘https://example.com/restricted_page‘)

Web スクレイパーを認証し、必要な Cookie とヘッダーをリクエストに含めることで、アクセス許可の不足によって発生する 403 エラーを回避できます。

ステルステクニック

もちろん、ログインするだけでは十分ではありません。 Web サイトは、Web スクレイパーとの絶え間ないいたちごっこを繰り返し、ボットと人間のユーザーを区別するシグナルを探しています。ブロックされないようにするには、Web スクレイパーは人間の動作をできるだけ模倣して溶け込む必要があります。

重要なステルス技術には次のようなものがあります。

  • ユーザーエージェントのローテーション: ユーザー エージェントは、リクエストを行っているクライアントを識別する文字列です。すべてのリクエストに同じユーザー エージェントを使用すると、トラフィックがボットから送信されていることが明らかになります。代わりに、ユーザー エージェント文字列のプールを維持し、リクエストごとに異なる文字列をランダムに選択します。

  • IP アドレスのローテーション: 単一の IP アドレスから大量のリクエストを送信することも、ボット検出システムにとって危険信号です。プロキシ サービスを使用して、さまざまな IP アドレスを通じてリクエストをルーティングします。最良の結果を得るには、住宅用 IP の大規模なプールを提供するプロバイダーを選択してください。

  • リクエストパターンのランダム化: 人間は完全に規則的な方法で Web サイトを閲覧するわけではありません。一時停止したり、ページが不規則に変更されたり、リクエスト間の時間が異なります。 Web スクレイピング リクエスト間にランダムな遅延を導入し、完全に予測可能なパターンでサイトをクロールすることを回避します。

  • CAPTCHA の処理: 一部の Web サイトでは、ボットの活動が疑われる場合に CAPTCHA を表示します。 CAPTCHA は、Web スクレイパーにとって自動的に解決するのが難しい場合があります。頻繁にそれらに遭遇する場合は、スクレイパーに代わって人間の作業者を利用して課題を解決する CAPTCHA 解決サービスを使用する必要がある場合があります。

以下は、ランダムなユーザー エージェントと遅延を使用した、Python でのよりステルスなリクエストの例です。

import requests
import random
import time

# List of user agent strings
user_agents = [    
    ‘Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36‘,
    ‘Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36‘,
    ‘Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.157 Safari/537.36‘,  
]

# Randomize user agent 
headers = {‘User-Agent‘: random.choice(user_agents)}

# Introduce a random delay of 1-5 seconds
time.sleep(random.randint(1, 5))

# Send the request
response = requests.get(‘https://example.com‘, headers=headers)

Web スクレイパーのトラフィックをできるだけ「人間的」に見せるための措置を講じることで、403 エラーやその他の障害に遭遇するリスクを大幅に減らすことができます。

検出不可能な自動化

可能な限り最も密かに Web スクレイピングを行うには、Puppeteer や Playwright などの完全なブラウザ自動化ツールを使用するとよいでしょう。これらのツールは実際のブラウザ (Chrome または Firefox) をプログラムで実行し、実際の人間のユーザーと区別するのが非常に難しい方法で Web サイトを操作できるようにします。

ブラウザ自動化ツールは、最大限のステルスを実現するように構成できます。たとえば、JavaScript フィンガープリント コードをブロックしたり、Navigator オブジェクト内のオートメーションの明らかな兆候をマスクしたり、ビューポートの寸法をランダム化するように設定できます。実際のブラウザを制御することで、Cookie、ヘッダー、リダイレクト、および基本的な Web スクレイピング ライブラリでは管理できない HTTP のその他の側面を自動的に処理することもできます。

ブラウザ自動化の欠点は、Requests や Axios などのライブラリを使用して単純な HTTP リクエストを送信するよりもリソースを大量に消費し、時間がかかることです。ただし、スクレイパーのブロックに特に積極的なサイトの場合は、パフォーマンスを犠牲にする価値があるかもしれません。

以下は、Node.js で Puppeteer を使用してヘッドレス Chrome のページにアクセスする基本的な例です。

const puppeteer = require(‘puppeteer‘);

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();

  // Configure the browser for stealth (omitted for brevity)

  await page.goto(‘https://example.com‘);

  // Scrape data from the page...

  await browser.close();
})();

いくつかの追加構成を使用すると、Puppeteer などのツールを使用して、検出を回避しながらスクレイピングを自動化する強力な方法になります。

まとめ

403 エラーの発生は Web スクレイピングでは避けられない部分ですが、適切なアプローチを使えば、プロジェクトを頓挫させる必要はありません。 403 が発生する理由を理解し、認証、ステルス技術、検出不可能な自動化を通じて、XNUMX のトリガーを回避するための措置を講じることで、Web スクレイパーをスムーズに実行し続けることができます。

最も効果的なアプローチは、対象とする特定の Web サイトによって異なります。 403 を回避するために単純なリクエスト ヘッダーのみが必要な場合もあれば、ブラウザーの完全な自動化セットアップが必要な場合もあります。重要なのは、基本的なテクニックから始めて、遭遇する障害物に応じて、必要に応じてより洗練されたステルス層を追加することです。

403 やその他のスクレイピング対策の回避という進化し続ける課題に困難を感じる場合は、独自のスクレイピング インフラストラクチャを構築して維持するのではなく、既製の Web スクレイピング API の利用を検討することをお勧めします。 ScrapingBee や ScraperAPI などのサービスは、開発時間を大幅に節約できる組み込みの 403 回避機能を備えた、実績のあるスクレイパーを提供します。

独自の Web スクレイパーを使用する場合でも、事前に構築されたソリューションを使用する場合でも、重要なことは、403 エラーによって必要なデータの取得が妨げられないようにすることです。少しの粘り強さとキット内の適切なツールがあれば、ボット対策に直面しても Web スクレイパーを実行し続けることができます。ハッピースクレイピング!

参加する

あなたのメールアドレスは公開されません。 必須フィールドは、マークされています *