プライベートプロキシの仕組みと選び方

プライベートプロキシの仕組みと選び方

プライベートプロキシサービスは通常、料金を支払った期間中、1人の利用者にIPアドレスを確保します。どのアプリ、業務用パソコン、チームメンバーに使わせるかは自分で決められます。そのサービスのほかの利用者が、同時に同じアドレスを使うことはありません。

プライベートプロキシと共有プロキシの選択全般は、概要記事で説明しています。ここでは、プライベートのサービスが何を確保するのか、実際の利点は何か、不適切なパッケージに料金を払わないために何を確認すべきかを見ていきます。

事業者がプロキシを確保する仕組み

事業者は、注文に属するIPや接続と、その利用可能期間を記録します。専用IPの場合は、合意した期間中、ほかの利用者がそのIPを介してリクエストを送れないようにします。

接続時、プロキシはユーザー名とパスワード、またはパソコンやサーバーの送信元IPを確認します。その後、アカウントに割り当てられたアドレスや接続を介してリクエストを送ります。接続の許可と、特定の出口IPを使う許可は、別々の設定です。個別のパスワードがあるだけで、そのIPが自分用に確保されるわけではありません。

プロキシのアドレス、ポート、アクセス情報を受け取ります。複数の自分のアプリで利用でき、確保の対象は顧客としての自分です。図では、固定IPの30日間レンタルを例にしています。接続していない間やアプリを閉じている間も、IPは確保されたままです。

1人の利用者が、専用の固定IPを30日間使います。そのサービスのほかの利用者は、このアドレスを介してリクエストを送りません。

プロキシの種類ごとの専用アクセス

DCと表示されたサーバー。IPは1人の利用者に割り当てられています。

データセンタープロキシ:サーバー上のIPを確保

データセンタープロキシでは、事業者が自社サーバーを介して使えるアドレスを管理します。プライベートのパッケージは、特定のIPを自分のアカウント用に確保します。プロキシはウェブサイトとの接続を開くときに、その割り当てられたアドレスを使います。

1台の物理サーバーで多数のIPを扱えます。プロキシソフトウェアは、外向きの各接続の送信元アドレスを選び、誰がそのアドレスを使えるかを確認します。そのため、同じマシンで異なる利用者にサービスを提供し、それぞれに専用IPの組を割り当てられます。

一般的な接続方法は2つあります。1つはIPとポートのリストを受け取り、必要な項目へ直接接続する方法です。もう1つはサービスのゲートウェイへ接続し、ポートや接続パラメーターで自分のリスト内の特定IPを選ぶ方法です。どちらでも、サービスが利用者と割り当てアドレスの対応関係を維持します。

同じ構成のサーバーにISPと表示されています。IPは1人の利用者に割り当てられています。

ISPプロキシ:インターネット事業者由来の専用アドレス

ISPプロキシは、インターネット事業者から取得したアドレスをサーバー基盤で使います。このモデルはStatic Residentialという名称でも販売されています。プロキシサービスが顧客への割り当てを管理し、プライベートのパッケージでは、在庫内の特定アドレスを1人に割り当てます。

固定IPのISPパッケージでは、サービスが利用者、割り当てIP、接続情報、レンタル期間を記録します。ゲートウェイの構成例として、各ポートを自分のリスト内の特定IPに対応付ける方式があります。そのポートに再接続すると、同じ割り当てアドレスを使います。接続パラメーターでアドレスを選ぶサービスもあります。

ISPはアドレスのネットワークの由来を表し、プライベートは誰が使えるかを表します。プライベートのISPパッケージは1人に固定リストを確保できますが、Static Residentialという名称だけでは約束されません。アドレスの種類とアクセス条件を両方確認してください。

上:複数の利用者が使う一般的なSDKプール。下:特定サイト向けに家庭のIPを1人に割り当てる、例外的な方式。

住宅用プロキシ:専用アドレスはまれな例外

