Si tienes que elegir entre Selenium y Playwright para un trabajo que pasa por proxies residenciales, o mantener ambos, lo útil no son dos guías de configuración separadas sino la comparación: qué es idéntico, qué es realmente diferente y cuáles de esas diferencias deberían influir en cómo construyes. Aquí tienes el mismo trabajo hecho en cada uno, en paralelo.
Para el detalle más profundo por framework, incluyendo los casos límite que tiene cada uno, consulta proxies residenciales en Selenium y proxies residenciales con Playwright. Esto es la capa de comparación por encima.
Lo que es idéntico: la puerta de enlace
Ambos frameworks hablan con el mismo endpoint con las mismas credenciales, porque al proxy no le importa qué lo está manejando. Host p.shifter.io, puerto 443, y todo tu targeting codificado en el nombre de usuario:
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
Eso significa que cada decisión sobre geografía, rotación y duración de sesión es una cadena de texto, idéntica en ambos frameworks. Nada de lo que sigue cambia la puerta de enlace, solo cómo cada framework le entrega tus credenciales. La referencia de formato está en cómo conectar.
La única diferencia real: la autenticación
Esta es la diferencia que importa, y explica la mayor parte de la friccion con la que se topa la gente.
Playwright soporta proxies autenticados de forma nativa. El nombre de usuario y la contraseña son opciones de primera clase, así que funciona desde el primer momento.
Selenium no. Puede establecer un host y un puerto de proxy, pero la especificación de WebDriver no tiene ningún mecanismo para pasar credenciales, así que Chrome muestra un diálogo de autenticación nativo que tu script no puede cerrar. Cada solución en Selenium es un workaround para ese vacío, y hay tres: Selenium Wire, que gestiona las credenciales por ti; una pequeña extensión de Chrome generada que las proporciona; o CDP, manejando directamente el protocolo de depuración del navegador.
Si empiezas de cero y tu trabajo necesita proxies autenticados, esa diferencia por sí sola es una razón legítima para preferir Playwright.
La misma configuración en ambos
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, usando 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)
Misma puerta de enlace, mismo nombre de usuario, mismo resultado. La única diferencia es cómo entran las credenciales.
La diferencia estructural: cómo aíslas las identidades
Esta es la que realmente debería moldear tu diseño, y se deriva de lo cara que resulta una identidad aislada en cada framework.
En Playwright, los contextos son baratos. Un contexto de navegador es un perfil aislado con sus propias cookies, almacenamiento y, lo importante, su propio proxy. Puedes ejecutar un solo proceso de navegador y crear un contexto por identidad, lo que convierte rotar geografía o sesiones en cuestión de crear un nuevo contexto en lugar de un nuevo navegador.
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
En Selenium, el proxy está vinculado al driver. Cambiarlo generalmente significa un nuevo driver, y un driver es un proceso de navegador completo: lento de iniciar y pesado en memoria. Así que el patrón de Selenium es el contrario, reutilizar un driver para muchas solicitudes con una identidad, y tratar un cambio de identidad como una operación cara que agrupas en lotes en lugar de hacer por solicitud.
La consecuencia práctica: un trabajo que necesita muchas identidades de corta duración es notablemente más barato en Playwright, mientras que un trabajo que mantiene una identidad durante una secuencia larga se adapta bien a cualquiera de los dos. Si estás usando Selenium y te encuentras lanzando un driver por solicitud, eso es lo primero que hay que arreglar, no la configuración del proxy.
Geo, rotación y sesiones
Como el targeting está en el nombre de usuario, esta parte es independiente del framework. Omite sid y cada nueva conexión obtiene una salida nueva; incluye uno y la misma dirección se mantiene hasta que expire el TTL. En Playwright lo delimitas por contexto; en Selenium lo delimitas por driver.
Una cosa que hay que hacer bien en ambos: cuando fijas un país, ajusta la configuración regional y la zona horaria del navegador para que coincidan. Una salida alemana que reporta una zona horaria de Nueva York es una contradicción fácil de detectar y fácil de evitar, y ambos frameworks exponen esas opciones como opciones de contexto, según ajustar geo, zona horaria y configuración regional.
Ancho de banda: el coste que ambos frameworks comparten
Los navegadores son caros en un producto por GB porque descargan todo lo que descargaría un navegador real: imágenes, fuentes, medios, analíticas. Bloquear lo que no necesitas es el mayor ahorro disponible, y ambos frameworks lo soportan.
Playwright:
context.route("**/*", lambda route: route.abort()
if route.request.resource_type in {"image", "media", "font", "stylesheet"}
else route.continue_())
Selenium no tiene un equivalente de una línea en su forma nativa; con Selenium Wire puedes filtrar solicitudes, o puedes bloquear tipos de recursos vía CDP. De cualquier forma, merece la pena hacerlo, ya que comúnmente reduce el peso de la página por un múltiplo considerable. El argumento más amplio, incluyendo si necesitas un navegador en absoluto, está en cuándo necesitas un navegador headless y reducir los costes de ancho de banda del proxy.
Verificar que funciona, en ambos
No asumas que el proxy se está aplicando. Navega a un endpoint que reporte la dirección y comprueba que no es la tuya:
# 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)
Si la dirección es la tuya, el proxy no se está aplicando en absoluto. Si es correcta pero el contenido es incorrecto para la región, sospecha del DNS o de un desajuste de configuración regional antes de culpar al pool, según prevenir fugas de DNS.
Cuál elegir
Si no tienes ningún compromiso previo y tu trabajo implica proxies autenticados y muchas identidades, Playwright es el camino más fácil: el soporte nativo de credenciales y el aislamiento barato por contexto eliminan dos problemas que de otro modo tendrías que resolver por tu cuenta.
Selenium sigue siendo una opción razonable cuando ya tienes un ecosistema Selenium establecido, cuando necesitas su grid y su ecosistema multi-navegador, o cuando el trabajo consiste en una sesión larga en lugar de muchas cortas. El soporte de proxy es totalmente viable, solo te cuesta una librería o una pequeña extensión para introducir las credenciales.
Y en ambos casos, recuerda que el navegador es solo la mitad de no ser bloqueado: la dirección te lleva a la puerta, y las cabeceras, el fingerprint y el ritmo decide qué pasa después, según evitar bloqueos.
Conclusión
La puerta de enlace es idéntica para ambos frameworks, así que la geografía, la rotación y la duración de la sesión son la misma cadena de texto en cada uno. La diferencia real es la autenticación, que Playwright soporta de forma nativa y Selenium no, requiriendo Selenium Wire, una extensión o CDP. La diferencia que debería moldear tu arquitectura es el coste de aislamiento: los contextos de Playwright son baratos así que rotas identidad por contexto, mientras que un proxy de Selenium está vinculado a un driver, así que reutilizas drivers y agrupas los cambios de identidad. Ajusta la configuración regional y la zona horaria a la salida en ambos, bloquea recursos innecesarios en ambos porque pagas por gigabyte, y verifica la dirección de salida antes de confiar en cualquiera de ellos.
Ambos funcionan sobre los mismos proxies residenciales, una única puerta de enlace con targeting por país y ciudad y sesiones persistentes cuando un flujo lo necesita, facturado por GB de modo que el bloqueo de recursos anterior se traduce directamente en una factura menor.