プロキシで PowerShell Invoke-WebRequest を使用する方法

PowerShell の Invoke-WebRequest コマンドレットは、ウェブサイトに HTTP 要求を行うのに便利なツールです。Bright Data のプロキシサービスを使用している場合は、-Proxy パラメーターの後にプロキシの詳細を指定することで、このコマンドレットをプロキシで使用できます。
3 min read
Invoke-Webrequest With a Proxy

この Invoke-WebRequest PowerShell プロキシガイドでは、次の内容が解説されています。

さっそく始めましょう!

PowerShell Invoke-WebRequest とは

Invoke-WebRequest は、HTTP、HTTPS、FTP 要求をウェブサーバーやウェブサービスに送信するための PowerShell コマンドレットです。デフォルトでは、サーバーによって生成された応答を自動的に解析し、フォーム、リンク、画像、その他の重要な HTML 要素のコレクションを返します。

通常、REST API へのアクセス、ウェブからのファイルのダウンロード、ウェブサービスの操作に使用されます。Invoke-WebRequest 要求の基本的な構文は次のとおりです。

Invoke-WebRequest [-Uri] <Uri> [-Method <WebRequestMethod>] [-Headers <IDictionary>] [-Body <Object>]

把握しておくべき主なパラメーターは次のとおりです。

  • -Uri: 要求の送信先のウェブリソースの URI。
  • -Method: 要求に使用する HTTP メソッド (GET、POST、PUT、DELETE など)。Invoke-WebRequest はデフォルトで GET 要求を送信します。
  • -Headers: 要求に含める追加の HTTP ヘッダー。
  • -Body: サーバーに送信する要求の本文。

ご覧のとおり、必須の引数は だけです。つまり、特定の URI に GET 要求を実行する最も簡単な構文は、次のとおりです。

Invoke-WebRequest <Uri>

このコマンドレットは 2012 年に PowerShell 3.0 で導入されました。

Invoke-WebRequest のインストール

Invoke-WebRequest を使用するには、PowerShell が必要です。それでは、PowerShell をインストールして Invoke-WebRequest コマンドレットを使用する方法を説明します!

Windows

まず、Windows PowerShellPowerShell は、それぞれ別物であることを理解する必要があります。Windows PowerShell は Windows に付属する PowerShell のバージョンで、最新バージョンは 5.1 です。Windows Powershell では Invoke-WebRequest コマンドレットを使用できます。そのため、最新の Windows リリースを使用していれば、他に準備は必要ありません!古いバージョンの場合は、 PowerShell 公式インストールガイドに従ってください。

また、Invoke-WebRequest の一部の機能は、PowerShell 7.x 以降でのみ利用可能です。インストール方法の詳細については、Windows PowerShell 5.1 から PowerShell 7 への公式移行ガイドを参照してください。PowerShell 7.x は新しいディレクトリにインストールされ、Windows PowerShell 5.1 と並行して実行されます。

ご使用の Windows マシンにインストールされている PowerShell の現在のバージョンは、次のコマンドで確認できます。

$PSVersionTable

PowerShell 7.x では、次のような内容が表示されます。

PSVersion                      7.4.1

PSEdition                      Core

GitCommitId                    7.4.1

OS                             Microsoft Windows 10.0.22631

Platform                       Win32NT

PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}

PSRemotingProtocolVersion      2.3

SerializationVersion           1.1.0.1

WSManStackVersion              3.0

macOS および Linux

PowerShell 7.x は macOS と Linux の両方にインストールできます。ただし、Invoke-WebRequest コマンドレットを使用するためだけに PowerShell エコシステム全体を OS にインストールするというのは、あまり賢明ではありません。代わりに curl を使用します。このライブラリは macOS やほとんどの Linux ディストリビューションにプリインストールされており、Invoke-WebRequest と同じ機能を提供します。詳細については、 curl プロキシガイドをご覧ください。

