Novedades
Rotar IPs de salida es la parte que todo el mundo automatiza. La firma del navegador debajo de ellas normalmente nunca cambia.
Single y Proxy Finder ahora aceptan cuatro campos opcionales que determinan qué navegador presenta tu request: browser, os, version y profile. El catálogo detrás de ellos es público en GET /api/profiles y no requiere API key. Actualmente contiene 79 perfiles entre Chrome, Edge, Safari, Firefox y Tor, en Windows, macOS, Android e iOS.
Y cuando no especificas uno, Proxy Finder lo cambiará por ti. Pero solo después de que un sitio haya demostrado dos veces que no acepta el que enviaste.
Cómo funciona
Tres de los campos son para humanos y uno es para máquinas.
browser, os y version filtran el catálogo, y puedes enviar cualquier subconjunto de ellos. os coincide con la familia, por lo que solicitar macOS acepta todas las versiones de macOS en la lista, mientras que solicitar la etiqueta exacta de la versión se limita a esa. Cuando varios perfiles siguen encajando, la versión más reciente tiene prioridad, porque mantenerse al día es todo el objetivo. Las versiones principales antiguas son en lo que se basan las listas de bloqueo.
curl -X POST https://eu.api.foura.ai/api/single/ \
-H "X-API-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"method": "GET",
"url": "https://example.com/listing/42",
"browser": "Safari",
"os": "iOS"
}'
Eso resuelve a la versión más reciente de Safari en iOS dentro del catálogo, y envía el User-Agent, los client hints y el orden de headers correspondientes, en ese orden. El orden de los headers es en sí mismo una señal, por lo que nada se reordena al salir.
profile es el cuarto campo: un id exacto del catálogo, pensado para código que debe seguir enviando el mismo cliente incluso después de que aparezca una versión más nueva. Proxy Finder acepta los cuatro dentro de su objeto request. La lista completa de parámetros está en la referencia de la API, y el Playground lee el mismo catálogo, por lo que sus menús desplegables solo pueden ofrecer lo que tu código puede solicitar. Los mismos cuatro campos viajan dentro de foura_single y foura_proxy en el servidor MCP, permitiendo que un agente reintente como otro navegador en lugar de devolver un simple 403.
Hay dos cosas que esto se niega a hacer deliberadamente.
Una combinación que el catálogo no puede ofrecer genera un error que indica lo que está disponible para ese navegador. Recurrir a un valor por defecto enviaría un cliente que no elegiste y que no puedes ver en la respuesta. También se rechaza la elección de un perfil con unblocker: false, porque ese flag es el que transporta los headers (lo que realmente hace ese flag). Medio perfil es peor que ninguno.
El catálogo en sí se mide, no se escribe a mano. Un script ejecuta cada perfil a través de la ruta real de la request y registra lo que realmente viajó por la red. Eso importa más de lo que parece: entre dos versiones principales recientes de un navegador, el string de la marca del placeholder cambió y el orden de las marcas se invirtió, y ese es exactamente el tipo de detalle que lee un servicio de detección.
Impacto
Esta es la parte que no esperábamos.
Un valor por defecto es un valor por defecto compartido. El cliente que presenta tu request cuando no pides nada es el mismo que presenta cada request que no pidió nada, y una defensa que busca basarse en algo económico se basa exactamente en eso. Además, falla de una forma inconfundible: un sitio que rechaza un navegador lo rechaza en cada salida que posees. Gastas todo el presupuesto de reintentos demostrando que ese mismo cliente no es bienvenido.
Lo medimos tres veces, en tres proveedores distintos, y el patrón fue idéntico en cada caso.
Un portal inmobiliario detrás de PerimeterX rechazó nueve intentos con el valor por defecto. Cambiar únicamente la plataforma declarada por la request (manteniendo todo lo demás igual, incluido el pool) devolvió la página seis de seis veces. Una tienda de suplementos detrás de Akamai rechazó el valor por defecto y entregó contenido a otras dos familias de navegadores sin problemas. Un sitio de noticias financieras detrás de DataDome respondió al valor por defecto con un 401 y un interstitial de 774 bytes, mientras que otros tres perfiles descargaron la página real, de unos 760 KB, doce veces cada uno. Ejecutamos esa prueba en ambos sentidos para asegurarnos de que el orden no influyera en el resultado.
Así que Proxy Finder ahora rota la familia de navegadores, no solo la salida. Dos salidas independientes tienen que rechazar la solicitud antes de que cambie, porque un solo rechazo es la opinión de una sola salida. Luego avanza por una escala que comienza con el menor cambio posible, la plataforma, y solo entonces prueba otras familias.
No cuesta nada. La rotación cambia lo que envía un reintento, nunca si un reintento ocurre o no, por lo que las solicitudes y los créditos por tarea quedan exactamente igual que antes.
Para usuarios avanzados
La rotación no interfiere en tu camino, y vale la pena conocer las reglas para ello.
Nunca se activa cuando nombraste un perfil tú mismo. Tampoco se activa nunca cuando enviaste tu propio header user-agent o cookie, y ese es el punto importante: una cookie de autorización está vinculada al cliente que la obtuvo, por lo que rotar la firma debajo de una reproducción de sesión funcional rompería una solicitud que estaba teniendo éxito. Fija lo que quieras y se mantendrá fijado.
Tampoco todos los fallos cuentan como evidencia para mover el perfil. Un proveedor de defensa reconocido cuenta. También cuenta un simple código de estado de rechazo (401, 403, 429, 503) sin ningún proveedor identificado, y ese detalle resultó ser importante. Una tarea regresó con ocho rechazos por código de estado y nada identificado en ninguno de ellos: rechazos reales que la rotación estaba ignorando, porque solo confiaba en el detector. Una página faltante o un bloqueo por país no cuentan. Esas son respuestas sobre tu URL y tu geografía, no sobre tu cliente.
Puedes verlo todo. Una respuesta exitosa de Proxy Finder incluye profile solo cuando nosotros lo elegimos, nunca cuando lo hiciste tú. Una tarea fallida incluye attemptReport.profilesTried: las familias que envió, en orden de primer uso, con default para una solicitud que salió sin modificaciones. Sin ese campo, "probamos cuatro navegadores y todos fueron rechazados" y "nunca cambiamos de navegador" se ven idénticos desde afuera.
Un hábito que vale la pena adoptar: cuando estés probando si un perfil ayuda, mantén todo lo demás sin cambios. El resumen de 2026 de herramientas de prueba de fingerprint de Scrapfly lo explica bien: cambiar tres variables entre ejecuciones te dice que algo funcionó, pero no qué cambio fue el que importó. El mismo objetivo, la misma salida, un solo campo diferente. Así es también como se produjo cada número anterior.
Lo que sigue
La lista de candidatos solo crece mediante mediciones, un objetivo a la vez. Una familia se añade después de que la hemos visto abrir un objetivo que la opción predeterminada no pudo, no porque pareciera una buena suposición, y el catálogo se vuelve a medir en cada actualización del motor en lugar de arrastrarse de versiones anteriores.
Esa es la naturaleza compleja de este problema. La mejor firma de cliente es un blanco móvil, rastrearla es un trabajo continuo en lugar de algo que publicas una sola vez, y lo que funcionó el trimestre pasado ya está en la lista de alguien a estas alturas. Por eso es un campo que configuras y un catálogo que puedes consultar, en lugar de un número que elegimos por ti.