Caso de Estudio7 min de lectura

Escalar el registro de cuentas a 50 perfiles: un flujo por lotes real

Un equipo combinó datos únicos por perfil, resolución automática de CAPTCHA y comprobaciones de recuperación para mantener consistente un registro en 50 navegadores de principio a fin.

8 mar 2026

El Escenario

Un equipo necesitaba registrar cuentas en una plataforma en 50 perfiles de navegador antidetección. Cada cuenta requería un correo electrónico único, nombre, número de teléfono y contraseña. El flujo de registro incluía verificación de correo electrónico, un desafío reCAPTCHA v2 y un paso de incorporación posterior al registro.

Hacerlo manualmente habría tomado 3-4 horas. Con Ornold MCP y un agente de IA, todo el lote se completó en menos de 25 minutos, incluida la resolución de CAPTCHA y la recuperación de errores.

Preparación: Datos por Perfil

El primer paso fue preparar datos únicos para cada uno de los 50 perfiles. Cada campo que requería el formulario de registro necesitaba un valor distinto por sesión. Reutilizar datos entre perfiles es la forma más rápida de ser marcado.

El equipo preparó un conjunto de datos con:

Direcciones de correo electrónico únicas (una por perfil, de diferentes proveedores)
Nombres realistas que coincidan con la configuración regional/idioma del perfil
Contraseñas fuertes (únicas por perfil, no secuenciales)
Números de teléfono para verificación por SMS (de un servicio de números virtuales)

La calidad de los datos es más importante que la velocidad de automatización. Un correo electrónico duplicado o un nombre obviamente falso pueden desencadenar la detección de fraude y marcar todo el lote. Invierte tiempo en generar conjuntos de datos realistas y diversos.

// Estructura de ejemplo del conjunto de datos de perfil
const profiles = [
  { email: "sarah.mitchell@proton.me", name: "Sarah Mitchell", phone: "+1-555-0142", password: "kR9#mPx2vL" },
  { email: "james.wong@tutanota.com", name: "James Wong", phone: "+1-555-0198", password: "nT4$hQw8bJ" },
  // ... 48 perfiles más únicos
];

Fase 1: Lanzamiento y Navegación

Con 50 sesiones de Linken Sphere listas (cada una con su propio proxy, huella digital y zona horaria), el primer paso fue navegar todas simultáneamente a la página de registro.

// Iniciar todas las sesiones y navegar a la página de registro
await browser_list(); // Verificar que 50 sesiones estén disponibles
await browser_parallel_navigate({ url: "https://target.example/signup" });

// Esperar a que el formulario cargue en todas las sesiones
await browser_parallel_wait_for({
  text: "Create your account",
  timeoutMs: 20000
});

48 de 50 sesiones cargaron la página de registro en 8 segundos. Dos sesiones fueron más lentas debido a la latencia del proxy: el comando `wait_for` esperó hasta que alcanzaron la marca de 14 segundos.

Fase 2: Llenado de Formulario

Cada sesión necesitaba sus propios datos únicos. El comando de llenado paralelo de Ornold acepta una matriz de valores que se asigna 1:1 a sesiones activas:

// Llenar correo electrónico — cada sesión obtiene un valor único
await browser_parallel_fill({
  ref: "email",
  values: profiles.map(p => p.email)
});

// Llenar nombre
await browser_parallel_fill({
  ref: "fullname",
  values: profiles.map(p => p.name)
});

// Llenar contraseña
await browser_parallel_fill({
  ref: "password",
  values: profiles.map(p => p.password)
});

El llenado de formulario en las 50 sesiones tomó aproximadamente 3 segundos. El modo de interacción basado en DOM (gratuito, sin créditos de visión) manejó los campos de formulario estructurados sin problemas.

Fase 3: Resolución de CAPTCHA

La página de registro tenía un desafío reCAPTCHA v2. Ornold lo detectó en las 50 sesiones y envió solicitudes de resolución en paralelo:

// Resolver CAPTCHA en las 50 sesiones
const captchaResult = await browser_solve_captcha();
// { total: 50, detected: 50, solved: 47, failed: 3 }

47 de 50 CAPTCHA se resolvieron en el primer intento (15-35 segundos). Tres sesiones fallaron: el servicio de resolución agotó el tiempo. En lugar de reintentar todo el lote, el equipo reintentó solo las sesiones fallidas:

// Reintentar sesiones fallidas
const retryResult = await browser_solve_captcha();
// Solo se dirige a sesiones que aún tienen CAPTCHA sin resolver
// { total: 3, detected: 3, solved: 3, failed: 0 }

