Puntos clave
Si das de baja uno de nuestros servidores, tu siguiente request pasa a otro. La API, el puerto proxy, el servidor MCP, el inicio de sesión y el sitio web ahora también se ejecutan en servidores de respaldo (standby), y el tráfico se redirige por sí solo. Los rate limits también dejaron de castigar pequeños excesos: recibes tu cuota permitida y solo se rechaza el excedente.
Novedades
Servidores de respaldo detrás de cada servicio
Si los servidores principales dejan de responder, tu tráfico pasa a servidores de respaldo sin que tengas que cambiar nada de tu lado. Mismas claves, mismos hosts, mismos usuarios de proxy.
Un request que llega a un servidor que no puede procesarlo en ese momento se transfiere a uno que sí puede, en lugar de devolver un error. Además, tus llamadas en los servidores restantes no pierden velocidad mientras esto ocurre.
Los rate limits recortan, no bloquean
Si superas ligeramente el límite por minuto de tu plan en Single o Proxy Finder, ahora obtienes tu cuota y solo se rechaza el excedente, ya que los requests rechazados ya no cuentan para el minuto. Retry-After indica cuándo pasa el siguiente.
Si reintentas con demasiada frecuencia, se aplica una pausa. Cuando los rechazos en un minuto superan el doble de tu cuota, la respuesta es una espera de 30 segundos marcada con cooldown: true. Como los rechazos durante este período no se contabilizan, la pausa termina automáticamente incluso si tu cliente sigue enviando peticiones. Las nuevas conexiones al puerto proxy siguen la misma regla: una que nunca se convirtió en túnel no cuenta para tu minuto.
import time
import requests
def single(url, key, tries=5):
for _ in range(tries):
r = requests.post(
"https://api.foura.ai/api/single",
headers={"X-API-Key": key},
json={"url": url},
)
if r.headers.get("X-FourA-Limit") != "plan_limit_rate":
return r
# same header on the 30-second pause; the body adds "cooldown": true
time.sleep(int(r.headers.get("Retry-After", "1")))
return r
Cada campo está en la página de rate limits.
Auto desiste antes en sitios que rechazan a todos
Cuando un sitio rechaza cada salida que Auto prueba, incluyendo Browser, la llamada ahora finaliza tras unos pocos intentos en lugar de consumir todo tu presupuesto. En un sitio que Proxy Finder ya ha procesado antes, Auto primero solicita la página a Proxy Finder según tu propia regla validate, y esa búsqueda no tiene costo si regresa vacía.
Dos cambios adicionales mantienen a Auto dentro de los límites que definiste. Una llamada que espera por una sesión ocupada, o por otra request que ya está trabajando en el mismo sitio, ahora termina dentro de tu timeout_ms con un error time budget exhausted, para que puedas reintentar o aumentar el presupuesto (problemas comunes incluye los detalles). Además, una página JSON regresa en data como texto sin importar la ruta que la haya obtenido, de modo que un solo parser procesa cada llamada.
Nada de esto cambia el propósito de Auto. Encuentra la ruta; una vez hecho esto, repite el session que devuelve en /api/single o /api/browser y dirige tu volumen allí.
Páginas que requieren un paso adicional
Browser ahora espera a que pase un tipo adicional de página de espera temporal, la breve que ejecuta un script y luego se recarga en el contenido real, devolviendo la página resultante. Auto transfiere dichas páginas a Browser en la misma salida, por lo que la llamada finaliza con el contenido del sitio.
Algunas páginas de productos de Amazon primero te piden hacer clic en "Continue shopping". Single y Browser ahora presionan ese botón en la misma salida y devuelven la página del producto. Las llamadas a través de Proxy Finder y Auto reciben el mismo tratamiento.
Browser también sigue una página que se redirige a otra dirección después de cargarse, en lugar de agotar tu timeout. Las cookies llamadas __Secure- o __Host- que envíes de vuelta ahora reciben los atributos que requiere su prefijo, permitiendo que la página reconozca toda tu sesión guardada.
Proxy Finder y dos errores más claros
Las requests HTTP sin cifrar a través de Proxy Finder ahora abren primero una conexión directa con el sitio, tal como siempre lo ha hecho HTTPS. Un proxy que responde con una página propia, o que entrega el mismo body a sitios no relacionados, se omite y tu request pasa al siguiente.
Si pasas tu propia URL de proxy a Single o Browser con un hostname que no resuelve, la respuesta es status 0 con un error que indica el host, igual que ocurriría con un objetivo. Una request dirigida a api.foura.ai o al propio eu.api.foura.ai recibe un 400 de inmediato, antes de que se obtenga o cobre nada. El error señala la causa habitual: un enlace resuelto contra la URL de la API en lugar de la página de donde provino.
Dashboard, registro y facturación
- Un registro iniciado en foura.ai ahora termina en tu Dashboard, donde Overview te guía hacia un primer resultado: crea una API key y luego envía una request desde una terminal o el Playground. En un teléfono, los pasos comienzan en el Playground, y el puerto proxy tiene sus propios pasos configurados en torno a un usuario proxy.
- En un teléfono o en una ventana estrecha, el Playground desplaza la response a la vista tan pronto como llega.
- Usage by Domain y by Client IP clasifican cada fila en el período antes de dividirla en páginas, por lo que la página uno contiene las entradas superiores reales.
- Las tarjetas de Overview siguen el período que elijas mientras aún se están cargando, el cuadro de diálogo del período se abre en el que estás viendo y la barra lateral incluye un enlace a Docs debajo de Tools.
- Las facturas que emitimos manualmente ahora aparecen en la página Billing junto a las automáticas. Una factura con IVA de la UE aplica la tasa vigente el día de la venta, incluidos los cambios anunciados con anticipación.
Cada una de estas novedades tiene su propia entrada en updates.foura.ai.
Bajo el capó
El puerto proxy mantiene un recuento en tiempo real de tus túneles abiertos, y un túnel que finalizó cuando una de nuestras instancias se reinició se elimina de él en cuestión de segundos. Así, la concurrencia que permite tu plan es exactamente la concurrencia que obtienes.
El mejor failover es aquel del que solo te enteras en un resumen.