Cómo reducir de forma efectiva los bloqueos de cuentas en servicios de relay de IA
Wokey Team · 2026-06-27
Los proveedores de modelos acaban de lanzar una oleada masiva de bloqueos de cuentas, tan amplia que incluso usuarios individuales con un uso legítimo quedaron atrapados en el fuego cruzado.
Si operas un servicio de relay, o si estás eligiendo uno, vale la pena pensarlo en serio: ¿los bloqueos son cuestión de suerte o de arquitectura?
Mi respuesta es lo segundo. Las tasas de bloqueo no son aleatorias: las determina la arquitectura.
Veamos el panorama completo. Cuando los proveedores deciden si una cuenta se está compartiendo o revendiendo, suelen fijarse en estas señales:
- Cambios de IP y tipo de IP: tus solicitudes saltan de repente de una IP residencial a una IP de centro de datos, o pasan por distintas ubicaciones geográficas.
- Anomalías de comportamiento: frecuencia de llamadas, concurrencia y distribución horaria que claramente no parecen de una sola persona.
- Varias cuentas compartiendo una salida: las solicitudes de decenas de cuentas canalizadas por el mismo grupo de IP.
- Anomalías en la huella del cliente: encabezados de solicitud, huella TLS y características del dispositivo que no coinciden con un cliente normal.
Si se acumulan estas señales, el sistema de riesgo del proveedor marca tu cuenta.
Pero si me preguntas qué señal pesa más y es más fácil de detectar, diría que la IP.
La razón es sencilla: la IP es el criterio de filtrado más externo y de menor costo. Una solicitud desde una IP residencial frente a una desde una IP de centro de datos representa un nivel de riesgo totalmente distinto a ojos de un sistema de riesgo. ASN de centro de datos + IP que cambia + anomalía geográfica: cuando estas tres aparecen juntas, prácticamente le están diciendo al sistema de riesgo "este no es un usuario normal".
Sinceramente, la arquitectura de los servicios de relay convencionales cae justo sobre esta mina: todas las solicitudes salen desde los servidores del relay, con decenas de cuentas compartiendo el mismo grupo de IP de centro de datos. Por más que balancees la carga o rotes tu pool de proxies, el punto de salida es, en esencia, una sala de servidores. He revisado las soluciones de otros operadores de relay: rotan proxies con mucha dedicación, pero una consulta rápida de ASN revela que todos son proveedores de nube. Otra máscara, la misma cara.
Por eso hay gente que cambia entre tres servicios de relay y la bloquean cada dos semanas en cada uno: no es mala suerte, es que todos los servicios tienen la misma arquitectura.
Entonces, ¿cómo mantienes la IP sin cambios?
Si eres un usuario individual, ya existe un enfoque bien establecido: despliega un gateway unificado como New API o One API en un NAS de tu casa, o usa herramientas como sam-to-API, y haz pasar por él todas las API de los proveedores. Tu celular, tu laptop, cualquier cliente que llame a un modelo: ninguno se conecta directamente al proveedor. En su lugar, pasan por tu dispositivo de casa, que reenvía a la API del proveedor. Así, llames al modelo que llames, la IP de salida que ve el proveedor siempre es la IP de tu conexión de banda ancha doméstica, indistinguible de estar sentado en casa usándolo con normalidad.
¿Y cuando estás fuera? Usa herramientas de red mesh como Tailscale o WireGuard para enviar primero el tráfico de tu celular o laptop al NAS de tu casa y que salga desde allí. Estés en una cafetería, en la oficina o en un tren, tus solicitudes siguen saliendo desde tu conexión doméstica. El proveedor nunca ve que tu IP salta solo porque cambiaste de Wi-Fi o activaste los datos móviles.
Este enfoque está bien probado en la comunidad de fnOS y en el ámbito del autoalojamiento de IA, con muchos tutoriales y usuarios que lo aplican. Para usuarios individuales, es actualmente la solución más confiable para fijar la IP.
Pero esto solo resuelve el problema de una persona.
Un servicio de relay gestiona cuentas de decenas o cientos de Providers. No puedes ir a la casa de cada uno a instalar un NAS y configurar un gateway. Necesitas una solución sistemática que permita a cada Provider instalar un nodo ligero y conectarse a la plataforma: las solicitudes siguen saliendo desde la propia red del Provider, pero la distribución de pedidos y el enrutamiento del tráfico los gestiona la plataforma de forma centralizada.
Esta arquitectura se llama salida del lado del Provider (provider-side exit): las solicitudes salen desde la propia red del Provider, no desde los servidores del relay.
Una analogía: el enfoque del NAS es como tener tu propia tienda en la carretera: envías desde casa y te encargas tú solo del abastecimiento, la selección y los pedidos. Un Provider Node es como unirte a la franquicia de una plataforma: sigues enviando desde casa, pero la plataforma te asigna los pedidos. La dirección de envío no cambia; lo que cambia es quién asigna los pedidos.
Esto es lo que hace Wokey Provider Node.
La instalación es sencilla: un solo comando, compatible con macOS, Linux, Windows y Docker. Después de instalarlo, abre la consola local, vincula tu cuenta de Wokey e importa las credenciales de tu suscripción local. Cuando el nodo arranca, mantiene una conexión WebSocket con la plataforma Wokey. La plataforma le envía las solicitudes de los usuarios y el nodo hace la solicitud a la API del proveedor desde tu equipo. Todo el proceso sale desde la propia IP del Provider: para el proveedor, es idéntico a que el Provider use su propia suscripción con normalidad.
Los proveedores compatibles actualmente incluyen OpenAI/Codex, Anthropic/Claude, Zhipu, Kimi, DeepSeek, Gemini, xAI y más.
Después de operar esta arquitectura yo mismo, la conclusión más clara es esta: no "pelea" contra los controles de riesgo; simplemente nunca activa las condiciones previas para la detección de riesgo. Desde la perspectiva del proveedor, es solo un usuario normal en su casa usando su propia suscripción, sin nada anómalo que explicar.
Todo el proyecto es de código abierto bajo Apache-2.0, con la lista blanca de salidas fijada en el código fuente. No es seguro porque yo lo diga: es seguro porque cada línea de código se puede auditar.
Por supuesto, no voy a afirmar que la salida del lado del Provider garantiza cero bloqueos. La IP es solo un factor: la frecuencia de llamadas, los patrones de concurrencia y la distribución horaria también pueden activar los controles de riesgo. Ninguna solución puede garantizar una tasa de bloqueo de cero.
Pero la lógica es clara: si no has resuelto la señal más importante, cualquier otra optimización es construir sobre arena.
La clave para reducir las tasas de bloqueo es que tu uso sea indistinguible de lo normal. Mantener la IP sin cambios es la pieza más importante. Los usuarios individuales tienen soluciones individuales; los servicios de relay necesitan un enfoque sistemático de salida del lado del Provider.
Cuando la competencia entre relays llegue a su fase final, no se tratará de quién tiene más modelos o precios más bajos, sino de qué arquitectura hace que el proveedor no pueda saber que eres un relay. El servicio que usas ahora mismo: ¿desde la red de quién salen las solicitudes?