一般的な住宅用プールは、家庭の端末ネットワークへの共有アクセスを提供します。サービスが各利用者のリクエストに対して端末を選びます。スティッキーセッションで選択したIPを一時的に維持できても、その利用者専用に確保するわけではありません。

特化したサービスでは、指定サイトへのアクセス用に、一群の家庭のIPを1人に確保する場合があります。ほかの利用者は同じドメインに対して、そのIPを使えません。これは一般的な共有プールの例外です。任意の接続先に使える専用IPと考える前に、対象ドメインのリストを確認してください。

1人の利用者に、SIM付きの専用モデムが提供されます。パブリックIPは専用とは表示されていません。

モバイルプロキシ:専用モデムでもパブリックIPは共有される

専用モバイルプロキシは通常、SIMカード付きのモデムやスマートフォンと、その携帯回線を1人に確保します。提供されるアドレスとポートを使うと、その端末にリクエストが届きます。プロキシサービスのほかの利用者は、確保された端末を使えません。

パブリックIPを管理するのは携帯通信事業者です。CGNATでは、プロキシをまったく使わない人を含め、複数の契約者が同時に1つのパブリックアドレスを使えます。そのため、モデムを割り当ててもらっても、サイトが見るアドレスが自分専用になるわけではありません。

割り当てられた端末は自分で制御します。アプリの接続、負荷の管理に加え、サービスが対応していれば、ダッシュボード、URL、APIから再接続を要求できます。再接続後、通信事業者が別のパブリックIPを割り当てる場合があります。モデムは引き続き自分に割り当てられ、プロキシの接続アドレスとポートも変わらない場合があります。

プライベートプロキシの利点

ほかの利用者の活動からIPの評判を守る

パブリックIP自体が自分用に確保されていれば、レンタル中、ほかのプロキシ利用者はそこからリクエストを送れません。どのアプリが使い、どのサイトに接続するかを自分で決められます。この利点は専用のパブリックIPに関するものです。CGNATの背後にある専用モバイルモデムでは、通信事業者のアドレスを共有するほかの契約者を制御できません。

サイトはIPの評判に応じて、CAPTCHAなどの確認を要求するかを決める場合があります。専用IPなら、レンタル中にほかのプロキシ利用者がその評判に関わるリクエストを追加することはありません。アドレスに関連付く活動の頻度と種類を制御できますが、どう応答するかはサイトが決めます。

作業を続けると、操作の順序、リクエスト頻度、活動時間帯といった自分のやり取りの履歴が蓄積されます。サイトの応答が変わったら、自分のアプリの活動と比較できます。これにより、不具合の原因を特定し、関係するタスクを調整しやすくなります。

そのIPからのすべてのリクエストを調整できる

専用IPを介したリクエストの流れは、自分のアプリとチームメンバーが作ります。ダウンロードの予定を組み、タスク間でリクエストを分配し、どのアプリが負荷を生んだかを確認できます。専用アクセスの利点は、この流れを制御することです。利用者別の通信量集計なら、共有プロキシでも可能です。

サイトがIP単位でリクエスト頻度を制限するとき、この利点は特に明確です。同じアドレスを使う自分の全アプリのリクエストが、共通のカウンターに加算されます。別のアプリを起動すると全体の負荷が増えるため、IP全体でスケジュールとリクエスト頻度を調整します。

専用アクセスなら、そのリクエストの流れ全体を制御できます。並行タスク数を変える、一部を一時停止する、送信を時間的に分散するといった調整を行い、自分のログで結果を評価できます。知らない利用者が同時にどれほどの通信をしているかを推測する必要はありません。

プライベートプロキシを選ぶときの確認点

割り当てられたIPに既存の制限はあるか

例:前の利用者が使っていたときに、サイトAがIP 203.0.113.21を制限しました。その制限は、自分に割り当てられた後も残る可能性があります。

