長時間セッションと永続ログインのための最適なISPプロキシ設定

数時間に及ぶセッションとログイン状態を維持するためのISPプロキシの設定方法: アカウントごとに1つのIP、永続的なプロファイル、そして最初にエグジットチェックを行う

ローテーティングレジデンシャルプロキシは規模に対応するために作られている。リクエストごとに新しいIPを使うか、最長30分のスティッキーセッションを使うかのどちらかだ。しかし、これはまったく異なる種類の作業には不向きだ。アカウントに一日中ログインし続けること、チェックアウトや監視セッションを何時間も維持すること、あるいは毎回同じ場所からストアの出品者アカウントを管理することなどだ。こうした用途では、サイトは一貫した一人の訪問者を期待しており、IPが変わると乗っ取られたセッションのように見えてしまう。

ISPプロキシはこのために作られている。各プロキシは、選択した都市とインターネットプロバイダーに、課金期間全体を通じてとどまる。しかし、優れたプロキシはセットアップの半分に過ぎない。残り半分は、セッションに関する他のすべてが同じように一貫していることを確認することだ。このガイドでは、私たちが顧客に推奨するセットアップを、応用できるコードとともに解説する。

ローテーティングプロキシの代わりにISPプロキシが必要な場合

作業内容	使用するもの
多数のサイトから多数のページを収集する	ローテーティングレジデンシャルプロキシ
30分以内に完了する複数ステップのフロー	レジデンシャルスティッキーセッション
何時間も続けなければならないセッション	ISPプロキシ
自分のアカウントに毎日ログインし続ける	ISPプロキシ
特定の都市とプロバイダーからサイトがどう見えるかを確認する	ISPプロキシ

30分という線引きは実用的なものだ。Shifterのレジデンシャルスティッキーセッションは最長30分続く。それより長く続くもの、あるいは翌日同じアカウントに戻ってくるものは、ISPプロキシを使うべきだ。

ShifterのISPプロキシの仕組み

配置する各IPには専用のユーザー名が割り当てられ、プラン内のすべてのユーザー名は1つのパスワードを共有する。
すべてのプロキシは同じホストとポート isp.shifter.io:443 を通じて、HTTP(S)またはSOCKS5で接続する。
配置時に、各IPの**都市とISP(ASN)**を120か国の中から選択できる。
各プロキシは、プランが有効である限り、その都市とISPを維持する。
背後にあるIPアドレスは時間とともに更新されることがある。これは、自宅のブロードバンド回線がプロバイダーから時折新しいアドレスを受け取るのと同じ仕組みだ。都市とプロバイダーは変わらない。
帯域幅は無制限で、プランはIP単位で価格設定されている。

最後から2番目のポイントは、永続的なログインにとって重要だ。セットアップは、アドレスが時折変化することを前提とし、変わらないもの、つまり場所、プロバイダー、ブラウザプロファイルに依拠すべきだ。

5つのルールによるセットアップ

1. アカウントごとに1つのプロキシを使い、決して共有しない。 すべてのアカウントに専用のISPプロキシのユーザー名を割り当て、そのペアリングを固定する。1つのIPに2つのアカウントがあると関連付けられているように見え、1つのアカウントが複数のIPにまたがると、異なる場所からアクセスされているように見える。

2. 各IPを、アカウントが実際に存在する場所に配置する。 アカウントがシカゴの店舗に属している場合、そのIPをシカゴのプロバイダーに配置する。正しい都市からのログインとレジデンシャルプロバイダーは、アカウントの通常の行動パターンのように見える。

3. アカウントごとに永続的なブラウザプロファイルを維持する。 Cookie、ローカルストレージ、保存されたセッションがログイン状態を維持する要素だ。これらをアカウントごとのプロファイルディレクトリに保存し、毎回再利用する。実行のたびに新しいブラウザを使うということは、実行のたびに新規ログインを行うということであり、それがまさに確認プロンプトを引き起こす原因になる。

4. ブラウザをプロキシと一致させる。 タイムゾーンと言語は、出口の場所と一致させるべきだ。最も簡単な方法は、出口に自分の場所を尋ね、その回答に基づいてブラウザを設定することだ。プロキシの地理、タイムゾーン、ロケールを一致させるガイドで、シグナルの全リストを解説している。

