KYC不要 — IDもセルフィーも書類も不要。暗号通貨で支払い:BTC, USDT, USDC, ETH, SOL, LTC
言語: 日本語
今すぐ始める

ドキュメント · セッション · ローテーション · キープアライブ

スティッキーセッションとIPローテーション:セッションID、TTL、接続再利用

ローテーションは接続単位、スティッキーはセッションID単位。使うライブラリが接続をどう再利用するかがわかれば、IP変更タイミングを正確に把握できます。

最終更新:

クイックアンサー

レジデンシャルプロキシでスティッキーセッションとIPローテーションはどう動く?

CrawlRelayでは、セッションIDなしのユーザー名はTCP接続ごとにプールからIPが割り当てられ、通常は違うIPです。-session-<id>-ttl-<minutes>はそのIDに対して最大30分間間IPを保持しますが、早く変わることもあります。ローテーションはHTTPリクエストではなく接続に基づくため、キープアライブがIP変更タイミングを決定します。レジデンシャルトラフィックは$0.50/GBで50GBから。KYC不要で暗号通貨払い可能です。

セッションルール概要

ローテーション単位新規TCP接続ごとにプールから別IPを割当てる
スティッキーセッションユーザー名に-session-<id>-ttl-<minutes>を付加
セッション長さ最大30分間
セッションID1~32文字の英数字で、フローごとに1つのID
セッションを早期終了させる要因背後のレジデンシャルデバイスがオフラインになること
共有ID同じIDを送信するクライアントは同じ出口を共有します
コストなし:セッションとローテーションはGB単価に含まれています

セッションIDを送信したときにゲートウェイで何が起こる?

ゲートウェイは新しい接続ごとにユーザー名を読み取ります。セッションパートがなければ、その接続に対してターゲティングに合うレジデンシャルプロキシ出口を選びます。セッションパートがあれば、設定したTTLまでそのIDに対し同じ出口を保持します。

スティッキーIPは実際の家庭用接続なので、TTL終了前に消える場合があります:デバイスの電源が切れる、Wi-Fiを失う、ネットワークが変わるなどです。長時間のフローはこれに耐える必要があり、チェックポイントで出口IPを確認し、ジョブ全体を失敗させる代わりにチェックポイントから再スタートします。

各ライブラリはどう接続を再利用する?

ライブラリが接続を維持していれば、その接続の全リクエストは同じ出口を共有します。これがそれぞれの動作を意図的に得る方法です。

ライブラリデフォルトリクエストごとに新しいIPフローごとに1つのIP
Python requestsSessionは接続を生かしますヘッダーConnection: close、またはリクエストごとに新しいSessionユーザー名にセッションIDを入れた1つのSession
httpxクライアントは接続をプールしますhttpx.Limits(max_keepalive_connections=0)セッションIDごとに1つのクライアント
aiohttpTCPConnectorは接続をプールしますTCPConnector(force_close=True)プロキシURLのユーザー名にセッションID
Scrapyプロキシ認証情報・ホストごとにプールmeta={"proxy_session": "new"}は当社のmiddlewareとフローに固定のproxy_session
Playwright / PuppeteerChromeはコンテキスト単位でプールページごとに新しいコンテキストセッションIDごとに1コンテキスト
Node.js undici, axios, gotエージェントはソケットを維持リクエストごとに新しいエージェント、あるいはkeep-aliveオフセッションIDごとに1エージェント
curlコマンドごとに1接続すでにそうなっています各コマンドで同じセッションID

どのスクレイピング案件にどのセッション戦略が適切?

案件戦略推奨TTL
独立した商品、記事、またはリスティングページ回転: セッションIDなし—
次のページがクッキーやカーソルに依存するページネーションリスティングごとに1つの固定セッション10~30分
検索→結果→詳細ページ検索ごとに1つの固定セッション10~20分
ヘッドレスブラウザで1つのサイトの複数ページをレンダリングブラウザコンテキストごとに1つの固定セッションコンテキストの寿命、最大30分
複数の都市でページの表示内容を確認都市ごとに1回の短いセッション5分
同じページを毎時再チェック回転—

Pythonで固定セッションのプールをどう管理する?

小規模なプールは安定した出口を数台で分散し、一定のリクエスト数か502や503など退出エラー検出でそれぞれを順次廃棄します。注意すべきはIPを403や429突破用に切り替えないことです。これらはサイトが速度を落とすように指示しているので、プールはコード側に例外を投げます。

