Nouveautés

La signature par défaut envoyée par l'unblocker correspond désormais à une version majeure actuelle, et non plus à l'ancienne version codée en dur par les scrapers. Les sites qui avaient commencé à renvoyer des pages de blocage statiques aux versions majeures plus anciennes renvoient leur vraie page sur Single et Browser. Les deux produits ont évolué ensemble, donc un rejeu cf_clearance de Browser vers Single correspond toujours octet par octet.

Auparavant, Browser facturait le palier de 30 crédits pour la résolution de défense uniquement lorsqu'un cookie de validation Cloudflare apparaissait. Désormais, il fait de même pour toute défense que nous reconnaissons et contournons, à commencer par SiteGround. La réponse inclut également defenses: { present, cleared }, vous permettant d'identifier le fournisseur qui faisait obstacle, même si nous ne l'avons pas encore contourné (DataDome, PerimeterX, Akamai, Incapsula et hCaptcha sont reconnus pour le moment, mais pas encore contournés).

Les réponses du navigateur renvoient désormais defenses: { present, cleared } : chaque fournisseur exécuté par la cible, et tous ceux que nous avons réellement contournés. La facturation suit la même règle. Une requête qui contourne un fournisseur (et pas seulement Cloudflare) constitue une résolution de défense. Les fournisseurs que nous identifions mais ne pouvons pas encore contourner apparaissent dans present et n'augmentent jamais le prix.

Si vous passez exitCountries et que votre forfait n'inclut pas le ciblage géographique, vous recevrez une erreur 403 indiquant le paramètre et la solution. Plus besoin de deviner quel champ de la requête a déclenché la vérification. Les forfaits qui incluent le ciblage géographique ne sont pas affectés.

Le tableau comparatif des forfaits comporte maintenant une ligne pour la bande passante. Chaque forfait public inclut la bande passante illimitée, le trafic sortant ne consommera donc pas discrètement votre budget à mesure que votre trafic augmente. Les forfaits personnalisés affichent leur volume exact en Go lorsqu'ils sont plafonnés.

Tout worker déconnecté entre les versions restait hors ligne jusqu'à ce que quelqu'un le remarque, réduisant silencieusement la capacité aux heures de pointe. Désormais, chaque déploiement rétablit la pleine capacité du pool en parallèle de la mise à jour continue, afin que les pics de trafic s'appuient sur la capacité que vous attendez.

Utilisation et limites dispose désormais de points d'attention par onglet, de barres d'utilisation colorées (orange à 80 %, rouge une fois la limite dépassée), d'une colonne Dernière utilisation triable et d'une actualisation automatique toutes les 30 secondes. Ouvrez-le depuis la barre latérale dans votre Dashboard.

Le tableau de comparaison de la page des tarifs est désormais regroupé par utilisation, fonctionnalités, rate limits et compte. Chaque cellule provient du même modèle de forfait que l'API lit, ce que vous y voyez est donc ce que votre forfait inclut réellement. La bande passante est illimitée sur tous les forfaits publics.

Proxy Finder exécute désormais ses trois vérifications de disponibilité simultanément au lieu de l'une après l'autre, de sorte que les sorties mortes sont recyclées environ trois fois plus vite. Une correction de blocage en tête de file maintient le débit de validation stable lorsqu'un sous-réseau atteint son rate limit. Attendez-vous à moins de proxies obsolètes sélectionnés pour vos requests.

Les proxies sont désormais validés en continu depuis un chemin réseau distinct, de sorte que le pool actif ne conserve que les sorties qui fonctionnent réellement en ce moment (et pas seulement au moment de leur découverte). Lorsque vous appelez /api/proxy ou laissez /api/auto router votre requête, le proxy sélectionné a plus de chances de fonctionner du premier coup.

L'API bloque toute requête Single ou Browser dont l'URL cible, la chaîne de redirection ou le champ proxy correspond à une plage d'adresses IP privée ou réservée. Même si une cible publique redirige vers un réseau interne, la requête s'arrête avant d'y parvenir.

Le sélecteur de langue du site principal, du blog, de la documentation et du portail de mises à jour a été entièrement revu. Chaque option affiche le nom natif de la langue ainsi que son nom dans la langue de votre interface actuelle (par exemple 'Deutsch · немски' sur le site bulgare), avec un champ de recherche qui filtre les 13 locales par nom, code ou identifiant de locale. Chaque option est désormais un vrai lien avec hreflang, afin que les moteurs de recherche et les robots d'IA puissent suivre chaque traduction, et vous pouvez faire un cmd-clic pour ouvrir une autre langue dans un nouvel onglet. Le sélecteur se trouve également dans le pied de page de chaque site.

Auto réduisait auparavant le TTL de session d'un hôte à chaque échec de rejeu, même lorsque l'échec ne reflétait pas une véritable expiration du cookie. Les sessions continuaient d'être évincées et résolues à nouveau alors que leurs cookies fonctionnaient encore. Le TTL augmente désormais lors des succès prolongés et ne diminue que lors des véritables expirations, de sorte qu'une session apprise pour un hôte autorisé par Cloudflare peut se maintenir pendant plusieurs minutes au lieu de s'interrompre après la première erreur 403.

Les sessions automatiques s'adaptent désormais aux besoins de chaque cible. Les sites sans défis interactifs s'exécutent comme des sessions portables où les cookies utilisent le pool de proxy, la rotation et le basculement se font donc automatiquement. Les sites qui lient leur déverrouillage à une seule sortie (Cloudflare interactif étant le principal) sont épinglés avec un plafond de simultanéité par autorisation, afin qu'une rafale de requêtes répétées ne puisse pas épuiser votre déverrouillage.

Les aperçus de requêtes dans Activité affichent désormais l'ID de proxy opaque partout, correspondant à ce que les réponses renvoyaient déjà.