5. 開始する前に出口を確認する。 アカウントを開く前に、プロキシが想定している都市と想定しているプロバイダー上にあることを確認する。そうでない場合は、間違った場所からログインするのではなく、停止する。

コード

以下のモジュールは、PythonとPlaywrightを使ってこの5つのルールを実践する。アカウントとプロキシのマッピングを検証し、ip-info.com(無料のIPジオロケーションAPI)を通じて出口を確認し、出口自体から取得したタイムゾーンを用いて、そのアカウントのプロキシに固定された永続的なブラウザプロファイルを開く。

from pathlib import Path

import requests

ISP_GATEWAY = "isp.shifter.io:443"


def validate_assignments(accounts):
    """One ISP proxy per account, and no proxy shared between accounts."""
    problems, seen_accounts, owner = [], set(), {}
    for a in accounts:
        if a["account"] in seen_accounts:
            problems.append(f"{a['account']}: listed twice")
        seen_accounts.add(a["account"])
        other = owner.setdefault(a["isp_username"], a["account"])
        if other != a["account"]:
            problems.append(f"{a['isp_username']}: shared by {other} and {a['account']}")
    return problems


def check_exit(account, password, get=requests.get):
    """Ask the exit where it is, and compare with where this account belongs."""
    proxy = f"http://{account['isp_username']}:{password}@{ISP_GATEWAY}"
    info = get("http://ip-info.com/json", proxies={"http": proxy, "https": proxy}, timeout=20).json()
    problems = []
    if info.get("city") != account["city"]:
        problems.append(f"city is {info.get('city')}, expected {account['city']}")
    if info.get("asn") != account["asn"]:
        problems.append(f"ASN is {info.get('asn')}, expected {account['asn']}")
    return {"ip": info.get("ip"), "timezone": info.get("timezone"), "problems": problems}


def browser_options(account, password, exit_info, profile_root):
    """Persistent Chromium profile for one account, pinned to its own ISP proxy."""
    return {
        "user_data_dir": str(Path(profile_root) / account["account"]),
        "proxy": {"server": f"http://{ISP_GATEWAY}",
                  "username": account["isp_username"], "password": password},
        "timezone_id": exit_info["timezone"],
        "locale": account["locale"],
        "viewport": {"width": 1440, "height": 900},
    }


def open_account(playwright, account, password, profile_root="profiles"):
    """Check the exit first; only then open the account's own browser profile."""
    exit_info = check_exit(account, password)
    if exit_info["problems"]:
        raise RuntimeError(f"{account['account']}: " + "; ".join(exit_info["problems"]))
    options = browser_options(account, password, exit_info, profile_root)
    return playwright.chromium.launch_persistent_context(**options)

それを使う例:

import os

from playwright.sync_api import sync_playwright

from isp_sessions import open_account, validate_assignments

ACCOUNTS = [
    {"account": "store-us", "isp_username": "us-chicago-illinois-as7922-XXXXX",
     "city": "Chicago", "asn": 7922, "locale": "en-US"},
    {"account": "store-de", "isp_username": "de-berlin-berlin-as3320-XXXXX",
     "city": "Berlin", "asn": 3320, "locale": "de-DE"},
]
password = os.environ["ISP_PASSWORD"]

problems = validate_assignments(ACCOUNTS)
if problems:
    raise SystemExit("\n".join(problems))

with sync_playwright() as p:
    browser = open_account(p, ACCOUNTS[0], password)
    page = browser.pages[0] if browser.pages else browser.new_page()
    page.goto("https://example.com/account")
    # ... the account's work; cookies and storage persist in profiles/store-us
    browser.close()

XXXXX の部分は、プランページに記載されているユーザー名に置き換える。プランページには、各ユーザー名とその都市・ISPがすべて記載されている。プロファイルディレクトリ(この例では profiles/store-us)は、実行間でアカウントのログイン状態を維持するものだ。これをバックアップし、2つのアカウントを同じディレクトリに向けないようにする。

