Quick Tunnels Cloudflare : quand localhost devient une star du web
J’ai vu ce bug des dizaines de fois. La semaine dernière, un client m’appelle, paniqué : « Marc, mon site de démo doit être présenté dans une heure à un investisseur, mais il tourne sur mon PC ». Autant dire que le timing était serré. Sauf que voilà, les quick tunnels cloudflare existent depuis un moment, et personne ne les utilise. C’est dommage, parce que ça transforme un localhost:3000 en adresse publique en une seule commande, sans compte, sans configuration, sans passer par la case « je paye un VPS pour rien ».
Cloudflare a sorti cet outil via son binaire cloudflared, et mine de rien, ça fait le job. Pas de DNS à bidouiller, pas de certificat SSL à se taper à la main, pas de reverse proxy nginx à configurer à 23h. Tu tapes une ligne, tu récupères une URL en trycloudflare.com, et tu l’envoies à qui tu veux. Pour être honnête, j’aurais adoré avoir ça il y a dix ans quand je faisais des démos clients avec des IP dynamiques qui changeaient toutes les six heures.
Quick tunnels cloudflare : comment ça marche vraiment sous le capot
Le principe est simple. cloudflared ouvre une connexion sortante vers l’infrastructure de Cloudflare. Cette connexion reste ouverte, et Cloudflare te file une URL publique qui pointe dessus. Du coup, ton routeur n’a pas besoin d’ouvrir un port, ton IP reste cachée, et le trafic arrive directement sur ta machine par un tunnel chiffré. Évidemment, il y a un revers à la médaille : tout ce qui touche à ta machine devient accessible publiquement.
J’insiste là-dessus parce que j’ai déjà vu un stagiaire exposer sa base de données de test avec un tunnel grand ouvert. Trois jours plus tard, il recevait des mails de rançon. Véridique.
Installation : deux minutes, pas plus
Sur Linux ou macOS, un petit coup de brew install cloudflared ou un téléchargement direct du binaire. Sur Windows, tu chopes l’exécutable sur le site de Cloudflare, tu le fous dans un dossier du PATH, et roule. Rien de sorcier.
- Linux :
wgetdu binaire,chmod +x, déplacement dans/usr/local/bin - macOS :
brew install cloudflaredet c’est plié - Windows : téléchargement du
.exe, ajout au PATH, un redémarrage du terminal
Une fois installé, la commande magique ressemble à ça : cloudflared tunnel --url http://localhost:3000. Et là, en quelques secondes, tu vois apparaître une URL du genre https://random-words-here.trycloudflare.com. Tu la partages à ton client, à ton pote, à ton investisseur. Ça marche.
Le piège de Vite qui m’a fait perdre deux heures
Alors là, il faut que je vous raconte. Un pote dev me dit : « Marc, ton tunnel il marche pas, mon site affiche une erreur 521 ». Je regarde, je teste, je me gratte la tête. Le tunnel était bien actif, l’URL répondait. Sauf que le site derrière, c’était du Vite. Et Vite, par défaut, refuse les requêtes dont le Host header ne correspond pas à ce qu’il attend.
Du coup, la solution, c’est de lancer Vite avec l’option --host et de configurer allowedHosts dans le vite.config.js. Sinon, le tunnel te renvoie un joli « Invalid Host header » qui te fait croire que Cloudflare est cassé, alors que c’est ton bundler qui fait de la paranoïa mal placée. Mine de rien, ce genre de détail te bouffe une soirée si tu ne sais pas où regarder.
Pour être honnête, je ne suis pas certain à 100% que toutes les versions de Vite se comportent pareil. D’après mon expérience en atelier, les versions récentes sont plus souples, mais j’ai encore vu le cas la semaine dernière sur un projet en Vite 4. Donc méfiance.
–allowed-mail : la nouveauté qui change la donne depuis la 2026.9.3
Là, on touche à un truc que j’attendais depuis longtemps. Depuis la version 2026.9.3 de cloudflared, tu peux restreindre l’accès à ton tunnel à une liste d’adresses mail précises. La commande ressemble à ça : cloudflared tunnel --url http://localhost:3000 --allowed-mail marc@total-depannage.com.
Concrètement, quand quelqu’un ouvre l’URL, Cloudflare lui demande de s’authentifier avec une adresse mail. Si elle n’est pas dans la liste, il reste à la porte. Autant dire que ça change tout pour les démos clients ou les previews d’app en cours de dev. Fini le scénario où tu envoies un lien à un pote et où le lendemain tu découvres que Google a indexé ton prototype tout pété.
Ce que ça ne protège pas
Attention, hein. –allowed-mail ne protège pas contre une mauvaise configuration de ton app. Si ton back-end expose une API sans auth derrière le tunnel, le mail ne servira à rien.
- Ça ne chiffre pas les données côté application
- Ça ne remplace pas un vrai système d’authentification
- Ça ne bloque pas les attaques applicatives (injection SQL, XSS, j’en passe)
- Ça ne t’exonère pas de couper le tunnel quand tu as fini
Je le dis parce que j’ai vu des gens s’imaginer que c’était une solution de sécurité. Non. C’est une porte fermée à clé, mais la fenêtre reste ouverte si tu ne fais pas attention au reste.
Le hook pour empêcher Claude Code d’ouvrir un tunnel public
Là, on rentre dans le territoire marrant. Vous savez que certains outils de dev assistés par IA adorent lancer des commandes toutes seules, histoire de « tester ». Sauf que si l’outil en question se met à exécuter cloudflared tunnel sans prévenir, tu te retrouves avec ton projet en cours exposé sur Internet sans l’avoir demandé. Pas top.
La parade, c’est un hook qui intercepte la commande avant qu’elle ne s’exécute. Sous Git, tu peux par exemple bloquer via un pre-commit hook qui grep les fichiers de config pour détecter les tunnels ouverts. Sous Linux, un alias shell qui redirige cloudflared tunnel --url vers un message d’avertissement marche aussi. Du coup, tu gardes le contrôle.
C’est un peu paranoïaque, je vous l’accorde. Mais après quinze ans à voir des fuites de données par négligence, je préfère être parano. La semaine dernière encore, un client m’a appelé parce qu’un de ses devs avait laissé un tunnel ouvert pendant trois semaines sur un serveur de staging. Avec les credentials AWS en clair dans le .env. Autant dire que la facture a piqué.
Windows, cette plaie : la MAJ qui casse cloudflared
Évidemment, Windows a encore tout cassé avec la MAJ. Windows 11 version 24H2 a introduit un comportement bizarre avec les binaires non signés exécutés depuis un dossier utilisateur. Résultat : cloudflared se lance, mais le tunnel tombe au bout de trente secondes sans aucune erreur visible. Génial.
Le contournement que j’utilise en atelier, c’est de déplacer le binaire dans C:\Program Files\cloudflared\ et de l’exécuter en tant qu’administrateur la première fois. Après ça, Windows semble se calmer. Je ne suis pas certain à 100% que ce soit la cause exacte du problème, mais dans les cinq derniers cas que j’ai traités, ça a réglé le souci. Si vous avez une meilleure explication, je prends.
Pour être honnête, je pense que Windows devient de plus en plus hostile aux outils en ligne de commande un peu exotiques. Entre Defender qui bloque, SmartScreen qui panique, et les politiques de groupe qui s’invitent dans le game, on n’a pas fini de rigoler.
Sur macOS et Linux, ça roule
Rien à signaler côté Unix, mine de rien. Sur Ubuntu, Debian, Fedora, Arch, ça tourne comme une horloge. Sur macOS avec les puces Apple Silicon, utilisez bien le binaire arm64, sinon vous allez vous arracher les cheveux avec Rosetta qui fait n’importe quoi. Une fois le bon binaire installé, c’est d’une stabilité exemplaire.
Mon avis tranché : à utiliser, mais avec les yeux ouverts
Les quick tunnels Cloudflare, c’est un outil que j’aurais rêvé d’avoir il y a dix ans. Pour les démos, les tests à distance, les previews clients, c’est imbattable. Zéro configuration, zéro compte, zéro friction. Et depuis l’arrivée de –allowed-mail, on peut même se la jouer un peu sérieux sans tomber dans l’usine à gaz.
Cela dit, je vois trop de devs l’utiliser comme solution permanente. Un tunnel qui tourne H24 sur ta machine de dev, c’est une porte dérobée qui attend patiemment qu’on la trouve. Les URLs trycloudflare.com sont random, certes, mais elles finissent dans les logs, dans les navigateurs, dans les historiques. Ne laissez jamais un tunnel ouvert plus longtemps que nécessaire.
Autre point : ne comptez pas sur les quick tunnels pour de la prod. Cloudflare propose des tunnels nommés, avec authentification, domaine personnalisé, monitoring. C’est un autre produit, ça demande un compte, mais c’est fait pour ça. Les quick tunnels, c’est l’outil du dimanche soir quand tu veux montrer un truc vite fait. Pas plus.
Du coup, si vous êtes dans le dev web et que vous ne connaissiez pas encore, testez. Ça prend cinq minutes à installer et ça sauve des situations. Et si vous tombez sur le bug Vite ou sur la MAJ Windows qui fait des siennes, vous saurez à qui vous adresser. Je suis joignable via total-depannage.com, et pour la source originale de cet article, c’est par ici : le tuto de Korben sur les quick tunnels Cloudflare.
Et pendant ce temps, dans l’atelier…
Ce matin, un client m’appelle parce qu’il n’arrivait plus à pousser sur GitHub. Trois heures de debug plus tard, on découvre que son tunnel Cloudflare tournait encore depuis la veille et redirigeait tout son trafic local vers une URL publique random. Le mec avait collé l’URL dans son git remote par erreur. Autant dire que j’ai facturé la séance avec le sourire.
Moralité : les quick tunnels, c’est puissant, mais ça se manipule comme un fer à souder. Avec attention. Et surtout, on les coupe quand on a fini. Ctrl+C, vérification que l’URL renvoie bien une erreur, et on passe à autre chose. C’est pas plus compliqué que ça.
Source : article original
