Los mercados de cripto nunca cierran. Precios, libros de órdenes, operaciones, tasas de financiación y estadísticas de 24 horas se mueven cada segundo en cientos de exchanges, y cualquier equipo que recopile esos datos, para analítica, investigación, agregación, o construir un dataset, lo hace sin parar y a través de fronteras. Esa combinación saca a la luz un conjunto concreto de problemas que la infraestructura corriente maneja mal: límites de tasa de los exchanges que se aplican por IP, endpoints y productos restringidos por país, y un mercado que castiga cada hueco en tu feed. Los proxies residenciales resuelven los tres.
Esta es la versión práctica de cómo encajan, y de dónde una API oficial es mejor herramienta que hacer scraping a un front end.
Qué recopilan de verdad los equipos de datos cripto
La mayoría de los datos útiles son datos de mercado: último precio y estadísticas del ticker de 24 horas por símbolo, profundidad del libro de órdenes, operaciones recientes, velas OHLCV, y tasas de financiación o de interés en el lado de derivados. En la mayoría de los exchanges esto viene de una API pública REST o WebSocket construida exactamente para esto, y ahí es donde deberías empezar. El scraping del front end entra en escena en los márgenes: un exchange o región sin un endpoint público para lo que necesitas, una página de listados o de anuncios, una página de estado o de comisiones, o una fuente de datos que restringe su API pero deja el sitio público abierto. El objetivo de este artículo es la capa de recopilación que hay debajo de cualquiera de los dos enfoques, y es la misma capa en ambos casos.
Por qué una sola IP no basta: los límites de tasa
Los límites de tasa de los exchanges son estrictos, y casi siempre se cuentan por IP. Muchos usan un sistema de peso donde distintos endpoints cuestan cantidades distintas contra un presupuesto por IP que se recarga en una ventana fija, y una consulta más pesada como snapshots profundos del libro de órdenes puede comerse ese presupuesto rápido. Sondea unos cientos de símbolos a través de varios exchanges desde una única dirección y golpeas el techo en segundos, momento en el que quedas limitado, luego baneado temporalmente, y tu feed se detiene.
La solución es dejar de enviarlo todo desde una sola dirección. Repartir las solicitudes a través de muchas IP residenciales significa que cada IP se mantiene cómodamente dentro de su propio presupuesto por IP mientras tu rendimiento agregado se multiplica, que es la misma lógica de balanceo de carga en la que se apoya cualquier recopilador de alto volumen, y es para lo que sirven las conexiones concurrentes ilimitadas. Esto es una técnica de escalado para datos de mercado públicos, no una manera de sortear los límites de una cuenta concreta, y debería combinarse con respetar los límites documentados y los términos de cada exchange en lugar de tratarlos como un obstáculo.
Geo-restricciones y datos bloqueados por región
Cripto es uno de los espacios más fragmentados geográficamente de la web. Algunos exchanges no están disponibles en ciertas jurisdicciones del todo, algunos restringen productos o endpoints específicos por región por motivos regulatorios, y algunos sirven distintas comisiones, listados o interfaces según de dónde venga la solicitud. Si recopilas desde una única ubicación, simplemente no puedes ver los datos que ve un usuario en otra región permitida, y una solicitud desde el país equivocado puede ser bloqueada de plano.
Un proxy residencial con targeting por país y, cuando hace falta, a nivel de ciudad te deja hacer la solicitud desde una IP en una región donde esos datos están públicamente disponibles, de modo que recopilas lo que recopilaría un visitante normal de allí. La advertencia importante es que esto es una herramienta para alcanzar datos a los que tienes permiso de acceder, no para evadir una restricción que está pensada para aplicarte a ti. Recopila datos de mercado públicos, respeta los términos de servicio de cada exchange y la ley en las regiones donde operas, y usa el targeting geográfico para alcanzar datos que varían por geografía de forma legítima en lugar de para rodear una prohibición genuina.
Fiabilidad para un mercado que nunca duerme
Un mercado 24/7 significa que un hueco en la recopilación es un agujero permanente en tu dataset, y los agujeros son caros: un backtest, una cifra de investigación, o un producto de analítica construido sobre un feed que dejó caer silenciosamente una hora está silenciosamente equivocado. Cuando todo corre a través de una sola IP, un único evento de límite de tasa o un bloqueo tumban el feed entero hasta que se despeja.
Repartir a través de un pool elimina ese único punto de fallo, y combinarlo con un failover real mantiene el feed fluyendo cuando cualquier ruta se degrada. Detecta una respuesta de límite de tasa, un timeout, o un desafío en una IP dada, retira esa ruta, y continúa por una nueva, que es el patrón detrás del failover en pipelines multi-región. Nada de esto funciona a ciegas, así que monitoriza el pipeline por exchange y por ruta: la tasa de éxito, la latencia, y la detección de huecos te dicen que una fuente se está degradando antes de que se convierta en un agujero en los datos. Como muchos datos cripto son sensibles al tiempo, un pool limpio y de baja latencia también importa, y mantener baja la latencia con salidas geográficamente cercanas y de buena reputación reduce cuán rancio está cada snapshot cuando aterriza.
Sesiones sticky para streams e instantáneas coherentes
No toda solicitud debería rotar. Dos casos piden una IP retenida.
El primero son los streams de WebSocket, que es como llega de verdad la mayoría de los datos de libro de órdenes y operaciones en tiempo real. Un stream es una única conexión de larga vida, así que necesita una IP retenida durante toda su vida, lo que significa una sesión sticky por stream en lugar de una dirección que rota por debajo de un socket abierto. El segundo son las instantáneas coherentes. Si comparas precios o libros a través de exchanges en un momento en el tiempo, quieres que la serie de cada exchange venga de un punto de vista estable y consistente en lugar de una IP distinta y posiblemente una región distinta en cada sondeo, así que una sesión sticky por exchange mantiene esa vista limpia. Rota el sondeo REST de alto volumen para repartir los límites de tasa; mantén sticky los streams y los feeds de comparación. La calidad de esas IP decide si eres confiable en absoluto, y una dirección limpia con buena reputación pasa donde una marcada recibe desafíos.
Prefiere la API oficial, usa los proxies para escalarla
El encuadre honesto: donde un exchange publica una API pública de datos de mercado, úsala. Es más rápida, devuelve datos estructurados, y es la vía de acceso que el exchange pretende, lo que te mantiene dentro de sus términos. Los proxies residenciales no son un sustituto de esa API, son lo que te deja ejecutarla a escala y a través de geografías: reparte tu sondeo entre IP para que cada una se mantenga dentro del límite por IP, apunta a países para alcanzar datos públicos específicos de una región, retén sesiones sticky para los streams, y haz failover para mantener el feed vivo. Reserva el scraping del front end para los huecos genuinos, una página sin API detrás, y trátalo con la misma contención, solo datos públicos, dentro de los términos del sitio y la ley aplicable. Esto es recopilación de datos, no trading ni asesoramiento financiero, y nada de lo aquí escrito es una recomendación sobre ningún activo.
Un montaje mínimo
Un proxy residencial rotativo para el sondeo REST le parece a tu cliente un proxy corriente. El targeting vive en el nombre de usuario en el gateway, así que una salida de EE. UU. sin identificador de sesión rota por solicitud:
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())Reparte una lista grande de símbolos entre muchas de esas llamadas para que ninguna IP cargue con todo, y ante una respuesta de límite de tasa o un timeout, retira esa ruta y reintenta por una nueva. Para un stream de WebSocket, añade un identificador de sesión para retener una IP durante la vida de la conexión, por ejemplo customer-USERNAME-country-us-sid-book42, y dale a cada stream su propio identificador. Los mismos patrones de cliente se trasladan desde la guía general de usar proxies residenciales con Python.
En resumen
Recopilar datos de exchanges y de mercado de cripto está acotado por tres cosas: límites de tasa por IP que una sola dirección golpea casi de inmediato, endpoints y productos bloqueados por región que no puedes alcanzar desde una ubicación, y un mercado 24/7 que convierte cada hueco en un agujero permanente. Los proxies residenciales responden a los tres. Reparte tu sondeo a través de un pool para multiplicar el rendimiento efectivo mientras cada IP se mantiene dentro de su presupuesto, apunta a países para recopilar los datos públicos que ve una región permitida, retén sesiones sticky para los streams y las instantáneas entre exchanges, y haz failover con monitorización para que el feed nunca se detenga en silencio. Usa APIs oficiales dondequiera que existan, cíñete a los datos públicos y a los términos de cada exchange, y deja que la capa de proxy haga aquello en lo que es buena: escala y geografía.
Esa capa es para lo que están los proxies residenciales, un gran pool de IP reales de nivel doméstico con targeting por país y ciudad y sesiones sticky cuando las necesitas. El precio por GB significa que pagas por los datos que de verdad extraes, lo que le va bien a una carga de trabajo que es en su mayoría solicitudes de datos de mercado pequeñas y frecuentes corriendo de forma continua.