日々のオンラインデータ管理やWebスクレイピングにおいて、誤ったプロキシメッセージが表示されることは非常に一般的です。これらのエラーコードは、プロキシのデータ配信上の問題を特定するための指標となり、問題の診断と解決に重要な役割を果たします。
この記事では、あらゆる HTTP プロキシエラーコードの概要と、各エラーの種類や解釈、ならびに発生しやすい条件について説明します。
プロキシエラーコード
プロキシエラーは、サーバーのダウンタイムや設定上の不一致など、さまざまな原因により発生します。原因の詳細を理解することにより、問題点が把握しやすくなり、エラーの修正が簡素化されます。
次のセクションでは、さまざまなプロキシコードと、これらを効果的にトラブルシューティングし、解決する方法について学ぶことができます。
3xx コード：リダイレクト
HTTP 3xx ステータスコードはリダイレクトのために使用され、ユーザーエージェントがリクエストを完了するために追加の手順を実行する必要があることを表します。このコードは通常、編集上の変更やWebサイトの再構築により、ユーザーが新しいURLにリダイレクトされることを意味します。
Webスクレイピングを行う際は、正確で効果的なデータ収集を維持するために、これらのリダイレクトに対処する必要があります。
301: Moved Permanently（恒久的な移動）
301 エラーの発生は、探しているリソースが恒久的に移動したことを意味します。このコードは、一般的にコンテンツの再設計や再編成など、Webサイトにて何らかの更新が行われている際に表示されます。
このエラーが発生した場合、スクレイパーは、レスポンスヘッダーから取得した新しい場所に参照URLを転送する必要があります。
response_data = requests.get('http://example.com/old-page')
if response_data.status_code == 301:
new_redirect_url = response_data.headers['Location']
response_data = requests.get(new_redirect_url)
このコードでは、ヘッダーからリダイレクト先を取得するようスクレイパーに指示することができます。これにより、スクレイパーが新しい場所にあるコンテンツにアクセスすることが可能となります。
302: Found (Temporary Redirect)（特定済み／一時的なリダイレクト）
302 Found ステータスコードは、アクセスしようとしているリソースが一時的に別の URL に移動していることを表します。この場合、恒久的な変更ではないため、元の URL がいずれ再び使用可能になることが予測されます。このコードは、一般的にWebサイトにてメンテナンスが行われている際に表示されます。
Webスクレイピングを行う際は、保存されている URL を変更せず、リダイレクトが自動的に処理されるようにスクリプトの構成を行うことが重要です。また、 PythonのRequestsなど多くの HTTP ライブラリは 302 のリダイレクトを自動的に処理しますが、この動作がスクレイピング上の目標と一致していることを確認する（特に元のリクエストメソッドを維持する必要がある場合など）ことが重要です。
304: Not Modified（未更新）
アクセスしようとしているコンテンツが、前回の検証済みリクエストより後に更新されていない場合には、 304 エラーが表示されます。このエラーは不要なデータのダウンロードを防ぎ、Web スクレイピングアクティビティの効率を向上させます。
スクレイパーが既にダウンロードされているページにアクセスした場合、 If-Modified-Since や If-None-Matchなどのリクエストヘッダーを使用することで、コンテンツが変更されていないことを確認できます。
import requests
# Correct header format and Python syntax
headers = {'If-Modified-Since': 'Sat, Oct 29 2024 19:43:31 GMT'}
# Making a GET request to the server with the headers
response = requests.get('http://example.com/page', headers=headers)
# Checking if the status code returned is 304
if response.status_code == 304:
print("Content has not changed.")
このコードでの作業は、レスポンスコードが 304であるかどうかをテストすることから始まります。コードが304であることが確認されると、 「コンテンツは変更されていません」というメッセージが出力され、何もする必要はありません。
307: Temporary Redirect（一時的なリダイレクト）
一時的なリダイレクトを意味するステータスコード 307は、アクセスしようとしているリソースが一時的に別の URL に配置されていることを表します。この場合、元のリクエストと同じ HTTP メソッドおよびボディをリダイレクトされた URL で再度使用することができます。この点において、リダイレクトされた URL における他のメソッドやボディの使用を可能とする 302とは異なります。
response = requests.post('http://examples.com/submit-form', data={'key': 'value'} )
if response.status_code == 307:
response = requests.post(response.headers['Location'], data={'key': 'value'})
Web クローラーをリダイレクトする際は、順序を維持する必要があります。これにより、対象 Webサイトの構造とサーバーシステムを尊重しながら、効果的でかつ信頼性の高いデータ収集を行うことが可能となります。次のコードにより、レスポンスステータスが 307であるかどうかが確認されます。ステータスが307である場合は、ボディ内の同じデータがレスポンスヘッダーで指定された新しい 場所 に再送信されます。
4xx コード：クライアント側のエラー
クライアント側のエラーは、4xx の HTTP ステータスコードとして表示され、通常はクライアントによるリクエストが問題の原因となります。多くの場合、これらの解決にはリクエストパラメータの修正や、認証メカニズムの運用強化が必要となります。
400: Bad Request（不正なリクエスト）
400 Bad Request エラーは、サーバーがリクエストを理解しなかったことを表します。Web スクレイピングにおいて、一般的にこのようなエラーは書き込まれたリクエストヘッダーが正しくなかったり、部分的な欠落を伴っていたりする場合に発生します。
例として、誤って間違った形式で情報を送信した場合（ JSON の代わりにテキストを送信した場合など）、サーバーはリクエストを処理せずに拒否します。この問題を解決するには、慎重な検証を行い、リクエスト構文がサーバーによる条件を満たしていることを確認する必要があります。
Web スクレイピングにおいて、リクエストがサーバーの条件を満たしていることを確認するためには、いくつかの手順を実行する必要があります。まず、対象となるWebサイトの構造が理解できているかを確認する必要があります。ブラウザの開発者ツールを使用することにより、要素の検証を行ったり、データがどのようにフォーマットされているかを調べたりすることができます。また、テストおよびエラー処理の実装を行い、リクエストに適切なヘッダーが使用されていることを確認する必要があります。
401: Unauthorized（権限がありません）
401 Unauthorized エラーは、リソースへのアクセスに必要な認証がないか、認証が失敗したことを表します。Web スクレイピングにおいては、一般的に認証されたコンテンツにアクセスしようとした際に発生します。例として、間違った認証情報を使用してサブスクリプションベースのデータにアクセスしようとすると、このエラーが発生します。これを防ぐには、リクエスト時に必ず正しい認証ヘッダーを入力する必要があります。
403: Forbidden（閲覧禁止）
403 Forbidden エラーは、サーバーがリクエストを理解したものの、ユーザーによるリソースへのアクセスを拒否したことを意味します。一般的に、厳重なアクセス制御が行われている Webサイトをスクレイピングしようとした際に発生します。多くの場合、Web サイトの禁止部分を閲覧しようとするとこのエラーが表示されます。例として、ユーザー認証が行われた状態で別のユーザーの投稿にアクセスしようとした場合、権限がないと判断されアクセスが拒否されます。
403 エラーが表示された場合、キーまたは資格情報を確認し、認証の検証を行う必要があります。認証ができず、有効な資格情報がない場合、Web サイトのアクセスポリシーに準拠し、コンテンツのスクレイピングを中止することをお勧めします。
404: Not Found（ページが見つかりません）
リクエストされているリソースが見つからない場合、サーバーは 404 Not Found エラーを返します。
一般的に、Web スクレイピングで使用される URL が変更されたり、破損したりしている場合（例として商品ページが削除された場合や、URLのリダイレクトや更新が行われずに変更された場合など）に発生します。
この問題を解決するには、スクレイピングスクリプト内の URL を確認し、必要な場合、現在の Web サイト構造に合わせて更新する必要があります。
コード内の 404 エラーは、常に処理することが推奨されています。
Python を使用していて、サーバーによりリソースが特定されなかった場合、このエラーによりコードが停止するのを防ぐため、次のコードブロックを渡すようコードに指示することができます。
import requests
# List of URLs to fetch
urls = [
"http://example.com/nonexistentpage.html", # This should result in 404
"http://example.com" # This should succeed
]
for url in urls:
try:
response = requests.get(url)
if response.status_code == 404:
print(f"Error 404: URL not found: {url}")
# Continue to the next URL in the list
continue
print(f"Successfully retrieved data from {url}")
print(response.text[:200]) # Print the first 200 characters of the response content
except requests.exceptions.RequestException as e:
print(f"An error occurred while fetching {url}: {e}")
continue # Continue to the next URL even if a request exception occurs
print("Finished processing all URLs.")
次のコードにより、URL の配列を反復処理し、ページコンテンツの取得を試みます。 400のエラー発生により失敗した場合、コードは配列内の次の URL へと進みます。
407: Proxy Authentication Required（プロキシ認証が必要です）
407 Proxy Authentication Required エラーは、リクエスト続行のため、プロキシサーバーによるクライアントの認証が必要となった際にトリガーされます。一般的に、Webスクレイピング中にプロキシサーバーの認証が必要となった際に発生するエラーです。これは、対象 Webサイトの関連データへのアクセス認証が必要となって発生する、 401 エラーとは異なります。
例として、プライベートプロキシを使用しながら対象 Webサイトのデータアクセスを試みた際にこのエラーが発生した場合、これはユーザーが認証されていないことを意味します。この問題を解決するには、リクエスト時に有効なプロキシ認証情報を入力する必要があります。
408: Request Timeout（リクエストのタイムアウト）
408 Request Timeout ステータスコードは、サーバーのリクエスト待機時間が長すぎたことを表します。このエラーは、スクレイパーの動作が遅すぎる場合や、ピーク時など、サーバーが過負荷状態になった場合に発生します。
リクエストのタイミングが最適化され、指数バックオフメカニズムを使用した再試行が実装されると、サーバー応答に十分な時間が確保されるため、問題の発生を最小限に抑えることができます。
429: Too Many Requests（リクエストが多すぎます）
429 Too Many Requests エラーは、ユーザーが短期間に大量のリクエストを送信した場合に発生します。一般的に、一つのWebサイトにおけるWebスクレイピングのレート制限を超過した場合に発生します。例として、Webサイトへのクエリを頻繁に実行すると、レート制限が有効になり、データのスクレイピングがブロックされます。
対象となるWebサイトの API レート制限を尊重し、リクエスト遅延などの スクレイピングのベストプラクティスを適用することにより、この問題の発生を防ぎ、必要なリソースへのアクセスを維持することができます。
5xx コード：サーバー側の問題
サーバー側の問題は、5xx シリーズの HTTP ステータスコードとして表示されます。これは、内部の問題によりサーバーがリクエストを処理できないことを意味します。多くの場合、Web スクレイピングにおけるこのようなエラーは、クライアント側のエラー処理とは異なるアプローチを必要とするため、エラー内容を十分に理解することが重要となります。
500: Internal Server Error（内部サーバーエラー）
500 Internal Server Error は、サーバー上で何らかの異常事態が発生し、特定のリクエストを完了できなかったことを通知するための一般的なレスポンスです。このエラーはクライアント側のミスにより発生するものではなく、サーバー自体に問題があることを示すものです。
データのスクレイピング時における例として、サーバー上のページにアクセスしようとした場合にこのエラーが発生することがあります。この問題を解決するには、のちに再度試すか、ピーク時など、サーバーが過負荷状態になっている時間帯以外でWeb スクレイピングプロジェクトの実行を計画する必要があります。
501: Not Implemented（実装されていません）
501 Not Implemented エラーは、サーバーがリクエストメソッドの認識、または完了に失敗した場合に発生します。通常、クローラーのメソッドが事前にテストされるため、Webスクレイピングにおけるこのようなエラーの発生は稀ですが、一般的でない HTTP メソッドを使用した場合に発生することがあります。
例として、スクレイパーがサーバーでサポートされていないメソッド（ PUTやDELETEなど）を使用するように設定が行われていて、これらのメソッドがWeb スクレイピングの機能のために必要である場合、 501 エラーが発生します。スクレイピングスクリプトが HTTP メソッドを使用する場合、これらのメソッドがすべての場所にて必要であることを確認することにより、エラーを防ぐことができます。
502: Bad Gateway（不正なゲートウェイ）
502 Bad Gateway エラーは、サーバーがゲートウェイまたはプロキシとして機能しているにもかかわらず、接続先のサーバーから不適切なレスポンスを受け取ったため、リクエスト処理のためにアクセスされたことを表します。これは、中間サーバーとの通信に問題が発生したことを意味します。
Web スクレイピング中、使用しているプロキシサーバーがターゲットサーバーから適切なレスポンスを取得できない場合、 502 エラーが発生することがあります。この問題を解決するには、プロキシサーバーの状態が正常であり、構成が機能していてターゲットサーバーと通信できることを確認する必要があります。プロキシサーバーの CPUやメモリ、そしてネットワーク帯域幅の使用状況をモニタリングすることをお勧めします。また、プロキシサーバーのエラーログを確認し、リクエストの処理時に問題が発生しているかどうかを確認することもできます。
503: Service Unavailable（サービスが利用できません）
503 Service Invailable エラーは、サーバーがビジー状態であるため、リクエストを処理できないことを表します。これは、サーバーのメンテナンスまたは過負荷が原因である可能性が考えられます。
Web スクレイピング時に、メンテナンス中やピーク時であるためにアクセスが不可能なサイトへのアクセスを試みると、このエラーが発生することが多々あります。サーバーの問題を示す 500 エラーとは異なり、 503 エラーは、サーバーが稼働してはいるものの、現時点では利用できないことを意味します。
このエラーを回避するには、 指数バックオフを使用した再試行戦略を実装する必要があります。リクエストの再試行が行われるにつれ、バックオフ間隔が長くなります。このため、リクエストによりダウンタイム中にサーバーが飽和状態になることが回避されます。
504: Gateway Timeout（ゲートウェイタイムアウト）
504 Gateway Timeout エラーは、ゲートウェイまたはプロキシとして機能しているサーバーが、アップストリームサーバーからのレスポンスを時間内に取得できなかった際に発生します。これはタイムアウトが原因の問題であり、 502 と同種類のエラーです。
Web スクレイピングにおいて、このエラーは一般的にターゲットサーバーからプロキシへのレスポンスが遅すぎた場合（ 120 秒を超えた場合）に発生します。この問題を解決するには、より長い待機時間に対応するようスクレイパーのタイムアウト設定の微調整を行うか、プロキシサーバーの健全性や応答性を検証する必要があります。
505: HTTP Version Not Supported（HTTP バージョンがサポートされていません）
505 HTTP Version Not Supported エラーは、リクエストで指定された HTTP プロトコルバージョンをサーバーが認識しない場合に発生します。Webスクレイピングにおいては稀ですが、ターゲットサーバーの設定で、特定のバージョンのHTTPプロトコルのみがサポートされている場合に発生することがあります。例として、新しすぎる、または古すぎるバージョンでスクレイピングリクエストが送信された場合、サーバーはこれを拒否します。
このエラーの回避には、HTTP リクエストヘッダーにターゲットサーバーで受け入れられるバージョン（最も広くサポートされている HTTP/1.1、または HTTP/2 など）が入力されていることを確認する必要があります。
一般的なプロキシエラーを回避するためのクイックヒント
プロキシエラーは苛立たしいものですが、特定の戦略をいくつかWeb スクレイパーに実装することで、多くのプロキシエラーは回避することができます。
リクエストの再試行を行う
プロキシ関連の問題の多くは、短時間のネットワーク中断や小規模なサーバー障害など、短期的な問題が原因となります。問題が自然に解決した場合、リクエストを再試行することで問題を回避できる可能性があります。
次の方法により、Pythonの Requests ライブラリと urllib3 再試行ロジックを使用し、スクレイピングスクリプトに再試行を実装することができます。
import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
def requests_retry_session(
retries=3,
backoff_factor=0.3,
status_forcelist=(500, 502, 503, 504),
session=None,
):
session = session or requests.Session()
retry = Retry(
total=retries,
read=retries,
connect=retries,
backoff_factor=backoff_factor,
status_forcelist=status_forcelist,
)
adapter = HTTPAdapter(max_retries=retry)
session.mount('http://', adapter)
session.mount('https://', adapter)
return session
s = requests_retry_session()
try:
response = s.get('http://example.com', proxies={"http": "http://proxy_address:port"})
print(response.text)
except requests.exceptions.HTTPError as e:
print('HTTPError:', e)
このコードでは、バックオフ係数を使用して再試行メカニズムを設定します。つまり、リクエストが失敗した場合、同じリクエストの再試行を最大で三回まで行い、その度に次の試行まで少し長く待機します。
プロキシ設定を確認する
間違ったプロキシ設定は、あらゆるエラーの原因となります。これらのエラーは例として、間違ったプロキシポートやIPアドレス、または認証情報を入力した際に発生することがあります。リクエストが問題なく宛先に届くよう、ネットワークのニーズに沿って正しい設定が行われていることを確認する必要があります。
文書とサポートを参照する
プロキシサービスまたはライブラリの利用時に問題が発生した場合は、まず第一に公式の文書を参照します。文書内に解決策が見つからない場合は、サービスまたはライブラリに参加できるSlackまたはDiscordチャンネルがあるかどうかを確認します。また、いつでもサポートチャンネルでチケットを開いたり、質問や問題の詳細を記載したメールを送信したりすることができます。
まとめ
今回の記事では、Webスクレイピングにおけるエラーの特定とトラブルシューティングのため、さまざまなプロキシエラーコードと、それぞれの持つ意味について学びました。また、一般的なエラーの発生を防ぐためのヒントについても学びました。
プロキシエラーでお困りの場合は、 Bright Dataのプロキシサービスの利用を検討しましょう。当社のプロキシは、エラーの発生率を軽減し、より効率的なデータスクレイピングを実現します。スクレイピングのエキスパートであるか初心者であるかにかかわらず、Bright Dataのプロキシツールシリーズを使うことで、Web スクレイピング能力の向上を目指しましょう。
クレジットカードは必要ありません
