Why having our own node in São Paulo matters

Almost every reverse tunneling provider (ngrok, Cloudflare Tunnel, Tailscale Funnel, etc.) runs their servers in the US and Europe. Makes sense at their scale. But when you're a customer in Brazil and your end users are in Brazil too, every bit makes a roughly 12,000 km round-trip before reaching the destination.

The practical impact on latency

Real measurements from 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

Why this changes everything in some cases

For a simple webhook (stateless, one request per event), 200 extra milliseconds make no difference. But for interactive use the gap is dramatic:

• RDP / SSH — every keystroke needs the round-trip. With 180 ms it feels laggy; with 15 ms it feels local.
• Database — a simple query that does 10 round-trips goes from 150 ms to 1,800 ms.
• RTSP IP camera — the buffer has to absorb the latency or it keeps stalling.

Picking the right node in the panel

When you create a tunnel, pick the node closest to your end user, not closest to your machine. If you're in Brazil and your user is in Lisbon, eur1 (Frankfurt) probably feels better than spo1 (São Paulo) — even for you.

When in doubt, measure: create the same service through two tunnels in different nodes and compare with curl -w or mtr. The dashboard does not replace real measurement.