Wenn Sie zwischen Selenium und Playwright für Arbeiten wählen müssen, die über residentielle Proxys laufen, oder beide pflegen, ist nicht das Nützliche zwei getrennte Setup-Anleitungen, sondern der Vergleich: was identisch ist, was tatsächlich unterschiedlich ist, und welche dieser Unterschiede beeinflussen sollten, wie Sie bauen. Hier ist dieselbe Aufgabe in beiden, nebeneinander.
Für die tieferen Details je Framework, einschließlich der Sonderfälle, die jedes hat, siehe residential proxies in Selenium und residential proxies with Playwright. Dies ist die Vergleichsebene darüber.
Was identisch ist: das Gateway
Beide Frameworks sprechen mit demselben Endpunkt mit denselben Anmeldedaten, weil dem Proxy egal ist, was ihn steuert. Host p.shifter.io, Port 443, und Ihr gesamtes Targeting kodiert im Benutzernamen:
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
Das bedeutet, jede Entscheidung über Geografie, Rotation und Sitzungslebensdauer ist ein String, identisch in beiden Frameworks. Nichts in den folgenden Abschnitten ändert das Gateway, nur wie jedes Framework ihm Ihre Anmeldedaten übergibt. Die Formatreferenz finden Sie unter how to connect.
Der eine echte Unterschied: Authentifizierung
Dies ist der Unterschied, der zählt, und er erklärt den größten Teil der Reibung, auf die man stößt.
Playwright unterstützt authentifizierte Proxys nativ. Benutzername und Passwort sind vollwertige Optionen, sodass es sofort funktioniert.
Selenium tut das nicht. Es kann einen Proxy-Host und Port setzen, aber die WebDriver-Spezifikation hat keinen Mechanismus zur Übergabe von Anmeldedaten, sodass Chrome einen nativen Auth-Dialog anzeigt, den Ihr Skript nicht schließen kann. Jede Selenium-Lösung ist ein Workaround für diese Lücke, und es gibt drei: Selenium Wire, das Anmeldedaten für Sie verarbeitet; eine kleine generierte Chrome-Erweiterung, die sie liefert; oder CDP, das das Debugging-Protokoll des Browsers direkt steuert.
Wenn Sie neu anfangen und Ihre Arbeit authentifizierte Proxys benötigt, ist dieser Unterschied allein ein legitimer Grund, Playwright zu bevorzugen.
Dasselbe Setup in beiden
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, mit 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)
Dasselbe Gateway, derselbe Benutzername, dasselbe Ergebnis. Der einzige Unterschied ist, wie die Anmeldedaten hineingelangen.
Der strukturelle Unterschied: wie Sie Identitäten isolieren
Dies ist derjenige, der Ihr Design tatsächlich prägen sollte, und er ergibt sich daraus, wie teuer eine isolierte Identität in jedem Framework ist.
In Playwright sind Kontexte günstig. Ein Browser-Kontext ist ein isoliertes Profil mit eigenen Cookies, Speicher und, wichtig, seinem eigenen Proxy. Sie können einen Browserprozess ausführen und pro Identität einen Kontext erstellen, was die Rotation von Geografie oder Sitzungen zu einer Frage des Erstellens eines neuen Kontexts statt eines neuen Browsers macht.
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 stays
In Selenium ist der Proxy an den Driver gebunden. Ihn zu ändern bedeutet im Allgemeinen einen neuen Driver, und ein Driver ist ein ganzer Browserprozess: langsam zu starten und speicherintensiv. Das Selenium-Muster ist also das Gegenteil, einen Driver für viele Anfragen mit einer Identität wiederverwenden und einen Identitätswechsel als teure Operation behandeln, um die man Batches bildet, statt sie pro Anfrage durchzuführen.
Die praktische Konsequenz: eine Aufgabe, die viele kurzlebige Identitäten benötigt, ist in Playwright deutlich günstiger, während eine Aufgabe, die eine Identität über eine lange Sequenz hinweg hält, für beide geeignet ist. Wenn Sie Selenium ausführen und sich dabei ertappen, pro Anfrage einen Driver zu starten, ist das die Sache, die zuerst behoben werden sollte, nicht die Proxy-Konfiguration.
Geo, Rotation und Sitzungen
Da das Targeting im Benutzernamen liegt, ist dieser Teil framework-agnostisch. Lassen Sie sid weg und jede neue Verbindung erhält einen frischen Exit; fügen Sie eine hinzu, wird dieselbe Adresse gehalten, bis das TTL abläuft. In Playwright scopen Sie das pro Kontext; in Selenium scopen Sie es pro Driver.
Eine Sache, die man in beiden richtig machen sollte: Wenn Sie ein Land festlegen, setzen Sie das Gebietsschema und die Zeitzone des Browsers passend dazu. Ein deutscher Exit, der eine New Yorker Zeitzone meldet, ist ein Widerspruch, der leicht zu entdecken und leicht zu vermeiden ist, und beide Frameworks stellen diese als Kontextoptionen zur Verfügung, siehe matching geo, timezone and locale.
Bandbreite: die Kosten, die beide Frameworks teilen
Browser sind bei einem Pro-GB-Produkt teuer, weil sie alles abrufen, was ein echter Browser abrufen würde: Bilder, Schriftarten, Medien, Analytics. Das Blockieren dessen, was Sie nicht brauchen, ist die größte verfügbare Einsparung, und beide Frameworks unterstützen dies.
Playwright:
context.route("**/*", lambda route: route.abort()
if route.request.resource_type in {"image", "media", "font", "stylesheet"}
else route.continue_())
Selenium hat in der reinen Form keine gleichwertige Einzeiler-Lösung; mit Selenium Wire können Sie Anfragen filtern, oder Sie können Ressourcentypen über CDP blockieren. So oder so lohnt es sich, da dies das Seitengewicht üblicherweise um ein Vielfaches reduziert. Das umfassendere Argument, einschließlich ob Sie überhaupt einen Browser benötigen, finden Sie unter when you need a headless browser und cutting proxy bandwidth costs.
Überprüfen, dass es funktioniert, in beiden
Nehmen Sie nicht an, dass der Proxy angewendet wird. Navigieren Sie zu einem Endpunkt, der die Adresse meldet, und prüfen Sie, dass es nicht Ihre eigene ist:
# 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)
Wenn die Adresse Ihre eigene ist, wird der Proxy überhaupt nicht angewendet. Wenn sie richtig ist, aber der Inhalt für die Region falsch ist, verdächtigen Sie DNS oder eine Gebietsschema-Fehlanpassung, bevor Sie dem Pool die Schuld geben, siehe preventing DNS leaks.
Wofür entscheiden
Wenn Sie keine bestehende Bindung haben und Ihre Arbeit authentifizierte Proxys und viele Identitäten umfasst, ist Playwright der einfachere Weg: native Anmeldedaten-Unterstützung und günstige Isolation pro Kontext beseitigen zwei Probleme, um die Sie sonst herumkonstruieren müssten.
Selenium bleibt eine vernünftige Wahl, wo Sie bereits eine Selenium-Umgebung haben, wo Sie dessen Grid und Cross-Browser-Ökosystem benötigen, oder wo die Arbeit eine einzelne, langlebige Sitzung ist statt vieler kurzer. Die Proxy-Unterstützung ist durchaus machbar, sie kostet Sie nur eine Bibliothek oder eine kleine Erweiterung, um Anmeldedaten hineinzubekommen.
Und in beiden Fällen: denken Sie daran, dass der Browser nur die Hälfte davon ist, nicht blockiert zu werden: die Adresse bringt Sie zur Tür, und Header, Fingerabdruck und Tempo entscheiden, was als Nächstes passiert, siehe avoiding blocks.
Fazit
Das Gateway ist für beide Frameworks identisch, sodass Geografie, Rotation und Sitzungslebensdauer in jedem derselbe String sind. Der eigentliche Unterschied ist die Authentifizierung, die Playwright nativ unterstützt und Selenium nicht, wofür Selenium Wire, eine Erweiterung oder CDP erforderlich sind. Der Unterschied, der Ihre Architektur prägen sollte, sind die Isolationskosten: Playwright-Kontexte sind günstig, sodass Sie die Identität pro Kontext rotieren, während ein Selenium-Proxy an einen Driver gebunden ist, sodass Sie Driver wiederverwenden und Identitätswechsel in Batches durchführen. Passen Sie in beiden Gebietsschema und Zeitzone an den Exit an, blockieren Sie in beiden unnötige Ressourcen, weil Sie pro Gigabyte bezahlen, und überprüfen Sie die Exit-Adresse, bevor Sie irgendetwas davon vertrauen.
Beide laufen auf denselben residential proxies, einem Gateway mit Länder- und Stadt-Targeting und Sticky Sessions, wenn ein Ablauf eine benötigt, abgerechnet per GB, sodass sich die oben beschriebene Ressourcenblockierung direkt in eine kleinere Rechnung übersetzt.