Les marchés crypto ne ferment jamais. Prix, carnets d’ordres, transactions, taux de financement et statistiques sur 24 heures bougent chaque seconde à travers des centaines d’exchanges, et toute équipe qui collecte ces données, pour de l’analytique, de la recherche, de l’agrégation, ou pour construire un jeu de données, le fait sans arrêt et par-delà les frontières. Cette combinaison fait remonter un ensemble précis de problèmes que l’infrastructure ordinaire gère mal : des limites de débit d’exchange appliquées par IP, des endpoints et produits restreints par pays, et un marché qui punit chaque trou dans votre flux. Les proxys résidentiels gèrent les trois.
Voici la version pratique de la façon dont ils s’insèrent, et de là où une API officielle est un meilleur outil que le scraping d’un front end.
Ce que les équipes de données crypto collectent vraiment
La plupart des données utiles sont des données de marché : dernier prix et statistiques du ticker sur 24 heures par symbole, profondeur du carnet d’ordres, transactions récentes, bougies OHLCV, et taux de financement ou d’intérêt du côté des dérivés. Sur la majorité des exchanges cela vient d’une API publique REST ou WebSocket construite exactement pour ça, et c’est là que vous devriez commencer. Le scraping du front end entre en scène aux marges : un exchange ou une région sans endpoint public pour ce dont vous avez besoin, une page de listings ou d’annonces, une page de statut ou de frais, ou une source de données qui verrouille son API mais laisse le site public ouvert. Le sujet de cet article est la couche de collecte sous l’une ou l’autre approche, et c’est la même couche dans les deux cas.
Pourquoi une seule IP ne suffit pas : les limites de débit
Les limites de débit des exchanges sont strictes, et elles sont presque toujours comptées par IP. Beaucoup utilisent un système de poids où différents endpoints coûtent des montants différents sur un budget par IP qui se recharge sur une fenêtre fixe, et une requête plus lourde comme des snapshots profonds de carnet d’ordres peut dévorer ce budget vite. Sondez quelques centaines de symboles à travers plusieurs exchanges depuis une seule adresse et vous heurtez le plafond en quelques secondes, moment où vous êtes limité, puis banni temporairement, et votre flux s’arrête.
La solution est de cesser d’envoyer tout depuis une seule adresse. Répartir les requêtes sur de nombreuses IP résidentielles signifie que chaque IP reste confortablement dans son propre budget par IP tandis que votre débit agrégé se multiplie, ce qui est la même logique d’équilibrage de charge sur laquelle s’appuie tout collecteur à haut volume, et c’est à quoi servent les connexions concurrentes illimitées. C’est une technique de mise à l’échelle pour des données de marché publiques, pas un moyen de contourner les limites d’un compte donné, et elle devrait être associée au respect des limites documentées et des conditions de chaque exchange plutôt qu’à les traiter comme un obstacle.
Géo-restrictions et données verrouillées par région
La crypto est l’un des espaces les plus fragmentés géographiquement du web. Certains exchanges ne sont pas disponibles dans certaines juridictions du tout, certains restreignent des produits ou endpoints spécifiques par région pour des raisons réglementaires, et certains servent des frais, listings ou interfaces différents selon d’où vient la requête. Si vous collectez depuis un seul emplacement, vous ne pouvez tout simplement pas voir les données qu’un utilisateur dans une autre région autorisée voit, et une requête depuis le mauvais pays peut être bloquée d’emblée.
Un proxy résidentiel avec ciblage par pays et, quand il le faut, au niveau ville vous laisse faire la requête depuis une IP dans une région où ces données sont publiquement disponibles, de sorte que vous collectez ce qu’un visiteur normal de là-bas collecterait. La réserve importante est que c’est un outil pour atteindre des données auxquelles vous avez le droit d’accéder, pas pour contourner une restriction censée s’appliquer à vous. Collectez des données de marché publiques, respectez les conditions de service de chaque exchange et la loi dans les régions où vous opérez, et utilisez le ciblage géographique pour atteindre des données variant géographiquement de façon légitime plutôt que pour contourner une interdiction véritable.
Fiabilité pour un marché qui ne dort jamais
Un marché 24/7 signifie qu’un trou dans la collecte est un trou permanent dans votre jeu de données, et les trous coûtent cher : un backtest, un chiffre de recherche, ou un produit d’analytique bâti sur un flux qui a silencieusement lâché une heure est silencieusement faux. Quand tout passe par une seule IP, un seul événement de limite de débit ou un blocage met tout le flux à terre jusqu’à ce que ça se dégage.
Répartir sur un pool supprime ce point de défaillance unique, et l’associer à un vrai failover garde le flux qui coule quand une route quelconque se dégrade. Détectez une réponse de limite de débit, un timeout, ou un challenge sur une IP donnée, retirez cette route, et continuez sur une nouvelle, ce qui est le schéma derrière le failover dans les pipelines multi-régions. Rien de tout cela ne fonctionne à l’aveugle, alors surveillez le pipeline par exchange et par route : le taux de succès, la latence, et la détection de trous vous disent qu’une source se dégrade avant qu’elle ne devienne un trou dans les données. Parce que beaucoup de données crypto sont sensibles au temps, un pool propre et à faible latence compte aussi, et maintenir la latence basse avec des sorties géographiquement proches et bien réputées réduit à quel point chaque snapshot est périmé quand il arrive.
Sessions sticky pour les flux et les instantanés cohérents
Toute requête ne devrait pas tourner. Deux cas demandent une IP maintenue.
Le premier, ce sont les flux WebSocket, la façon dont arrivent réellement la plupart des données de carnet d’ordres et de transactions en temps réel. Un flux est une seule connexion à longue durée de vie, il lui faut donc une IP maintenue pour sa durée de vie, ce qui signifie une session sticky par flux plutôt qu’une adresse qui tourne sous un socket ouvert. Le second, ce sont les instantanés cohérents. Si vous comparez des prix ou des carnets à travers des exchanges à un instant donné, vous voulez que la série de chaque exchange vienne d’un point de vue stable et cohérent plutôt que d’une IP différente et possiblement d’une région différente à chaque sondage, donc une session sticky par exchange garde cette vue propre. Faites tourner le sondage REST à haut volume pour répartir les limites de débit ; gardez les flux et les flux de comparaison sticky. La qualité de ces IP décide si l’on vous fait confiance tout court, et une adresse propre avec une bonne réputation passe là où une signalée se fait défier.
Préférez l’API officielle, utilisez les proxys pour la mettre à l’échelle
Le cadrage honnête : là où un exchange publie une API publique de données de marché, utilisez-la. Elle est plus rapide, elle renvoie des données structurées, et c’est la voie d’accès que l’exchange prévoit, ce qui vous maintient dans ses conditions. Les proxys résidentiels ne sont pas un remplacement de cette API, ils sont ce qui vous laisse l’exécuter à l’échelle et à travers les géographies : répartissez votre sondage sur des IP pour que chacune reste dans la limite par IP, ciblez des pays pour atteindre des données publiques spécifiques à une région, maintenez des sessions sticky pour les flux, et faites du failover pour garder le flux en vie. Réservez le scraping du front end aux véritables trous, une page sans API derrière, et traitez-le avec la même retenue, données publiques seulement, dans les conditions du site et le droit applicable. Ceci est de la collecte de données, pas du trading ni du conseil financier, et rien ici n’est une recommandation sur un quelconque actif.
Un montage minimal
Un proxy résidentiel rotatif pour le sondage REST ressemble à un proxy ordinaire pour votre client. Le ciblage vit dans le nom d’utilisateur sur le gateway, donc une sortie US sans identifiant de session tourne par requête :
import requests
PROXY = "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443"proxies = {"http": PROXY, "https": PROXY}
# Public ticker endpoint, one symbol, through a rotating US residential IPr = requests.get( "https://api.exchange.example/v1/ticker?symbol=BTC-USD", proxies=proxies, timeout=10,)r.raise_for_status()print(r.json())Répartissez une grande liste de symboles sur beaucoup de ces appels pour qu’aucune IP ne porte toute la charge, et sur une réponse de limite de débit ou un timeout, retirez cette route et réessayez sur une nouvelle. Pour un flux WebSocket, ajoutez un identifiant de session pour maintenir une IP pendant la durée de vie de la connexion, par exemple customer-USERNAME-country-us-sid-book42, et donnez à chaque flux son propre identifiant. Les mêmes schémas de client se reportent depuis le guide général pour utiliser les proxys résidentiels avec Python.
En résumé
Collecter les données d’exchanges et de marché crypto est borné par trois choses : des limites de débit par IP qu’une seule adresse heurte presque immédiatement, des endpoints et produits verrouillés par région que vous ne pouvez pas atteindre depuis un seul emplacement, et un marché 24/7 qui transforme chaque trou en trou permanent. Les proxys résidentiels répondent aux trois. Répartissez votre sondage sur un pool pour multiplier le débit effectif tandis que chaque IP reste dans son budget, ciblez des pays pour collecter les données publiques qu’une région autorisée voit, maintenez des sessions sticky pour les flux et les instantanés inter-exchanges, et faites du failover avec surveillance pour que le flux ne s’arrête jamais en silence. Utilisez les API officielles partout où elles existent, tenez-vous-en aux données publiques et aux conditions de chaque exchange, et laissez la couche proxy faire ce en quoi elle est bonne : l’échelle et la géographie.
Cette couche est ce à quoi servent les proxys résidentiels, un grand pool d’IP réelles de niveau domestique avec ciblage par pays et ville et sessions sticky quand vous en avez besoin. La tarification au Go signifie que vous payez pour les données que vous tirez réellement, ce qui convient à une charge de travail faite surtout de petites requêtes de données de marché fréquentes tournant en continu.