PowerShell でプロキシを使い始めるための前提条件

プロキシは、クライアントと送信先サーバーの間の仲介役として機能します。クライアントからの要求をインターセプトし、サーバーに転送し、サーバーから応答を受信し、それをクライアントに返します。これにより、送信先サーバーは、要求がクライアントからではなく、選択したプロキシサーバーの IP と場所からのものであると認識します。

Invoke-WebRequest で PowerShell プロキシを使い始めるには、プロキシサーバーの URL がどのようなものかを理解しておく必要があります。

これは PowerShell Invoke-WebRequest プロキシの URL です。

<PROTOCOL>://[<USERNAME>:<PASSWORD>]@<HOST>[:<PORT>]

構成は次のとおりです。

  • : プロキシサーバーへの接続に使用するプロトコル。
  • : プロキシサーバーのホスト名の IP アドレスまたは URL。
  • : プロキシサーバーが受信するポート番号。
  • : プロキシ認証が必要な場合に指定するオプションのユーザー名。
  • : プロキシ認証が必要な場合に指定するオプションのパスワード。

URL の :// の部分は、Invoke-WebRequest により必須となります。この部分を省略すると、要求は次のエラーで失敗します。

Invoke-WebRequest : この操作は相対 URI でサポートされていません。

プロキシプロトコルに関しては、HTTP、HTTPS、SOCKS が最も一般的です。PowerShell 5.1 の Invoke-WebRequest では HTTP のみがサポートされていますが、PowerShell 7.x では HTTPS と SOCKS もサポートされています。

それでは有効な HTTP プロキシを取得しましょう!

以下のように、オンラインで無料で見つけることができます。

Protocol: HTTP; IP Address: 190.6.23.219; Port: 999

この情報を組み合わせて、次のプロキシ URL を取得します。

http://190.6.23.219:999

警告

無料のプロキシは、学習目的で使用する分には問題ありませんが、実際のシナリオでは信頼できません。無料のプロキシは信頼性が低く、エラーが発生しやすく、低速で、データを大量に消費し、長持ちしません。そのため、使用すべきではありません!

では何を使えば良いのでしょうか?市場大手のプロバイダーである Bright Data のプレミアムプロキシをお勧めします。加入して、信頼性の高いプロキシを無料でお試しください。

Bright Data のプロキシは認証によって保護されているため、信頼できるユーザーしかアクセスできません。それでは、プロトコルが HTTP、ホストが 45.103.203.109、ポートが 9571、認証情報の組み合わせが admin-4521 と rUuH3tJqf であるとします。この場合、Invoke-WebRequest のプロキシ URL は次のようになります。

http://admin-4521:@rUuH3tJqf45.103.203.109:9571

Invoke-WebRequest で HTTP プロキシを指定する方法

始める前に、PowerShell で以下のコマンドを起動します。

Invoke-WebRequest "https://httpbin.org/ip"

That should print something like:

StatusCode        : 200

StatusDescription : OK

Content           : {

                      "origin": "194.34.233.12"

                    }

RawContent        : HTTP/1.1 200 OK

                    Connection: keep-alive

                    Access-Control-Allow-Origin: *

                    Access-Control-Allow-Credentials: true

                    Content-Length: 32

                    Content-Type: application/json

                    Date: Thu, 01 Feb 2024 10:46:14 GMT...

Forms             : {}

Headers           : {[Connection, keep-alive], [Access-Control-Allow-Origin, *], [Access-Control-Allow-Credentials,

                    true], [Content-Length, 32]...}

Images            : {}

InputFields       : {}

Links             : {}

ParsedHtml        : mshtml.HTMLDocumentClass

RawContentLength  : 32

Content フィールドに注目してください。これにはユーザーの IP が含まれます。

なぜでしょう?HTTPBin プロジェクトの /ip エンドポイントは、要求の送信元の IP を返すためです。つまり、要求を実行したマシンの IP アドレスを返します。この場合、ユーザーのマシンの IP になります。

