Despliegue de Plataforma Trading via Tunel SSH — Lecciones desde China

El Problema de Infraestructura que Enfrenta Toda Plataforma de Trading

Si alguna vez has construido una plataforma de trading que necesita atender a usuarios en múltiples países, ya conoces el problema: China Mobile bloquea las conexiones SSH directas a servidores en el extranjero. Sin advertencia, sin mensaje de error — solo silenciosos tiempos de espera de conexión que te hacen pensar que tu servidor está caído cuando en realidad está funcionando.

Nuestra configuración: el terminal principal de se ejecuta en un servidor RackNerd (107.174.186.162) en EE. UU., pero todo el desarrollo se realiza desde China. ¿SSH directo? Bloqueado. ¿Proxy basado en VPN? Poco fiable para scripts de despliegue automatizados. La solución que encontramos después de semanas de intentos fallidos es una cadena SSH simple pero efectiva.

La Arquitectura de Salto JD Cloud

La clave: China Mobile bloquea SSH en el extranjero, pero los servidores cloud domésticos pueden conectarse libremente a servidores en el extranjero. Así que usamos un servidor Windows de JD Cloud (京东云) (111.228.37.165) como servidor de salto:

PC Local (China)
  → Servidor de salto JD Cloud (IP doméstica, 111.228.37.165)
    → Servidor destino RackNerd (IP extranjera, 107.174.186.162)

En Python con Paramiko, esto se ve así:

import paramiko

# Paso 1: Conectar a JD Cloud
ssh_jd = paramiko.SSHClient()
ssh_jd.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh_jd.connect('111.228.37.165', port=22, username='root', password='***')

# Paso 2: Abrir un canal TCP directo a través de JD Cloud hacia RackNerd
channel = ssh_jd.get_transport().open_channel(
    'direct-tcpip', 
    ('107.174.186.162', 22),  # Destino
    ('127.0.0.1', 22)         # Origen
)

# Paso 3: Conectar a RackNerd a través del canal
ssh_rn = paramiko.SSHClient()
ssh_rn.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh_rn.connect('107.174.186.162', port=22, username='root', password='***', sock=channel)

# Ahora ssh_rn está conectado — usa sftp, exec_command, etc.
sftp = ssh_rn.open_sftp()
sftp.put('local_file.html', '/var/www/blog/tools/file.html')

La llamada open_channel('direct-tcpip', ...) es la magia — le indica al servidor JD Cloud que reenvíe una conexión TCP al destino, creando efectivamente un túnel SSH sin necesidad de configurar el reenvío de puertos en el servidor de salto.

El Problema de Velocidad de Despliegue

Una vez que la cadena SSH funciona, el siguiente problema es la velocidad. Con más de 200 archivos HTML para desplegar, subirlos uno por uno a través del túnel SSH lleva una eternidad. Nuestro primer intento subió archivos individualmente — se agotó el tiempo a los 300 segundos después de procesar solo aproximadamente la mitad de los archivos.

La solución: empaquetar todo en un solo tar.gz, subir una vez, extraer en el servidor:

import tarfile, os

# Empaquetar localmente
with tarfile.open('upload.tar.gz', 'w:gz') as tar:
    for f in os.listdir('tools/'):
        if f.endswith(('.html', '.json')):
            tar.add(f'tools/{f}')

# Subir un solo archivo
sftp.put('upload.tar.gz', '/tmp/upload.tar.gz')

# Verificar coincidencia de tamaño (crítico — hemos visto subidas truncadas)
assert sftp.stat('/tmp/upload.tar.gz').st_size == os.path.getsize('upload.tar.gz')

# Extraer en el servidor
ssh_rn.exec_command('cd /var/www/blog && tar xzf /tmp/upload.tar.gz')

Esto redujo un despliegue de 5 minutos a menos de 30 segundos.

La Trampa del Caché CDN de Cloudflare

Después de desplegar, verificábamos obteniendo la URL en vivo — y a veces el contenido antiguo seguía mostrándose. El culpable: el caché CDN de Cloudflare, incluso cuando Nginx estaba configurado con Cache-Control: no-cache.

La parte complicada: nuestro DNS de gfil-lab.com estaba configurado como "Solo DNS" (nube gris), no como "Proxy" (nube naranja). Esto significa que Cloudflare no debería estar almacenando nada en caché — las solicitudes van directamente a nuestro servidor Nginx. Pero algunos ISP y proxies corporativos aún almacenan respuestas en caché. La solución:

# Agregar encabezados de invalidación de caché a la configuración de Nginx
location ~* \.(html|xml|txt|md)$ {
    add_header Cache-Control "no-cache, must-revalidate" always;
}

# Cuando necesites forzar una actualización, agrega un parámetro de consulta
# https://gfil-lab.com/tools/entity.html?v=2

Pero la verdadera lección: cuando tu archivo local es correcto pero el sitio en vivo muestra contenido antiguo, no asumas que el despliegue falló. Verifica primero directamente en el servidor (curl http://localhost/tools/entity.html desde el propio servidor) antes de pasar horas depurando un despliegue que en realidad fue exitoso.

Lección: Siempre Verifica del Lado del Servidor Primero

Perdimos un ciclo completo de auditoría pensando que nuestro despliegue había fallado. El revisor de Claude verificó la URL en vivo y encontró contenido antiguo. Redesplegamos. Mismo resultado. Resultó que el servidor tenía los archivos correctos desde el principio — el contenido obsoleto provenía de una capa de caché intermedia.

Nuestra lista de verificación ahora:

1. Verificación del lado del servidor: curl http://localhost/path desde el servidor — evita todos los cachés
2. Verificación externa: curl https://domain/path desde fuera — prueba lo que ven los usuarios
3. Hash de contenido: Comparar cadenas específicas (ej., grep -c "liudapao880807-arch" /var/www/blog/tools/entity.html) en lugar de comparar archivos completos

Esta verificación de tres pasos nos ha salvado de falsas alarmas de "despliegue fallido" varias veces desde entonces.

Prueba Nuestras Herramientas Gratuitas

Esta infraestructura impulsa 22 calculadoras de trading gratuitas en 4 idiomas. Prueba la Calculadora de Tamaño de Posición — maneja Forex, Oro, Cripto e Índices con valores pip correctos para más de 30 instrumentos.