Por qué tener un nodo propio en São Paulo importa

Casi todo proveedor de tunelización inversa (ngrok, Cloudflare Tunnel, Tailscale Funnel, etc.) opera servidores en EE.UU. y Europa. Tiene sentido por escala. Pero cuando eres cliente en Brasil y tu usuario final también, cada bit hace una vuelta de unos 12.000 km — ida y vuelta — antes de llegar al destino.

El efecto práctico en latencia

Mediciones reales hechas desde São Paulo:

• spo1.nodes.superdmz.com (São Paulo): 12–18 ms
• usa1.nodes.superdmz.com (Atlanta): 120–145 ms
• eur1.nodes.superdmz.com (Frankfurt): 180–210 ms
• ngrok.io (us-east-1): 140–170 ms

Por qué esto cambia todo en algunos casos

Para un webhook simple (sin estado y con 1 request por evento), 200 ms extra no marcan diferencia. Pero para uso interactivo es enorme:

• RDP / SSH — cada tecla requiere el ida y vuelta. Con 180 ms se siente lento; con 15 ms parece local.
• Base de datos — una consulta simple que hace 10 idas y vueltas pasa de 150 ms a 1.800 ms.
• Cámara IP RTSP — el buffer tiene que absorber la latencia o se traba.

Cómo elegir el nodo correcto en el panel

Al crear un túnel en el panel, elige el nodo más cercano a tu usuario final, no al tuyo. Si estás en Brasil y expones un servicio para un cliente en Lisboa, el nodo eur1 (Frankfurt) probablemente entrega mejor desempeño que spo1 (São Paulo) — incluso para ti.

En caso de duda, mide: crea el túnel apuntando al mismo servicio en 2 nodos y mide con curl -w o mtr. La interfaz gráfica no reemplaza una medición real.