Content フィールドのみにアクセスする場合は、次のコマンドでアクセスできます。

$response = Invoke-WebRequest "https://httpbin.org/ip"

$response.Content

This would print:

{

  "origin": "194.34.233.12"

}

同じ要求をプロキシ経由でルーティングすると、自分の IP ではなく、プロキシサーバーの IP アドレスが表示されます。したがって、そのエンドポイントを呼び出すことで、指定された PowerShell Invoke-WebRequest プロキシが正常に動作していることを確認できます。

Invoke-WebRequest で PowerShell プロキシを設定するには、いくつかの方法があります。以下のステップバイステップガイドのセクションで詳細をご覧ください!

コマンドラインオプションの使用

Invoke-WebRequest には、要求のプロキシ URL を指定するための -Proxy フラグが用意されています。

プロキシサーバーで Invoke-WebRequest を使用する場合の構文は、次のようになります。

Invoke-WebRequest -Proxy "<PROTOCOL>://[<USERNAME>:<PASSWORD>]@<HOST>[:<PORT>]" <Uri>

この時点でこの PowerShell コマンドを実行した場合

Invoke-WebRequest -Proxy "http://190.6.23.219:999" "https://httpbin.org/ip"
Invoke-WebRequest -Uri "http://httpbin.org/ip" -Proxy "http://brd.superproxy.io:22225" -ProxyCredential (New-Object System.Management.Automation.PSCredential("brd-customer-CUSTOMER_ID-zone-ZONE’S_NAME", ("ZONE’S_PASSWORD" | ConvertTo-SecureString -AsPlainText -Force)))

The result should be:

StatusCode        : 200

StatusDescription : OK

Content           : {

                      "origin": "190.6.23.219"

                    }

RawContent        : HTTP/1.1 200 OK

                    Connection: keep-alive

                    Access-Control-Allow-Origin: *

                    Access-Control-Allow-Credentials: true

                    Content-Length: 31

                    Content-Type: application/json

                    Date: Thu, 01 Feb 2024 12:36:56 GMT...

Forms             : {}

Headers           : {[Connection, keep-alive], [Access-Control-Allow-Origin, *], [Access-Control-Allow-Credentials,

                    true], [Content-Length, 31]...}

Images            : {}

InputFields       : {}

Links             : {}

ParsedHtml        : mshtml.HTMLDocumentClass

RawContentLength  : 31

Content の送信元がプロキシサーバーの IP と一致しています。これは想定通り、ターゲットサーバーが要求をプロキシからのものとして認識していることを示します。見事です!

注意: 無料のプロキシは長続きしません!このガイドを読むころに上記のサーバーがまだ稼働している可能性は、ほとんどありません。エラーが発生した場合は、新しいプロキシに置き換えてください。

環境変数の使用

PowerShell 7.0 以降、Invoke-WebRequest は環境変数によるプロキシ構成をサポートしています。

したがって、Invoke-WebRequest で PowerShell プロキシを使用するもう 1 つの方法は、次の 2 つの envs を設定する方法です。

  • HTTP_Proxy: HTTP 要求の場合に使用するプロキシサーバーの URL。
  • HTTPS_PROXY: HTTPS 要求の場合に使用するプロキシサーバーの URL。

Windows では、次の PowerShell 構文を使用してこの 2 つの環境変数を設定できます。

$env:HTTP_PROXY = "<PROTOCOL>://[<USERNAME>:<PASSWORD>]@<HOST>[:<PORT>]"

$env:HTTPS_PROXY = "<PROTOCOL>://[<USERNAME>:<PASSWORD>]@<HOST>[:<PORT>]"

この例では、コマンドは次のようになります。

$env:HTTP_PROXY = "http://190.6.23.219:999"

$env:HTTPS_PROXY = "http://190.6.23.219:999"

