SeleniumとPlaywrightのどちらをレジデンシャルプロキシ経由の作業に選ぶか、あるいは両方を維持するか検討している場合、役に立つのは二つの別々のセットアップガイドではなく比較です。何が同じで、何が本当に違うのか、そしてどの違いが構築方法に影響すべきかです。ここでは同じ作業をそれぞれで行い、並べて示します。
各フレームワークごとのより深い詳細、それぞれが持つエッジケースについては、SeleniumでのレジデンシャルプロキシとPlaywrightでのレジデンシャルプロキシを参照してください。これはその上に重なる比較のレイヤーです。
同一なもの：ゲートウェイ
どちらのフレームワークも同じエンドポイントに同じ認証情報で話しかけます。プロキシは何がそれを操作しているかを気にしないからです。ホストはp.shifter.io、ポートは443、そしてすべてのターゲティングはユーザー名にエンコードされます。
customer-USERNAME # rotate, no geo
customer-USERNAME-country-de # German exit
customer-USERNAME-country-us-city-new_york # city level
customer-USERNAME-country-de-sid-abc123-ttl-600 # sticky, ten minutesつまり、地理、ローテーション、セッション寿命に関するすべての決定は文字列であり、両フレームワークで同一です。以下のセクションの内容はゲートウェイを何一つ変更せず、変わるのは各フレームワークが認証情報をどう渡すかだけです。フォーマットのリファレンスは接続方法にあります。
唯一の本質的な違い：認証
これが重要な違いであり、人々がつまずく摩擦の大部分を説明しています。
Playwrightはネイティブに認証付きプロキシをサポートします。 ユーザー名とパスワードは第一級のオプションであり、すぐに動作します。
Seleniumはそうではありません。 プロキシのホストとポートは設定できますが、WebDriver仕様には認証情報を渡す仕組みがないため、Chromeはスクリプトが閉じられないネイティブの認証ダイアログを表示します。Seleniumのあらゆる解決策はこのギャップに対する回避策であり、三つあります。認証情報を代わりに処理するSelenium Wire、それらを供給する小さな生成済みChrome拡張機能、あるいはブラウザのデバッグプロトコルを直接操作するCDPです。
新規に始めていて作業に認証付きプロキシが必要な場合、その違いだけでもPlaywrightを選ぶ正当な理由になります。
両方で同じセットアップ
Playwright、Python：
from playwright.sync_api import sync_playwright
USER = "customer-USERNAME-country-de-sid-abc123-ttl-600"
with sync_playwright() as p:
browser = p.chromium.launch()
context = browser.new_context(
proxy={"server": "http://p.shifter.io:443",
"username": USER, "password": "PASSWORD"},
locale="de-DE", timezone_id="Europe/Berlin", # match the exit
)
page = context.new_page()
page.goto("https://ipinfo.io/json")
print(page.inner_text("body"))Playwright、Node：
const ctx = await browser.newContext({
proxy: { server: 'http://p.shifter.io:443',
username: 'customer-USERNAME-country-de-sid-abc123-ttl-600',
password: 'PASSWORD' },
locale: 'de-DE', timezoneId: 'Europe/Berlin',
});Selenium、Python、Selenium Wireを使用：
from seleniumwire import webdriver
USER = "customer-USERNAME-country-de-sid-abc123-ttl-600"
proxy_url = f"http://{USER}:PASSWORD@p.shifter.io:443"
opts = {"proxy": {"http": proxy_url, "https": proxy_url,
"no_proxy": "localhost,127.0.0.1"}}
driver = webdriver.Chrome(seleniumwire_options=opts)
driver.get("https://ipinfo.io/json")
print(driver.find_element("tag name", "body").text)同じゲートウェイ、同じユーザー名、同じ結果です。違いは認証情報がどう入るかだけです。
構造的な違い：どうやってアイデンティティを分離するか
これは実際に設計を形作るべき違いであり、それぞれのフレームワークで分離されたアイデンティティにどれほどのコストがかかるかから生じています。
Playwrightでは、コンテキストは軽量です。 ブラウザコンテキストは独自のCookie、ストレージ、そして重要なことに独自のプロキシを持つ分離されたプロファイルです。一つのブラウザプロセスを実行し、アイデンティティごとにコンテキストを作成できるため、地理やセッションをローテーションすることは新しいブラウザではなく新しいコンテキストを作成する問題になります。
browser = p.chromium.launch() # one process
for country in ["de", "fr", "us"]:
ctx = browser.new_context(proxy={"server": "http://p.shifter.io:443",
"username": f"customer-USERNAME-country-{country}",
"password": "PASSWORD"})
page = ctx.new_page()
page.goto("https://example.com")
ctx.close() # identity discarded, process staysSeleniumでは、プロキシはドライバーに紐づいています。 それを変更するには一般に新しいドライバーが必要で、ドライバーは丸ごとブラウザプロセスです。起動が遅く、メモリを多く消費します。そのためSeleniumのパターンは逆で、一つのアイデンティティで一つのドライバーを多くのリクエストに再利用し、アイデンティティの変更をリクエストごとにではなくまとめて行う高コストな操作として扱います。
実際上の帰結は、多くの短命なアイデンティティを必要とする作業はPlaywrightの方が明らかに安上がりであり、一つのアイデンティティを長い一連の処理で保持する作業はどちらでも構わないということです。Seleniumを使っていてリクエストごとにドライバーを起動していることに気づいたら、それが最初に修正すべきものであり、プロキシ設定ではありません。
地理、ローテーション、セッション
ターゲティングはユーザー名の中にあるため、この部分はフレームワークに依存しません。sidを省略すれば新しい接続ごとに新しい出口が得られ、含めれば同じアドレスがTTLが切れるまで保持されます。Playwrightではそれをコンテキストごとにスコープし、Seleniumではドライバーごとにスコープします。
両方で正しく行うべきこと：国を設定するときは、ブラウザのロケールとタイムゾーンをそれに合わせてください。ドイツの出口がニューヨークのタイムゾーンを報告するのは検出しやすく、避けやすい矛盾であり、両フレームワークともこれらをコンテキストオプションとして公開しています。詳細は地理、タイムゾーン、ロケールの一致を参照してください。
帯域幅：両フレームワークが共有するコスト
ブラウザはGBあたりの課金という点でコストがかかります。本物のブラウザが取得するもの、画像、フォント、メディア、アナリティクスをすべて取得するからです。必要のないものをブロックすることが利用可能な単一の最大の節約であり、両フレームワークともそれをサポートしています。
Playwright：
context.route("**/*", lambda route: route.abort()
if route.request.resource_type in {"image", "media", "font", "stylesheet"}
else route.continue_())Seleniumにはバニラの形での同等の一行はありません。Selenium Wireでリクエストをフィルタリングするか、CDP経由でリソースタイプをブロックできます。いずれにせよやる価値があります。ページの重さを大幅に削減することが一般的だからです。ブラウザが本当に必要かどうかを含む広い議論はヘッドレスブラウザが必要な時とプロキシの帯域幅コスト削減にあります。
両方で動作を確認する
プロキシが適用されていると仮定しないでください。アドレスを報告するエンドポイントにナビゲートし、それが自分のものでないことを確認します。
# Playwright
page.goto("https://ipinfo.io/json"); print(page.inner_text("body"))
# Selenium
driver.get("https://ipinfo.io/json"); print(driver.find_element("tag name", "body").text)アドレスが自分自身のものであれば、プロキシはまったく適用されていません。アドレスは正しいがコンテンツがその地域にとって間違っている場合は、プールを疑う前にDNSやロケールの不一致を疑ってください。詳細はDNSリークの防止を参照してください。
どちらを選ぶか
既存のコミットメントがなく、作業に認証付きプロキシと多数のアイデンティティが関わる場合、Playwrightがより簡単な道です。ネイティブの認証情報サポートとコンテキストごとの軽量な分離が、そうでなければ回避策を設計しなければならない二つの問題を取り除きます。
Seleniumは、すでにSeleniumの資産がある場合、そのグリッドとクロスブラウザのエコシステムが必要な場合、あるいは作業が多くの短いセッションではなく一つの長寿命セッションである場合に、妥当な選択肢であり続けます。プロキシのサポートは完全に機能しますが、認証情報を入れるためにライブラリか小さな拡張機能のコストがかかるだけです。
そしてどちらの場合も、ブロックされないことの半分はブラウザにすぎないことを忘れないでください。アドレスはドアまで連れて行ってくれますが、ヘッダー、フィンガープリント、ペーシングが次に何が起こるかを決めます。詳細はブロックを避けるを参照してください。
結論
ゲートウェイは両フレームワークで同一であるため、地理、ローテーション、セッション寿命はどちらも同じ文字列です。本当の違いは認証であり、PlaywrightはネイティブにサポートしますがSeleniumはサポートせず、Selenium Wire、拡張機能、あるいはCDPが必要になります。アーキテクチャを形作るべき違いは分離のコストです。Playwrightのコンテキストは軽量なのでコンテキストごとにアイデンティティをローテーションでき、一方Seleniumのプロキシはドライバーに紐づいているため、ドライバーを再利用しアイデンティティの変更をまとめます。両方でロケールとタイムゾーンを出口に合わせ、GBあたりの課金なので両方で不要なリソースをブロックし、何かを信頼する前に出口アドレスを確認してください。
どちらも同じレジデンシャルプロキシ上で動作します。国と都市のターゲティング、フローが必要とする場合のスティッキーセッションを備えた一つのゲートウェイであり、GBあたりで課金されるため、上記のリソースブロックが直接請求額の削減につながります。