ベストプラクティス

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に割り当てられるため、ブロックをソフトなシグナルとして扱い、少し待ってから再試行を続けてください。

誤った製品を選ぶことが、トライアルの結果が振るわない最も一般的な原因です。

Residential Proxies: ローテーティングレジデンシャルIPを使用するため、トラフィックは多数の実際のユーザーのように見えます。スクレイピング、モニタリング、広告検証、市場調査、SERP収集に向いています。
ISP Proxies: 請求期間全体を通じて同じ都市・同じISP（ASN）を維持します。アカウント管理、長時間のチェックアウトやログインセッション、特定の都市・ISPからの広告チェックに向いています。

迷った場合は製品の選び方を参照してください。

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

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

テストがトラフィック、ターゲット、タイミングの点で本番環境をより忠実に再現するほど、トライアルから得られる情報も多くなります。実際の運用に近い形でセットアップすれば、判断はおのずと下せるようになります。