macOS と Linux では、以下の構文を使用する必要があります。

export HTTP_PROXY="<PROTOCOL>://[<USERNAME>:<PASSWORD>]@<HOST>[:<PORT>]"

export HTTPS_PROXY="<PROTOCOL>://[<USERNAME>:<PASSWORD>]@<HOST>[:<PORT>]"

つまり、2 つのコマンドは次のようになります。

export http_proxy="http://190.6.23.219:999"

export https_proxy="http://190.6.23.219:999"

今後すべての Invoke-WebRequest 要求は、-Proxy オプションを追加しなくても指定されたプロキシを経由するようになります。envs を設定したら、以下のコマンドを起動します。

Invoke-WebRequest "https://httpbin.org/ip"

You will get the same result as before:

StatusCode        : 200

StatusDescription : OK

Content           : {

                      "origin": "190.6.23.219"

                    }

RawContent        : HTTP/1.1 200 OK

                    Connection: keep-alive

                    Access-Control-Allow-Origin: *

                    Access-Control-Allow-Credentials: true

                    Content-Length: 31

                    Content-Type: application/json

                    Date: Thu, 01 Feb 2024 12:36:56 GMT...

Forms             : {}

Headers           : {[Connection, keep-alive], [Access-Control-Allow-Origin, *], [Access-Control-Allow-Credentials,

                    true], [Content-Length, 31]...}

Images            : {}

InputFields       : {}

Links             : {}

ParsedHtml        : mshtml.HTMLDocumentClass

RawContentLength  : 31

Invoke-WebRequest プロキシを無効にするには、次のように環境変数の設定を解除します。

$env:HTTP_PROXY = ""

$env:HTTPS_PROXY = ""

Or on macOS and Linux:

unset HTTP_PROXY

unset HTTPS_PROXY

Invoke-WebRequest は標準の動作に戻り、https://httpbin.org/ip によりユーザーの IP が公開されるようになります。

PowerShell で HTTPS および SOCKS プロキシを使用する方法

HTTPS または SOCKS プロキシを使用する必要がある場合は、PowerShell のバージョン 7.x+ へのアップグレードが必要です。アップグレードしないと、Invoke-WebRequest は次のエラーで失敗します。

Invoke-WebRequest : ServicePointManager が HTTPS スキームのプロキシをサポートしていません。

または SOCKS プロキシの場合

Invoke-WebRequest : ServicePointManager が SOCKS スキームのプロキシをサポートしていません。

PowerShell 7.x で HTTPS または SOCKS プロキシを使用する場合、Invoke-WebRequest コマンドの構造は変わりません。

Invoke-WebRequest -Proxy "<PROTOCOL>://[<USERNAME>:<PASSWORD>]@<HOST>[:<PORT>]" <Uri>

変わるのは、 が http ではなく、https、socks4、socks4a、socks5、または socks5a になる点です。

上記以外のプロトコルを使用するプロキシで要求を呼び出そうとすると、次のエラーが表示されます。

Invoke-WebRequest: Only the 'http', 'https', 'socks4', 'socks4a' and 'socks5' schemes are allowed for proxies.

したがって、Invoke-WebRequest SOCKS プロキシ要求の完全な例は、次のようになります。

Invoke-WebRequest -Proxy "socks5://94.14.109.54:3567" "http://httpbin.org/ip"

As you can expect, the result will be:

StatusCode        : 200

StatusDescription : OK

Content           : {

                      "origin": "94.14.109.54"

                    }

RawContent        : HTTP/1.1 200 OK

                    Connection: keep-alive

                    Access-Control-Allow-Origin: *

                    Access-Control-Allow-Credentials: true

                    Content-Length: 31

                    Content-Type: application/json

                    Date: Thu, 01 Feb 2024 12:47:56 GMT...

Forms             : {}

Headers           : {[Connection, keep-alive], [Access-Control-Allow-Origin, *], [Access-Control-Allow-Credentials,

                    true], [Content-Length, 31]...}

