同じプロキシが IP アドレスを 1 秒、1 分、または 30 分間保持することができ、これはあなたのアカウントが禁止されるかどうかに直接影響します。多くのアービトラージャーや SMM 専門家は、デフォルト設定をそのまま使用し、Facebook Ads には特定のローテーションのロジックが必要であり、Wildberries のデータ収集には全く異なるロジックが必要であることを理解していません。この記事では、特定のタスクに応じたスティッキーセッションの長さを選択し、アカウントやサイトへのアクセスを失わない方法を解説します。
スティッキーセッションとは何か、どのように機能するか
スティッキーセッションとは、特定の時間（1 分、10 分、30 分、またはそれ以上）にわたって同じ IP アドレスに固定されるプロキシの動作モードです。セッションがアクティブな間、すべてのリクエストは同じ IP から送信されます。時間が経過すると、システムはプールから新しいアドレスを割り当てます。これは、リクエストごとに IP が変更される「リクエストごとのローテーション」とは対照的です。
これはなぜ必要なのでしょうか？たとえば、Instagram にログインした後、5 秒後にフィードの読み込みリクエストが別の国の別の IP から来た場合、プラットフォームには疑わしい活動として見えます：1 つのアカウントで、数秒の間に 2 つの異なる「位置」があります。スティッキーセッションはこの問題を解決します。これは、インターネットプロバイダーからの 1 つの IP を持つ通常のユーザーの行動を模倣します。
レジデンシャルプロキシとモバイルプロキシは通常、1 分から 1 時間以上までのスティッキーセッションの柔軟な設定をサポートしています。データセンタープロキシは、ローテーションなしで静的 IP で動作することが多いため、セッションの長さに関する問題はあまり重要ではありません。レジデンシャルプロキシを使用している場合、ログインのパラメータや管理パネルを介して IP の固定時間を手動で設定する機会がほぼ常にあります。
重要なのは、セッションの長さは単なる技術的な設定ではなく、行動を模倣するためのツールであるということです。セッションが短すぎると「1 人のユーザー」のロジックが崩れ、長すぎると、同じアドレスが異なるタスクでアクティブな間にプラットフォームのブラックリストに載るリスクが高まります。
短いセッション (1 分): いつ必要か
約 1 分のセッションは、アドレスの変更速度が重要であり、「生きている」ユーザーの模倣が必要ない場合に適しています。典型的な例は、マーケットプレイスでの価格のデータ収集です。Wildberries や Ozon の数千の商品のデータを収集する際、各リクエストは本質的に独立しており、すべてのリクエストを 40 分間連続してカタログを閲覧する 1 人の人間が行っているかのように「装う」必要はありません。
1 分の短いローテーションは、1 つの IP が短時間に過剰なリクエストを送信し、サイトのレート制限保護に引っかかるリスクを低減します。外部のパーサー（価格監視用の既製の SaaS ソリューション）を使用している場合、1 分のセッションは、アドレスプールに均等に負荷を分散させるための最適なオプションです。
また、1 分のセッションは、さまざまな地域の Avito での広告の可用性を大量に確認する場合や、Google Ads プレビュー ツールを使用して異なる都市での広告の表示を迅速に確認する場合にも役立ちます。ここでは、各確認が一回限りの操作であり、必要以上に 1 つの IP を保持する意味はありません。
1 分のセッションを選ぶべき時: マーケットプレイスのカタログのデータ収集、さまざまな地域での広告の確認、認証なしでのデータ収集、一時的な API リクエストでクッキーにセッションを保存しない場合。
中程度のセッション (10 分): ユニバーサルバランス
10 分のスティッキーセッションは、実質的に「黄金の中間」であり、大多数のアービトラージャーが広告アカウントのウォーミングアップや日常業務に選択するものです。この長さは、Facebook Ads のダッシュボードにアクセスし、統計を確認し、クリエイティブを編集し、変更を保存するなどの論理的な一連のアクションを実行するのに十分であり、同時に IP がアカウントに長時間「滞留」しないため、複数のプロファイルを同時に操作する際に重要です。
Dolphin Anty や AdsPower のアンチデテクトブラウザを介して 20 ～ 30 の Instagram および TikTok アカウントを管理する SMM 専門家にとって、10 分のセッションは典型的なシナリオに適しています：ログインしていくつかの投稿に「いいね」を付け、コメントし、ログアウトします。アクションのセッションが 5 ～ 8 分かかり、IP の固定が 10 分間続く場合、アカウントは 1 つのアドレスからの論理的な継続的な活動を認識します。これは、実際の人間の行動です。
中程度のセッションのもう 1 つの利点は、長いセッションと比較して IP アドレスプールへの負荷を軽減することです。特定の都市でのモバイル IP の数が限られている場合に 15 のアカウントを同時に操作する必要がある場合、10 分のローテーションは、アドレスをより頻繁に解放し、異なるプロファイルに再利用することを可能にし、時間の重複のリスクを回避します。
10 分のセッションは、モバイルプロキシで最も一般的に使用されます。これらは、プロバイダーの動的な IP の性質により、ブロックされることが少なく、セッションの適度な長さは、Facebook や TikTok のアルゴリズムからの疑念の可能性をさらに低下させます。
長いセッション (30 分以上): どのようなタスクに適しているか
30 分以上のセッションは、「完全なオンラインセッション」の模倣がタスクの成功にとって重要な場合に必要です。新しい Facebook または Instagram アカウントのウォーミングアップはその典型的な例です。アカウントの初期の数日間、プラットフォームは行動パターンを特に注意深く監視しており、長時間のフィード閲覧中に IP が数分ごとに変更されると、非常に疑わしく見えます。
Facebook Ads や TikTok Ads での広告キャンペーンを開始する際、長いセッションは余計なトリガーなしでモデレーションの段階を通過するのに役立ちます。ダッシュボードにアクセスし、キャンペーンを設定し、クリエイティブをアップロードし、オーディエンスを確認するなど、このプロセスは 20 ～ 40 分かかる可能性があり、その間 IP が通常のマーケティング担当者のように変わらないことが理にかなっています。
銀行や決済サービスに関連する広告アカウントを操作する際にも、長いセッションは重要です。カードの操作中に IP を変更すると、ほぼ確実に追加の確認や一時的な凍結が発生します。Facebook Ads Manager にカードをリンクしたり、決済システムの個人アカウントを介して残高を確認したりする場合は、30 ～ 60 分のセッションを保持して、余分なセキュリティフラグを避けるのが良いでしょう。
長いセッションの欠点は、集中的に作業していると、同じ IP がより多くのアクションに「露出」し、プラットフォームがそのアドレスの行動を分析するためのデータが増えることです。したがって、長いセッションは特定の敏感な操作のために選択的に使用し、すべてのタスクのデフォルト設定として使用するべきではありません。
表: どのタスクにどのセッションの長さが適しているか
以下は、アービトラージャー、SMM 専門家、およびマーケットプレイスの販売者の一般的なタスクに対するスティッキーセッションの推奨長さをまとめた表です。
| タスク | 推奨セッションの長さ | プロキシの種類 |
|---|---|---|
| Wildberries/Ozon の価格のデータ収集 | 1 分 | データセンタープロキシ |
| 地域ごとの広告の確認 | 1-3 分 | レジデンシャルプロキシ |
| Instagram/TikTok アカウントの管理 | 10 分 | モバイルプロキシ |
| Facebook Ads のダッシュボードの操作 | 10-30 分 | レジデンシャル / モバイルプロキシ |
| 新しいアカウントのウォーミングアップ | 30-60 分 | レジデンシャルプロキシ |
| カードのリンク / 支払い | 30-60 分 | レジデンシャルプロキシ |
| Avito での広告の掲載 | 10-20 分 | モバイルプロキシ |
アンチデテクトブラウザでのスティッキーセッションの設定
スティッキーセッションの長さは、プロキシの接続文字列のパラメータを介して設定することができます（通常はログインの一部、たとえば user-session-abc123-sessTime-10 など）または、プロバイダーの管理パネルを介して、視覚的なインターフェースで長さを選択することができます。
Dolphin Anty では、プロキシの設定は各プロファイルごとに行います：プロファイルを開く → 「プロキシ」セクション → 接続データを入力し、IP の固定時間を設定する session パラメータを含める → 保存して、内蔵のチェックツールで IP を確認します。クライアントの複数のアカウントを管理している場合、異なるアクティビティを持つアカウントに対して異なるセッションの長さを設定することが重要です。たとえば、コンテンツを公開するためのアカウントは 10 分のセッションで維持し、広告ダッシュボードの設定を行うアカウントは 30 分のセッションで維持します。
AdsPower でも同様のロジックです：プロファイル設定セクション → 「プロキシ」 → 種類の選択 (HTTP/SOCKS5) → ホスト、ポート、ログイン、パスワードを入力し、セッションパラメータを指定します。GoLogin や Multilogin も、ローテーションのパラメータを含む接続文字列の手動入力をサポートしています。セッションパラメータの構文はプロキシプロバイダーによって異なる場合があるため、具体的なプロバイダーのドキュメントを確認することが重要です（どこでは session、どこでは sessTime、どこではログインの別の数値サフィックスです）。
スティッキーセッションが実際に機能していることを確認するのは簡単です：設定されたプロキシを使用してブラウザで IP チェックサイト（たとえば、ip-info サービス）を開き、30 秒後にページを更新します。IP は同じであるべきです。セッションの長さを超える時間が経過した後にもう一度更新します。IP は変更されるべきです。もしアドレスが早すぎる段階で変更される場合、パラメータが正しく渡されていないか、プロバイダーが選択した長さをサポートしていない可能性があります。
セッションの長さを選ぶ際の一般的な間違い
最初の、そして最も一般的な間違いは、すべてのタスクに対して同じセッションの長さを使用することです。アービトラージャーは、データ収集とアカウントのウォーミングアップが根本的に異なるローテーションのロジックを必要とすることを忘れて、1 つのプロジェクトから別のプロジェクトに設定をコピーすることがよくあります。
2 番目の間違いは、高いアクティビティの中での長すぎるセッションです。もし 30 分のセッションの間に 1 つの IP から 1 分間に 200 のリクエストを行うと、プラットフォームはセッションの時間が経過する前に異常な活動を検出し、ロックが発生します。
3 番目の間違いは、支払いまたは認証を通過するなどの重要な操作中に短すぎるセッションです。カード情報を入力している最中に IP を変更すると、ほぼ確実に決済システムがトランザクションを疑わしいものとしてブロックします。
4 番目の間違いは、プロキシプロバイダーの制限を無視することです。すべてのサービスが 10 ～ 30 分を超えるセッションをサポートしているわけではなく、60 分のパラメータを指定しても、プロバイダーが物理的に 10 分ごとに IP をローテーションしている場合、予測不可能な動作が発生し、アンチデテクトブラウザで存在しない問題を探すために時間を浪費します。
5 番目の間違いは、スケーリング時に設定を見直すことを忘れることです。10 分のセッションで 5 つのアカウントに対して機能していたものが、同じ IP プールで 50 のアカウントに対しては機能しない可能性があります。ローテーションの強度が選択した IP プールに対して十分に大きくない場合、アドレスの重複や衝突のリスクが高まります。
結論
スティッキーセッションの長さは、二次的な技術的詳細ではなく、アカウントの生存率やデータ収集の安定性に影響を与える重要なパラメータの 1 つです。1 分の短いセッションは、認証なしでのデータ収集に適しており、10 分の中程度のセッションはアカウントや広告ダッシュボードの管理にユニバーサルなオプションであり、30 分以上の長いセッションは、ウォーミングアップ、支払い、その他の操作に必要です。これらの操作では「1 人のユーザー」の継続性が重要です。
複数のタイプのタスクを同時に操作している場合（たとえば、Facebook Ads の広告ダッシュボードを管理し、同時に Wildberries の競合の価格を監視している場合）、異なるプロファイルに対して異なるセッション設定を組み合わせることを恐れないでください。アカウントの管理やウォーミングアップには、セッションの長さを柔軟に設定できるレジデンシャルプロキシが適しており、大量のページを迅速にパースするには、短いローテーションとリクエスト間の最小遅延を持つプロキシが適しています。デフォルトではなく、特定のタスクに応じてセッションの長さを選択し、ブロックの数を大幅に減らしましょう。