La lista blanca de IP de la API de Binance es la medida de seguridad más crítica: una vez configurada, solo las solicitudes provenientes de las IP especificadas podrán usar esa clave para operar la cuenta. Incluso si la clave se filtra, los atacantes no podrán colocar órdenes. Este artículo cubre las soluciones completas de configuración para cinco escenarios: IP fija en servidores cloud, IP dinámica en banda ancha doméstica, salida multi-IP, proxies VPN e IPv6, junto con scripts de consulta y 10 errores comunes. Si aún no tiene una cuenta de Binance, complete su registro en el sitio oficial de Binance; los nuevos usuarios pueden registrarse gratis aquí.
I. Reglas fundamentales de la lista blanca de IP
| Regla | Descripción |
|---|---|
| Máximo de IP por clave | 30 IP |
| Tipo de IP | Solo admite IPv4 (IPv6 no soportado actualmente) |
| Segmentos CIDR | No soportados (debe ingresar cada IP individualmente) |
| Tiempo de activación | Inmediato tras guardar (menos de 30 segundos) |
| Permiso de retiro | Requiere obligatoriamente lista blanca de IP (si no se limita la IP, el permiso de retiro se desactiva forzosamente) |
| Frecuencia de modificación | Sin límite, se puede ajustar en cualquier momento |
Importante: Una clave sin lista blanca de IP nunca podrá activar el permiso de retiro, esta es una regla de seguridad obligatoria de Binance.
II. Escenario 1: Servidor en la nube (IP estática)
Es el escenario ideal. Al crear la API, simplemente ingrese la IP pública de su servidor cloud.
1. Consultar la IP pública del servidor cloud
# Método 1: Consultar servicios externos
curl -4 ifconfig.me
curl -4 ipv4.icanhazip.com
curl -4 api.ipify.org
# Método 2: Metadatos de Alibaba Cloud
curl http://100.100.100.200/latest/meta-data/eipv4
# Método 3: Metadatos de AWS
curl http://169.254.169.254/latest/meta-data/public-ipv4
2. Configuración en Binance
Página de gestión de API de Binance → Editar clave → Restringir acceso solo a IP de confianza (Recomendado) → Ingresar direcciones IP → Guardar.
Múltiples IP deben estar separadas por comas:
1.2.3.4,5.6.7.8,9.10.11.12
3. Notas para servidores cloud
- Las IP elásticas no se conservan tras ser desvinculadas; asegúrese de eliminarlas de la lista blanca de Binance sincronizadamente.
- Las instancias de grupos de auto-escalado cambian de IP pública, lo cual no es apto para listas blancas; se recomienda usar un NAT Gateway para fijar la IP de salida.
- Proxies inversos CDN no son aplicables: Binance verá la IP del proveedor de CDN, no la IP real de su servidor back-end.
III. Escenario 2: Banda ancha doméstica (IP dinámica)
La IP de casa puede cambiar cada 24 horas. Existen varias soluciones:
Opción A: Sin restricción de IP (Simple pero riesgoso)
En la gestión de API, seleccione Sin restricciones (Menos seguro). Desventajas:
- El permiso de retiro se desactiva automáticamente.
- No hay protección si se filtra la clave.
Apto solo para lectura de datos (marcando solo "Enable Reading").
Opción B: Actualización dinámica de la lista blanca (Nivel medio)
Binance no ofrece una API para actualizar la lista blanca, debe hacerse manualmente en la web. Por lo tanto, la automatización total no es posible.
Se puede hacer un sistema semi-automático:
- Detectar la IP de salida actual cada hora.
- Compararla con la IP configurada en la lista blanca.
- Si difieren, enviar una notificación (vía Telegram o similar).
- Iniciar sesión manualmente en Binance para actualizarla.
Ejemplo de script:
import requests
import time
CURRENT_WHITELIST = {"1.2.3.4"} # La IP configurada en Binance
TG_BOT = "TELEGRAM_BOT_TOKEN"
TG_CHAT = "TU_CHAT_ID"
def get_current_ip():
return requests.get("https://api.ipify.org").text.strip()
def notify(msg):
requests.get(
f"https://api.telegram.org/bot{TG_BOT}/sendMessage",
params={"chat_id": TG_CHAT, "text": msg}
)
last_ip = None
while True:
ip = get_current_ip()
if ip != last_ip:
if ip not in CURRENT_WHITELIST:
notify(f"La IP ha cambiado a {ip}, por favor actualice la lista blanca en Binance")
last_ip = ip
time.sleep(3600)
Opción C: DDNS + Punto de entrada fijo (Recomendado)
Use un servidor cloud con IP fija como proxy inverso o puente:
PC de casa → Túnel SSH → Servidor Cloud → API de Binance
En el servidor cloud (por ejemplo, uno económico de 5 USD/mes):
# Crear túnel SSH desde el PC de casa
ssh -N -L 8443:api.binance.com:443 [email protected]
Luego, en su código, cambie la BASE_URL a https://localhost:8443 (manejando la validación del certificado TLS). Simplemente añada la IP fija del servidor cloud a la lista blanca.
Una solución más elegante es configurar una VPN WireGuard para que todo el tráfico del PC doméstico salga por el VPS.
IV. Escenario 3: Equilibrio de carga multi-servidor
Las estrategias cuantitativas de nivel de producción suelen desplegarse en varios servidores para redundancia:
Estrategia principal: Alibaba Cloud Tokio Zona A (IP: 47.1.2.3)
Estrategia de respaldo: AWS Tokio Zona B (IP: 54.4.5.6)
Servicio de monitoreo: Tencent Cloud Hong Kong (IP: 150.7.8.9)
Ingrese las 3 IP en Binance, separadas por comas:
47.1.2.3,54.4.5.6,150.7.8.9
Refuerzo de seguridad: Cree claves independientes para cada servidor en lugar de compartir una sola. Así, si una máquina se ve comprometida, solo tendrá que revocar esa clave y las demás seguirán funcionando.
V. Escenario 4: IP de salida mediante VPN / Proxy
1. Confirmar la IP de salida final de la cadena de proxy
Una VPN o proxy hará que el tráfico salga por la IP del proxy en lugar de su IP real:
# Consulta a través de proxy
curl -x http://proxy.ejemplo.com:8080 ifconfig.me
# O consulta tras activar VPN
curl ifconfig.me
Añada la IP de salida del proxy a la lista blanca.
2. Riesgos de salidas compartidas
Las IP de salida de los proxies comerciales suelen ser compartidas por miles de personas. Estas IP:
- Aparecen frecuentemente en las listas negras de Binance (por ser usadas para spam o lavado).
- Si alguien activa el control de riesgo, toda la IP de salida se bloquea, afectando a todos los usuarios.
- No cumplen con los requisitos de KYC de Binance y pueden activar auditorías de cuenta.
No se recomiendan proxies comerciales para trading vía API. Un VPS propio con IP exclusiva es la opción más segura.
VI. Escenario 5: Contenedores Docker / Kubernetes
La IP de salida de un contenedor depende de la configuración de red del host:
1. Modo de red Host
# Docker Compose
services:
bot:
image: mi_bot
network_mode: "host" # El contenedor usa la IP del host
En este caso, la IP de salida del contenedor es la IP pública del host.
2. Red Bridge + NAT
services:
bot:
image: mi_bot
networks:
- default
Docker usa NAT por defecto, por lo que la salida sigue siendo la IP pública del host (a menos que el host tenga múltiples tarjetas de red apuntando a salidas distintas).
3. Kubernetes
Se usa un NAT Gateway o Egress Gateway para unificar la IP de salida. Proveedores cloud (GKE, EKS, Alibaba Cloud ACK) soportan funciones de IP de salida fija.
VII. Razones comunes por las que falla la lista blanca de IP
| Síntoma | Causa | Solución |
|---|---|---|
| Nueva IP no está en lista blanca, error -2015 | La IP cambió y no se sincronizó | Actualizar en la web de Binance |
| IP no cambia tras reiniciar VPS pero falla la llamada | Bloqueo por firewall o VPC | Revisar reglas de salida |
| curl funciona, pero falla el script Python | Python usa proxy socks5 | Revisar variable de entorno http_proxy |
| curl ifconfig.me muestra A, pero Binance reporta B | Múltiples tarjetas con rutas distintas | Revisar con route -n |
| Fallo inmediatamente después de añadir la IP | Caché no refrescada | Esperar 30 segundos y reintentar |
| El script sale por IP doméstica al caer la VPN | VPN sin "kill switch" | Configurar iptables para bloquear tráfico fuera de VPN |
VIII. Doble seguro: Verificación de IP en la capa de aplicación
Incluso si Binance limita la IP, su programa debería autoverificarse al iniciar:
import requests
IP_ESPERADA = "1.2.3.4"
def verificar_ip():
actual = requests.get("https://api.ipify.org").text.strip()
if actual != IP_ESPERADA:
raise SystemExit(f"IP de salida anómala: {actual} ≠ {IP_ESPERADA}, inicio rechazado")
print(f"Verificación de IP exitosa: {actual}")
verificar_ip()
# Solo entonces se inicializa el cliente de Binance
IX. Preguntas frecuentes (FAQ)
P1: ¿Cuántas IP se pueden configurar en una sola clave?
R: Hasta 30 IP, ingresándolas en el mismo campo separadas por comas. Si tiene más de 30 servidores, se recomienda crear varias claves por grupos de servidores.
P2: ¿Se puede añadir una IP de China continental a la lista blanca?
R: Puede ingresar cualquier dirección IPv4; los servidores de Binance no rechazan IP de regiones específicas para la lista blanca. Sin embargo, la conexión directa desde China a binance.com es inestable; se recomienda usar un VPS en Hong Kong o Singapur como intermediario.
P3: ¿Cuál es la diferencia entre lista blanca de IP y firewall?
R: La lista blanca es un control de acceso en el lado de Binance (limita el origen de las solicitudes); el firewall es un control en su servidor (limita el tráfico entrante). Son complementarios y ambos deben configurarse.
P4: Mi VPS soporta IPv6, pero Binance no. ¿Qué hago?
R: Binance no soporta listas blancas de IPv6 por ahora. Solución: Use curl -4 para forzar IPv4 o desactive IPv6 a nivel de sistema:
# En Linux
sysctl -w net.ipv6.conf.all.disable_ipv6=1
P5: Tras configurar la lista blanca, ¿las consultas de mercado también deben venir de esa IP?
R: Sí. La lista blanca restringe todas las solicitudes que lleven el encabezado X-MBX-APIKEY, incluyendo interfaces de firma y USER_DATA. Los datos públicos de mercado (como /ticker/price sin Header) no están restringidos.
Tras configurar su esquema de lista blanca de IP, regrese a la Navegación de categorías para consultar otros tutoriales de seguridad en la sección «Integración API».