Images            : {}

InputFields       : {}

Links             : {}

ParsedHtml        : mshtml.HTMLDocumentClass

RawContentLength  : 31

知っておくべきヒントやコツ

PowerShell Invoke-WebRequest プロキシをプロのように使うために役立つヒントやコツをご紹介します。

PowerShell プロキシ構成を無視する

Invoke-WebRequest が環境変数から読み取られた構成済みの PowerShell プロキシを使用しないようにするには、以下のように -NoProxy オプションを使用できます。

Invoke-WebRequest -NoProxy <Uri>

これにより、Invoke-WebRequest にプロキシを使用せず に接続するよう指示されます。

この方法が機能することを確認するには、envs でプロキシを設定して以下を実行します。

Invoke-WebRequest -NoProxy "https://httpbin.org/ip"

結果の送信元には、プロキシサーバーの IP ではなく、ユーザーの IP が含まれます。

Avoid SSL Certificate Errors

HTTP プロキシを使用する場合、SSL 証明書エラーが原因で要求が失敗する可能性があります。これを回避するには、-SkipCertificateCheck オプションを指定します。

Invoke-WebRequest -SkipCertificateCheck -Proxy "<PROTOCOL>://[<USERNAME>:<PASSWORD>]@<HOST>[:<PORT>]" <Uri>

-SkipCertificateCheck は、セキュリティで保護されていないサーバーへの接続を許可することで、証明書エラーを回避するのに役立ちます。このパラメーターの使用は安全ではないため、注意が必要です。既知のホストを使用する場合にのみ設定してください。

たとえば、以下の方法で SSL の問題を回避しながら、プロキシ経由で HttpBin に接続できます。

Invoke-WebRequest -SkipCertificateCheck -Proxy "http://190.6.23.219:999" "https://httpbin.org/ip"

どの PowerShell プロキシを使用すべきか

この質問の答えは、Invoke-WebRequest 要求の目的によって異なります。ニーズに合った PowerShell プロキシを見つけるには、使用可能なさまざまなタイプのプロキシをご覧ください。

  • データセンタープロキシ: 高速で安価ですが、IP 範囲が識別可能なため、サイトが簡単に検出しブロックできます。
  • 住宅用プロキシ: 特定の場所にある実際のデバイスの本物の IP アドレスをローテーションで提供します。これにより、高いレベルの匿名性が保証されます。住宅用プロキシは、地域制限ブロックがかかっているサイトにアクセスしたり、ボット対策を回避したりするのに最適です。
  • ISP プロキシ: ISP に登録されたデバイスの固定 IP アドレスを提供するため、安全で高速かつ信頼性が高いのが特徴です。ISP プロキシは住宅用静的プロキシとも呼ばれ、SEO のモニタリングや市場調査に最適なソリューションです。
  • モバイルプロキシ: 実際のモバイルデバイスの IP を提供し、高い匿名性を実現します。モバイルデバイス向けに特別に設計されたアプリケーションやサイト、コンテンツにアクセスするのに便利です。

以上、簡単な概要になりますが、詳細についてはプロキシ IP タイプに関する ガイドをご覧ください。

まとめ

この PowerShell プロキシガイドでは、Invoke-WebRequest とは何か、どのような仕組みか、HTTP/HTTPS/SOCKS プロキシでの使用方法を解説しました。無料プロバイダーのプロキシは頼りになりません。そのため、どのプロキシプロバイダーを使用するか決める必要があります。市場大手の Bright Data を選べば、時間も手間も省けます。

Bright Data は世界最高水準のプロキシサーバーを管理しており、フォーチュン 500 企業や 20,000 社以上の顧客にサービスを提供しています。世界中に広がるプロキシネットワークで、以下のようなプロキシが提供されています。

総合的に、これは市場で最大かつ最も信頼性の高いスクレイピング指向のプロキシネットワークの 1 つです。 

