La automatización de navegador —headless Chrome, Playwright, Puppeteer, Selenium— se conecta al proxy de forma distinta a un cliente HTTP normal: la dirección se define en los parámetros de inicio del driver, no en la configuración del sistema operativo. Un error en este punto delata al bot antes de que entre en juego cualquier ajuste antidetect, y la propia automatización gasta mucho más tráfico de lo que parece al empezar. Veamos cómo encaja el canal en la cadena navegador—driver—red, de dónde sale el consumo extra de gigabytes y qué lo reduce de verdad.
Cómo se conecta el proxy al navegador headless y al driver
En un navegador headless la dirección no es «del sistema», sino que va en los parámetros de inicio: en Chromium, con la opción «--proxy-server=host:port»; en Playwright y Puppeteer, con el campo proxy en las opciones del contexto; en Selenium, con el objeto Proxy en las capabilities del driver. La configuración del sistema redirige todo el tráfico de la máquina, incluidos los procesos en segundo plano; la configuración a nivel de driver actúa solo dentro de la sesión del navegador, y eso es justo lo que necesitas cuando en una misma máquina conviven en paralelo decenas de perfiles con direcciones distintas.
La autenticación se hace con usuario y contraseña en la URL (funciona en Playwright y Puppeteer mediante los parámetros del contexto, pero no al lanzar Chromium solo con la opción) o mediante vinculación a la IP blanca del servidor de automatización. La segunda opción es más fiable para un runner de CI con dirección de salida fija: no hace falta guardar la contraseña del proxy en variables de entorno.
Por qué la automatización consume más tráfico de lo que parece
Una persona que desplaza la página solo ve la parte superior de la pantalla. El driver, por defecto, carga la página completa: fuentes (cientos de kilobytes por familia), scripts de analítica y redes publicitarias, píxeles de retargeting, websockets de chats de soporte. Ninguno de estos elementos hace falta para comprobar un precio o un texto, pero se descargan junto con el contenido objetivo.
En la ficha de un producto, los datos útiles —el HTML con el precio y las características— pesan decenas de kilobytes, y el resto de la página, de 2 a 5 MB, son imágenes, fuentes y scripts de terceros de los que la tarea no sabe nada. Eso es pagar por un tráfico que nunca llegará al resultado. Encontrarás un análisis detallado de qué desactivar y cómo calcular el ahorro paso a paso en el artículo cómo reducir el consumo de GB en proxies.
Desactivar los medios: la principal forma de ahorrar
La palanca principal de ahorro es bloquear, a nivel de driver, todo lo que no forma parte del resultado del scraping, en lugar de elegir un canal más barato. En Playwright y Puppeteer se hace interceptando las solicitudes y cancelando los tipos image, media, font y, a veces, stylesheet. En Selenium con Chrome, el mismo efecto se consigue con un ajuste de perfil que desactiva la carga de imágenes.
El efecto es una reducción del peso de la página de 3 a 10 veces, según la cantidad inicial de imágenes y vídeos. En las tareas donde solo hace falta texto —precio, disponibilidad, estado de un pedido—, bloquear los medios no afecta al resultado: los datos están en el HTML, no en las imágenes. Buscar el canal más barato en vez de desactivar los medios suele dar el efecto contrario; la diferencia se explica en el artículo proxies baratos frente a caros.
Coherencia de locale, zona horaria e idioma de la solicitud con la geo de la dirección
Cambiar la IP no cambia automáticamente ni el locale del navegador, ni la zona horaria del sistema, ni el encabezado Accept-Language. Si la dirección figura como estadounidense, pero el contexto informa la zona horaria Europe/Moscow y el idioma ruso, el sitio recibe señales contradictorias. Algunos sitios entregan el contenido según el idioma del encabezado y no según la IP, así que la desincronización cambia los resultados que ves y no solo hace más sospechosa la sesión.
En Playwright y Puppeteer, locale, timezoneId y los encabezados se definen en las opciones del contexto al crear la página, y deben sincronizarse con la geo de la dirección en cada lanzamiento, no una sola vez para todos los perfiles a la vez. Encontrarás una lista de verificación para la combinación «perfil más canal», que incluye la comprobación de WebRTC y DNS, en el artículo proxy para navegador antidetect paso a paso.
Perfiles en paralelo y un puerto aparte por perfil
Cuando la automatización lanza varios perfiles a la vez, un solo puerto para todos genera dos problemas. El de red: las sesiones comparten el ancho de banda y el límite de hilos, de ahí los timeouts y los reintentos. El de comportamiento: si el proveedor cambia la IP de salida en un puerto al reconectarse, el sitio ve un cambio de dirección dentro de la sesión y puede considerarlo una anomalía.
La regla es simple: un puerto aparte y una dirección estable durante la sesión para cada perfil en paralelo. Esto aumenta el número de canales que compras, pero elimina ambas fuentes de reintentos. La rotación por API permite controlar por programa el cambio de dirección en cada puerto, sin reconstruir a mano la configuración antes de cada lanzamiento; se explica en el artículo cómo configurar la rotación de IP por API.
Preguntas frecuentes
¿Se puede usar un mismo proxy para varios perfiles headless a la vez?
Técnicamente sí, pero no conviene: las sesiones paralelas por un mismo puerto comparten el ancho de banda y provocan timeouts, y el sitio puede interpretar la alternancia de solicitudes desde una misma dirección como actividad sospechosa. Para el lanzamiento en paralelo, usa un puerto aparte por perfil.
¿Desactivar imágenes y fuentes no rompe el scraping de datos?
No, siempre que los datos que necesitas estén en el HTML y no se rendericen como imagen o elemento canvas. Antes de un lanzamiento masivo conviene ejecutar la tarea con los medios activados y desactivados y comparar el resultado: para precios, disponibilidad y campos de texto, normalmente no hay diferencia.
¿Cómo comprobar que el locale y la zona horaria del navegador coinciden con la geo del proxy?
Con cualquier servicio de verificación de la huella del navegador: te mostrará la IP, el país, la zona horaria y el idioma que ve el sitio. Conviene integrar la comprobación en el propio script de automatización como primer paso antes de la tarea principal, y no hacerla a mano de vez en cuando.
Un puerto aparte para cada perfil de automatización, autenticación por IP blanca para CI y la elección del canal según la tarea —direcciones residenciales y móviles por tráfico o de centro de datos por mes— están en la sección de proxies.