ベストプラクティス

Shifterがプロジェクトに適しているかを知る最も速い方法は、本番環境で実行するのと同じリクエストによる実際のワークロードを実行し、その結果を正直に読み取ることです。以下のプラクティスは、誤解を招く結果ではなく、クリーンで代表的なテストを得るのに役立ちます。

タスクに合わせてローテーションを選ぶ

IPをどうローテーションするかは、タスクが必要とするものに従うべきです。

リクエストごとのローテーション(デフォルト): ゲートウェイ p.shifter.io:443 を経由するすべてのリクエストで新しいレジデンシャルIPが割り当てられます。スクレイピング、クロール、価格収集、SERP作業、および各リクエストが単独で成立するあらゆる用途に最適です。
スティッキーセッション: セッションID(sid)と存続時間(ttl)を使用して、一定の期間同じIPを保持します。ログイン、カート、チェックアウトなど、1つのIPに留まる必要がある複数ステップのフローに最適です。例えば、customer-USERNAME-sid-9f3a2b7c-ttl-600 は約600秒間1つのIPを保持します。

原則として、各ステップが互いに依存している場合はセッションを使用し、依存していない場合はローテーションを使用します。詳細はセッションを参照してください。

多くのサイトはロケーションによってコンテンツ、価格、または在庫状況を変えます。

ターゲットが位置情報に敏感な場合は、国、地域、都市、またはASNでターゲティングし、テストがその市場の実際のユーザーが目にするものを反映するようにしてください。例えば、customer-USERNAME-country-us-state-newyork-city-newyork のようにします。
用途にとってロケーションが重要でない場合は、ターゲティングを広く保ってください。過度に絞り込むと、利用可能なIPプールが縮小し、成功率が低下する可能性がありますが、それに見合うメリットはありません。

すべてのパラメータについてはジオターゲティングを参照してください。

負荷を分散させることが、通常、強いテストと弱いテストの違いになります。

1つのターゲットに集中して負荷をかけるのではなく、時間とIPにわたってリクエストを分散させてください。リクエストごとのローテーションでは、すでにIPが変動するため、主なレバーは同時実行数とタイミングです。
控えめな同時実行数から始め、成功率を確認しながら段階的に引き上げてください。負荷を強めるにつれて成功率が下がる場合、それはプロキシの制限に達しているのではなく、そのターゲットに対して速度を出しすぎていることを意味します。
小さくばらつきのある遅延を加え、失敗したリクエストは新しいIPで再試行してください。ローテーションを使用していれば、再試行は自然に別の出口IPに割り当てられるため、ブロックはソフトなシグナルとして扱い、速度を落とし、再試行して続行してください。

誤った製品を選ぶことが、トライアルが期待通りの成果を出さない最も一般的な理由です。

レジデンシャルプロキシ: ローテーティングするレジデンシャルIPにより、トラフィックが多数の実際のユーザーのように見えます。スクレイピング、モニタリング、広告検証、市場調査、SERP収集に向いています。
ISPプロキシ: 同じ専用IPを数日から数週間使用します。アカウント管理、長時間のチェックアウトやログインセッション、ホワイトリスト登録されたIPを使う連携に向いています。

判断に迷う場合は、製品を選ぶを参照して進めてください。

数回のテスト呼び出しではなく、実際の数値で判断してください。

本番相当のボリュームでの成功率とデータ品質を確認してください。少数の失敗は正常であり、重要なのは大規模時の割合です。
ipinfo.io のようなIPエコーエンドポイントにプロキシ経由でリクエストを送り、IPと国を確認することで、出口が意図通りであることを確認してください。
結果がおかしいと感じたら、ネットワークを疑う前に次の3点を確認してください。ローテーションかセッションかがタスクに合っているか、ターゲットのロケーションが正しく設定されているか、同時実行数が高すぎないか、です。

テストがトラフィック、ターゲット、タイミングの面で本番環境をより忠実に反映するほど、トライアルから得られる知見は多くなります。実際の状況に近づけてセットアップすれば、判断はおのずと明らかになります。