La resolución de CAPTCHA es el paso más lento en la mayoría de los flujos de registro. Resuelve después de llenar el formulario (no antes) para minimizar la posibilidad de expiración del token.

Fase 4: Envío y Verificación

Con formularios llenos y CAPTCHA resueltos, el siguiente paso fue hacer clic en el botón de envío y verificar que el registro fue exitoso:

// Enviar el formulario
await browser_parallel_click({ ref: "submit" });

// Esperar la página de éxito
await browser_parallel_wait_for({
  text: "Check your email",
  timeoutMs: 15000
});

// Verificar estado
const status = await browser_status();

Resultados después del envío:

46 sesiones llegaron a la página de confirmación "Check your email"
2 sesiones obtuvieron un desafío de seguridad secundario (solicitud de verificación por teléfono)
1 sesión recibió un error "too many requests"
1 sesión agotó el tiempo durante el envío

Fase 5: Recuperación de Errores

En lugar de reiniciar todo el lote, el equipo manejó cada tipo de fallo por separado:

Verificación por teléfono (2 sesiones)

Estas sesiones necesitaban un paso adicional. El agente de IA detectó el campo de entrada de teléfono, llenó los números virtuales del conjunto de datos y envió. Ambas sesiones se completaron después de la verificación por SMS.

Error de límite de velocidad (1 sesión)

El error "too many requests" estaba relacionado con el proxy: la IP se había usado recientemente. El equipo cambió el proxy de la sesión e intentó de nuevo. El registro fue exitoso en el segundo intento.

Tiempo agotado (1 sesión)

Una simple recarga de página y reenvío lo solucionó. Los datos del formulario aún estaban llenos (el navegador los conservó), por lo que solo necesitaba repetir la acción de envío.

Resultado final: 50 de 50 cuentas registradas exitosamente. Tiempo total desde la primera navegación hasta la última confirmación: 23 minutos.

Lo que Hizo Esto Posible

Varios factores convirtieron esto de un script frágil en una operación de lote confiable:

Datos por perfil — Cada sesión tenía datos únicos y realistas. Sin duplicados, sin patrones.
Ejecución paralela — Las 50 sesiones avanzaron por cada fase juntas, no una a la vez.
Recuperación selectiva — Los fallos se manejaron por sesión, no reiniciando el lote. El agente de IA identificó qué salió mal y aplicó la corrección adecuada.
Verificaciones de estado entre fases — Las llamadas `browser_status()` y `wait_for` después de cada paso detectaron divergencias temprano.
Lógica de reintento de CAPTCHA — Los intentos fallidos se reintentaron individualmente en lugar de resolver todo el lote nuevamente.

Desglose de Tiempo

Lanzamiento de sesión + navegación: ~15 segundos
Llenado de formulario (50 sesiones): ~3 segundos
Resolución de CAPTCHA (primer paso): ~35 segundos
Reintento de CAPTCHA (3 sesiones): ~25 segundos
Envío de formulario + verificación: ~10 segundos
Recuperación de errores (4 sesiones): ~8 minutos
Total: ~23 minutos para 50 cuentas

Sin la fase de recuperación de errores, la ruta feliz para 46 sesiones se habría completado en aproximadamente 2 minutos. La mayor parte del tiempo total se gastó en la resolución de CAPTCHA y el manejo de casos extremos, lo cual es esperado a esta escala.

Lecciones para Escalar Más

La calidad de los datos es el cuello de botella, no la velocidad de automatización. Gasta más tiempo en conjuntos de datos realistas que en optimizar el tiempo de clic.
La calidad del proxy afecta directamente la tasa de éxito. Los proxies compartidos baratos conducen a límites de velocidad y bloqueos. Los proxies residenciales o móviles funcionan significativamente mejor.
No ejecutes más sesiones de las que tu máquina puede manejar. 50 instancias de Chromium necesitan 16-24 GB de RAM. Monitorea el uso de recursos y escala el hardware antes de escalar el número de sesiones.
Construye recuperación en el flujo de trabajo desde el principio. Con 50+ perfiles, algunos fallos son garantizados. La pregunta es si los manejas automáticamente o manualmente.
Prueba primero con 5 perfiles. Valida todo el flujo de extremo a extremo antes de escalar a 50. La depuración a escala es exponencialmente más difícil.
Distribuye lotes grandes. Ejecutar 100 perfiles a la vez desde el mismo rango de IP es una bandera roja. Divídelos en grupos de 20-30 con retrasos entre ellos.