購入前に住宅用プロキシ トラフィックを計画する
住宅用プロキシはトラフィックに応じて課金されます。国、支払いコイン、セッション モードは個別に選択できます。コインを変更しても、受け取るネットワークは変更されません。
完全な現実世界のタスクを測定する
HTML ドキュメントだけでは、プロキシ トラフィックの測定には不十分です。ブラウザは画像、フォント、スクリプト、API 応答をフェッチすることもあり、試行が失敗すると追加のリクエストがトリガーされる場合があります。 HTTP クライアントを使用するスクリプトは異なる動作をします。 20 ~ 30 個の代表的なアイテムに対して実際のワークフローを実行し、クライアントまたはリクエスト ログによって転送されたバイト数を記録します。
実行ごとに、処理されたアイテムの数、行われたリクエスト、および使用されたバイト数を書き留めます。合計を正常に完了した項目で割ると、結果ごとの有効な MB の数値がわかります。失敗した試行を個別に記録します。結果が生成されない場合でも、リダイレクト、ログイン ページ、および再試行によってトラフィックが消費される可能性があります。
テスト構成を実稼働環境に近い状態に保ちます。イメージがテストではブロックされているが実稼働環境ではロードされている場合、推定値は低すぎます。キャッシュ、圧縮、およびリソース ブロックの設定を記録して、後の実行を公平に比較できるようにします。
- ブラウザーで、[ネットワーク] パネルを使用して、ドキュメントの応答だけでなく、ワークフロー全体を測定します。
- スクリプトの場合は、転送、リダイレクト、失敗、再試行の両方向を含めます。
- 数回の実行にわたって測定を繰り返します。異常にスムーズな実行があったとしても、信頼できる予算とは言えません。
妥当なマージンを持ってパッケージを見積もる
まず、操作の数に成功した操作ごとに測定されたトラフィックを乗算し、次に再試行を考慮します。アイテムごとに 0.6 MB とすると、800 ページで約 480 MB が使用されます。平均して 4 回に 1 回のリクエストが繰り返されると、ブラウザーの資産、認証、ワークフローが変更されるまでの推定値は約 600 MB に増加します。
裏付けのない確実性の約束ではなく、テストで観察された範囲を使用してください。 1,000 個のアイテムが 500 ~ 650 MB を使用する場合は、両端を計算し、より高い推定値を超える余地を残します。需要が不確実な場合は、より小さなパッケージから始めて、アカウント内の実際の控除を検査し、実稼働の測定後にトラフィックを追加します。
価格帯によって GB あたりの料金が変わります。宣伝されている最低料金だけで選ぶのではなく、使用が予想される金額の合計額を比較してください。追加のギガバイトは、ワークロードで消費される場合にのみ役に立ちます。
- 基本推定値: 800 × 0.6 MB = 480 MB。
- 再試行あり: 480 MB × 1.25 ≈ 600 MB 他のリソースよりも前。
- 次のパッケージを購入する前に、最初の生産実行から再計算します。
セッションモードをワークフローに合わせる
ローテーションは、共有 ID を必要としない独立したリクエストに適しています。スティッキー セッションは、ページを開く、サインインして結果を取得するなどのいくつかのステップで同じ終了 IP を維持する必要がある場合に便利です。間違ったモードでは失敗率や再試行率が上昇し、GB あたりの料金が変わらない場合でもトラフィックが増加する可能性があります。
プロキシを構成する前に、1 つのタスクの境界を定義します。一緒に保持する必要があるステップには 1 つのセッション ID を再利用します。次の独立したタスクのために新しいタスクを開始します。通常の実行に余裕を持たせて期間を設定し、アプリケーションが Cookie と一時停止をどのように処理するかを確認します。
国の選択により、出口プールが狭まります。接続後の空き状況と実際の出口を確認します。国を選択しても、特定の都市、プロバイダー、または ASN が自動的に保証されるわけではありません。これらの設定が提供されている場合は、個別に確認してください。
注文と最初の生産実行を確認する
現在の段階価格をアカウントの見積もりと比較します。ウォレットにチャージするには、独自の支払いリクエストに示されている通貨、送金ネットワーク、金額、住所を使用します。管理者が手動で支払いを確認します。残高が入金されたら、トラフィックを購入し、公開ページの例ではなくアカウント コンフィギュレーターから接続形式を取得します。
完全に実行する前に、IP チェック サービスに対してプロキシをテストし、次に目的の宛先に対してプロキシをテストします。テスト時間、出口国、応答コード、成功率、トラフィック バランスの変化を記録します。この証拠は、認証の問題を宛先エラーや狭すぎる場所の選択から区別するのに役立ちます。
数百回の操作の後、成功した結果ごとに MB を再計算します。増加した場合は、リダイレクト、再試行、およびロードされたリソースを検査します。調査するときは、一度に 1 つの設定を変更します。そうしないと、原因を特定することが困難になります。動作が選択した構成と一致しない場合は、再現可能な小さな例をサポートに提供してください。
- 支払い前: ネットワーク、金額、GB あたりの料金、国、セッション モード。
- アクティベーション後: 認証、出口位置、目的地の応答。
- 作業中: 成功結果ごとのトラフィック、再試行率、残高。
具体例
ジョブがそれぞれ約 0.6 MB の 800 ページを開き、4 回のリクエストに 1 回を繰り返すとします。応答だけでも 600 MB に近づきます。画像、スクリプト、ブラウザのリロードによりさらに追加されます。 20 ~ 30 回の代表的な実行を測定し、エラーを許容してからトラフィック層を選択します。
よくある質問
再試行はどのように含めるべきでしょうか?
短いテストで再試行率を記録し、それを全ワークロードに適用します。ブラウザーにアクセスすると、ページ URL を超えて多くのリソースが読み込まれる可能性があります。
スティッキー セッションによって請求は変わりますか?
課金単位はGBのままです。セッション モードでは、出口 IP の動作が変更され、ワークフローが再試行する必要がある頻度が間接的に変更される場合があります。