はい。専用IPはレンタル前に別の利用者が使っていた場合があり、そのときの制限が残ることがあります。専用利用が決めるのは現在誰が使うかであり、サイトがすでに持つ履歴を消すわけではありません。

IPを調べる際は、ネットワークの由来と観測された活動を分けます。ホスティングネットワークという分類はアドレスの種類を表します。迷惑メールの記録や特定サイトの制限は、その使われ方に関するものです。各システムは独自のデータと評価基準を持つため、1つのデータベースの結果が、すべてのサイトでの扱いを示すわけではありません。

異なる利用者への割り当ての間に、一定の休止期間を置く事業者もあります。最近の活動を評価するシステムでは、以前の観測がいずれ評価対象期間の外に出ます。休止によって特定システムの評価が変わる場合はありますが、すべてのデータベースから情報が消える共通の期間はありません。

「クリーンなIP」という約束は、検証可能な条件に置き換えます。提供された時点で、必要なサイト上で自分のタスクを実行できることです。購入前に、小さなパッケージで試せるか、割り当てIPが最初から伝えた用途に合わない場合にどうなるかを確認します。問題の調査にはデータベースの確認を使い、必要なサービスで実際にどう動くかに基づいて判断してください。

プライベートIPがサイトにブロックされる理由

想定される例:同じ専用IPでも、ブラウザーはページを受信し、アプリケーションは拒否されます。リクエストとセッションの違いが、サイトの応答に影響する場合があります。

ブロックの判断には、IPだけでなく、リクエスト、セッションデータ、アプリの動作も影響します。専用アクセスは、そのアドレスの現在の活動に対するほかのプロキシ利用者の影響を除きますが、サイトは自分のリクエストを引き続き独自のルールで評価します。

HTTPやSOCKSのプロキシが外向きの接続を確立するため、サイトが見るのはプロキシのIPとネットワーク接続です。一般的なCONNECTトンネルを介したHTTPSでも、サイトとのTLSのやり取りはアプリが行います。サイトはアプリのヘッダー、Cookie、セッションデータも受け取ります。専用IPを使っても、これらの情報がアプリ間で同一になるわけではありません。

使用予定のアプリと操作でプロキシをテストしてください。ブラウザーでは開けるのにアプリケーションでは拒否されるなら、そのリクエスト、認証、設定を調べます。条件を1つずつ変え、結果を記録します。IPとアプリを同時に変えると、どちらが改善につながったか分かりません。

1つのブロックで複数の専用IPが影響を受けるか

異なる3つのIP、203.0.113.21、.22、.23は、203.0.113.0/24に属します。このサブネットをブロックするルールは、3つすべてからの通信を拒否します。

はい。サイトのルールが、そのアドレスの属する範囲やネットワークを対象にする場合です。各IPを個別に自分へ割り当てても、サブネットやネットワーク事業者が分散するわけではありません。

サイトは、1つのIP、アドレス範囲、事業者のネットワーク全体を制限できます。たとえば、203.0.113.21、.22、.23は、すべて203.0.113.0/24に属し、先頭24ビットが同じです。この/24を対象とするルールは3つすべてに影響します。複数のサブネットが、ASNで識別される1つの自律システムに属する場合もあるため、サブネットが違ってもネットワーク事業者が違うとは限りません。

多数のIPを選ぶときは、IP数と併せてサブネット数とASN数を確認します。異なるサブネットなら、1つのサブネット向けルールで影響を受けるアドレス数を減らせます。ASNも違えば、自律システム間に分散できます。この独立性が必要なタスクでは、パッケージの構成と、別ネットワークのIPへ交換できるかを確認してください。すでに制限された範囲からアドレスを追加しても、その問題は解決しません。

大量データ転送の費用をどう見積もるか

プロキシ料金の概念図です。固定料金Fは水平で、従量料金Gと通信量の積は増加します。2本の線はF/G GBで交わります。同じタスクに適したプラン同士を比較してください。架空の価格は示していません。

