Por que ter um nó próprio em São Paulo importa

Quase todo provedor de tunelamento reverso (ngrok, Cloudflare Tunnel, Tailscale Funnel, entre outros) opera servidores nos EUA e Europa. Faz sentido pela escala. Mas quando você é cliente no Brasil e seu usuário final também é, todo bit do seu tráfego dá uma volta de aproximadamente 12.000 km — ida e volta — antes de chegar no destino.

O efeito prático em latência

Medições reais que fizemos a partir de 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 que isso muda tudo em alguns casos

Para um simples webhook (que é stateless e tem 1 request por evento), 200 ms a mais não fazem diferença. Mas para uso interativo a diferença é gritante:

• RDP / SSH — cada tecla digitada precisa fazer o round-trip. Com 180 ms vira sensação de "atraso" perceptível; com 15 ms parece local.
• Banco de dados — uma query simples que faz 10 round-trips vai de 150 ms para 1.800 ms.
• Câmera IP RTSP — o buffer precisa absorver a latência ou trava periodicamente.

Como escolher o nó certo no painel

Ao criar um tunnel no painel, escolha o nó mais próximo do seu usuário final, não da sua máquina. Se você no Brasil expõe um serviço para um cliente que está em Lisboa, o nó eur1 (Frankfurt) provavelmente entrega melhor desempenho do que spo1 (São Paulo) — mesmo para você.

Em caso de dúvida, faça o teste: crie o tunnel apontando para o mesmo serviço em 2 nós e meça com curl -w ou mtr. A interface gráfica não substitui medição real.