マッピングのチェック、(記録済みのレスポンスに対する)出口のチェック、そしてPlaywrightのChromiumによるブラウザオプションをテストした。実際のプロキシに対して出口のチェックを実行するには、有効なISPプランが必要だ。

何時間もセッションを維持する

一定の、人間らしいペースを保つ。 アカウント内の人間はクリックし、読み、待つ。1分間に何百もの操作をまとめて行うと、プロキシがどれほど優れていても自動化されているように見える。
開いたブラウザを再利用する。 タスクごとに再起動するのではなく、作業セッションの間は1つのブラウザを開いたままにする。
長い中断の後は出口を再確認する。 数時間後に再開する場合は、出口のチェックを再実行する。アドレスが更新されることがあるため、サイトが時折ログインの確認を求めることがある。同じ都市、プロバイダー、プロファイルであれば、それは実際のユーザーが自宅のルーターが再起動した後に経験するのと同じことだ。
問題を解決するためにアカウントを別のプロキシに切り替えない。 アカウントがチャレンジを受けた場合、異なる都市やプロバイダーに変えると事態は悪化する。原因を修正し、ペアリングは維持する。

トラブルシューティング

症状	考えられる原因	対処法
`407 Proxy Authentication Required`	ユーザー名またはパスワードの誤り	プランページから認証情報を再度コピーする。各IPには専用のユーザー名がある
出口のチェックで間違った都市が報告される	ユーザー名が別の配置に属している	プランページのリストに対してユーザー名を確認する
実行のたびにログアウトされる	毎回新しいブラウザプロファイルを使っている	アカウントごとに永続的なプロファイルディレクトリを使用する
確認プロンプトが繰り返し表示される	タイムゾーンまたは言語が出口と一致していない、またはアカウントがプロキシ間で移動した	出口の場所からブラウザを設定し、アカウントごとに1つのプロキシを維持する
1つのIPからのリクエストが遅い、または失敗する	その配置に問題がある	ドキュメントの接続チェックを実行し、ユーザー名とともにサポートに連絡する

アカウントを責任を持って使用することについての注意

これらの技術は、使用する権利のあるアカウント、すなわち自分自身のビジネスアカウント、許可を得たクライアントのアカウント、そして自社サービスのテストアカウントのためのものだ。すべてのプラットフォームには、自動化や、1人または1企業が運用できるアカウント数に関する独自のルールがある。一貫したセットアップは、正当な作業がフラグ付けされることを防ぐものであり、プラットフォームのルールを回避する手段ではなく、そのように使うべきでもない。

よくある質問

長いセッションにローテーティングレジデンシャルプロキシを使えるか?

ある程度までは可能だ。Shifterのレジデンシャルスティッキーセッションは最長30分続く。それより長く続くセッション、あるいは毎日戻ってくるログインには、課金期間全体を通じて都市とISPを維持するISPプロキシを使用する。

ISPプロキシのIPアドレスは変化することがあるか?

プランが有効である間、都市とISPは固定されている。プロキシの背後にあるIPアドレスは、自宅のブロードバンド回線のように時間とともに更新されることがある。セットアップは、変わらないもの、すなわち場所、プロバイダー、永続的なブラウザプロファイルを中心に構築する。

1つのISPプロキシをいくつのアカウントで共有すべきか?

1つだ。各アカウントが別々の世帯のように見え、どの2つのアカウントも関連付けられて見えないように、各アカウントに専用のプロキシを割り当てる。

永続的なブラウザプロファイルは必要か?

ログインにおいては必要だ。プロファイルは、サインイン状態を維持するCookieとストレージを保持する。これがないと、実行のたびに新しいデバイスとして開始することになり、確認を求められる可能性がはるかに高くなる。

結論

長いセッションと永続的なログインに必要なのは、ローテーションではなく一貫性だ。各アカウントに、そのアカウントの実際の都市に配置された専用のISPプロキシを割り当て、アカウントごとに1つの永続的なブラウザプロファイルを維持し、出口からブラウザのタイムゾーンと言語を設定し、開始のたびに出口を確認する。これらが整っていれば、アカウントは毎日同じように見える。それこそがサイトが確認しているすべてだ。ISPプロキシとレジデンシャルプロキシの比較記事では、両者のより広い選択肢について解説している。