Últimas actualizaciones y mejoras de FourA
Muchos sitios sirven su página de entrada a cualquier usuario y restringen las páginas más profundas. Auto ahora toma la sesión que entrega esa página de entrada y solicita la URL profunda incluyéndola, y te notifica que lo hizo con un nivel warmup en la response.
Configura timeout_ms hasta 120 segundos en un request de Browser y se ejecutará por todo ese tiempo asignado, así un destino lento obtiene el tiempo que le diste y puedes leer el veredicto del propio motor.
Ahora el navegador resuelve el desafío de la casilla de verificación de Cloudflare en requests concurrentes a la misma página, y un clic solo cuenta una vez que el desafío realmente ha desaparecido. Tres requests simultáneos se resuelven en 5 a 9 segundos.
Playground ahora renderiza la respuesta de tu destino, incluso en sitios que configuran cookies grandes, y los endpoints de la API siempre responden en JSON.
Las páginas protegidas de eBay redirigen a los visitantes a un desafío proof-of-work de Argon2. Single ahora lo resuelve en una sola llamada y devuelve el anuncio real por 2 créditos, una reducción desde los aproximadamente 360 a través de la ruta de respaldo. Si has estado pagando el precio completo en eBay, eso se acabó.
Si tu destino redirigía a una ruta URL diferente, Browser devolvía 'No response received' aunque la página hubiera llegado. Esto está solucionado; la request sigue la navegación a donde sea que llegue. eBay, tiendas con muchas redirecciones y cualquier sitio con un 3xx a una página de desafío ahora funcionan.
Las respuestas ahora reportan akamai y ebay-splashui donde antes no reportaban nada (o atribuían erróneamente el bloqueo a Cloudflare). Si tu código se bifurca en defense.vendor para elegir una estrategia de reintento, esos dos nombres ahora aparecen correctamente.
Ahora Activity se ajusta a un MacBook de 14" sin desplazamiento horizontal, y cada columna mantiene su valor. El panel de detalles es un panel con pestañas (Request, Response headers, Response body), por lo que la respuesta está en la parte superior en lugar de 900px más abajo. Los tooltips siguen a tu puntero y muestran la URL completa.
La columna del método ahora lee el verbo del cuerpo de tu request (GET, POST, PUT, etc.), en lugar de decir siempre POST porque eso fue lo que recibió nuestra capa de API. Las llamadas de Playground también registran la IP del navegador de la persona que hizo clic en Enviar, para que una cuenta compartida pueda saber quién ejecutó qué.
FourA MCP 0.6.0 permite a un agente elegir qué navegador presenta un request. foura_single y foura_proxy aceptan browser, os, version, o un id exacto de profile del catálogo público en GET /api/profiles. Viajan dentro del request que ya va hacia el upstream, por lo que no hay ninguna llamada adicional. Si los omites, el request presenta el último Google Chrome, exactamente como antes. Una combinación que el catálogo no puede presentar se devuelve como un error que enumera lo que está disponible, por lo que un request nunca se envía como un navegador que no elegiste.
Ambas herramientas ahora devuelven defense cuando el objetivo ejecuta una verificación de bots. defense.solved: false significa que el cuerpo puede ser una página de desafío en lugar del contenido que solicitaste, lo cual es la señal para reintentar con un navegador diferente o escalar, en lugar de analizar una página de bloqueo como datos.
Una corrección en la misma versión: la descripción de unblocker decía que su valor predeterminado estaba apagado. Siempre ha estado encendido, por lo que los requests ya llevaban un conjunto completo de headers del navegador. El esquema publicado ahora coincide con el comportamiento.
Una instancia saturada responde a una comprobación de estado de 3 a 10 segundos, mientras que una sana tarda de 9 a 225 milisegundos, y antes ambas se mostraban como correctas. Ahora, las instancias lentas aparecen como degradadas e incluyen el motivo de la propia instancia, de modo que vemos el problema mientras todavía es un solo servidor lento y no tu request fallida. Auto también se monitoriza, con límites ajustados al tiempo que tarda una resolución compleja real en lugar de un límite genérico que se activaría con cada éxito.
El parámetro profile le indica al unblocker qué navegador simular en /api/single y /api/proxy. Pasa un id de perfil exacto (como firefox147 o chrome146), o deja que browser + os + version se resuelvan en la combinación coincidente más reciente. GET /api/profiles devuelve el catálogo actual (79 perfiles en cinco familias de navegadores), para que no definas estáticamente en tu código una lista que se vuelva obsoleta. El entorno de pruebas del Dashboard expone el mismo selector como tres listas desplegables en cascada.
El Playground del Dashboard ahora tiene tres selectores en cascada para SO, navegador y versión, obtenidos en vivo del catálogo de perfiles. Elige dos cualquiera y el tercero se restringe a las opciones que realmente se resuelven. Seleccionar un perfil activa unblocker, porque la API rechaza los perfiles que no lo tienen.
Ahora un servicio se considera caído solo cuando ha perdido todas sus instancias, el único estado en el que tu request no tiene a dónde llegar. Los rolling deploys de rutina ya no aparecen como incidentes en la página de estado.
La firma por defecto que envía el desbloqueador es ahora una versión mayor actual, no la antigua que los scrapers tenían fijada en su código. Los sitios que habían empezado a devolver páginas de bloqueo estáticas a versiones mayores más antiguas devuelven su página real en Single y Browser. Ambos productos se actualizaron al mismo tiempo, por lo que una repetición de cf_clearance desde Browser hacia Single sigue llegando byte por byte.
