Destaques
Tire um dos nossos servidores do ar e a sua próxima request cai em outro. A API, a porta de proxy, o servidor MCP, o login e o site agora também rodam em servidores standby, e o tráfego migra sozinho. O rate limit também parou de punir pequenos excessos: você recebe a sua cota e apenas o excedente é recusado.
O Que Há de Novo
Servidores standby em cada ponto
Se os servidores principais pararem de responder, seu tráfego migra para servidores standby sem nenhuma alteração do seu lado. As mesmas chaves, os mesmos hosts, os mesmos usuários de proxy.
Uma request que chega a um servidor incapaz de processá-la no momento é repassada para outro que pode, em vez de retornar como erro. E as suas chamadas nos servidores restantes não sofrem lentidão durante o processo.
Rate limits limitam, não bloqueiam
Se você ultrapassar um pouco o limite por minuto do seu plano no Single ou no Proxy Finder, você recebe a cota permitida e apenas o excesso é recusado, pois requests recusadas não contam mais para o minuto. Retry-After informa quando a próxima será aceita.
Tente novamente com muita frequência e você terá uma pausa. Quando as recusas em um minuto passarem do dobro da sua cota, a resposta será uma espera de 30 segundos marcada como cooldown: true. Como as recusas durante essa pausa não são contabilizadas, ela termina sozinha mesmo se o seu cliente continuar tentando. Novas conexões na porta de proxy seguem a mesma regra: uma conexão que nunca virou um túnel não conta para o seu 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
Todos os campos estão na página de rate limits.
O Auto desiste mais cedo em sites que bloqueiam tudo
Quando um site rejeita todas as saídas que o Auto tenta, incluindo o Browser, a chamada agora termina após algumas tentativas em vez de consumir todo o seu orçamento. Em um site que o Proxy Finder já atendeu antes, o Auto primeiro consulta o Proxy Finder para obter a página usando a sua própria regra validate, e essa busca não custa nada quando retorna vazia.
Mais duas alterações mantêm o Auto dentro dos limites definidos por você. Uma chamada aguardando uma sessão ocupada, ou outra request que já esteja processando o mesmo site, agora termina dentro do seu timeout_ms com um erro time budget exhausted, permitindo que você tente novamente ou aumente o orçamento (problemas comuns traz os detalhes). E uma página JSON retorna em data como texto, independentemente da rota que a buscou, para que um único parser processe todas as chamadas.
Nada disso altera a finalidade do Auto. Ele encontra a rota; assim que encontrar, repita o session retornado no /api/single ou /api/browser e direcione seu volume para lá.
Páginas que exigem uma etapa extra
O Browser agora aguarda mais um tipo de página intermediária: aquela rápida que executa um script e depois recarrega a si mesma no conteúdo real, retornando a página de destino. O Auto encaminha essas páginas para o Browser na mesma saída, para que a chamada termine com o conteúdo do site.
Algumas páginas de produtos da Amazon pedem primeiro que você clique em "Continue shopping". O Single e o Browser agora clicam nesse botão na mesma saída e retornam a página do produto. Chamadas via Proxy Finder e Auto recebem o mesmo comportamento.
O Browser também segue uma página que redireciona para outro endereço após carregar, em vez de esgotar o seu timeout. Cookies chamados __Secure- ou __Host- que você envia de volta agora recebem os atributos que o prefixo exige, garantindo que a página veja toda a sua sessão salva.
Proxy Finder e dois erros mais claros
Requests em HTTP puro via Proxy Finder agora abrem uma conexão direta com o site primeiro, da mesma forma que o HTTPS sempre fez. Um proxy que responde com uma página própria, ou entrega o mesmo body para sites não relacionados, é ignorado e sua request avança para o próximo.
Passe a URL do seu próprio proxy para o Single ou Browser com um hostname que não resolve, e a resposta será status 0 com um erro indicando o host, da mesma forma que ocorre com um destino. Uma request direcionada ao próprio api.foura.ai ou eu.api.foura.ai recebe um 400 imediatamente, antes que qualquer coisa seja buscada ou cobrada. O erro aponta a causa comum: um link resolvido em relação à URL da API em vez da página de onde ele veio.
Dashboard, cadastro e faturamento
- O cadastro iniciado em foura.ai agora termina no seu Dashboard, onde a Overview guia você até o primeiro resultado: crie uma API key e envie uma request pelo terminal ou pelo Playground. No celular, os passos começam no Playground, e a porta de proxy tem etapas próprias criadas em torno de um usuário de proxy.
- No celular ou em uma janela estreita, o Playground rola a response para a visualização assim que ela chega.
- O uso por Domain e por Client IP classifica todas as linhas do período antes de dividi-las em páginas, garantindo que a primeira página mostre os registros principais reais.
- Os cards da Overview seguem o período que você selecionar enquanto ainda carregam, o diálogo de período abre no que você está visualizando e a barra lateral traz um link de Docs em Tools.
- As faturas emitidas manualmente agora aparecem na página Billing ao lado das automáticas. Faturas com IVA da UE utilizam a taxa vigente no dia da venda, incluindo alterações anunciadas com antecedência.
Cada um desses itens tem sua própria entrada em updates.foura.ai.
Sob o capô
A porta de proxy mantém uma contagem em tempo real dos seus túneis abertos, e qualquer túnel encerrado após o reinício de uma de nossas instâncias é removido em poucos segundos. Assim, a concorrência permitida pelo seu plano é a concorrência real entregue.
O melhor failover é aquele que você só descobre lendo um resumo.