Python: 固定セッションのプール
import random
import uuid

import requests

GATEWAY = "gw.crawlrelay.com:7777"
BASE_USER, PASSWORD = "USERNAME-country-us", "PASSWORD"


class SlowDown(Exception):
    """The target asked us to slow down (403 or 429): back off, do not rotate."""


class StickySession:
    def __init__(self, ttl=15, max_requests=50):
        self.id = uuid.uuid4().hex[:10]
        self.max_requests, self.used = max_requests, 0
        user = "%s-session-%s-ttl-%d" % (BASE_USER, self.id, ttl)
        proxy = "http://%s:%s@%s" % (user, PASSWORD, GATEWAY)
        self.http = requests.Session()
        self.http.proxies = {"http": proxy, "https": proxy}


class SessionPool:
    EXIT_PROBLEMS = {502, 503, 504}

    def __init__(self, size=5, **options):
        self.options = options
        self.sessions = [StickySession(**options) for _ in range(size)]

    def _replace(self, i):
        self.sessions[i].http.close()
        self.sessions[i] = StickySession(**self.options)

    def get(self, url, **kwargs):
        i = random.randrange(len(self.sessions))
        s = self.sessions[i]
        s.used += 1
        try:
            r = s.http.get(url, timeout=(10, 30), **kwargs)
        except requests.exceptions.RequestException:
            self._replace(i)  # dropped exit or timeout: start a fresh session
            raise
        if r.status_code in (403, 429):
            raise SlowDown("%s returned %d" % (url, r.status_code))
        if r.status_code in self.EXIT_PROBLEMS or s.used >= s.max_requests:
            self._replace(i)
        return r


pool = SessionPool(size=5, ttl=15, max_requests=50)
print(pool.get("https://api.ipify.org").text)

固定IPが変わったかどうかは?

問い合わせます。https://api.ipify.orgのようなIPエコーサービスを同じセッション内でフロー開始時と各チェックポイントで呼び出し結果を比較します。変わればセッションの後ろにある出口が変わったので、前のチェックポイントからやり直すか新しいセッションを開くべきです。ログにはセッションIDを記録して、デバッグ時にIP変更とサイト挙動を区別できます。

セッションのミスで一番コストがかかるのは?

  • マルチステップフローのすべてのリクエストで回転させること。 カートやカーソル、検索トークンが国をまたいで跳んでサイトがリセット。
  • 全ワーカーで同一セッションIDを使うこと。 セッションは1フロー用なのでワーカーやフローごとにIDを分ける。
  • ジョブよりずっと長いセッション継続。 2分タスクに30分TTLは無駄にIPを占有しログも読みにくい。
  • 429をIP問題と勘違いする。 新IPでもサイトルールは変わらず、速度を落とすことが必要。 429 Too Many Requests を参照。
  • リクエストごとの回転を当然と思う。 Keep-aliveは出口を維持。使うライブラリ別に上表を確認。

セッションと回転に関する質問

固定セッションはどれくらい続く?

スティッキーセッションで設定した時間(ttl、分単位、最大30分間)同じIPを維持。例外としてレジデンシャルデバイスがオフラインになると早期変更あり。。対象フローより少し長めのTTLを選び、各チェックポイントで出口を確認。

固定セッションは回転より高くつく?

いいえ。CrawlRelayはGB単位のトラフィック課金で、セッションも回転もターゲティングも料金に含まれます。固定セッションは1つのキープアライブ接続で毎回TLSハンドシェイクを省略でき、トラフィック節約にも。

すべてのリクエストで回転させるのがスクレイピングで良い?

独立ページなら回転は負荷分散になり、1IPで何時間も1サイトにアクセスするのを防げます。クッキーに紐づくページネーションなど状態を持つものはフローが壊れます。ほとんどのクロールは両方混在:アイテム間で回転・フロー内は固定。

正確なIPを選べる?

できません。レジデンシャルゲートウェイがリアルタイムで変わるプールから出口を割り当て、ユーザー名のターゲティングにマッチします。国、都市、米国州、ZIPコード、ASNは選べます。IPをセッションで維持はできますが特定のアドレスを予約することはできません。

回転とセッションは全プランに含む

$1.50は1 GB、$0.50/GBは50 GBから。

$0.50/GBから · KYC不要

今すぐ始める