弊社の営業担当者にご相談の上、お客様のニーズに最適な Bright Data 製品をお選びください。

あなたは下記にもご興味がおありかもしれません

Anonymous Proxy_
プロキシ全般

匿名プロキシ: 定義とその仕組み

このガイドでは、次の内容を説明します。 では、さっそく始めましょう! 匿名プロキシとは何か? 匿名プロキシはアノニマイザーとも呼ばれ、インターネット上のアクティビティを追跡できないようにすることを目的としたプロキシサーバーの一種です。もっと詳しく言うと、ユーザーの身元、位置、プライバシーを隠すことがこのプロキシの目的です。 匿名プロキシサーバー経由でWebを閲覧しているユーザーは、デスティネーションサーバーで一般的な匿名ユーザーとして表示されます。具体的には、Webサーバーはリクエストを送信したユーザー本人を特定する情報を追跡できなくなります。 あらゆるタイプのプロキシが匿名プロキシとして機能できる点に注意してください。プロキシサーバーは、プロキシのタイプではなく、ユーザーとターゲットWebサイト間の動作方法に基づいて「匿名」と見なされます。 匿名プロキシサーバーの仕組み 匿名プロキシサーバーの機能は他のプロキシサーバーと同様で、ユーザーのデバイスとターゲットサイト間の仲介役として働きます。プロキシを使用した際の詳細は次のようになります。 要するに、デスティネーションは受信リクエストをソースクライアントから送信されたものとは認識しません。その代わりに、プロキシサーバーから送信されたリクエストとして認識します。ターゲットサーバーがプロキシのIPから発信されたリクエストとして認識するため、このプロセスでクライアントのIPが本質的に隠されることになります。IPはユーザーの位置特定に使用されるため、このプロセスでユーザーの位置情報を保護することにもなります。 匿名プロキシが他のプロキシと一線を画すのは、プライバシーに重点を置いている点です。ターゲットサーバーにリクエストを転送する際に、ユーザーのリクエストから識別情報を取り除くことで匿名性がさらに強化されます。隠す方法と隠すデータの種類によって、3つのカテゴリーに分類できます。以下のセクションで詳しく説明します。 プロキシ匿名性のレベル 匿名プロキシサーバーは、提供する匿名性のレベルによって、次の3つのグループに分類できます。 エリートプロキシ エリートプロキシは、ユーザー本人を特定する情報を完全に隠すことで、最高レベルの匿名性を提供します。ユーザーのIPを隠し、それ以外のユーザー固有の情報も一切送信しません。ユーザーの完全な匿名性を保つため、エリートプロキシはデスティネーションへのリクエストから次のヘッダーを削除する傾向があります。 匿名プロキシ 匿名プロキシは、ユーザーのIPアドレスを隠すことでプライバシーを向上します。高レベルの匿名性を提供しますが、それでもデスティネーションサーバーに一部の情報が漏洩する可能性があります。例をあげると、匿名プロキシではリクエストにいくつかのヘッダーを残すことが可能です。また、デスティネーションサーバーがリクエストをプロキシから発信されたものと識別し、リクエストに応じてブロックできるプロキシ固有のヘッダーを追加できます。 透過型プロキシ 透過型プロキシは匿名プロキシとは言い難いものです。透過型プロキシのX-Forwarded-ForヘッダーにはユーザーのIPが含まれ、経由ヘッダーにはプロキシのIPが格納されます。これはサーバーがリクエストを転送するために使用する仲介役としては機能しますが、通常エンドユーザーが使用することはありません。透過型プロキシがクライアントのオンラインIDとアクティビティを露出することがその理由です。 匿名プロキシ: ユースケース 匿名プロキシサーバーは、個人およびビジネス両方のアクティビティに関する無数のユースケースを提供します。個人ユーザーにとって、一番のメリットは安全なブラウジングです。匿名性は、ターゲティング広告、地理的な制限、潜在的な検閲からユーザーを保護し、より安全で自由なオンライン体験を促進します。 ビジネスおよび開発者向けの用途では、匿名プロキシが次の分野で重要な役割を果たします。 これらはほんの一例ですが、可能性は無限であることを忘れないでください! 匿名プロキシを使用すべき理由 オンラインアクター(サーバー、サービス、ソーシャルメディアなど)から身元(IPアドレスなど)を隠す重要性を示す説得力のある理由が多数あります。以下はその一部です。  オンラインプライバシーはかけがえのない資産です。どんな犠牲を払ってでも守る必要があります。それを実現するのが匿名プロキシです。特にWebスクレイピングの際に匿名プロキシは必須で、これによって慎重かつ効率的なデータ抽出が可能になります。 ただし、プロキシが常にプライバシーを確保すると思い込むのは危険です。無料の匿名プロキシサービスの多くは信頼性に欠けます。ユーザーに課金せずに世界規模のサーバーアーキテクチャをどうやって維持できると思いますか?彼らは無料を維持するために、ユーザーのデータを販売したり、ハッカーや政府機関が作ったマルウェアとなったりします。こういった事例はいくつかの研究でも証明されています。さらに、無料の匿名プロキシソリューションは通常HTTPSをサポートせず、SOCKSなどの高度なプロトコルもサポートしていません。詳細は SOCKSとHTTP比較ガイドをご覧ください。 このような理由から、無料のプロバイダーは利用せず、Bright Dataのような強力で信頼性の高い有料ソリューションを選択しましょう。 「匿名プロキシが検出されました。ここをクリックしてください」エラーへの対処方法 プロキシを使用すると、次のような「匿名プロキシが検出されました。ここをクリックしてください」というエラーページが表示される場合があります。   これは、プロキシ経由での接続をターゲットサーバーが検出したことを意味します。このエラーが発生する場合、次にような原因が考えられます。  通常、信頼性を欠くIPを提供する低品質または無料の匿名プロキシサーバーを使用することが主な原因です。「匿名プロキシが検出されました」エラーを修正するには、次の方法を実行してみてください。 これらの回避策がどれもうまくいかない場合は、使用中のプロキシプロバイダーよりも 優れたプロキシプロバイダーが必要になります。 プロキシを使用した際に表示されるエラーは、「匿名プロキシが検出されました。ここをクリックしてください」だけではないことに注意してください。これ以外にも発生する可能性のあるエラーは多数あります。プロキシエラーコードのガイド内で説明しているように、エラーの多くは迅速かつ簡単に解決できます。 まとめ この記事では、匿名プロキシとは何か、その仕組み、匿名プロキシが提供するプライバシーレベル、匿名プロキシを使用すべき理由について説明しました。詳細部分では、信頼できるプロキシサービスプロバイダーを使用すると、「匿名プロキシが検出されました。ここをクリックしてください」というエラーを回避できることも指摘しました。ただし、ここで問題となるのが、世の中にはプロキシプロバイダーが多数あること、すべてのプロバイダーをチェックするのに数か月かかることです。そんな時間とコストを節約するのが、市場で最高水準のBright Dataです! Bright Dataは世界最高のプロキシサーバーを管理しており、フォーチュン500企業と2万以上の顧客にサービスを提供しています。次にように、さまざまなタイプのプロキシを提供しています。 信頼性が高く、高速でグローバルなプロキシネットワークは、いかなるサイトからのデータ取得も容易に実行する、多数のWebスクレイピングサービスの基礎でもあります。
1 min read
Web scraping with R - featured image
各種ご利用方法

Rによるウェブスクレイピングの実践ガイド

このチュートリアルでは、R言語とrvestを使用してウェブスクレイピングを実行し、Amazonのウェブサイトで一般にアクセス可能な1つのURLから商品レビューを抽出する方法を説明します。
2 min read