データ量が多い場合、固定料金で通信量を含む専用パッケージは、GB単位のプランより安くなることがあります。同じタスクを実行できる選択肢を比較します。必要な結果を得られなければ、IP単価が低くても作業費用は判断できません。

通信量無制限の専用IPセットの月額費用をF、追加の固定料金がない別の適切なプランのGB単価をGとします。転送料金がセットの料金と等しくなる通信量は、次のとおりです。

通信量(GB)= F / G

この値を超えると、同じ転送量に対するプロキシ料金は固定パッケージのほうが低くなります。再ダウンロードも計算に含めてください。同時接続数と帯域幅の上限も確認します。GB単位の料金がないというのは課金方式の説明であり、処理速度は利用可能な資源にも左右されます。

運用予算では、総支出を、正常に完了した操作数や取得した有用なデータ量と比較します。再試行や追加の確認処理が必要なら、その通信量、時間、有料サービスも費用に含めます。速度や節約に関する一律の約束に頼らず、自分のワークフローを評価できます。

割り当てIPが使えなくなったらどうするか

2つの異なるケースです。上:プロキシ接続が失敗するため、アドレス、ポート、認証を確認します。下:プロキシには到達できてもサイトが拒否するため、サイトの応答とアプリのリクエストを調べます。交換前に、元のIPが復旧するのか別のIPに変わるのかを確認します。

まず、プロキシ自体が使えないのか、必要なサイトだけが拒否しているのかを判断します。前者は接続の復旧、後者はサイト応答の調査が必要です。自動のプロキシ可用性チェックでは、特定接続先の制限を検出できない場合があります。

専用アドレスでは、既存IPの復旧と新IPの発行を区別します。不具合を検出すると自動交換するサービスもあります。直接接続ではアプリのプロキシ項目の更新が必要になり、ゲートウェイでは接続情報が同じまま、サイトが見るIPだけ変わる場合があります。元のアドレスに結び付いた処理では、交換によって動作条件が変わります。

支払い前に、不具合IPを復旧するのか交換するのか、どの不具合が交換対象か、変更のタイミングを自分で選べるかを尋ねます。同じアドレスの維持に依存する処理なら、これらの条件は総合的な可用性の割合より重要です。

拡大前にパッケージをテストする方法

1. タスクに必要な資源を明確にする

自分だけが使うパブリックIPが必要なら、アドレスを1人に割り当てると明記されたサービスを選びます。条件には、割り当て期間と専用利用の範囲が必要です。データセンターやISPプロキシなら具体的なIPリストの場合があり、モバイルサービスならモデムだけが専用かどうかを確認します。製品名の「プライベート」という言葉は、この説明の代わりになりません。

2. 必要な構成の小さなセットから始める

テスト用パッケージは、将来の注文とネットワークの種類、地域、利用条件を揃えます。アプリを接続し、実際の出口IP、ASN、必要な地域を確認します。固定割り当てでは、接続を閉じた後とテスト後半に再確認し、合意した条件どおりアドレスが割り当てられ続けるかを見ます。これはIPの持続性の確認です。専用割り当てはサービス条件に明記される必要があります。

3. ワークフロー全体をテストする

予定の同時接続数で、必要なサイトの通常の操作を一通り実行します。応答時間、成功結果、再試行、追加の確認要求、通信量を記録します。プロキシ接続のエラーとサイト自体の応答を分けてください。トップページの読み込みや速度テストが1回成功しただけでは、長期間のアプリ動作を評価できません。

4. 結果に基づいてパッケージを拡大する

注文を拡大する際は、テストしたネットワークの種類、地域、必要なサブネット・ASN分布、上限、交換条件を維持します。得られた結果から月間支出を見積もります。必要な操作を許容できる応答時間で実行でき、成功結果あたりの費用が予算内で、アドレスを失った際の手順もワークフローに合う場合に拡大してください。

ナレッジベースに戻る