Pourquoi avoir un nœud propre à São Paulo compte

Presque tous les fournisseurs de tunneling inverse (ngrok, Cloudflare Tunnel, Tailscale Funnel, etc.) opèrent des serveurs aux États-Unis et en Europe. Ça a du sens à leur échelle. Mais quand vous êtes client au Brésil et que votre utilisateur final l'est aussi, chaque bit fait un aller-retour d'environ 12 000 km avant d'arriver à destination.

L'effet pratique sur la latence

Mesures réelles depuis 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 (Francfort) : 180–210 ms
• ngrok.io (us-east-1) : 140–170 ms

Pourquoi cela change tout dans certains cas

Pour un webhook simple (sans état, 1 requête par événement), 200 ms de plus ne changent rien. Mais pour un usage interactif, l'écart est énorme :

• RDP / SSH — chaque touche tapée nécessite l'aller-retour. À 180 ms, ça donne une sensation de lag ; à 15 ms, ça semble local.
• Base de données — une requête simple avec 10 allers-retours passe de 150 ms à 1 800 ms.
• Caméra IP RTSP — le buffer doit absorber la latence ou ça gèle régulièrement.

Comment choisir le bon nœud dans le panneau

En créant un tunnel, choisissez le nœud le plus proche de votre utilisateur final, pas du vôtre. Si vous êtes au Brésil et exposez un service à un client à Lisbonne, le nœud eur1 (Francfort) sera probablement meilleur que spo1 (São Paulo) — même pour vous.

Au moindre doute, mesurez : créez le tunnel pointant vers le même service sur 2 nœuds et comparez avec curl -w ou mtr. L'interface graphique ne remplace pas une mesure réelle.